# 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.

<figure><img src="https://1103423335-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FvyEajzuIz0PAtDiV6JcU%2Fuploads%2FRm2pKDDbzsXLHmnF1Obs%2Fa.png?alt=media&#x26;token=e8a3c5af-84b7-487e-947e-74f052a052fe" alt=""><figcaption><p>Applications using Pinning will not communicate through a proxy</p></figcaption></figure>

## 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.
