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
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:
- Proliferation of root CAs.
- Other issues.
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
TLS protocol operates in two phases:
- Handshake protocol
- Establish a shared key between two entities.
- Record-layer protocol
- Use the shared key for secure communication.
The core idea of how handshake protocol works between a client and a bank is as follow:
- Client browser sends
httpsrequest, along with a random number called nonce
- Bank responds with a copy of their public key
cert, and another random value nonce
- Client verifies the public key
pkfrom the bank is correct, using the public key from CA
- If the verification succeeds, client generates a random value called premaster key
pmk, and encrypts
pmkusing the public key
pkof 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.
- 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).
- 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).
- 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.
- 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.
- Bank computes its own message authentication code
Macmk(transcript')and send it to the client.
- 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.
Client is going to use
k'C to encrypt/authenticate all the messages it sends. Bank is going to use
k'S to encrypt/authenticate all the messages it sends. This will prevent the reflection attacks, where:
- a client sends a message
- an attacker redirects that back at the client
- the client verifies and everything seems OK.
Sequence numbers are also used here to prevent replay attacks.
For more on Public Key Infrastructures & SSL/TLS, please refer to the wonderful course here https://www.coursera.org/learn/cryptography
Related Quick Recap
I am Kesler Zhu, thank you for visiting my website. Check out more course reviews at https://KZHU.ai
All of your support will be used for maintenance of this site and more great content. I am humbled and grateful for your generosity. Thank you!
Don't forget to sign up newsletter, don't miss any chance to learn.
Or share what you've learned with friends!Tweet