About Trust Stores Extending Trust
Whenever the app connects to a server whose certificate is self-signed or unknown to the system, the secure connection will fail. This is typically the case for any non public CAs, for instance those issued by an organization such as a government, corporation, or education institution for their own use.
Both Android and iOS offer means to extend trust, i.e. include additional CAs so that the app trusts the system’s built-in ones plus the custom ones.
However, remember that the device users are always able to include additional CAs. Therefore, depending on the threat model of the app it might be necessary to avoid trusting any certificates added to the user trust store or even go further and only trust a pre-defined specific certificate or set of certificates.
For many apps, the “default behavior” provided by the mobile platform will be secure enough for their use case (in the rare case that a system-trusted CA is compromised the data handled by the app is not considered sensitive or other security measures are taken which are resilient even to such a CA breach). However, for other apps such as financial or health apps, the risk of a CA breach, even if rare, must be considered.
Restricting Trust: Identity Pinning
Some apps might need to further increase their security by restricting the number of CAs that they trust. Typically only the CAs which are used by the developer are explicitly trusted, while disregarding all others. This trust restriction is known asIdentity Pinningusually implemented as Certificate PinningorPublic Key Pinning.
In the OWASP MASTG we will be referring to this term as “Identity Pinning”, “Certificate Pin- ning”, “Public Key Pinning” or simply “Pinning”.
Pinning is the process of associating a remote endpoint with a particular identity, such as a X.509 certificate or public key, instead of accepting any certificate signed by a trusted CA. After pinning the server identity (or a certain set, aka. pinset), the mobile app will subsequently connect to those remote endpoints only if the identity matches. Withdrawing trust from unnecessary CAs reduces the app’s attack surface.
General Guidelines
TheOWASP Certificate Pinning Cheat Sheetgives essential guidance on:
• when pinning is recommended and which exceptions might apply.
• when to pin: development time (preloading) or upon first encountering (trust on first use).
• what to pin: certificate, public key or hash.
Both Android and iOS recommendations match the “best case” which is:
• Pin only to remote endpoints where the developer has control.
• at development time via (NSC/ATS)
• pin a hash of the SPKIsubjectPublicKeyInfo.
Pinning has gained a bad reputation since its introduction several years ago. We’d like to clarify a couple of points that are valid at least for mobile application security:
• The bad reputation is due to operational reasons (e.g. implementation/pin management com- plexity) not lack of security.
• If an app does not implement pinning, this shouldn’t be reported as a vulnerability. However, if the app must verify against MASVS-L2 it must be implemented.
• Both Android and iOS make implementing pinning very easy and follow the best practices.
• Pinning protects against a compromised CA or a malicious CA that is installed on the device.
In those cases, pinning will prevent the OS from establishing a secure connection from being established with a malicious server. However, if an attacker is in control of the device, they can easily disable any pinning logic and thus still allow the connection to happen. As a result, this will not prevent an attacker from accessing your backend and abusing server- side vulnerabilities.
• Pinning in mobile apps is not the same as HTTP Public Key Pinning (HPKP). The HPKP header is no longer recommended on websites as it can lead to users being locked out of the website without any way to revert the lockout. For mobile apps, this is not an issue, as the app can always be updated via an out-of-band channel (i.e. the app store) in case there are any issues.
About Pinning Recommendations in Android Developers TheAndroid Developerssite includes the following warning:
Caution: Certificate Pinning is not recommended for Android applications due to the high risk of future server configuration changes, such as changing to another Certificate Authority, rendering the application unable to connect to the server without receiving a client software update.
They also include thisnote:
Note that, when using certificate pinning, you should always include a backup key so that if you are forced to switch to new keys or change CAs (when pinning to a CA certificate or an intermediate of that CA), your app’s connectivity is unaffected. Otherwise, you must push out an update to the app to restore connectivity.
The first statement can be mistakenly interpreted as saying that they “do not recommend certifi- cate pinning”. The second statement clarifies this: the actual recommendation is that if develop- ers want to implement pinning they have to take the necessary precautions.
About Pinning Recommendations in Apple Developers
Apple recommendsthinking long-termandcreating a proper server authentication strategy.
OWASP MASTG Recommendation
Pinning is a recommended practice, especially for MASVS-L2 apps. However, developers must implement it exclusively for the endpoints under their control and be sure to include backup keys (aka. backup pins) and have a proper app update strategy.
Learn more
• “Android Security: SSL Pinning”
• OWASP Certificate Pinning Cheat Sheet