Requirements of Crypto

[sushi2k]

https://github.com/sushi2k/owasp-masvs/blob/master/Document/0x08-V3-Cryptography_Verificiation_Requirements.md#requirements

Following comments for discussion:

• 3.6: As far as I understand, Oracle Padding is not really applicable to a mobile application and something an attacker would do against a mobile App. The requirement is good, but I would delete Oracle Padding. Or is this a risk for a mobile App?
• 3.9: This is describing the usage of e.g. a PKI. The MASVS will be used for creating mobile applications. I think this requirement is addressing problems on a OS layer, like certificates for 802.1X authentication or certificates/keys for VPN.
• 3.10: Is there a best practice for this on iOS/Android?
• 3.11: I think this should already be in Level 2, e.g. as using HSM is anyway enforced for Financial Institutions.

[commjoen]

3.6: padding oracle can be a problem in cases of wrongly applied payload encryption and then there are things like POODLE, but that requires you to not configure your server correctly. 3.9: key lifecycle management can be an issue in apps, but only in those of high risk that actually use pki for signing or authentication means. 3.10: there are best-practices for Android, this include applying the PRNGfix that has been published for older android versions (pre 4.2). For iOS there are also best practices in terms of sources and seeding. But most of this is technology dependent, it is not really something for the MASVS itself right? 3.11: 👍

[muellerberndt]

Using HSM is anyway enforced for Financial Institutions.

Can you elaborate?

[sushi2k]

@b-mueller: I thought this is at least enforced in Singapore, but I couldn't find anything that enforces this for FI in Singapore in MAS-TRM. Guess I had remembered it wrongly.

[muellerberndt]

The crypto-chapter is lacking at the moment. We need to better clarify the role of crypto hardware and HSMs in the requirements, and have more details on how the crypto APIs are to be used instead of just "follow best practices".

The first question is the role of hardware-backed key storage in the requirements. On iOS, starting with A7 devices, file encryption is hardware-backed through the secure enclave. The unwrapped file keys are never exposed to the main CPU, and from what I know the secure enclave is somewhat secure against tampering (however there have been some attacks, such as updating the firmware to allow for faster passcode brute-force attacks). Encryption keys are generated from the device UID (non-retrievable) and the user's passcode. Using the device UID means that the attacker needs access to the device to decrypt the data.

The main problem with this however is the dependence on a strong passcode. Four-digit PINs are very common and can easily be brute-forced, even with the hardware-enforced 5 second delay. Clearly, the best possible solution is to use iOS Keychain in combination with a strong passphrase. But an app cannot verify the strength of the passphrase (can it verify if a passphrase is set at all?). So from the perspective of the app, using it doesn't guarantee that the sensitive data is encrypted securely.

On Android, OEMs may or may not a provide hardware-backed Keystore. For example, ARM TrustZone is sometimes used, but this is of course inconsistent between different vendors and versions.

So realistically, I don't think we can have any requirements for whether the crypto should be hardware-based or not. The big question is, do we require:

1. Use of the OS-provided keychain / keystore, with the advantage that security is enforced on by the OS, but the disadvantage that security depends on the OS configuration over which the app has no control?
2. Or, do we consider the default keychain to be insecure, and require apps from a certain level to add additional layers of encryption?

My feeling is that the OS Keychain(s) are the way to go for L1-L2 requirements, maybe with some additions on L2, such as reminding the user to set a strong system-wide passphrase (again we need to research the possibilities for an app to verify this). L3 and higher could require additional layers of encryption to to be added. We have to look at the details but this could be the basic outline.

What's also interesting is Apple's use of HSMs to secure Keychain items in the cloud. As far as I can see, the data is effectively non-retrievable even for Apple (assuming they don't lie about destroying the smart-cards used to access the HSMs). If this is true, why not allow sensitive data being synced to iCloud as long as it has the right protection class?

What do you guys think?

[commjoen]

A couple of remarks:

• having a hardware backed TEE is mandatory if you want to get Android 6 certified, which means that over time you will find more of these devices.
• In android an app can see which security patch level has been applied and whether the Keystore is backed by hardware starting from Android 6, which means that you can always fall back to DIY: e.g. use local storage with symmetric encryption of which the key resides at a server.
• iOS 9 defaults to a 6 digits pins and there is a better slowdown implemented by the OS.
• In android you can evaluate the strength of the password, but you have to be device administrator (using https://developer.android.com/reference/android/app/admin/DevicePolicyManager.html), which users might not like (e.g.: why is my bank a device administrator?). For iOS have have not found something similar yet.

Given all this, I would say that we cannot give an answer that is "clear and concise", without taking versions and operating systems into account (keystore updates in android, ios getting better security per version). Therefore I would recommend the same thing: OS provided security is enough for only for L1-L2 and always add something on top of it for higher level security. And we should really re-evaluate this guideline per year as the security controls on the OS are changing over time.

One last remark: I would not trust apple for it. I would apply the same "general" guideline for both android and ios: do not auto-backup sensitive data without the proper additional encryption being applied.

[muellerberndt]

Thanks @commjoen, great input.

So for iOS, can we make things simple by requiring an app (from L2 onwards) to support only iOS 9 or higher? I think this should be reasonable as new iOS versions are adopted very fast.

For Android, the situation is much more difficult. Do we need an either/or requirement? Something like: If Android version is 6+ and hardware-backed keystore is available, use that, if not use something else? What would be acceptable options? How about:

1. use local storage with symmetric encryption of which the key resides at a server or
2. use local storage with symmetric encryption where the key is derived from a passphrase chosen by the user

[muellerberndt]

I cleaned up the data storage requirements & clarified the role of hard-backed keystore as follows

for L1-2: "Verify that system credential storage facilities are used appropriately to store sensitive data, such as user credentials or cryptographic keys."

for L3-4: "Verify that the app only runs on operating system versions that offer a hardware-backed keystore, and that the device supports the hardware-backed keystore. Alternatively, verify that encryption has been implemented according to the controls in MASVS V3.