So, I've been reading this article this morning on how the US "private and public" institutions are going to revolutionize the way we authenticate on the web. The "ground breaking" idea, also illustrated on this NIST animation, is to use 3rd party authorities that would first verify your identity somehow ("Can we see your id?", "What is your Mam's maiden name?", etc), and then would issue you some kind of a token that you would later use for authentication on the web. A token would be e.g. a smart card, or a USB stick (probably they just mean a smart card with USB connector, whatever), or even a "phone application".
The idea is that the user will not have to "remember" all those passwords for all the various websites, which apparently is a problem in practice, because most users never heard about password manager apps, and so they actually try to remember all those passwords, or even try to use the same one all over the place. Using one password for more than one website is obviously wrong and people should be told not to do that. But an easy way to solve this is to just get people to use password managers.
But the key problem that they try to solve, which is identity theft, is just not gonna be solved by this "password revolution". This is because if somebody has compromised my laptop, then it really doesn't matter if I use passwords, or smart cards, or whatever other multi-factor authentication mechanism -- none of them will help if the attacker controls my operating system.
Most people cannot just get it -- this is because they lack understanding of how computers and operating systems work. They don't understand that the operating system can impersonate the user at will! This is because the operating system fully controls the keyboard, the mouse, and the screen.
So, imagine you use your super-secure smart card token for authentication to your bank. So, before you log into your bank account, and perhaps before you make any transaction on the banking website, you must insert your smart card somewhere (e.g. into smart card reader, or into USB port, etc). Before you insert your token, no one can impersonate you on the bank website. So far, so good! But then, once you inserted your token, it's all lost! The compromised OS could have saved your PIN to this card when you used it previously (even if you configured it not to do so!) and now, immediately, it could use the inserted card to authenticate as you to the bank and start issuing transactions on your behalf. And you won't even notice this all, because in the meantime it will show you a faked screen of your banking account. After all, it fully controls the screen.
The bottom line is that we cannot secure our digital lives, if our client operating systems could not be secured first. And today, the operating systems we use on our laptops, such as Windows, or Mac, or Ubuntu, are just trivial to be compromised by the attackers. After all, if that wasn't true we wouldn't have all those problems with identity theft. But introduction of tokens won't make our operating systems any more secure!
What we need instead are technologies that allow to build next-generation trusted operating systems. Technologies such as Intel TXT or VT-d. And we need OS vendors to actually start using them.
You can say I'm biased, because of our work on Qubes OS. But then, consider this -- perhaps we would never invest so much money and resources into this project, if we believed there are other ways to bring security to our digital life.
Saturday, April 16, 2011
Subscribe to:
Post Comments (Atom)
22 comments:
Until we have all those secure OS's, what's actually so secure about password managers ? It seems like it's only moving the problem from one place to another ?
Passwords manages do help a little bit even if we have insure client OSes -- because they allow to easily avoid using the same password for different services, which is good for many reasons (e.g. if one website gets compromised, the attacker doesn't automatically gain the victim's access to other services).
But, generally, you're asking a wrong question! You should really be asking: Until we have secure client OSes, what's actually so secure about smart cards?
The way this problem (could) be solved is a secure (external) smartcard terminal with it's own pin interface. The 'host' computer never sees the PIN...
This means that you only need to worry about securing the card reader - much simpler than a modern operating system.
"we cannot secure our digital lives, if our client operating systems could not be secured first."
In a sense, we can. All we need is separate the general purpose OS from the OS that is handling secure transactions for us. The latter, being limited in functionality, can be made reasonably secure with reasonable cost/effort.
In other words, we need a "smartcard" that has a display and "Commit"/"Cancel" buttons. The display will show us the request that we are signing, and, as long as we can trust that the card itself stays secure, we can stop bothering about possible MitM trojans lurking in our general-purpose OS.
Otherwise, great article. Too many people (and, worse, security vendors!) are ignoring the issue that you have highlighted.
Moving the PIN entry keypad from your host to the smart card reader really doesn't solve anything!
The compromised OS must just wait until the user enters the PIN on this secure keypad (well, the user will make use of the smart card from time to time, right) and then the OS can request the smart card to do whatever it wants, e.g. sign some unauthorized transaction, no matter what the actual user's intention was!
Adding a "little" screen to the card reader might seem like a good idea, but only in theory. How much info would it need to display on this "little" screen to assure the user that the transaction the smart card is about to sign is indeed the same that the user intended?
With banking it might be simple (although how would a user know the target account is really what he intended -- the list of accounts displayed on the computer screen could be faked, obviously), but what about signing e.g. a document? The smart card reader would need to display you the whole document that you're signing. Oh, sure, we can built in a "little" PDF viewer into the smart card reader, why not!
I hope it's clear how this is becoming a nonsense -- we must now build another universal computer, this time on the smart card reader, so that the user always know what they are singing/authorizing. Despite the fact it wouldn't make any sense from the economical point of view, why do you think such smart card would not be prone to compromises just like our current desktop OSes or smartphones are?
"Adding a "little" screen to the card reader might seem like a good idea, but only in theory." ... "I hope it's clear how this is becoming a nonsense".
For general purpose transactions, I agree. For monetary transactions, why not? Seeing the amount of money, and some sort of verifiable identification of the recipient would be of great help.
For example, verifiable identification could be an account number that you can match against a paper invoice, a NASDAQ ticker, a well-known domain name.
Looks like the most promising path to me. Albeit far from trivial.
"Paper invoices"? Are you kidding me? Most couturiers are moving away from using paper invoices and adopt electronic ones, e.g. PDFs send via email.
In any cases, the idea with a "small screen" on the smart card keypad will never work because it would have to be too-application-specific.
The proper way to go is to secure our client OSes. Period.
So far, the comments have been about devices hooked up to the computer. But what's your take on external card readers (not hooked up to the comp) that generate one time passwords?
Of course the solution suggested by the US gov raises a whole slew of new problems:
- what will the requirements be to authenticate the owner of the card?
- who will do the authentication?
- how will the cards be transported to the users and who can pick them up?
- how will lost/stolen cards be handled?
- will Americans ever "trust" a federated PKI system? :)
@csaba_s: One time password generators/lists do not change anything.
If your laptop is compromised you don't control what transaction you authorize. On your screen you might be seeing: "Enter password #21 from the list to authorize this transaction for electricity bill", but in fact you might authorizing a whole different transaction!
I agree with Joanna in that with a sufficiently compromised OS, all bets are off. Just look at some of the recent thefts of funds from small to medium organizations:
http://krebsonsecurity.com/category/smallbizvictims/
http://krebsonsecurity.com/wp-content/uploads/2010/04/ebankvictims.jpg
These victims had their banking credentials stolen while they were online via a compromised machine. The stolen credentials were used to send wire transfers to money mules who went the money on to foreign countries. In at least one occasion, the wire transfers were done while the individual was still online. In the case of the money transfers being done while the user was still online, RSA SecureID would not have helped since the login was already authenticated. I haven't looked at Qubes yet, but the best solution currently is to use a Linux boot CD and do banking transactions that way.
Joanna is right, the best way of doing this is to use Trusted Computing. However, there's different way of doing this with TC.
Image a very limited operating system which can only be used to verify some info (e.g. transactions information using some sort of parser (image XML)) and sign them with some sealed keys (i.e. for those not used to trusted computing terms, to put it simple, *seal* means data that can only be accessed if running the proper system (e.g. boot loader, hypervisor, *verificationOS*, document parser, etc)). This system would have very few lines of code and a high degree of confidence (i.e. it must be easily understood and verified - hard to get wrong).
When a secure transaction is required on a standard operating system, the information regarding the transaction would need to be signed by the sealed key in order to be accepted by the transaction server. This key could only be read by the *verificationOS* since it is sealed. Now whatever was on the untrusted operating system doesn't really matter since it has no control what so ever on the *verificationOS* (TXT/VT-d).
Sure it’s another model with its own constraints but it’s still possible. I believe Qubes OS could very easily integrate such things with its current model.
A big part of the industry (OTP, smartcard, etc) is just plain wrong and some corporations are presently integrating -Bring Your Own Laptop-and -Remote Users using their own unsecure system- simply by using OTP devices. This will only force identify thief to move from passive (i.e. keylogger) to active attacks. Oh wait it’s already the done… http://www.technologyreview.com/computing/23488/page1/
What do you think? Comments/insults?
@Danny: The model you propose is similar to ARM Trust Zone from what I understand it, and I also saw some proof-of-concept implementations for x86 using x86 (don't remember a project name ATM) -- i.e. an on-demant "pop up" OS being started from Windows or Linux.
Generally this should be somehow equivalent to the model of "smart card reader with little screen", that we discussed above in the comments -- just more cost-efficient and easier to use.
The main problem that still remains with such as micro-secure-popup-OS, is how much info it should display to the user? E.g. if I wanted to sign a PDF document with my TAX income declaration, then it would need to parse & display the whole PDF.
In Qubes we don't need this, because Qubes comprises of many such isolated OSes that we call domains -- so some of them we might just call "trusted" and use only for some trusted activities such as banking, or for preparing and signing TAX decclarations.
@Joanna: Thanks for the info! I'll take a look at the ‘trust zone’ stuff.
Yeah it’s easier to image with simple transactions but after all I guess it address different problems:
One advantage I see with the "micro-secure-popup-os" (i like the name you used) is the ability to provide a strong level of assurance to the server you are doing the transaction with (the actual server could be the one providing this OS). However, for sure, it's not a model which really helps end-users getting -real general usage security- to standard operating system since, as you mentioned, it would only be able to secure/externalize a finite sets of validation scenario. On the other hand, in Qubes the end-user can have a strong trust in his day-to-day usage for not being compromise while it's harder to prove to other parties.
@Danny: it would be easy to add e.g. TXT-based remote attestation to Qubes. We might even do that in the near future.
> A token would be e.g. a smart card, or a USB stick (probably they just mean a smart card with USB connector, whatever), or even a "phone application".
A minor point, but I believe nist/nstic was illustrating a smart card, rsa hardware token, and a phone app.
Avivah Litan at Garner has a nice comment on her blog about the new authentication recommendations that FFIEC is supposedly about to issue:
"Sure a smarter device identification or KBA system will be harder for these crooks to beat but they can still beat them and they will beat them just as soon as the banks upgrade from the simple dumb versions of these techniques to the complex smarter ones. The regulators need to take a look at what’s happened in other parts of the world as well as in the U.S., where just about every single type of user authentication and transaction verification (out of band or in band) method has been beaten. That’s not to say banks shouldn’t continue to strengthen these and other security layers – but it is to say that it’s dangerous to call out the strengthening of specific security layers and subtly imply that by doing so, this can rectify the ills of many current security systems."
The only way to do online banking securely, which is in all the FBI advisories so far, I think, is to use a dedicated, isolated system.
Since keepassx is included in the Qubes OS default AppVM template, I assume that is your recommended password manager. Do you use both a password and a key file to protect your kdb? If so, what protection do either offer? If your machine is compromised, neither help. Maybe it's part of a defense-in-depth strategy, so if the kdb happens to get off box you are protected.
Currently my password manager is a text file and has served me well. It's cross platform, extensible, available, reliable, and secured by the OS. In debating my upgrade to keepassx the primary advantage I see is integrated password generation. There seems to be no difference (other than some niceties) between keepassx and /home/me/password.txt (-rw-------). Of course, keepassx is way more vogue.
@Bruce: Correct the only advantage that a password manager offers over a simple text file is: 1) Password generator, 2) nice UI that e.g. allows for easy copy-to-clipboard of selected username/passwords.
Securing it your "vault" with a password/key files bring only an illusion of additional security -- if somebody compromised your machine (or VM) where you keep your files, they will be able to steal the passwords the next time you enter the password.
I use keepass because it runs on many platforms, and I have changed OSes several times in the past few years.
i have a feeling you put an 'equal' sign between 'stealing your computer' and 'cracking your password'. frankly, following this path i could say that anybody who stole my computer would as well gain the access to my bank account no matter i use password managers or not.
if all my passwords are scrambled and cannot be simply decrypted (i.e. not plain text), how can you assume anybody who stole your computer would also have access to all your credentials?
does 'knowing you have an account in bank X' mean same as 'knowing your balance'?
of course not.
@Chic: Save your _feelings_ to tourself, and stick to _logic_ when attempting to rebut my statements ;)
Full disk encryption is what should be responsible for protecting all your data in case somebody steal your laptop. Not password manager encryption.
In my opinion, the type of "security" the article promotes is purely designed to form/change the public perception and hide the reality. I love the way you crush such sick notions Joanna. Thanks.
Joanna - great blog post. Just a few thoughts.
ID theft is still mostly old fashioned at this point - mail fraud, dumpster diving, for eg.
Even if a secure password is chosen, there is one thing that will keep ID theft alive, and it's impossible to completely eliminate: the innate human desire to trust others. It is not feasible (or advisable) to completely eliminate that, even if we had a way to do so.
Unfortunately, con artists, thieves, and other societal parasites tear this societal fabric. Passwords can always be reset and security can always be bypassed. In geek-speak, we call this social engineering. We can also call this con artistry. Some people are such skilled natural liars that it is simply impossible to differentiate truth vs fiction from them (any of the "socially deviant" personality disorders, such as psychopathy, for eg).
I.e., technical perfection in the area of security--if possible--would not obviate ID theft, fraud, etc. But monitoring systems, legal deterrents, etc, can be fully utilized. Further, incentive structures (including economic) can be used as well to push the burden on companies w/ lax security (Sony, for eg, is experiencing this now due to their PSN hack).
"Security is hard," as one famous security guru is fond of saying.
Post a Comment