To set up a secure connection between two users, they have to exchange keys. In total, there are just three safe ways of exchanging public keys, which are as follows:
- In a personal meeting – the direct transfer of an public key from one user to another, without the use of any public networks of data transfering (such as the internet).
- A key, which has been used before – across a non-secure network, but with the protection of a previously used key.
- Through a trusted third party – obtaining the public key from a user through a trusted third party, through whom a secure line of communication has already been established.
This listing demonstrates that the second and third options are simply versions of the first one. That means that to start work in an information system with public keys, securely, it’s necessary to hold at least one personal meeting to which users has to travel, and exchange their key in person. One of the most crucial roles in the functioning of the entire Internet is played by PKI – public key infrastructure. It has been especially set up to resolve issues of exchanging user’s public keys, by the use of trust third parties (the third of the options cited above).
The problem, which PKI sets out to resolve, is that of securing compliance between an entity’s identifier and its public key. Checking such compliance is essential when ensuring the authenticity of the entity with whom secure connection must be established. The most vital issue is establishing conformity between the identity (i.e. the identification data) and the user’s public key. It’s a challenge, which is resolved using a Public Key Certificate – an electronic document that establishes proof of ownership of the key. The Certificate contains the public key along with the user identification information, in addition to an electronic signature of the trusted party who has physically verified the user. In other words, in order to vouch for the integrity and authenticity of the Certificate, it is signed by a trusted entity – the Certificate Authority.
The Certificate Authority (CA) is an organization, which checks the authenticity of the identification information, and generates digital certificates to the next hierarchical level of Certification Authorities and to end-users. The Certificate Authority is a trusted third party in communications between users. The Certificate Authority holds its own certificate – and uses its key to sign all certificates issued to it.
The Root Certificate Authority (Root CA) is the Certificate Authority, which is not subordinate to any other center, and is therefore the highest in the hierarchy. A certificate from this center is signed with its own key, and is known as a self-signed certificate.
For any certificate issued to a user, it is possible to construct what is known as a certificate chain. The user’s certificate refers to the certificate of the center, which issued it – and this, in turn, refers to the certificate of the center which is above it in the hierarchy. This means it is possible to construct a certificate chain that leads back to the certificate of the Root CA, and therefore to verify all the electronic signatures which are used in the chain. This is a mandatory procedure when verifying a certificate prior to use.
A certificate’s life-cycle consists of the following stages:
- A request is sent to the Certificate Authority to issue a public key certificate and verify the user’s identity.
- A certificate is issued in accordance with the data detailed in the request, and the prevailing certification policy.
- The certificate is distributed among the members of the information system.
- Storage and issue of the certificate takes place at the request of users and certificate owners.
- The certificate may be suspended or renewed.
- Information in the certificate may be updated, and its key pair.
- The certificate may be revoked at the request of its owner, or the regulatory body.
- A certificate may expire, or be reissued as appropriate.
PKI currently operates only on the condition that user browsers correctly verify the chain of certificates; their status; that cryptographic computations have been properly implemented and operate correctly; that confidential key data is not compromised; and that there is the correct set of root certificates on the client side.
Centralized PKI for mass use, particularly when deployed for web resources, is subject to a whole raft of complexities and issues, including:
- The problem of rapid notification of compromized keys – since setting-up and distribution of a list of revoked certificates can take from between several minutes to over an hour. As a result, there can be no 100% guaranteed that a particular key belongs to an identified user at a particular moment in time.
- If certificate checking is carried out online, (by requests to the Certificate Authority), the user’s privacy is violated – since the Certificate Authority will discover the entire history of user interactions.
- Difficulties in unveiling the presence of certificates from undesirable Root Certificate Authorities. In such cases, special equipment can be installed at some point of digital traffic route between the client and the server, which is capable of decrypting all data, whilst going unseen for the client and the server.
- A number of certificates could be issued in an identical name – in other words, the same identifier could be certified at different Root CAs.
- The process of updating certificates is complex, since this requires repeated access to the registration center, changing the data, reissuing the certificate, and then verifying it once again with the Certificate Authority.
- There is an issue with parallel existence of differing standards for electronic signatures, as a result of the need to select algorithms, and user compatibility difficulties for possible interaction.
- System centers are permanently subject to possible attacks, which can compromise Root Certificates and thus expose the entire system to a large number of threats.
- When PKI is centralized, the identifiers are in the hands of a centralized organization, rather than belonging to the actual owners of the identifiers themselves.
In our next article, we shall be looking at possible ways some of the above-mentioned difficulties might be resolved by adopting a decentralized approach.