The “Device Identity Model”
In the previous post, we looked at why our current practices for identifying ourselves have developed some serious flaws. Over time in the “Shared Secret Model”, our secrets become more vulnerable while our identity becomes more valuable. The risks and rewards are skewed far too heavily in favor of the identity thief.
The fix has been coming for several years:
- If you have a chip on your credit or debit card, and you put it in the dedicated slot or wave it over a sensor, you are already participating in the “Device Identity Model”. If you still had to swipe it, you are not.
- If you have been asked to enter a number from a text message into a webpage, you can start to see how Google and others like your bank are using a device (your cell phone) to ensure your identity over and above your login and password.
Before we flood ourselves with too many examples, it is helpful to review how cryptography works (in a very simplified form) because it is the key building block of the Device Identity Model.
Most children have played with a version of the following. PGP is more complex than Pig Latin or simple substitution but the principal is similar.
I add information into an encryption program which may be part of a phone operating system or a specific program like a Password Manager. The information is encrypted with a key that was set up with the phone initialization or program install. And the output, the text in the black box, is what sits in my file system, phone and/or in a database.
Once I have entered the information, the only thing sitting on my phone, computer or the cloud is a block of encrypted text. One will often hear this referred to as data “encrypted at rest”.
Now, when I want to see my bank information on my phone or computer screen (“get moving, data!”), all I need to do is reverse the process:
By giving my phone a password, fingerprint or PIN, I can instruct the phone or program to use my secret key to decrypt the text and show me the information (note that there is no relationship between password, fingerprint or PIN and my Secret Key).
The nice thing about modern encryption is that one’s private key is unique. It is created by mathematically crunching various pieces of information together (including the time) so that even if one were to create a number of keys using the same program, each one would come out differently.
So, the Secret Key can function as a unique identifier. But aren’t we back to the same old problem of the Social Security number and Date of Birth? Yes and no. Yes, if you were foolish enough to share the Secret Key. But no, because as we will see, one need not share the key for others to make use of its features. And, unlike your date of birth or your mother’s maiden name, if you get tired of your key, lose your key or it is somehow stolen, you can just disavow the old key and create a new key.
Sharing one’s key — the right way
In order to share this new tool of identity with the world, one’s secret key is able to make a public key.
Despite the changed shape, nothing has actually changed with my secret key, the extra bump is just there to show the relationship.
So, we know that the Secret Key can encrypt data and decrypt data. What can the Public key do? The Public Key can encrypt data (but not decrypt) and it can verify the Secret Key from which it was created. What it can’t do is be reverse engineered to recreate the Private Key. So, since it can’t decrypt information or be forced to recreate the private key, we can feel pretty comfortable letting it float around.
How would we use it in practice?
Let’s say I wanted to communicate with Ryan securely. I could simply encrypt the message using his Public Key. Where would I get his public key? Perhaps from his namecard or website. He could even email it to me in the clear.
If someone were in the middle intercepting my message, all they would get is the black block of encrypted text. Only when Ryan ran the block through his Secret Key will he see the highly sensitive message.
But, if I wanted to decrypt that message later to see what I had said, I would be completely blocked out. After all, I do not have Ryan’s Secret Key and his Public Key is unable to decrypt the message for anyone (even Ryan).
The solution is to use my Secret Key with Ryan’s Public Key during encryption:
Now, Ryan can decrypt the message and so can I.
But, unless the message contains some hints as to my identity (which could be spoofed), he might not be entirely sure about whether it was really me who sent it. His computer or phone would have no confidence of my identity whatsoever.
By adding my Public Key to the process:
Ryan’s program can use my Public Key to be certain of my identity. Also, it is convenient for when he wants to carry on the conversation in the other direction.
So, now we have all the building blocks for establishing a unique identity, encrypting a sensitive message, ensuring that only the sender and intended recipient can read it and a method for the recipient to feel confident about the identity of the sender.
But that is only half of the puzzle. The other half is managing the devices that form our web of secure identity. Unlike the traditional model where our birthday, SS# and mother’s maiden name remain unchanged, we need to account for the fact that we are very unlikely to have the same cellphone for more than a few years, that our hard drive may crash on our laptop or that we may just lose a device and with it: the secret key.
Permissioning devices
When you first unbox a cell phone, you are required to set it up with information, pin codes, fingerprints and other personal information so that the machine can calculate up some private keys. The phone itself has a unique identifying number and a phone number (on a SIM or set up by the service provider) so it can call and be called. Once done, the cellphone can act as your agent. And one of the functions of your new agent is to permission other devices. There are a variety of schemes for this permissioning but the result is the same: a web of devices which have a hierarchy of relationship that can be used to uniquely identify you individually and as a group. And those devices are not necessarily physical. Have you noticed that some websites allow you to log in with your Facebook and/or LinkedIn credentials? Each time you do so, you add to the web of identity and make it harder for others to pretend to be you.
If you think this sounds strange, borrow your spouse’s or child’s car the next time you meet up with old friends. You will get strange looks at first because even though you did not change your face, hair or even your clothes, stepping out of the “wrong” car causes a moment of doubt as to your identity.
That web of identity not only makes multi-factor identity possible (the idea that multiple sources make for a more secure identification…think 100 points of ID) but it also allows for the loss and replacement of devices. Dropped your phone in the lake while fishing? No problem, get your laptop to permission and verify the replacement phone you bought on the way home.
Building Graphs
As we interact with our devices (which can be physical or virtual like Facebook), we build up patterns of behavior which are thought of as graphs. We have social graphs of our friends and recommendations of restaurants on Yelp, we have financial graphs created by our earning, spending and investing, we have health graphs created by our doctors visits, lab tests and Fitbit and so on.
Does this sound too creepy or far off in the future? Well, the credit card companies have been doing this for years. They compare not only the credentials that you just handed the grocery store clerk (ie. your credit card) but a behavioral graph of likely stores you frequent. When my sister bought $600 worth of groceries several hundred miles from Manhattan, the credit card verification system threw up a red flag. Because her cell phone number was a “permissioned device” attached to the account, the computer sent a query by SMS asking her if she was buying $600 worth of groceries in deepest, darkest Maine while the cash register flashed “processing”. As soon as she responded “Y”, the cash register processed the sale. In the olden days, the cashier would have had to call a number and maybe hand over the phone to speak to a person while everyone piled up in line…the technology has improved but the idea is not a new one.
Transitioning to and Managing the Device Identity Model
The ability to adopt the new model is driven by the amount of processing and networking power we can stuff in our pockets, purses and backpacks. In the not too distant past, it was impractical to ask average consumers, retailers, patients, doctors and others to be full custodians of their identity in the same secure fashion as financial institutions shifting billions of dollars of transactions between each other every day (using SWIFT and Hardware Security Modules). That’s why we were handed documents that could be counterfeited (from international spies to 17 year old bar hoppers), debit/credit cards that could be quickly and efficiently duplicated and assured that we could secure it all with information that was either well distributed or easily googled (Ancestry.com for a mother’s maiden name?) and a couple of passwords (Password123, anyone?) or PIN numbers (1234, perhaps?).
It will take time to transition everyone from the old ways to the new because the value is still overwhelmingly in the old system (even after accounting for the expense of fraud). Institutions will have to redesign their operations to accommodate the device identity model as well. But in the not too distant future, the idea of typing your credit card details into a webpage or showing someone a laminated driver’s license will seem as quaint as rotary dial phones.
Of course the real reason to push the change is because of the other possibilities which open up. Once we have secure control of our identity and data, there is no reason why we cannot exercise controls over how information about us (financial, health, social, location etc) is gathered, stored and shared. Now that the right pieces in place, new relationships between persons (human, corporate and government entities) can be built.
The third and final post will look at how we can use encryption, the device identity model and signature chains to manage complex interactions with our data and third parties. The changes should be even more dramatic than those which followed the switch from bank tellers to ATMs.
