Hacker News new | past | comments | ask | show | jobs | submit login
Wireless Charging Power Side-Channel Attacks (arxiv.org)
68 points by tosh on Sept 13, 2021 | hide | past | favorite | 37 comments



This doesn't seem like a surprising result, but it's nice to see it demonstrated. It's also a clear demonstration that avoiding untrusted chargers isn't just a matter of avoiding plugging your phone into random USB sockets - if you have a sufficient level of concern, it's also a matter of not putting your phone down on a flat surface that someone could have put a charger in and then letting your phone do some cryptography.


Where will it end though? At this level of paranoia how would people leave the house?

At some point you need to have a level of trust which is viable for daily life.


I wouldn't mind a toggle switch in settings that requests me to push "Yes" if I place my phone on a wireless charger. If you leave this function off, it just charges (for people who don't mind the risk).


When you connect your iPhone to a new and unrecognized device, it actually asks to whether trust or not trust that device.

If your device is locked, you need to authenticate to trust to said device.


Really, even wireless chargers? That's great.


A wireless charger has no data transfer capability yet, so "no" for now. However if a USB port shows any sign of data transfer capability, it's blocked until you trust it.

Power starvation / observation attacks are passive attacks in a sense. They get their results by observing only.


> A wireless charger has no data transfer capability yet

..but...the article


The article is about a side-channel attack, where you don't transfer any data, but just observe something (in this case power draw from a wireless charger) to get some information.

In these types of attacks, you don't transfer any actual information, but guess something from observation.

There are more exotic attacks [0][1] which exploit the heat computers generate to exfiltrate data or time power starvation attacks.

[0]: https://dl.acm.org/doi/pdf/10.1145/3133956.3133994 [1]: https://www.wired.com/2015/03/stealing-data-computers-using-...


Clearly what's needed are single use phones that don't need charging, thus eliminating the side channel.


Even simpler; do not use when it's charging.


The severity and number of side-channel attacks is slowly becoming cripplingly ridiculous. At what point do we just give up with side-channel attacks on consumer devices and assume the mentality that all consumer devices connected to the internet should be treated as insecure by default.


> At what point do we just give up with side-channel attacks on consumer devices and assume the mentality that all consumer devices connected to the internet should be treated as insecure by default.

There is always an endless stream of vulnerabilities for every piece of tech you use: software, OS, router, etc. This fact is not a good reason to embrace security nihilism, for consumer devices, routers, or servers. When any vulnerability is found, it should be remediated within reason (likelihood of exploitation, severity of exploit) and life should go on until the next one is found. That's one of the persistent costs of using technology.


Next week on HN:

School teachers able to determine which students have been using their phones in class by looking at battery charge before and after.


Was going to guess it was by microscopic blackouts every second where sensors would detect the source of any light that remains.


Starting at least several years ago, if not a decade. The security industry has had this policy towards IoT devices before the technology was even cheap enough to mass produce.


> assume the mentality that all consumer devices connected to the internet should be treated as insecure by default.

"Zero trust security model" https://en.wikipedia.org/wiki/Zero_trust_security_model :

> The main concept behind zero trust is that devices should not be trusted by default, even if they are connected to a managed corporate network such as the corporate LAN and even if they were previously verified.


I'm not sure if I understood it correctly but it sounds like they're able to know which website of the top 20 you're visiting based on how much the power usage changed whilst charging.

If that's correct then what's the actual real world problem here?


Power analysis have opens a lot of doors for indirect attacks.

If they can predict which site you're on, they can also possibly detect an unsecured secure algorithm's state.

SSL or PGP had a similar "power starvation" attack: reducing the power to the power supply and watching power drainage allowed one to predict private keys.

The attack has been patched, then.


This sounds really interesting! Do you have any links where I can read more about this power starvation attack?


I remembered it correctly: It's the RSA part of OpenSSL which was cracked (or leaked to be exact), 11 years ago (wow, time flies).

Summary is here [0], and paper is here [1].

[0]: https://www.theregister.com/2010/03/04/severe_openssl_vulner...

[1]: http://web.eecs.umich.edu/~valeria/research/publications/DAT...


Does anyone actually use their phone while attached to a wireless charger? It seems incredibly awkward.


I actually use mine. Generally stream music to something. However, you don't need to use it.

iOS does a lot of thing during charging. Face recognition, backups, mail checks, software updates, another applications' background stuff.

It might as well interact with your home or car over BT (cars have wireless charging these days). There's a myriad of opportunities there.


There are wireless charging phone mounts:

* https://www.rammount.com/shop-all/phone-mounts/wireless-char...


There really is none, if you control the environment where someone is charging their phone while using it, it wouldn’t be hard to just point a hidden camera at the screen.

Or just offer free wi-fi and watch people’s traffic.


That assumes the camara always has a view and that there's no VPN or other layer protecting the traffic.


No, if all you want is detecting which one of 20 websites a user is browsing to, which you can by checking how much power it uses, you can definitely do that from traffic patterns even if the traffic flows through a vpn.

And this ‘leak’ assumes a user has his phone on a charger while it is already full, there is no guarantee it works.


To me this is notable research because if this side-channel attack is possible, then maybe more serious ones are.


According to the paper, the leak occurs when the battery is close to full (>95%). In that case, since the battery is almost full, the power drained from the charger reflects the concurrent power being consumed by the device.

I initially thought this is easily fixable (for example, by always request full power), but then I realized it isn't, since the extra power would then have to be dissipated as heat, which is a bad cellphone UX as well.


And then the heat might become a new source of leak, given precise enough instruments.


They’re already like 50% efficient with the inefficient 50% largely being the phone acting like an inductive pan and heating up, so what’s a bit more heat.


Checked the power draw a couple years ago on reddit's new design, which was a huge increase from the old design. Should have written a paper with lots of clever words in it, could have been my first scientific contribution!

I didn't because this research has been done long ago and with rsa key operations, which are both more severe if you can capture it and much more difficult to measure. That you can see the difference between multi-megabyte JavaScript pages is a given at that point.


From https://planetfriendlyweb.org/mental-model :

> When you think about how a digital product or website creates an environmental impact, you can think of it creating it in three main ways - through the Packets of data it sends to users, the Platform the product runs on, and the Process used to make the product itself.

From https://sustainableux.com/talks/2018/how-to-build-a-planet-f... :

> SustainableUX: design vs. climate change. Online, Worldwide, Free. The online event for UX, front-end, and product people who want to make a positive impact—on climate-change, social equality, and inclusion


I wonder if someone tested this on Tor Browser, I'm curious if the attack can be implemented on that.


Of course it can, one doesn't need to test this. It's not as if any browser would allocate and burn the cpu at 100% for 30 seconds and then stop all javascript execution or css rendering or anything on the page. That's the kind of solutions you're looking at to fix this. This is like research to confirm the sky is blue. Good to know for sure but we're rather sure to begin with.

If you want to try it, a power meter is a good thing to have anyhow, or someone could lend you one. Plug it in and load different websites a few times, then look how many joules you used. Not every site can be told apart with a limited measurement like this, especially on the lighter end of the spectrum, but if you want to know if Tor Browser mitigates this then you can confirm it this way.


What if background processes meddle with the measurement?

Also, wasn't there some kind of WebRTC which allowed a remote website to get battery readings?


The usefulness of this given how finnicky wireless chargers are is questionable, over USB seems more plausible as even a USB condom wouldn't protect you from this.

I imagine sitting in an airport, charging my phone and using the free WiFi. I see a friend showing their new Nikes on Instagram, then start browsing the Nike website myself. After a few minutes I look up and see the information screen opposite me showing an advert, "20% off Nike today".


Thank you for article. We have not avoided many security concerns on almost every topic. Maybe this one help. At least one early stage technology will be secure enough. Beside that we can continue to consume other type of attacks from other weak points as a daily routine :D




Consider applying for YC's W25 batch! Applications are open till Nov 12.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: