Apple’s proprietary approach to securing Bluetooth peripherals, known as MagicPairing, has some benefits, but not magical enough to make vulnerabilities vanish. Researchers from TU Darmstadt in Germany examined the MagicPairing protocol and found that its three implementations – in iOS, macOS, and RTKit – contain ten disclosed flaws between them that have yet to be
Apple’s proprietary approach to securing Bluetooth peripherals, known as MagicPairing, has some benefits, but not magical enough to make vulnerabilities vanish.
Researchers from TU Darmstadt in Germany examined the MagicPairing protocol and found that its three implementations – in iOS, macOS, and RTKit – contain ten disclosed flaws between them that have yet to be addressed.
RTKit is the real-time operating system based on the RTKit framework and is used in Apple’s AirPods 1, 2, and Pro, Siri Remote 2, Apple Pencil 2, and Smart Keyboard Folio. While not widely known, it’s widely distributed, thanks to the popularity of Apple’s AirPods, which account for more than half of the global wireless earbud market.
In a paper [PDF] entitled “MagicPairing: Apple’s Take on Securing Bluetooth Peripherals,” Dennis Heinze, Jiska Classen, and Felix Rohrbach observe that Apple’s MagicPairing protocol overcomes two shortcomings of Bluetooth device pairing: poor scalability and a security model that collapses if the permanent key – the Link Key or Long-Term Key – gets compromised.
Despite this, they say, Apple’s implementation of MagicPairing still has problems, though not particularly serious ones.
“As MagicPairing is available prior to pairing and encryption, it poses a large zero-click wireless attack surface,” the Bluetooth boffins state in their paper, slated for presentation at WiSec ’20 in July.
Stuck inside with nothing to do? Apple fires out security fixes for iOS, macOS, wrist-puters… and something weird called iTunes for Windows
“We found that all implementations have different issues, including a lockout attack and a Denial of Service (DoS) causing 100 per cent CPU load. We identified these issues performing both, generic over-the-air testing and iOS in-process fuzzing.”
When two Bluetooth devices connect, they generate a permanent key that gets used to protect device authenticity, message integrity, and message secrecy. It remains in place until the user manually deletes it, by unpairing the devices, and it is the source from which shorter-lived session keys are derived.
MagicPairing adds Apple’s iCloud service into the equation. It generates fresh permanent keys based on user-specific iCloud keys every session, a security improvement over permanent keys that remain unchanged. It does so, the researches explain, using a symmetric ratcheting algorithm and authenticated encryption.
“The security goals of the MagicPairing protocol seem to be to provide authentication and a fresh shared key for each connection,” the paper explains. “It uses a symmetric ratcheting algorithm and authenticated encryption to achieve these goals.”
The researchers performed over-the-air fuzzing and in-process fuzzing using code called ToothPicker that they say they’ll make available through their Bluetooth testing framework called InternalBlue.
They identified eight MagicPairing and two L2CAP vulnerabilities that can induce crashes, overload the CPU, and disassociate paired devices. The paper says that they were disclosed between October 30, 2019 and March 13, 2020, and have not yet been fixed. The PoC code was published on Sunday.
In an email, Jiska Classen, a researcher with the TU Darmstadt’s Secure Mobile Networking Lab (SEEMO) and co-author of the report, suggested that Apple’s lack of action may be because Cupertino does not consider them to be particularly serious.
“In contrast, they will fix everything that is related to potential remote code execution very fast,” she said.
The paper says that Apple’s MagicPairing implementations in iOS and macOS contain a number of spelling mistakes in logging messages and, for macOS Bluetooth daemon
bluetoothd, function names.
“As these mistakes vary with the stack, each stack was probably implemented by a different developer,” the paper says. “While spelling mistakes are not directly related to flaws in an implementation, they leave the impression the code was not extensively reviewed, and development probably outsourced.”
Apple did not respond to a request for comment.
Asked about the apparently low code quality, Classen said her colleague Dennis Heinze found the bugs using the ToothPicker tool he created.
Based on his findings I would assume that Apple did not fuzz large parts of their Bluetooth protocol stack,” she said. “However, there are also parts that were well-tested. Probably this depends on the teams being responsible for certain protocols.”
However, Classen allowed that for some protocols, open-source over-the-air testing tools exist and other security researchers may have already used them to scrutinize Apple’s Bluetooth stacks.
“Overall, we were surprised that Apple did not fix the rather simple bugs that could be fixed by adding a few checks. However, we are also a bit ahead of the originally planned timeline, as the WiSec conference is virtual this year and authors were asked to pre-publish their papers,” she explained.
“Nonetheless, we informed Apple about the changed timeline and they did not disallow publication. And as even the oldest bugs are not fixed, this probably does not have to do anything with the changed timeline.” ®