Poulsen, Kevin Wednesday, November 07, :54 PM Singel, Ryan FW: [hush.com # ] Journalist's query

Transcription

1 Singel, Ryan From: Sent: To: Subject: Poulsen, Kevin Wednesday, November 07, :54 PM Singel, Ryan FW: [hush.com # ] Journalist's query -----Original Message----- From: Brian Smith Sent: Wednesday, November 07, :40 PM To: Poulsen, Kevin Subject: RE: [hush.com # ] Journalist's query Hi Kevin, Sorry, I've been really busy the past couple of days. However, I've collected some info from our internal counsel that hopefully will make things a bit clearer. Like any company doing this sort of thing for a long time, we've had to deal with quite a few requests from law enforcement. In these situations, we always require that a court order be issued, and that court order must be issued by the Supreme Court of British Columbia. For such an order to be issued in respect of a request where the alleged offenses have not occurred in Canada, a formal request must be made to the government of Canada under an applicable Mutual Legal Assistance Treaty by the country in which the requesting law enforcement agency is located. Assuming the government of Canada accepts the request, or if the alleged offense has occurred in Canada, an application is then made by the Department of Justice to the Supreme Court of British Columbia for an order that Hush be required to provide certain information. That application must be supported by Affidavit evidence such that the presiding Judge determines that an offense has occurred and that Hush has evidence of same. We receive many requests for information from law enforcement authorities, including subpoenas, but on being made aware of the requirements, a large percentage of them do not proceed. To date, we have not challenged a court order in court, as we have made it clear that the court orders that we would accept must follow our guidelines of requiring only actions that can be limited to the specific user accounts named in the court order. That is to say, any sort of requirement for broad data collection would not be acceptable. There's been some discussion about Hushmail in this context on the web lately, and I think it's a healthy thing. There are situations where Hushmail is an appropriate tool and situations where is not. It is useful for avoiding general Carnivore-type government surveillance, and protecting your data from hackers, but definitely not suitable for protecting your data if you are engaging in illegal activity that could result in a Canadian court order. That's also backed up by the fact that all Hushmail users agree to our terms of service, which state that Hushmail is not to be used for illegal activity. However, when using Hushmail, users can be assured that no access to data, including server logs, etc., will be granted without a specific court order. Yes, you are right about the fact that view source is not going to reveal anything about the compiled Java code. However, it does reveal the HTML in which the applet is embedded, and whether the applet is actually being used at all. Anyway, I meant that just as an example. The general point is that it is potentially detectable by the end-user, even though it is not practical to perform this operation every time. This means that in Java mode the level of trust the user must place in us is somewhat reduced, although not eliminated. The extra security given by the Java applet is not particularly relevant, in the practical sense, if an individual account is targeted. However, it makes it less necessary to take us at our word when we say we do not do any broad collection of private user data. The issues with applet verification were pointed out by Schneier back when Hushmail originally came out. 1

2 Regards, Brian On Wed, 07 Nov :44: "Poulsen, Kevin" wrote: Hi Brian, I want to make sure you didn't send me a reply to this message that I missed. I think we're going to write up something on this issue. K -----Original Message----- From: Poulsen, Kevin Sent: Monday, November 05, :16 AM To: 'Brian Smith' Subject: RE: [hush.com # ] Journalist's query Speaking generally, and not specifically about the affidavit I sent you, it seems like if Hushmail can be compelled by legal process to actively capture a private key, you could also be compelled to send a user a modified version of your Java applet that would send the user's private key to Hushmail or a law enforcment agency. Unless I'm missing something, "view source" wouldn't help a user against this type of attack, since the tinkering would be done in the compiled Java code. Are you free to say whether you've been obliged to do this, and if so, how often. And have you challenged in court an order compelling the collection and production of private keys? Kevin Poulsen senior editor -- wired news office: mobile: klp@wired.com -----Original Message----- From: Brian Smith [mailto:sbs@hushmail.com] Sent: Monday, November 05, :53 AM To: Poulsen, Kevin Subject: RE: [hush.com # ] Journalist's query Kevin, Yes, you are right. That's why in the matrix on that help page it shows "Not protected" for "Attacker controls webserver while you are accessing your ". That actually goes for Java and non-java, with the difference being that in Java mode, what the attacker does is potentially detectable by the user (via view source in the browser). For this reason a web-based service is never going to reach the rigorous level of security of an entirely client-based solution like GnuPG. However, the attack required to get encrypted messages from Hushmail is significantly more difficult than simply recovering messages from a server hard drive. Brian 2

3 On Mon, 05 Nov :13: "Poulsen, Kevin" wrote: Thanks again Brian for your quick response. I just want to make sure I understand this correctly. Is the case of the non-java user, it sounds the only option available to an attacker would require that someone reconfigure your servers to store the user's private key during the brief time that it's unencrypted. In other words, if an attacker gains access to your servers they still can't access the content of my -- until I next log in. Then everything I've received, or subsequently receive, is compromised. K -----Original Message----- From: Brian Smith [mailto:sbs@hushmail.com] Sent: Monday, November 05, :38 AM To: Poulsen, Kevin Subject: RE: [hush.com # ] Journalist's query Hi Kevin, I can't comment specifically on the affidavit, but I can clear up your questions about the architecture. The only way to decrypt encrypted Hushmail messages stored on our servers is with the private keys associated with the senders and recipients of those messages, and the only way to access those private keys is with the associated passphrases. Since early 2006, Hushmail can run in a couple of different configurations, which provide different balances of usability and security. One uses a Java applet, one does not. These links give a pretty full explanation of the different levels of security between the two version: i t y/java/index.html The key point, though, is that in the non-java configuration, private key and passphrase operations are performed on the server- side. This requires that users place a higher level of trust in our servers as a trade off for the better usability they get from not having to install Java and load an applet. 3

4 This might clarify things a bit when you are considering what actions we might be required to take under a court order. Again, I stress that our requirement in complying with a court order is that we not take actions that would affect users other than those specifically named in the order. BTW, if you have an older Hushmail account yourself, it may not have the non-java option available. If that's the case, I can switch that on for you. Regards, Brian On Thu, 01 Nov :59: "Poulsen, Kevin" <Kevin_Poulsen@wired.com wrote: Hi Brian, Thanks for your reply on this. I have a related question. This law enforcement affidavit (below) in a steroid sales case indicates that the police obtained, not just the IP addresses of users, but the actual content of mail sent to and from three separate Hushmail accounts. I understand that you have to comply with legal process, but I thought that Hushmail's architecture made it impossible for anybody, including your company, to access s' contents. Is that wrong? e. prod_ affiliate.25.pdf K Kevin Poulsen senior editor -- wired news office: mobile: klp@wired.com -----Original Message----- From: Brian Smith [mailto:sbs@hushmail.com] Sent: Wednesday, September 19, :10 PM To: Poulsen, Kevin Subject: [hush.com # ] Journalist's query Hi Kevin, Our policy is that we only release user information under court order from a court of British Columbia. 4

5 ( When a US agency requires information, they have to work in co- operation with Canadian authorities. While I'm not legal counsel, I believe that most of this is handled through the Mutual Legal Assistance (MLAT) process. From our perspective, the end result is always a Canadian court order. We comply fully with Canadian court orders, so long as they apply to specifically identified accounts as opposed to broad data collection. If you need any more info, let me know. Brian Smith CTO Hush Communications Corporation sbs@hushmail.com (604) ext 222 On Wed Sep 19 00:09: , klp@wired.com wrote: Hi Hushmail. I'm working on a story about Max Butler, a hacker who was recently indicted for a bunch of credit card related stuff in the U.S. It turns out U.S. law enforcment traced Butler through his Hushmail account. A U.S. Secret Service affidavit says "Secret Service has obtained Internet Protocol (IP) connection logs for the account, digits@hush.com. On multiple occasions, the account was accessed from a computer assigned the IP addresses ," etc. I'm just wondering what steps the Secret Service goes to in order to get information like that, given that you're located in Canada. Thanks in advance! Kevin Poulsen senior editor - wired news office: mobile: klp@wired.com 5