Schneier on Security

Clive Robinson • November 20, 2021 6:58 AM

@ Dave,

Yet another case of “if you want to be secure, don’t use the cloud”.

Whilst I would be one of the first to agree with you on that, there is another issue that unfortunately occupies much of my thinking and that is communications and the failings of encryption and signing of code.

Historically there is the old joke about secure computers in that,

“The only truely secure computer, is one with no leads connected, embedded in a huge concrete block, and dropped to the unreachable bottom of the Marianas Trench.”

But that was then, now the bottom of the Marianas Trench is now reachable…

“So what is considered secure today, is unlikely to be so in the near future due to advancment of knowledge”.

A lesson all who are interested in security should take to heart.

But the real unstated reason that computer was secure was not because of where it physicaly “unreachably” was, but because it was also compleatly usless, as it had no “communications”.

No matter how we slice or dice it all computers that have utility have to communicate in some way, and that is both a fundemental and primary security issue.

Even apparently “output only” computers have inputs be it power, signals, or both. They also often use communications protocols on the outputs, that have “error control” of some form. Which is actualy an input signal in it’s own right that can reach right back through systems to the other inputs[1] and so backwards into what are concidered “isolated”, “protected”, or even “gapped” systems.

But there is another need for communications one which nags at satellite payload developers all the time. Which is the issue of,

“All code has defects.”

The simple fact is it does not matter at what level of the computing stack you are at there will be unspecified states that can cause issues[2].

Most often it’s at the specification or standards level that the problem originates, but becomes an issue at the protocol or lower inplementation level. There are only two basic things you can do with it,

1, Live with the problem by mitigation.
2, Upgrade the software to resolve the problem.

For obvious reasons the “live with it” or mitigate at my end issue is undesirable, so the “upgrade” by “patch or replace” is prefered. Which means you have to have communicates where an unknown at design time user can access the system to run their own software.

Of “patch” or “replace, patching carries less “system risk”, which is not the same as “security risk”.

Unfortunately to alow patching you end up with a system that can alow a RowHammer style attack (though untill recent times unlikely due to bandwidth restrictions, something that is unfortunately changing where shared high bandwidth comms is becoming normal).

So to reduce the chance that a future unknown user is malicious, we have two crypto solutions,

1, Encrypted files.
2, Signed files.

As has recently been seen yet again with Intel CPU chips, both of these can be bypassed if access to one or more “secret keys” embedded in the device come into a users hands.

Clearly neither or both encryption and code signing are sufficiently secure.

Not something you want to realy think about with “Military Platforms in Space” going increasingly kinetic[3].

[1] For example, if you jam a network connection, and input from the keyboard keeps happening, the computer keeps trying to output data to the network. But as it can not be sent the network sub system just buffers it. However when the network output buffer is full an error signal goes back and unless trapped and dealt with other buffers keep filling and eventually the computer either drops all further input or it tells the keyboard to stop sending. The same if the input comes from an old serial line TTY terminal (which nearly half a century ago I used to bash away on quite literally as they were electro-mechanical “Keyboard Send and Recieve”(KSR) or punch tape “Automatic Send and Recieve”(ASR) teletype devices).

[2] Down at the lower levels of the computing stack you have logic gates. Amongst these you have data storage elements called “latches” these suffer from “soft errors” caused by meta-stability at their inputs. Look up the NOR or NAND gate “Set Reset”(SR) latches or clocked D-Types and “metastability”,

https://electronics.stackexchange.com/questions/381481/why-do-cascading-d-flip-flops-prevent-metastability

[3] The recent Russian destruction of one of their old satellites that caused issues for the International Space Station and presumably the Chinese Tiangong space station currently undergoing construction. Some assume Russia did it as a warning to both the Chinese and US about space use. The US Military are finally sort of acknowledging this danger and are now holding an annual “Hack-a-Sat” competition,

https://csmng.com/2021/11/12/21516/

Clive Robinson • November 23, 2021 5:00 PM

@ 6449-225, ALL,

Likewise, by refining the Rowhammer method, can you cause any desired aggregate of memory states to occur ?

Long answer quick,

In theory yes with some limitations, in practice we are getting there slowely, but the current state of play favours the attacker not the defender and it’s difficult to see if it could be otherwise.

Long answer,

What you quote being described by the pipes and jets of water is not realy any diferent to X-Ray crystallography, it you think about it. But is it actualy relevant?

Read on 😉

RowHammer is about moving charge across the top of or tunneling through an insulator. The old way of doing it was kind of like “raising the tide to floats all boats” in a chosen locallity.

The downside of the old way is not just that it is relatively easy to detect, it’s also relatively easy to predict in that it’s relatively “flat” so it is relatively easy to find a way to counter the charge build up “measure two points” and assume that if they are equal the points in between are in effect the same amplitude / hight. Thus you need very few points of mesurment.

This new method is more like dropping individual grains of sand such that you build up different amplitudes / hights in diferent places. Thus the charge amplitude forms an approximation to a series of normal growth distribution curves and ends up like a map of foothills with hight measurments not as contour lines but as individual points on the grid intersections.

Whilst not a “one way function” it is certainly a lot easier to calculate in one direction –ie from cause at every point– but a heck of a lot harder to calculate from the other direction –effect from very very few points– due to the limited ability of the defender to measure[1] but the relative ease to calculate for the attacker (not that it is that easy).

The problem for manufacturers is what ever they do to counter act RowHammer is it “robs real estate” so overall the usefull bit density per given area on a chip drops…

So the game so far has been to do just enough to stop one attack method, but not actually solve the underlying problem so stop all attacks no mater how novel they may be.

Expect to hear more in the future, this is likely to turn into one of those “gifts that keep giving”…

[1] Think of it like trying to map a large area of foot hills in the dark your ability to get any meaning is dependent on the smoothing function of the terrain and the number of points of measurment. If the points are to few thus too far appart you miss a lot of edges and valleys. From basic signal analysis if you have three points in a line you have two measurment periods. The maximum frequency you can measure is one cycle across those two periods. To get the real amplitude the phase of the highest frequency has to be such that the maximum and the minimum have to align with the “sampling” measurment points. If there is a phase shift then the sampling is reading lower points on the curve and reaches zero at one phase offset. To avoide this you use IQ qudrature phase measurment at each point and the amplitude is given as A = sqr(I^2 + Q^2) and gets way more complicated as you move from simple one dimensional to two or more dimensions.