EST: The Forgotten Standard January 24, 2019 Duncan Jones | Head of Research More About This Author > We have seen an explosion in certificate use in recent years. This is partly due to the trend towards miniaturization. The monolithic applications of old are now deployed as dozens of micro-services on platforms like Kubernetes. These applications scale up and down to meet demand, creating hundreds or thousands of instances at peak times. All these instances need to prove their identity to each other, as well as third parties. At the other end of the stack, we have countless devices coming to life every day. Less than a decade ago, our kitchens were full of appliances that merely produced coffee or kept food cold. Now they’re packed with Wi-Fi enabled minicomputers, regularly streaming data to cloud services and receiving over-the-air updates. New buildings are packed with gadgetry to control everything from security to mood lighting. You wouldn’t build a modern bridge without sensors to monitor load, vehicle throughput, sheer stress, and so on. A common requirement in all these settings is the provisioning of identity information after the device has been installed. Docker containers must first spring to life, before reaching out for identity certificates for their particular environment. Home devices need to be personalized to their owner and granted permission to act on their behalf. In the industrial setting, sensors or smart gateways will be delivered containing manufacturer keys and need to be “captured” when they are first turned on. When Thales began solving these problems a few years ago, we examined the available standards and settled on a very useful protocol for certificate distribution. In the years since, this protocol hasn’t received the acclaim it deserves. It’s simple and effective, with relatively little room for interpretation when implementing. It ought to be more popular than it is. Enter the hero of our piece: Enrollment over Secure Transport (EST). Enrollment over Secure Transport EST is a protocol for requesting X.509 certificates over HTTPS. The device requesting the certificate is known as the EST client. The client communicates with an EST server, which listens for requests on a predictable URL path. Clients just need to know the IP address of the server to get started. The EST server acts as a registration authority. Its job is to decide whether EST clients deserve the certificate they have requested. If so, it passes the request to the certificate authority (CA) and returns the resulting certificate to the client. The communication between the EST server and the CA is not covered by the protocol and would differ based on the CA being used. Bootstrapping The EST client needs initial credentials to get started. This can take the form of a shared secret or an existing private key and certificate. At first glance, this can be confusing. If you need to provision identity before you run an identity protocol, what’s the point? The answer is that in most cases, we are talking about personalization of a device from its factory state. We don’t want to issue certificates to every Tom, Dick and Harry, just because they can hit the EST server endpoint. In the case of physical products, the manufacturer typically injects default keys or secrets and shares this information with their customer. For containers, the platform they run on (such as Kubernetes) can usually install some basic credentials that allows the container to prove it’s running in a given cluster. The client also needs to authenticate and authorize the EST server. If the EST server’s certificate is issued from a well-known (or otherwise trusted) root CA, the client should be able to authenticate without further intervention. Otherwise, two options are available: a certificate-less protocol can be used, based on shared secrets, such as those provided in TLS-SRP. Alternatively, a human being can be involved to validate the fingerprint of the EST server certificate. Clearly the latter option is only feasible in certain circumstances. The forgotten standard So, why has EST been overlooked for so long? One reason is its simplicity. It’s tempting and easy to invent similar protocols without considering whether standards already exist. Yet, standards allow us to build solutions faster and in a more interoperable fashion. They also reduce the likelihood of design errors, which are so prevalent in home-grown crypto protocols. Another reason is timeliness – we are just entering an age of certificate flux and it takes time for the industry to realise new approaches are needed. When EST was first proposed in 2012, the world looked very different. As we embrace this new age of IoT and cloud computing, the industry should seriously consider adopting existing standards for secure certificate issuance. EST is not the only option (perhaps a topic for a future blog), but it’s a strong candidate and one that we’ve used extensively at Thales eSecurity. To learn more, visit our Horizons research portal and follow Thales eSecurity on Twitter, LinkedIn and Facebook.