In the last article, I wrote about how we can use public key cryptography to perform digital signing. At the end, we started to touch on the problem of key distribution – I need to give you a document, signed with my private key, but you need my public key in order to verify the signature. I can just give it to you by attaching it to the file… but should you trust it? Where’s the danger here?
Let’s put our “man in the middle” into play here – let’s call him “Gregor”. Randy wants to send Josh a signed email. Randy types up his email, computes the MD5 hash of his email, encrypts the hash with his private key, and attaches it to the email. Because he has never communicated with Josh before, Josh doesn’t have Randy’s public key. Because Randy is the helpful sort, he attaches his public key to the email. Gregor intercepts the email, changes the text, and then recomputes the digital signature using a private key he generated himself. He attaches the corresponding public key to the email, replacing the one Randy originally attached. He then forwards the email along to Josh. Upon receipt, Josh installs the attached public key into his electronic “keyring” and uses it to successfully check the integrity of the received email. Since it checks out, he knows the message from Randy is genuine and wasn’t modified in transport.
The problem here is a twist on our classic secret key encryption problem: key distribution. We have removed the problem of keeping the key secret – the public key is supposed to be public. However, we have no way to verify that a public key actually belongs to the person it is supposed to belong to – the public key is simply a large number, with no identifying information attached. An adversary can easily substitute one large number for another, and fool you into using the wrong public key. One solution includes meeting the other person face to face, checking two forms of government-issued photo ID, and then exchanging public keys on CD-ROMs or thumbdrives. Other solutions involve generating “key fingerprints” and then reading these over the phone to the other person (assuming you have positively established the person is who he claims to be.) These solutions are cumbersome at best, and would not allow public key cryptography to be widely deployed if they were required. Fortunately, digital certificates provide a solution for us.
A digital certificate makes someone else do the job of verifying that a public key belongs to the correct person or entity. This “someone else” is known as a certificate authority (CA). A certificate authority is an organization that the users of a digital certificate have chosen to trust to perform the validation of identity and the issuance of digital certificates. Well-known public certificate authorities on the Internet include VeriSign, Thawte, Entrust, and GeoTrust. These companies will, for a fee, verify your identity or the identity of your organization and then issue you a digital certificate, which contains your public key. Other users of the system, having chosen to trust these CAs, will know that your digital certificate is genuine. The entire system is known as a Public Key Infrastructure, or PKI. More on PKI next time..
At Aruba, we believe that the most dynamic customer experiences happen at the Edge. Our mission is to deliver innovative solutions that harness data at the Edge to drive powerful business outcomes.
© Copyright 2020 Hewlett Packard Enterprise Development LPAll Rights Reserved.