21–30 of 56 posts
Silly question based on my layman's understanding of the attack: Can you impede the extraction process simply by having your phone/tablet/laptop generate interference while the decryption process is happening? For instance, if your laptop is simultaneously playing music through its speakers, would the analysis still let them definitively pick out the signing key?
Earlier quoted context omitted.
Upvoted, you're totally correct. Each of these attacks is providing support to DJB's focus on constant time implementations of everything.
Does constant time mean constant power usage and constant EM emission? It seems like those would be separate problems.
There are a number of works that perform 'differential power analysis' (DPA) attacks on mobile devices that target symmetric crypto. These are generally both constant time and constant execution path. In this instance, attackers can attack the data dependancy in the EM emanations.
Simple example! a program that XORs two registers:
r1 = r1 XOR r2
If r2 has all the bits set to 1, then this will completely invert the contents of r1. This in turn consumes more energy (and hence emit more EM) in comparison to if r2 was all 0's. Hope that clarifies.
Earlier quoted context omitted.
Does constant time mean constant power usage and constant EM emission? It seems like those would be separate problems.
They are highly correlated. The best way to achieve constant time is making your code paths data independent, that is, it always execute the same instructions, whatever the data. This code will also use constant power and have constant EM emission. (Except for low level optimizations in hardware, that may break any of those characteristics.)
Silly question based on my layman's understanding of the attack: Can you impede the extraction process simply by having your phone/tablet/laptop generate interference while the decryption process is happening? For instance, if your laptop is simultaneously playing music through its speakers, would the analysis still let them definitively pick out the signing key?
But I wonder if there are feasible, modern attacks against software using symmetric encryption. For example products offering full disk encryption, or encrypted volumes. Or are the operations in symmetric ciphers so 'constant' as not to reveal anything about the master key?
This is a really impressive piece of work. Unfortunately, the authors completely ignore Curve25519[0], which was designed by DJB (and implemented as NaCl[1]), with the goal to reduce side-channel vulnerabilities. From a random Curve25519 presentation [2]: - No data-dependent branches. - No data-dependent indexing. I really wonder how much can be extracted from a NaCl implementation under the same conditions. [0] http…
Please elaborate the downvotes. While not actually testing Curve25519 is perfectly valid for the authors, comepletly ignoring its existence is a bit far-fetched, as it is clearly in scope. To quote the first sentence of the paper: "We show that elliptic-curve cryptography implementations on mobile devices are vulnerable to electromagnetic and power side-channel attacks." At least they should have said "some implement…
I don't know that it's typical for research like this to comprehensively evaluate targets that aren't relevant to the research. Regardless, here we have an attack on the ECDSA k-nonce. People who use Curve25519 don't even use ECDSA; they use Ed25519's deterministic Schnorr-style signatures. It's not even the same signature construction.
So what you're asking of the authors seems a bit like the authors of the DROWN paper explaining that their RSA padding oracle attack doesn't work if you instead use DH key agreement.
I always see these non-intrusive side channels being applied to asymmetric cryptography. From using a microphone to listen in on GPG RSA private keys, to now the difference between point adding and point doubling in ECDSA. But I wonder if there are feasible, modern attacks against software using symmetric encryption. For example products offering full disk encryption, or encrypted volumes. Or are the operations in sy…
Side-Channel attacks are nasty. Wonder why the FBI wasn't able to use this to hack the San Bernardino iPhone 5C, the NSA must be aware of this? From the article In the sequel, unless stated otherwise, the experiments were performed on Apple iPhone 3GS which exhibited a particularly clear signal. Hope Apple fixes this in future models, even when opened.
Earlier quoted context omitted.
San Bernardino 5C could be cracked in two days using a NAND flash write blocker. You only need to program an FPGA to buffer writes to NAND chips in RAM instead of passing them through and to allow the reads, then you just try N PIN codes and reboot while resetting the blocker state cache. N is 4 if they haven't tried any PINs and 1 if there are delays after each because they've tried a couple PINs already. Phone boot…
Do you have a good citation for that or is it just a personal theory?
This is a really impressive piece of work. Unfortunately, the authors completely ignore Curve25519[0], which was designed by DJB (and implemented as NaCl[1]), with the goal to reduce side-channel vulnerabilities. From a random Curve25519 presentation [2]: - No data-dependent branches. - No data-dependent indexing. I really wonder how much can be extracted from a NaCl implementation under the same conditions. [0] http…
These are implementation properties not properties of the curve. 25519 is a fine set of parameters but it always disappoints me to see this conflation.
The implementations being attacked here were grotesquely sidechannel vulnerable. There are grotesquely sidechannel vulnerable ed25519 implementations (esp. parties that have been bitten by the 'tutorial to ecc' bug and implemented it themselves; or are otherwise reusing the verification multi-exp for signing)... and there are implementation of other things which are not vulnerable.