The next kind of trust

[bnewman]

Our 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.

Comments

[q10.livejournal.com]

but the point is that your system deprecates the previous way of providing your company with any short-notice evidence that you're not just calling in as a prank, and i'm still not sure what it's putting in its place.

[orawnzva.livejournal.com]

If by "the previous way" you mean "knowing your social security number", then that's intentional. In its place it would put a battery of similarly weak questions, such as "what's your mother's maiden name" or the like, the kind of thing you set up in case you forget a password. I suppose "what are the last four digits of your SSN" could be among them, but it's a feature of this system that the SSN is not regarded as secure.

Similarly, I do want to deprecate the use of possession of documents without any corroborating recent biometrics, such as a social security card (no biometrics) or birth certificate (no current biometrics) as meaning anything. Thus photo ID such as a passport or driver's license, especially if it listed height/weight, would still play a very important role. You'd only need to visit a notary with witnesses if you'd lost all of that, to get a certificate of identity issued without any documents attesting to your identity (the witnesses would need ID). To register a key, you'd go somewhere that generates keys (notary, post office, bank, etc.) and get the key along with a receipt signed by the establishment attesting that they gave the key to someone who authenticated as you, in whatever manner you so authenticated.

It's true that authenticating as yourself on short notice if you are not present in person and have lost any relevant documents is going to be either difficult or provide very weak authentication. That's how it actually is — I'd prefer a system that doesn't paper over it and then make people jump through unfamiliar, punitive hoops on those occasions when it actually becomes an issue.

[q10.livejournal.com]

(this is my 4096th lj comment - i need to get les distractable.)

no, by ‘the previous way’ i meant ‘furnishing secondary verifying personal information’ - which is what you do when you're calling in a fraud alert on your credit record, as i've recently seen first-hand.

let's start over, since i think we've been talking past each other. there are basically two problems with the current system:

1. it has replayability insecurity and various of its cousins.
2. it has a single point of moderately catastrophic failure (in the form of the SSN).

your system solves (1), but, as originally sketched, appears to make (2) worse, since all your verifying ability is wrapped up in your private key, and, if that's compromised, it may take a matter of days to even get it flagged as compromised.

‘days’ is a lot of damage worth of time. ‘hours’ would be acceptable. ‘minutes’ would be preferable. ‘days’ is right out. my claim is that, although using smart cryptography is a good idea, it's more important to reduce the degree to which there's any one document which an attacker can cause large amounts of havoc by compromising. this is actually the kind of security we're seeing develop emergently (with the more and more complex identifying questions). if we want to build a new crypto infrastructure, we should make a point of stepping forward, rather than back, in the area of error-tolerance. since there's been a lot of work on cryptographic protocols to do almost exactly this, we should be able to make some real progress here.

[orawnzva.livejournal.com]

Okay, another important distinction which I suppose I didn't actually mention before — it ought to be much easier to get credentials revoked than to get them issued. A company needs to have two standards of identification — a strong one for allowing you access to your account, and a weak one (i.e. one that you can use even if you don't have a crypto-widget) for allowing you to revoke the first one should it be compromised. But nobody should be under the illusion that this weaker form of authentication cannot be cracked by someone who is "just calling as a prank". For this weak layer, questions about your recent account history would probably be better than personal questions.

So, yeah, you should be able to get a key revoked much more easily than I seem to have otherwise implied. It should simply be understood that this is a wholy different (and lower) order of "proving you're you".