Written by Deepak Choudhary
There are always risks involved when relying on a third party to send and receive sensitive data over secure network channels. While we recognize the roles of the Public Key Infrastructure (PKI) and third party certificate authority (CA), we also believe that Certificate SSL Pinning can play a key role in bolstering security.
Current CA Role
CA plays a very critical role in secure communications over the Internet. They are the only entity trusted by both the end users (certificate owners and frontend parties) to authenticate the encryption process. If a trusted authority like CA confirms that the communication is authorized, we usually feel confident that there is a secure connection between the client and the server. The downside is, in this process user doesn’t verify that it’s the same certificate, which is uploaded to the server. The user just blindly believes the CA for all legitimacy, since it is a trusted entity, but some recent issues around this process have begun to dilute this trust. It only takes one certificate comprise to undermine a client’s trust in security provider group (CA). That means if hacker get the private key of any CA, they can generate the certificate for any website. Obviously the CA is placed in browser trusted zone; it will show valid flag to compromised certificate.
Some recent examples of CA compromises:
Role of Keystore and KeyChain in Mobile Application
Keystone and KeyChain are basically repositories for all root certificates within the mobile operating systems – similar to a trusted zone implemented in the web browser. These certificates are used in the authenticity of the application file (like APK) and to ensure secure data transmission. In this case, CA plays a role to authenticate the certificate and allow transmission only upon when it’s accurate.
Again, because of recent CA concessions, application developers were in need of another layer of protection within the structure of mobile application data transmissions. That’s were SSL pinning plays a pivot role.
In mobile application also the same default SSL handshake process is followed. For doing MITM, device has to trust the bad certificate which is highly improbable. But again CA issues are not allowing trusting on this default process. Mobile application developers have found a way around this problem in order to mitigate some of the risks associated with the default SSL handshake process by implementing Certificate pinning.
Pinning is the process where the current authentication process and the risks associated with it could be completely bypassed. It is an enhanced certificate security mechanism implemented where authentication happens by comparing value (in this case certificate) at both the ends.
In Pinning, root server certificate itself (own keystore) is inserted in the executable file. When SSL communication starts, this make sure that first SSL request from the client validates that server certificate exactly matches the certificate present in the application bundle. Mobile application files have embedded code to verify the certificate sent by the server and known certificate in the application bundle match. Certificate used in this process could be self-signing (mostly used) or signed by a legitimate CA group.
Pinning can be done in two ways:
Let’s have a detailed flow showing how Pinning happens in Android (APK):
Figure 2: The above figure shows a sample blow on how Android uses pinning to avoid CA related flaws
What is needed from the provider?
Vendor needs to update his application bundle from time-to-time to keep a valid certificate in the files.
What is the Risk?
Certificate pinning process mitigates all possibility of certificate compromises, which leads to MITM. The only way is when bad hands capture your private key. That is very dubious.