Certificate Pinning

Applications put constraints on the certificates used for verification (Trusted Roots).

• They fix (Pin) a certificate/ pub key/ hash to a hostname.

• Validation of the host authenticity (in TLS) will also include this additional constraint.

Impact

A Trusted Root can be injected but it will be ignored.

• The application will simply not use it, or the application will have additional checks to detect the injection.

Approaches

Applications extend the X509TrustManager, overriding the checkServerTrusted method, with custom checks.

• E.g the Certificate/ Public Key/ hash is hard coded, and this value is used to validate the certificate.

Using a KeyStore with a predefined list of certificates, ignoring other sources.

• Pins the host certificate.

• Pins an intermediate Certification Authority.

• Pins a Root Certification Authority.

Pinning may create issues for developers as changes to certificates or PKI must be reflected in the applications.

• Soft Fail: just let the application work, even if with limited functionality.

• Hard Fail: an update is forced for the application to work.

Applications using Pinning will not communicate through a proxy

Circumvention

If restricted KeyStores are used, use an emulator or rooted device.

• Enables free manipulation of the keystores, injecting custom certificates.

• Inject certificates into the system keystores.

If Pinned with hard-coded information, modify the application.

• Unpack the application.

• Edit the code, change the Pin or remove it.

  • smali maybe enough and full decompilation to Java is not required.

• Repack and install the application.