The following checklist is intended to be used as a baseline for assessing, designing, and testing the security of a MAM solution and is thus aptly suited to assist three major stakeholders in the BYOD space: buyers, builders, and breakers. This list was constructed from our experience and research assessing a variety of MAM solutions in the marketplace today. This research was presented at Blackhat USA 2014 and the slides can be downloaded here and the published whitepaper can be downloaded here. This should not be considered an exhaustive list, but rather a compilation of major test cases that can be used to determine the security posture of a MAM solution. As always, contributions/recommendations from the community are welcome in an effort to further expand this checklist. It should be noted that several of the test cases require significant reverse engineering and advanced mobile application testing skills. Therefore, it is recommended that organizations consult skilled security professionals to perform/verify the test cases.
| Implementation of MAM Secure Container Authentication | |
|---|---|
| 1 | Stored encrypted data should be protected using key material that is only accessible upon successful offline or online authentication |
| 2 | Online authentication should aim to retrieve the key material from the MAM admin server. This provides the ability to enforce passcode lockout attempts |
| 3 | Online key material or any Content Encryption Key (CEK) derived from the online key material should never persist on the disk |
| 4 | If the policy is configured to only allow online authentication, the MAM agents or managed apps should not be susceptible to any offline attacks due to storing offline authentication hashes |
| 5 | Key material must be deleted from memory upon entering an unauthenticated state (server initiated application lock, session timeouts, sign off, etc.) |
| 6 | Incorrect passcode attempts beyond the configured threshold should result in the deletion of all device key material and stored application data |
| 7 | Strict incorrect passcode attempts policy should be configured by default |
| 8 | Offline authentication must utilize a strong key derivation function (e.g. PBKDF2) that is configured with sufficient work factor (e.g. 20,000 minimum) to generate the Key Encryption Key (KEK). The work factor should be increased over time to account for hardware advancements |
| 9 | Ensure a secure random salt of sufficient length is used by the key derivation function to prevent attacks involving pre-computed keys |
| 10 | Offline authentication passcode should not be the same password as the employee's primary Active Directory or SSO password |
| 11 | Offline passcode complexity policies should be sufficiently strong in order to mitigate offline passcode brute force attempts (Minimum of five characters with numbers and special characters recommended) |
| 12 | The key derivation routines used for offline passcode validation and symmetric key derivation should be the same. A malicious user should not be able to perform a faster brute force on one routine over the other |
| 13 | MAM agent and wrapped applications should have a reasonably short session timeout in order to force the user to re-authenticate |
| 14 | Validate that the offline/online authentication routines within the wrapped applications match that of the MAM agent |
| 15 | If MAM server authentication tokens and/or client certificates must be stored, they should be encrypted using the CEK and made available to the application only after the user successfully enters their passcode |
| 16 | If an application requires online access to function, the organization should consider enforcing online authentication policies for the application |
| Implementation of MAM Secure Container Cryptography | |
| 17 | Identify the secure random number generator library and routine used throughout the solution and ensure it is not vulnerable to known issues |
| 18 | Validate that the cryptography used to protect any sensitive data is utilizing FIPS compliant library (if solution claims they are FIPS compliant) |
| 19 | The solution should not utilize an insecure mode of encryption |
| 20 | Solution should utilize secure random IV/nonce of sufficient length when encrypting data. IVs and nonces should not be derived from deterministic data and must never be reused |
| 21 | Ensure encrypted data stored is not susceptible to tampering by performing an HMAC of the ciphertext and validating the value prior to decryption |
| 22 | Beware of using string objects to hold sensitive binary data (Cryptographic Keys, IVs, Salts) as it could lead to unexpected charset encoding and a loss of entropy |
| 23 | The solution should avoid utilizing database encryption solutions such as SQLCipher to encrypt/decrypt application data as it will cause the symmetric key to be stored as a string |
| 24 | The solution should avoid storing passcode or cryptography keys on the heap as it will cause the key to persist in memory for an extended period of time. The data will only be removed from memory once the garbage collection is performed. |
| 25 | Verify third party cryptography library is not out of date and susceptible to any vulnerabilities that apply to the MAM solution |
| Completeness of MAM Wrapping | |
| 26 | Verify that common APIs that persist data on the file system will be adequately wrapped and encrypted by the solution. The recommended way to perform file system wrapping is by hooking system calls in order to ensure coverage across APIs provided by higher level code. |
| 27 | If the solution claims to be FIPS compliant, ensure that the FIPS compliant library is used consistently across the solution to protect enterprise data. |
| 28 | Wrapped application should not be utilizing device level data protection as the primary form of encryption since it requires a passcode being set on the device |
| 29 | If data written to external storage undergoes path based analysis in order to determine if the file should be encrypted, the solution must take symbolic links into consideration. Android devices contain several symbolic links to the external storage that may not be taken into consideration by the solution |
| 30 | Ensure data stored within Webviews are adequately wrapped and data will be encrypted by the solution (HTML5 storage, Cached Pages, Cookies, etc) |
| 31 | Custom URL schemes rendered within Webviews (e.g. tel, mailto, sms, etc.) should contain security controls to prevent leakage (e.g. telephone numbers, email addresses, etc.) to unmanaged applications |
| 32 | Verify that native or low level APIs (NDK, C functions) are also wrapped and data will be encrypted by the solution |
| 33 | Files opened by a wrapped application should not lead to unencrypted storage of cached documents |
| 34 | Cached HTTP response data should not be written to the file system unencrypted |
| 35 | Persistent HTTP cookies should not be written to the file system unencrypted |
| 36 | Data written to the system pasteboard by a wrapped application should be encrypted |
| 37 | Data written using cloud based APIs should be encrypted (iCloud, Backup API, etc) |
| 38 | Snapshot Caching when sending applications to the background should be actively prevented within wrapped applications |
| 39 | Verify that notifications from any wrapped applications do not appear on the home screen. This includes unencrypted filenames, sensitive app data, etc. |
| 40 | Filenames should be encrypted by the applications |
| 41 | Files opened by a wrapped applications (Open-in) should remove any plaintext copies made into its application container |
| 42 | Any application APis that rely on device level policies (e.g. iOS Keychain) should not be used to store sensitive data within the MAM agent or wrapped applications |
| 43 | The wrapping solution should be able to handle language specific introspection/reflection if used on a wrapped API |
| 44 | The MAM agent should try to encrypt all data except values that would be required prior to authentication. |
| 45 | Solution should restrict wrapped apps from sending data to other systems via exposed system APIs (e.g. AirDrop APIs) |
| Implementation of the MAM Inter-Process Communication | |
| 46 | IPC entry points within the MAM agents and wrapped applications should validate the calling application to ensure it is trusted |
| 47 | IPC messages should not be susceptible to forgery by third party applications |
| 48 | Data passed through IPC between the MAM agent and wrapped applications should not be readable by third party applications |
| 49 | Verify how keys are exchanged or generated within managed/wrapped apps if encryption is performed (e.g. URL Schemes, Content Providers, Intents, etc.). The key exchange process should contain authorization checks to ensure it cannot be invoked or sniffed by third party applications |
| Effectiveness of Client Side Security Controls | |
| 50 | Security policies sent from the MAM server to the MAM mobile agent should be digitally signed to prevent trivial modification over the network by a malicious user |
| 51 | Security policies should not be stored in plaintext on the device to prevent trivial modification by a malicious user |
| 52 | Solution should provide restrictions on any IPC calls wrapped apps can make into an unmanaged application |
| 53 | Solution should incorporate obfuscation of client-side code to increase the difficulty in reverse engineering. |
| 54 | Jailbreak/Root detection should not be susceptible to trivial bypasses. For example, using the xCon Cydia application or by simply writing a hook for a “isJailbroken” method. It is recommended that jailbreak detection be written in low level code and placed inline across various methods in the application. |
| Effectiveness of Remote Lock and Wipes | |
| 55 | Server invoked data wipes should cause all data to be removed from the MAM Agent (This includes encrypted documents, encrypted key material, offline passcode validation data, etc) |
| 56 | Server invoked data wipes should cause all data to be removed from the Wrapped Applications (This includes encrypted documents, encrypted key material, offline passcode validation data, etc) |
| 57 | Server invoked security commands should be invoked on the device immediately. The user should not need to interact with the application in order to invoke a polling request |
MAM Security Checklist by Gotham Digital Science is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.
React
Typescript
Django
Laravel
Facebook
Microsoft
Google
Alibaba
D3
Tencent