14 ms·

ECDSA Key Extraction from Mobile Devices via Nonintrusive Physical Side Channels

122 points by moks 11y ago

moks 11y ago
From the abstract "We show that elliptic-curve cryptography implementations on mobile devices are vulnerable to electromagnetic and power side-channel attacks. We demonstrate full extraction of ECDSA secret signing keys from OpenSSL and CoreBitcoin running on iOS devices, and partial key leakage from OpenSSL running on Android and from iOS's CommonCrypto. These non-intrusive attacks use a simple magnetic probe placed in proximity to the device, or a power probe on the phone's USB cable. They use a bandwidth of merely a few hundred kHz, and can be performed cheaply using an audio card and an improvised magnetic probe".
taneq 11y ago
What sorcery is this?!
smartbit 11y ago
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.
- 05 11y ago
  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 time is ~1 minute, T(10000) = 10000 minutes / N (= a week if N==1)
  - 13of40 11y ago
    Do you have a good citation for that or is it just a personal theory?
    - mikeash 11y ago
      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-code/ 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.
      - dr_zoidberg 11y ago
        Thanks for the link, it looks interesting.
      - superuser2 11y ago
        Note that this was patched and is no longer feasible.
    - 05 11y ago
      A personal theory. The iPhone Wiki has a description of iPhone storage structure - it seems newer phones (pre Secure Enclave) don't have separate NOR, NVRAM and NAND - they just use NAND for everything. [1] https://www.theiphonewiki.com/wiki/NOR https://www.theiphonewiki.com/wiki/NOR
- karlytypes 11y ago
  iOS 9, which apparently isn't vulnerable to this, was released 3 months prior to the San Bernardino attack. Furthermore, is a locked phone just sitting there performing time-dependent ECDSA signing operations all day long?
- tptacek 11y ago
  How would that attack work? The key isn't resident; it's derived in part from the passcode. The target can't do any useful work with the key that could leak through side channels, because it doesn't have the key.
powerbutton65 11y ago
It's great to see this kind of work published. It is worth noting however that the US government is well aware of these kind of attacks. The Snowdon docs show that the CIA have been performing side-channel analysis since 2012 on the Iphone 4s and Ipad 2: https://theintercept.com/2015/03/10/ispy-cia-campaign-steal-apples-secrets/ https://theintercept.com/2015/03/10/ispy-cia-campaign-steal-... Cryptography Research demonstrated this on an ipod in 2011: https://www.youtube.com/watch?v=4L8rnYhnLt8 https://www.youtube.com/watch?v=4L8rnYhnLt8 In any case, great stuff.
gdgtfiend 11y ago
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).
- powerbutton65 11y ago
  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.
ge0rg 11y ago
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] https://cr.yp.to/ecdh.html https://cr.yp.to/ecdh.html [1] https://nacl.cr.yp.to/ https://nacl.cr.yp.to/ [2] http://cr.yp.to/talks/2006.04.25/slides.pdf http://cr.yp.to/talks/2006.04.25/slides.pdf
- ge0rg 11y ago
  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".
  - cjbprime 11y ago
    Upvoted, you're totally correct. Each of these attacks is providing support to DJB's focus on constant time implementations of everything.
    - mikeash 11y ago
      Does constant time mean constant power usage and constant EM emission? It seems like those would be separate problems.
      - marcosdumay 11y ago
        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.)
CiPHPerCoder 11y ago
Oh if only there were a elliptic curve digital signature algorithm that was side-channel resistant and well studied by cryptography experts. https://en.wikipedia.org/wiki/EdDSA https://en.wikipedia.org/wiki/EdDSA (Fortunately, we should see its adoption when TLS 1.3 is standardized.)
- nullc 11y ago
  EdDSA is not fundamentally more sidechannel resistant; sidechannel resistance is a function of the implementation. EdDSA's authors make a reasonable argument that it takes less work with their parameters to make a timing sidechannel free implementation which is also fast (at least for secret key operations); but "less work" isn't really the problem when comparing to a grotesquely vulnerable implementation, especially where it would be perfectly acceptable to take a slowdown implied by an especially simple way of making the operation constant time. It would be more accurate to say that so far EdDSA has had a more conscientious implementation culture around it. But I think that won't last if too many people misunderstand sidechannel resistance as automatic there (even now one can go to lists of ed25519 implementations and get linked, without warning, to implementations which are not sidechannel resistant at all).
  - CiPHPerCoder 11y ago
    > EdDSA is not fundamentally more sidechannel resistant; sidechannel resistance is a function of the implementation. > ... > It would be more accurate to say that so far EdDSA has had a more conscientious implementation culture around it. Your assessment is correct. EdDSA is deterministic which eliminates the nonce-reuse concerns, but deterministic EdDSA/ECDSA requires side-channel resistance. I erred in my previous comment.
    - nullc 11y ago
      Right. One can easily implement EdDSA without deterministic nonce generation or with insecure nonce generation (it would be an error to call it EdDSA: but no verifier could tell; and if the signature is accepted that is EdDSA-enough for people to call it that in practice); likewise one could implement ECDSA with deterministic nonce generation (e.g. as specified in RFC6979). It's not hard to find examples of both.
AdmiralAsshat 11y ago
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?
- powerbutton65 11y ago
  Valid question. You shift the burden from being a cryptography related problem to signal processing related problem.
  - dogma1138 11y ago
    This isn't exactly a cryptography related problem to begin with, it's an implementation issue which inherently all side channels attacks are. This doesn't mean that you can't add some resistance against side channel attacks to your cryptographic algorithm but it will cost you quite a bit in terms of performance, and for the most part it's not where it should be. Better silicon should solve some of these issues, for example adding some additional isolation between the power section and the logic a small super-cap with decent in-band filtering might do the trick. As far as radiating EM goes I'm not sure what can be done but some more additional shielding and EM noise reduction should add some degree of protection. Most implementations will eventually be vulnerable to some type of side channel attacks, the complexity and cost-vs-benefit is important here. Launching an evil USB attack on the off chance of getting a key is most likely not very scalable, but considering that NFC/wireless payments for phones will become more and more common, and that crypto-currencies might actually end up being in common day use being able to extract keys during signing from EM leakage might just be the natural evolution of ATM/Payment Cards skimmer attacks. In the past 2-3 years we had various key extraction attacks using "strange" vectors like EM/audio extraction, temperature, cpu usage, cross platform cache attacks, these attacks can threaten cloud computing and mobile computing quite severely unless we can root them out and being to modify the devices and platforms to be much more resistant to them.
- brohee 11y ago
Confiks 11y ago
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 symmetric ciphers so 'constant' as not to reveal anything about the master key?
- tptacek 11y ago
  From one of the same authors: https://www.tau.ac.il/~tromer/papers/cache.pdf https://www.tau.ac.il/~tromer/papers/cache.pdf
- powerbutton65 11y ago
  The authors cite some EM side-channel attacks in the paper (eg [0,1]) [0]: https://eprint.iacr.org/2015/561.pdf https://eprint.iacr.org/2015/561.pdf [1]: https://eprint.iacr.org/2015/727.pdf https://eprint.iacr.org/2015/727.pdf
nullc 11y ago
This work is very important. Some might dismiss it because it is no surprise that these implementations would have serious sidechannel vulnerabilities, and --indeed-- in Bitcoin Core we stopped using OpenSSL for signing two years ago for this reason. But, as cryptographers ourselves, our choices aren't all that representative of application authors in general. I've found it to be difficult to get parties to stop using obviously vulnerable crypto code-- even businesses making "high security" hardware wallets. Everyone has many other priorities, and without a demonstration the attacks are "too theoretical" to spend time on, or to justify a software slowdown, for many people.
- zmanian 11y ago
  What was the process of learning about side channels and techniques for mitigating them when developing libsecp256k1? It's an area I'd love to better understand.
  - nullc 11y ago
    For us it was an iterative process that started with making a commitment to do our best to do the right thing-- accepting that we don't control how the users us the software and that to do a good job we must defend against a very broad class of attacks... and that it's a good investment of time to really refine the tools here so that the users have the least time lost to worrying about the details of the underlying behavior. The earlier work on cache sidechannel attacks against OpenSSL also helped convince other people that this was important. Pieter did a cache timing attack project against DES at his university in 2004. I had experience with modeling fine scale algorithm delays as part of ultra-low latency audio codec work. So we had a little bit of additional background beyond regular systems programming and mathematical experience. We spent time studying other implementations and academic papers on the subject-- just a product of searching and following citations-- and we implemented and measured (both in timing form and 'read the assembly' form). Pieter had to do some algebraic work to adapt a 'unified' group law approach to our curve and coordinate system. [Then all of this also presented additional verification work to validate that the new group law was algebraically correct.] Because we accepted that this was going to be a considerable amount of work, we didn't refrain from trying multiple ideas and throwing things away. The libsecp256k1 codebase is written in a clean (IMO), typesafe, heavily tested way that makes iteration easier. We initially implemented a bit-slicing approach to achieve memory access uniformity. After we thought we were at least a strict improvement over OpenSSL, we contacted an outside expert (Yuval Yarom, one of the authors of this paper, in fact) and they were kind enough to give our implementation a look-- and pointed out some additional research that showed our particular bit slicing approach was not quite constant time on common hardware. So we fixed that too. I don't consider our work done on this-- we are likely vulnerable to differential power analysis on at least some hardware. We've implemented a basic level of blinding to harden against that-- but without a good measurement setup it's hard to tell if our efforts are helping (or maybe hurting, though that's unlikely). I loaned Thomas Daede a USRP, and he's been attempting to set up a DPA continuous integration rig for us (https://bitcointalk.org/index.php?topic=1319848.0); https://bitcointalk.org/index.php?topic=1319848.0); but it's effort that is competing with a lot of other projects for attention for all of us. Similarly some (now uncommon) hardware has things like data-variable time multipliers, and on that hardware little can be done beyond blinding; but again, without more analysis it's hard to know exactly where that stands.

122 points by moks 11y ago

moks 11y ago

From the abstract "We show that elliptic-curve cryptography implementations on mobile devices are vulnerable to electromagnetic and power side-channel attacks. We demonstrate full extraction of ECDSA secret signing keys from OpenSSL and CoreBitcoin running on iOS devices, and partial key leakage from OpenSSL running on Android and from iOS's CommonCrypto. These non-intrusive attacks use a simple magnetic probe placed in proximity to the device, or a power probe on the phone's USB cable. They use a bandwidth of merely a few hundred kHz, and can be performed cheaply using an audio card and an improvised magnetic probe".

taneq 11y ago

What sorcery is this?!

smartbit 11y ago

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.

05 11y ago
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 time is ~1 minute, T(10000) = 10000 minutes / N (= a week if N==1)
- 13of40 11y ago
  Do you have a good citation for that or is it just a personal theory?
  - mikeash 11y ago
    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-code/ 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.
    - dr_zoidberg 11y ago
      Thanks for the link, it looks interesting.
    - superuser2 11y ago
      Note that this was patched and is no longer feasible.
  - 05 11y ago
    A personal theory. The iPhone Wiki has a description of iPhone storage structure - it seems newer phones (pre Secure Enclave) don't have separate NOR, NVRAM and NAND - they just use NAND for everything. [1] https://www.theiphonewiki.com/wiki/NOR https://www.theiphonewiki.com/wiki/NOR
karlytypes 11y ago
iOS 9, which apparently isn't vulnerable to this, was released 3 months prior to the San Bernardino attack. Furthermore, is a locked phone just sitting there performing time-dependent ECDSA signing operations all day long?
tptacek 11y ago
How would that attack work? The key isn't resident; it's derived in part from the passcode. The target can't do any useful work with the key that could leak through side channels, because it doesn't have the key.

powerbutton65 11y ago

It's great to see this kind of work published. It is worth noting however that the US government is well aware of these kind of attacks. The Snowdon docs show that the CIA have been performing side-channel analysis since 2012 on the Iphone 4s and Ipad 2: https://theintercept.com/2015/03/10/ispy-cia-campaign-steal-apples-secrets/ https://theintercept.com/2015/03/10/ispy-cia-campaign-steal-... Cryptography Research demonstrated this on an ipod in 2011: https://www.youtube.com/watch?v=4L8rnYhnLt8 https://www.youtube.com/watch?v=4L8rnYhnLt8 In any case, great stuff.

gdgtfiend 11y ago

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

powerbutton65 11y ago
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.

ge0rg 11y ago

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] https://cr.yp.to/ecdh.html https://cr.yp.to/ecdh.html [1] https://nacl.cr.yp.to/ https://nacl.cr.yp.to/ [2] http://cr.yp.to/talks/2006.04.25/slides.pdf http://cr.yp.to/talks/2006.04.25/slides.pdf

ge0rg 11y ago
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".
- cjbprime 11y ago
  Upvoted, you're totally correct. Each of these attacks is providing support to DJB's focus on constant time implementations of everything.
  - mikeash 11y ago
    Does constant time mean constant power usage and constant EM emission? It seems like those would be separate problems.
    - marcosdumay 11y ago
      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.)

CiPHPerCoder 11y ago

Oh if only there were a elliptic curve digital signature algorithm that was side-channel resistant and well studied by cryptography experts. https://en.wikipedia.org/wiki/EdDSA https://en.wikipedia.org/wiki/EdDSA (Fortunately, we should see its adoption when TLS 1.3 is standardized.)

nullc 11y ago
EdDSA is not fundamentally more sidechannel resistant; sidechannel resistance is a function of the implementation. EdDSA's authors make a reasonable argument that it takes less work with their parameters to make a timing sidechannel free implementation which is also fast (at least for secret key operations); but "less work" isn't really the problem when comparing to a grotesquely vulnerable implementation, especially where it would be perfectly acceptable to take a slowdown implied by an especially simple way of making the operation constant time. It would be more accurate to say that so far EdDSA has had a more conscientious implementation culture around it. But I think that won't last if too many people misunderstand sidechannel resistance as automatic there (even now one can go to lists of ed25519 implementations and get linked, without warning, to implementations which are not sidechannel resistant at all).
- CiPHPerCoder 11y ago
  > EdDSA is not fundamentally more sidechannel resistant; sidechannel resistance is a function of the implementation. > ... > It would be more accurate to say that so far EdDSA has had a more conscientious implementation culture around it. Your assessment is correct. EdDSA is deterministic which eliminates the nonce-reuse concerns, but deterministic EdDSA/ECDSA requires side-channel resistance. I erred in my previous comment.
  - nullc 11y ago
    Right. One can easily implement EdDSA without deterministic nonce generation or with insecure nonce generation (it would be an error to call it EdDSA: but no verifier could tell; and if the signature is accepted that is EdDSA-enough for people to call it that in practice); likewise one could implement ECDSA with deterministic nonce generation (e.g. as specified in RFC6979). It's not hard to find examples of both.

AdmiralAsshat 11y ago

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?

powerbutton65 11y ago
Valid question. You shift the burden from being a cryptography related problem to signal processing related problem.
- dogma1138 11y ago
  This isn't exactly a cryptography related problem to begin with, it's an implementation issue which inherently all side channels attacks are. This doesn't mean that you can't add some resistance against side channel attacks to your cryptographic algorithm but it will cost you quite a bit in terms of performance, and for the most part it's not where it should be. Better silicon should solve some of these issues, for example adding some additional isolation between the power section and the logic a small super-cap with decent in-band filtering might do the trick. As far as radiating EM goes I'm not sure what can be done but some more additional shielding and EM noise reduction should add some degree of protection. Most implementations will eventually be vulnerable to some type of side channel attacks, the complexity and cost-vs-benefit is important here. Launching an evil USB attack on the off chance of getting a key is most likely not very scalable, but considering that NFC/wireless payments for phones will become more and more common, and that crypto-currencies might actually end up being in common day use being able to extract keys during signing from EM leakage might just be the natural evolution of ATM/Payment Cards skimmer attacks. In the past 2-3 years we had various key extraction attacks using "strange" vectors like EM/audio extraction, temperature, cpu usage, cross platform cache attacks, these attacks can threaten cloud computing and mobile computing quite severely unless we can root them out and being to modify the devices and platforms to be much more resistant to them.
brohee 11y ago

Confiks 11y ago

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 symmetric ciphers so 'constant' as not to reveal anything about the master key?

tptacek 11y ago
From one of the same authors: https://www.tau.ac.il/~tromer/papers/cache.pdf https://www.tau.ac.il/~tromer/papers/cache.pdf
powerbutton65 11y ago
The authors cite some EM side-channel attacks in the paper (eg [0,1]) [0]: https://eprint.iacr.org/2015/561.pdf https://eprint.iacr.org/2015/561.pdf [1]: https://eprint.iacr.org/2015/727.pdf https://eprint.iacr.org/2015/727.pdf

nullc 11y ago

This work is very important. Some might dismiss it because it is no surprise that these implementations would have serious sidechannel vulnerabilities, and --indeed-- in Bitcoin Core we stopped using OpenSSL for signing two years ago for this reason. But, as cryptographers ourselves, our choices aren't all that representative of application authors in general. I've found it to be difficult to get parties to stop using obviously vulnerable crypto code-- even businesses making "high security" hardware wallets. Everyone has many other priorities, and without a demonstration the attacks are "too theoretical" to spend time on, or to justify a software slowdown, for many people.

zmanian 11y ago
What was the process of learning about side channels and techniques for mitigating them when developing libsecp256k1? It's an area I'd love to better understand.
- nullc 11y ago
  For us it was an iterative process that started with making a commitment to do our best to do the right thing-- accepting that we don't control how the users us the software and that to do a good job we must defend against a very broad class of attacks... and that it's a good investment of time to really refine the tools here so that the users have the least time lost to worrying about the details of the underlying behavior. The earlier work on cache sidechannel attacks against OpenSSL also helped convince other people that this was important. Pieter did a cache timing attack project against DES at his university in 2004. I had experience with modeling fine scale algorithm delays as part of ultra-low latency audio codec work. So we had a little bit of additional background beyond regular systems programming and mathematical experience. We spent time studying other implementations and academic papers on the subject-- just a product of searching and following citations-- and we implemented and measured (both in timing form and 'read the assembly' form). Pieter had to do some algebraic work to adapt a 'unified' group law approach to our curve and coordinate system. [Then all of this also presented additional verification work to validate that the new group law was algebraically correct.] Because we accepted that this was going to be a considerable amount of work, we didn't refrain from trying multiple ideas and throwing things away. The libsecp256k1 codebase is written in a clean (IMO), typesafe, heavily tested way that makes iteration easier. We initially implemented a bit-slicing approach to achieve memory access uniformity. After we thought we were at least a strict improvement over OpenSSL, we contacted an outside expert (Yuval Yarom, one of the authors of this paper, in fact) and they were kind enough to give our implementation a look-- and pointed out some additional research that showed our particular bit slicing approach was not quite constant time on common hardware. So we fixed that too. I don't consider our work done on this-- we are likely vulnerable to differential power analysis on at least some hardware. We've implemented a basic level of blinding to harden against that-- but without a good measurement setup it's hard to tell if our efforts are helping (or maybe hurting, though that's unlikely). I loaned Thomas Daede a USRP, and he's been attempting to set up a DPA continuous integration rig for us (https://bitcointalk.org/index.php?topic=1319848.0); https://bitcointalk.org/index.php?topic=1319848.0); but it's effort that is competing with a lot of other projects for attention for all of us. Similarly some (now uncommon) hardware has things like data-variable time multipliers, and on that hardware little can be done beyond blinding; but again, without more analysis it's hard to know exactly where that stands.