Slashdot Mirror
What The CIA WikiLeaks Dump Tells Us: Encryption Works (ap.org)
"If the tech industry is drawing one lesson from the latest WikiLeaks disclosures, it's that data-scrambling encryption works," writes the Associated Press, "and the industry should use more of it." An anonymous reader quotes their report:
Documents purportedly outlining a massive CIA surveillance program suggest that CIA agents must go to great lengths to circumvent encryption they can't break. In many cases, physical presence is required to carry off these targeted attacks. "We are in a world where if the U.S. government wants to get your data, they can't hope to break the encryption," said Nicholas Weaver, who teaches networking and security at the University of California, Berkeley. "They have to resort to targeted attacks, and that is costly, risky and the kind of thing you do only on targets you care about. Seeing the CIA have to do stuff like this should reassure civil libertarians that the situation is better now than it was four years ago"... Cindy Cohn, executive director for Electronic Frontier Foundation, a group focused on online privacy, likened the CIA's approach to "fishing with a line and pole rather than fishing with a driftnet."
The article points out that there are still some exploits that bypass encryption, according to the recently-released CIA documents. "Although Apple, Google and Microsoft say they have fixed many of the vulnerabilities alluded to in the CIA documents, it's not known how many holes remain open."
The article points out that there are still some exploits that bypass encryption, according to the recently-released CIA documents. "Although Apple, Google and Microsoft say they have fixed many of the vulnerabilities alluded to in the CIA documents, it's not known how many holes remain open."
Intel CPU Backdoor Report (Updated Mar 12, 2017)
The goal of this report is to make the existence of Intel CPU backdoors a common knowledge.
What we know about Intel CPU backdoors so far:
TL;DR version
Your Intel CPU and Chipset is running a backdoor as we speak.
The backdoor hardware is inside the CPU/Bridge and the backdoor firmware (Intel Management Engine) is in the chipset flash memory.
30C3 Intel ME live hack:
@21m43s, keystrokes leaked from Intel ME above the OS, wireshark failed to detect packets.
[Video Link] 30C3: Persistent, Stealthy, Remote-controlled Dedicated Hardware Malware
[Quotes] Vortrag:
"DAGGER exploits Intel's Manageability Engine (ME), that executes firmware code such as Intel's Active Management Technology (iAMT), as well as its OOB network channel."
"the ME provides a perfect environment for undetectable sensitive data leakage on behalf of the attacker. Our presentation consists of three parts. The first part addresses how to find valuable data in the main memory of the host. The second part exploits the ME's OOB network channel to exfiltrate captured data to an external platform and to inject new attack code to target other interesting data structures available in the host runtime memory. The last part deals with the implementation of a covert network channel based on JitterBug."
"We have recently improved DAGGER's capabilites to include support for 64-bit operating systems and a stealthy update mechanism to download new attack code."
"To be more precise, we show how to conduct a DMA attack using Intel's Manageability Engine (ME)."
"We can permanently monitor the keyboard buffer on both operating system targets."
Backdoor removal:
The backdoor firmware can be removed by following this guide using the me_cleaner script.
Removal requires a Raspberry Pi (with GPIO pins) and a SOIC clip.
Decoding Intel backdoors:
The situation is out of control and the Libreboot/Coreboot community is looking for BIOS/Firmware experts to help with the Intel ME decoding effort.
If you are skilled in these areas, download Intel ME firmwares from this collection and have a go at them, beware Intel is using a lot of counter measures to prevent their backdoors from being decoded (explained below).
Useful links:
The Intel ME subsystem can take over your machine, can't be audited
REcon 2014 - Intel Management Engine Secrets
Untrusting the CPU (33c3)
Towards (reasonably) trustworthy x86 laptops
30C3 To Protect And Infect - The militarization of the Internet
30c3: To Protect And Infect Part 2 - Mass Surveillance Tools & Software
1. Introduction, what is Intel ME
Short version, from Intel staff:
Re: What Intel CPUs lack Intel ME secondary processor?
Amy_Intel Feb 8, 2016 9:27 AM
The Management Engine (ME) is an isolated and protected coprocesso
In fairness the leaks were of US government agency documents, so although you can presume non-US agencies have the same issues we don't have comparable document leaks to prove that.
VeraCrypt is it's open source replacement.
I'm still not convinced on EC cryptography, which was brought along with the help of the NSA choosing certain curves
There's nothing wrong with ECC. It has significant advantages over RSA, especially on low-power devices. There is a remote possibility that the NIST curves are weak in some way known to the NSA and not to the rest of the world, but if you're concerned about that you can simply choose different curves. Edd25519 is a particularly good choice (though Edwards curves work a little differently, so it's not a drop-in replacement for the NIST curves).
Personally, I have no real concerns about the NIST curves. Mostly because I think that if they were weak, the academic community would have discovered it by now, but also because if the NSA can crack them it's a closely-held secret which is used very sparingly, and nothing I encrypt or sign is that important.
IMO, the biggest problem with ECC is the lack of standardization around how to use it to encrypt. ECDSA is very well-standardized, but ECIES has too many free parameters (choice of KDF being the biggest) which makes interoperability hard.
Honestly, if I put on my tinfoil hat I'm more worried about what the NSA knows about how to break RSA than ECC. Not because I think they can factor products of large primes, but because there are so many subtle ways to screw up RSA and make it exploitable, and because the NSA really seems to discourage use of ECC for encryption. Not only have they not set out clear standards for ECIES, an odd exception to the normal thoroughness of the NIST standards which hinders interoperability and discourages use, but last year they even told the world not to bother with ECC and to stick with RSA until practical post-quantum algorithms are available.
nobody has yet shown practical attacks against large enough primes used in PKE
RSA != PKE. And, actually, there are lots of practical attacks, if you consider the space of the ways people screw up RSA. In addition, RSA's expensive key generation function makes forward secrecy impractical in most cases, which makes logged traffic vulnerable to subpoena attacks. This is the primary reason why all TLS security evaluations issue bad grades for any web server configured to use RSA. DH or ECDH are much better.
Every cryptographer I know recommends against using RSA. For encryption, pick your ECIES parameters and use it, with an authenticated encryption mode, e.g. AES-GCM. For signatures, use ECDSA. In both cases, if you're worried about backdoored curves use Brainpool curves, or Edd25519.
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.