Hacker News Reader

Comment by amelius | Hacker News Reader

Does this verify for side-channel attacks?

I'm a bit reluctant to reply without having looked at the article in detail, but I feel confident that the answer must be negative!

Why?

Because the very concept of side-channel depends on attacker capability! For example, does your attacker have physical access to the processor or not? With physical access you can exploit channels like power consumption through differential power analysis, or shoot laser pulses at target transistors to flip them and induce the processor to leak secrets. OTOH, without physical access, those channels don't meaningfully exist and you need to rely on, for example, speculation failure attacks and exfiltration via cache timing. So what counts as a side-channel is attacker-capability dependent.

A good middle ground is to say "no secret data should be leaked via timing of operations".

Ie. a high security and a low security thread on the same CPU should not be able to get clues about what data the other has in its address space.

Offering stricter protection than that is pretty hard - simply the fact that one thread is using the floating point units a lot and causing the CPU to throttle is an info leak, so I don't think it's possible to really prevent small leaks of flow control information.

This is a good middle ground, but ...

... leakage by timing side-channels depends in parts on how accurate your time-measurements are (e.g. Javascript's timer resolution was degraded, in order to make transient failure attacks like Spectre harder [1]).

I totally agree with your second point and believe, but cannot prove, that no current processor with any competitive performance is free from timing side-channels, the best we can currently do is put upper bounds on leakage rate. There are just so many other timing side channels, e.g. port contention [2]. They just keep popping up ...

Another dimension is the very meaning of thread. Presumably, as an end-user, you care about the threads/processes that the operating systems defines. But they don't map one-to-one to hardware threads, cores etc. Indeed I would argue that processors don't have threads in the sense that end-users care about. So the relevant security property must be regarding a hardware/software interface. Quite how to nail down this isolation property is active research I think. See e.g. [3] for work from 2016 in this direction.

Yet another dimension to this is through passwords and similar mechanisms: presumably you want to allow doing things like "sudo" so a low-priority thread can increase priority, provided the former knows the right password. But the very act of supplying a false password, leaks a tiny bit of information (that can be quantified in terms of Shannon-style information theory) about the password's search space.

[1] https://hackaday.com/2018/01/06/lowering-javascript-timer-re...

[2] A. Bhattacharyya, A. Sandulescu, M. Neugschwandtner, A. Sorniotti, B. Falsafi, M. Payer, A. Kurmus, SMoTherSpectre: Exploiting Speculative Execution through Port Contention. https://arxiv.org/abs/1903.01843

[3] D. Costanzo, Z. Shao, R. Gu, End-to-end verification of information flow security for C and assembly programs. https://6826.csail.mit.edu/2019/papers/certikos-sec.pdf

I'd like to see CPU's having a notion of "theoretical time" and "real time". Theoretical time ticks once per CPU instruction or similar. Real time is kept in sync with theoretical time by slowing the CPU down if theoretical time gets ahead, and throwing an exception if real time gets ahead.

All IO with untrusted devices would be delayed until the real time exceeds the theoretical time the message was sent.

Then one can have as many timing sidechannels as one likes, and the running program can never learn about them.

That would be great. But isn't there a danger, that such a CPU, at least if implemented naievely, would basically mostly idle, since modern OoO processors schedule memory access dynamically? For hard real-time tasks, some CPUs don't have caches, to make timing more predictable, but there is a heavy performance penalty to be paid for that predictability.

Are you familiar with works like [1]? That is thinking in this direction, but from a different angle.

[1] G. Heiser, G. Klein, T. Murray, Can We Prove Time Protection?. https://arxiv.org/pdf/1901.08338.pdf

> heavy performance penalty to be paid for that predictability

I think this is probably a fascinating area of study. It feels like there is a power/time/space non-linearity and being able to trade one for another.

How about the CPU is put into a fixed timestep mode, where all operations take the same amount of time.

If there was a hardware level concept of a thread, it could be a thread property.

Another option would be a queue of futures with a rate control based on the required security properties.

> ... leakage by timing side-channels depends in parts on how accurate your time-measurements are (e.g. Javascript's timer resolution was degraded, in order to make transient failure attacks like Spectre harder [1]).

But that doesn't matter if how long it takes for your instructions to execute is data independent, no ?

How are you planning to ensure that all victim code has data-independent timing?

> ... leakage by timing side-channels depends in parts on how accurate your time-measurements are

The rate of leakage from a existing timing side-channel depends on how accurate your time-measurements are; the presence of such a side channel does not. (Though one shouldn't discount the value of degrading a side channel from kilobytes per second to millibits per hour, even the latter will only protect a reasonably-sized private key for a decade or two.)

I think most of practical timing attacks are on software pieces rather than hardware, if two threads interact using some way (pipes, IPC, TCP) you can't blame the CPU for the inter-threads leaks, looks for example how a simple RSA timing attack works, it depends on software implementation. Of course you can use branch-less code to avoid timing leak at some point, but some leaks depend on the algorithm.

Yes, so you want to say something like: the CPU doesn't allow additional timing attacks that already exist in software. Making such a relational property formal in a way that is usable in practise is a hard problem.

I agree that that's good level of security to ask for, but it's a vastly less vague level of security than "verified for side-channel attacks".

I don't see why it would. Verified doesn't mean unhackable (including physically), it means correct.

I'm not sure how exactly you'd do it.

I guess you could write some kind of AI that writes gadgets, then tries to find the optimal probability of correctly leaked data.

There are methodologies for doing this automatically published but it's in the "floats rather than books" category of behaviour since it's quite chaotic, so a formal proof would be hard.

Reply on news.ycombinator.com