A few posts back I provided one of the simplest examples I could come up with for Information Centric Security. To recap, consider having a PGP plug-in to an email tool like Outlook or Eudora. The outbound email you send is encrypted with the receiver’s public key, and signed by your private key to ensure authenticity. Conversely inbound email is encrypted with your public key, digitally signed by the sender. Consider some of the advantages of this that a) your email is stored locally in a safe form, b) your email is reasonably safe in transit, c) you can verify the email came from the person on the ‘From’ line. There are certainly secondary advantages in filtering spam, not having to worry about lost backups, in transit alteration, and can still communicate with other non-secured persons and applications at the users discretion just as you do today.
I also wanted to discuss a slightly more complex example to illustrate how Information Centric Security can solve other problems.
Let’s say I am on my laptop at some coffee shop, using their 'secure' wireless hackspot. I want to buy a book, so I go to Amazon, or some such site. And they want to make this easy for me, the customer, to very quickly make my purchases with as little effort as possible. A very easy process as I simply select a book after browsing the site, choose my shipping and click ‘Give us $$$ right now’ button. They store my credit card whether I want them to or not, so no need for me to enter that data again after my first purchase. I assume that I am directly connected to the merchant and that the ‘HTTPS’ and little lock symbol means something. The vendor is a big, trustworthy company and does this type of thing all the time so I assume they must secure all of these credit card numbers, right? And from the Identity perspective, the vendor is pretty sure I am me. No password required, because the cookie on my machine told them I was me and cookies don’t lie.
What don’t I like about this? I don’t like the merchant storing my credit card number. There really is no good reason for them to have it to clear payment, and so it invites liability to store it. I don’t like that there is no password required. Even if they did want a password, given I am using my laptop at the hackspot, every piece of personal data passed across that link can be accessed in an man-in-the-middle attack.
Let’s take a quick look at this from a packetized or object data model. Let’s assume that the process is the same … I go to my WiFi spot, select a book, click checkout, and authorize the payment. But this time there will be a couple small differences. The first is that I am using a small tool kit that can encrypt or provide a digital signature (or both) to certain objects on my machine, and while I would not necessarily have it as a browser plug-in, but for simplicity, let’s say that is what it is. In this case, when I get my book order confirmation, I am going to be sent an electronic purchase order from the merchant. It will contain a short description of the purchase, a purchase Id, merchant Id, and amount, a timestamp and a customer Id. I will pull my credit card from the secure tool kit, append that credit card number which has been encrypted with the public key of the credit card processor, and digitally sign the entire PO. I then return the entire blob back to the merchant.
The merchant will pass a copy of this back to the payment processor who will decrypt the credit card number, and verify the number belongs to the user who signed the PO. They can then send some form of acknowledgment back to the vendor to verify the user was the owner of the credit card, and that the payment has been approved. Merchant sends me back an order confirmation and the process is complete. A remediation or dispute resolution is a simple process for the merchant that does not require a credit card number stored in the clear.
In this scenario the merchant can verify that I am me because of the digital signature, but I did not have to pass a password across the Internet. It keeps the merchant from trying to keep credit card numbers lying around, which is an advantage to everyone. It protects the merchant as it lessens the likelihood of replay attacks, forgeries, and the passwords or credit card numbers from being intercepted by a man-in-the-middle. It protects the user from the same issues. And as the toolkit can be used to store personal information on the laptop encrypted, reduces the possibility of the information being obtained during a physical theft.
As much of this can be automated by a local application, the user does not need to worry about all of the ugly details or be a cryptographic expert. This is almost zero change to the shopping experience, a small addition of code to the user and merchant sides, and a moderate change to the underlying payment clearing process. But it is my contention that this offers greater user & merchant security. But best of all, this could do away with the entire PCI Industry as we know it, reducing costs for the merchant and fraud for the merchant banks!
A perfect solution? Not even close. It opens up new attack vectors in key management and public key distribution, but these are more complicated, and more expensive, attacks. And I still have the problem that if someone gets my laptop, they can order whatever they like without my assistance. If they get a hold of the laptop, the only thing that keeps a thief from pretending to be me is a password. If they can now guess the password(s), and I am not using some form of n-factor authentication, it’s game over. But that is no different than what we have today. With this packetized data model, information is stored on the disk like keys, credit card numbers and other valuable data is encrypted and not accessible without passing access control requirements. And the vendor may have my credit card number, but that number is secured so that only the bank & I know what it is.
Thoughts? Questions? Character Assassinations? Feel free to chime in.
Comments