Schneier on Security

Clive Robinson • August 11, 2022 2:07 PM

@ ALL,

Some of these attacks “seem obvious” especially as they “keep hapening”.

But there is a reason behind this that we all should consider when building what is new technology starting from down below what some would consider the “physical layer” in the computing and communications stacks.

I’ve talked about “Fault Injection Attacks”(FI) in the past on this blog and started doing EMFI on 8bit CMOS processors back in the early 1980’s[1].

The problem is that if an attacker can inject a signal at a time of their chosing then they can flip a software branch, or reduce the entropy of a True Random Number Generator to next to nothing.

Few hardware engineers have any real experience in FI attacks, and they can be close to impossible to stop without a full system redesign with costly additions.

Any one who has been taught TEMPEST basics will know that active electronics radiate signals on which confidential information can be impressed or modulated and travel sizable distances.

What should be obvious to RF Design enginers is that there is the basic laws of physics “symmetry” at play. That is one of the first things you learn about antennas is that,

“They are reciprocal in most cases”

That is if they cause “emissions” they are also “susceptible” to EM fields. Almost the second thing you learn is,

“Every wire and PCB trace is an antenna.”

And you should design accordingly.

Unfortunately most design engineers do not… The way they work is to come up with the simplest system they can that sort of functions, fit it out with a test harness and then incremently build the system.

That is as I’ve pointed out in the past the way you go about building secure systems where you have a reasonable expectation it’s going to be attacked.

What is not mentioned in the Wired article and should be is why you should never run code from RAM only Masked ROM (which has issues of it’s own[2]). If there is any way the code can be changed, then an attacker with access can find a way to do so, which means there is NO real security in the system.

The second big mistake made by designers is “loading into RAM”. Whilst you can put all sorts of superficial security around loading code such as cryptographic signing, it’s fairly pointless in most cases.

The reason being is the incorrect assumption that once loaded it does bot need to be checked because other OS protection mechanisms will stop it being changed…

As assumotions go it’s a fairly large pile of bovine scat.

Anyone who knows anything about “RowHammer” should know that,

“RAM Contents Can not be Trusted”

As any bubbling up attack will work to far down the computing stack to be stopped. RowHammer and derivatives are in of themselves a form of “glitching attack”…

Oh and do not think that “tagging memory” or adding “Error Correcting Code”(ECC) circuitry will work either. It might make it harder but it’s not going to stop it.

Back a decade or so back when discussing “Castles-v-Prisons” I pointed this out and indicated that there was only two things you could do,

1, Encrypt RAM contents via the CPU memory interface.
2, Halt the CPU and with a second hypervisor state machine, walk the CPU executable memory space every few seconds or faster.

Thus depending on how often you walked the memory you had a certain probability of catching any changes in the code in RAM. Do it to infrequently and you could be “fast cracked” to fast and your resources would be taken up. Hence I named it “Probabilistic Security”.

To design a secure hardware system that will be in an attackers hands as standard and your probability of detecting there attack develipment is low needs a special mind set.

Which is why you also need a “health signal” to be sent out. That is your protection mechanisms actually use signalling from some other part of the system an attacker does not have access to. I won’t go into details but consider it a “challenge response” system that has “proof of integrity” testing an attacker can not predict or falsify.

[1] It came about from testing “Remote Telemetry Units”(RTU) for RF susceptability when VHF or UHF mobile radios were mounted inside the units. Put simply if you stuck the “Rubber Duck” antenna of a walkie-talky close to the CPU or it’s PCB signal traces and “keyed-up” quite often the CPU would “Go for a walk in the park” or just lockup untill the “Brown-out” detector timed out and triggered a reset (if it to had not been locked up by the EM radiation). As I’ve mentioned I went on to modulate the EM carrier in controled ways to reliably trigger a particular fault. I did not make myself popular when I showed that such attacks against “Electronic Wallets”(Mondex) and Pocket Gambling devices (a branch of Casinos) could be profitably attacked to their designers…

[2] If your code can only execute from ROM that can not be changed, you had better make sure that,

1, It’s error free.
2, It’s complete.

Because the price of security is not being able to change it, thus there can be no “patching” or “upgrading”. Something “Embedded Systems” designers who had to use “Masked ROM” parts back befor the late 1990’s were only to aware of. The advent of “Flash ROM” was a disaster for security in two ways,

1, It was easy for an attacker to change.
2, Becsuse it was easy to change there was no real insentive for software engineers to have their code anywhere near being “error free” or “compleate”.