[Cryptography] hacked hearing aids ("Code of Silence")

[Steven M. Bellovin]

On 18 Aug 2025, at 18:25, Jon Callas wrote:

>>
> I have a distinct raised eyebrow, while agreeing with you in principle.
>
> The main disagreement is that in the larger space, we have two related, but different devices, namely "headphones" and "headsets." Headsets are a superset of headphones; they have speakers and a microphone while headphones are only speakers. There's not only hardware differences, but there are differences in the networking profiles for the devices.
>
> Hearing aids are a type of headphone, not headset. They don't have a microphone and it is nearly impossible to make that work because the whole BT-hearing aid tech system assumes they are speakers, not microphones.
>
> Having said that, internally, hearing aids are audio processing systems that related to an MiTM in that they take audio in, process it, and then spit it back out again, so while the system boundary for hearing aids is that they're speakers, internally they are a mic -> speaker audio pipeline. You can, brushing away many things, totally rewrite the code and get the input. However, there's likely no network exfiltration pipeline neither in hardware nor protocol. So that's a problem. Moreover, you actually want to take over the hearing aids in a way that the owner does not detect. If you break the hearing aids, then the owner is going to do something. If you slow down the audio processing, the owner will very likely detect it. (I can supply anecdotes, but suffice it to say that low latency is the major selling point on hearing aids.) There's other things like battery life and so on, along with code size, etc.
>
A lot depends on the actual data paths—are they hard-wired or software-defined? These days, my money is on the latter, because of all of the signal processing that goes on inside.

Hearing aids have microphones, of course, to pick up the ambient sound. They also have speakers that (generally) go into one's ears. Some, like mine, can receive Bluetooth signals from, e.g., my phone. In principle, then, sound input from the mics can be routed to both the speakers and transmitted over Bluetooth, which of course means that there has to be a malicious Bluetooth receiver around that is paired with the hearing aids.

I suspect that code space is not an issue. There's a lot of code that is rarely used, e.g., the programming interface that the audiologist uses, features that aren't currently in use (mine can listen to my phone's microphone instead), etc. Latency might be an issue, but the real killer is likely to be battery life. I don't know what the current figures are, but on my previous pair I was told that if I used them as AirPods to listen to a lot of music battery lifetime might be cut by 75%. Then again, that same issue has long been raised as a reason why law enforcement can't turn a cell phone into a remote bug, but it was done almost 20 years ago: https://www.cnet.com/news/privacy/fbi-taps-cell-phone-mic-as-eavesdropping-tool/.

I'm really skeptical about open source hardware for hearing aids. Apart from the question of whether or not even dedicated, highly qualified examiners (and most folks are not) can find subtle back doors (they can't), hearing aids are a marvel of physical miniaturization and the consequent manufacturing requirements.



        --Steve Bellovin, https://www.cs.columbia.edu/~smb