The FBI Can Bypass Encryption [pdf]
cryptome.org
cryptome.org
And there is no need for intentional security vulnerabilities, the accidental ones are quite sufficient. Fixing that is a whole different problem.
I foolishly transferred an old private key to a cloud server years ago, therefore I can no longer assume it is private. Even having the only copy on my laptop isn't ultimately safe, as it is reasonably possible that the vulnerabilities that exist in my browser or the OS may have been compromised.
In the earlier leaked docs Snowden mentions targeting of sysadmins by looking for SSH usage patterns. Lookup by IP, fingerprint the device using HTTP headers (and other tells), look up the usage patterns, execute a MITM attack by injecting the appropriate malicious exploit code into the TCP stream as required.
I will give an example of some confirmed and speculative backdoors.
Microsoft Windows and Phone.
1) Bitlocker keys are uploaded to OneDrive by 'device encryption'.
"Unlike a standard BitLocker implementation, device encryption is enabled automatically so that the device is always protected.
...
If the device is not domain-joined a Microsoft Account that has been granted administrative privileges on the device is required. When the administrator uses a Microsoft account to sign in, the clear key is removed, a recovery key is uploaded to online Microsoft account and TPM protector is created."
http://technet.microsoft.com/en-us/library/dn306081.aspx
2) Device encryption is supported by Bitlocker for all SKUs that support connected standby. This would include Windows phones.
"BitLocker provides support for device encryption on x86 and x64-based computers with a TPM that supports connected stand-by. Previously this form of encryption was only available on Windows RT devices."
http://technet.microsoft.com/en-us/library/dn306081.aspx#BKM...
3) The tech media and feature articles recognise this.
"... because the recovery key is automatically stored in SkyDrive for you."
http://www.zdnet.com/surface-bitlocker-and-the-future-of-enc...
4) Here's how to recover your key from Sky/OneDrive.
"Your Microsoft account online. This option is only available on non-domain-joined PCs. To get your recovery key, go to ...onedrive.com..."
http://windows.microsoft.com/en-us/windows-8/bitlocker-recov...
5) SkyDrive (now named OneDrive) is onboarded to PRISM. (pg 26/27)
http://hbpub.vo.llnwd.net/o16/video/olmk/holt/greenwald/NoPl...
Similarly, Apple's newfangled full disk encryption KDE depends entirely on the security of the Secure Enclave UID, which it claims not to have. The UID is used in tandem with ~12 bits of user provided entropy (passcode).
Apple may not have this UID (burned in by the manufacturer) but the manufacturer still does. The FBI/NSA etc need only to manipulate, partner or serve legal papers, or to infiltrate as an employee the manufacture of Secure Enclave devices and wallah.
Microsoft implemented new TLS capabilities but added a backdoor so that the FBI could filter through it (pg. 30).
http://hbpub.vo.llnwd.net/o16/video/olmk/holt/greenwald/NoPl...
Microsoft removed the end-to-end crypto from Skype. They also have a newfangled 'voice recognition and translation feature'. Yummy.
RSA's BSAFE (more wirely deployed than shills will insist) included DUAL_EC - in fact were paid to do it - which means that even if you were to use, for example, AES the randomness you used to do it would not be safe.
As announced by Germany, TPM 2.0 was backdoored. China will not import TPM 2.0 (in fact any TPM from America) or Window 8.1 as a result. Lenovo (Chinese company) has a patent under the 380/286 classification 'key escrow' to extract keys stored in TPMs.
https://www.google.com/patents/US8290164
The encryption standards for voice on telephony networks of course are completely broken and have been for 20 years.
And taking a detour from backdoors themselves for a second you do realize that CALEA, the Stored Communications Act, and Section 215 of the Patriot Act require companies to provide data intercept methods, and key escrow or data access when the encryption is added by them.
I could go on. Anyway - you get the point. It is NOT bullocks. Cryptography, both in implementation, as a practice and in standards is backdoored in a way that enables mass surveillance.
Edit: A correction, as other users have pointed out - Germany specifically warned against the use of Windows with TPM - not TPMs themselves. See the following threads for more details.
I'm curious (since I care about TPMs and am looking forward to TPM 2.0 being more widely available) what this is, since this is the first I've heard of it. A quick Google search brings up this article: http://www.zdnet.com/german-government-refutes-windows-backd... which seems to say that the entirety of the German government's claims is that TPMs, as a technology, can be used to implement back doors (which is true of older versions of the standard, too), and the same article claims that the chips are often manufactured in China and _exported_ from there (which matches my previous understanding), not imported. So I assume there's something more up-to-date here; do you have a link to more details?
http://www.zeit.de/digital/datenschutz/2013-08/trusted-compu...
Here's a press release from the BSI - not the original one but the announcement made _after_ the fallout of previous reporting:
"From the perspective of the BSI, the use of Windows 8 in combination with a TPM 2.0 goes hand in hand with a loss of control over the operating system and the hardware used." The paragraph goes on to describe a scenario where a fault somewhere causes the system to fail and put it into an irrecoverable mode. The article (not this announcement) mentions _other_ ways that it could manipulate the computer. Specifically, policy attestation can force software decision and installs and can set Machine Level policy - in the case of a compromise this would means forcing the machine to use weaker security settings.
"For certain user groups can use Windows 8 in combination with a TPM certainly improve safety. This includes users who may for various reasons not care about the security of their systems, or want, but trust the manufacturer of the system that this provides a secure solution and cares." The announcement goes on to say that this is a legitimate use case for some users, especially those who do trust Microsoft, manufacturers and their partners.
https://www.bsi.bund.de/DE/Presse/Pressemitteilungen/Presse2...
As the leak specifically centered around new features in Windows 8 and the new TPM capabilities, my best guess would be that the backdoor was in remote attestation, which allows the TPM to identify trusted entities for the Operating System.
https://duckduckgo.com/?q=remote+attestation+tpm&t=canonical
Remote attestation also raises privacy concerns:
"The above protocol raises privacy concerns. The fear is that the attestation key and its certificate can be used to track activity and compromise privacy. Originally, a trusted third party was proposed that would provide anonymized identity services to users. The trusted third party would issue certified attestation keys that were not directly traceable to the device and could issue multiple attestation keys to a device in order to prevent correlation. Due to problems with this proposal, another protocol was developed that provides a anonymity without the need for a trusted third party."
http://courses.cs.washington.edu/courses/csep590/06wi/finalp...
Then again the TPM spec does not specify where the chip must be placed and the most common location is the low pin count bus, which can request bus master and has DMA.
I'm having trouble reading the machine translation of the article, but it sounds like Microsoft is enabling the TPM by default. This is a little concerning -- analogous to Debian adding their own public key to root's authorized_keys (but significantly _less_ concerning than that). However, it doesn't seem to indicate a back door in the _standard_ or its cryptography, any more than the Debian case would indicate a back door in OpenSSH or the secure-shell protocol.
TPMs are a device that has DMA on your machine, that you can't inspect and can't run code on. And then there's the similarity to the Clipper Chip in function. These things should make you at least pause.
You're talking about explicit backdoors separate from the encryption algorithms, with the exception of DUAL_EC, which is really in the same category because cryptographers have considered it suspicious from the beginning and the only people using it are using it because of the backdoor rather than in spite of it.
The difference is that the consequence changes from "encryption is useless" to "don't trust implementations from the likes of Microsoft, AT&T or hardware vendors."
(It is difficult to say whether heartbleed was accidental or intentional - intentionally introduced bugs or purposefully accepted buggy code are likely to be deniable. Asking whether a bug is intentional is ultimately a question about the mind of the programmer and not the code. Check out the underhanded C coding contest if you'd like to try a hand at writing or trying to find intentionally deniable security bugs.)
> You're talking about explicit backdoors separate from the encryption algorithms, with the exception of DUAL_EC
Well I also mentioned the TLS one... and the removal of e-to-e in Skype. If you want to compare to heartbleed again that was an explicit backdoor - not actually similar to DUAL_EC.
> The difference is that the consequence changes from "encryption is useless" to "don't trust implementations from the likes of Microsoft, AT&T or hardware vendors."
Totally agree.
Creating key hierarchies under the SRK that can be duplicated or moved is actually very clearly specified in the TPM 2.0 spec, and is at least partially meant for exactly this sort of recovery process. The seed that's used to derive the SRK itself will still never leave the TPM, so any keys that are in a separate hierarchy under the SRK (instead of the imported base key) are still secure.
https://www.trustedcomputinggroup.org/resources/tpm_20_libra...
Whether this becomes escrow for law enforcement depends on where/how it is escrowed. The example with Bitlocker and Device Encryption is one such way to do that.
I understand the claim that almost all standard operating systems are pre-hacked. I could believe this for Windows, and for any system running software that does not have publicly visible source, but I do not believe this is true for carefully built linux systems.
Additionally, even if your system IS rooted, I believe it is possible to run a secure virtual machine on it. ( note an encrypted keyboard would need to be used to prevent keylogging in the host OS )
As others here have stated, I think this article is mostly FUD. It could have been shorted to the single sentence "Your encryption is irrelevant if the software on your box can be hacked while it is running."
Once you have encrypted critical data on a safe source, and are sure that the keys are safe, you can actually trust that nobody is breaking your encryption in the next few weeks. The safe source and safe keys are the problem, not the encryption.