Our trust framework is based on a Public Key Infrastructure (PKI) using Certificate Authorities hosted internally (CAs). We will explain how we developed our PKI, how we use it internally, and how to use our open source software to run your own in this article.
Public Key Infrastructure is a collection of functions, policies, hardware, software and protocols necessary to develop, maintain, distribute and use digital certificates, store and revoke digital and to administer the encryption of public key systems. The goal of PKI is to ensure safe electronic information transmission for a range of network operations including e-commerce, internet banking and confidential email services. In activities where simple passwords are an insufficient form of authentication, more comprehensive evidence is important in order to confirm and verify the identity of the parties involved in a conversation.
Protection at the layer of application
Modern web services, most fairly complex, do not consist of one monolithic programme. An application is also divided into several “services” that handle various sections of business logic or data storage in order to handle complex operations. On different machines or even in different datacenters, each of these services can live.
Encrypting and authenticating data in transit is one technique to minimise the threats faced by attackers. Our policy is to require that an encrypted protocol, Transport Layer Security (TLS), be used by all new services to keep inter-service communication secure. It was a natural choice: in HTTPS, TLS is the “S” and is the base of the encrypted network. In addition, as the de-facto standard for application layer encryption, modern web servers and APIs have adopted TLS. All these things together protects customer data.
Be careful about your PKI
Digital certificates and public key cryptography are the instruments that allow this. A certificate enables the identity to be confirmed by a website or service. In practise, a certificate is a file containing the owner’s identification information, a public key and a signature from the certificate authority (CA). Each certificate also contains a public key. Each public key has an associated private key that is safely held under the control of the owner of the certificate. The personal key can be used to produce digital signatures that can be checked by the public key associated with it.
Constructing your own CA
The most difficult part of obtaining a website certificate is going through the process of securing it. We reduced this pain for websites by launching Universal SSL. The administration is the most difficult aspect of operating a CA. We tried to make both acquiring certificates and running the CA painless and even enjoyable when we decided to develop our internal CA.
Main security Key protection
You need a CA certificate and the corresponding private key to execute a CA. This private key is a highly sensitive one. Any individual who understands the importance of the key can act as the CA and issue certificates. Browser-trusted certificate authorities are expected to retain their private keys within specialized hardware known as Hardware Security Modules (HSMs). The criteria for corporate infrastructure protection of private keys are not generally as strict, so we have included many key protection mechanisms.
Trust in services
Internal services must have mutual trust. By checking the hostname signature and by checking the Subject Alternative Names (SANs) list of the certificate, browsers validate website certificates. This kind of clear control is helpful, but it does not work as planned. It does. The implicit testing based on service CAs is another way for services to trust one another.