Infosec bods pop mobile money crypto by 'sniffing' e-mag radiation Researchers have broken the encryption schemes used in mobile money transfers by “sniffing” electromagnetic radiation from smartphones. The work, by researchers from the Check Point Institute for Information Security at Tel Aviv University and the University of Adelaide, offers further evidence that TEMPEST-style side channel …
Not sure how practical it is, but it is rather simple to prevent via software changes. These types of attacks rely on being able to divine the key based on changes in workload - i.e. if you had more work for 1s than 0s or something along those lines.
If you change the software to do some 'unnecessary' work during the vulnerable calculations then the useful information is lost in the noise, at a (very) small cost in power for the wasted work.
Not sure how practical it is, but it is rather simple to prevent via software changes.
No, it isn't. Power, timing, and EMF side channels have been widely understood since Kocher's research in 1996, and a wide array of whitening techniques have already been implemented, but researchers continue to demonstrate new usable side-channel attacks. For example, OpenSSL already uses constant-time mathematical operations to whiten against timing attacks, and those have the side effect of whitening against some power- and EMF-channel attacks as well, but as this paper demonstrates, even on a general-purpose system (which includes smartphones) sufficient information may still leak.
Now, no doubt you know better than the OpenSSL development team and everyone else who's implemented whitening measures against side-channel attacks, and it's simple for you to prevent them; but apparently such magical skills are in short supply.
If you change the software to do some 'unnecessary' work during the vulnerable calculations then the useful information is lost in the noise, at a (very) small cost in power for the wasted work.
In fact, it's proven quite difficult to produce enough noise to prevent side-channel attacks in practice. And the power cost can be significant for battery-powered devices.
Admittedly this isn't something I've studied closely, I'm relying on what I've read 5-10 years after side channel attacks were first (publicly) described.
Still, for something like mobile payments I can't see how you could extract any useful information if you did your actual encryption in parallel with several other encryptions of random data. Yeah that's wasteful of power, but since mobile payments aren't something you do every few seconds and don't suffer if a tiny fraction of a second of latency is added, who cares?
For an attack against something you do often like sending an encrypted wifi packet obviously increasing your workload by 4x wouldn't be a good option.
I thought Android Pay also used elliptic curve? The EMV standard is 3DES, though it supports alternate methods. I assume that Apple (and Google, if Android Pay uses it as well) use elliptic curve because triple DES is rather power hungry by comparison...though I can't see how that would matter for something like payments that you would do a handful of times at most, per phone charge.
This is potentially very significant.
EC is pretty much the standard for new cryptosystems designed with mobile in mind, due to shorter key lengths and less computation when compared to RSA. For instance, the Austrian (and I think German) ID card schemes are build on EC - this stuff is now baked in at a very deep level. I realise these attacks are against software-based implementations, but the fact they they're done with relatively cheap hardware (impressive), against EC on relatively recent mobile devices is, I think, quite a big deal.
It's been years and we're all still running crappy, outdated crypto in our browsers - well imagine how long it's going to take to upgrade mobile infrastructure. There are hardware implementations of ECDH and ECDSA too, a successful TEMPEST attack against those would be huge.
As I said above, it is not difficult to fix software to block such attacks. Apple could fix this in the next iOS update if they wanted (though I doubt they are focused on TEMPEST style attacks against Apple Pay at the moment, since they have much bigger concerns right now like protecting iOS from the FBI forcing them to hack themselves)
Dedicated hardware presents much bigger problem, since the only option is replacing it.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
