ECDSA smartphone key extraction using $2 magnetic probe | Hacker News Reader

ECDSA smartphone key extraction using $2 magnetic probe

cs.tau.ac.il

292 pointspizza41 comments

Previous exciting works by the same research group (already discussed on HN):

- Acoustic cryptanalysis : https://www.cs.tau.ac.il/~tromer/acoustic/

- Get Your Hand Off My Laptop : http://www.tau.ac.il/~tromer/handsoff/

I saw a live demo of the latter at the CHES 2014 conference in Busan, it was really impressive.

Now to be honest, I'm less impressed by this new one because I already saw a very similar attack on a smartphone using an EM probe (except maybe it was on the RSA cryptosystem). I'm not entirely sure but it may have been at the CRI demo stand at the CARTES convention in Paris in either 2012 or 2013.

CRI had a demo like that at RSA (the conference) around that time, so I think your recollection is right.

yeah, talk about an exciting research group. so cool.

This is impressive, especially given how cheaply the attack can be realized. If you can get near the device you only need a coil and a sound card.

That being said:

> After observing the elliptic-curve double and add operations during a few thousand signatures, the secret signing key can be completely reconstructed.

This is probably the biggest obstacle for pulling this off in reality. I have no idea what that means in minutes or hours you have to be near a phone doing encryption though.

A few thousand might be a lot of negotiations. Often the assymetric keys like EC or RSA are only used once to negotiate a smaller/faster key for aes.

"The attack requires measuring a few thousand ECDSA signatures" - so not quite feasible by bumping into the target in a crowded subway.

And this is the kind of context i find often missing from security discussions.

It will still protect against anything short of a determined attacker with direct access to the hardware for an extended period.

Very little is secure against such a scenario, even less so if the attacker don't care about the defender knowing after the fact.

But all too often security research seems to consider anything that can be broken, even with the most complicated and time intensive of processes, as insecure.

But all too often security research seems to consider anything that can be broken, even with the most complicated and time intensive of processes, as insecure.

That's basically the whole point of security research - to find any weaknesses and try to fix them. It sounds great on the surface, but the logical conclusion of reaching "ultimate security" is not so pleasant...

Correct – the fact that there exists a possible way to extract these secrets is a chink in the armor. It's like how SHA1 started getting out of favor as soon as they started finding a couple of collisions.

Interesting that Apple already fixed this in iOS 9. Makes me wonder what kinds of crazy tests their security team must be doing, that they can mitigate such things.

These sorts of side channel vulnerabilities aren't some sort of new revelation-- the notion dates at least back to 2002 (per the authors' cited references). For example, one of the design goals of DJB's NaCl [1] is to mitigate side-channel vulnerabilities, specifically calling out data flow from secrets to load addresses (which has been used to break AES via a timing attack) and data flow from secrets to branch conditions (which is the sort of thing that's happening here-- where you can see secret-dependent patterns in the number and timing of operations in ECDSA computations) [2].

What's novel here is just how cheaply they're able to carry out these side-channel attacks.

[1] https://nacl.cr.yp.to/

[2] http://cr.yp.to/highspeed/coolnacl-20120725.pdf -- see section 3, Core security features and their impact

SHA1 fell out of favor long before any collision was found -- it fell out of favor in 2012 or even earlier, when it was clear that one will be found sooner than later.

FWIW, there is no publicly known SHA1 collision yet. There's a known freestart collision, and a real world (non-freestart) collision is expected to be found within the next couple of months by the same group (the search is already running on their cluster - and the expected time to success is a couple of months). They have already found the first pair that they need out of two.

A weakness that takes minutes or hours to exploit today isn't going to get stronger over time, it's going to get weaker, maybe to the point of only requiring a few seconds. The point of this kind of security research is to provide ample warning before an attack becomes practical.

This attack requires some time, but the general strategy works from feet away, or from the other side of a wall, or from far away on a VGA cable headed to a projector. Don't dismiss it as requiring "direct access to the hardware".

Only koblitz curves (secp256k1) seem to be secure?

On a related note, the Bernstein team designed Ed25519 with side channels attacks in mind. https://en.wikipedia.org/wiki/EdDSA#Features

It would have been nice if the paper had discussed Ed25519. Anyone else know what the status is relative to this (and other, similar) work?

The paper attacks implementations, not algorithms. As far as I know, all of the of the major Ed25519 implementations are side channel protected and safe (no branches on secret data, no array indexing with secret data)

HN discussion of the paper: https://news.ycombinator.com/item?id=11223266

Capturing the CPU instructions by a side-channel is indeed possible but the "real-life, working" use of the method described here is questionable for me. CPU in modern phones runs above 1GHz. USB sound card they're using provides max 192kHz which allows max 96kHz signal. 4 orders of magnitude less. There's also a lot of noise from different circuitry (GPU, display, wireless comm.) and laptop's noise as well which will obfuscate the signal.

It still strikes me as plausible. Sub-harmonics are a thing; it is entirely possible to leak data about what the CPU is or isn't doing down into the ultrasonic or audible bands.

As an example, one of my computers leaks a ton of noise into the onboard audio that quickly becomes audible with a moderate amount of gain. So much so, that I've learned to recognize changes in the noise pattern from various activities (shuffling windows around the gui, launching a program, compiling a program, etc).

How practical a real-life, working use of the method described here will depend in no small part how much noise the device being attacked casts off. There's some pretty bad devices out there.

You misunderstand the attack. You don't need to sample at 1GHz. Each 0 and each 1 in private key material leads to calculations taking thousands of tens of thousands of clock cycles. So you only need to sample EM radiations at around 100 kHz or 1 MHz.

Would like to know where to get those $2 magnetic probes :o

You can find it here: https://www.digikey.com/product-search/en/inductors-coils-ch...

Honestly, just strip coax away the outer sheath to expose the inner conductor. Make a loop with the exposed inner conductor and solder back onto the sheath. Increase the loop size or turns for lower frequencies.

Stripped probe is electric. Looped probe is magnetic. Stripped/looped probe is mixed probe. If you use coax - leave the shielding, just make sure to leave a gap. Just look at this picture [1] from this quite good article [2]. Depending on the design/equipment, you might need balancing/symmetrization.

Also directivity/sensitivity. While turn count will improve overall sensitivity, loop size will increase directivity. Keep in mind that both loop size and turn count affect probe filtering characteristics (it IS a filter), so I highly recommend experimenting with several designs. Have a look at my attempt at making magnetic probe from RG174 [3]. It is fat because of two layers of thermal shrink tube, which made it stiff enough for my experiments :)

It is hard to tell from a picture, but it should be that this probe uses two wires exactly for this purpose: one acts as a central conductor, other as a shield.

[1]: http://www.compliance-club.com/archive/old_archive/030718b.j... [2]: http://www.compliance-club.com/archive/old_archive/030718.ht... [3]: http://imgur.com/hiRUJl6

An RTL-SDR (6$ on ebay, get the R820T2) could work too.

The RTL SDR can (unmodified) only receive down to a few ten MHz. At least for some of their research they used a soundcard. As far as I know you will access different types of information. kHz range is mostly power consumption. Tens/hundreds of MHz is bus activity.

Both may be correlated, and both gives you side channel information to attack cryptography.

To me it looks like the coil of an wireless charger, or of an RFID reader.

Yes, this is what you can find inside a wireless charging pad or inside a wireless charging phone. You can find them on ebay for $3. Look for "usb wireless pad".

One of my favorite articles on how someone extracted the private key from a Trezor wallet: http://johoe.mooo.com/trezor-power-analysis/

I'm surprised that security researchers use Lenovo - at least apart from researching/testing their devices.

I suppose they have enough qualification to wipe clean those machines and install linux or at least a clean copy of windows.

On the contrary. They are qualified enough to know that there's not much they can do, whether it is Lenovo, Apple or Dell.

Windows PCs (especially enterprise laptops) are a commodity at this point. One brand doesn't offer a significantly better/worse product than another outside of build quality (which even then is usually just a factor of price). You just look for one that makes the tradeoffs (extra ports, bigger battery, etc) that fit with how you plan to use it.

It's time for smartphone manufacturers to improve smartphone's EMI shielding and improve key entropy!

Well, wideband EMI can't be fully shielded if you intend your phone to be a... phone.

very interesting angle of attack. I wonder if you could use this avenue to get something off of a yubikey?

Is this how the FBI are going to get into the iPhone maybe??

Not specifically. ECDSA is a signing algorithm. Unless there's some really fancy asymmetric authentication protocol between components within the phone, which perform curve operations, it's most unlikely. Of course, there's no saying a hardware side-channel isn't a possible attack vector.

There is a dedicated authentication coprocessor, to which the communications will be authenticated, so yes.

The thing you're talking about ("secure enclave") is not present in the phone the FBI are trying to attack.

Also, the Secure Enclave co-processor is on-die, so there will be no need to authenticate or encrypt communications with it.

I suppose not. I presume the way would be vulnerabilities in code handling untrusted data streams such as USB, Wi-Fi, or BlueTooth. Although the amount of time it takes might be getting longer, every major iOS update eventually has had jailbreaks, which implies for an organization with larger budget than jailbreak hackers would likely be able to discover 0-day vulnerabilities in iOS.

Reply on news.ycombinator.com