Slashdot Mirror
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.
Governments shouldn't be using closed source garbage to begin with. It just locks them into a specific company and keeps them at their mercy, not to mention that even if the government reviews the source, the public can't do the same. Not a good message to send.
Who cares if you can look at the code? What matters is what you're running.
Looking at the code gives you nothing if you can't compile it to the exact same binary that you are running.
And even if they let you do that... you still need to trust the compiler, and the compiler that compiled that compiler, etc.
>> a place where governments who use Microsoft software can come to review the source code
Where's the proof that the source code you see is exactly the same as that which gets compiled to make the Windows you buy?
Also does anyone else find it as highly suspicious as me that this center is only open to governments?
So.. Microsoft let governments of the world look at the source code at your special center, and then double-dog-swears that there's nothing fishy going on between then, and compiling the source code, like say a patch applied somewhere in the build process? Riiiight.
If you WERE to put a backdoor in, that's probably how it'd be done. Would you really want a backdoor explicitly in the code for a developer to find? Of course not, you'd put in something only a few people know about. The secret to secret keeping is limiting the amount of people who know.
The other way to hide the backdoor is to make it a hard to find bug. Plausible deniability is quite high.
I have to believe this is good news though. It means a lot of foreign governments are suspicious of closed source software, to the point where Microsoft has had to announce a plan to make their code however less closed source.
AccountKiller
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.
"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.
Who the hell is going to sit down and scan a few million lines of source code with Microsoft looking over your shoulder and hope to spot a backdoor or two in the process?
Even then, how can you be sure that the source code they show you is the stuff you're actually running?
What a PR stunt this is!
Hundreds of legacy code developed for Windows platform using Windows development tools run only on XP and are not supported by 7 or 8.
So not only have you tied yourself to a particular version of a proprietary OS that - as we all know from previous experience - has a limited lifetime but you chose to do that by using proprietary software that won't run on anything else and you didn't think there might be a problem with that? Seriously? If you cut corners then you're going to get burned.
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!):
Here's the scenario where PFS matters, and why it is "perfect":
Here's where it gets interesting:
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.
There's no place I could be, since I've found Serenity...