3 ms·

One or two cores for crypto would likely be susceptible to the same attacks, unless you don't let any user (or kernel) programs run crypto on those cores, makin

One or two cores for crypto would likely be susceptible to the same attacks, unless you don't let any user (or kernel) programs run crypto on those cores, making them useless. Any resource that needs scheduled will likely be attackable - either by timing on context switches, or flooding the resource with users and measuring things, and so on. Likely any scheduling method for those resources can leak information.

hgomersall 4y ago
Presumably you can schedule only on non-information-leaking-boundaries with very high level APIs?
- ChrisLomont 4y ago
  >non-information-leaking-boundaries Every one of the recent leaking boundaries were assumed to be non-leaking. You cannot just inject "non-leaking" into a statement and assume that solves anything.
  - hgomersall 4y ago
    Sure, but you can mitigate against all known attacks. You can also mitigate against the class of attacks by, for example, not allowing multitasking and forcing single task to completion (within a dedicated core for a subset of operations).
tux3 4y ago
I don't see how a fixed-frequency crypto core would be susceptible to the same attack, assuming proper constant-time cryto code. This attack exploits the fact that cycles are not constant time, so although crypto primitives are constant in terms of cycle, due to DVFS they're not really constant in terms of time. If the crypto core doesn't have DVFS and runs constant-cycle crypto, it doesn't matter that the core is contended and that you can measure the contention. You'll be measuring how many people are using the resource, but that won't tell you anything about the secret data, just about how much data there is.
- ChrisLomont 4y ago
  >fixed-frequency crypto core would be susceptible to the same attack, I also added there are other attacks. Once you are allowing multiple processes to utilize these limited crypto cores, you're gonna leak information. And fixed frequency makes many attacks easier - the attacker no longer has to work through variances in performance due to all the randomness in chips from power and caches and other timing things. >assuming proper constant-time cryto code Yeah, that's exactly what the SIKE authors had assumed too. Turns out that it broke. The point is once you allow things to be scheduled, it's nearly impossible to prevent information from leaking. My task asks for some crypto to be done - if fast, there was less in front. If slow, there was more in front. "Randomize!" the geek says - this nearly never works because random assumes some distribution, and again I can now keep poking at the scheduling to find the differences in behavior by statistical sampling. There is no free lunch here.
  - rictic 4y ago
    What can an attacker do by knowing how many much queued crypto work there is?
    - ChrisLomont 4y ago
      There's lots of attacks currently on existing systems exploiting this. Leaking any information about other processes or supposedly hidden state of the system means you are leaking - and attacks always get better, not worse. The point is once you have shared, scheduled resources, others are going to get knowledge that they should not have. The rough idea is, say some other process is repeatedly running some known code with an unknown key, and you want to get that key. By fiddling with how you schedule your requests, you can interrupt or interject his work and your work, and the timing issues due to scheduling have been shown to leak things. Say one process is dealing with web requests, signing things fairly often. An attacker on the same machine can craft web requests, learn how the shared system is responding, and glean information about the web server via timing. This type of poking has been used to leak AES keys by exploiting things thought safe until they were on shared resources.

hgomersall 4y ago

Presumably you can schedule only on non-information-leaking-boundaries with very high level APIs?

ChrisLomont 4y ago
>non-information-leaking-boundaries Every one of the recent leaking boundaries were assumed to be non-leaking. You cannot just inject "non-leaking" into a statement and assume that solves anything.
- hgomersall 4y ago
  Sure, but you can mitigate against all known attacks. You can also mitigate against the class of attacks by, for example, not allowing multitasking and forcing single task to completion (within a dedicated core for a subset of operations).

tux3 4y ago

I don't see how a fixed-frequency crypto core would be susceptible to the same attack, assuming proper constant-time cryto code. This attack exploits the fact that cycles are not constant time, so although crypto primitives are constant in terms of cycle, due to DVFS they're not really constant in terms of time. If the crypto core doesn't have DVFS and runs constant-cycle crypto, it doesn't matter that the core is contended and that you can measure the contention. You'll be measuring how many people are using the resource, but that won't tell you anything about the secret data, just about how much data there is.

ChrisLomont 4y ago
>fixed-frequency crypto core would be susceptible to the same attack, I also added there are other attacks. Once you are allowing multiple processes to utilize these limited crypto cores, you're gonna leak information. And fixed frequency makes many attacks easier - the attacker no longer has to work through variances in performance due to all the randomness in chips from power and caches and other timing things. >assuming proper constant-time cryto code Yeah, that's exactly what the SIKE authors had assumed too. Turns out that it broke. The point is once you allow things to be scheduled, it's nearly impossible to prevent information from leaking. My task asks for some crypto to be done - if fast, there was less in front. If slow, there was more in front. "Randomize!" the geek says - this nearly never works because random assumes some distribution, and again I can now keep poking at the scheduling to find the differences in behavior by statistical sampling. There is no free lunch here.
- rictic 4y ago
  What can an attacker do by knowing how many much queued crypto work there is?
  - ChrisLomont 4y ago
    There's lots of attacks currently on existing systems exploiting this. Leaking any information about other processes or supposedly hidden state of the system means you are leaking - and attacks always get better, not worse. The point is once you have shared, scheduled resources, others are going to get knowledge that they should not have. The rough idea is, say some other process is repeatedly running some known code with an unknown key, and you want to get that key. By fiddling with how you schedule your requests, you can interrupt or interject his work and your work, and the timing issues due to scheduling have been shown to leak things. Say one process is dealing with web requests, signing things fairly often. An attacker on the same machine can craft web requests, learn how the shared system is responding, and glean information about the web server via timing. This type of poking has been used to leak AES keys by exploiting things thought safe until they were on shared resources.