It's time to change how Social Security numbers work
Matthew Martin 2/16/2015 09:52:00 AM
Social Security numbers are an example of symmetric-key encryption, also known as a "shared secret," except that they aren't very secret. They way that is supposed to work is that your social security number is a private key which you know, and which the second party you wish to prove your identity to can match against your identity records. By communicating this private key to the second party--provided no one else in the world knows this secret--you prove you own the identity in their records. This is obviously flawed. First, social security numbers are essentially public information--that's how all these firms are able to match them to your identity in the first place. Even worse, once you give out your social security number, it can be copied by the recipient--or any man-in-the-middle attacker who steals it--and used anywhere else.
What we really need is to convert social security numbers into a public-private key asymmetric-encryption system. Instead of assigning everyone just one private social security number, everyone would get two related numbers: a public social security number and a private, secret social security number. The latter will never be revealed to anyone, ever. The public and private social security numbers correspond to the public and private keys, respectively, of an asymmetric encryption algorithm such as RSA. The numbers are related in such a way that the private number can encrypt text, while the public number can decrypt but not encrypt text.
So to prove you are who you claim to be, a firm would send you some randomized text to encrypt using your private social security number (we'll call this plain text an "address"), then you would reply with the encrypted address along with your public social security number. The firm would then decrypt the original message using your public number, and if the result is what they sent you, then you've proved you own that social security number. They can then match this public social security number against identity records in the usual way. In addition, the firm would transmit a record of the (unencrypted) address they used to the government, who would store it anonymously in a public master list, to prevent reuse by anyone else, ever.
Because addresses are never reused, it doesn't matter if anyone steals your public social security number or even a copy of the encrypted address you sent to the firm. The only way someone would be able to impersonate you would be to actually possess your private social security number, which you never have give out to anyone ever.
A few footnotes:
 Note that this idea is not highly original. I've basically taken well-known ideas about how to use the bitcoin block-chain for identity verification, and stripped out all of the computationally-intensive fat by adding in a trusted centralized party--the social security administration.
 The main weakness of this system is that people will loose and/or accidentally disclose their private social security numbers. The government would need to maintain a system so that people can revoke and replace their social security numbers at any time, and this would form a relatively weak link in the security chain.
 I'm not a cryptographer, so I don't really know how plausible it is to actually break the RSA algorithm, or whatever asymmetric algorithm they end up using. Probably, we'd want to add a step so that customers can verify that the address the firm sent them is valid--that is, has never been used before, and is totally random. Reuse is a problem for firms, since a customer claiming to be someone may have simply stolen the encrypted copy of the address. And non-random addresses could (I think) potentially be used by phishers to break the encryption algorithm and reconstruct your private social security number. Thus, the government needs to maintain an API that allows both parties to validate the address.
 All of this has to be mediated by software, since no one is going to do RSA encryption/decryption by hand. Since the software would need your private social security number to carry out the encryption, this is also a weak point in the system--phishers would create bogus apps mimicking actual identity software in order to steal your private number. Moreover, since this would need to be on a device owned and controlled by customers rather than firms (such as iPhones), this system places poorer people at a disadvantage since they would not have as much access to devices to run the encryption software and transmit the information to the firm.