Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

ECDSA Key Extraction from Mobile Devices via Nonintrusive Physical Side Channels

eprint.iacr.org

Post reply on HN
Print view View original

11–20 of 56 posts

Re: ECDSA Key Extraction from Mobile Devices via Nonintrusive Physical Side Channels

#11

Post by ge0rg »

ge0rg wrote: post #8

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 implementations" or "widely-used implementations".

Re: ECDSA Key Extraction from Mobile Devices via Nonintrusive Physical Side Channels

#12

Post by cjbprime »

ge0rg wrote: post #11
ge0rg wrote: post #8

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…

Upvoted, you're totally correct. Each of these attacks is providing support to DJB's focus on constant time implementations of everything.

Re: ECDSA Key Extraction from Mobile Devices via Nonintrusive Physical Side Channels

#13

Post by powerbutton65 »

ge0rg wrote: post #11
ge0rg wrote: post #8

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…

The paper serves to demonstrate that electromagnetic side-channel attacks on mobile devices (even almighty Apple stuff) are feasible. ECDSA is just an example they chose. Also, Curve25519 is only side-channel resistant to timing side-channels, this does NOT protect it in any way against the EM side-channels exploited in this paper. You can't expect the authors to go over every possible curve out there.

Re: ECDSA Key Extraction from Mobile Devices via Nonintrusive Physical Side Channels

#14

Post by 13of40 »

05 wrote: post #9
smartbit wrote: post #4

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.

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?

Re: ECDSA Key Extraction from Mobile Devices via Nonintrusive Physical Side Channels

#15

Post by ge0rg »

powerbutton65 wrote: post #13
ge0rg wrote: post #11

Earlier quoted context omitted.

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…

The paper serves to demonstrate that electromagnetic side-channel attacks on mobile devices (even almighty Apple stuff) are feasible. ECDSA is just an example they chose. Also, Curve25519 is only side-channel resistant to timing side-channels, this does NOT protect it in any way against the EM side-channels exploited in this paper. You can't expect the authors to go over every possible curve out there.

I was not questioning the impact of their demonstration, which is really impressive. However, being responsible academics, they should have done their related work research. And when doing related work research on side-channel attacks against elliptic curves, it is hardly possible to miss Curve25519 and the fact that it was designed with side-channel attacks in mind. The authors at least reference earlier work by DJB on attacking AES.

Also, Curve25519 is only side-channel resistant to timing side-channels, this does NOT protect it in any way against the EM side-channels exploited in this paper.

This only reinforces the point that performing an EM side-channel attack on Curve25519/NaCl/Sodium would have been a good contribution to the state of the art, with mentioning Curve25519 in the "Future work" section a viable second.

Re: ECDSA Key Extraction from Mobile Devices via Nonintrusive Physical Side Channels

#16

Post by mikeash »

cjbprime wrote: post #12
ge0rg wrote: post #11

Earlier quoted context omitted.

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…

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.

Re: ECDSA Key Extraction from Mobile Devices via Nonintrusive Physical Side Channels

#17

Post by AdmiralAsshat »

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?

Re: ECDSA Key Extraction from Mobile Devices via Nonintrusive Physical Side Channels

#18

Post by powerbutton65 »

gdgtfiend wrote: post #7

This paper seems to focus on old Apple hardware (the newest I can find is the iPhone 5s). I wonder what the results would be on Apple's newest hardware (6 and above).

The Apple hardware perspective is mostly just a gimmick. The side-channel leaks are a direct result of the ARM IP core (also not Apple proprietary). This is arguably old news, people have been attacking ARM based mobile devices for years now.

It would be far more interesting to see if they could attack the Apple crypto hardware accelerators which AFAIK are hardened against these types of attack (as is the Apple CommonCrypto framework as of IOS 9). Apple seems to have ramped up their side-channel game in recent years.

Re: ECDSA Key Extraction from Mobile Devices via Nonintrusive Physical Side Channels

#19

Post by mikeash »

13of40 wrote: post #14
05 wrote: post #9

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?

Apple used to have a bug where they'd report PIN failure before writing that failure to nonvolatile storage. Somebody took advantage of this by building a box that cut power before the write could be performed, allowing a brute force attack:

https://www.intego.com/mac-security-blog/iphone-pin-pass-cod...

The proposal here is similar, just using a different technique to prevent the write.

There isn't any nonvolatile storage besides the flash memory, so if you can reset that then the software has no way of knowing what happened before.

Re: ECDSA Key Extraction from Mobile Devices via Nonintrusive Physical Side Channels

#20

Post by marcosdumay »

mikeash wrote: post #16
cjbprime wrote: post #12

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.

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.)

Post reply on HN