Digital Signatures
When you sign something, it often represents a commitment to follow through, or at least prove that you are who you say you are. In the world of cryptography, a digital signature provides three core benefits:
Authentication
Data integrity
Nonrepudiation
Digital Signatures in Action
One of the best ways to understand how a digital signature operates is to remember what you learned in the previous sections about public and private key pairs, hashing, and encryption. Digital signatures involve each of these elements. Here’s the play by play. Bob and Lois are two devices that want to establish a VPN connection to each other, and to do so they want to use digital signatures to verify each other to make sure they are talking to the right device. Both the devices want to verify each other, but for simplicity will focus on one device: Bob wanting to prove its identity to the other device Lois. (This could also be phrased as Lois asking Bob to prove Bob’s identity.)
As a little setup beforehand, you should know that both Bob and Lois have generated public-private key pairs, and they both have been given digital certificates from a common certificate authority (CA). A CA is a trusted entity that hands out digital certificates (more on that later). If you and I were to open a digital certificate, we would find the name of the entity (for example, Bob). We would find Bob’s public key (which Bob gave to the CA when he applied for his digital certificate). There would also be a digital signature of the CA. Both Bob and Lois trust the CA and have both received their certificates. Okay, now back to the story.
Bob takes a packet and generates a hash. Bob then takes this small hash and encrypts it using Bob’s private key. (Think of this as a shipping container, and we are using the small key in the small keyhole to lock the data.) We attach this encrypted hash to the packet and send it to Lois. There is a fancy name for this encrypted hash: a digital signature.
When Lois receives this packet, she looks at the encrypted hash that was sent and decrypts it using Bob’s public key. (Think of this as a big keyhole and the big key being used to unlock the data.) She then sets the decrypted hash off to the side for one moment and she runs the same hash algorithm on the packet she just received. If the hash she just calculated matches the hash she received (after she decrypted it using the sender’s public key), she knows two things. She knows the only person who could have encrypted that was Bob with Bob’s private key, and that data integrity on the packet is solid, because if 1 bit had changed the hash would not have matched. This process is called authentication, using digital signatures, and normally happens in both directions with an IPsec VPN tunnel if the peers are using digital signatures for authentication, referred to as rsa-signatures in the configuration.
One might ask, okay so how did Lois get Bob’s key (Bob’s public key) to begin with? The answer is that Bob and Lois also exchanged digital certificates, which contained each other’s public keys. Bob and Lois do not just trust any certificates, but they do trust certificates that are digitally signed by a CA that they trust. This also implies that to verify digital signatures from the CA, both Bob and Lois would also need the CA’s public key. Most browsers today have the built-in certificates and public keys for the mainstream CAs on the Internet today.