Single-decryption EM-based attack reveals private keys from Android phones [pdf] | Hacker News Reader

Single-decryption EM-based attack reveals private keys from Android phones [pdf]

usenix.org

111 pointsdhx45 comments

For those not familiar with reading papers, just read the conclusion and see figure 12 on the same page. It's a fair summary of both the obtained results, required hardware and possible mitigation.

They mention "sub-$1000 hardware" as required, but for 1GHz and 40MHz, a HackRF One knock-off of $150-$200 should do just fine. Heck, you might be able to run with some DVB-T sticks at $20 depending on the chip in your particular model and production batch (the one for $15 I had went from 20-800MHz, just short of a gigahertz).

this magnetic probe they use, you think it's hall probe -> frequency analyser? perhaps a hall sensor + arduino would work ? (sorry im not good with electronics :D..?) i'm wondering how to get the magnetic signal into my hackrf or arduino. how to catch it? they just mention using a probe, and i see on the picture some device which looks just to be hooked up to antenna cable?

Could just be a coil of wire with a LNA in front of it. Would be curious about the details as well.

I wonder if one could use the read head from an old HDD

1GHz is easily in range of RTLSDR, but required 40MHz bandwidth is problematic. LimeSDR for 300$ could be suitable.

Yeah, that's pretty darn impressive to do that with a magnetic probe, no physical connection needed.

Gone are the days of putting a sense resistor between the safe and battery, just pick it out of the air now.

It's interesting how we've really entered the era of side channel attacks and vulnerabilities. We're seeing this with the meltdown bugs (speculative execution is a kind of side channel) and now we are seeing stuff where even if your code is well written you have to take into account if the hardware executes in a certain way to leak EM emissions.

I imagine we are going to see more and more of these types of attacks.

Yep, several times this year I had to do double-takes to see if directional microphones are now considered script-kiddie level toys. Nope, it's "just" SDR.

Meltdown is ultimately a timing attack, so it definitely qualifies.

I take this as an indication that the underlying cryptographic primitives have become really good, so it’s no longer (usually) practical to attack that layer.

Were the underlying cryptographic primitives ever bad (in a practical attack sense)? Even DES with it's 56 bit key was not cracked in a real targeted attack.

DES can be brute forced. RSA can as well, with key sizes that were once considered reasonable. MD5 and SHA-1 both have serious vulnerabilities.

Edit: it also used to be really common for people to use crappy, often homegrown primitives. How many systems were broken because the “encryption” was a simple xor with a fixed key or something? Now it’s very likely that the information you want to access is protected with something like TLS.

I mean, DES could be broken fairly fast with commodity GPUs 8 years ago [1], it's not gotten slower to break since.

[1] - http://home.deib.polimi.it/barenghi/files/ITNG2010.pdf

For meltdown, speculative execution alone only allows an attacker to load stuff in to the processor's cache, actually reading if from cache requires a textbook side channel timing attack.

So meltdown definitely qualifies as side-channel.

Ironic that a user with a rooted phone will probably have this fix before official firmwares get updated if at all. Yet most banks and some other app (snapchat) don't let you run them if you phone is rooted.

Magick's root hiding module fixes this, and you're probably running Magick anyways to re-enable Google Play certification.

It's still funny that Banks infer rooting, and maybe even weirder, using a custom ROM equals a security vulnerability when usually the reverse is true.

Not really. My generally-reasonable local bank has a sign up asking people to remove hats and sunglasses (I don't). It's about pushing whatever they think helps their security, often at the expense of yours.

Google isn't going to use its control of your phone to directly transfer money out of your bank account - that would be illegal, so Google is not a threat to the bank.

You are under attack from Google, and taking back ownership of your phone is a necessary step to defending against this. It's just not the bank's concern.

I don't think they're referring to Google as the threat, but the fact that stock Android is often outdated and missing patches.

I guess there's that too. As someone that has strayed from the herd, I had forgotten about that whole planned obsolescence thing. Although the herd immunity does still somewhat apply to outdated devices, given the bank knows which Android version you're on, and can thus increase their prior that the device has been pwnt by 4th parties.

It gets worse. Log into Bank of America with a perfectly up-to-date Firefox on Linux, and you'll get a dickbar across the top of the screen stating "You are using an unsupported browser version. Learn more or update your browser."

Apparently, they've decided that Firefox isn't Firefox when it's not running on Windows.

I haven't tried this because I haven't used a bank application on an Android device, but how does it perceive LineageOS with its official SU capability? When the application asks for root, can you deny root in the prompt and the app will be none the wiser?

My bank is quite funny about this because even if you disable su on LOS it will write to a file that your phone has been rooted because of the cutsom rom, so even if you install magisk after the bank app freaks out, you still can't make it _forget_ that you had root. Also it takes a week to activate most features on the app after install, _sigh_, so uninstalling is pretty much not an option either.

The funny part is, when you first open the app after install, to stop root/rom users using some features, they just write a boolean to Android's shared preferences `USER_HAS_ROOT` or something. So _if_ you do have root you can just use a file explorer, or adb or something else go to the shared prefs file, change the value to false and when you relaunch the app, as long as magisk is installed, it works fine.

But no, my app doesn't like Los, and I think I even had to uninstall the inbuilt su of the ROM.

Tangentially, on the topic of banks & security, I decided the other day I would try out the virtual credit card number feature available on one of my credit cards. It turns out using the feature requires...Flash! Sigh.

BoA? I use that feature too, and I'm worried that they'll just drop it once flash reaches end of life.

Nope, so that makes two.

I'm expecting them to add it to their mobile app.

https://forum.xda-developers.com/android/general/snapchat-ro...

Works for me. Although some versions are less buggy than others on different roms.

What has it got to do with root ? You're talking about custom ROMs v/s OEM ROMS. Yes, custom ROMs will be faster with updates, but that has got nothing to do with root. What you mean is phones with unlockable bootloaders can flash a custom ROM. Unlockable bootloader =\= root.

Is it not possible to stop the app from figuring out the phone is rooted?

As I read this paper, the attack used a training set on the target hardware with the exact antenna setup; then ran a test set on the exact same configuration to demonstrate key recovery. This seems like it would be much more difficult to execute in the wild on a random device at Starbucks.

- The device would have to be profiled ahead of time.

- There's nothing else running on the device but the key decryption at some point.

- The device is quite close to the detection apparatus (within 20 cm in the paper).

The paper states that a mitigation has been merged into openSSL, how near is that version to being pushed to android?

For an android build to be released with this mitigation included: Six to nine weeks.

For the mitigation to be implemented on your android phone: Six to nine years.

Funny way how you spell decades

He meant centuries.

Or the multiple phones you go through before you will find it included.

I wonder when we'll reach the point that devices actively defend themselves. In this case, the device might emit a stronger signal on the frequency that it anticipates might be sampled, masking its true operation.

I’m curious to hear more about what the device itself was doing. It’s doing RSA decryption, of course, but is that it? Can we still recover “d” if the phone is doing other stuff at the same time? I wonder if exponentiaton is produces distinct enough signals. Seems like it might.

So, if someone has your phone, they have your phone's private RSA key. Jesus.

I’m curious how reliably you could distinguish the act of exponentiaton from other activity if the phone was just sitting on a table. (Or if it was being actively used, but you weren’t able to see what was happening.)

Any possibility of picking out the pattern of exponentiation activity from a long recording of the device working? ML?

So, exactly the same as it has always been!

What's the point of buying into this model where a possessor (ie owner) of a device is considered an attacker? It hasn't even shown itself to be workable on general-purpose computers, meanwhile users' practical experience seems to be centered around companies that are attempting to hinder people attempting to retain ownership of their phone.

Especially as the main push is aimed smaller devices - exactly the ones easier to take with you! At a certain point, the threat from the past (undetectable tampered software) outweighs the threat from the present (due to being able to easily read out the entire device state). It's a bit tough to take a rackmount server into the shower with you, but there's very little reason for a usb-port-sized device to stymie the user for the goal of protecting against physical access.

> So, exactly the same as it has always been!

Not really. Apple's Secure Enclave is resistant against many side channel attacks, including differential power attacks.

Sure, but that is a recent development which the jury is still out on.

I'm just saying for most all of computing history (besides a few perverted niches), we've thought of the data on the device is accessible by the person who has the device. So this attack just puts us back at the traditional expectation - a place that a large amount of people would actually just prefer to stay.

Just keep your phone in a wire mesh pouch. Oh wait...

I can't remember the exact year, but a while back, maybe 10 years ago, I was talking about this type of attack with some friends, including an EM transmission guy, and we came to the conclusion that it would be hard, but probably possible and it could probably be worked into an airport security scanner.

If memory serves, I sent Bruce Schneier an email about it and he replied with:

"Very interesting. Thanks."

Now that I'm older I realize the hard part would be keeping it secret that you're doing this, not actually pulling it off.

Reply on news.ycombinator.com