[HN Gopher] Hertzbleed Attack
___________________________________________________________________
Hertzbleed Attack
Author : arkadiyt
Score : 705 points
Date : 2022-06-14 17:43 UTC (5 hours ago)
(HTM) web link (www.hertzbleed.com)
(TXT) w3m dump (www.hertzbleed.com)
| Dwedit wrote:
| 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.
| planb wrote:
| 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)?
| rfoo wrote:
| > How much samples are needed to get anything useful?
|
| There is proof-of-concept code for reproducing. I don't think
| sample count is a big concern.
|
| That said, I believe the real caveat lies in the "workload must
| run for long enough to trigger frequency scaling" part. Usual
| crypto primitives are just too fast on our processors, which is
| likely why they picked SIKE to demo the attack.
| samus wrote:
| SIKE is a very relevant example because we are slowly
| creeping toward a world where Quantum computing will be
| ubiquitous and existing asymmetric cryptography will face
| serious challenges.
| nickelpro wrote:
| We are nowhere near "ubiquitous" quantum computing. We
| aren't near _rare_ quantum computing.
|
| Quantum computing as a practical platform has yet to be
| proven feasible. When you ask people who know what they're
| talking about and aren't pitching for grant money, quantum
| computing is somewhere between decades away [1] and never
| happening [2].
|
| [1]: https://www.nature.com/articles/d41586-019-02936-3
|
| [2]: https://spectrum.ieee.org/the-case-against-quantum-
| computing
| gmiller123456 wrote:
| My bet is that you could write all of your passwords on your
| front door and still not be victimized in any meaningful way.
| But, in many/most cases, it's cheaper to thwart the attack than
| to analyze if it can be used to exploit your systems.
| klysm wrote:
| > time required to detect the attack
|
| Personally I haven't seen much of this done in the real world.
| melenaboija wrote:
| 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 wrote:
| 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 wrote:
| 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.
| nickelpro wrote:
| None of the attacks are feasible in a trusted
| environment. If your code isn't running in an environment
| where other processes from untrusted sources are also
| running, these timing side-channels and their mitigations
| are irrelevant.
|
| If an untrusted source gets shell access to your trusted
| platform/server/container and can run payloads, you're
| already screwed six ways from Sunday and the rest of the
| discussion is moot. It's security theater specifically
| because individuals and organizations following these
| blind mitigation recommendations don't assess the attack
| surface that's being exposed.
|
| A school teacher wearing a condom is strictly speaking
| safer than the alternative, and yet someone should still
| be fired.
| ziddoap wrote:
| Not all timing attacks require any sort of privileged
| access. As one example, OpenSSH had a timing attack where
| under certain configurations a query for a non-existent
| user returned faster than an existing user, allowing
| attackers to enumerate user accounts.
|
| I'm not saying this specific attack is something to get
| worked up over. But, as I have already said, writing off
| an entire class of vulnerabilities because you think it's
| all theatre is naive. Weighing each exploit against your
| attack surface, risks, and risk tolerance is not.
|
| > _It 's security theater specifically because
| individuals and organizations following these blind
| mitigation recommendations don't assess the attack
| surface that's being exposed._
|
| Blaming researchers for security theatre when it is the
| organizations which are not doing their due diligence is,
| at least to me, a weird way to look at things.
| nickelpro wrote:
| I don't blame the researchers, this is specifically
| against the nonsense discussions that plague this thread
| and others like it talking about the performance impact
| on personal computers. These side-channel bugs are minor
| annoyances, and mostly a problem for cloud providers.
|
| I wouldn't want Intel or AMD or anyone else to abandon
| speculative execution, clock boosting, or any other of
| the "vulnerable" technologies just because their unsafe
| in specific application spaces, which seems to be what
| half of HN starts advocating for whenever this stuff
| comes up.
|
| An application bug like OpenSSH is a completely separate
| spiritually from the hardware bugs that inspire these
| mitigation discussions.
| ziddoap wrote:
| I agree on almost all fronts.
|
| The person I replied to asserted that _all_ timing
| attacks are theatre, which I disagree with (and,
| evidently, poorly communicated my stance). Perhaps they
| did not mean the entire class of vulnerabilities which
| rely on some sort of exploitable timing difference, but
| only those that require privileged (or physical) access.
| In that case, I still believe it is foolish to completely
| dismiss them simply for being a 'timing attack' (and
| therefor theatre), but I also believe it is foolish to
| blindly follow mitigation recommendations without
| analysis.
| Syonyk wrote:
| > _If your code isn 't running in an environment where
| other processes from untrusted sources are also running,
| these timing side-channels and their mitigations are
| irrelevant._
|
| And then you put 'mitigations=off' in your kernel command
| line and go on your way. I do it for all my BOINC compute
| nodes, because they literally have nothing sensitive on
| them.
|
| But remember, L1TF/Foreshadow could reach across virtual
| machine boundaries. It's not just inter-process
| speculation that's a problem.
| nickelpro wrote:
| Yep, and yet everyone in this thread seems to be rushing
| to kneecap their own performance, for what? My laptop
| isn't a GKE node.
|
| There's a reason this CVE is classified as medium
| severity
| CamperBob2 wrote:
| I think the one-dimensional severity classification is
| part of the problem. If you're running a cloud provider,
| it's a much bigger deal. Call it "high severity" issue
| for those use cases. No objection to that, better safe
| than sorry.
|
| Probably 90% of PCs are single-user Windows desktops,
| though. It's a "nonexistent severity" issue for those use
| cases... yet we all get to pay.
| ziddoap wrote:
| > _. If you 're running a cloud provider, it's a much
| bigger deal. Call it "high severity" issue for those use
| cases. No objection to that, better safe than sorry._
|
| It's odd, because this agrees with what I wrote, and the
| parent to your comment says they "fully concur", yet they
| are arguing that I'm incorrect. I did a poor job in
| communicating.
|
| As an attempt to better clarify what I wrote: I agree
| with you that for the vast majority of people this
| specific attack is a non-issue. But, there are plenty of
| different timing attacks, and _some_ of those may affect
| _some_ people. It would follow then that _some_ timing
| attacks should not be abruptly dismissed simply because
| it 's classified as a timing attack.
|
| However, my initial comment was replying to someone who
| wrote off the entire class of vulnerabilities, asserting
| that no timing attack of any variety has been used
| successfully. I find this a naive approach to
| vulnerability management. Instead of dismissing all
| attacks that are classified as timing attacks,
| vulnerabilities should be assessed for what they can do,
| the ease of doing it, and the potential impact of a
| successful attack.
| nickelpro wrote:
| Fully concur, although now that I've read some of the
| white paper some of this doesn't even appear to be a real
| issue? Like the claimed "remote" attacks against,
| "Cloudflare's Interoperable Reusable Cryptographic
| Library (CIRCL) [28], written in Go, and Microsoft's
| PQCrypto-SIDH [65], written in C ... [are] meant to run
| in constant time"
|
| But they just straight up don't run in constant time, so
| they're vulnerable to a timing attack across the network.
| That's clearly just a library bug? Like surely the
| dumbest part of a "constant time" algorithm is double
| checking that you ran for a constant wall clock amount of
| time?
| Syonyk wrote:
| > _But they just straight up don 't run in constant time,
| so they're vulnerable to a timing attack across the
| network. That's clearly just a library bug? Like surely
| the dumbest part of a "constant time" algorithm is double
| checking that you ran for a constant wall clock amount of
| time?_
|
| It's... hard. A lot of the "constant cache behavior" and
| "constant time behavior" algorithms were written back in
| the day when the CPU speeds didn't change randomly on
| you, or at worst toggled between "idle" and "running
| hard." Think... oh, even the Core 2 days, really. They
| didn't switch that fast.
|
| And then the hardware behavior changed out from under the
| algorithms, and nobody noticed. Now the throttling is far
| more rapid. So they may still be "constant instruction
| count," but that no longer implies constant time.
|
| It's... complicated. :( And what's worse, even the people
| in charge of managing the complexity don't understand all
| the details anymore. When stuff like this surprises
| Intel, we've got problems.
| rdpintqogeogsaa wrote:
| 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 wrote:
| 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.
| tootie wrote:
| I'm mind-blown at this vuln being exploitable remotely. How is
| that possible?
| hatware wrote:
| Shared tenancy in cloud platforms.
| bri3d wrote:
| 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 wrote:
| Thank you for enjoying reading our paper!
| laserbeam wrote:
| This is why we can't have nice things, dear security researchers.
| rowanG077 wrote:
| jokes on them I disable turbo boost on all my machines because
| modern portables can't handle turbo boost anyway.
| nullc wrote:
| 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.
| halfmatthalfcat wrote:
| At first I thought it had something to do with the company
| Hertz...
| kzrdude wrote:
| It's just the German dub of Heartbleed that _finally_ showed
| up. The cast of voices is dull though
| frankus wrote:
| 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 wrote:
| 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.
| jessermeyer wrote:
| 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.
| mike_hock wrote:
| 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.
| mlyle wrote:
| > Why do we never get proactive defense ... The need for
| constant time should have...
|
| We got proactive constant time on a lot of cryptographic
| operations.
|
| The problem is, it's not constant power.. and DFS provides a
| window by which you can make remote power measurements.
| throwawaylinux wrote:
| That wasn't proactive it was in response to earlier timing
| analysis attacks.
| p0ckets wrote:
| 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 wrote:
| 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 wrote:
| 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.
| sounds wrote:
| Simplest solution here is to implement the algorithm in
| hardware, with a new instruction that has all the security
| attributes. (Including resistance to power differential and
| timing differential attacks.)
|
| Downthread: https://news.ycombinator.com/item?id=31745105
| mike_hock wrote:
| But this is inflexible.
| sounds wrote:
| True.
|
| But did you want a microcode vulnerability? That'd make for
| another one of these awesome HN discussions...
| SilverBirch wrote:
| This is engineering, there's a lot of things that could happen
| but don't, we don't all run ECC RAM either. The problem is that
| speculative execution is _really good_ and if Intel didn 't
| have it they would've been selling worse CPUs. And to be clear,
| it was about 20 years from the point where people were
| seriously publishing theories about speculative execution
| attacks to the point where it was a practical attack.
|
| Think about how much benefit we gained during that time. And
| even then, anyone running in a trusted environment would rather
| have the optimization consequences be damned. Do you think HFTs
| patched their boxes to criple their perfomance? No.
|
| Sure, now we know it's a problem we'll offer solutions for
| people who really need it. But it'll be a long while before the
| average person needs to think about this and in the meantime
| billions of people benefitted from better CPUs.
| goodpoint wrote:
| > we don't all run ECC RAM either
|
| ...because Intel placed profit above user's needs and choose
| not to allow ECC on desktops.
|
| Similarly, many other things have been made insecure by plain
| greed.
| gambiting wrote:
| The other way of looking at it is that a huge portion of
| the market is running non-ECC ram and it hasn't resulted in
| any measurable reduction of security or stability of
| operating systems worldwide. So maybe it _really_ isn 't
| necessary for your average user, and manufacturing ECC ram
| for users who ultimately don't need it would be just a
| waste(both financial and environmental).
| goodpoint wrote:
| > hasn't resulted in any measurable reduction of security
| or stability of operating systems worldwide
|
| Except it did.
| sandworm101 wrote:
| 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.
| colinsane wrote:
| 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 Blomer, Merchan and Krummel from
| 2004.
| snowwrestler wrote:
| Essentially, a computational time salt.
| sandworm101 wrote:
| 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 wrote:
| 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.).
| sam0x17 wrote:
| 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 wrote:
| >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.
| codeulike wrote:
| 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?
| phamilton wrote:
| 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?
| mastax wrote:
| Your devices probably aren't responding to unsolicited network
| requests from the internet.
| phamilton wrote:
| But they do run arbitrary javascript code in my browser.
| rocqua wrote:
| 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.
| Starlevel001 wrote:
| 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.
| pyrolistical wrote:
| 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?
| adrian_b wrote:
| The attackers do not read the CPU frequency, they estimate it
| based on the latency of the replies to their queries.
|
| The attack works only for certain combinations of CPUs and
| cryptographic algorithms that contain a mixture of instructions
| that cause a CPU to lower its clock frequency, with
| instructions that allow the CPU to raise its clock frequency.
|
| For such combinations, algorithms that are supposed to be
| executed in constant time are actually executed in a variable
| time, creating a side-channel.
|
| As a response to Hertzbleed, Intel has published a guide for
| those who write cryptographic libraries, about how to mitigate
| this vulnerability:
|
| https://www.intel.com/content/www/us/en/developer/articles/t...
|
| The main problem that creates this vulnerabilty is that the CPU
| vendors publish very little information about their turbo
| algorithms, so, unless you make your own measurements, it is
| very difficult for a software writer to predict at which clock
| frequency will be executed a certain segment of a program, and
| what should be done to avoid changes in the clock frequency.
| advisedwang wrote:
| > 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| Haha so constant time algorithm isn't constant time
| jackcook wrote:
| You can pull off attacks like this from JavaScript by
| repeatedly recording the time and training a machine learning
| model on traces of instruction throughput over time, which my
| group did in a recent paper: https://jackcook.github.io/bigger-
| fish/
| yunohn wrote:
| Could you elaborate on this attack? It's an interesting read,
| but I'm curious about practicality.
|
| How would you ensure that the user loads your malicious
| script, and has a running web worker for it?
|
| I see that you trained it on 100 websites. Would you need to
| retrain for every new version deployed or different paths
| with varying content?
|
| If your intention is to detect sensitive website accesses,
| wouldn't you need those websites to be public to train the
| model first? I'm not convinced that detecting porn access is
| particularly malicious, but I acknowledge that it is illegal
| in some places.
| jackcook wrote:
| You'd just need to put the script on any webpage the user
| might access and leave open, such as Google, or Facebook,
| or whatever. The attack isn't specific to JavaScript, so
| really you could put this in a desktop app too, think
| Slack, Spotify, etc. Any app or website that you know the
| target user is likely to open. CDNs are also a great
| target.
|
| We evaluated on 100 websites as a proof of concept, but we
| also included experiments in an "open world" setup where
| the classifier has to predict whether the activity is from
| one of 100 sensitive websites, or whether it's none of
| them, and found that it's still very accurate in that more
| realistic setup. You would need to retrain to identify more
| websites outside of your set of 100.
|
| The websites would need to be public, which is basically
| the same limitation as hertzbleed, since they need to know
| what they're looking for in order to identify an activity.
| Some use cases with this limitation aren't too hard to
| imagine: maybe you're in a country that bans access to
| major Western news sites but you're evading censorship with
| a VPN.
| yunohn wrote:
| I'm a little confused about your attack vector - how
| feasible would you reckon it is to place such a malicious
| script on the largest public websites in existence,
| versus just getting the victim to install a Trojan? The
| latter could just literally monitor the user.
|
| I'm not saying your paper is technically wrong, just
| practically infeasible.
|
| Right now, you've chosen very specific websites. Have you
| explored if there is a correlation between specific
| scripts (react, jquery, etc) and whether websites with
| similar setups cannot be differentiated? I was also
| curious about content/non-homepage paths. Your conclusion
| seems to be that interrupts/etc are the primary
| indicators, so I suspect there's a connection.
|
| Edit:
|
| In my experience, large websites and most web apps don't
| use CDNJS/etc, but bundle their code - this would make
| injecting your script much harder without a supply chain
| attack.
|
| On second thought, given CORS I think this attack is
| actually impossible. How would your embedded script
| communicate your findings with your server? You would
| need to control the originating domain itself...
| jackcook wrote:
| I don't think any of these side channels are really easy
| to pull off without the technical capabilities of a
| nation state or something similar. I personally think
| embedding a malicious script in a CDN (e.g.
| https://blog.ryotak.me/post/cdnjs-remote-code-execution-
| en/) that serves a script for a large website, or
| something similar
| (https://blog.igorescobar.com/2016/08/21/ive-the-chance-
| to-tr...), is more realistic than getting the victim to
| install your program -- I would imagine sensitive
| individuals are very concerned about installing arbitrary
| software.
|
| We did get a comment about this in our rebuttal but
| didn't end up including it in our final paper -- we found
| that we distinguished sites with the same frameworks
| (such as react, angular, and jquery) at the same accuracy
| at sites that used different frameworks.
|
| We didn't do much research into content/non-homepage
| paths but it's a good area for future research. I would
| suspect it'll still do pretty well.
|
| And yes, we concluded that the source came from
| interrupts (in Table 3 of our paper you can see we ran an
| experiment with frequency scaling turned off), which does
| make me question the practicality of hertzbleed. I
| wouldn't doubt it can be exploited somehow though.
| Symmetry wrote:
| 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 wrote:
| Isn't it possible to monitor for this type of attack, and then
| apply mitigations?
| kube-system wrote:
| 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.
| nindalf wrote:
| 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.
| Zamicol wrote:
| >All libraries we use are constant time.
|
| Well, except anything Javascript.
|
| "Node.js's crypto libraries do not provide constant-time
| guarantees and, unfortunately, are still at the mercy of the
| JavaScript GC"
|
| https://cseweb.ucsd.edu/~dstefan/pubs/renner:2018:ct-
| wasm.pd...
| arkadiyt wrote:
| 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 wrote:
| If you are not using one it is a very bad sign.
|
| All modern cryptographic libraries use various constant time
| operations.
| zamalek wrote:
| 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 wrote:
| As one example, SSL uses constant-time crypto operations, so
| the answer to this question is an almost universal "yes"
| [deleted]
| tgv wrote:
| 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 wrote:
| 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).
| eixiepia wrote:
| Can this attack be used to extract Widevine decryption key?
| ancientsofmumu wrote:
| 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_p...
| samstave wrote:
| UHM... Am I the only one who feels the influence of
| StuxNet/Duqu on this one?
| omginternets wrote:
| Could you elaborate?
| samstave wrote:
| Yes. Gimme a sec to re-read, then type up.
|
| ---
|
| If you recall, the original method that Stuxnet (stx) and
| Duqu (dq) worked was that they would cause
| oscillations/faulty bursts of (power?) to a centrifuge...
|
| Which would vary over time in order to destabilize the nuke
| centrifuges, resulting in poor outcomes for whatever
| product, higher wear on the components, and ultimately an
| explosion...
|
| But while doing all this nefarious nefariousness - they
| were able to take control of the control-systems telemetry
| objects, with remote, autonomous agents in an off-grid,
| air-gapped facility... and report back to the monitoring
| systems that all was green... (while the wetwork was done
| outside exploding cars of scientists, with "internal
| extremists"
|
| So this attack reminds me of the variable oscillation
| attack against the iran nuke facility, with masking the
| results in thermal/whatever mechanisms... to the point of
| destruction of target...
|
| But what really triggered me to this similarity was the
| comment of another HN user who stated that (in response to
| a "who would care about this attack?" type question), said
| "journalists... and the like" (see wetwork, above)
|
| ---
|
| Welp the only people that cared about stx/dq == nuclear
| scientists...
|
| So, if this attack is real - and can be a real damage
| modifier, then I would expect that all 5Eyes already have
| it available to them.
| vore wrote:
| This is about measuring CPU frequency, where doing so
| definitely does not cause your computer to explode.
| samstave wrote:
| I am aware of what it states... I am not talking about
| the actual mechanism, I am talking about the methodology
| and modality....
|
| " _Cause some crazy busllshit at a very small level,
| targetting specific people, such that I get the outcome I
| want!_ "
|
| Clearly you have not spent the hours listening to all the
| experts on how stx/dq did exactly this.
|
| Let me prove it to you.
|
| I am going to state one thing, but I am going to mean
| something completely else:
|
| " _I love you_ "
| saagarjha wrote:
| Being unnecessarily cryptic and sounding like a crackpot
| while calling everyone else out for being uninformed is
| generally unlikely to get you support on Hacker News.
| dan000892 wrote:
| OR DOES IT???
|
| Oh, it doesn't? Carry on.
|
| I'm quite fatigued by the recent (?) increase in
| comparisons of current vulnerabilities, attacks, and
| adversarial capabilities to Stuxnet and can't help but
| tune out when it's invoked. Yes, the '96 Bulls were the
| best team of all time. That has no bearing on how good
| the Bulls are now and sure as hell shouldn't blind you to
| how good other teams have gotten since...
| fpoling wrote:
| 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 wrote:
| 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
| fpoling wrote:
| It is Gnome Power setting dialog changes the governor. The
| above command just disables Turbo boost while allowing CPU
| to spend 100% of its time at the base frequency.
| forrestthewoods wrote:
| 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?
| 1MachineElf wrote:
| 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 wrote:
| 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 wrote:
| 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.
| xiphias2 wrote:
| Is the libsecp256k1 library affected? How hard is to fix it?
| hinkley wrote:
| 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.
| culpable_pickle wrote:
| Wouldn't the TPM fit those requirements, presuming it could be
| sped up enough for the required workload
| ChrisLomont wrote:
| 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 wrote:
| Presumably you can schedule only on non-information-leaking-
| boundaries with very high level APIs?
| ChrisLomont wrote:
| >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.
| tux3 wrote:
| 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 wrote:
| >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 wrote:
| What can an attacker do by knowing how many much queued
| crypto work there is?
| ChrisLomont wrote:
| 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.
| abiro wrote:
| Which ARM processors could be affected? Can't find an overview of
| ARM processors that implement frequency scaling.
| drvdevd wrote:
| 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?
| bobbylarrybobby wrote:
| Interesting, and seems like a natural followup to this side
| channel:
| 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 wrote:
| 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 wrote:
| This is mostly a concern in airports, internet cafes and other
| places where attackers have easy access. Less so a data center.
| hindsightbias wrote:
| Surprising it took that long to look at sound when exploits on
| hw LEDs was a thing decades back.
| bob1029 wrote:
| 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.
| UniverseHacker wrote:
| > predict the presence, make, model & operational schedule of
| someone's washing machine just by observing how fast their
| power meter spins over time
|
| I think this is a really excellent analogy that explains the
| situation well. However, I think doing exactly that would be
| really straightforward, and your analogy explains why. Imagine
| an ML model constantly adjusting the probabilities for the set
| of possible washing machines... after a large number of washing
| machine runs, it will be narrowed down to a really small subset
| of the possibilities. Given that this is a cryptographic key,
| they can then trivially brute force the remaining
| possibilities.
| kzrdude wrote:
| 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.
| velcrovan wrote:
| This is the kind of exploit that might legitimately warrant
| the character-by-character "password slot machine" animation
| from movies like "War Games" (https://tvtropes.org/pmwiki/pmw
| iki.php/Main/PasswordSlotMach...)
| coredog64 wrote:
| If a string match isn't done in constant time you could
| theoretically get your results character by character.
|
| (Top of mind because I just had to handle that case in a GH
| webhook)
| samus wrote:
| It's more like being able to tell what else is in the washing
| machine after I hand you some pants to wash for me.
| JulianWasTaken wrote:
| 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 wrote:
| 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.
| R0b0t1 wrote:
| It's more like discerning the washing machine based on the
| power meter, but you know exactly when and how many washing
| machines turn various bits on and off.
|
| Could be doable, with some expensive equipment.
|
| For the ghost side channel attacks we did see in situ proofs of
| concept. It's an open question how many people have the skill
| to do either those side channel exploits or the power meter
| washing machine guess above and are also engaged in crime.
| mike_hock wrote:
| > 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.
|
| That sounds almost trivially easy provided you can afford to
| buy each and every washing machine on the market so you can
| measure its power consumption profile for each of its programs.
| laurent123456 wrote:
| 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.
| orblivion wrote:
| 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 wrote:
| I got the same feeling, how does this apply to me?
| samus wrote:
| 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.
| stingraycharles wrote:
| 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 wrote:
| 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.
| Sephr wrote:
| 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 wrote:
| 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 wrote:
| > 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.
| MrWiffles wrote:
| 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.
| yunohn wrote:
| > > Why did Intel ask for a long embargo, considering they are
| not deploying patches?
|
| > > Ask Intel.
|
| Indeed, I really found this unnecessarily snarky on their part.
| I don't think Intel was acting in bad faith.
|
| In my experience, security researchers are very /particular/.
| They like telling everyone that no matter what you do, you are
| vulnerable for umpteen reasons, whether practical or not.
| AlexCoventry wrote:
| If they didn't tell you about the risks and you got hacked,
| you'd also be asking why.
| bayindirh wrote:
| > What can you do about it? Nerf your CPU performance by
| disabling "turbo boost" or equivalent.
|
| A server running a multithreaded load is probably disabling
| turbo boost anyway because of the thermal load on the package
| already. Instead, you should disable speedstep and set your
| systems to maximum performance. However, this will increase the
| heat and your power bill considerably.
| mcronce wrote:
| I was thinking about busy servers running mixed workloads. I
| would think that, with the CPU running a bunch of workloads
| on different cores, context switching, etc, it wouldn't be a
| practical attack. Maybe that's incorrect.
|
| Mostly idle servers are a different story, obviously.
| bayindirh wrote:
| Sometimes response critical VMs are pinned to the cores at
| the hypervisor level, and intel's chips support independent
| (frequency) scaling of CPU cores for some time.
|
| In that scenario, mixed loads won't help. You'll have at
| least one pinned core, and it can scale relative to the VMs
| load (considering you also pin hypervisor cores, etc). So,
| it's possible to hit that pinned core and execute the same
| timing attack.
|
| I know it's a niche scenario, but it's not an impossible or
| implausible one. Another possibility is the servers which
| fill critical roles, but they're idle or in a constant low-
| load state to have headspace for high loads. Again,
| attacking these servers are plausible. Considering these
| servers are not open to internet most of the time, we're
| bordering on corporate espionage, but it's not the subject
| here.
| mjevans wrote:
| A spike performance up, random delay in down might be
| sufficient mitigation on a multi-tenant platform.
| bayindirh wrote:
| You can tune the normal on demand governor with a high
| hysteresis to keep the frequency up for a long time. On
| demand governor is already trigger happy enough to jump to
| maximum frequency with a slight increase in load, so one
| needs to add more delay in calming down step.
|
| A random hysteresis is bad from a system responsiveness
| aspect, because frequency scaling is not free (in terms of
| time) when observed from the CPU perspective.
| mackmgg wrote:
| I've always turned off Turbo Boost on my Intel laptops anyway,
| because of the heat/battery hit. If I was doing something that
| I really wanted the extra speed and I was plugged in, I would
| turn it back on for that task, but I never really felt I was
| missing anything by having it off.
|
| Considering how easy it is to turn on/off (on macOS at least I
| used Turbo Boost Switcher which added a button in the menu bar
| to toggle it) I don't think you would have a noticeable
| performance hit by keeping it off except when you need it.
| bayindirh wrote:
| Turbo Boost is not something you can reliably kick in any
| load spike due to its operation being constrained by the
| thread and thermal load of the CPU. Also, it's affected by
| the CPU instructions you're already running. AVX family is
| esp. power-heavy and thermal-heavy.
| xoa wrote:
| > _What can you do about it? Nerf your CPU performance by
| disabling "turbo boost" or equivalent._
|
| Eh? Doesn't this require an attacker to actually be able to
| talk to the targeted system? You mention classes of actor
| ("journalist, human rights activist, etc") that aren't online
| public service providers or at least perhaps shouldn't be.
| Private devices connecting out to the greater net are
| effectively universally behind firewalls and often (CG)NAT as
| well and not unilaterally addressable the other direction. For
| private services, access should be exclusively via VPN (direct
| WG or mesh like nebula or something) with PSK alongside public
| keys and perhaps something like port knocking in front as well.
|
| Same as with other hot class side channel attacks, the attacker
| does in fact need to be able to get the targeted system to run
| something somehow. So the most basic thing to do about it is
| simply not allow attackers to do that. The players for whom
| this is fundamentally impossible are general public online
| service providers, but that isn't the class most people or
| businesses fall into. If attackers are getting sensitive
| servers to respond to arbitrary code then they have already
| gotten access credentials of some kind.
| BoppreH wrote:
| > the attacker does in fact need to be able to get the
| targeted system to run something somehow
|
| Unfortunately that includes Javascript, and now that affects
| virtually everybody. Speculation: if you can find a
| Javascript call that uses protected keys, you might be able
| to extract secrets from that route.
| bobkazamakis wrote:
| > the attacker does in fact need to be able to get the
| targeted system to run something somehow
|
| >Unfortunately that includes Javascript, and now that
| affects virtually everybody.
|
| Debatable -- not because of the goofballs who insist on
| never running javascript, but because it doesn't have the
| necessary clock precision available.
| fpoling wrote:
| When Spectre came it turned out that it was very
| straightforward to implement the relevant attacks in JS.
| A script can use workers with shared memory access to
| monitor execution and get a timer with less than 100ns
| resolution. As the result the shared memory were
| disabled. Later under the presumption that relevant
| issues were mitigated, the shared memory was re-enabled
| again.
|
| So I wonder if the shared memory will be disabled again
| as it may allow to monitor frequency changes.
| jabart wrote:
| My understanding was that the timer precision was limited
| and that was never re-enabled.
|
| From MDN.
|
| "It's important to keep in mind that to mitigate
| potential security threats such as Spectre, browsers
| typically round the returned value by some amount in
| order to be less predictable. This inherently introduces
| a degree of inaccuracy by limiting the resolution or
| precision of the timer. For example, Firefox rounds the
| returned time to 1 millisecond increments."
| xoa wrote:
| OK, but can you walk me through the threat model here? This
| isn't a rhetorical question, it's easy to see how servers
| in general and shared hosting, colocated VMs etc in
| particularly might theoretically face a threat here, I'm
| just trying to get a better understanding of how GP would
| be correct for end user devices. The individual in question
| on the smartphone or computer specifically chooses to
| initiate a connection to a desired web server, and you're
| imagining said server was hacked or otherwise
| compromised/untrustworthy and begins running Hertzbleed via
| JS, and that JS has the precision in practice for it to
| work. So vs other RCEs and such what is the path here? What
| short secrets (AFAICT these attacks aren't about pulling
| gigabytes of RAM but a few bits of key stuff) is it going
| after that, after having obtained them, represent a serious
| compromise by themselves or allow further escalation?
| Nothing done on the user device is going to affect the
| network hardware they're going through, and this attack is
| about reading not writing, so what is the attacker getting
| that will then let them break out of the web broswer/OS
| sandboxes and start pulling more the other direction?
|
| I can see that if other persistent access credentials were
| sitting unencrypted in memory that could be an issue if the
| attacker can use those to hop into other services the user
| has access to, but that's manageable via care with device
| usage, proper MFA etc right? Or I can see how true external
| IP address might be a dangerous short secret for someone
| trying to hide (vs merely secure) via VPN. But I think in
| those cases externalizing the VPN to the network level is a
| good idea anyway since being 100% sure of zero leaks in a
| modern OS/application stack is challenging, and then the
| user device doesn't have to know anything about the real IP
| at all. JS also already allows a huge amount of
| fingerprinting, so if someone is allowing JS to run and is
| deadly worried about privacy they must be thinking about
| mitigations there already.
|
| Again, not at all denying that incredibly tricky stuff can
| be done using little leaks like this to escalate in
| surprising ways. But for a dedicated web browsing device
| with only outgoing and session access to WAN, likely though
| a VPN but not necessarily on-device, what new threat
| scenario is this such that completely disabling dynamic
| frequency is the only response? Although I suppose for a
| dedicated web browsing device using tor browser or the like
| disabling that might not actually be a big deal anyway.
| mgiampapa wrote:
| On most shared infrastructure would be even harder to
| exploit. In an ideal world you are sharing the
| infrastructure to maximize CPU and other resource
| utilization. When running workloads on VMWare for
| example, the best practice is to disable deep C states
| and not allow the CPU to dynamically scale down. This
| prevents all kinds of clock drift issues in guest VMs
| that expect a CPU cycle to be relatively constant.
| neurostimulant wrote:
| Many password managers are using end-to-end encryption
| and have browser extensions written in js. It would be
| bad if hertzbleed can be used to extract keys used by
| those password manager extensions.
| BoppreH wrote:
| The exploit comes from a hacked server, a bad ad, social
| engineering, etc.
|
| As for the attack, imagine a browser that encrypts local
| storage with a system key. If I understand correctly, by
| storing different patterns of bits, Hertzbleed might be
| able to extract the system key from the timings to save
| data.
|
| This might sound very theoretical, but modern OS'es (and
| password managers) have lots of keys like that. There's a
| good chance one or more of them are reachable from
| Javascript. And that's just what popped in my mind in two
| minutes, I'm sure red teams will have better ideas.
|
| The scary part is that this is another attack in the same
| ugly class as Meltdown and Spectre, where the antidote is
| nearly as damaging as the poison.
| lossolo wrote:
| > imagine a browser that encrypts local storage with a
| system key. If I understand correctly, by storing
| different patterns of bits, Hertzbleed might be able to
| extract the system key from the timings to save data.
|
| Don't you need precise clocks for this in JS? The ones
| that were disabled in browsers after Meltdown/Spectre.
| api wrote:
| > 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.
| jessermeyer wrote:
| There's so much variation (read, noise) intrinsic to response
| times for network requests to be satisfied on most cloud
| hosts anyway that I'm very skeptical about any practical
| attacks being made in the short term.
| FabHK wrote:
| > Hertzbleed is a real, and practical, threat to the
| security of cryptographic software. 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".
| jessermeyer wrote:
| Please. If you actually read the paper you'll come to
| learn that "practical" here means "we've conclusively
| shown under strict laboratory conditions that this
| works".
| wmf wrote:
| For one request, yes. For statistical analysis of many
| requests, no. People keep extracting secrets from very
| noisy and weak signals.
| mike_hearn wrote:
| In lab conditions, yes. In this case:
|
| _" Our attack is practical; an unoptimized version
| recovers the full key from a CIRCL server in 36 hours and
| from a PQCrypto-SIDH server in 89 hours ... The target
| server and the attacker are both connected to the same
| network, and we measure an average round-trip time of 688
| us between the two machines."_
|
| Note that:
|
| * The server in this case does absolutely nothing except
| use the cryptographic library. Would it work on a real
| server that actually does something useful with the
| requests? We don't know, the paper doesn't try that.
|
| * We aren't told if it works if other people are using
| the server simultaneously.
|
| * They show the attack against obscure post-quantum
| algorithms nobody actually uses (as far as I know). Why
| not RSA or ECDSA or something more standard? Presumably
| they don't have a technique that works on those, as
| otherwise it'd have been a big upgrade to their paper.
|
| * What about if you aren't running your attack physically
| right next to your target? Is <1msec of latency what
| people think of when they hear "remote attack"?
|
| I'm not hugely surprised Intel has limited themselves to
| issuing guidance. This paper continues a trend that's
| emerged since the first Meltdown/Spectre breaks in 2018
| in which attacks become ever more convoluted, theoretical
| and unlikely to work outside of a lab yet they're all
| presented as equally important by the academics who
| develop them. I used to follow this area of research
| quite closely but eventually got sick of it. Way too many
| papers had some bizarre caveat buried deep in the paper,
| e.g. eventually I noticed that a lot of attacks on Intel
| SGX that claimed to leak cryptographic keys turned out to
| be using an extremely specific version of GnuTLS. I got
| curious why that might be and discovered that it was
| absolutely ancient, dating from _many_ years before the
| papers were written. They were using it because that
| version had no hardening against side channel attacks of
| any kind whatsoever. Was that a realistic assumption to
| make for these attack papers? Probably not, but to notice
| this sort of trick you had to read well beyond the
| headlines.
|
| I also remember some years ago, Google researchers got
| worried people weren't taking Spectre seriously enough,
| so they released a demo that claimed it would show a
| Spectre attack in action inside the browser. I was keen
| to see this because so many posited attacks seemed to
| rely on extremely specific situatons that didn't seem
| particularly plausible in the real world. I visited it in
| Chrome on macOS, i.e. one of the most predictable
| hardware and software environments the developers could
| have, and it didn't work. Checked reddit, it was filling
| up with people saying it didn't work for them either.
|
| In the ~5 years since these attacks came out and started
| being patched in software and hardware, have there been
| any real world attackers found using them? Maybe but I
| don't remember hearing about any. State sponsored
| attackers seem to be sticking with more conventional
| techniques, which probably says a lot.
| jessermeyer wrote:
| This is not inconsistent with what I said.
| thfuran wrote:
| Isn't it? It probably wouldn't require any novel
| statistical techniques.
| jessermeyer wrote:
| Novel statistical techniques is a different concern to
| practical attacks. (And I appreciate the relativity in
| what is meant by 'practical' -- nation state resources
| are in a distinct category of capability)
|
| But I would like to see some statistical expectations on
| 'how long you'd have to wait on an average open network
| for each key bit to reach 95% confidence'.
| gpm wrote:
| > since those tend to run at a sustained max anyway
|
| Really? I've never been on the cloud-provider side of cloud
| computing, but every application I've developed that ran on
| the cloud was rarely if ever running at a sustained maximum
| of the resources allocated to it. We always wanted a buffer
| to be able to absorb load spikes and users performing
| unusually expensive actions.
| staindk wrote:
| I think this means you were paying for the over-
| provisioning i.e. paying for a full CPU or baremetal
| server?
|
| "The Cloud" is all about vCPU - "2 vCPUs" feels somewhat
| standard for a base-tier VPS... and 2 vCPUs means "2
| virtual CPUs" or rather "roughly equivalent to 2 CPU cores"
| I think. I understand that jargon to mean they are always
| cramming 11 x 2vCPU clients onto 20 physical cores.
| sofixa wrote:
| Depends on the cloud - OVH and Digital Ocean yes, but AWS
| give you whole uncontested cores ( bar the t* instance
| line, but that's it's whole thing).
| phamilton wrote:
| Nah, vCPU is generally just hyperthreading. See
| https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/cpu-
| opti...
|
| So you get 2 vCPUs per core.
| staindk wrote:
| Thanks for the link, that's great to know about AWS.
|
| I don't think all other VPS providers are that good about
| things - googling around for some other definitions of
| vCPU (in VPS context) I see a lot of examples of 16
| thread server CPUs handling "128 vCPUs".
| ceeplusplus wrote:
| No, 2 vCPUs is 2 logical threads, which is equivalent to
| a single physical core on x86. So yeah, they are cramming
| 11 x 2 vCPUs onto 20 physical cores. In fact, it's more
| like 20 x 2 vCPUs.
| sofixa wrote:
| Depends on your workload, spot batch jobs would run at
| sustained maximum.
| gpm wrote:
| Absolutely, my observation is in a way that "most
| workloads don't seem (to me) to be like that".
|
| The number of servers serving interactive queries
| (frontends, rest api servers, databases, etc) seems (to
| me) to greatly outnumber the number of batch jobs, and
| I've always seen those intentionally "over" provisioning
| CPU because otherwise you get latency issues if load
| increases at all.
|
| I don't actually know that cloud providers don't either
| have some clever way around this (e.g. spending spare CPU
| cycles on some other form of work), or that it isn't the
| typical usage pattern, but I strongly suspect it.
| rhn_mk1 wrote:
| That only means you were making space for others to phase
| in and use the remaining resources that you spared. You're
| not the one deciding which process sits on which resource,
| after all.
|
| The only reason why resources might be left unused are
| usage spikes that all customers share.
| bombcar wrote:
| Dynamic scaling involves bringing the CPU frequency down
| but not off - you can get almost as much power savings for
| _some loads_ by using the old HLT instruction, so your CPU
| /core is either at full speed or basically off.
| depereo wrote:
| I am on the cloud provider side; we would sometimes limit
| the upper and lower range of frequency but completely
| disabling scaling would be very unusual.
| href wrote:
| Same. Our compute hosts are generally not using 100% of
| their cores at all time.
|
| There's computes that are not full, computes that run
| rather diverse tenants, and even the fully utilized
| computes responsible for CPU optimized VMs have enough
| variance in their workload for frequency scaling to
| occur.
| 2OEH8eoCRo0 wrote:
| 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.
| willcipriano wrote:
| > 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.
| -\\_(tsu)_/-
| syrrim wrote:
| 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 wrote:
| 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
| dkbrk wrote:
| 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.
| SilverBirch wrote:
| 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.
| phendrenad2 wrote:
| 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.
| 2OEH8eoCRo0 wrote:
| `cpupower frequency-set --governor performance`
| FartyMcFarter wrote:
| > 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
| simias wrote:
| 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.
| jl6 wrote:
| 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?
| RcouF1uZ4gsC wrote:
| Pick at most 2:
|
| Sharing of computing resources
|
| Performance
|
| Security
| Phlarp wrote:
| 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 wrote:
| 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]
| iueotnmunto wrote:
| An awesome attack vector and kudos to the authors. I do wish it
| had never been discovered for environmental reasons though :(
| nequo wrote:
| Naive question:
|
| Would another possible defense be for the kernel to introduce a
| small random delay in the task scheduler?
| rocqua wrote:
| 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 wrote:
| > 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 wrote:
| 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 wrote:
| 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.
| eternityforest wrote:
| I suppose future systems will just run crypto operations at a
| fixed speed, and turn dynamic stuff back on when they're done?
| night-rider wrote:
| 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 wrote:
| 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 wrote:
| 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?
| rocqua wrote:
| 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.
| tails4e wrote:
| 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 wrote:
| 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.
| candiddevmike wrote:
| And yet folks will keep using cloud services and multi tenant
| offerings until we have regulations forbidding multi tenant
| computing for sensitive data.
| jfk13 wrote:
| How many people can reliably identify "sensitive data", do you
| think?
| goodpoint wrote:
| Enough to collect and handle such data in the first place.
|
| Or do you handle data without knowing what it is?
| jfk13 wrote:
| I suspect ideas of what is "sensitive" vary greatly. Whose
| definition counts?
| Strilanc wrote:
| 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.
| Rafuino wrote:
| Why did they wait 2 extra quarters to tell AMD about this?
| jagger27 wrote:
| 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.
| shahar2k wrote:
| would quantizing the boost to a few specific levels or even
| randomizing the levels mitigate something like this?
| leephillips wrote:
| My first highly amateur idea was to modify the frequency scaling
| algorithm with some randomness. How stupid is my idea?
| [deleted]
| bragr wrote:
| I guess it depends on how much randomness you need to
| effectively mask the signal.
| cylon13 wrote:
| 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 wrote:
| Except that the processor can be doing other work during
| artificially induced noise delays, something not possible
| with delays introduced by lower mean frequency.
| teraflop wrote:
| 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.)
| alanh wrote:
| 100% correct
| matthewdgreen wrote:
| This is not entirely true. Or rather: it is true when the
| countermeasure is to add random _delays_ to pad out overall
| timing, since one can simply collect more samples to obtain
| an average. And that may be what the OP is suggesting: just
| scale the frequency to random levels that are not quite the
| pre-programmed ones, which is very similar to adding random
| delays. (In practice this might actually work well enough to
| defeat delicate attacks.) However what I hoped the OP was
| suggesting is to add random instructions as a way to prevent
| the processor from switching power modes: sort of like
| tapping your phone screen occasionally to keep it from
| dimming.
|
| There are also other (unrelated) techniques that use
| randomness to eliminate side channels. One of the most basic
| anti-timing-attack countermeasures is to use RSA blinding in
| which a base C is first randomized by computing C^r mod N
| before that (random) result is combined with the secret key.
| The randomness can then be removed from the final result.
| This defeats attacks that depend on choosing or knowing the
| value C.
| abiro wrote:
| How about making operations constant time in application
| code by picking an upper bound which is acceptable for the
| application, but that is certainly longer than the actual
| CPU computation and then waiting until the upper bound to
| return the result?
|
| Eg. my app is performing digital signatures and I'm sure
| that they take <1ms CPU time, but performing digital
| signatures in 10ms is acceptable for my application, so
| when I perform a signature I measure the CPU time elapsed,
| say 0.5ms and then wait for 9.5ms.
| kelseyfrog wrote:
| Does that necessarily mean that all is lost? It sounds
| possible to arbitrarily extend the time necessary. Don't we
| already do this when we choose encryption keys with lengths
| that take an arbitrary amount of time to crack by brute
| force?
| minedwiz wrote:
| Oh man the overclocking community would just _love_ it if Intel
| messed with the power scaling architecture </s>
| tester756 wrote:
| How about returning the same frequency to OS every and change
| it every 10sec?
|
| 2.9 2.9 2.9 2.9 2.9 2.9 2.9 2.9 2.9 2.9 2.9 2.9 2.9 2.9 2.9 2.9
| 3.2 3.2 3.2 3.2 3.2 3.2 3.2 3.2 2.8 2.8 2.8 2.8 2.8 2.8 2.8 2.8
| 2.8
|
| totally fake value
| Phlarp wrote:
| The attack isn't nicely asking the computer "hey how fast are
| you running right now?" and then deriving the private key
| from that data. If that was the case the fix would be as
| simple as you laid out here.
|
| This attack works by measuring the absolute (wall) time that
| elapses during many crypto operations and deriving the speed
| / private keys based on statistical methods applied to that
| timing data.
|
| Side-channel attacks are by definition, attacks against
| unintentional information leakage by a machine. The laws of
| thermodynamics virtually ensure that side channel attacks
| will be a persistent issue as long as computers are made of
| matter and consume electricity, multi-tenant computing
| exacerbates the issue.
| tester756 wrote:
| thank you
| nickskull wrote:
| Would this apply to M1 Macs as well?
| blueflow wrote:
| Website, Brand, everything, nice!
|
| But, if they had a merchandise shop they would look more
| professional.
| bombcar wrote:
| The Intel-requested delay would have let them cross-brand with
| a famous bankrupt car rental company!
| [deleted]
| etaioinshrdlu wrote:
| Does this mean that an evil process may gain information about a
| foreign process by measuring its own execution speed variations?
| jackcook wrote:
| We did exactly this in a recent paper we're presenting at ISCA
| next week (see https://jackcook.github.io/bigger-fish/) -- it's
| very possible for an attacker to do this. However, we didn't
| find that the signal the attacker found was due to frequency
| variations (and we did run an experiment to test this), but
| rather due to system interrupts.
| Phlarp wrote:
| 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 wrote:
| 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 wrote:
| >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 wrote:
| 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.)
| hinkley wrote:
| The 'S' in 'RSA' is Adi Shamir, who has spent a lot of his
| career analyzing side-channel attacks. It is especially a
| problem with special-purpose cryptographic hardware because it
| tends to be within a small multiple of 'just enough' hardware
| to do the task. It's a lot easier to spot a 2% increase in
| processing time (or for that matter, current draw) when the
| hardware only runs one task, and the task is dominated by CPU
| time rather than other factors.
|
| But analysis tools only get better over time, so the scenarios
| where they are useful multiply.
| mochomocha wrote:
| 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 :)
___________________________________________________________________
(page generated 2022-06-14 23:00 UTC)