Usable Security

I attended the Boalt Tech Law Journal’s Spyware conference last week (http://www.law.berkeley.edu/institutes/bclt/spyware/about.html), and one of the more pessimistic statements made (by Susan Crawford - http://scrawford.net/page.php?display=contact) was that “we’re not going to win” - that even when the law catches up to spyware and phishing scams and allows for more effective prosecution, ultimately the legal system won’t solve these problems.

I’m interested in discussing from a usability and engineering perspective what measures might make a difference in combating these menaces. These scams exploit weaknesses in how many users fundamentally understand (or misunderstand) the Internet or software generally, and thus offer a substantial challenge for designers.

Using encrypted e-mail is part of what got me really interested in HCISEC. Aside from the sorts of things discussed in “Why Johnny Can’t Encrypt”, I came upon a handful of other issues as I was trying to use encrypted mail.

There was a period of time where I was using PGP to encrypt all of my e-mail messages, as even without an integrated client it isn’t *that* hard to do if you’re a bit tech savy. During this period I encountered a few major HCI issues that are probably a bit more towards the psychology of security than CompSci proper, but they clearly affect the security of the whole notion:

- You really do need some kind of PKI to make encrypted mail work properly, at least insofar as authentication goes. The problem here is that ANYBODY can create a new PGP key and claim to be “Richard M. Conlan” and publish it to the keyserver. This leads to three major problems:

1) Anybody doing a search for “Richard M. Conlan” is now at least as
apt to find this new key as to find MY key (in fact, maybe moreso
since the imposter key will be more recent), and unless there is
some official way to distinguish the two I would have just as little
ground as the imposter to prove that my key is the real key. Even if
I could do so on an individual basis, that assumes that people think
to question the validity of the key in the first place.

2) The imposter could use this key to sign other keys, which would
create the impression that I had actually signed keys that I hadn’t
and may harm my reputation in that regard.

3) Really, ANYTHING signed by the imposter would appear to be signed
by me and the burden of proof might shift to me to prove that the
key in question ISN’T my key…just because it contains my name
and most people who understand the CONCEPT of digital signatures
might not think too much about the question of the security of key
creation and distribution.

- Just signing the body of the message can cause some major problems. One of my friends demonstrated this by cutting & pasting the body of my e-mail into another e-mail sent to somebody else. Because encrypting the body of the e-mail does not contain any information about the CONTEXT or the intended recipient, this created a situation in which it appeared I had sent a non-repudiatable message to this third-party when I had not. This could be an especial problem if I signed an e-mail saying something like “You suck!” and it got forwarded on to somebody important…say my boss. I would have to try and explain that I hadn’t sent him a signed e-mail when he could easily verify the body and see it was my signature.

- My partial solution to the above was to manually include the TO, FROM, SUBJECT, and DATE lines in the body of the e-mail so that they would be inherent in the signed message. However, even this doesn’t get around the problem that there are situations where it is important for me to be able to confirm to person X I said something but where I do not want them to be able to turn around and prove to person Y that I said it. For instance, I may want to prove my identity for the purposes of a vote, but not want the vote tabulator to be able to turn around and prove that I voted a particular way. This is a problem with most digital signature schemes I am aware of because signatures tend to imply arbitrary non-repudiation.

- There is a danger to a partial understanding of digital signatures. In particular, many people might get the idea just enough to know that there tends to be a block of gobbly-gook appended to the end of signed messages and that through some magick mechanism that block validates the contents of the e-mail. These creates a danger that people who don’t take the time to validate the content of the message will just ASSUME it is valid because there is a block of gibberish at the end. The ramifications of this are pretty scary - it renders the digital signatures themselves somewhat useless in practical usage because if people just assume anything with a gibberish block MUST have been signed by the person in question then it lends automatic authority to an attacker that might not have been there otherwise.

So…I stopped using digital signatures. The encryption side of things is still pretty sweet…except that that is the side that requires the recipient to be playing the game too. Hence, I am back to plaintext e-mails for the time being, and just keep wishing for a more comprehensively designed system. Anybody want to help me build one?