5 ms·

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 re

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.

int0x80 8y ago
That an also to avoid posibly revealing internals and details of the designs/architecture/etc to non-intel people.
monocasa 8y ago
Security by obscurity obviously shouldn't be your only method, but it can absolutely be a valid component of a broad defense in depth.
- fromthestart 8y ago
  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.
  - monocasa 8y ago
    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.
    - lostapathy 8y ago
      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.
      - monocasa 8y ago
        That just sounds like misplaced priorities than the obfuscation layer getting in the way.
        lostapathy 8y ago
        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.
- codedokode 8y ago
  Defence from whom? From system administrator?
  - monocasa 8y ago
    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?
  - squarefoot 8y ago
    And lawyers probably.
  - wolfgke 8y ago
    > Defence from whom? From system administrator? From the user, since SGX is also used/intended for DRM purposes.
fermienrico 8y ago
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.
- gonesilent 8y ago
  So that no nerd will see your 14lines of code for a $80 IOT temp sensor
- marssaxman 8y ago
  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?
nickpsecurity 8y ago
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.
- ratmice 8y ago
  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.
  - nickpsecurity 8y ago
    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.
- codedokode 8y ago
  Why copy the code that can run only on Intel CPUs? It doesn't make sense.
  - nickpsecurity 8y ago
    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.
bubblethink 8y ago
>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.
extrapickles 8y ago
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.pdf https://web.eecs.umich.edu/~taustin/papers/HPCA17-coldboot.p...
- slededit 8y ago
  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 https://github.com/enjoy-digital/litedram

int0x80 8y ago

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

monocasa 8y ago

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

fromthestart 8y ago
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.
- monocasa 8y ago
  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.
  - lostapathy 8y ago
    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.
    - monocasa 8y ago
      That just sounds like misplaced priorities than the obfuscation layer getting in the way.
      - lostapathy 8y ago
        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.
codedokode 8y ago
Defence from whom? From system administrator?
- monocasa 8y ago
  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?
- squarefoot 8y ago
  And lawyers probably.
- wolfgke 8y ago
  > Defence from whom? From system administrator? From the user, since SGX is also used/intended for DRM purposes.

fermienrico 8y ago

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.

gonesilent 8y ago
So that no nerd will see your 14lines of code for a $80 IOT temp sensor
marssaxman 8y ago
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?

nickpsecurity 8y ago

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.

ratmice 8y ago
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.
- nickpsecurity 8y ago
  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.
codedokode 8y ago
Why copy the code that can run only on Intel CPUs? It doesn't make sense.
- nickpsecurity 8y ago
  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.

bubblethink 8y ago

>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.

extrapickles 8y ago

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.pdf https://web.eecs.umich.edu/~taustin/papers/HPCA17-coldboot.p...

slededit 8y ago
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 https://github.com/enjoy-digital/litedram