Public Key Infrastructures & SSL/TLS

An attacker can try to manipulate the public key distribution process. In particular nothing prevents an attacker from inserting attacker’s public key pk* into the public database but claiming other’s name in order to overwrite the original public key pk.

Moreover, the attacker may prevent or block the communication from any party from reaching the database, potentially inject its own public key pk* again onto the channel. The result will be disaster. The way to fix the problem is to use signature for secure key distribution.

---

---

Public Key Infrastructures

The idea behind public key infrastructures is to use signatures themselves for secured distribution of public keys. Assume a trusted party called CA (certificate authority) with a public key pkCA known to everyone.

Now one can ask CA to sign the binding of user’s identity, say name, and a public key, i.e. (identity, pk). That is CA should sign some message indicating that one’s public key is pk. We can call that the signature on the binding between the public key and the identity, a certificate.

certCA→Identity = Signsk_CA(Identity, pk) 

CA must verify the identity out of band. CA can be a business, a reputable company, and can take the time to develop the resources to be able to verify people’s identity before certifying their public keys.

Once a certificate is issued, if someone else can obtain a copy of that certificate, along with the identity and the public key itself, then that person can verify the signature to check that everything is OK.

Vrfypk_CA( (Identity, pk), certCA→Identity ) = 1 ?

This will prevent an attacker from fooling the person into accepting an incorrect key, say pk*, unless the attacker is somehow able to fool the authority as well. CA’s private key should never be compromised.

Roots of Trust

But how does one person get the public key of the CA in the first place? There are several possibilities here. The most natural possibility is to imagine there are one or a few central trusted CAs that we can call Roots of Trust.

One only need to securely obtain a small number of CA’s public keys. In practice, they are usually distributed as part of an operating system, or web browser.

Web of Trust

This is a model that originated with the popular PGP email encryption software. You will obtain public keys from your friends in-person, so the public key distribution problem is “solved”. People can also have “key signing parties”, where a bunch of people who are all using the PGP software will get together, and exchange public keys in person. After that you can additionally obtain certificates on your public key from your friends.

If A knows public key of B (A and B are friends), and B issued a certificate for C (B and C are friends), then A can learn about C’s public key, by having C send its public key along with the certificate to A. A can verity the certificate because it knows B’s public key, assuming A finds B trustworthy, then A has some confidence that public key claimed by C is really C’s public key.

Public Key Repository

Rather than only storing a public key in a repository, we can store the public key along with any certificates for that public key. One well known example is MIT PGP key server.

PKI in Practice

PKI does not work quite as well as in theory, because of several reasons lies in the realm of network security than cryptography per se:

1. Proliferation of root CAs.
2. Revocation.
3. Other issues.

---

---

SSL/TLS Protocol

This is a protocol that you use every day, and by millions of people around the world. SSL stands for Secure Socket Layer (developed by Netscape, in the mid 1990s), TLS stands for Transport Layer Security (an attempt to standardize SSL). This protocol is used by every web browser for https connections.

TLS protocol operates in two phases:

1. Handshake protocol
   • Establish a shared key between two entities.
2. Record-layer protocol
   • Use the shared key for secure communication.

Handshake Protocol

The core idea of how handshake protocol works between a client and a bank is as follow:

1. Client browser sends https request, along with a random number called nonce NC.
2. Bank responds with a copy of their public key pk, certificate cert, and another random value nonce NB.
3. Client verifies the public key pk from the bank is correct, using the public key from CA pkCA.
4. If the verification succeeds, client generates a random value called premaster key pmk, and encrypts pmk using the public key pk of the bank to get the cipher text c:
   c = Encpk(pmk). Ideally we would like this public key encryption scheme to be CCA secure. However in fact, the TLS protocol does not quite use CCA encryption.
5. Client uses a key derivation function KDF, to derive a master key mk = KDF(pmk, NC, NB), then apply a pseudorandom generator G to the master key to derive 4 different keys: kC, k'C, kS, k'S = G(mk).
6. Bank, after receiving the cipher text c, can decrypts and recover pmk = Decsk(c), and then apply the same procedure as client did: mk = KDF(pmk, NC, NB), then kC, k'C, kS, k'S = G(mk).
7. Client computes a message authentication code, using mk, over the entire transcript of the communication thus far, i.e. Macmk(transcript), and send it to the bank.
8. Bank verify the message authentication code tag is correct on its own view of the transcript of the protocol up to that point, to make sure any message sent by the client was received unmodified by the bank, and vice versa.
9. Bank computes its own message authentication code Macmk(transcript') and send it to the client.
10. Client has to verity the message authentication code is correct, no message was modified in its interaction with the bank.

After a successful completion of the handshake protocol, the client and the bank now share four different keys kC, k'C, kS, k'S. And it’s those keys that they can then use in the record layer protocol to secure their communications.

Record-Layer Protocol

 Client is going to use kC and k'C to encrypt/authenticate all the messages it sends. Bank is going to use kS and k'S to encrypt/authenticate all the messages it sends. This will prevent the reflection attacks, where:

1. a client sends a message
2. an attacker redirects that back at the client
3. the client verifies and everything seems OK.

Sequence numbers are also used here to prevent replay attacks.

---

---

My Certificate

For more on Public Key Infrastructures & SSL/TLS, please refer to the wonderful course here https://www.coursera.org/learn/cryptography

My #90 course certificate from Coursera

---

Related Quick Recap

Discrete Logarithm Based Digital Signature

---

I am Kesler Zhu, thank you for visiting my website. Check out more course reviews at https://KZHU.ai