« March 2008 | Main | May 2008 »
Security Dr Seuss style (via Bruce)
On the serious side, it does appear that there might be some 'acceptability' issues. But considering some of the 'security' solutions that have been inflicted on unwilling users it is hardly beyond imagination.
We have all done it: we fill in a form on a Web site, we click OK and the Web site trashes all the information we just spent up to an hour working on.
Why do Web sites think that this is OK? This week I have filled in several web forms that required lengthy chunks of descriptive text that for some reason thought it was ok to just trash all my effort and repeat it because something was not exactly right.
Web browsers have remembered passwords for years. We have history files. But none of the major browsers can be configured to automatically keep track of all form data as it is entered. There is a Firefox form saver that allows you to elect to save a page and somewhat interestingly an experimental project that has been started by Ka-Ping Yee who folk in the security usability community know from his principles of usability.
Not trashing user effort should be considered a key usability requirement. But besides that I would like to have a permanent record of every form that I have entered at every site in a verifiable archive. While there might be people who would not want their activities to be tracked at certain sites this is already an issue with the history mechanism and something that can and should be fixed in any case. There should be a button that you can click to tell the browser not to track or record any interactions at that site.
We tend to think about the basic email operations as sending and receiving messages. From a security point of view however there is a problematic third category, the reply. In the last installment I had three reply tasks:
The problem with reply is that it it consists of (1) receiving a message, (2) generating a reply based on the message received. If the person making the reply makes a false assumption as to the origin of the original email the reply is likely to be one that was not intended.
Lets take the first example, replying to a message that purports to come from a company employee. Like any large organization, there are a large number of employees who do not know each other directly. And due to my job function, there are many people who contact me shortly after we make an acquisition. So quite often I will receive a message from someone who is (or considers themselves to be) quite senior who I have no direct knowledge of, asking me for information that could be commercially sensitive.
Current email clients do not meet the requirements of the first law 'sufficient information'. There is no way for me to know who sent the message with any degree of certainty. Anyone can forge a From header.
The problem for the new hire is even worse. As Shizzy demonstrated when he yanked the chain of a new Starbucks hire for several weeks while pretending to be the CEO. There is no way for a new hire to know that all internal mail comes from the starbucks.com domain and that they should consider messages from the starbucks-inc.com domain to be fraudulent.
And Outlook makes the problem even worse by hiding the DNS email addresses from the user completely so they don't know the address they are responding to. The reason for this remarkable design choice is that Outlook was originally designed as an X.400 mail client and X.400 mail addresses are inordinately long so displaying them to the user would take up a lot of screen real-estate. Outlook is not the only desktop mail client to do this, but it is the only one I have used that does not provide the option to display the full RFC821 email address.
So when replying to an email we are replying blind. The only information we have in the display is information that is untrustworthy. The only information that is trustworthy is the DNS based RFC822 email address which is at best subject to a look alike attack, if not hidden completely.
All three tasks suffer as a result of this information deficiency in ways that can easily lead to an attack, or worse, result in an inadvertent user error. Why is an inadvertent error worse than an attack? Because people make mistakes of their own accord far more often than someone attacks them. Since the 1950s there have been no significant terrorist attacks that have succeeded against nuclear power stations but there have been many incidents caused by operator error. As Ira Winkler keeps pointing out, the fact that a disaster occurred through a design flaw rather than an attack does not make it any better.
So what can go wrong?
I first saw an example of the last one when I sent a note to the original security architect at Netscape in 1994, pointing out that there was a problem with his approach to random number generation. In short, a pseudo-random number generator that only has 32 bits of ergodicity in the input cannot generate more that 32 bit of ergodicity in the output regardless of the number of bits the algorithm generates.
Various Netscape employees commented on the message in particular and the Web development taking place at CERN in uncomplimentary terms on an internal thread, all of which I received when the security architect forwarded his authorized reply. If I had circulated the message further it would have caused considerable damage to the relationship between Netscape (at that time a very small startup) and what became W3C.
The common thread in all these cases is that the user does not have the information necessary to complete the task securely in a trustworthy form. Worse still, the user is presented with untrustworthy information.
Some people have asked why I did not mention
john Markof's article on the email phishing scam where a fake subpoena was sent to executives of certain companies.
The answer is that I actually wrote the entry on Monday before the attack occurred and the scheduling robot posted it.
This particular attack appears to have originated from a group that specializes in bank fraud against company accounts. But now that the possibilities of this particular vector have become apparent we will probably start to see similar attacks with a corporate espionage motive.
With RSA over, its back to thinking about security usability and in particular email security usability. When I wrote the dotCrime Manifesto, I began by saying that there is more to security than just cryptography. Then I described a proposal for making email more usable that was essentially pure cryptography, albeit cryptography that was much better hidden than in the past.
The value of applying the task based analysis is that it has exposed a number of security issues that have absolutely nothing to do with cryptography and lead to far more real world problems than actual cryptanalytic attacks do today.
One thing I discovered when working on the task analysis is that it is pretty hard to do by thinking about it. I remain skeptical as to the value of small-n studies in the evaluation of the design itself, but I do think that they are likely to prove useful in building up the set of tasks.
So here are the tasks that I performed with email yesterday:
I suspect that these are pretty typical. But as I will discuss in the next installment, the current email clients do not give me sufficient information to complete these tasks securely without the user engaging in an unreasonable degree of effort.
During RSA I was using Twitter at the request of the organizers of the blogger event. Outside conferences twitter seems to me to be the most monumental time sink I can imagine. I have turned it off on my work machines.
Twitter is essentially a variation on IRC or Jabber that can be forwarded over SMS. The cell phone thing seems to me to be a step too far. Each user has a log to which they post 'tweets' of up to 140 characters to. People can follow other people's twitter logs. A suprising number of logs consist of 'what is the purpose of twitter'. Its one of those zen things I suppose.
So now Andrew Baron is auctioning off his Twitter handle on Ebay, which has raised many blogger's eyebrows including Chris Brogan who asked whether someone is going to buy it. Brogan asks the wrong question of course, the bid price is already $1520 and it is arguably a lot more valuable than a Hail Mary cheese toastie. But what he is really pointing out is that his 1600 followers can melt away rather quickly.
At close to $1 per follower, the handle is certainly highly priced even by dotcom standards. There might be 1600 eyeballs but I can't imagine that many of them would stay long if there was an attempt to monetize them by spamming them with Viagra ads. And while 1600 followers is quite a lot on Twitter, it is hardly enough to bootstrap some other project.
While I am in the San Francisco Mosconne, the protest against the Olympic torch relay is being synchronized using a twitter feed.
People have a way of applying new technologies in interesting and unanticipated ways.
Whitfield Diffie kicks off and urges us to be cautious of the claims that imminent cyberwarfare requires us to surrender civil society. We cannot meet these threats through cryptography alone
Marty Hellman, warns us about complacency, in particular the fact that humans are very bad at estimating the risk of low probability events. He is currently working on nuclear deterence.
Ron Rivest, re-interprets the Turing test in terms of cryptography. Interesting. He will be entering the NIST contest with an MD6. Also voting, cryptography is relevant to provide end to end security. Has a paper coming with David Chaum. Also on the standards body for setting acceptance criteria for voting machines.
Systems to be software independent. A system is software dependent if a bug or defect can cause the outcome to be affected. So the counter to this is a paper trail or whatever. He would like people in the room to comment on the necessity of this to the Electoral System Commission.
Shamir, progress in breaking SHA-1. The complexity is now 2^60 which is within reach of a distributed crack program. There is a group trying to do this but they have only a few % of the necessary computing power.
Intel has announced it is to put AES in hardware on their cpus from 2009. There will be 4 instructions for doing this. [hey this will make cracker's more efficient as well!] Mention of the bypassing of disk encryption by rebooting with a different O/S and looking at the memory. Will be good to see the end of encryption in software.
On Blu-Ray vs HD-DVD. a rumor Warner might have tipped to Blu Ray because the system has a means of introducing a new security system after the original one was cracked. So maybe security caused the tipping function.
Burt: How about software independent cyber security. Rivest, hard, Whitt need an existence proof, had one for voting for millennia.
Burt: How can we predict the probability of algorithm failure? Marty, we tend to treat cryptography as a Maginot line, algorithm security not the issue. Mentions Kocher's side channel attacks. Need to have a plan-B, what happens with your breaking of a 128-bit system?
Shamir, points out that main losses are very large losses from high level attacks and from very low level attacks. But the media tends to concentrate on the middle attacks that are not very common. Need to focus on stopping the low and the middle, not get distracted by the rare high level attack.
Burt: who has the capability to act, people, government. Whitt, lots of people talk about security education, comes from an era when people were told about security process. Mcrosoft correctly deduced that first to market was more important than security. Points out that Sun has a chip with the whole of Suite B implemented. Shamir, Intel sells more CPUs than sun, Whitt whose execute more CPU cycles per sec at the major Web sites. Need to have a design and development strategy that is transparent and tells us that something does what it claims without anything hidden. Rivest, Ken Thompson, what if the Intel chip keeps a copy of your AES key...
Marty: What happens if someone crashes the ATM system, how do you recover. A massive low level attack can become a high level attack.
Rivest: like a botnet.
Marty: Which comes to the war issue, Estonia was targeted in a DDoS attack.
Shamir: Its a media level attack, a lot of press, little effect
Marty: Their banking system was out of action for a week. What if it was a Russian attack, would NATO be obliged to come to their aid?
Shamir: Since we got to politics, does all this advice the US gives to companies apply to the US govt.? Does not seem to, US used to be very easy to visit. Last week NYT published story that Chertoff wants to upgrade fingerprint system to ten fingers rather than 2 at a cost of $300 million. The current system has caught 2000 people overstaying their visa. The upgrade might catch another guy (very expensive). Is anyone looking at the risk reward? On visiting, US has always asked strange questions, used to be are you a communist, now are you trained to operate nuclear weapons. Should asked, are you bad? very bad? extremely bad?
Burt: Where would you put your research time if you were starting now.
Rivest: What sort of world do you want to live in? what is the framework? Not clear that we have articulated.
Whitt: Genetic engineering, potential to change the world, won't be human beings discussing here in the next century. What will cause most upset is first child that is the genetic product of two women, will prove that men are unnecessary.
Burt: That is very interesting
Whitt: Code for I won't be invited back
Burt: We have invited you back many years.
Marty: If we planned for email security and embedded it in all the clients that would be very good for privacy but would remove the information we have on terrorists.
Burt: Closing remarks, what would you like to be remembered for?
Whitt: Maybe liked to be remembered. Most important development of late 20th century was client-server computing. Security was a mess, to secure something you put the salary computer on its own machine and secured that. The biggest impact may be something similar, unexpected, may take younger and smarter people.
Marty: Expect the unexpected, both negatively (attacks) and positively (upside)
Rivest: I think taht cryptography is still at its early stages.
Whitt: Yes, but if the rest of information security was as well baked
Rivest: Still a lot to be done, lot of things outside the field of crypto. Still do not have a secure platform. Other big problem user interfaces
Shamir: Security is basically ok, we adapt and survive and produce necessary tools. We should develop new kinds of techniques, we need kind of a GPS for data. One way to do it would be 160SHA1 summaries of your data. Talking about unauthorized data, data on USB drives and such.
Burt: We have some minutes, key sizes, how long for RSA 1024
Shamir: Keep suggesting 1 year, perhaps 5.
Hellman: Watched key sizes for RSA going up and up, ECC looks a lot better.
Rivest: Can predict a lot of things, the number field sieve but its the low probability math attack that you cannot predict.
This is the first post Gates RSA conference. Craig Mundie is taking the Microsoft keynote. This year's slogan is 'End to End Trust'. Looks like we will be hearing about Trustworthy Computing. He is doing a tag team with Chris Leach from affiliated security.
They are discussing the tension between security and privacy. With medical records of course we need security to guarantee the privacy.
Now discussing the change in the approach to security at Microsoft, management and process issues.
So finally we get to the technology, the 5 layer 'trusted security stack'. Device has to be trusted, Trusted version of the operating system,, applications have to be trusted as well, trusted processes for managing people, finally trusted data, (Yep, its orange book).
There is a whitepaper.
Of course maybe I should not expect to see much new here given that I just wrote a book on the subject.
Mentioning their research work, putting noise into a data set to prevent identification of individuals. Thus making data sharing easier.
Ah now there is something interesting, using Credentia technology in combination with CardSpace. But its a long road.
I don't know if VeriSign bloggers are meant to comment on each other's blogs, but Branden Williams makes many interesting points about credit card security in his Security Convergence Blog, and one in particular that I want to pick up on:
Uhh... what? Chip & PIN is the new Holy Grail of secure card acceptance? Last I checked, it slows down the bad guys, but does not stop them. There are flaws in that system as well. Besides, you have an issue with Chip & PIN in the US... acceptance! What good is a reader if no one carries the card to use them!
The economics of Internet crime has been a major consideration in the security world for many years. The criminals are looking to make money. Professional criminals are not interested in unprofitable crimes. What is beginning to be looked at is the economics of deploying security countermeasures. I wrote two chapters on this issue in my book, The dotCrime Manifesto. Adam and Andrew also consider it in their book, The New School.
At one level this is not a new issue, banks are always going to look at the economics of any security product and demand a return. But we have only recently begun to understand that of the two major problems Branden identifies with Chip and PIN deployment in the US, the technical issue is the easy part, it is establishing an economic case for deployment that is hard.
Fixing the problems identified by Ross Anderson and his colleagues is simple, just implement the encryption protocol already supported in the standard. But fixing the economic case is hard. American Express has been issuing 'Blue' cards with embedded smart chips for years. I have never once seen a reader in a US store.
Deployment of Chip and PIN is probably in the interests of every party in the credit card system, or can be made so with appropriate adjustment of charges, etc. Merchants need to be compensated for the cost of new reader terminals if the direct benefit is going to fall on the banks. Card issuers have to be compensated for the cost of the chips if the direct benefits are going to be seen by the merchants and the card acquirers.
Getting this to happen in the US is not impossible, but it will take executive branch commitment to make it happen. Until recently the prospects for this have appeared remote. Internet crime is a serious problem, but terrorism and other foreign relations issues are bigger problems. But as many of us have predicted for years, Internet crime is becoming a terrorist issue and a foreign policy issue. The risk of a life threatening Internet crime attack remains very low, the risk that terrorists might use a spot of phishing fraud to buy weapons and explosives to kill people is very high.
On the foreign relations side, there are very worrying signs that certain states have been developing a cyber-warfare capability with the intention of using it as a low intensity warfare alternative to outright war in much the same way that certain states employed terrorism in the 1970s. In some cases development of this capability has been outsourced to Internet criminal gangs.
Microsoft Dreamspark" makes free copies of the full (not demo, restricted or time limited) Professional edition of Visual Studio available to college students .
While Microsoft has been giving copies of developer tools to college students for years, the Dreamspark program is rather interesting because of the identity eco-system that it is built on. All a college needs to do to become part of the program is to set up a Shiboleth identity server to provide students with a credential to tell the Microsoft stie that they are a bona-fide student.
Shiboleth is an open system based on SAML that was originally built to support inter-library loans. Microsoft are re-using the infrastructure for their program. This is the really important event. People build one-off infrastructures designed to serve a single purpose all the time. Rather less frequent is the case where an architecture designed to serve multiple purposes is actually applied beyond the original niche.
It another sign that Identity 2.0 is statring to take hold. What matters much less than the protocol employed is the social infrastructure. In particular the understanding that identity management is not something that the content provider should control but something that the user who is asserting their identity must control.
Let us imagine that the first car you buy has an idiosyncratic set of controls. The left turn signal is on a stalk to the right of the steering wheel, the right turn signal is a knob on the dashboard that looks like a cigarette lighter. all the controls are this way, mislabeled, inconsistent. You simply don't have a chance. To make sure that your confusion is complete the mechanics rearrange the controls each time you take the car in for service (and as you can imagine, a machine built this way probably requires a LOT of service).
Now you go for a test drive of a different model in the showroom. This car has been designed for Steve Jobs by Jakob Nielsen and Donald Norman. Every control is laid out logically and consistently.
Question is, will you find the new car any more usable than the old one in a 30 minute test drive?
I think not. The underlying problem here is confusion. If you have been exposed to a confusing, illogical user interface for years, you are not going to become any less confused in a half hour or so. In particular it takes much more than 30 minutes to get to the point where you can start to expect a rational outcome.
And this is one reason why I am very skeptical of using standard usability testing approaches to test security usability. Every computer user has learned over the course of many years that most security warnings can be ignored, that virtually no Internet interaction has negative consequences. If you try to measure the performance of a new security tool you are going to end up measuring the confusion they brought into the room with them.
The test that matters is whether a security usability measure will result in the long term changes in user behavior that have the potential to provide a real reduction in risk.
