Ubiquitous Public Key Certificates
1. Why Do We Need Public-Key Certificates?
In the previous article, we discussed digital signatures. Digital signatures can detect tampering or whether the sender’s identity has been spoofed; in other words, they verify message integrity, authenticate messages, and prevent repudiation. Everything seems perfect, but their weakness lies in their strength: digital signatures require a public key to verify the sender’s identity.
We need to obtain an untampered public key from a sender whose identity has not been spoofed. To verify whether the public key we obtained is legitimate, we must use a public-key certificate. A certificate treats the public key as a message and has a trusted third party sign it.
2. What Is a Public-Key Certificate?
A public-key certificate (PKC) records personal information (such as name, organization, email address, and other personal information) and the person’s public key, and it is digitally signed by a certification authority (Certification Authority, Certifying Authority, CA). A public-key certificate is also referred to simply as a certificate.
3. Public-Key Certificate Standards
The most widely used specification today is X.509 (RFC3280), developed by the ITU (International Telecommunication Union) and ISO (International Organization for Standardization). Most programs basically follow this standard specification for certificate generation and exchange.
4. Application Scenarios for Public-Key Certificates
Let’s use an example to illustrate how certificates are applied. The figure below shows Alice sending ciphertext to Bob. The public key of Bob used to generate the ciphertext is obtained through a certification authority.
Steps 1–7 in the figure above are labeled in order. Here are some additional notes for specific steps:
- In step 1, Bob’s key may be generated by Bob himself, or it may be generated on his behalf by the certification authority.
- In step 3, after obtaining Bob’s public key, the certification authority begins verifying whether the public key really belongs to Bob. There are three verification levels: Class 1 confirms the person’s identity via email; Class 2 confirms the person’s identity through a third-party database; Class 3 confirms the person’s identity through in-person verification and identity checks. The higher the level, the stricter the identity verification.
- In step 5, Alice uses the public key of the certification authority Trent to verify the digital signature in the certificate. If verification succeeds, it confirms that the public key contained in the certificate belongs to Bob.
- In step 6, although the figure labels this as “public-key encryption,” in practice this step can also use hybrid encryption.
Steps 1, 2, 3, and 4 in the figure above do not need to be performed every time. Steps 1, 2, and 3 are only required when registering a new public key. Step 4 is only needed the first time public-key cryptography is used; after the public key is saved on the computer, it does not need to be requested every time.
5. What Is Public-Key Infrastructure (PKI)?
Public-Key Infrastructure is the general term for a series of norms and specifications designed to make more effective use of public keys. Its English abbreviation is PKI.
PKI is a general term; it does not refer to any single individual norm or specification. The PKCS (Public-Key Cryptography Standards) series developed by RSA is one type of PKI; the Internet specifications known as RFCs (Request for Comments) are also a type of PKI; X.509 is also a type of PKI. APIs (Application Programming Interfaces) and specification design documents written by individual companies can also be considered PKI-related specifications.
Public-Key Infrastructure (PKI) should not be misunderstood as meaning “there is only one public-facing authoritative certification authority” or “all public keys in the world are certified by a single root CA.” These are incorrect interpretations. A certification authority only needs to digitally sign a public key, so anyone can become a certification authority.
1. Components of PKI
- User — a person who uses PKI
- Certification authority — a party that issues certificates
- Repository — a database that stores certificates
Both users and certification authorities can be people or computers; collectively, they are called entities. An entity is the actor that performs certificate- and key-related processing.
There are two types of users: one type wants to use PKI, and the other wants to use a registered public key.
Users like Bob, who register public keys:
- Generate a key pair (either by themselves or through a certification authority)
- Register a public key with a certification authority
- Apply to the certification authority for a certificate
- Request revocation of a registered certificate
- Decrypt received ciphertext
- Digitally sign messages
Users like Alice, who use public keys:
- Encrypt a message and send it to the recipient
- Verify digital signatures
2. Certification Authority (CA)
A Certification Authority (CA) is the party that manages certificates. It is mainly responsible for the following operations:
- Generate key pairs (these may also be generated by users)
- Authenticate the identity of the person registering the public key
- Generate and issue certificates
- Revoke certificates
A certification authority may also include a separate Registration Authority (RA). The registration authority handles registration-related operations, while the certification authority focuses on issuing and revoking certificates.
3. Repository
A repository is a database that stores certificates. A repository is also called a certificate directory. Revoked certificates also require a Certificate Revocation List (CRL).
4. Certificate Chain
Certificates can also have a hierarchical structure. For example, a certificate issued by a top-level root CA can issue a certificate to a lower-level CA, forming a hierarchy level by level.
6. Attacks Against Public-Key Certificates
Because certificates are in fact based on digital signature technology, all attack methods against digital signatures are also effective against certificates.
1. Attacking Before Public-Key Registration
A man in the middle can replace the user’s public key with the attacker’s own public key when the user submits the public key to the certification authority for certification. There are two ways to prevent this man-in-the-middle attack:
- When the user sends the public key to the CA, encrypt it using the public key of the certification authority CA.
- After the certification authority has verified the user’s identity, send the public-key fingerprint back to the user as a receipt for confirmation.
There is an organization called a PKG (Private Key Generator). This organization has a status parallel to that of a certification authority CA. It uses publicly available information—email address, mailing address, name, and other ID-based cryptographic data—to generate private keys. It relies on trust in the ID. The private key generator is responsible for generating a private key based on the ID and securely sending the private key to the legitimate recipient. Since the private key generator has the ability to decrypt all ciphertext, its own security requires even greater attention.
Compared with PKI, the advantage of PKG is that the sender does not need to obtain the recipient’s public key before encryption, and the recipient does not need to manage their own private key before actually performing decryption.
2. Attacking by Registering a Similar Name
Register a similar name to trick the other party into trusting it.
3. Attacking by Stealing the Certification Authority’s Private Key
This approach attacks the CA itself. If the CA discovers that its private key has indeed been stolen, it must promptly notify all users, revoke the relevant certificates in time, and update the CRL.
4. An Attacker Impersonates a Certification Authority
Certification authorities do not need to register; anyone can act as a certification authority. The only question is whether other CAs recognize it. An attacker can pretend to be a CA and issue certificates to users, in which case certificate verification will certainly pass. However, the contents of the communication will no longer be secret. For example, an attacker could perform DNS poisoning in an area or attack a Wi-Fi signal, causing users in that area to mistakenly believe the attacker is a trusted CA; the attacker can then carry out attacks.
If a certification authority is not trustworthy, then even if a certificate is legitimate, the corresponding public key must not be used.
5. The “Vulnerability” in CRLs
An attacker can exploit the time gap in CRL publication to launch an attack. A sends B an email saying that A wants 1,000,000. After B transfers 1,000,000 to A, A repudiates it and says he never sent that email. The signature was not made by A, because the certificate had already been revoked. B did not update the CRL in time, which allowed the other party to repudiate the message.
Countermeasures against this attack:
- Notify the certification authority as soon as the public key becomes invalid (user A)
- Publish the CRL as soon as possible (CA)
- Update the CRL promptly (user B)
7. Problems Public-Key Certificates Cannot Solve
At this point, the introduction to public-key certificates is complete. Currently, public-key certificates also have no unsolvable problems. They can detect tampering or whether the sender’s identity has been spoofed; in other words, they verify message integrity, authenticate messages, and prevent repudiation.
The difference between public-key certificates and digital signatures lies in the certification authority. Some readers may wonder why a certification authority is necessary.
- If you can obtain a trusted public key, you do not need a certification authority. This situation is only possible face to face with the person; otherwise, it is not trustworthy.
- If you possess the public key of a trusted certification authority and trust the identity verification performed by that certification authority, then you can trust the certificates issued by that certification authority and the public keys obtained through that path.
- A certification authority creates a trust relationship in a completely untrusted state.
Reference:
Cryptography in Pictures
GitHub Repo: Halfrost-Field
Follow: halfrost · GitHub
