28 ms·

Hertzbleed Attack

• 2OEH8eoCRo0 4y ago
  `cpupower frequency-set --governor performance`
• mkleinstadt 4y ago
  "Hertz" means "heart" in German, so the name is a pun on "heartbleed" and the unit for frequency
  • minedwiz 4y ago
    Almost, the word for "heart" is spelled "Herz".
    • schoen 4y ago
      I think it's still intended as a pun as Hertz (the physical unit and the name of Heinrich Hertz) and Herz are pronounced alike. Wikipedia and Wiktionary also have some suggestion that the name Hertz is etymologically related to the word Herz, although they disagree about exactly how.
      • Hublium 4y ago
        In German, a <z> always makes a /ts/ sound and in modern orthography, "tz" is only used after (short) vowels.
• MrWiffles 4y ago
  Brilliant approach, really. Never occurred to me to try something like this! Are you affected? Very likely. What can you do about it? Nerf your CPU performance by disabling "turbo boost" or equivalent. Should you do it? Probably not unless you're particularly vulnerable (journalist, human rights activist, etc.) One thing I found interesting that may get changed later, so I'm documenting it here, is in their FAQ they say: > Why did Intel ask for a long embargo, considering they are not deploying patches? > > Ask Intel. So Intel did ask for a long embargo, then apparently did nothing about it. My guess is they investigated "can we actually mitigate this thing with a microcode update?" and arrived at the conclusion after actually trying - or possibly after external influences were exerted (you be the judge) - that no, there's not much you can really do about this one. Later in the document another FAQ says: > [...] Both Cloudflare and Microsoft deployed the mitigation suggested by De Feo et al. (who, while our paper was under the long Intel embargo, independently re-discovered how to exploit anomalous 0s in SIKE for power side channels). [...] Which is again telling us that there indeed WAS a long embargo placed on this research by Intel. Only mentioning this here just in case the PR spin doctors threaten the researchers into removing mention of Intel on this one. Which honestly I hope doesn't happen because my interpretation is that Intel asked for that long embargo so they could investigate really fixing the problem (state agencies have more methods at their disposal and wouldn't need much time to exert influence over Intel if they decided to). Which speaks well of them IMO. But then again, not everybody's going to come to that same conclusion which is why I'm slightly concerned those facts may get memory-holed.
  • 2OEH8eoCRo0 4y ago
    You can configure your CPU to always boost if you're really paranoid. It shouldn't run much hotter since the load doesn't increase, just the frequency.
    • zx8080 4y ago
      Tell that to my intel macbook. Seriously, using a popular Turbo Boost Switcher makes it a lot colder and live longer on a battery
    • throwaway742 4y ago
      Then why isn't that the default setting?
      • smaudet 4y ago
        I wonder if this is such a widespread issue - frequency attacks mean the cpu must actually change speed frequently in order for any attack to occur. For a laptop how I thought it worked was cpu frequently was constant depending on performance level - so cpu should shift from low to high depending on idle state... For a server trying to aggressively save power, frequently changing speed per operation could leak this information. Turbo boost I thought was a setting overlong periods of time to change power levels, if you change too frequently you don't actually save much power.
      • 2OEH8eoCRo0 4y ago
        I didn't say temps or power won't rise, just that it's not a huge hit.
  • api 4y ago
    > What can you do about it? Nerf your CPU performance by disabling "turbo boost" or equivalent. Should you do it? Probably not unless you're particularly vulnerable (journalist, human rights activist, etc.) The most likely to be targeted (and probably easiest to target) systems are probably cloud hosts. This might be an argument for disabling frequency scaling and fixing clock speed on cloud VM hosts or bare metal servers. Less of a performance hit there too since those tend to run at a sustained max anyway, and turbo boost can be problematic in those environments due to heat. It can reduce overall throughput in a sustained load scenario.
• leephillips 4y ago
  My first highly amateur idea was to modify the frequency scaling algorithm with some randomness. How stupid is my idea?
  • bragr 4y ago
    I guess it depends on how much randomness you need to effectively mask the signal.
  • cylon13 4y ago
    Any noise strong enough to have a good chance of hiding the signal would completely defeat the benefit of having dynamic frequency scaling in the first place, I think.
    • sneak 4y ago
      Except that the processor can be doing other work during artificially induced noise delays, something not possible with delays introduced by lower mean frequency.
    • bobbylarrybobby 4y ago
      What if you discretized the allowed frequencies and linked the rate at which the cpu could switch?
    • staticassertion 4y ago
      An additional millisecond to your public key exchange is probably not going to matter - key exchange is pretty infrequent anyway.
  • teraflop 4y ago
    Unfortunately, trying to defeat side-channel attacks by adding random noise usually only increases the number of samples required to extract information, rather than preventing the attack entirely. (You can blame the central limit theorem for this.)
    • matthewdgreen 4y ago
• etaioinshrdlu 4y ago
  Does this mean that an evil process may gain information about a foreign process by measuring its own execution speed variations?
  • Phlarp 4y ago
    That is my reading of the text on the linked page. >We have demonstrated how a clever attacker can use a novel chosen-ciphertext attack against SIKE to perform full key extraction via remote timing, despite SIKE being implemented as “constant time”.
    • hinkley 4y ago
      That's a big problem. If you created an algorithm that evaluated all possible 32 bit inputs in parallel and then picked the correct value at the end based on the input, you'd still have some funky corner case where the branch predictor in your x64 processor spilled the beans. Are we going to have to design our crypto algorithms entirely on SIMD instructions to combat this sort of thing?
      • Phlarp 4y ago
        >Are we going to have to design our crypto algorithms entirely on SIMD instructions to combat this sort of thing? There is likely still potential for side channel attacks. From a 'first principles' approach a computer is always going to leak information about it's current state (power, noise, emi, etc) and the methods / tools / techniques for analyzing that leaking information are only getting better. The multi-tenant nature of modern infrastructure is the bigger issue in play here.
      • bombcar 4y ago
        It sounds like there's some mitigations available for the crypto libraries, but perhaps defense-in-depth is going to require the libraries to do "junk work" to obfuscate what's happening against future attacks like this. (I wonder if one is possible if the same key were to be used on different processors, if that would leak certain information, for example.)
• tootie 4y ago
  I'm mind-blown at this vuln being exploitable remotely. How is that possible?
  • bri3d 4y ago
    The paper is pretty good and does a great job explaining this: Basically, P-state / frequency governor side effects cause "constant-time" implementations of some algorithms like SIKE not to be constant time anymore - because in reality, these implementations were never "constant-time" but rather "constant-cycles" and with clock speed changing, so does the observed wall-clock time. Once this observation is made and the timing oracle understood, it's just a normal remote timing attack - spam the service with constructed data, measure the response time, and eventually your oracle tells you when you got bits right or not.
    • zhdllwyc 4y ago
      Thank you for enjoying reading our paper!
  • hatware 4y ago
    Shared tenancy in cloud platforms.
• halfmatthalfcat 4y ago
  At first I thought it had something to do with the company Hertz...
  • kzrdude 4y ago
    It's just the German dub of Heartbleed that finally showed up. The cast of voices is dull though
    • frankus 4y ago
      I’ve often wondered if choosing Hertz as the name for “cycles per second” was some kind of scientific dad joke since 1 Hz ≈ human heart rate.
      • kzrdude 4y ago
        It has a certain beauty to it! Confusingly enough Herz and Hertz are homophones but the former is the spelling used for heart. However it's possible the name Hertz is derived from an arcahic spelling for heart.
• kube-system 4y ago
  I'm not too much of a cryptography expert. How do I know if I'm using a > constant-time cryptographic library ? Edit: thanks everyone, I just wasn't familiar with the terminology.
  • arkadiyt 4y ago
    If your cryptographic library is not constant time then it is already vulnerable. This new attack is able to target the even previously unaffected constant time libraries - that's why they call it out specifically in their FAQ, but this is saying that _all_ cryptographic libraries are vulnerable to timing/side channel attacks (when running on processors which don't have these performance features disabled).
  • Grimburger 4y ago
    If you are not using one it is a very bad sign. All modern cryptographic libraries use various constant time operations.
  • zamalek 4y ago
    If it's the one built into your language stdlib, then you almost certainly are. Crypto libraries that are not constant time tend to not pass audits.
  • Phlarp 4y ago
    As one example, SSL uses constant-time crypto operations, so the answer to this question is an almost universal "yes"
  • deleted 4y ago
    [deleted]
  • nindalf 4y ago
    All libraries we use are constant time. What’s constant time? Crypto libraries need to do operations to encrypt and decrypt your data. The simple, naive implementation of these operations will work - giving correct input and output. However, a person can time the operation being performed and learn about the key being used. If you’ve deployed on a server and the other person can submit any text they want, whenever they want, they would be able to extract the key from your naive implementation. That’s bad, the worst outcome possible. That’s why good libraries will make sure that these operations take the same amount of time, regardless of input. So we thought we were safe. And now these authors tell us, no. That’s not the case. The guidelines used by crypto library developers don’t protect against the attack being described here.
• tgv 4y ago
  So if the encryption function would look at an actual timer, and insert bogus calculations at random places during encryption to pad the execution time, would that remove the information this attack needs?
  • bri3d 4y ago
    From a theory point of view, adding "bogus calculations at random places" would probably just increase the number of measurements required - it would introduce additional jitter above and beyond the large amount already accounted for in the attack documented in the paper, but the central limit/tendency over a large enough set of repeated measurements would still have multiple peaks. Adding a minimum wall clock floor (i.e. simply waiting to release the decrypted data to a client until a given wall clock time has passed from initiation) would close the door on this particular remote exploitation, although it would leave the door open to local/hardware attacks (power, frequency-analysis, parallel process checking P-states as the oracle instead of overall timing).
• bob1029 4y ago
  Something about this doesn't bother me as much as other side channels. To me, this reads like trying to predict the presence, make, model & operational schedule of someone's washing machine just by observing how fast their power meter spins over time. Unless you have an intimate awareness of all of the other power consuming appliances, as well as habits of the homeowner, you would have a hell of a time reaching any meaningful conclusions.
  • laurent123456 4y ago
    I guess it's a problem when it's possible to isolate a particular cryptographic operation? For example on a server that's not particularly busy.
  • JulianWasTaken 4y ago
    I would claim to know less than nothing about what's happening here, but to press a bit on the analogy -- aren't there workloads where clearly you're going to be more sure about what's happening? E.g. consider a bastion host proxying SSH connections into an environment. If you can observe the power meter on that laundry machine, you're much more likely to know what's using the power, no? (Especially so if the bastion isn't used flatly throughout the day).
    • IncRnd 4y ago
      Often, these side channel attacks work using an oracle or by forcing the system into a vulnerable state. Forcing a cpu to scale frequencies would do that here.
  • kzrdude 4y ago
    You can say the same thing about all of these attacks. That they are tedious ways of collecting data. The problem is that computers can be made to repeat operations, over and over again. Leaking keys fractional bit by bit or what it is. That's why the attack doesn't work against someone's laundry machine - unless it's connected to the internet, that is.
    • 4y ago
• stingraycharles 4y ago
  This is probably a naive question, but could this be mitigated by fencing a part of code by some “frequency fence” of some sorts? This is of course a long-term mitigation as it may require compiler support, may affect performance and other threads and whatnot, but I wonder what a proper solution would look like.
  • mlor 4y ago
    I'm curious whether this type of thing would work as well. It sounds like you're suggesting to be able to wrap sections of code in compiler-specific declarations (e.g., UNSAFE blocks in C#) that force the underlying hardware to operate at a constant frequency. I have PRECISELY no idea whether that is coherent or makes sense. It's just interesting at a glance.
  • tumetab1 4y ago
    Does not seem practical to me. A server accepting TLS connections would have almost always some thread doing “frequency fenced” code so the CPU would always be frequency locked. It's much more practical to just disable Turbo-boost. A more simpler mitigation is just add noise, perform random computations so the whole algorithm is constant time + random time. Greatly increases the difficulty of gathering timing data.
• RcouF1uZ4gsC 4y ago
  Pick at most 2: Sharing of computing resources Performance Security
  • Phlarp 4y ago
    People in this thread: Just run the CPU at max boost frequency all the time! Other people in this thread: Just disable turbo boost! cloud providers: quivering over the cost implications of either.
  • DSingularity 4y ago
    Well, I haven’t finished reading the paper but this is the kind of thing that would basically get is down to security iff sharing is disabled and performance is compromised. So, pick one.
  • deleted 4y ago
    [deleted]
• rocqua 4y ago
  Isn't this sort of a stand-in for power draw side-channel analysis? I guess it is cool that you can do it purely from software rather than needing physical access.
• candiddevmike 4y ago
  And yet folks will keep using cloud services and multi tenant offerings until we have regulations forbidding multi tenant computing for sensitive data.
  • jfk13 4y ago
    How many people can reliably identify "sensitive data", do you think?
    • goodpoint 4y ago
      Enough to collect and handle such data in the first place. Or do you handle data without knowing what it is?
      • jfk13 4y ago
        I suspect ideas of what is "sensitive" vary greatly. Whose definition counts?
• blueflow 4y ago
  Website, Brand, everything, nice! But, if they had a merchandise shop they would look more professional.
  • bombcar 4y ago
    The Intel-requested delay would have let them cross-brand with a famous bankrupt car rental company!
  • deleted 4y ago
    [deleted]
• pyrolistical 4y ago
  I don't get it. Is this only a problem for platforms that can read the current CPU frequency? Does this mean platforms such as JavaScript in the browser are unable to exploit this? Ditto for WebAssembly? If you don't give it the CPU frequency and don't give it the ability to make a syscall for it, then its unaffected? Is the longer term fix then to make reading of any compute metrics a privileged operation?
  • advisedwang 4y ago
    > Is this only a problem for platforms that can read the current CPU frequency? No, it just takes measuring the total wall-clock time of the relevant processing to exploit this.
  • kevingadd 4y ago
    The frequency change is observable by the whole algorithm taking a different time to run - the algorithm is constant-time, but because the clock speed is changing based on the data, it's not constant-wall-clock-time and you can perform a timing attack.
    • karussell 4y ago
      And also when I set the scaling governor to "performance" (under Linux)? Is the frequency in that case still adjusted based on the data or always "maximum"?
      • adrian_b 4y ago
        With the performance governor, the clock frequency is continuously adjusted between the "base frequency" and the "maximum turbo frequency", e.g. between 3.7 GHz and 4.8 GHz, for my computer. With the powersave governor, the clock frequency is continuously adjusted between a frequency much lower than the "base frequency", and also the "maximum turbo frequency", e.g. between 2.2 GHz and 4.8 GHz, for my computer.
    • pyrolistical 4y ago
      Haha so constant time algorithm isn’t constant time
• 1MachineElf 4y ago
  Interesting that the mitigation is to turn off Turbo/Precision Boost. Four or five years ago there was an an article submitted here (I wish I could find it) about a developer who keeps a machine with Turbo Boost disabled specifically because it seemed to interfere with their performance testing. By keeping it disabled they were able to eliminate a number of factors that prevented them from getting consistent results. It sounded like they preferred this approach for working on optimizing their code. I am not pointing this out to disparage this performance boosting feature, only calling it out as a point of interest
  • jessermeyer 4y ago
    Yes, this is a common technique in optimization. With frequency scaling enabled, a profiled function may have more than one hot region, implying 'hot' and 'code' code paths, but are really just manifestations of CPU speed being non-constant.
  • samus 4y ago
    These "optimizations" might not matter in the end though if the production environment runs with Turbo Boost enabled. Unless they are verified on another machine of course.
• hinkley 4y ago
  I suspect what we are seeing in the last few years is the slow death of purely symmetric multiprocessing. At the end of this I wonder if we'll see processors with one or two cores dedicated to cryptographic primitives, where the ALU has a fixed IPC, the core has a very limited number of clock rates, and the caches are sized to prevent eviction when running common cryptographic algorithms.
  • ChrisLomont 4y ago
    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.
• bobbylarrybobby 4y ago
  Interesting, and seems like a natural followup to this side channel: http://www.cs.tau.ac.il/~tromer/papers/acoustic-20131218.pdf http://www.cs.tau.ac.il/~tromer/papers/acoustic-20131218.pdf (RSA Key Extraction via Low-Bandwidth Acoustic Cryptanalysis), in which researchers deduced that the high-pitched sounds made by CPUs could leak the operations that GPG was performing to decrypt some encrypted content, and thus leak the private key. All you need is a microphone and the ability to trick the victim into decrypting some known content.
  • rocqua 4y ago
    The cool thing is that you can do this attack with code execution rather than physical access. That means a totally separate threat model.
  • samus 4y ago
    This is mostly a concern in airports, internet cafes and other places where attackers have easy access. Less so a data center.
  • hindsightbias 4y ago
    Surprising it took that long to look at sound when exploits on hw LEDs was a thing decades back.
• night-rider 4y ago
  So this can be used on so called ‘airgapped’ devices, but what if you house the machine in a giant Faraday cage to prevent this? Maybe a little paranoid, but if your threat model requires it, then surely Faraday cages would make sense no?
  • sharikous 4y ago
    How is that relevant? Sure in very specific threat models you want to run in a Faraday cage. People already do so if they build for example alternative LTE network or they use device that leak in the RF. Also you need to isolate the power supply. But it has nothing to do with the article
    • night-rider 4y ago
      Thanks for pointing that out. I was just thinking if you want to exfiltrate secrets then you need some sort of network to pass them on remotely. An air gap stops the secrets being leaked. Are you saying you can exfil by merely having access to the power?
• planb 4y ago
  Ok, I See how this works in theory. But until I see an exploit that uses this method in real life to extract keys (or maybe any memory content) from a server running real life workloads, I am extremely skeptical. How much samples are needed to get anything useful? And wouldn't the time required to acquire these samples be longer than the time required to detect the attack (or even all keys to be shifted)?
  • klysm 4y ago
    > time required to detect the attack Personally I haven't seen much of this done in the real world.
    • melenaboija 4y ago
      Not trying to be disrespectful and it is true curiosity, what is your role to have to deal with this type of attacks (as much as can be disclosed) and could you please quantify “much”?
    • CamperBob2 4y ago
      I haven't seen ANY side-channel timing attacks performed in the real world, but that doesn't stop the Security Theater crowd from costing us hundreds of millions of dollars and megatons of unnecessary carbon emissions by slowing everyone's CPU performance on the grounds that everyone's threat model is the same.
      • ziddoap 4y ago
        There are several (dozens) of papers showing the practicality of various timing attacks written by highly respected academics. Just because you haven't stumbled across an attack in the wild one does not somehow invalidate that there are practical attacks. Do you expect those who do carry out a successful attack to email you and let you know of their success? Or perhaps you think they'll exploit someone, and follow it up with an academic write-up of how they carried out that exploitation, to be widely published? While security theatre does exist, it's laughable to write off an entire class of vulnerabilities as theatre.
• rdpintqogeogsaa 4y ago
  What's the impact on AES-NI specifically? If hardware AES is impacted and no microcode updates are coming, this would be bad news. Assuming ChaPoly needs expensive masking mitigations and AES-NI is safe, ChaPoly just became a lot less attractive, too.
  • adrian_b 4y ago
    Neither AES-NI nor ChaPoly can be influenced by this vulnerability, because they do not use the secret key with different kinds of instructions, that might consume different powers. The secret key is used only in XOR operations. Other secret state of the ciphers is also used only in simple operations, e.g. XOR, additions and rotations, where there is very little variation of the power consumption depending on the operand values. The cryptographic algorithms that have chances to be influenced are those based on public keys, which compute arithmetic operations with large numbers that can cause changes in the clock frequency.
• rowanG077 4y ago
  jokes on them I disable turbo boost on all my machines because modern portables can't handle turbo boost anyway.
• jessermeyer 4y ago
  If the frequency scale is known to user applications, I presume jittering response times proportional of the scale factor just before write() would be effective.
• phamilton 4y ago
  A lot of people here commenting about shared hosting in clouds, but I don't see any actual text that shared environments are more vulnerable. It sounds like a black box timing attack that could target my laptop, my phone, my server, anything that does cpu frequency scaling and is performing a computation that is susceptible to this attack. Is that accurate?
  • rocqua 4y ago
    Shared hosting is where an attack like this is most useful. Because you don't need remote code execution on a (virtual) machine. You just need to happen to be colocated with it. For RCE on a laptop, server, phone, etc. You just need privilege escalation to get equivalent access, which tends to be easy.
  • mastax 4y ago
    Your devices probably aren't responding to unsolicited network requests from the internet.
    • phamilton 4y ago
      But they do run arbitrary javascript code in my browser.
• Symmetry 4y ago
  I did my MEng, in part, on analyzing data dependent power usage in adders and I'm sort of embarrassed I didn't think of this.
• Geee 4y ago
  Isn't it possible to monitor for this type of attack, and then apply mitigations?
• xiphias2 4y ago
  Is the libsecp256k1 library affected? How hard is to fix it?
• nequo 4y ago
  Naive question: Would another possible defense be for the kernel to introduce a small random delay in the task scheduler?
  • rocqua 4y ago
    You would need to block access to high-resolution time sources. Because all an attacker needs is accurate measurement of how long code ran.
    • nequo 4y ago
      > Because all an attacker needs is accurate measurement of how long code ran. So would it thwart the attack if the kernel added a random delay to the execution time?
      • IncRnd 4y ago
        It wouldn't, not by itself. The attack would take more measurements to create a profile, however. Extending the time required to mount an attack is probably not sufficient to thwart an attack. It could be for some workloads, but not for all.
    • ibejoeb 4y ago
      I think the intention here would be to provoke random jitter. So rather than trying to fight it with constant-time algorithms that turn out not to be under certain conditions, we make all the timing unreliably measurable. I think the terminology is little awkward. It's not algorithmic constant time, and it's not wall-clock constant time, but, I suppose, clock rate-relative input-independent time. So the options are 1) don't change the frequency, which has systemic negative effects, or 2) start with input-independent timing and purposefully skew it.
• nullc 4y ago
  Some cryptographic implementations are blinded such that as the number of attempts increase the amount of 'secret' data recovered (e.g. via power/emi sidechannels-- which this acts like) also increases. If the rate of uncertainty increases faster than the rate of leaked data, then the attack should fail.
• sandworm101 4y ago
  Seems like the simplest way to mitigate is to randomly throw some junk at the problem. Some random cypto code, some random no-purpose cryptographic calculations, should prevent any listener from gaining any useful information. It shouldn't take much, a single-digit percentage increase during cypto functions would be enough imho.
  • snowwrestler 4y ago
    Essentially, a computational time salt.
    • sandworm101 4y ago
      There are a dozen names for it. In the intelligence world, if you know that the enemy is listening on an unencrypted communications pipe, but you cannot afford to stop using that pipe, you throw random junk down the pipe until they cannot tell real from fake.
      • IncRnd 4y ago
        Excellent point. In this case, the name used here is masking, referring to what is called data masking, and the reference was to adding noise. There are other operations(as you point out) that could also be used (substitution, shuffling, etc.).
  • colinsane 4y ago
    well, yes. if you’re an NSA-level actor your AES implementation hasn’t been `AES_encode(key, input)`, but `AES_encode(key, input, random)`. you then XOR the randomness into the input, do all your (modified) AES operations, and then XOR the randomness out [1]. the modified AES operations take about double the area/power because your “input” is effectively twice as long as it used to be, but there’s now next to zero correlation between input/key and power use. like most things, i expect the reason they’re not adopted for consumer devices is because they use notably more power/area/are slower. [1] enter "Provably Secure Masking of AES" into scihub and you'll find a useful paper by Blömer, Merchan and Krummel from 2004.
• Sephr 4y ago
  We need an industry-wide effort for coordination between cryptography library owners & device/chip vendors to ensure the use of constant CPU frequencies during cryptographic operations. It's odd that the authors haven't chosen to initiate this themselves, as it seems like the proper solution to this vulnerability.
  • samus 4y ago
    There are no "cryptographic operations" on the hardware level. It's just normal math, therefore cryptographic code would have to give hints to the processor to enable such countermeasures. Such a facility does not seem to exist yet, and this is why this vulnerability is considered to be unfixable. In comparison, there were workarounds for Spectre because compilers can emit code where the processor cannot apply the dangerous optimizations. There are special CPU instructions to help speed up cryptographic algorithms, but applying countermeasures to these is not always crucial. They only matter if an attacker could otherwise create a side-channel. This applies in TLS, but not, e.g., when verifying checksums of downloaded software.
    • Sephr 4y ago
      > therefore cryptographic code would have to give hints to the processor to enable such countermeasures. Such a facility does not seem to exist yet, and this is why this vulnerability is considered to be unfixable That is what I am describing. I am proposing that we need to implement these facilities in firmware/microcode.
• willcipriano 4y ago
  > This means that, on modern processors, the same program can run at a different CPU frequency (and therefore take a different wall time) when computing, for example, 2022 + 23823 compared to 2022 + 24436. I'm a layman when it comes to things this low level however, I always assumed that different addition inputs would take different amounts of wall time, but looking it up it turns out that in theory I was wrong, but I guess I'm actually correct. ¯\_(ツ)_/¯
  • syrrim 4y ago
    Adding individual bits can be parallelized, as long as there is no carry. If there's a carry, then we have to wait for it to be computed and propagated. Compare adding 0b01111011 + 0b00000001, versus 0b01111111 + 0b00000001. If we first compute the sum of each pair of bits, then recompute if there's a carry bit, the first will complete after 3 cycles, whereas the latter will complete after 8.
    • FartyMcFarter 4y ago
      It doesn't seem that this affects wall time for a single addition though, at least on typical x86 CPUs. If you look at Agner's performance tables [1], ADD instructions always take the same number of cycles. I'm not a hardware expert, but I'm guessing that what's happening here is that transistors get hotter with certain input values more than others. Eventually this results in higher overall CPU temperature and a lowering of CPU frequency to compensate. [1] https://www.agner.org/optimize/instruction_tables.pdf https://www.agner.org/optimize/instruction_tables.pdf
• jl6 4y ago
  Assume you’re a tenant on a cloud service provider and you don’t care about power consumption… can you mitigate this by running a process with a busy loop that forces the CPU into max frequency at all times, with `nice` set to run it at lower priority than your actual workload?
• iueotnmunto 4y ago
  An awesome attack vector and kudos to the authors. I do wish it had never been discovered for environmental reasons though :(
• Strilanc 4y ago
  Sometimes I wonder if the main use of quantum computers will just be to verifiably have no side channels, because any such side channel would act as a measurement (which produces phase errors that you can check for). It wouldn't be efficient but the computation would be provably isolated from the rest of the universe. Well... other than the input at the start and the output at the end.
• sam0x17 4y ago
  So I take it when they say "constant time" for things like SIKE, they aren't sleeping for X milliseconds, but are just using some operation that is thought to be effectively constant time, hence this vulnerability? What is the countermeasure for this? Are crypto systems that always wait a full second using system timers, for example, immune to this sort of thing, or is it still detectable even in those circumstances?
  • syrrim 4y ago
    >Are crypto systems that always wait a full second using system timers, for example, immune to this sort of thing No. Such a crypto system would still leak information via the amount of power it consumes, which might change the frequency of the cpu, which could be measured by an attacker through the other processes of the computer.
    • sam0x17 4y ago
      ah ok I was assuming over public internet timing attacks. This requires local hardware access or a local ssh account. Got it
• mike_hock 4y ago
  Why do we never get proactive defense against this sort of thing? As with speculative execution, caching, out-of-order execution, dispatching instructions to multiple ALUs depending on availability, etc, it was clear from the get-go that in principle the timing can depend on the payload so in principle it can be a problem for crypto. The need for constant time should have first class support on the language/compiler level, the OS level, the ISA level, and the hardware level. E.g. the processor could guarantee that the instructions of a certain section of code are executed at a constant rate, the OS could guarantee that the thread remains pinned to one core and the frequency fixed, and the compiler could guarantee that only branchless assembly gets emitted.
  • p0ckets 4y ago
    Until consumers demand this as a requirement, it won't happen. Almost everyone would rather have a compiler/language/OS/ISA/CPU that's finishes faster some of the time, rather than one that finishes at the same time all the time. It would just appear (especially in benchmarks) to be slower for no apparent benefit. Maybe we can introduce a new set of instructions that are guaranteed to be constant time, but good luck convincing the compiler/language/OS to use these slower instructions even if just for the code that is important for security.
    • p0ckets 4y ago
      And for this particular attack, constant time isn't even enough! You would need either constant power, or limit the frequency when running secure code (which again reduces performance).
      • Atheros 4y ago
        Constant time comparisons take practically no time at all. I hardly see how it would noticeably reduce performance if software could command a CPU to lock to a low frequency for a certain period of time or when the sensitive code finishes, whichever happens first. The OS could track how often this happens and give a simple UI so that we can blame those applications that abuse it.
• Starlevel001 4y ago
  It's so cool that x86 is completely fucked security-wise because of all the perf hacks that have been introduced - and yet, computers never seem to get any faster.
• forrestthewoods 4y ago
  Can someone explain this to a non-crypto expert? I understand the concept that information can leak via timing measurements. However I don’t understand how this can extract the exact bits of a signing key from this?
• phendrenad2 4y ago
  Wow, I didn't know that frequency scaling on CPUs was a function of the workload being processed, I thought it was a function of CPU temperature, which would be much less easy to glean meaningful data from (presumably it has a large deal of hysteresis, and you'll have to somehow run a computation millions of times and then run another computation millions of times and compare them). I'm not convinced that I'm wrong.
• samus 4y ago
  Would it help to slighty reduce the granularity of the frequency adjustment? Just enough to make the analysis infeasible? It doesn't have to be all or nothing. We had a similar issue with browsers restricting access to high-precision timers in JavaScript.
• eixiepia 4y ago
  Can this attack be used to extract Widevine decryption key?
• ancientsofmumu 4y ago
  This paper relies on Turbo P-states, where they measure the oscillation when that is active; it is not measuring general SpeedStep (OS software controlled) as some seem to have taken away from it. Turbo state is the HWP (hardware P-state controlled) layer above SpeedStep; turning off Turbo in the BIOS still fully allows OS controlled SpeedStep P-states to function, it just disables the hardware level bursting P-states above that max listed CPU level for short periods of time. As others have noted, Turbo state can really kill a laptop battery and/or drive up the thermals pretty quick, a lot of folks disable it anyways if they've tinkered around before. The abstract writes it as "When frequency boost is disabled, the frequency stays fixed at the base frequency during workload execution, preventing leakage via Hertzbleed. This is not a recommended mitigation strategy as it will very significantly impact performance." This is a confusing grammatical way to state it, as SpeedStep will still work at the OS layer, you'll scale min to max "as usual" and just lose temporary hardware boost max+ capability when under stress (full load at P0 state) - not really "fixed" as it were in layperson's terms. That would be more akin to saying SpeedStep had to be disabled, IMHO. https://www.kernel.org/doc/html/v4.19/admin-guide/pm/intel_pstate.html#turbo https://www.kernel.org/doc/html/v4.19/admin-guide/pm/intel_p...
  • _0w8t 4y ago
    On MacOS Low-Power mode in the Power section of system settings disables turbo-boost. On Linux echo 1 > /sys/devices/system/cpu/intel_pstate/no_turbo does the rick. Note that this is not the same as power-saving mode in Gnome settings. I have found that for heavy C++ compilation that lasts for many minutes the slowdown was about 20% on my ThinkPad X1 laptop. The big plus is that it made the laptop almost silent.
    • ancientsofmumu 4y ago
      I think you're running into changing the governor mode here, which is a related but different part of the same ballpark. Modern Intel even has a "bias hint" allowed in addition to just a governor, where the user can help tell the power saving features what tradeoffs they prefer; power-saving mode is an additional limitation in conjunction with SpeedStep (or Turbo) P-state use; if the laptop is almost silent (no fans) you're surely clocking it down to avoid heat/thermal buildup (no fans) - this is usually used to conserve/extend battery to the max possible, at the expense of CPU clock speed. The Arch Wiki has a nice page outlining all of it, there's a lot of knobs to twiddle. https://wiki.archlinux.org/title/CPU_frequency_scaling https://wiki.archlinux.org/title/CPU_frequency_scaling
• mochomocha 4y ago
  Given that cloud providers oversubscribe their rack power supplies for $ reasons, I'm waiting for the cloud-level equivalent of this DVFS attack, where you throttle a competitor cloud instances by bursting on collocated instances of yours :)
• FartyMcFarter 4y ago
  > This means that, on modern processors, the same program can run at a different CPU frequency (and therefore take a different wall time) when computing, for example, 2022 + 23823 compared to 2022 + 24436. I'm not a hardware expert, and I was a bit surprised at this. Is that because the transistors heat up more with certain input values, which then results in a lower frequency when the CPU gets hot enough? Something like AND(1,1) using more energy than AND(1,0) on the transistor level? As far as I can tell [1], addition typically takes a constant number of cycles on x86 CPUs at least, so any difference should happen at a very low level. [1] https://www.agner.org/optimize/instruction_tables.pdf https://www.agner.org/optimize/instruction_tables.pdf
  • simias 4y ago
    Not an expert either but number of cycles is not everything, transistors that transition use up more energy than those who remain in the same state. As such it's possible that 0x00000000 + 1 uses up significantly less energy than 0xffffffff + 1, just because of all the bit flips. That's just a guess though.
    • userbinator 4y ago
      That is exactly the principle behind this. A small quantity of energy needs to be consumed to flip a bit.
  • SilverBirch 4y ago
    I've got some background in FPGA development, and you can actually design for this effect. We literally have tools where you can plug in simulated activity and the tool will tell you how much dynamic power the chip will use and therefore what power & cooling you'll need. It works exactly as you say - different inputs are going to cause different numbers of transistors to need to switch every cycle and switching draws more power. So if you have a transistor that goes 1->0->1 every other cycle, that'll draw more power than a transistor that's just sitting at 0 the entire time. Then, since modern CPUs have frequency scaling (fpgas generally don't) you can observe that a high switching rate would increase the power consumption which increases the heat and therefore causes the CPU to scale down the frequency.
• Rafuino 4y ago
  Why did they wait 2 extra quarters to tell AMD about this?
  • jagger27 4y ago
    It probably didn't matter too much since Microsoft and Cloudflare were notified at the same time as Intel. Both of them run AMD hardware in their datacenters. It does seem weird though.
    • Rafuino 4y ago
      Yeah but I wonder whether the users can tell the vendor under disclosure rules. It is really weird that they didn't tell AMD at the same time!
• laserbeam 4y ago
  This is why we can't have nice things, dear security researchers.
• orblivion 4y ago
  As I've said before, these announcements could benefit from better "action items" or "TLDR" for the average person with other problems to think about. What libraries are affected, what do I need to upgrade exactly, on Ubuntu, etc etc. And I'm guessing this is intended to reach those people (among others) given the effort they put into the graphics, etc. In this case. "Am I affected?" "Likely, yes. It's on all the CPUs". Okay, but how does this work exactly? Is the Hertzbleed going to take over my computer and steal my private keys from my hard drive? Do I need to be running a server? Do I need to be in the middle of a cryptographic operation with the key in question? Etc. "What is the impact" Ah, this sounds like the useful part. "...modern x86 cpus... side channel attacks...power consumption...constant-time execution". Nope, this isn't it either. I think this is simply a matter of being so deeply embedded in something, one forgets how much is assumed. If they showed it to an outsider first they'd get the necessary feedback.
  • bruce343434 4y ago
    I got the same feeling, how does this apply to me?
  • IfOnlyYouKnew 4y ago
    There really isn't anything for the "average person" to do here, who wouldn't understand any of your questions, either (the library? The one with all the dirty books?)
    • orblivion 4y ago
      What about the average reasonably computer savvy person? Also "don't worry about it" or "there's nothing you can do for now" is an answer.
  • orblivion 4y ago
    I'm sorry, sometimes (often) it's my reading comprehension. The answer I was looking for was in the first f-ing paragraph. (And I checked archive.org, it was there yesterday) "In the worst case, these attacks can allow an attacker to extract cryptographic keys from remote servers that were previously believed to be secure." I'll probably have more to complain about the messaging when a fix comes out, but for now mea culpa.
• eternityforest 4y ago
  I suppose future systems will just run crypto operations at a fixed speed, and turn dynamic stuff back on when they're done?
• tails4e 4y ago
  Is it not possible to add noise by running other processes in parallel that will also cause frequency boosts to occur and colour the results? Bauscilaly the mitigation is to disable boost, but instead boosting more often or boosting in a controlled way (with another process triggering it) should so help mitigate.... That said if it was thst trivial, surely intel or someone would suggest it.
• tails4e 4y ago
  Is it not possible to add noise by running other processes in parallel that will also cause frequency boosts to occur and colour the results? Bauscilaly the mitigation is to disable boost, but instead boosting more often or boosting in a controlled way (with another process triggering it) should so help mitigate.... That said if it was that trivial, surely intel or someone would suggest it.
  • Too 4y ago
    Noise helps to increase the difficulty, but with a large enough sample size you can statistically exclude it, greatly simplified but essentially by doing X-avg(all X). Imagine you do the above bit for bit. So first you sample 1M times to find the baseline, then flip one bit and sample another 1M times to see if any deviations, and so on. There is also the chance of your PRNG being predictable, so attacker can predict what noise will be generated if they have seen enough of it.
    • tails4e 4y ago
      True, but is it reasonable to assume the same key would be used for long enough on a go en operation to allow averaging to help? The mitigation only needs to work practically, not in a worst case theoretical situation.
• nickskull 4y ago
  Would this apply to M1 Macs as well?
• abiro 4y ago
  Which ARM processors could be affected? Can't find an overview of ARM processors that implement frequency scaling.
  • drvdevd 4y ago
    I’m wondering the same thing but I’m curious if the heterogeneous nature of modern ARM processors is essentially equivalent- if you can get the same crypto primitive to run first on a P-core and then an E-core, can you measure the difference for a similar effect?
• SilverBirch 4y ago
  That first paragraph is perfect. It's an exact description of the concept and it's impossible to know whether this is a shower thought or whether 1,000 Intel engineers are going to spend the next 3 years added RNGs to their clock generation circuitry.
• Dwedit 4y ago
  If you're already executing native code on the machine, you probably have the ability to read and write all the other memory of every other user mode process, so you don't need this to attack cryptographic keys stored there. This attack is more against secure enclaves.
• codeulike 4y ago
  This reminds me of: In the 90s I rememebr hearing a story about someone hacking a supposedly 'impossible' remote machine for a competition - they did it by analysing the response times and using that info to derive the key - at the time, a novel approach. Can anyone remember the story I must be dimly remembering?
• dkbrk 4y ago
  I think it's worth noting that the main attack described in the paper, against SIKE, depends on exploiting some behavior peculiar to that particular algorithm (what the paper calls "anomalous 0s"): > The attacker simultaneously sends n requests with a challenge ciphertext meant to trigger an anomalous 0 and measures the time t it takes to receive responses for all no requests. When an anomalous 0 is triggered, power decreases, frequency increases, SIKE decapsulation executes faster, and t should be smaller. Based on the observed t and the previously recovered secret key bits, the attacker can infer the value of the target bit, then repeat the attack for the next bit. While any leakage of information can in be exploited in principle, it might be that this technique is impractical against a target which doesn't exhibit some sort of behavior that facilitates it.
  • staticassertion 4y ago
    I think SIKE was just chosen because of its relevance, not because it has any particular issues that make it more susceptible. I'd be curious to hear from an expert on this.
    • avianes 4y ago
      SIKE is definitely not the most widely used cryptographic algorithm. And as the paper points out: > In our attack, we show that, when provided with a specially-crafted input, SIKE’s decapsulation algorithm produces anomalous 0 values that depend on single bits of the key. It was clearly selected for this property. The attack allows to determines the number of 0s and 1s in words processed by an algorithm, so they chose an algorithm that has specific data outcomes which will produce a measurable power effect.
      • staticassertion 4y ago
        I didn't think it was widely used, I'm sure it's very very rarely used. I was saying it was relevant because it represents the "future" of cryptography. I would think that any kind of key exchange algorithm that relies on a constant time algorithm is vulnerable to this. I could be wrong.
• shahar2k 4y ago
  would quantizing the boost to a few specific levels or even randomizing the levels mitigate something like this?
• FrostKiwi 4y ago
  I do wonder, if only the Turbo P-States are what cause the vulnerability. Is relying on Deep C-states for instance an alternative to get power savings? On my server during idle, when cores enter C6, the power savings are at their maximum and no frequency scaling can match that. Why not just rely on that? (Ignoring the loss of turbo boost ofc)
• sim7c00 4y ago
  honestly, i dont think this is some universal remote exploit, despite it being remotely exploitable. under certain circumstances seems a keyword here.. this is incredibly clever and devious, but mostly i think practical locally. since different cpus have different power usage, and systems roll different configurations, id expect the most reliable use case would be for instance to roll a custom os on a confiscated device to learn what power throttling patterns it has related to this kind of attack and then perform that on the systems original installation to decrypt it. (something along those lines). I think, maybe better in a counter example, that it is unlikely that someones online service or personal system would be ever exploited by this. why? because the system runs a lot of threads in general when its being used, making it much harder to predict what measurements mean what. if a system is not idle during the attack, its hard to deduce if timing diffetences are related to the attack or for example just other tasks/threads being executed during the attack. am i wrong?
• throwaway81523 4y ago
  I haven't looked at the article but this sounds like a local exploit, right? Those were important in the timesharing era, but with personal computers we temporarily had an era when we didn't have to let hostile code run on our computers. When will we learn that we shouldn't have given that up? Local exploits will never go away, at least on high performance machines.
• wly_cdgr 4y ago
  The amount of time and energy that's wasted because people insist on having secrets is absolutely insane
  • teaearlgraycold 4y ago
    Can I get your bank account username and password?
    • notatoad 4y ago
      sure. i have a computer that's vulnerable to hertzbleed. do your worst.
      • teaearlgraycold 4y ago
        That account’s as good as drained, kiddo
• walrus01 4y ago
  > What can you do about it? Nerf your CPU performance by disabling "turbo boost" or equivalent. Should you do it? Probably not unless you're particularly vulnerable (journalist, human rights activist, etc.) Would not another option be to do something that temporarily maxes out the CPU and forces it into boost mode, immediately prior to executing the crypto operation? But not for such a long duration that the CPU reaches any thermal limits and decreases its speed again. Obviously energy inefficient and not good for laptops or portable devices.
• userbinator 4y ago
  I don't care! There, I said it. I didn't care about Spectre, Meltdown, or any of the other obscure timing side-channels that came after them either, because they relied on so much detailed information about the environment being attacked that you'd almost certainly be able to get the information you wanted by some much easier way. Attacking something that doesn't seem to be in much use either doesn't make me any more worried either. Go after e.g. TLS, SSH, AES, RSA, etc. if you want to get our attention, but I suspect that trying this in practice, you're going to be overwhelmed by all the other sources of noise --- especially over a network connection -- that you won't be very successful at all. They mention 36h and 89h to get the key (few dozen bytes), and I assume that was in a basically ideal environment with nothing else to measure. Those of us familiar with hardware would know that things like this are pretty natural; but unlike these people, we don't go feeding the paranoia machine and driving us even more towards the growing dystopia.
  • selcuka 4y ago
    > they relied on so much detailed information about the environment being attacked A disgruntled, previous employee may easily have access to such information, but nothing else because their credentials had been disabled.
    • kelnos 4y ago
      I think you overestimate what kind of information most employees -- even those who build the software that runs on their servers -- have about their execution environments.
      • iratewizard 4y ago
        Sure, but at one point in time I had the names, addresses, social security numbers, DoBs and in-patient statuses of around 20k people. I didn't want it or like that it was there, but it was due to carelessness. Or the time I found a client database was actually a flat file with usernames, emails and passwords in plain text. Hertzbleed is out of a sci-fi movie. The stuff a lot of developers come across is not exploited sheerly out of professionalism.
• fijiaarone 4y ago
  Here’s a simple mitigation — don’t have your encryption depend on 2022 + 23823 being compared to 2022 + 24436. The idea that a cpu frequency change (based on cpu load) could be detected, and if detected — that it could lead to any useful information by an attacker is laughably preposterous. The only theoretical vulnerability is if someone in a shared data center was able to gain control over a system on dedicated hardware that had nothing else running on it — exploit some code on it that triggers and expected frequency — open the cage and case, detects the frequency (by turning off all other hardware in the vicinity — meaning you already know which machine it is) and then by exploiting the machine you already control (and have already isolated) you can then physically identify the machine you have exploited.
• kccqzy 4y ago
  > We disclosed our findings, together with proof-of-concept code, to Intel, Cloudflare and Microsoft in Q3 2021 and to AMD in Q1 2022. Why did they choose to disclose their findings to just two software companies (Cloudflare and Microsoft)? Why not other software companies like Amazon or Google? Or developers behind open source cryptography libraries?
  • agucova 4y ago
    The attack in question was only tested on SIKE, so it seems logical to start targeted disclosure on the community using and developing it, while using the general disclosures to target the broader cryptographic community. Both Cloudflare and Microsoft are one of the few companies that have put significant investments into developing SIKE for post-quantum cryptography. Microsoft has a SIKE research team, and Cloudflare has been exploring SIKE for post-quantum TLS for years. Both companies also maintain the key open-source implementations of SIKE [1][2], and Microsoft is spearheading the effort to standardize SIKE through NIST. Most open source cryptographic libraries don't implement SIKE. [1]: https://github.com/cloudflare/circl https://github.com/cloudflare/circl [2]: https://github.com/Microsoft/PQCrypto-SIKE https://github.com/Microsoft/PQCrypto-SIKE
    • fomine3 4y ago
      But it seems that SIKE isn't widely deployed yet. Should it be preferred?
      • agucova 4y ago
        SIKE is promising, but lacks research and maturity. It is mostly not ready for real-world use.
• sydthrowaway 4y ago
  It’s clear the secure enclave was a genius move a decade ago.
• dcow 4y ago
  Isn’t the real long term mitigation here to do all crypto operations on a separate chip? Rewire platform libraries to use the TPM/SecureEnclave backends exclusively. Then if you need “soft crypto” you are kinda on your own in “you better know what you’re doing” territory?
• justinclift 4y ago
  From the AMD advisory, it seems like desktop Ryzen 5000 series aren't affected, nor 3rd gen and later EPYC. Pretty much everything else is: https://www.amd.com/en/corporate/product-security/bulletin/amd-sb-1038 https://www.amd.com/en/corporate/product-security/bulletin/a...
  • WXLCKNO 4y ago
    Not sure why though, my 5900x has precision boost. Wonder what's different.
• nayuki 4y ago
  Is the long-term solution some kind of balanced binary encoding where two wires represent a bit, with exactly one wire high and one wire low?
• umvi 4y ago
  Can't wait until 2050 when all of our computers are bogged down with energy hungry security chips and processors that barely get any real work done because the security arms race demands ever increasing resources...
• theicfire 4y ago
  Hmm, it feels like Intel/AMD are ducking and just hoping that the implications of this are not large. Here's a video from Intel chatting with the researchers: https://community.intel.com/t5/Blogs/Products-and-Solutions/Security/Chips-Salsa-Episode-19-June-2022-Security-Advisories-Hertzbleed/post/1392094 https://community.intel.com/t5/Blogs/Products-and-Solutions/... The questions are incredibly weak from the interviewers. They first state that it's not practical because the attack could take many hours, even days. But they don't describe why a day-long attack is not practical. They then bring the researchers and ask them the same question. The researchers say that the attack is very practical because it only takes.. a few hours or days to execute the attack. Here's the specific part: https://youtu.be/BiRPr839dSU?t=1476 https://youtu.be/BiRPr839dSU?t=1476 Instead of chatting more about this discrepancy they just ignore it and ask the researches how they feel about their new popularity. From what I can tell from the advisory from Intel, it's simply that people should understand the attack and mitigate it in software. It's very vague. The specifics (i.e. a list of example popular programs that are vulnerable) seem entirely missing.
  • mike_hearn 4y ago
    What you're seeing here is a collision between academic cryptography culture and real world engineering culture. In particular, the word "practical" has very different meanings in those two worlds, hence the discrepancy. In engineering, the word "practical" has an expansive definition that takes into account end goals, likely costs, rewards and risks of getting there, whether better approaches exist and so on. In academic cryptography the word practical is used far more narrowly and means something like: this algorithm doesn't only exist on a whiteboard, we wrote a toy implementation of it as well. There are people in this thread telling each other how to disable power scaling and stuff. They're probably people who take the claim of "real and practical" literally without realizing what this does(n't) mean when coming from academics. If you read the paper you'll notice a lot of aspects about the attack that aren't actually practical at all, so to believe this is a threat worth spending time on requires a lot of assumptions about unknown developments that may not hold. To name just a few aspects of "practicality" that engineers might care about but the paper authors do not: 1. The attack requires DoSing the target server for extended periods, like days at a time, without being detected. Do you have CPU load or bandwidth monitoring in place? Then you're going to detect the attack within minutes of starting before it got anywhere at all and can simply block the attacking IPs. 2. The attack is only demonstrated against specific crypto libraries and algorithms that you're almost certainly not using. You're asked to assume it can be easily applied against normal algorithms, but their technique relies heavily on the exact mathematics and implementation schemes they're attacking, so it's not entirely obvious how easily it can be adapted. Presumably they chose this obscure target for a reason. 3. The attack was demonstrated on a perfectly unloaded system in which the server does nothing except cryptography and has no other users. Given how sensitive it is to tiny timing fluctuations, it seems like more or less any other activity would raise the noise level so much that days of DoS attacks might turn into months or years. You're asked to assume this isn't a problem for the attackers, but that seems like a very unsafe assumption. 4. The attack was demonstrated on a machine that's in the same datacenter as the machine being attacked (~600 microseconds of latency to the server). Are your machines in a private colo facility where the owners know who is renting their servers? Well then, the attackers are going to be pretty quickly detected and investigated by the authorities aren't they, because there are no valid use cases for DoSing a server right next to your own for days at a time with carefully crafted crypto packets. 5. What about the cloud? Pretty easy to get machines there, but you also can't control whereabouts you get placed. I read another paper where researchers tried to do remote timing attacks on machines in AWS. It requires massive amounts of descheduling and rescheduling VMs in the hope that eventually you get lucky and the scheduler places you near enough to the victim. That pattern is extremely distinctive, has no real legitimate use cases and AWS could very easily detect and it shut it down if this sort of attack ever became an actual problem. But of course, such obvious mitigations don't get mentioned in these papers. 6. Is this really the easiest way to snoop on traffic? Why not just search for a classical vuln in the client or server software itself? It's not like there's a shortage of those. Just weeks ago it turned out Jira was vulnerable because it was shipping a library last updated in 2005. If this attack is the best way to achieve a specific goal it means you're going up against an unusually well hardened target such that all other means of entry like phishing, hacking, government intervention, physical attack etc are less practical than this. Very few organizations will meet that level of security. As you can see, once you expand the definition of "practical" to include consideration of everything a real attacker would care about end-to-end, like not being detected, and succeeding against real servers doing actual work that are monitored by humans, the whole thing starts to look very questionable indeed. Frankly I find it a bit irresponsible that they've named it Hertzbleed. The original Heartbleed attack was quite practical and let you dump the memory contents of real world servers at will. People demoed it on random Cloudflare edge nodes and the like. It required an immediate response by many, many people. Now we have a website that looks nearly identical to the Heartbleed website - it has a similar name, a a logo, a similar FAQ, talk of "patches" by CPU vendors, etc. But when we read the paper there's no similarity between the attacks really. It's just another case of academics exaggerating their work for the sake of getting a paper and it needs to stop.
• throwaway742 4y ago
  Overclocking FTW
• sph 4y ago
  Aside: giving a new exploit a catchy name, a top level domain and a logo doesn't make it more dangerous that it really is. After Heartbleed, this trend is becoming common and annoying and feels more and more like crying wolf.
  • qayxc 4y ago
    Agreed. Especially considering that the main threats are still good old social engineering and gullible users downloading and running malware. Attack vectors like Hertzbleed require considerable resources, detailed knowledge about the target (in order to get the required preconditions right), and as others pointed out are easily detectable.
• _8j50 4y ago
  Can't intel and amd just change how long a core stays at a turbo frequency to mitigate this? I.e.: if it scales up by 1hz, it can't scale down by that much until N number of cycles.
  • zgs 4y ago
    This would add noise to the measurements which should cause an exploit to take longer but it wouldn't prevent the exploit.
    • _8j50 4y ago
      Pardon my ignorance but why wouldn't sufficient noise make it practically impossible to timing attacks. Very short secret material being processed multiple times?
• Gelob 4y ago
  How was cloudflare chosen over say linux foundation or red hat to disclose
• AtlasBarfed 4y ago
  So would this rely on a known compiled binary they could reliably project/simulate/anticipate? This seems vaguely like when they would use page fault boundaries to extract passwords. An OS/hardware event that occurs within some if-then to leak parts of the "key". Do we need some sort of "random delays" or binary execution randomization?
• _tk_ 4y ago
  Djb says: „This particular attack demo succeeded with toy models and toy signal processing, so I'd expect state-of-the-art models and state-of-the-art signal processing to extract secrets from many more programs, _except_ when users protect themselves by setting constant CPU frequencies.“ https://twitter.com/hashbreaker/status/1537188851440943105 https://twitter.com/hashbreaker/status/1537188851440943105
• mFixman 4y ago
  Can anyone ELI-CS graduate this vulnerability? My understanding from reading the page is that modern processors process certain data with higher frequency, and somehow that allows an attacker to know guess private keys. However, I don't understand the connection between those two things. How would an attacker trigger a lot of almost-identical CPU runs without hitting some rate limit somewhere? And how is this different than just guessing the password?
• midislack 4y ago
  Yet another embargo assented to, which appears to be pointless. Maybe the spy agencies wanted time to develop an exploit? Who knows. "Responsible" disclosure is cancerous.