Hacker News Reader

Comment by codedokode | Hacker News Reader

Why does Intel encrypt the code? It is unlikely that anyone would steal it because it is useable only with Intel CPUs and is protected with copyright. So the reasons are either Intel wants to hide something (a code that changes CPU behaviour when a benchmark is detected?) or wants to have some features that cannot be disabled or modified by the user.

It is difficult to believe that there is no backdoor.

View on HN

Physics is another reason. Since things are so small these days, you don't want a large amount of 1s or 0s because the charge will "leak" into neighboring cells. In the case of buses, anything other than a nominal 50/50 distribution requires too much power or will confuse the automatic gain control on the RX end of the link.

DDR3&4 is a good example of this where the CPU scrambles[0] what is written to physical memory to get the data closer to 50/50 1s and 0s.

In this case I doubt this is the primary reason though.

[0]: https://web.eecs.umich.edu/~taustin/papers/HPCA17-coldboot.p...

DDR3 doesn't scramble the data bits, and I don't think DDR4 does either.

Here's an open source controller - you can see yourself: https://github.com/enjoy-digital/litedram

There's two reasons I've seen companies obfuscate as much of their hardware and firmware as possible:

1. Protecting their trade secrets. Even if it's eventually leaked or copied, the time between introducing the product and a clone happening might represent billions in sales.

2. Reducing patent damages. Hardware is a patent minefield with suits and licensing deals pretty common. The companies that want to troll need to see clearly that their patents were infringed. Making the product as opaque as possible reduces the number that will notice in the first place and/or how certain their claim will look. Patent suits are the single, greatest threat to open-source, hardware companies that operate in an existing ecosystem.

IANAL, but I find 2. weird, my first thought was that it obfuscation would give the opposing litigant an argument for willfulness potentially increasing patent damages.

i.e. it may reduce the total sum of patent damages across all potential cases by reducing the number that result in litigation, while increasing likelihood of increased damages for an unsuccessful defense.

Can't help but think 2. really seems to me a double edged sword.

Well, I know they do No 2 and it seems to work a bit. My guess is they never bring up that motivation. Just say they hid their design to stop Chinese copycats and delay hackers.

Why copy the code that can run only on Intel CPUs? It doesn't make sense.

They mostly try to protect hardware implementation details. Another example was how hard it is to get data needed for writing good drivers, another firmware. Even that most companies don't want to share for fear it leaks some aspect of the design. Finally, for Intel ME backdooring all CPU's, there's a decent chance they're paid a fortune by one partner in particular to keep it there with buggy, obfuscated code. That's on top of ordinary reasons.

Security by obscurity obviously shouldn't be your only method, but it can absolutely be a valid component of a broad defense in depth.

Defence from whom? From system administrator?

ME is (among other things) supposed to be the secure enclave for SGX keys, which Intel is hoping will allow encrypted computation on cloud computing clusters that are protected from inspection by the system admins.

So, without even getting into the whole DRM argument, yes?

> Defence from whom? From system administrator?

From the user, since SGX is also used/intended for DRM purposes.

And lawyers probably.

I don't know if I agree. While obscurity can be a deterrent, I imagine most groups are unlikely to come up with sufficient, convoluted complexity to prevent identification of exploits. Primarily because you're effectively pitting yourself against a collective of $hat hackers, instead of doing things "right" and attempting to use encryption.

This doesn't mean it isn't a deterrent, but doing things in an obfuscated and unusual way also means you're potentially treading on unexplored ground, and so there will potentially be other exploits, bugs, innefficiencies which can come with the territory.

This isn't an "instead of doing things 'right'". Like I said, it's only valid as one component of a broader strategy.

You might have a point if someone had ever made a perfect scheme, but everything that seems to have attracted attention has been broken AFAICT.

So, a moat around a castle does help. Calling it good after digging a moat and not building any walls is probably less useful than doing nothing. The moat is only useful in the broader context.

Conversely, sometimes the obscurity layer will obscure the issues not just from others, but also yourself.

I worked for a thin client vendor years ago that was obsessed with encrypting our boot image etc, and poured all our resources into that. Which lead to encryption that was still trivial to work around, and a lot of other real security issues were never dealt with because we were fixated on the ineffective obscurity layer.

That just sounds like misplaced priorities than the obfuscation layer getting in the way.

Absolutely. The obsession with that obfuscated our priorities, 100%.

It also made our images more insecure, because it added no real security, while making it harder to improve security where it mattered.

I am not defending Intel, but firmware encryption is a very common thing in embedded software. The new ARM Cortex M33 architecture adds a ton of security & encryption features. This is becoming increasingly important in IOT devices.

Wow, that's awful! All the more reason to continue avoiding having anything to do with the IOT. Who would want to own household devices that keep secrets against you?

>Why does Intel encrypt the code?

In general, to protect the hardware IP. ME and FSP both do a lot of low level stuff that is instrumental to the silicon working in the first place.

That an also to avoid posibly revealing internals and details of the designs/architecture/etc to non-intel people.

Reply on news.ycombinator.com