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-11 04:31 pm (UTC)you're absolutely right about the SSN not being designed for authentication, only identification. it's also worth noting that you can usually get by with refusing to give out your SSN, especially if you cite that it was not meant for authentication.
(no subject)
Date: 2007-02-11 04:40 pm (UTC)Which is why you also have a PIN. "Something you are, something you have, something you know."
(no subject)
Date: 2007-02-11 04:43 pm (UTC)(no subject)
Date: 2007-02-11 04:49 pm (UTC)(no subject)
Date: 2007-02-11 05:20 pm (UTC)(no subject)
Date: 2007-02-12 01:41 am (UTC)WHAT is that icon? I can read "Республика Тыва", which is .... Ah ha. Google is your friend. Republic of Tuva.... fascinating!
(no subject)
Date: 2007-02-12 09:39 am (UTC)(no subject)
Date: 2007-02-12 03:27 pm (UTC)(no subject)
Date: 2007-02-12 04:05 pm (UTC)-- Dr. Whom, Consulting Linguist, Grammarian, Orthoëpist, and Philological Busybody
(no subject)
Date: 2007-02-11 04:50 pm (UTC)(no subject)
Date: 2007-02-11 05:01 pm (UTC)(no subject)
Date: 2007-02-11 06:13 pm (UTC)(no subject)
Date: 2007-02-11 05:44 pm (UTC)(no subject)
Date: 2007-02-11 06:15 pm (UTC)(no subject)
Date: 2007-02-11 08:07 pm (UTC)(no subject)
Date: 2007-02-11 08:22 pm (UTC)The thing is that the widget isn't a black box — its specifications are well-documented. Everything about the inside of your widget is generally known except the contents of and keys to its secure memory — the secure memory keys are internal to the widget and known to nobody, not even you, and the ROM holding them is designed to fry itself if the widget is tampered with. Of course a determined hacker will be able to crack your card. However, I should think that the fact that a hardware attack involveng actual dissassembly is required to even buy a sandwich with a stolen widget would be somewhat reassuring.
(no subject)
Date: 2007-02-11 08:41 pm (UTC)this takes a lot longer than calling my credit card company and telling them my card has gone missing. the last couple of times i've needed a notary, it's taken me a while to track one down. most credit card companies will take theft reports by phone 24/7. the cost of this delay (not clear for whom, but some part of it will end up getting passed on to joe consumer) may be quite high.
multiple widgets will help, but this appears to have the same real problem as the current system, which is that your identify is in practice confirmed by a single small and frail object (here your notarized statement). and you are aware that many citizens don't have safe deposit boxes, and that indeed many don't have very good standing with the baning system in genera, right?
second paragraph:
it's a black box in the sense that it's distinctive information content needs to be accessible only through the approved interface (that is, all the fancy open-everything electronics is just part of the box exterior).
and people make remote purchases by credit card. this is, for some of us, the only real reason we ever use credit cards. disassembling the card to make one or two respectable-sized internet purchases seems like a better deal to the attacker.
you may be about to point out that internet purchases generally involve sending a physical object to a physical location, making tracking easier. this is worth something, but since an increasing portion of commodities transacted over the internet are non-physical, it's not as reassuring as it once was, and anyway it means that you have the satisfaction of catching the bastard, not that he doesn't still do damage. deterrence is something, but it's not everything.
and this isn't even starting on the possibility that the card might be vulnerable to non-mechanically-invasive scanning. you need to worry about the information content of any field emanating from the card and any energy transacted across its surface.
(no subject)
Date: 2007-02-11 09:22 pm (UTC)As for proving you're you to your credit card company in order to report a stolen card — what, you don't have a backup? Without a backup copy of your card number (as on a monthly statement), how would you do that now? You'd probably also have a couple of questions on file with your credit card company (and not on the widget), answers to which would be sufficient to suspend (but not to reactivate) a stolen key. You'd only need to visit a notary if you needed to re-bootstrap onto the official trust network from scratch (where scratch = personal acquaintance/physical presence).
A signature produced by a card might also identify the individual card (i.e. might also be signed with a key unique to the card, on top of your key), which would make it possible to revoke a card without revoking all the keys on it. You'd revoke the card+key combinations (you could do this over the phone, at least for your credit card key), and authorize a new set of card+key combinations (this, you would probably need notarization for).
(no subject)
Date: 2007-02-11 09:46 pm (UTC)i think we need to take a page from the error correction community and start finding ways to build in smart redundancy. it seems like the priority should be on minimizing the damage that can be done in the worst case by any one document being compromised, and to do this in a way that doesn't increase the risk of document security violations occurring.
that is, i like the fact that when any one form of identification has been compromised, i can still assert my identity relatively easily by bringing all the others to bear against it. your system, as originally described, seems to have less of this kind of redundancy than the current system (except of course for the higher-cost restart/nuclear option), and this makes me jumpy.
(no subject)
Date: 2007-02-11 10:07 pm (UTC)I see what you're getting at. It'd be fairly easy to build in whatever kind of redundancy you like, including the current level of redundancy, by having multiple widgets. In fact, you can strike any balance between convenience and security that you like — multiple backups of the same omnibus widget (with the keys locked to the widget I'm using, so that widget can be revoked if stolen), multiple widgets with different stuff on 'em, whatever. A lot depends on the cost of manufacturing the widgets.
(no subject)
Date: 2007-02-11 10:21 pm (UTC)i guess what i'm saying is that your problem is less too few widgets and more too few keys - does that make sense? having everything ride of the integrity of a single private key means that if security at the wrong single physical location, in the wrong single transaction is compromised, you're completely fucked, (even if you can in principle restore your identity eventually, it'll be a long and deeply unpleasant process). the idea is to have the ‘key’ distributed over a large number of certificates, of which you only have to use a small fraction for any given transaction except the meta-transactions involved in resets and security compromise reports.
(no subject)
Date: 2007-02-12 12:17 am (UTC)Ah, right. I suppose I gave the impression that you can only have one root key. You can have as many root keys as you like — a "root key" is just one that is tied to your entry in the current identity system, i.e. your name+SSN, is listed (just the public key, of course) in your credit file, and where the fact that the person who received the key when it was generated is the person to whom it is registered is notarized. You could pick up as many keys as you liked at the notary, and then use them for different things, or use one and save the others (in their tamper-evident envelopes) in a safe place in case the first one got compromised.
(no subject)
Date: 2007-02-12 12:19 am (UTC)(no subject)
Date: 2007-02-11 09:25 pm (UTC)(no subject)
Date: 2007-02-11 09:38 pm (UTC)(no subject)
Date: 2007-02-11 10:09 pm (UTC)(no subject)
Date: 2007-02-11 10:23 pm (UTC)(no subject)
Date: 2007-02-12 12:09 am (UTC)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.
(no subject)
Date: 2007-02-12 12:38 am (UTC)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.
(no subject)
Date: 2007-07-31 10:23 pm (UTC)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".
(no subject)
Date: 2007-02-11 08:14 pm (UTC)and these are going to be government engineers. probably Social Security Administration or IRS engineers.
and then we have to trust said government engineers not to deliberately compromise your security for their own or their masters' evil purposes, although i suppose certain political measures could make that sufficiently unlikely.
(no subject)
Date: 2007-02-11 08:28 pm (UTC)The widget can do exactly three things with a piece of read data:
1. store it as data under a given key
2. encrypt it with a given key and output the result
3. store it as a key
None of these involves code which dispatches on the value of the data. The data buffer is of fixed size. I think that pathway can be made secure fairly easily.
(no subject)
Date: 2007-02-12 12:36 am (UTC)