With smartphones, tablets, and other mobile devices being used on a daily basis as viable ways of gaining access to corporate networks, security professionals devote additional attention to keeping these portable “endpoints” safe—just like any other network resource.
Secure channels are a cornerstone to users and employees working remotely and on the go as they expect end-to-end security when sending and receiving data, especially sensitive data such as banking transactions, on channels protected by VPN, SSL, or TLS. History has shown that these protocols are not invulnerable and users have suffered chronic breaches. One of the first things an attacker will do when reverse engineering a mobile application is to bypass the SSL/TLS protection to gain a better insight in the application’s functioning.
When an SSL/TLS connection is made, a client (such as a web browser or mobile app) establishes a link to a server, which responds with its digital SSL certificate. The public encryption key in the web server’s certificate is used to encrypt traffic to the web site, while the certificate identifies who owns the site. As an assurance that a certificate is authentic and valid, it’s digitally signed by a root certificate which belongs to a trusted Certificate Authority, or CA.
Operating systems, web browsers, and certain online applications maintain lists of trusted CA root certificates, so that they can easily verify certificates that CAs have issued and signed. For each client – server link, a connection is only allowed if the certificate being used for authentication and encryption was issued by a Certificate Authority that’s trusted by the operating system, browser, or app. Once the verification is made, all data passing between endpoint and server is encrypted using the server’s public key. Such a connection is considered to be secure. At least, in theory.
What is the problem?
The Key Distribution Problem was the first incident of insecure communications because of lack of authentication and verification. Verification of digital certificates depends on a hierarchy or “chain of trust” involving several parties: the user or endpoint client, the server, its trusted list of Certificate Authorities, and the CAs themselves. The problem is that the Certificate Authorities aren’t invulnerable to attack. In the recent past, hackers have broken into a number of CA networks (including DigiNotar and Comodo), and signed faked digital certificates in the names of organizations such as Microsoft, Mozilla, Yahoo, Google, Facebook, and Twitter. “Chain of trust” could solve the problem but only in a sterile environment, because, in practice, trusting seems quite problematic.
Once breaches like this are discovered, a crisis of confidence occurs, and establishing trust in a Certificate Authority which has had one or more of its certificates compromised becomes difficult, to say the least.
What is certificate pinning?
Certificate pinning (also referred to as public key pinning) provides a framework for reducing the tendency to rely on trusting third parties when making security decisions concerning identity. Pinning is the process of associating a host with their expected X.509 certificate or public key. Once a certificate or public key is known or seen for a host, the certificate or public key is associated or 'pinned' to the host. If more than one certificate or public key is acceptable, then the program holds a pinset. In this case, the advertised identity must match one of the elements in the pinset.
A host or service's certificate or public key can be added to an application at development time, or it can be added upon first encountering the certificate or public key. Adding the certificate or public key at development time is preferred since preloading “offline” usually means the attacker cannot taint the pin. If the certificate or public key is added upon first encounter, you will be using key continuity. Key continuity can fail if the attacker has a privileged position during the first encounter.
Although pinning can result in less flexibility, it leverages knowledge of the pre-existing relationship between the user and an organization or service to help make better security related decisions. Because you already have information on the server or service, you don't need to rely on generalized mechanisms meant to solve the key distribution problem. That is, you don't need to turn to DNS for name/address mappings or CAs for bindings and status.
The framework provides a layer of defense against MitM attacks that use forged certificates, and certificate pinning is deployed by several of the major IT players. For example, Google’s Chrome browser pins the certificates for Google sites, with only specific certificates signed by the Google Internet Authority regarded as trustworthy.
What should you pin?
There are two options, you either pin the certificate or you pin the public key. There are pros and cons to both of the options, but the recommended one is pinning the public key. Pinning the certificate seems like the easy solution, but actually pinning the public key (specifically the SubjectPublicKeyInfo (SPKI)) gives you more flexibility. Typically certificates are valid for one or two years, so when pinning the certificate the application won’t be able to operate once the certificate expires. When pinning your public key, or the public key of the CA, you can easily issue new certificate and revoke an existing certificate without breaking your existing application.
Pinning considerations and final thoughts
The main problem with pinning is that it can brick web sites. The culprit is the memory effect: pins, once set, remain valid for a period of time. Each pin is associated with a unique cryptographic identity that the web site must possess to continue operation. If you lose control of these identities, you effectively also lose your web site. Clearly, pinning introduces a paradigm shift. Without it, TLS is quite forgiving—if you lose your keys you can always create a new set and get a fresh certificate for them. With pinning, your keys become precious.
Thus there is a need for a pinning strategy. A successful certificate pinning strategy must begin with a threat assessment, to determine whether pinning is the ideal solution to address the real threats that a web site may be facing. Having put a framework in place, it then becomes a priority for certificate pinning keys to be safely stored and guarded, with backup keys held in a separate storage location, in case the primary server goes down. If pinning keys are to be changed periodically, there’s also the need for a carefully planned and executed key rotation schedule which allows users who have had access only to older key sets, or those who are using legacy software and devices, to continue to have access to the web site throughout.
In order to implement effectively the above pinning strategy, the need arises for automatic the processes. This can be achieved by employing solutions such as the Venafi Trust Protection Platform, which generates the machine identity intelligence necessary to automatically safeguard the flow of information to trusted machines and prevent communication with untrusted ones.