Why You Should Be Using Certificate Pinning In Apps

Safety for users and platforms tops the charts in terms of the most important elements to a software’s architecture – here, certificate pinning (occasionally called identity pinning) is crucial to protecting data in transit between the app and its server. This enables data to be encrypted, meaning anyone who intercepts data packets exchanged between an app and its server would obtain useless data.

Of the many security mechanisms in use today, encryption plays a major role in preventing usable data from falling on prying eyes. Throughout the following, we’re going to explain what certificate pinning is, why it’s important, and what happens if you fail to properly implement this system for your app.

What is certificate pinning?

Of the many flavors of certificates you can find, the principle is generally the same. A certificate issued by a certificate authority (CA) behaves as an official identifier for a server. It acts as a kind of passport that verifies its identity to other machines that connect. It’s the foundation for establishing trust that is used by systems to create secure connections. Whenever you see the little lock icon in the address bar of your web browser, this means one is use.

For example, when you use the Twitter app, it communicates with the server using a formal process to establish a secure, encrypted connection between the two endpoints. The certificate comes into play when the app and server first connect. The certificate of the server exposes a public key that any app or front-end client can use to encrypt traffic sent back and forth between the server. The server retains the private key for that certificate which is the secret code that allows only that server to decrypt traffic sent to it using the private key. Once the app verifies the identity of the server using the certificate they generate a master key together and agree to the terms that all future communications will be encrypted using the same cryptographic protocol, most commonly TLS (Transport Layer Security) or SSL (Secure Sockets Layer) for apps.

Encryption works by scrambling the data in an incredibly complex manner. It pulls apart, alters, and skews every bit of data such that only the unique key shared between the two endpoints can make sense of the information. While it’s not perfect, consider that there are about 1.1 x 1077 combinations for the 256-bit AES key which means that it’s virtually impossible to crack without compromising the server or user device.

The concept of certificate pinning is to add an additional layer of trust atop the process explained above. Certificate pinning is the process by which a client knows the identifier of the certificate or certificate authority that it is expecting when connecting to the site and rejects any attempt to present a different or intermediate certificate.  Without certificate pinning, an app visiting a HTTPS URL will use whatever certificate the server returns to it to begin the handshake process as long as the certificate is cryptographically valid. With certificate pinning, an app visiting an HTTPS URL will only use the certificate returned to it by the server if it matches the identifier or hash of the certificate the app was programmed to be expecting. 

Why is certificate pinning important?

Just about every app you can think of will need to use certificates to allow them to securely communicate with backend servers. It’s a good rule of thumb to assume that every bit of data your system will exchange is private, meaning you need to “bubble wrap” your data wherever possible. As such, everything in transit should be protected by encryption.

The reason the pinning portion of the process is important is that there are many times that it’s necessary to limit the number of certificate authorities that can be trusted. This is usually required in instances where an app is subject to regulatory requirements that mandate systems only connect to authorized systems. For example, in healthcare app development, it would be unwise to leave any potential openings on your system that wouldn’t comply with HIPAA – just because a server possesses a certificate and can be trusted only means that it’s a verifiable entity and capable of encrypting any information exchanged. 

Without certificate pinning, it is possible for malicious actors to insert themselves in between your device and the server, called a man-in-the-middle attack (MITM). In a MITM, a malicious actor intercepts traffic being sent to a remote URL and instead of the app receiving the correct certificate for that URL, the malicious actor returns a technically correct certificate, but not the one that belongs to the site. Instead, a certificate they created is used, meaning they know the private key. The end result is that the malicious actor is then able to eavesdrop and decrypt all communication between the app and the remote site. These types of attacks are likely to occur by connecting to an unknown WiFi network or access point. 

Many times, apps subject to these conditions will still have a dynamic range of systems to which they can connect. Organizations will (or should) apply a systemic method of applying certificates from the same CA to their systems that in turn enables apps to reference their public keys through pinning to establish trust. Doing so prevents the need to constantly update configuration in the app when systems from the same organization using the same CA are either added or removed.

There is one small catch. Should the certs used by the server for TLS or SSL (even if it’s only being used for management purposes) ever change, this means that the app will likely need to be reshipped to the app stores or through whatever distribution means is in effect.

Consequences of failing to employ best practices

We already covered why this is important, so it should be easy to assume what can happen when certificates aren’t used properly.

Any time new resources linked to a pinned public key are added to a domain or network, they automatically become available to the app. If you’re using a more manual system of adding authorized systems through either a real or conceptual whitelist, your taking extra time to update the binary and leaving room for human error. 

Each certificate will produce a unique private key for every exchange which effectively prevents man-in-the-middle (MITM) attacks, whether or not you’re pinning public CA keys. So long as an encrypted connection is in place, there’s essentially no chance that intercepted data could ever be reconstructed. With that said, further protecting information once it arrives relies on following security best practices like using modern authentication methods such as Sign in with Apple for both outside and internal users. 

Keeping malicious users from accessing your system keeps the data it stores safe and the certificate from being compromised. Should someone ever breach your system, simply locking them out again may not be enough. By setting up a proxy or by spoofing information cert information, a MITM attacker could either use the certificate information to break the cipher while the information is in transit or create a false system using the certificate information.

In short, using encryption keeps your user’s information safe while in transit as well as protects admin and developer credentials from being intercepted during transit. Of course, it doesn’t protect against users recycling simple passwords or phishing attempts. Developers need to cover all angles and regularly audit systems to make sure the bad guys stay out.

Blue Label Labs designs secure solutions for any industry

Our focus is aligning everything from usability through safety to ensure that our apps offer a great UX and optimal security. For most endeavors, getting and applying certificates is just a very small portion of the overall development process but in other cases, it’s quite important. In these scenarios, we want our customers to understand how we are helping meet data compliance regulations for their project. If you’re in the market for a secure app, please get in touch to learn more.