A Solution for NISTs Identity Ecosystem
by Peter
For today’s blog we’re going to take a look at NISTs “Identity Ecosystem” and see if it’s possible to build it.
The key attributes of the Identity Ecosystem include privacy, convenience, efficiency, ease-of-use, security, confidence, innovation, and choice. So we have a lot of things to consider when building this solution.
When looking at these kind of projects I always like to start around 50,000 feet and then zoom down all the way to ground level. So lets start with one of NISTs use cases – (remembering that our solution has to work for all of them)
Let’s use the Smartphone one:
Parvati does most of her online transactions using her smart phone. She downloads a “digital certificate” from an ID provider that resides as an application on her phone. Used with a single, short PIN or password, the phone’s application is used to prove her identity. She can do all her sensitive transactions, even pay her taxes, through her smart phone without remembering complex passwords whenever and wherever it is convenient for her.
Now lets add some “context” around the ecosystem.
- Digital Certificate – could come from anyone, and whatever you need to store it in, has to accept multiple certificates
- Not sure why this needs to be an application (after all it’s just a certificate)
- We need to add PIN number to this Cert. (this assumes that she’s registered for the Cert. and has already set up her PIN number)
Now when Parvati logs into her financial Web sites to conduct business she’ll be required to use this certificate to prove who she is. Here’s where we hit our first real snag. Lets say I’ve stolen Parvati’s phone, all I have to do is guess her PIN number and I can now access anything that Cert. allows me to.
Not good. While I’ve made it convenient and easy to use, I’ve created a huge Identity hole. I can easily masquerade as Parvati just by guessing her PIN number. So what could we do better?
Well how about adding some more “authentication” capabilities? Wikipedia has a great link on “Multi-Factor Authentication”
US Federal regulators consistently recognize three authentication factors:”Existing authentication methodologies involve three basic “factors”:
- Something the user knows (e.g., password, PIN)
- Something the user has (e.g., ATM card, smart card); and
- Something the user is (e.g., biometric characteristic, such as a fingerprint).
Authentication methods that depend on more than one factor are more difficult to compromise than single-factor methods.”
At first blush it appears that the NIST use case is already using 2 factor authentication – A PIN and a Cert. assigned to Parvati. However they’re really just distinct pieces of information vs. using information from two or more categories.
So in this case what we really need to do for Parvati is add “something the user is”. And for that we could use a fingerprint reader or even a voice print which can be compared with one on record at the financial Web site.
Now lets return to the use case and update it.
- Install a secure database on the device – think of this like the wallet you carry in your pocket
- Allow it to store “anything” from certificates, to voice prints, to data about your device
That’s much better. Now we have lots of distinct pieces of information about “ME” (Identity). Now all you have to do is merge them into the Web request going to the financial site which is very straightforward.
Identity takes many forms – but ultimately boils down to something very simple – ME. It’s data that defines who I am, where I am and what device I’m using (so the experience can be optimized).
All you need is a simple way to store it securely (a database) – transmit it securely (HTTPS or Encrypted Headers) and process it with your existing infrastructure (CGI Environment variables which have been around for as long as the Internet has been with us).
If you go back and look at the use cases you see this solution scales to everyone one of them without requiring a single change to your current infrastructure.