The next kind of trust
Feb. 11th, 2007 08:53 am![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
bnewmanOur society's trust and authentication systems are fundamentally broken. They are broken for a very specific, concrete reason which I will outline below. Bruce Schneier has, of course, written on this exact matter, but I can't find the specific article I'm thinking of.
Suppose John Doe applies for a credit card. He tells them truly that his name is John Doe and his SSN is 123-45-6789. He tells them a bunch of other stuff too — enough stuff for someone to decide whether or not to issue him credit as John Doe, 123-45-6789. This means that any employee of the credit card company with access to his application can submit a fraudulent application to another credit card company, just like that, because they have all the information that needs to be on such an application!
The problem with this system is that transactions are replayable — the same "secret" is used to authenticate to everyone, which makes it a lousy secret. The SSN was never meant to be used this way. It was meant to be used for identification purposes, in the strict and limited sense: If I say "John Doe, 123-45-6789", and you say "John Doe, 123-45-6789", we know we are talking about the same person, and that one of us is not, for instance, thinking instead of John Doe, 987-65-4321. But we have no reason to believe that either of us is John Doe, 123-45-6789 — how could we, when everyone who has ever had need to refer to him in such a capacity knows his SSN?!
Well, then, we need a new authentication model. In this model, transactions will not be replayable. This model already exists — it's called a public key infrastructure. It's already used informally by many computer geeks. Here's how an official version would work in my world:
When you come of age, you go to a notary public who knows you personally, and claim under penalty of perjury that you are you. The notary then uses a specialized key generator (a computer which, by law, is not networked and runs only the open-source key-generating software) to generate a public-private key pair, which is printed out all folded up like a paycheck, with the public key on the outside and the private key on the inside. The notary then notarizes a letter associating your name and SSN with the public key. This is your root public key. It goes on your credit report, and you'll use it to prove very officially that you are you. You can change it by repeating the same process — the old one will be tagged as compromised, but not deleted.
You'll want to transfer that private key to your secure crypto-widget (as you'll see shortly, everyone will need a crypto-widget) and then put it in a safe-deposit box or burn it. Now let's say you want to apply for a credit card. You download an application, which will have a unique id. You fill out the application as before, claiming to be John Doe, 123-45-6789. You also sign the unique id with your private key and fill in the signature in the appropriate place on the form. (You'd probably have to give it your John Hancock as well — some habits die hard, and it does provide some additional security.) The credit card company can verify the signature because your public key is in your credit report.
When you get your credit card, it will be in the form of another key pair to add to your crypto-widget. You use this key to sign a hash of the transaction record whenever you make a credit card purchase. Now your credit card transactions aren't replayable. Voila!
It's now much harder for someone to steal your identity, and easier to find out how if they do. With enough time or a quantum computer, your keys can be cracked, but most people aren't important enough to warrant such effort. On the other hand, what if someone steals your crypto-widget? Well, what if someone steals your credit card? They could do that before, but they could also steal a receipt, a copy of your statement, or any of a number of ephemeral documents associated with your credit card. Now, they have to steal the widget itself — and then it won't do them much good.
The crypto-widget I imagine is about the size and shape of a credit card, but thicker. It contains a tiny computer-on-a-chip, a solar cell on the back to recharge it, a rudimentary scanner to read barcodes, a strip of e-ink to display a bar code, a keypad to enter a PIN, a fingerprint scanner, and a photo. You'd sign a credit-card transaction by entering your PIN to activate the widget, scanning the barcode on the bill (which is the hash of the transaction record), and then handing the card, credit-card-like, to the cashier with the signature displayed as a barcode on the e-ink strip. You could also enter a hash using the keypad and have it display in human-readable form on the e-ink strip.
The widget can store a handful of keys — your root key, protected by your fingerprint and a nice, long PIN, your credit cards, protected by a shorter PIN (if you like), etc. Each activation is good for just one transaction. There is no direct electronic interface, only optical (and certainly not RFID!), and the card's firmware will never treat a scanned barcode as code, only as data (a hash to sign or a new key to add), so it should be fairly difficult to hack.
Suppose John Doe applies for a credit card. He tells them truly that his name is John Doe and his SSN is 123-45-6789. He tells them a bunch of other stuff too — enough stuff for someone to decide whether or not to issue him credit as John Doe, 123-45-6789. This means that any employee of the credit card company with access to his application can submit a fraudulent application to another credit card company, just like that, because they have all the information that needs to be on such an application!
The problem with this system is that transactions are replayable — the same "secret" is used to authenticate to everyone, which makes it a lousy secret. The SSN was never meant to be used this way. It was meant to be used for identification purposes, in the strict and limited sense: If I say "John Doe, 123-45-6789", and you say "John Doe, 123-45-6789", we know we are talking about the same person, and that one of us is not, for instance, thinking instead of John Doe, 987-65-4321. But we have no reason to believe that either of us is John Doe, 123-45-6789 — how could we, when everyone who has ever had need to refer to him in such a capacity knows his SSN?!
Well, then, we need a new authentication model. In this model, transactions will not be replayable. This model already exists — it's called a public key infrastructure. It's already used informally by many computer geeks. Here's how an official version would work in my world:
When you come of age, you go to a notary public who knows you personally, and claim under penalty of perjury that you are you. The notary then uses a specialized key generator (a computer which, by law, is not networked and runs only the open-source key-generating software) to generate a public-private key pair, which is printed out all folded up like a paycheck, with the public key on the outside and the private key on the inside. The notary then notarizes a letter associating your name and SSN with the public key. This is your root public key. It goes on your credit report, and you'll use it to prove very officially that you are you. You can change it by repeating the same process — the old one will be tagged as compromised, but not deleted.
You'll want to transfer that private key to your secure crypto-widget (as you'll see shortly, everyone will need a crypto-widget) and then put it in a safe-deposit box or burn it. Now let's say you want to apply for a credit card. You download an application, which will have a unique id. You fill out the application as before, claiming to be John Doe, 123-45-6789. You also sign the unique id with your private key and fill in the signature in the appropriate place on the form. (You'd probably have to give it your John Hancock as well — some habits die hard, and it does provide some additional security.) The credit card company can verify the signature because your public key is in your credit report.
When you get your credit card, it will be in the form of another key pair to add to your crypto-widget. You use this key to sign a hash of the transaction record whenever you make a credit card purchase. Now your credit card transactions aren't replayable. Voila!
It's now much harder for someone to steal your identity, and easier to find out how if they do. With enough time or a quantum computer, your keys can be cracked, but most people aren't important enough to warrant such effort. On the other hand, what if someone steals your crypto-widget? Well, what if someone steals your credit card? They could do that before, but they could also steal a receipt, a copy of your statement, or any of a number of ephemeral documents associated with your credit card. Now, they have to steal the widget itself — and then it won't do them much good.
The crypto-widget I imagine is about the size and shape of a credit card, but thicker. It contains a tiny computer-on-a-chip, a solar cell on the back to recharge it, a rudimentary scanner to read barcodes, a strip of e-ink to display a bar code, a keypad to enter a PIN, a fingerprint scanner, and a photo. You'd sign a credit-card transaction by entering your PIN to activate the widget, scanning the barcode on the bill (which is the hash of the transaction record), and then handing the card, credit-card-like, to the cashier with the signature displayed as a barcode on the e-ink strip. You could also enter a hash using the keypad and have it display in human-readable form on the e-ink strip.
The widget can store a handful of keys — your root key, protected by your fingerprint and a nice, long PIN, your credit cards, protected by a shorter PIN (if you like), etc. Each activation is good for just one transaction. There is no direct electronic interface, only optical (and certainly not RFID!), and the card's firmware will never treat a scanned barcode as code, only as data (a hash to sign or a new key to add), so it should be fairly difficult to hack.
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
(no subject)
Date: 2007-02-12 12:19 am (UTC)