Originally published at: https://awallet.io/are-public-keys-really-public/
Usually, those who work with PKI, work behind the protection of software developers, technical support staff, professional organizations and business people. Despite the social ring the name has: ‘public key infrastructure’, those keys typically work in the fancy infrastructure while remaining pretty well segregated from the public.
Blockchain is based on digital signatures, which is the key part of PKI. Bitcoin’s popularity leads to a lot of use-cases of PKI being rediscussed and reapplied. As a Blockchain architect, I find myself explaining PKI again and again, through practice, I have refined the art in explaining it. This article is the shortest and most concise way of getting that job done. I first learned about PKI when I was merely 13 years old, a mesmerizing experience as I was dwelling in the state library of Gansu for months. Nevertheless, I intend to explain it in just a few minutes.
PKI for everyone to understand
This article is intended to make PKI understandable for anyone who can read up to this point.
This article intentionally does not cover Blockchain. It’s my day job to talk about Blockchain but for now, I prefer to give my reader a clearer picture of PKI.
Password is inadequate
A password is a useful tool for authenticating against a known, trusted party. Here’s a simplified example:
Insurance company:
Are you one of our users?
User:
Yes, here is my password.
That’s all that it does.
It is not useful when authenticating a 3rd party.
3rd Party:
Hey, are you a customer of the Insurance Company?
User:
Yes
3rd Party:
Prove it.
User:
Here is my password.
3rd Party: (logging in)
Seems right, okay.
3rd Party: Rolling his eyes: now I can assume your identity since I can login too…
If by this time the technical terminology ‘SSO’ comes to your mind, push it back for a while. I can’t spare the time to flog that beast but I’ll do that properly some other time.
Passwords have other faults, e.g. they are re-used, so if a website is compromised, you need to change your password not only on that website but also on every other website where you have used the same password.
Finally, passwords are predominantly used for authentication, not for authorization. Let’s examine the difference:
Bank:
We are following up your chargeback claim. First, your password, please.
User:
dogBreath#231!
Bank:
Okay. You have been authenticated. According to our record, it seems you have authorized that payment.
User:
I didn’t.
Bank:
You logged in to our online banking system yesterday.
User:
Yes
Bank:
And then you clicked ‘Authorize payment’.
User:
No I didn’t!
Bank:
You did it.
User:
What’s the proof?
Bank:
The computer says so. You did it.
User:
You can get your computer to say anything! It’s your computer!
Here, the password doesn’t allow the bank to provide proof of authorization.
- How PKI works: Digital signatures
First, you get yourself a private key and a public key using a computer. You don’t need anyone to give you one. (In fact you must not allow anyone to give you one! If anyone gives you a private key, then it is their key, not yours)
Then, you give the public key to someone. In the future, when you send that person any message, you can attach a signature to show the message is from you.
signature := sign(message, private_key)
:= means ‘obtained by’.
That person can then verify it:
verify(message, signature, public_key)
This will return True or False, meaning the signature is ‘valid’ or ‘not valid’.
“Why the hassle?” You may ask: “If Alice writes an email to her colleague Bob, without using the elaborate digital signature, Bob can see that it is from Alice because it lies in Bob’s INBOX (e.g. Gmail) and it says ‘From: Alice’.”
Well, Bob’s confidence stems from the trust he has in his INBOX. A digital signature is a proof in the message itself, disregarding where the message is stored. If Bob drags the email message outside of his INBOX, and puts it on a USB stick, and gives the USB stick to Carol, Carol will be is less likely to trust that Alice wrote it. With a digital signature, an authentic message is an authentic message; it is irrelevant of the trustworthiness of Bob’s INBOX or Bob himself for that matter.
“Big deal”, I hear you say, “as if an INBOX is not already good enough.” It’s indeed a big deal if you can trust the message by itself. Think if you received a cheque from the Post Office, do you need the cheque to be signed? Yes. Do you need it to be signed even if the post office promises that they got it from the sender’s own hands? Well, even then, you still want the cheque signed. Apparently it really is such a big deal.
- How PKI works: Authority
In the last chapter, Alice created her private key and public key, and she wants to write to Bob and provide a signature. However, she never had a chance to meet Bob, and Bob needs to know Alice’s public key to verify the signature.
Alice can send her public key to Bob by email. For authenticity, she can also sign that email. But Bob didn’t have Alice’s public key at the outset, how can he verify that first email?
Alice and Bob need a middleman. That middleman is Carlos, whom they both trust. By trust, we imply that both Alice and Bob already know Carlos’ public key and can verify Carlos’ digital signature if Carlos sends them anything. This is how it works:
Step 1. Alice visits Carlos. Carlos signs with his key the following message:
carlossignature := sign(“I met Alice, and she told me her public key is 0xd1fc.”, carlospublic_key”)
Step 2. Alice writes a message to Bob, signs it.
alice_signature := sign(“Bob, can we connect?”, 0xd1fc)
Step 3. Alice put everything together and send it to Bob:
Bob, can we connect? I am the real Alice, see following Carlos’ testament.
First, you get yourself a private key and a public key using a computer. You don’t need anyone to give you one. (In fact you must not allow anyone to give you one! If anyone gives you a private key, then it is their key, not yours)
Then, you give the public key to someone. In the future, when you send that person any message, you can attach a signature to show the message is from you.
signature := sign(message, private_key)
:= means ‘obtained by’.
That person can then verify it:
verify(message, signature, public_key)
This will return True or False, meaning the signature is ‘valid’ or ‘not valid’.
“Why the hassle?” You may ask: “If Alice writes an email to her colleague Bob, without using the elaborate digital signature, Bob can see that it is from Alice because it lies in Bob’s INBOX (e.g. Gmail) and it says ‘From: Alice’.”
Well, Bob’s confidence stems from the trust he has in his INBOX. A digital signature is a proof in the message itself, disregarding where the message is stored. If Bob drags the email message outside of his INBOX, and puts it on a USB stick, and gives the USB stick to Carol, Carol will be is less likely to trust that Alice wrote it. With a digital signature, an authentic message is an authentic message; it is irrelevant of the trustworthiness of Bob’s INBOX or Bob himself for that matter.
“Big deal”, I hear you say, “as if an INBOX is not already good enough.” It’s indeed a big deal if you can trust the message by itself. Think if you received a cheque from the Post Office, do you need the cheque to be signed? Yes. Do you need it to be signed even if the post office promises that they got it from the sender’s own hands? Well, even then, you still want the cheque signed. Apparently it really is such a big deal.
In the last chapter, Alice created her private key and public key, and she wants to write to Bob and provide a signature. However, she never had a chance to meet Bob, and Bob needs to know Alice’s public key to verify the signature.
Alice can send her public key to Bob by email. For authenticity, she can also sign that email. But Bob didn’t have Alice’s public key at the outset, how can he verify that first email?
Alice and Bob need a middleman. That middleman is Carlos, whom they both trust. By trust, we imply that both Alice and Bob already know Carlos’ public key and can verify Carlos’ digital signature if Carlos sends them anything. This is how it works:
Step 1. Alice visits Carlos. Carlos signs with his key the following message:
carlossignature := sign(“I met Alice, and she told me her public key is 0xd1fc.”, carlospublic_key”)
Step 2. Alice writes a message to Bob, signs it.
alice_signature := sign(“Bob, can we connect?”, 0xd1fc)
Step 3. Alice put everything together and send it to Bob:
Bob, can we connect? I am the real Alice, see following Carlos’ testament.
alice_signature
Carlos said:
I met Alice, and she told me her public key is 0xd1fc
carlos_signature
Alice’s part is done. Now Bob, upon reading the message, does 2 things:
verify(“I met Alice, and she told me her public key is 0xd1fc”, carlossignature, carlospublic_key)
verify(“Bob, can we connect? I am the real Alice, see following Carlos’ testament.”, alice_signature, 0xd1fc)
The first step involves Bob checking Alice’s public key is 0xd1fc by checking Carlos’ signature. Since Bob trusts Carlos, anything he signs must be true. This raises Bob’s confidence that Alice’s public key is 0xd1fc. The second step involves Bob checking Alice’s signature using the public key confirmed by Carlos. This raises Bob’s confidence that the message is signed by a private key of 0xd1fc.
Together, Bob is convinced that the message is from Alice.
For some strange reasons akin to ancestral worship and authority worship, we call Carlos an “Authority”. That name has been used since the 1980’s and it is outdated and inaccurate. If PKI can be compared to a court, then Carlos is a ‘witness’. He doesn’t have authority over anything, and his wiggling room is just to lie or not to lie. The word ‘authority’ implies that Carlos is the judge but he really isn’t. The word Authority was initially used to imply that they are trustworthy, and that too, isn’t true. For example, The Chinese Internet Authority CNNIC lied about Google’s public key in 2015. (It’s a big organization so it blamed a corrupted partner company in Egypt after its initial denial failed.)
If I had invented PKI, I would probably call them a Notary or a Witness.
As a consequence of Carlos being called Authority, the message he signed (“I met Alice, and she told me her public key is 0xd1fc”) is called a ‘Certificate’.
PKI provides trustworthy digital signatures, which can be used for two purposes. Authorization and Authentication.
Authorization is easy to understand:
“I, Alice authorise the payment.”
alice_signature
It is more often used in reverse ways, the user being authorized by someone instead of the user authorizing something to be done. That has nothing to do with technology. It’s the cultural structure of our society that organizations’ authorization needs are addressed before the individuals’ authorization needs.
As for authentication, here is how it works:
First, there is a verifier, against whom a user authenticates. Let’s say Alice is trying to prove that she is Alice to Victor, a verifier.
Victor: if you are Alice, you should be able to sign as Alice.
Alice: Sure, here you are:
“I am Alice.”
alice_signature
Victor: Wait. The real Alice could have said the same thing to another verifier, Veronica, and you happened to be there, so you copied her signature.
Alice: Then, what do you want me to do?
Victor: Sign this instead: “Dear Victor, I am Alice.”
Alice: Here you are. Now you must believe me.
“Dear Victor, I am Alice.”
alice_signature
This kind of thing happens with VISA Paywave or MasterCard Paypass. When you tap your credit card for a payment, the POS machine sends a challenge, like “Dear Victor, I am Alice.” but really any unpredictable number is okay, since all Victor intended is that Alice couldn’t produce the message before Victor challenges her. So these POS machines uses random unpredictable numbers. In reality, it turns out that some of them are actually fairly predictable — a security hazard, as was found by Melbourne based security expert Peter Fillmore.
Conclusion
PKI is a foundational trust mechanism. To understand how PKI works, not why it works, is a simple task that most people can accomplish in an hour. It doesn’t require a college degree or any math background. I Myself, for example, do not possess any college degree at all. The actual signing mechanism or what happens in the ‘sign()’ function is difficult, but the majority of people who need to work with PKI, like legal professionals and Blockchain advocates, don’t need to touch that at all.