US20140181842A1

US20140181842A1 - Secure mobile app connection bus

Info

Publication number: US20140181842A1
Application number: US14/137,845
Authority: US
Inventors: ManSu Kim; Joshua Sirota; Suresh Kumar Batchu
Original assignee: MobileIron Inc
Current assignee: Ivanti Inc
Priority date: 2012-12-21
Filing date: 2013-12-20
Publication date: 2014-06-26
Also published as: EP2936733A4; WO2014100756A1; US9537835B2; US20150319143A1; US9059974B2; EP2936733A1; EP2936733B1; US20140181518A1; CN105027493A; CN105027493B

Abstract

A secure mobile app connection bus is disclosed. An application URL scheme may be registered with an operating system. Encrypted data may be passed from a management agent to an application using a URL call associated with the application URL scheme. A source of the URL call may be validated.

Description

CROSS REFERENCE TO OTHER APPLICATIONS

This application claims priority to U.S. Provisional Patent Application No. 61/745,052 entitled SECURE MOBILE APP CONNECTION BUS filed Dec. 21, 2012 which is incorporated herein by reference for all purposes.

BACKGROUND OF THE INVENTION

Today enterprise users on mobile devices, which may belong to the user or be owned by the enterprise, use apps developed by enterprise in-house developers, or apps from trusted app store or untrusted 3rd party app stores. Each app may have its own way of managing its configuration, policy and data. This makes it difficult for enterprises to manage and enforce apps configuration and policies while securing app data consistently across all apps.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a table including applications according to various embodiments.

FIG. 2 is block diagram illustrating embodiments of a system including a secure mobile app connection bus.

FIG. 3 is block diagram illustrating embodiments of a system including a secure mobile app connection bus.

DETAILED DESCRIPTION

Techniques described herein help the management server and management agent to have a two-way secure application command bus to manage apps (configurations and policies) on mobile devices while keeping the user experience intact.
In various embodiments, an AppConnect bus is provided in mobile devices, which may be used to send command/information securely between managed apps and a trusted management agent running on the mobile device.
Detailed flow of the solution as implemented in some embodiments is described below:
VSP stands for Virtual Smartphone Platform by Mobilelron. All managed mobile devices' configuration, policies and apps are managed from here. Mobilelron clients connect to VSP on a periodic basis to update the device status as well as get the new configuration and policies.
Sentry is a reverse proxy for enterprise app traffic between mobile devices and the enterprise backend servers.
FIG. 1 is a table including applications according to various embodiments.
FIG. 2 is block diagram illustrating embodiments of a system including a secure mobile app connection bus.
(1) User creates application policies and configuration on VSP. VSP compile this information with parameters specific to user/devices (for example, change $USER_ID$ to actual user id for login, or issuing identity certificate for user/device).
(2) VSP will push Compiled and encrypted configuration to management agent (It can be standalone apps on mobile device or agent module part of enterprise apps.) This configuration is decrypted by each target app with proper decryption keys.
(3) Management Agent will push received AppConnect configuration to device specific AppConnect Bus with timestamps and checksums.
(4) When each app launches for the first time or becomes foreground, an embedded AppConnect library reads the latest configuration and applies a new configuration if there are changes. In some embodiments, the AppConnect library is embedded in the application code of the app, e.g., the app developer embeds the library in the app using a software development kit (SDK) or other tool, or subsequent to app development by the original developer the app is “wrapped” or otherwise modified by adding or changing app code to embed the library. In some embodiments, the new configuration, if any, may include a new configuration data and/or policy for the app. The configuration may affect or control how the app should work, for example, or a policy may govern how the app should or may behave. An example of policy includes, without limitation, whether the app is permitted to perform copy/paste operations, is it allowed to print, etc. Examples of configuration include, without limitation, which server the app should connect to, etc.
(5) Each app which applies the changes will update AppConnect bus with result.
(6) Management Agent will read the result. If local policy enforcement is enabled, Management Agent can push predefined configuration to AppConnect bus if local policy condition met.
(7) Management agent will update result to VSP.
(8) VSP analyzes the result and if it does meet quarantine policy requirement the VSP can send a command to Sentry to quarantine the device. Also this quarantine command will be sent to the device. In some embodiments, the device may be configured to perform an action in response to the command, such as wipe all or only enterprise data, not all the use of enterprise apps, etc.
(9) VSP will update result to each app configuration and app policies.
FIG. 3 is block diagram illustrating embodiments of a system including a secure mobile app connection bus.
AppConnect Bus: communication bus in devices which send/receive information between applications securely. Depends on device OS and capability, AppConnect Bus can be implemented in different ways depending on the requirements, capabilities, and limitations of the OS.
For example:


OS	Description

iOS	Application pasteboard with security with encryption
	Registered URL scheme with encrypted payload with source validation
	Shared keychain with injected keychain-access-groups -
	Validated Protocols/URL Scheme: Validating Installed application with
	application's URL scheme, make sure trusted app holds protocols/URL schemes
	required. For example, before install apps, which require URL scheme
	‘ironvault://’, check it whether it exist on the device.
Android	Certificate based Authenticated intention with encryption
Windows	Shared Certificate store and share protocol registration/file types
Phone

Secure Information sharing between apps: Application naturally shares information with other apps like photo, text, URLS. For security, this information will be encrypted and only distributed to allowed apps using AppConnect Bus.
For example:


Category	Description

Copy and Paste	Secure pasteboard which will encrypt content and
	allowed to share between trusted apps
File Exchange	When a trusted app tries to share a file, it will be shared
	only between trusted apps.

The following are examples, without limitation, of configurations, settings, and/or policies that may be communicated and set via the AppConnect bus in some embodiments:
Application configuration: Each application requires certain configuration/setting to operate. For example:


Information	Description

Server	Server name or IP address to access data
information
User Identity	User name with password or User or device certificate to
information	identify it to server

Application Policies: Management system want to force application management policy to application depends on enterprise policy, location, device security state, other application install state or user's group changes.
For example:


Policy	Description

Hardware	Block access by this app to Device's Camera, Bluetooth, NFC, USB,
control	other resources (set by user, group, app, time, location, etc.)
Storage access	Block access to device's storage (SD, Flash, Photo)
control
PIM access	Block access to device Email, Calendar, Contacts or allow to limited
control	to certain email account, calendar or contacts. For example, only allow
	to company email, calendar or contacts instead of personal.
Access control	Block access to app from system services like AirPrint, Share Email,
to system	Share with other apps
service

Information sharing: Sharing device, user or list of installed application with apps to allow application add functions based on this information.


Information	Description

Device	Management ID, MAC address, IMEI or other management
Information	token
Enterprise	Enterprise Emergency information
Information
Installed	Installed Application list with capability (open-in
applications	documents, secure copy paste support etcs)

Application Actions: When Enterprise administrator want to send command to application, it will be send to application via command bus.
For example:


Command	Action

Wipe	Wipe Application data and make it first installation state
	(option. Zero-out bytes before detele)
Remote	Enterprise access will be lock until user unlock. While locked
Lock	state any trusted apps's data will not able to accessed by apps.

Application Firewall: Application is not build to identify security of it's connected Wi-Fi networks or even it's identity and security of it's connected server. Application Firewall will validate and protect application from receiving untrusted party's data.
For example firewall rules:


Command	Action

Enforced	For each SSL/TLS connections, Server certificate will be
Server	validated before allow connection
certificate
validation
Allowed	only allow made connection to allowed network
network
Augmented	Instead of relying system's DNS server, application
Address	firewall can use secure DNS server which provide
lookup	additional security with authentic address information.
	(for example, opendns) or using host file pushed by
	management server
Content	Client side only inspection or Server assisted content
inspection	inspection to remove any malicious content

Enterprise authentication: Before allowing access to enterprise command bus (i.e., AppConnect bus), User has to authenticate identity.
For example, User ID with Password or preconfigured PIN, onetime password, NFC, 2D Barcode can be used to identify user, for example upon opening a protected app.

EXAMPLES

The following examples illustrative aspects of techniques disclosed herein:
1. Application Pasteboard with Security with Encryption
a. There is a common application paste board that is available in iOS. Applications can use them for exchange of data within or between applications (for more information read https://developer.apple.com/library/ios/#documentation/general/conceptual/Devpedia-CocoaApp/Pasteboard.html). In some embodiments, this pasteboard is used as a place to exchange the AppConnect (secure app connection bus) information/data between apps as disclosed herein. For example a management agent running on the mobile device will download the configuration or policy from the mobile device management server, and put that data on the pasteboard for recipient app to pick up that data.
2. Registered URL Scheme with Encrypted Payload with Source Validation
a. Applications can register their URL scheme with the OS so that either OS or other apps can reference/invoke the app. For example an application “ABC” can register the URL scheme “abc://” so that anytime OS or other apps need to invoke “ABC” they can call it by the URL “abc://”. OS will look up and see who registered for that URL and call that app. Any data that want to exchange between the apps then we can have the apps register their URLs and the management app can pass the data to those apps using URL mechanism. For example management want to pass the data “12345” to app “ABC” then it can call the URL “abc://12345” and when that app ABC receives the URL it will parse the URL and take the content “12345” for its use.
3. Shared Keychain with Injected Keychain-Access-Groups
a. OS provides a common place to store the certificates for the apps to use. In some embodiments, that certificate store is used to exchange information between apps. The information is secured such that only the intended recipient app(s) can understand the encrypted message in the keychain.
4. Certificate Based Authenticated Intention with Encryption
a. In Android there are intents that can be used to communicate between apps. (more info can be found here
https://developer.android.com/reference/android/content/Intent.html). We can encrypt the payload of the intent so that only intended recipient app(s) can understand the payload
5. Shared Certificate Store and Share Protocol Registration/File Types
a. Shared certificate store is similar to what I have explained above.
b. Shared protocol registration/file types
i. Each app can register for certain file type and that will help management app to put all the enterprise data in an encrypted file and when it tries to open the file the intended app will get called. (for more information http://msdn.microsoft.com/en-us/library/windows/apps/hh464906.aspx)

Claims

What is claimed is:

1. A method, comprising:

registering an application URL scheme with an operating system;

passing encrypted data from a management agent to an application using a URL call associated with the application URL scheme; and

validating a source of the URL call.