Identity crisis

Ever since its introduction in 1936, your Social Security number has served as your United States Employee ID number. It’s used to verify your credit when you sign up for a credit card or buy a car, it’s used to verify your identity when filling out government forms, and it’s used to keep your medical record where it’s supposed to be.

Unfortunately, there are a ton of problems with this system. It was never meant to be an ID number for any program except the Social Security program, but in lieu of an official alternative, it’s been misused and overexposed. Worse yet, since your Social Security number never changes, many private institutions use it as your ID number. Ever have to write the last four digits of your Social Security number on a college exam? Ever need to enter it to recover a lost password? The more it’s used, the easier it is to steal. Even if you only surrender the last four digits, an astute snooper can determine what the rest of it is based on where you were born. We need a better alternative. We need a way for US citizens to confirm their identity that is just as secure for private companies as it is the government. The solution, I believe, is public-key cryptography.

For those not well-versed in cryptography, I’ll use the common example. Suppose Alice wants to send a message to Bob without a third party, Eve, being able to intercept it. Bob, being the secure guy he is, has published a public key (a key is a long string of characters that represents a number which is used to encrypt the data mathematically). In other words, Bob can tell Alice his public key any way he wants – even if Eve knows the public key, the message is safe. This is the beauty of public-key cryptography: anyone can encrypt a message and send it to Bob, and then all Bob has to do is use his private key, a seperate key which he tells no one, to decrypt and read the message. The two keys are mathematically related, but if the key is a large enough number, it’s nearly impossible to determine the private key from the public key. Only the private key will decrypt the message.

How does this relate to replacing Social Security numbers? Instead of everyone being issued a Social Security number upon birth, we issue a public and private key to each person when they’re born. The public key goes on their birth certificate, driver’s license, and really anywhere it needs to go. The private key goes in one place and is stored safely.

Skip ahead to when the person applies for a credit card and identification is needed to make sure the person is who they say they are.

  1. The person fills out an online application including name, address, etc. The application also includes a field for the public key.
  2. Upon submission, the web site generates a random code and encrypts it using the the person’s private public key, and stores it in a text file. The server redirects the person to a form where he can download the text file and enter the code.
  3. The user downloads the encrypted text file and using software built-in to a secure thumb drive, decrypts the file using his private key. He copies and pastes the resulting code on the web site.
  4. The web site confirms that the code entered matches the code stored in the file. If it does, the user is who they say they are. If not, they’re not.

There are a couple issues with this system. For one, computer access is required. This isn’t a dealbreaker; basically, it would add another step to paper forms, where you’d fill out most of the form and write in your public key, then go to a computer and grab a confirmation code and write that down too. The server would need to store the confirmation code and the public key associated with it for a long enough period of time to ensure the application gets handled and verified. Second, and more importantly, computer literacy is required. I mentioned that the software should be on a thumb drive to make it easier, but that would still require some education on how to use the software built-in to encrypt and decrypt the keys, and what the difference is between your public and private key. Third, and most importantly, security would be of the utmost importance. The private key must only exist in two places, tops: a secure thumb drive (protected by a thumbprint or something similar) and a government registration system (used in case the thumb drive needs to be replaced). The thumb drive would need to be impenetrable; both the hardware and the software on the thumb drive would need to be reviewed by as many security experts as possible before deployment and reviewed often.

But the benefit from this system is worth it. Everyone’s identity is not only protected, it is mathematically secure. Where current Social Security numbers have (at most) at 1 in 1 billion (1 × 109) chance of being guessed (and as I said earlier, the odds are probably much lower), a 1024-bit key system would a 1 in 21024 ≈ 1.79 × 10309. Not only is the odds of guessing your identity lower, but providers are able to verify your identity without knowing anything that should remain as private as possible; the only things that would know your private key are your thumb drive and that database – you would never even have to see it.

Do I think this will happen anytime soon? Absolutely not. A change of this magnitude would cost billions of dollars, and over 25% of the current US population does not use the Internet. But it should, at some point. Our personal security and privacy is our most important asset, and we need to change how we protect it.



Originally posted on Cleveland, Curveballs and Common Sense on August 2, 2009 at 1:30 AM. Post text content © 2009 Jimmy Sawczuk. All rights reserved.

Comments