The FBI Can Bypass Encryption [pdf](cryptome.org)
cryptome.org
The FBI Can Bypass Encryption [pdf]
http://cryptome.org/2014/10/fbi-breaks-crypto.pdf
8 comments
Not bullocks. The thesis is that very widely deployed cryptography is subverted, both by direct partnership and by infiltration - the Snowden leaks confirmed as much.
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 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.
You're making a different argument than the PDF does. The example it uses is heartbleed, which would be difficult to use for mass surveillance and, even assuming without any evidence that it was put there intentionally, sits along a large class of vulnerabilities of a similar nature that certainly are accidental.
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."
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."
Completely agree. I am not repeating cryptome's argument but adding to it.
(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.
(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.
> 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.
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?
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?
Here is the original article that broke the story (you'll need to translate it) - still trying to source the leaked document from the German gov't.
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.
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.
Sure, remote attestation is one of many capabilities of TPMs. It does not need to be used to use other features of the TPM (and its use sometimes presents privacy concerns), and there's no "back door" in using it: it's the entity that's setting up the TPM to enable remote attestation that has the ability to compromise the privacy of the next user of the machine, not the manufacturer or anyone else. This is no more a "back door" than Debian shipping an SSH server with the OS for you to use.
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.
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.
I agree wholeheartedly with this. In fact the German gov't specifically claimed that TPMs + Windows is considered harmful - not the TPMs themselves.
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.
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.
That is not what the linked patent describes. In that patent, the base key in the hierarchy (the one created by the administrator, NOT the storage root of trust or SRK) is created outside the TPM and stored elsewhere, then imported and used. If the TPM is cleared or reset, then loading the key will fail and the base key will need to be imported again.
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...
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...
Right, the key is stored elsewhere. It is escrowed.
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.
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 think the article was leaning closer towards: regardless of the encryption, it's much easier to smash-and-grab the key.
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 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.
The title of this post is misleading. To bypass something means to work around it, not to already be past it. If your machine is not hacked, and is encrypted, and you don't run any unsafe binaries, then the FBI cannot "bypass" your encryption.
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."
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."
it seems that it wasn't just my hallucination that recent FBI director show was really an attempt to make everybody believe that encryption is an insurmountable obstacle for the FBI and the likes. Not a good theatrical performance. “I don't believe it!” :)
What the pdf says is that it actually is as safe as you thought. It's just that the computer you are using to do the encryption is not safe. If you might be targeted by capable sources, don't trust neither your phone, your PC, your tv, or your car. That's what every spy movie tells you, and it's also true.
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.
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.
Why is this a PDF and why is this news? Even a guy like me, with the security expertise of having send about 3 gpg encrypted emails in my life, knows that you can't trust the machines you are using, while being targeted by FBI/CIA etc. It's on the first page on every book about computer security.
AES(Rijndael) was the weakest out of the final three contenders for the advanced encryption standard. Serpent and Twofish were clearly more secure but Rijndael was chosen because of its speed. There are attacks that have broken 11 of out the 14 AES-256 rounds (https://www.schneier.com/blog/archives/2009/07/another_new_a...). Using a combination of RNG weaknesses, CPU attacks, software vulnerabilities I don't think its crazy to conclude that the FBI can "crack" AES implementations in targeted investigations.
It's also important to note that timing attacks on AES are trivial, whereas other ciphers (Serpent is a popular favorite) is timing-free with naive implementations.
http://cr.yp.to/antiforgery/cachetiming-20050414.pdf
http://cr.yp.to/antiforgery/cachetiming-20050414.pdf
The NSA claims to have a significant breakthrough in cryptanalysis from the Snowden revelations. I personally believe that through the commercial relations the NSA has partnered up with AMD/Intel to weaken chips and CPU's and could be even pushing microcode updates that could defeat encryption at such a low level that it would be nearly undetectable.
How? The CPU only has instructions for AES-NI (not for the actual encryption scheme, nor for key generation) and it has to be deterministic or it won't decrypt on the other side. The only thing I can think about is trying to leak information using timing attacks and I wonder if these can be introduced through microcode updates. I doubt it and besides the risk for Intel would be far greater than for any of the companies involved in PRISM.
Was the parent talking about RDRAND? In this case the randomness used by the machine for both cryptographic protocols and key generation could be compromised, making AES, implemented in AES-NI or otherwise, moot.
If you listen to James Comey talk https://www.noagendaplayer.com/listen/656/44-52 he sounds like a crazy person. "Dount of smart thinking"
I can't help it, but my eyes are filtering out the contents of the pdf like my eyes do with online ads and spam emails. It looks too much like a poorly designed manifesto filled with out of context quotes, just after your money.
And there is no need for intentional security vulnerabilities, the accidental ones are quite sufficient. Fixing that is a whole different problem.