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.
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.
(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.
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:
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:
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:
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:
Information sharing: Sharing device, user or list of installed application with apps to allow application add functions based on this information.
Application Actions: When Enterprise administrator want to send command to application, it will be send to application via command bus.
For example:
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:
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.
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)
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.
Number | Date | Country | |
---|---|---|---|
61745052 | Dec 2012 | US |