Microsoft Opens 'Transparency Center' For Governments To Review Source Code

MojoKid writes with news that Microsoft has announced the opening of a 'Transparency Center' at their Redmond campus, a place where governments who use Microsoft software can come to review the source code in order to make sure it's not compromised by outside agencies. (The company is planning another Transparency Center for Brussels in Belgium.) In addition, Microsoft announced security improvements to several of its cloud products: As of now, Outlook.com uses TLS (Transport Layer Security) to provide end-to-end encryption for inbound and outbound email — assuming that the provider on the other end also uses TLS. The TLS standard has been in the news fairly recently after discovery of a major security flaw in one popular package (gnuTLS), but Microsoft notes that it worked with multiple international companies to secure its version of the standard. Second, OneDrive now uses Perfect Forward Secrecy (PFS). Microsoft refers to this as a type of encryption, but PFS isn't a standard like AES or 3DES — instead, it's a particular method of ensuring that an attacker who intercepts a particular key cannot use that information to break the entire key sequence. Even if you manage to gain access to one file or folder, in other words, that information can't be used to compromise the entire account.

Comments

Re:Somebody has to do it

[Anubis IV]

The TL;DR version for folks who haven't seen it before or don't want to read it (which you really should do): just because the source is trustworthy doesn't mean the binaries are. The process to accomplish this sort of attack is fairly straightforward:
1) Modify, say, the compiler's source code so that it adds backdoors to some/all of the code it compiles.
2) Compile it, then replace the clean binary for the compiler with this new, tainted binary.
3) Revert the changes to the compiler's source code, erasing any evidence of wrongdoing.

By itself, that doesn't create a backdoor, but anything compiled using the tainted binary could potentially have a backdoor secretly added, even though the source code for both that code and the compiler would appear to be perfectly clean. The problem could be very hard to discover or pin down as well, only manifesting when a particular file is getting compiled, or even a particular line of code.

I think most of us are already familiar with this sort of attack, but it's worth repeating, since it's exactly the sort of thing that Microsoft's "Transparency Centers" don't address, and exactly the sort of thing we'd be expecting a government to be doing.

Re:Who thinks up these names?

[Anonymous Coward]

"Perfect Forward Secrecy" is a standard term in cryptography. It seems to have been introduced by Diffie, van Oorschot, and Weiner in their paper Authentication and Autheticated Key Exchanges.

The description of Perfect Forward Secrecy in the summary seems pretty confused. A cryptographic protocol has perfect forward secrecy if the only long-term key pair is used solely for authentication; that is to protect against man in the middle attacks and the like. Since you can't perform a man in the middle attack once the message has been transmitted, this means that compromise of the private key only jeopardizes future communications. In contrast, if a service uses RSA or ElGamal in the usual manner, then once the private key is compromised (e.g. via a Heartbleed like vulnerability), then all messages ever transmitted can be decrypted using this private key.

Somebody much smarter than you, dbIII

[cbhacking]

The summary's description of PFS is a complete clusterfuck, of course (this is /. so *obviously* the summary is going to be technically inaccurate, right?). Yours (LordLimecat) is more accurate, but the full concept isn't that hard so I'll explain it below.

First, some quick basics of TLS (I'm leaving out a lot of details; do *NOT* try to implement this yourself!):

• A server has a public key and a private key for an asymmetric cipher, such as RSA.
• When a client connects, the server sends their public key to the client. The public key is used to authenticate the server, so the client knows their connection wasn't intercepted or redirected.
• The client can also encrypt messages using the public key, and only the holder of the private key (the server) can decrypt those messages.
• Because RSA and similar ciphers are slow, TLS uses a fast, symmetric cipher (like AES or RC4) for bulk data.
• Before bulk data can be sent, the client and the server need to agree on a symmetric cipher and what key to use.
• The process of ensuring that both parties have the same symmetric key is called Key Exchange.
• Obviously, the key exchange itself needs to be protected; if the key is ever sent in plaintext, an attacker can decrypt the whole session.

Here's the scenario where PFS matters, and why it is "perfect":

• SSL/TLS (same concept, just different versions of the protocol really) is being used to secure connections.
• An attacker (think NSA) has been recording the encrypted traffic, and wants to decrypt it.
• The attacker has a way to get the private key from the server (a bug like Heartbleed, or possibly just a NSL).

Here's where it gets interesting:

• Without PFS (normal SSL/TLS key exchanges), the key exchange is protected using the same kind of public-key crypto used to authenticate the server. Therefore, without PFS, our attacker could use the private key material to either decrypt or re-create the key, and decrypt all the traffic.
• With PFS, the key exchange is done using randomly generated ephemeral (non-persistent) public and private parameters (Diffie-Hellman key exchange). Once the client and server each clear their private parameters, it is not possible for anybody to reconstruct the symmetric key, even if they later compromise the server's persistent public/private key pair (the one used for authentication).

It is this property, where the secrets needed to recover an encryption key are destroyed and cannot be recovered even if one party cooperates with the attacker, which is termed Perfect Forward Secrecy. Note that PFS doesn't make any guarantees if the crypto is attacked while a session is in progress (in this case, the attacker could simply steal the symmetric key) or if the attacker compromises one side before the session begins (in which case they can impersonate that party, typically the server). It is only perfect secrecy going forward.

Opensource

[DrYak]

The main advantages of free/libre open-source software is:

- source is available to review and hack upon for a WAY MUCH LARGER audience. It's "a few security reviewers cherry picked by a government" vs. "virtually anybody who has the time and resource to invest in it".
So you have a bigger pool from which to pick somebody who "is going to understand everything at every layer", or at least understand big enough parts of it, at a large enough number of layers, with enough overlap with the other "somebodies".

- the whole echo system is open. You can review lots of other stuff (compilers, libraries, etc.) You can have deterministic building to check if you really have the code that really produced the official binaries (that's already something that Tor, Truecrypt, Bitcoin, etc. are doing).
There's lot of things that you can do to check every piece of software that you need to trust.

Well of course, that's a lot work required. So in the end, you'll end up having to trust multiplt other people anyway. But at least, with opensource, that's a choice, and in any case you can do the checks your serlf (or more reallistically: ask someone you actually trust to do it for you. As in the current ongoing review of TrueCrypt, for example).

Whereas, no matter how motivated, with closed source software you'll always hit a wall. (Well microsoft gives you a peek at the windows code, but not necessarily all the rest needed to check full security).

Re:What's the point?

[jenningsthecat]

And who says they build their binaries from those sources? The backdoors are probably kept in a separate branch and merged with the release branch at build time...

This, exactly. Now if Microsoft allowed governments to build their own binaries from the source they had just finished reviewing, there might be some reassurance that this isn't just a smoke-and-mirrors act. Then again, the toolchain might be compromised. Somehow I don't think MS will allow governments to have access to the toolchain sources as well. And even if they did, I suspect most governments don't have the resources to conduct such a comprehensive review.