Analyzing Trust in Hushmail

Recently, law enforcement acquired confidential email messages from the so-called secure email service, Hushmail. Law enforcement exploited weaknesses in trust relationships to steal the passwords for secret keys which were then used to decrypt the confidential messages.

There are some lessons from this.

#1. Law enforcement trumps. This is not necessarily a lesson in Trust, per se, but keep in mind that large institutions have extensive resources and can be very persuasive, whether it is persuasion from threat of force or financial loss. Possibly an extremely well funded service (read: expensive) in a country that refuses to comply with US laws and policies (e.g. extradition) could keep messages secret (hence the proverbial Swiss bank account). There are definitely economic incentives to understand in evaluating the overall security of Hushmail's (or a similar service's) solution.

#2. A service like Hushmail, which sits in the middle as a broker for all of your message routing and (at least temporary) storage, is part of the Trusted Path between sender and receiver. Hushmail attempts to limit the scope of what is trusted by employing techniques that prevent their access to the messages, such as encrypting the messages on the client side using a java agent or only storing the passphrases temporarily when encrypting messages on the server side.

A user trusts that Hushmail won't change their passphrase storage from hashed (unknown to Hushmail) to plaintext (known to Hushmail) when the user uses the server side encryption option. A user also trusts that the java applet hasn't changed from the version where strong encryption of the messages happens on the client side without divulging either a copy of the message or the keys to Hushmail. The source code is available, but there is not much to guarantee that the published java applet has not changed. The average, non-technical user will have no clue, since the entire process is visual. Hushmail could easily publish a signed, malicious version of the java applet. There is no human-computer interface that can help the user make a valid trust decision.

#3. The Trusted Path also includes many other components: the user's browser (or browser rootkits), the OS and hardware (and all of the problematic components thereof), the network (including DNS and ARP), and last but not least, the social aspect (people who have access to the user). There are many opportunities to find the weakest link in the chain of trust, that do not involve exploiting weaknesses of the service provider. Old fashioned, face-to-face message exchanges may have a shorter trusted path than a distributed, asynchronous electronic communication system with confidentiality controls built-in (i.e. Hushmail's email). And don't forget Schneier's realism of cryptographic execution:

"The problem is that while a digital signature authenticates the document up to the point of the signing computer, it doesn't authenticate the link between that computer and Alice. This is a subtle point. For years, I would explain the mathematics of digital signatures with sentences like: 'The signer computes a digital signature of message m by computing m^e mod n.' This is complete nonsense. I have digitally signed thousands of electronic documents, and I have never computed m^e mod n in my entire life. My computer makes that calculation. I am not signing anything; my computer is."

#4. Services like Hushmail collect large quantities of encrypted messages, so they are a treasure trove to adversaries. Another economic aspect in the overall trust analysis is that the majority of web-based email service users do not demand these features. So the subset of users who do require extra measures for confidentiality can be easily singled out, regardless of whether the messages will implicate the users in illegal activity (or otherwise meaningful activity to some other form of adversary). And, at a minimum, there is always Traffic Analysis, where relationships can be deduced if email addresses can be linked to individuals. An adversary may not need to know what is sent, so long as something is sent with extra confidential messages.


To sum up, if you expect to conduct illegal or even highly-competitive activity through third-party "private" email services, you're optimistic at best or stupid at worst.