Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A brief history of the U.S. trying to add backdoors into encrypted data (2016)

atlasobscura.com

Post reply on HN
Print view View original

61–70 of 207 posts

Re: A brief history of the U.S. trying to add backdoors into encrypted data (2016)

#61

Post by adamomada »

Onavo wrote: post #44
loughnane wrote: post #2

This topic comes up a bunch still. Someone please correct me, but as I understand it anyone using new chips that use Intel ME (or AMD's equivalent) have a gaping hole in their security that no OS can patch. I know puri.sm[0] takes some steps to try to plug the hole, but haven't read up to see if it's effective or no. [0] https://puri.sm/learn/intel-me/

Does Apple have a warranty canary? How do we know that the M series of chips haven't been compromised?

marcan of the Asahi Linux project got into a discussion on reddit about this, and says that when it comes to hardware, you just can’t know.

> I can't prove the absence of a silicon backdoor on any machine, but I can say that given everything we know about AS systems (and we know quite a bit), there is no known place a significant backdoor could hide that could completely compromise my system. And there are several such places on pretty much every x86 system

(Long) thread starts here, show hidden comments for the full discussion https://old.reddit.com/r/AsahiLinux/comments/13voeey/what_is...

I highly recommend reading this if you’re interested https://github.com/AsahiLinux/docs/wiki/Introduction-to-Appl...

Re: A brief history of the U.S. trying to add backdoors into encrypted data (2016)

#62

Post by rightbyte »

adrian_b wrote: post #26
catlifeonmars wrote: post #15

Earlier quoted context omitted.

Source/reference? I’m not aware of such a backdoor

See the posting above about the Arstechnica article. During the last days of 2023 there was a big discussion, also on HN, after it was revealed that all recent Apple devices had a hardware backdoor that allowed bypassing all memory access protections claimed to exist by Apple. It is likely that the backdoor consisted in some cache memory test registers used during production, but it is absolutely incomprehensible how…

Can't Apple just push an software update with some:

    if (user_id == "adrian_b")
       pwn ();

?

Re: A brief history of the U.S. trying to add backdoors into encrypted data (2016)

#63

Post by bri3d »

dylan604 wrote: post #56
loughnane wrote: post #2

This topic comes up a bunch still. Someone please correct me, but as I understand it anyone using new chips that use Intel ME (or AMD's equivalent) have a gaping hole in their security that no OS can patch. I know puri.sm[0] takes some steps to try to plug the hole, but haven't read up to see if it's effective or no. [0] https://puri.sm/learn/intel-me/

Are these blob type of attacks accessible after boot? Essentially, are these only accessible if you have physical access? And at that point, isn't it game over anyways?

Intel ME allows intentional remote access through the ME in some enterprise scenarios (vPro). The driver support matrix is quite small and this is a massively overblown concern IMO, but it’s the root of a lot of the hand wringing.

However, onboard firmware based attacks are absolutely accessible remotely and after boot in many scenarios. It’s certainly plausible in theory that an exploit in ME firmware could, for example, allow an attacker to escape a VM or bypass various types of memory protection. Unfortunately the actual role of the ME is rather opaque (it’s known, for example, to manage peripherals in s0ix sleep).

Ditto for any other blob. Maybe a specially crafted packet can exploit a WiFi firmware. Maybe a video frame can compromise the GPU.

These are also good persistence vectors - gain access remotely to the NOR flash containing EFI, and you have a huge attack surface area to install an early boot implant. (or if secure boot isn’t enabled, it’s just game over anyway). On Linux, it’s often just hanging out in /dev as a block device; otherwise, once an attacker has access to the full address space, it’s not too hard to bitbang.

These are all fairly esoteric attacks compared to the more likely ways to get owned (supply chain, browser bugs, misconfiguration), but they’re definitely real things.

The closed-sourceness is only a tiny part of the problem, too - a lot of the worst attacks so far are actually in open source based EFI firmware, which is riddled with bugs.

Which takes me back to my original response to “isn’t everyone backdoored by ME” - sure, maybe, but if you’re looking for practical holes and back doors, ME is hardly your largest problem.

Re: A brief history of the U.S. trying to add backdoors into encrypted data (2016)

#64

Post by _kbh_ »

adrian_b wrote: post #26
catlifeonmars wrote: post #15

Earlier quoted context omitted.

Source/reference? I’m not aware of such a backdoor

See the posting above about the Arstechnica article. During the last days of 2023 there was a big discussion, also on HN, after it was revealed that all recent Apple devices had a hardware backdoor that allowed bypassing all memory access protections claimed to exist by Apple. It is likely that the backdoor consisted in some cache memory test registers used during production, but it is absolutely incomprehensible how…

> It is likely that the backdoor consisted in some cache memory test registers used during production, but it is absolutely incomprehensible how it has been possible for many years that those test registers were not disabled at the end of the manufacturing process but they remained accessible for the attackers who knew Apple's secrets.

I think we are nearly certain that the bug is because of a MMIO accessible register that allows you to write into the CPU's cache (its nearly certain this is related to the GPU's coherent L2 cache).

But I don't think it's 'incomprehensible' that such a bug could exist unintentionally. Modern computers and even more so high end mobile devices are a huge basket of complexity that has so many interactions and coprocessors all over the place I think it's very likely that a similar bug exists undiscovered unmitigated.

> For instance any iPhone could be completely controlled remotely after sending to it an invisible iMessage message.

I don't think the iMessage was invisible I think it deleted itself once the exploit had run, its also worth noting just how complicated the attack chain was and that the attacker _needed_ a hardware bug just to patch the kernel whilst having kernel code execution.

Re: A brief history of the U.S. trying to add backdoors into encrypted data (2016)

#65

Post by ahazred8ta »

londons_explore wrote: post #37
xyst wrote: post #31

for a long time, the US considered cryptography algos as a munition. Needed some arms license to export. Also, US tried to convince the world only 56 bits of encryption was sufficient. As SSL (I don’t think TLS was a thing back then) was becoming more mainstream, US govt only permitted banks and other entities to use DES [1] to “secure” their communications. Using anything more than 56 bits was considered illegal. ht…

Even now, if you join a discussion on crypto and say something like "Why don't we double the key length" or "Why not stack two encryption algorithms on top of one another because then if either is broken the data is still secure", you'll immediately get a bunch of negative replies from anonymous accounts saying it's unnecessary and that current crypto is plenty secure.

EVERYTHING IS FINE. WOULD YOU LIKE A BRAIN SLUG?

Re: A brief history of the U.S. trying to add backdoors into encrypted data (2016)

#66

Post by halJordan »

lkdfjlkdfjlg wrote: post #47
mmaunder wrote: post #43

Honorable mention for the ITAR regs that prevented Phil Zimmerman from exporting PGP 128 bit encryption until Zimmerman and MIT press printed the source as a book protected by the first amendment, exported it, and this enabled others to OCR it, and recompile it offshore. Also that ITAR enabled Thawte in South Africa (where I’m from) as a business to completely dominate sales for 128 bit SSL certs outside the US. Thaw…

[flagged]

ITAR is quite sensible. We can make mistakes and we can be sensible but wrong.

Re: A brief history of the U.S. trying to add backdoors into encrypted data (2016)

#67

Post by FactKnower69 »

lkdfjlkdfjlg wrote: post #47
mmaunder wrote: post #43

Honorable mention for the ITAR regs that prevented Phil Zimmerman from exporting PGP 128 bit encryption until Zimmerman and MIT press printed the source as a book protected by the first amendment, exported it, and this enabled others to OCR it, and recompile it offshore. Also that ITAR enabled Thawte in South Africa (where I’m from) as a business to completely dominate sales for 128 bit SSL certs outside the US. Thaw…

[flagged]

[flagged]

Re: A brief history of the U.S. trying to add backdoors into encrypted data (2016)

#68

Post by jonathanyc »

Now the argument coming from civil society for backdoors is based on CSAM:

> Heat Initiative is led by Sarah Gardner, former vice president of external affairs for the nonprofit Thorn, which works to use new technologies to combat child exploitation online and sex trafficking. In 2021, Thorn lauded Apple's plan to develop an iCloud CSAM scanning feature. Gardner said in an email to CEO Tim Cook on Wednesday, August 30, which Apple also shared with WIRED, that Heat Initiative found Apple's decision to kill the feature “disappointing.”

> “Apple is one of the most successful companies in the world with an army of world-class engineers,” Gardner wrote in a statement to WIRED. “It is their responsibility to design a safe, privacy-forward environment that allows for the detection of known child sexual abuse images and videos. For as long as people can still share and store a known image of a child being raped in iCloud we will demand that they do better.”

https://www.wired.com/story/apple-csam-scanning-heat-initiat...

Re: A brief history of the U.S. trying to add backdoors into encrypted data (2016)

#69

Post by ahazred8ta »

meroes wrote: post #45
xyst wrote: post #31

for a long time, the US considered cryptography algos as a munition. Needed some arms license to export. Also, US tried to convince the world only 56 bits of encryption was sufficient. As SSL (I don’t think TLS was a thing back then) was becoming more mainstream, US govt only permitted banks and other entities to use DES [1] to “secure” their communications. Using anything more than 56 bits was considered illegal. ht…

Do you have more on the legality aspect? I knew NSA pressured for a weaker key but what aspect could be made illegal? I had to write an undergrad paper on the original DES and I never saw an outright illegality aspect but wouldn’t be surprised. They also put in their own substitution boxes which I surprisingly never found much info on how exactly NSA could use them. So much speculation but why no detailed post mortem…

In the US, since the 1950s, you need a permit to export any product which has encryption. There are fines if you don't file the right paperwork. In the 1970s and 80s they would only approve keys of 40 bits or less.

https://en.wikipedia.org/wiki/Export_of_cryptography_from_th...

Post reply on HN