MagicPairing: Apple's Take on Securing Bluetooth Peripherals
MMagicPairing: Apple’s Take on Securing Bluetooth Peripherals
Dennis Heinze
Secure Mobile Networking LabTU Darmstadt, [email protected]
Jiska Classen
Secure Mobile Networking LabTU Darmstadt, [email protected]
Felix Rohrbach
CryptoplexityTU Darmstadt, [email protected]
ABSTRACT
Device pairing in large Internet of Things (IoT) deployments is achallenge for device manufacturers and users. Bluetooth offers acomparably smooth trust on first use pairing experience. Bluetooth,though, is well-known for security flaws in the pairing process.In this paper, we analyze how
Apple improves the security of Blue-tooth pairing while still maintaining its usability and specificationcompliance. The proprietary protocol that resides on top of Blue-tooth is called
MagicPairing . It enables the user to pair a deviceonce with
Apple’s ecosystem and then seamlessly use it with alltheir other
Apple devices.We analyze both, the security properties provided by this protocol,as well as its implementations. In general,
MagicPairing could beadapted by other IoT vendors to improve Bluetooth security. Eventhough the overall protocol is well-designed, we identified multiplevulnerabilities within
Apple’s implementations with over-the-airand in-process fuzzing.
CCS CONCEPTS • Security and privacy → Systems security ; Software secu-rity engineering ; Software reverse engineering; •
Networks → Application layer protocols . KEYWORDS
Bluetooth, Pairing, Security
ACM Reference Format:
Dennis Heinze, Jiska Classen, and Felix Rohrbach. 2020. MagicPairing: Ap-ple’s Take on Securing Bluetooth Peripherals. In
ACM, New York, NY, USA, 11 pages.https://doi.org/10.1145/3395351.3399343
Bluetooth device pairing has a long history of security flaws [1, 2,6, 15, 25, 26, 29]. While most issues were fixed in the Bluetooth 5.2specification [7], it is reasonable to assume that even this versionis not bullet-proof. Adding further layers of encryption within theapplications using Bluetooth is one solution many IoT developerschose [10]—but this leads to their devices being incompatible incommunicating with third-party applications and drains battery.Thus, encrypting data twice is no satisfying solution to this problem.Looking back into the history of Bluetooth security issues, it isnot the encryption itself that has been exploited this frequently.
WiSec ’20, July 8–10, 2020, Linz (Virtual Event), Austria © 2020 Association for Computing Machinery.This is the author’s version of the work. It is posted here for your personal use. Not forredistribution. The definitive Version of Record was published in , https://doi.org/10.1145/3395351.3399343.
Most problems originated from the initial key negotiation and con-nection setup. In Bluetooth, trust is established on first use bygenerating a permanent key. This permanent key protects deviceauthenticity, message integrity, and message confidentiality [7, p.269]. It is established individually between each pair of devicesand only changes when a user manually deletes and reestablishesa pairing. In Classic Bluetooth, the permanent key is called LinkKey (LK), while it is called Long Term Key (LTK) in Bluetooth LowEnergy (BLE)—however, they can be converted into each other [7,p. 280]. For the duration of each Bluetooth connection, a sessionkey is derived from the permanent key. Thus, if a device is out ofreach or switched off, this invalidates a session key.In modern IoT deployments, Bluetooth device pairing has twomajor shortcomings: (1)
It does not scale for pairing to many de-vices within an existing infrastructure, and (2) once the permanentkey is leaked, all security assumptions break for past and futureconnections. The permanent key can either be attacked by an ac-tive Machine-in-the-Middle (MITM) during pairing [6, 15, 25] or byRemote Code Execution (RCE) vulnerabilities within the chip [9].
Apple solves both challenges by introducing a protocol called
MagicPairing . It pairs
AirPods once and then enables the user toinstantly use them on all their
Apple devices. Security is improvedby generating fresh “permanent” keys based on the user-specific iCloud keys for each session. Seamless ecosystem integration andsecurity are imperative, since
AirPods are able to interact with the
Siri assistant.Despite being a proprietary extension,
MagicPairing is specifica-tion-compliant to the Host Controller Interface (HCI), and thus, canuse off-the-shelf Bluetooth chips. The general logic of
MagicPairing could be integrated into any cloud-based IoT ecosystem, increasingrelevance for the security community in general. Our contributionson research of
MagicPairing are as follows: • We reverse-engineer the
MagicPairing protocol. • We analyze the security aspects provided by this protocoland their applicability to other wireless ecosystems. • We document the proprietary iOS , macOS , and RTKit
Blue-tooth stacks. • We manually test
MagicPairing for logical bugs and automat-ically fuzz its three implementations. • We responsibly disclosed multiple vulnerabilities.While the overall idea of
MagicPairing is new and solves short-comings of the Bluetooth specification, we found various issuesin
Apple’s implementations. As
MagicPairing is available prior topairing and encryption, it poses a large zero-click wireless attacksurface. We found that all implementations have different issues,including a lockout attack and a Denial of Service (DoS) causing100 % CPU load. We identified these issues performing both, genericover-the-air testing and iOS in-process fuzzing. a r X i v : . [ c s . CR ] M a y iSec ’20, July 8–10, 2020, Linz (Virtual Event), Austria Heinze et al. iPhoneiCoud AirPods MasterKeyMasterHint
1a Key Creation 1b Key Distribution accKey via SSP and AAP
Setup ???
Pairing
BdAddrBlob ○ Hint hint x =enc ECB (MasterHint, BdAddrBlob)nonce_host x =arc4_rand()ratchet_host x while local_ratchet < ratchet:accKey=enc ECB (accKey, 0x10*0x00)
Generate authentication and encryption key:
SIV_Key x =enc ECB (accKey,’’bt_aessivauthentbt_aessivencrypt’’) ○ Ratcheting
AES_SIV x =enc SIV (SIV_KEY, rand_airpod+nonce_host+addr_airpod)ratchet_airpod x ○ AES-SIV
AES_SIV x =enc SIV (SIV_KEY, nonce_host+rand_host+rand_airpod+hint) unpack & check5 ○ Status Success & Link Key Derivation status sk_pre1=enc
ECB (rand_host, rand_airpod)sk_pre2=enc
ECB (rand_airpod, ’ \ x00’*0x10)while i != 16:link_key[i]=sk_pre1[i]+sk_pre2[i] calculate accKey and SIV_Key
AAP:
UpdateMagicCloudKeys sendsthe new accKey to the AirPods
KDF KDF KDF KDF Figure 1:
MagicPairing protocol steps.
Our fuzzing techniques can also be used to test other Bluetoothstacks and protocols. The Proof of Concepts (PoCs) for the identifiedvulnerabilities as well as the over-the-air fuzzing additions areavailable within the
InternalBlue project on
GitHub . The
ToothPicker in-process fuzzer part that integrates into
InternalBlue will followsoon, but has to be slightly delayed due to further findings [13].This paper is structured as follows. Section 2 gives an overview ofthe reverse-engineered
MagicPairing protocol. Its security proper-ties are explained in Section 3. Implementation internals regarding
Apple’s
Bluetooth stacks as well as
MagicPairing -specific detailsare provided in Section 4. Then, we explain our fuzzing setup inSection 5 used to identify the vulnerabilities explained in Section 6.We conclude our work in Section 7.
MagicPairing is a proprietary protocol providing seamless pairingcapabilities, for instance between a user’s
AirPods and all their
Apple devices. This is achieved by synchronizing keys over
Apple’s cloud service iCloud . The ultimate goal of the
MagicPairing protocolis to derive a Bluetooth Link Key (LK) that is used between a singledevice and the
AirPods . A fresh LK is created for each connection,which significantly reduces the lifetime of this LK.When a new or reset pair of
AirPods is initially paired with an
Apple device belonging to an iCloud account, Secure Simple Pair-ing (SSP) is used [7, p. 271ff]. All subsequent connections betweenthe
AirPods and devices connected to that iCloud account will use the
MagicPairing protocol as pairing mechanism.
MagicPairing in-volves multiple keys and derivation functions. It relies on AdvancedEncryption Standard (AES) in Synthetic Initialization Vector (SIV)mode for authenticated encryption [11].The protocol mainly consists of five phases. The protocol flow isvisualized in Figure 1 and explained in the following.
MagicPairing depends on a shared secret between the two participants. There-fore, the first phase establishes and exchanges a secret, followed byphases of the actual protocol. As the protocol is not publicly docu-mented, our naming relies on debug output and strings found inthe respective components, i.e., the Bluetooth daemon bluetoothd for iOS and macOS , as well as the
AirPod firmware. Further imple-mentation and Bluetooth stack details follow later in Section 4.
MagicPairing relies on a shared secret between the
AirPods and auser’s iCloud devices, the
Accessory Key (also accKey ). This keyis created by the first device pairing
AirPods for a specific iCloud account. After establishing an encrypted Bluetooth connectionusing SSP, the
Accessory Key needs to be transmitted to the
AirPods . Apple is using the
AAP Protocol for the Accessory Key transfer. Inaddition to the
Accessory Key , the host also creates an
AccessoryHint , which uniquely identifies the connection between an iCloud AAP is used for communication between a device and
AirPods . Its services all revolvearound configuring
AirPods and obtaining information from them, such as firmwareupdates, getting and setting tapping actions, or exchanging key material. agicPairing: Apple’s Take on Securing Bluetooth Peripherals WiSec ’20, July 8–10, 2020, Linz (Virtual Event), Austria account and the target device. The initiating device uses the iCloud account’s
Master Key and
Master Hint to create the
Accessory Key and the
Accessory Hint . In case these
Master credentials do not existyet, the device provisions them by creating random bytes. Anothercomponent that is needed to create the
Accessory Key and
AccessoryHint is the so-called
Bluetooth Address Blob , which is a deterministicmutation of the Bluetooth address of the targeted device, as shownin Listing 1. The
Bluetooth Address Blob is then encrypted with the
Master Key using AES in ECB mode to create the
Accessory Key .The
Accessory Hint is created by encrypting the
Bluetooth AddressBlob with the
Master Hint , respectively.After the initial setup, both devices share the same
Accessory Key .All devices logged into the iCloud account can generate the same
Accessory Key . In the following example, the device connects to the
AirPods , but all steps could also happen in the opposite direction. blob [1:5] = address [5:0]blob [6:9] = address [1:4] ^ address [0:3]
Listing 1: Creating a
Bluetooth Address Blob.
The first repeating phase in the
MagicPairing protocol is the
Hint phase. It ensures that both sides will agree on the same fresh sessionkey in the end that belongs to the correct device. The device initiatesthe pairing by sending a
Hint message. The
Hint message includesthree entries, the hint , a random nonce generated by the initiatinghost, and a
Ratchet . The
Ratchet is a counter used in later steps ofthe pairing process to rotate keys.The receiving end performs a local
Accessory Key table lookupfor the connecting device. The
AirPods use the hint that is includedin the
Hint message as a reference, iOS and macOS devices use theconnecting device’s Bluetooth address to look up the key. If no keyis found, the protocol is aborted with a
Status Message indicatingthat the initiating device is unknown.
The
Ratcheting phase is essentially a key rotation and derivationphase. The goal of
Ratcheting is to renew and maintain short-livedsession keys [21]. First, the
Accessory Key is rotated and then a
SIVKey is derived from the rotated key. The
Accessory Key is rotated byencrypting a buffer of 16 null-bytes with the current
Accessory Key using AES in Electronic Codebook (ECB) mode. After one rotationstep, the current counter, or
Ratchet , is incremented. This is doneuntil the local
Ratchet equals the
Hint’s Ratchet . Then, the
SIV Key is derived from the
Accessory Key by encrypting the static 32 Bstring bt_aessivauthentbt_aessivencrypt with the
AccessoryKey using AES in ECB mode. Next, an
AES-SIV value is created. Forthis, the device creates a local random value, concatenates it withthe received nonce and its own Bluetooth address, and encryptsit with the
SIV Key . This time, AES is used in SIV mode without anonce or any additional data. At the end of this phase, a
RatchetAES-SIV message is sent back to the initiating device. It containsthe local
Ratchet value, as well as the
AES-SIV value. The initiatingdevice executes the same key derivation steps as mentioned aboveusing the received
Ratchet value. This leads to both devices havingthe same updated
Accessory Key and
SIV Key . Using the derived
SIV Key , the initiating device can now decrypt the
AES-SIV value tounpack the random value of the responding device.
The initiating device will now create another
AES-SIV value. How-ever, this one is different from the one that the responding devicecreated before. First, the device creates a new random value. Then itconcatenates its nonce value, the new random value, the previouslyreceived
AirPods random value, and the hint value. This 64 B valueis then encrypted with the derived
SIV Key using AES in SIV modeand sent to the responding device. If the
AirPods can decrypt thereceived data, they send a
MagicPairing Status success message.
Finally, a Bluetooth-compliant connection LK is derived. First, two
Session Pre Keys are created and XORed. The
Session Pre Key 1 iscreated by encrypting the responding device’s random value withthe initiating device’s random value as key using AES. The
SessionPre Key 2 is created by encrypting a 16 B null-byte buffer with theresponding device’s random value using AES.It is important to note that even though
MagicPairing is a customkey derivation protocol, the further usage of this key is still com-pliant to the Bluetooth specification and does not require any mod-ifications to the Bluetooth chip. When establishing an encryptedconnection, the chip sends an HCI command to ask the host for thestored LK [7, p. 1948]. In case of
MagicPairing , the LK is not takenfrom the host’s storage but freshly created, which is completelytransparent to the chip. In either case, the LKs is stored on thehost. However, it is only short-lived within
MagicPairing , while itis permanent for a normal Bluetooth pairing.
The security goals of the
MagicPairing protocol seem to be to pro-vide authentication and a fresh shared key for each connection. Ituses a symmetric ratcheting algorithm and authenticated encryp-tion to achieve these goals.The idea of ratcheting was introduced by Borisov, Goldberg,and Brewer [8]. They introduced a continuous Diffie-Hellman keyexchange providing forward and post-compromise secrecy withina session. Marlinspike and Perrin [21] extended this notion in the
Double Ratchet algorithm to include a second, symmetric ratchetthat updates the key while one party is offline. A
Double Ratchet only provides forward secrecy, but no post-compromise secrecy.The
MagicPairing protocol uses only the symmetric ratchetingand therefore does not provide post-compromise secrecy. However,the usage of no expensive public-key cryptography makes thisprotocol feasible for usage with IoT devices like the
AirPods . Further,note that
MagicPairing uses ratcheting in a slightly different waythan the previous work: Instead of creating a new key per message,the protocol creates a new key per Bluetooth connection. What isdefined in the
Double Ratchet algorithm as message key is thereforea connection key in this protocol.In the
Double Ratchet algorithm, the symmetric ratchet consistsof a Key Derivation Function (KDF) that, given a chain key, producesa new chain key and an independent message key. This is donefor each new message, so each new message gets encrypted with iSec ’20, July 8–10, 2020, Linz (Virtual Event), Austria Heinze et al. a new key. As the KDF cannot be inverted, the knowledge of thechain key at some point only allows to calculate future chain andmessage keys, but no previous chain and message keys. Further,the knowledge of a message key does not enable an adversary tocalculate any of the chain keys.
MagicPairing uses two separateKDFs to accomplish the same goal: The first KDF,KDF ( k ) = enc ECB ( k , ) , is used to update the chain key. By using plain AES keyed with theold chain key to encrypt a constant (here: the bit string consistingof only zeros), it uses the Pseudo-Random Function (PRF) propertyof AES, which guarantees that without knowledge of the old chainkey k , the new chain key is indistinguishable from a random key.The second KDF,KDF ( k ) = ( enc ECB ( k , c ) , enc ECB ( k , c )) , where c is the string bt_aessivauthent and c bt_aessivencrypt ,produces a connection key, which itself consists of two differentkey parts, an authentication and an encryption part. By the sameargument as for KDF , the chain key cannot be calculated from theproduced key and both key parts are independent.The ratchet is initialized with the account key and the positionin the ratchet is synchronized by the values ratchet_host and ratchet_airpod .For the encryption of the messages between the host and the Air-Pod , AES is used in the SIV mode of operation. SIV, an authenticatedencryption mode, was introduced by Rogaway and Shrimpton [24]and standardized in the combination with AES in RFC5297 [11]. Itis used without any headers in
MagicPairing , which is secure aslong as the entropy of each message is high enough. As all mes-sages encrypted with AES-SIV contain a new random number, theentropy is sufficient.Finally,
MagicPairing uses a third KDF to generate the key usedfor the Bluetooth connection, based on two random values, onegenerated by the host and one generated by the
AirPod :KDF ( r h , r a ) = enc ECB ( r h , r a ) ⊕ enc ECB ( r a , ) Again, this uses the PRF property of plain AES to generate a keythat is indistinguishable from random as long as not both randomvalues are known. Knowledge of the final key implies knowledge of the SIV key,which in turn implies the knowledge of the account key, which iden-tifies the party as being connected to the iCloud account. Further,for each connection a new key is used in a forward-secret manner.Therefore, the protocol meets the security goals of authenticationand forward secrecy.
In the following, we discuss
Apple -specific implementation details,which impact our security analysis. Section 4.1 compares the threeBluetooth stacks. As all of them differ significantly, the attack sur-face as well as bugs in their implementations vary. Section 4.2 liststhe
MagicPairing message formats, which are relevant for fuzzingthe protocol, as well as understanding the fuzzing results and at-tacks. Section 4.3 explains the advertisements sent by
AirPods , andbased on these, connections are initiated. Finally, we spot manyspelling mistakes, as shown in Section 4.4, which outline the
Mag-icPairing code quality.
Apple uses three fundamentally different Bluetooth stacks in theirrecent devices. Each stack is for an individual device type andsupports a subset of features. Thus, the protocols they support haveduplicate implementations. While this circumstance helps us toreverse engineer these protocols, it raises maintenance overheadfor
Apple . From a security perspective, this results in different issuesin these stacks, as shown later in Section 6.
RTKit is a separate framework for resource-constraint embeddeddevices. While this separation to reduce features makes sense, also iOS and macOS have individual Bluetooth stacks. As they are closed-source and there is only little public documentation, we provide anoverview in the following. Figure 2 compares all stacks.
The most recent version of the macOS
Bluetoothstack was investigated and documented previously to integrate
InternalBlue [28]. The macOS kernel exposes a user-space
IOKit device-interface for Bluetooth [4].
IOKit communicates using aMach port with the
IOBluetoothFamily driver, which supportsconnectivity to USB, Universal Asynchronous Receiver-Transmitter
User-SpaceKernel-Space
Broadcom Bluetooth ChipXNU
IOBluetoothFamilyIOKitIOBluetoothbluetoothdCoreBluetooth (cid:44)(cid:44)
Broadcom Bluetooth ChipXNU bluetoothdCoreBluetooth
Marconi Bluetooth ChipPHY FirmwareController FirmwareRTKit OS
Figure 2:
Apple’s
Bluetooth stacks: macOS , iOS , and RTKit . agicPairing: Apple’s Take on Securing Bluetooth Peripherals WiSec ’20, July 8–10, 2020, Linz (Virtual Event), Austria (UART), and PCIe chips. User-space applications connect to Blue-tooth devices using the IOBluetooth private Application Program-ming Interface (API), which exposes methods to access the chipvia HCI and send Asynchronous Connection-Less (ACL) data. The macOS bluetoothd manages all Bluetooth logic and connects toother daemons such as bluetoothaudiod for music streaming. Thepublic API to access Bluetooth on macOS is CoreBluetooth , whichcommunicates with bluetoothd via Cross-Process Communication(XPC) and further abstracts the methods exposed by
IOBluetooth . Apple’s mobile operating system is iOS and has deriva-tives called iPadOS , tvOS , and watchOS . On iOS , the Bluetooth chipis exposed as serial character device to the user-space. On initial-ization, bluetoothd directly connects to the exposed Bluetoothsocket of this character device. Then, bluetoothd offers Bluetooth-related functionality as an XPC service. Similar to macOS , this XPCservice is accessed by the public CoreBluetooth
API. However, iOS
CoreBluetooth does not allow apps to create and use Classic Blue-tooth connections, which is slightly different from macOS . Instead,it offers a higher-level application protocol called
External Accessory that can be used in combination with Made for iPhone/iPad/iPod(MFi) certified Bluetooth devices [5].Even though HCI is not openly accessible, it is needed by systemcomponents. bluetoothd exposes a Mach port for features likeHCI, which is only accessible by system components. This privateframework is called
MobileBluetooth . For embedded devices,
Apple is using areal-time operating system based on the
RTKit framework.
RTKit is used on multiple embedded controllers and in all recent Blue-tooth peripherals, such as the
AirPods 1 , , and Pro , Siri Remote2 , Apple Pencil 2 , and
Smart Keyboard Folio . While
RTKit is notwell-known, it has an incredibly high market share. For example,
AirPods are accounted for 60 % of the global wireless earbud mar-ket [23]. Moreover,
RTKit powers a number of other devices andchips in the
Apple ecosystem, such as the Always-On Processor(AOP) firmware included in most of
Apple’s mobile devices like the iPhone and
AppleWatch .The
RTKit framework lacks public documentation by
Apple buthas been briefly mentioned by other researchers [17]. The newest
AirPod Pro firmware strings reveal version information, such as
RTKitAudioFrameworkW2 , RTKitOSPlatform-620.60.2616 , and
RTKit2.2.Internal.sdk . The latter lets us conclude that
Apple has an internal Software Development Kit (SDK) used to develop
RTKit applications.We consolidate all these peripherals into a single Bluetooth stack,however, the their firmware is very different due to their technolo-gies and use cases. The
Siri Remote , Apple Pencil , and
Smart Key-board only use BLE, while the
AirPods rely on both BLE and ClassicBluetooth. Nonetheless, the basic
RTKit code is the same.On the
AirPods , the communication to the Bluetooth chip isprovided via the Apple Controller Interface (ACI) instead of thespecification-compliant Host Controller Interface (HCI). This is be-cause the
AirPods use
Apple’s new Bluetooth chip
Marconi . An olderversion of the
PacketLogger contains a file
ACI_HCILib.xml , which A character device is exposed for all
Broadcom
UART chips, which are at least presentin the iPhone 6 , SE , , , X , XR , and various iPads . iOS also supports Marconi (newer
AppleWatches ) and
Broadcom
PCIe ( iPhone XS and ) Bluetooth chips. names and partially describes all ACI commands. Some of theseare AirPod -specific, such as synchronization of a pair of
AirPods and primary to secondary switching. The
Marconi
Bluetooth chipfirmware itself is also based on the
RTKit framework, as it is justanother peripheral.Note that it is very complex to debug root causes for crashes onthe
AirPods . As they are an embedded device, they reboot withinapproximately 2 s. Thus, a Bluetooth connection reset is indistin-guishable from a device reboot when performing wireless tests.
The general layout of a
MagicPairing message is shown in Figure 3a.It starts with a 2 B header, which is followed by data, depending onthe type of the message. In general there are two different types ofmessages with a slightly different structure. The first type, a
KeyMessage , contains key material (such as the
AES SIV , Ratchet , or
Hint data). The second type, a
Short Message , contains just one byteof data after the header. The data in the
Key Message is in a TypeLength Value (TLV) structure, as shown in Figure 3b. The numberof keys is encoded after the header. The
Short Message contains afixed amount of data after the header.The
MagicPairing Ping message can initiate the protocol. Whena device receives a
Ping message, it replies with a
Hint message.While the
Ping message does not necessarily need any additionaldata, it is still 3 B with the data set to . The
Status messageindicates success or, in case of an error, the reason for failing. The
Ratchet type message seems to be currently unused, as its receptionhandler implementation is empty on iOS and macOS bluetoothd . In addition to the pairing mechanism provided by
MagicPairing , italso offers the capability to decrypt BLE advertisements sent by the
AirPods . These advertisements have been shown to be linkable to
AirPods in general [20]. Advertisements notify other
Apple devicesof the presence of the
AirPods and encode battery state information.When an iOS device receives advertisements for a pair of
AirPods that belong to the same
Apple
ID as the iOS device, a pop-up showsan
AirPod image, the name of the
AirPods , and the current batterystate. The encrypted part constitutes the
MagicPairing data. A newkey is introduced, which is called
MagicPairing EncryptionKey . The
MagicPairing implementations on iOS and macOS contain vari-ous spelling mistakes in logging messages, and in case of the macOS bluetoothd also in function names. For example, the words
Ratchet and
Upload were spelled differently various times. As these mis-takes vary with the stack, each stack was probably implementedby a different developer. While spelling mistakes are not directlyrelated to flaws in an implementation, they leave the impressionthe code was not extensively reviewed, and development probablyoutsourced. iSec ’20, July 8–10, 2020, Linz (Virtual Event), Austria Heinze et al.
WiSec ’20, July 08–10, 2020, Linz, Austria Anon. Submission Id: 28
Message Type
MagicPairing
Version (cid:9)
MagicPairing
Header
MagicPairing
Data
Status Description Success Internal Error Key Not Found Invalid Parameters Pairing Busy Unsupported Version Operation Timed Out Failed Verification No Keys for Peer
ID Description Type
Hint Key Message
Ratcheting Key Message
AES SIV Key Message
Ratchet Key Message
Ping Short Message
Status Short Message (a)
MagicPairing message format.
Num Entries Key TypeKey LengthKey (variable length)
Key Type Description
Hint
Nonce
Unknown
AES SIV
Ratchet (b)
MagicPairing key message data.
Figure 3:
MagicPairing packet formats. (a) macOS 15.3 bluetoothd upload spelling.(b) macOS 15.3 bluetoothd ratchet spelling.(c) iOS 13.3 bluetoothd ratchet spelling.
Figure 4: Spelling mistakes in iOS and macOS bluetoothd . The
MagicPairing implementations on iOS and macOS contain vari-ous spelling mistakes in logging messages, and in case of the macOSbluetoothd also in function names. An excerpt of these spelling mis-takes is shown in Figure 4. For example, the words
Ratchet and
Upload were spelled differently various times. Also, as these mis-takes vary with the stack, each stack was probably implementedby a different developer. While spelling mistakes are not directlyrelated to flaws in an implementation, they do leave the impressionthe code was not extensively reviewed.
The wireless attack surface of
MagicPairing is rather large. First ofall, it is used prior to pairing and encryption.
MagicPairing providesa connection via the Logical Link Control and Adaptation Protocol(L2CAP), which is used for all kinds of data transfer within Blue-tooth [6, p. 252]. Second, the
MagicPairing attack surface is furtherenlarged by the different implementations for iOS , macOS , RTKit ,which all might have individual flaws. Instead of using a commonlibrary, the macOS implementation is written in
Objective C , the iOS implementation is based on
C/C++ , and the
RTKit firmwareon the
AirPods is a slightly feature-restricted variant written in C .Last, MagicPairing is always available on all
Apple devices withBluetooth enabled, no matter if the user owns
AirPods .After the reverse engineering in Section 2 and further lookinginto implementation details in Section 4, we have a basic under-standing of the protocol flow and message types. Based on thisknowledge, we perform further tests. We implement both, a genericover-the-air fuzzer (Section 5.1) and an iOS in-process fuzzer (Sec-tion 5.2). While the over-the-air fuzzer is rather generic and requiredto confirm vulnerabilities, it is limited in speed and does not providecoverage. In contrast, the iOS in-process fuzzer is faster and notlimited by connection resets, but requires a lot of platform-specifictuning. (a)
MagicPairing message format.
WiSec ’20, July 08–10, 2020, Linz, Austria Anon. Submission Id: 28
Message Type
MagicPairing
Version (cid:9)
MagicPairing
Header
MagicPairing
Data
Status Description Success Internal Error Key Not Found Invalid Parameters Pairing Busy Unsupported Version Operation Timed Out Failed Verification No Keys for Peer
ID Description Type
Hint Key Message
Ratcheting Key Message
AES SIV Key Message
Ratchet Key Message
Ping Short Message
Status Short Message (a)
MagicPairing message format.
Num Entries Key TypeKey LengthKey (variable length)
Key Type Description
Hint
Nonce
Unknown
AES SIV
Ratchet (b)
MagicPairing key message data.
Figure 3:
MagicPairing packet formats. (a) macOS 15.3 bluetoothd upload spelling.(b) macOS 15.3 bluetoothd ratchet spelling.(c) iOS 13.3 bluetoothd ratchet spelling.
Figure 4: Spelling mistakes in iOS and macOS bluetoothd . The
MagicPairing implementations on iOS and macOS contain vari-ous spelling mistakes in logging messages, and in case of the macOSbluetoothd also in function names. An excerpt of these spelling mis-takes is shown in Figure 4. For example, the words
Ratchet and
Upload were spelled differently various times. Also, as these mis-takes vary with the stack, each stack was probably implementedby a different developer. While spelling mistakes are not directlyrelated to flaws in an implementation, they do leave the impressionthe code was not extensively reviewed.
The wireless attack surface of
MagicPairing is rather large. First ofall, it is used prior to pairing and encryption.
MagicPairing providesa connection via the Logical Link Control and Adaptation Protocol(L2CAP), which is used for all kinds of data transfer within Blue-tooth [6, p. 252]. Second, the
MagicPairing attack surface is furtherenlarged by the different implementations for iOS , macOS , RTKit ,which all might have individual flaws. Instead of using a commonlibrary, the macOS implementation is written in
Objective C , the iOS implementation is based on
C/C++ , and the
RTKit firmwareon the
AirPods is a slightly feature-restricted variant written in C .Last, MagicPairing is always available on all
Apple devices withBluetooth enabled, no matter if the user owns
AirPods .After the reverse engineering in Section 2 and further lookinginto implementation details in Section 4, we have a basic under-standing of the protocol flow and message types. Based on thisknowledge, we perform further tests. We implement both, a genericover-the-air fuzzer (Section 5.1) and an iOS in-process fuzzer (Sec-tion 5.2). While the over-the-air fuzzer is rather generic and requiredto confirm vulnerabilities, it is limited in speed and does not providecoverage. In contrast, the iOS in-process fuzzer is faster and notlimited by connection resets, but requires a lot of platform-specifictuning. (b)
MagicPairing key message data.
Figure 3:
MagicPairing packet formats.
The wireless attack surface of
MagicPairing is rather large. First ofall, it is available prior pairing—it provides a connection via the Log-ical Link Control and Adaptation Protocol (L2CAP), which is usedfor all kinds of data transfer within Bluetooth [7, p. 252]. Second,the
MagicPairing attack surface is further enlarged by the differentimplementations for iOS , macOS , RTKit . Instead of using a commonlibrary, the macOS implementation is written in
Objective C , the iOS implementation is based on
C/C++ , and the
RTKit firmware onthe
AirPods is a slightly feature-restricted variant written in C [13].Last, MagicPairing is always available on all
Apple devices withBluetooth enabled, no matter if the user owns
AirPods .Based on our knowledge about
MagicPairing and its implemen-tations, we perform further tests. We implement both, a genericover-the-air fuzzer (Section 5.1) and an iOS in-process fuzzer (Sec-tion 5.2). While the over-the-air fuzzer is platform-independent andrequired to confirm vulnerabilities, it is limited in speed and doesnot provide coverage. In contrast, the iOS in-process fuzzer is fasterand not limited by connection resets, but needs a lot of platform-specific tuning. Our overall setup is explained in Section 5.3. Aswe apply a rather specific tooling to enable iOS in-process fuzzingwith FRIDA, we further describe it in Section 5.4
An over-the-air fuzzer runs independently of the target system. Still,the protocol needs to be re-implemented to fuzz inputs. Our fuzzerextends
InternalBlue , which already provides a generic interface toadd custom protocols on top of existing Bluetooth stacks, including iOS and macOS [19]. This approach has two main advantages thatcannot be reached with in-process fuzzing. (+) Platform Independence
The fuzzer is independent of thetarget device’s operating system or Bluetooth stack. (+) Few False Positives
The fuzzer behaves just as any otherBluetooth peripheral. Anything found can be used compara-bly easy for a PoC.However, wireless Bluetooth fuzzing has various limitations thatmotivate us to also perform in-process fuzzing. (-) Connection Termination
The connection is terminatedonce a few invalid packets are received. Thus, a lot of time isspent on reconnecting to the target. Moreover, it is difficultto nearly impossible to distinguish between a terminatedconnection and a crashed Bluetooth daemon. (-) Speed
The fuzzer’s speed is limited by the physical connec-tion to the target. (-) Coverage
Without collecting information from the target,the input cannot be adapted to trigger missing code paths.As the
MagicPairing protocol has a low complexity, we imple-ment a generation-based fuzzer, which generates all possible mes-sage types. It randomly generates valid and invalid messages basedon the reverse-engineered protocol definition. Apart from connect-ing to the target device, no further setup is required for fixed L2CAPchannels. The fuzzer keeps sending the generated L2CAP payloadsuntil it receives an
HCI_Disconnection_Complete event (see [7,p. 2296]). This indicates that the target device either disconnecteddue to multiple invalid received messages or due to a crash. Thefuzzer then tries to reconnect to the device.The target device is additionally monitored using the
PacketLog-ger , which is available for macOS and also on mobile devices since iOS 13 with a
Bluetooth Profile [3]. This enables us to determineif the device crashed and when the connection was terminated. Acrash can be detected by searching for the message “Connection tothe iOS device has been lost.”
In practice, the
HCI_Disconnection_Complete event is quiteunreliable. In multiple occasions the connection was terminated,but the fuzzer did not receive the event. This lowers the efficiency of agicPairing: Apple’s Take on Securing Bluetooth Peripherals WiSec ’20, July 8–10, 2020, Linz (Virtual Event), Austria the fuzzer as it needs to estimate when a connection is terminatedin case it did not receive the disconnection event. Moreover, toreliably send packets and confirm events, we restricted the fuzzerspeed to 1–2 packets / s. Despite the mentioned issues, the fuzzerended up finding multiple bugs in the protocol implementations. An in-process, coverage-guided fuzzer improves the efficiency whenfuzzing the reception handlers of interesting L2CAP-based proto-cols. While the throughput of messages and the stability of thepayload delivery is much higher than in the over-the-air implemen-tation, the in-process fuzzer comes with a different set of drawbacks. (-) Many False Positives
The usual operation of the Bluetoothdaemon is altered, which can lead to unexpected behavioror crashes that are related to the fuzzing operation itself. (-) Platform Dependence
Injecting and preparing the fuzzerinside the target process differs significantly for differentoperating systems. Even within the same Bluetooth stack,function addresses and implementation details change withupdated versions and need to be adapted.We reduce the false positives by minimizing the amount ofcrashes related to the injected fuzzing code. This is done by ob-serving any side-effects during fuzzing and patching the affectedfunctions.
RTKit currently cannot be altered, thus, only the macOS andjailbroken iOS
Bluetooth stack remain for in-process fuzzing. As iOS jailbreaks were comparably rare in the past but became availablewith checkm8 and checkra1n recently [16], we implement an in-process fuzzer for iOS .In practice, the iOS in-process fuzzer’s speed varies between5–30 packets / s. Though, as connections are not dropped with in-process fuzzing, the overall speedup is much higher. Figure 4 shows the fuzzing setup, with a main focus on the special-ized in-process fuzzer. The in-process fuzzer is divided into twocomponents: (1)
The manager running on a computer, and (2) thefuzzing harness running on the target device.The manger starts and maintains the fuzzing process. It injectsfuzzing harness into the target process and handles the communi-cation with it. Additionally, it maintains a set of crashes occurredduring fuzzing, a corpus to derive inputs, and coverage informationcollected during fuzzing. The manager generates new inputs by sending entries to the corpus of the input mutation component,which randomly mutates the input based on a seed.The fuzzing harness is divided into two sub-components. Thefirst component is a general fuzzing harness, which is responsiblefor the overall fuzzing of bluetoothd . It creates virtual connectionsand applies patches ensuring a stable fuzzing process. Moreover, itcollects code coverage and receives fuzzing input from the manager.The second component, the specialized fuzzing harness, is specificfor the target function and protocol to be fuzzed, such as
MagicPair-ing . It is responsible for preparing the received input and callingthe function handler, as well as any other preparation needed tofuzz the protocol-specific reception handler function.The fuzzer is initialized with an initial corpus of valid proto-col messages, i.e., function arguments. It then collects the initialcoverage by sending the initial corpus to the fuzzing harness. Thespecialized harness executes the payloads. The collected coverageis returned to the manager.Once the initial coverage is collected, the actual fuzzing begins.The manager picks one of the entries in the corpus and a seedvalue. These are passed to the input mutator, which mutates theinput and sends it back to the manager. The manager sends themutated input to the specialized fuzzing harness. If desired, thespecialized fuzzing harness further mutates the input—which isrequired for fields that require deterministic values or length fields.In this case, the specialized fuzzing harness first reports the modifiedinput back to the manager before calling the function under test.This ensures that the additional mutation is saved, even whenthe injected harness crashes together with the target. While thefunction is called, the harness collects basic block coverage. Thereare three possible results of the function call:
Ordinary Return
The function was executed successfully andreturns. The collected coverage is reported to the manager.
Exception
The function results in an exception, which is re-turned to the manager. The manager stores the input andthe exception as a crash.
Uncontrolled Crash
The target, i.e., bluetoothd , crashes ina thread not controlled by the fuzzing harness. It crashes andgenerates a crash report. In this case, the exception cannot besent to the manger. However, the manager detects this crashand stores the generated input as a crash. The correspondingcrash report is manually gathered from the operating system.These results may contain false positives, even in the case of anexception. Therefore, we verify identified crashes with the over-the-air fuzzer.
TOOTHP CKER iPhone LaptopCoverage, ExceptionsTCP/usbmuxInputGeneral Fuzzing HarnessSpecialized Fuzzing Harness ManagerInput Mutation CoverageCorpusCrashes OTA Fuzzer
Figure 4:
ToothPicker fuzzing setup. iSec ’20, July 8–10, 2020, Linz (Virtual Event), Austria Heinze et al.
Our in-process fuzzer is based on frizzer [18], which providesa basic fuzzing architecture including coverage collection, corpushandling, and input mutation. These are already a large part of themanager component. Our fuzzer, like frizzer , is built on FRIDA,which is a dynamic instrumentation toolkit [22]. FRIDA can injectcode into a target process using
JavaScript . Thus, our fuzzing har-ness is implemented in
JavaScript and injected into bluetoothd .The manager is implemented in
Python , as FRIDA also provides
Python bindings. We use the test case generator radamsa as inputgenerator component [14].On iOS , bluetoothd is missing symbols. Nonetheless, we canidentify various functions by static reverse engineering. Theseinclude creating a BLE handle, or creating an ACL handle, which isneeded to receive L2CAP data. Due to the lack of symbols, we needto resolve function pointers via their static offsets to make themcallable with FRIDA. In the following example, these offsets arevalid for an iPhone 7 on iOS 13.3 . In Listing 2, we call the functionthat creates an ACL handle. The input arguments are a Bluetoothaddress, and another state value set to as found by dynamicanalysis. Similar to calling the ACL connection creation function,we also call the specialized MagicPairing handler.Even fake connections created as in Listing 2 can be discon-nected. We keep the connection alive by overwriting the func-tion
OI_HCI_ReleaseConnection , named according to the debugstrings. Hooking and replacing such functions prevents connectionstructures from being destroyed.Note that this in-process fuzzing disconnection prevention doesnot work for over-the-air fuzzing. When a connection is initiatedby the Bluetooth chip itself, it holds an HCI handle, which thestack uses to reference the connection. Moreover, the chip holdsadditional state to keep the connection alive. While we can control bluetoothd with FRIDA hooks, we cannot overwrite chip-internalbehavior. // Create a buffer for the Bluetooth addressvar bd_addr = Memory.alloc (6);// Resolve function addressvar base = Module. getBaseAddress("bluetoothd");var fn_addr = base.add(0 xc81a0); // iOS 13.3, iPhone 7// Create JavaScript -callable function referencevar allocateACLConnection = new NativeFunction(fn_addr ,"pointer", ["pointer","char"]);// Write a (random) Bluetooth address to memorybd_addr.writeByteArray ([0xca ,0xfe ,0xba ,0xbe ,0x13 ,0x37]);// Call the function and create a forged ACL connectionvar handle = allocateACLConnection (bd_addr , 0);
Listing 2: Creating a forged ACL handle using FRIDA.
Exception Type: EXC_BAD_ACCESS (SIGSEGV)Exception Subtype: KERN_INVALID_ADDRESS at0x00000000000000a8VM Region Info: 0xa8 is not in any region. Bytes beforefollowing region: 4298293080[...]Termination Signal: Segmentation fault: 11Termination Reason: Namespace SIGNAL , Code 0xbTerminating Process: exc handler [958]
Listing 3: Excerpt of an
MP1 -related crash log.
In the following, the identified vulnerabilities in the
MagicPairing protocol are described. All vulnerabilities are summarized in Table 1.
Testing the
MagicPairing protocol resulted in multiple
NULL pointerdereferences or dereferencing addresses in the
NULL page. The
NULL page is not mapped on 64 bit iOS and macOS . This results in a bluetoothd crash. launchd immediately restarts bluetoothd af-ter crashing. Thus, these bugs are merely a bluetoothd
DoS. Anattacker does not have any control over the dereferenced value, andwe assume that these dereferences are not exploitable.
When sending a
MagicPairing Ping message to an iOS device froma Bluetooth device that is not a known pair of
AirPods , it respondsthat it does not have a hint for this sending device. If a
Ratcheting message is then sent to the device, bluetoothd will crash whiletrying to dereference a pointer in the
NULL page. Listing 3 shows anexcerpt of the crash log that is generated by the operating system.The invalid access to address is caused by a missing checkfor the return value of a lookup function shown in Listing 4. Thefunction looks up an entry in bluetoothd ’s table of known
Magic-Pairing devices by the sender’s Bluetooth address and returns
NULL .The issue is that this return value is never checked and assumed tobe a pointer to a valid
MagicPairing -related structure. Then, to re-spond to the
Ratcheting message, the structure is accessed at offset , which leads to the crash.
MP2–5 have a similar cause as the previous dereference in
MP1 .The return value of the lookup function is not properly verified. On iOS and macOS , this affects the
Ratcheting (MP1, MP3, MP5) and the
Hint (MP2, MP4) messages. As before, they lead to a dereference ofan invalid address, which is a fixed offset into a
MagicPairing struc-ture at address . Thus, all vulnerabilities are equally unlikelyexploitable other than crashing bluetoothd . The reason why the
Ratcheting messages lead to different crashes on iOS is that the or-der of keys in the message determines which fields in the mp_entry are accessed. void recv_mp_ratchet_aes_siv (char *bd_addr , char *data) {[...]// Returns NULL for unknown Bluetooth addressesmp_entry = lookup_mp_entry_by_bd_addr (bd_addr);[...]// The NULL entry is dereferenced with an offsetmemmove(mp_entry ->remoteAESSIV , data + aessiv_offset ,0x36);}
Listing 4: Pointer dereference
MP1 . agicPairing: Apple’s Take on Securing Bluetooth Peripherals WiSec ’20, July 8–10, 2020, Linz (Virtual Event), Austria Table 1: List of identified
MagicPairing and L2CAP vulnerabilities, status April 28 2020.ID Attack Effect Detection Method OS Disclosure Status
MP1 Ratcheting Crash Over-the-Air, In-Process iOS Oct 30 2019 Not fixedMP2 Hint Crash Over-the-Air, In-Process iOS Dec 4 2019 Not fixedMP3 Ratcheting Crash Over-the-Air macOS Oct 30 2019 Not fixedMP4 Hint Crash Over-the-Air macOS Oct 30 2019 Not fixedMP5 Ratcheting Crash In-Process iOS Mar 13 2020 Not fixedMP6 Ratcheting Abort Crash In-Process iOS Mar 13 2020 Not fixedMP7 Ratcheting Loop 100 % CPU Load Over-the-Air macOS Oct 30 2019 Not fixedMP8 Pairing Lockout Disassociation Manual iOS & macOS Feb 16 2020 Not fixedL2CAP1 L2CAP Zero-Length Crash Over-the-Air RTKit Dec 4 2019 Not fixedL2CAP2 L2CAP Groups Crash In-Process iOS 5–13 Mar 13 2020 Not fixed
This crash is caused by an assertion failure that leads to an abort .The code that parses the
Ratcheting message attempts reading fromthe message buffer. An assertion ensures that it does not read be-yond this buffer. However, if the assertion fails, the parser doesnot return gracefully and instead calls abort , which leads to thetermination of bluetoothd . The macOS bluetoothd can be forced to enter a ratcheting loopwith a very large iteration count. Unlike the previous vulnerabil-ities, this issue is not solely caused by implementation mistakes,but originates from an inherent problem in the protocol’s design.The receiver trusts the values sent in the
Hint message, withoutverifying that it was actually sent by a known
MagicPairing peer.An attacker can forge the
Ratchet value in the
Hint message. The
Hint message also includes a nonce, but this is random. The
Hint value itself, which is encrypted and could be used to verify thesender’s Bluetooth address, is ignored. Instead, macOS trusts theconnection’s Bluetooth address.Setting the
Ratchet to a very high value will cause bluetoothd to enter a long ratcheting loop. The
Ratchet field holds a 4 B value,thus the maximum value of a
Ratchet can be . Duringnormal usage however, the
Ratchet is only incremented for everypairing process. Therefore, it is rather small in practice. The attackwas tested on a
MacBook Pro Early 2015, 13-inch, 2.9 GHz DualCore i5 on macOS Catalina 10.15 with an initial Ratchet value of .Sending a Hint message with a
Ratchet value of caused bluetoothd to enter a ratcheting loop, with the local
Ratchet valueincreasing at a rate of approximately 7000 / s—causing a ratchetingloop running multiple days.During the ratcheting loop attack, the bluetoothd receptionthread is blocked. This disables further Bluetooth-based communi-cation, for example, the device under attack can no longer receivefiles via AirDrop . It is possible to corrupt the established pairing between an iOS or macOS device and a pair of AirPods . For this, an attacker needs toknow the victim’s Bluetooth address, as well as the target
AirPods ’Bluetooth address. The attacker can manipulate the local ratchet value of a host device by sending one or more
Ratcheting messageswith a ratchet value higher than the device’s current one. Thecurrent ratchet value can be obtained by sending a
Ping messageto the host. It responds with a
Hint message, which contains itscurrent local ratchet value. This value can then be incrementedand sent in a
Ratcheting message. The keys for encrypting the
AES-SIV value are not required, as the ratchet value is sent in plaintext.Therefore, an attacker can set a bogus value for the
AES-SIV partof the message and set the incremented ratchet value. Then, thereceiving host starts a ratcheting loop. As bluetoothd on iOS has atimeout functionality, the forged ratchet value should not be chosentoo high. Once the ratcheting loop is finished, the host’s local ratchetvalue is successfully increased, even if the decryption of the AES-SIV entry of the message fails. This corrupts an active pairing becausethe
AirPods have a threshold value for the discrepancy betweentheir local ratchet value and the value received by the paired host.This causes the
AirPods to decline the continuation of the
Magic-Pairing protocol and thus the whole pairing process. The user doesnot have any options to reset the
MagicPairing data and does notget any feedback about the error. The only solution is to reset the
AirPods and freshly pair them with the user’s iCloud account.As shown in Figure 5, the attack can be conducted as follows: iPhone/MacBook
InternalBlue iPhoneFake AirPods1 ○ Set
BdAddr ○ Ping3 ○ Hint ratchet_host ○ Ratcheting ratchet_airpod=ratchet_host + 10 ○ RatchetLockout
Figure 5: Lockout attack. iSec ’20, July 8–10, 2020, Linz (Virtual Event), Austria Heinze et al. (1) The attacker changes the Bluetooth address to that of thetarget’s
AirPods .(2) The attacker connects to the victim and sends a
Ping mes-sage to initiate a MagicPairing process.(3) The victim responds with a
Hint message which contains itscurrent local ratchet value.(4) The attacker increases this value by 10 and sends a
Ratcheting message with the incremented ratchet value and a random
AES-SIV value.(5) The victim will start the ratcheting loop with the receivedratchet value and derive the
SIV Key for decrypting the
AES-SIV value. As the
AES-SIV value is random, the victim willnot be able to decrypt it and sends a
Status message indicat-ing an internal error. However, its local ratchet value staysincremented and is not reset to its previous value.The issue originates from using an untrusted ratchet to incre-ment an internal value and execute a key rotation. As the ratchetvalue is neither encrypted nor authenticated, an attacker can easilyforge the ratchet.A solution to this problem is to only store the incrementedratchet value and the rotated key when the
AES-SIV part of themessage was successfully decrypted. Otherwise, the whole
Mag-icPairing message should be considered untrusted and the ratchetvalue should stay as it was before.
While fuzzing
MagicPairing over-the-air, we identified a crash inthe
RTKit
Bluetooth stack, more specifically, the
AirPods 1 and . When sending an L2CAP message with the length field set tozero and no payload, the AirPods crash. As there are no publiclydocumented debugging capabilities for the
AirPods , it is not possibleto tell whether the Bluetooth thread or the whole operating systemcrashes. We observe that the music stops playing, the connected iPhone reports the
AirPods as disconnected, and after a few seconds,the
AirPods play a sound indicating a successful connection.
This crash is another
NULL pointer dereference, albeit more severethan the previous ones. It is accessible via both BLE and ClassicBluetooth and is part of
L2CAP Group feature. This is indicated bylogging messages in the crashing function that mention the file corestack/l2cap/group.c . However, the
L2CAP Group featureis no longer supported since Bluetooth 1.1. We assume the groupreception function has been accidentally left in the code. In thenewest Bluetooth specification, the channel ID is reservedfor connectionless traffic instead of group traffic [7, p. 1035].Depending on the data that is received, the
L2CAP Group handlertries to find a matching entry in a function table allocated on theheap. However, this table has only been allocated, not initialized.Thus, all its entries are zero. When the payload starts with a
NULL byte, the first entry is identified as matching entry. The code thentries to jump to the function pointer stored in that table entry,which also is a
NULL pointer. However, any control over this tablewould immediately result in control over the instruction pointer. The attacker could also send regular
MagicPairing AirPod advertisements (Section 4.3),but they are encrypted and regularly change.
In addition to an iPhone 7 on iOS 13.3 , we were able to reproducethe crash on an iPad 2 with iOS 9.3.5 (released on August 25 2016),and an iPhone 4 with iOS 5.0.1 (released on November 10 2011).While the crash is not critical per se, it shows how long the iOS Bluetooth stack has not been tested. As iOS 5 and still had anotherBluetooth stack architecture, the crash is within BTServer insteadof bluetoothd . In this paper, we showed how
Apple deals with seamless pairing ofBluetooth peripherals in their large connected ecosystem. While
MagicPairing is proprietary, its general ideas and techniques canbe integrated into other IoT ecosystems. Furthermore, other Blue-tooth peripheral vendors could benefit from the
MagicPairing pro-tocol and infrastructure. All
Apple needs to do is to provide an APIthat lets developers generate and receive an
Accessory Key that isstored in the user’s iCloud account. Vendors could then implement
MagicPairing in their products and benefit from the same securityproperties and seamless pairing experience as the
AirPods . Apple’s three different Bluetooth stacks for iOS , macOS , and RTKit also reflect the variety of Bluetooth implementations out-side of their ecosystem. Many vendors choose to implement theirown stacks and protocols. This makes efficient testing of Bluetoothdevices challenging, but our over-the-air fuzzing setup based on
InternalBlue can also be useful to test further Bluetooth stacks. As
MagicPairing is a rather simple protocol, over-the-air fuzzing wassufficient to identify multiple vulnerabilities, despite the lack ofspeed and coverage information. However, our iOS -based in-processfuzzer had a better performance in practice.Overall,
Apple keeps their Bluetooth ecosystem rather closed tothird-party vendors. Already using Classic Bluetooth requires themto apply for MFi. However, this enables an overall smooth userexperience. Bluetooth runs silently in the background most of thetime and manages tasks like
AirDrop and
Handoff [12, 27]. Since iOS 13 , the Bluetooth icon has been removed from the status bar,even during audio streaming. Any incentive for disabling Bluetoothin the
Apple ecosystem is missing.While all of this is great for user experience, we were surprisedby the vulnerabilities uncovered within
MagicPairing . We assumethat this protocol never had an extensive code review and was neverfuzzed before integrating it as always-active Bluetooth backgroundservice. We are looking forward to
Apple integrating patches for thevulnerabilities we identified, but also hope that they will elaboratetheir other wireless protocols better in the future.
ACKNOWLEDGMENTS
We thank Bianca Mix, Oliver Pöllny, and Alexander Heinrich forproofreading this paper. Moreover, we thank Matthias Hollick forhis feedback and Anna Stichling for the
ToothPicker logo.This work has been funded by the German Federal Ministry ofEducation and Research and the Hessen State Ministry for HigherEducation, Research and the Arts within their joint support of theNational Research Center for Applied Cybersecurity ATHENE, aswell as by the Deutsche Forschungsgemeinschaft (DFG) – SFB 1119– 236615297. agicPairing: Apple’s Take on Securing Bluetooth Peripherals WiSec ’20, July 8–10, 2020, Linz (Virtual Event), Austria
REFERENCES [1] Daniele Antonioli, Nils Ole Tippenhauer, and Kasper Rasmussen. 2020. BIAS:Bluetooth Impersonation AttackS. In
Proceedings of the IEEE Symposium on Secu-rity and Privacy (S&P)
Proceedings of the 2004 ACM Workshop onPrivacy in the Electronic Society, WPES 2004, Washington, DC, USA, October 28,2004 , Vijay Atluri, Paul F. Syverson, and Sabrina De Capitani di Vimercati (Eds.).ACM, 77–84. https://doi.org/10.1145/1029179.1029200[9] Jiska Classen. 2019. All Wireless Communication Stacks are Equally Broken.[10] Jiska Classen, Daniel Wegemer, Paul Patras, Tom Spink, and Matthias Hollick.2018. Anatomy of a Vulnerable Fitness Tracking System: Dissecting the Fit-bit Cloud, App, and Firmware. In
PACM on Interactive, Mobile, Wearable andUbiquitous Technologies (IMWUT) .[11] Dan Harkins. 2008.
Synthetic Initialization Vector (SIV) Authenticated EncryptionUsing the Advanced Encryption Standard (AES) . RFC 5297. RFC Editor. https://tools.ietf.org/html/rfc5297[12] Alexander Heinrich. 2019. Analyzing AppleâĂŹs Private Wireless Communica-tion Protocols with a Focus on Security and Privacy.[13] Dennis Heinze. 2020. ToothPicker: Enabling Over-the-Air and In-Process FuzzingWithin AppleâĂŹs Bluetooth Ecosystem.[14] Aki Helin. 2020. radamsa - a general-purpose fuzzer. https://gitlab.com/akihe/radamsa.[15] Konstantin Hypponen and Keijo MJ Haataja. 2007. “Nino” Man-in-the-Middle At-tack on Bluetooth Secure Simple Sairing. In . IEEE. [16] Kim Jong Cracks. 2020. checkra1n—iPhone 5s – iPhone X, iOS 12.3 and up.https://checkra.in/.[17] Jonathan Levin. 2019.
New OSX Book, Volume II, *iOS Internals::Kernel Mode .20–22 pages. http://newosxbook.com[18] Dennis Mantz. 2019. Frida-based general purpose fuzzer. https://github.com/demantz/frizzer.[19] Dennis Mantz, Jiska Classen, Matthias Schulz, and Matthias Hollick. 2019. Inter-nalBlue - Bluetooth Binary Patching and Experimentation Framework. In
The17th Annual International Conference on Mobile Systems, Applications, and Services(MobiSys ’19) . https://doi.org/10.1145/3307334.3326089[20] Jeremy Martin, Douglas Alpuche, Kristina Bodeman, Lamont Brown, Ellis Fenske,Lucas Foppe, Travis Mayberry, Erik Rye, Brandon Sipes, and Sam Teplov. 2019.Handoff All Your Privacy–A Review of Apple’s Bluetooth Low Energy ContinuityProtocol.
Proceedings on Privacy Enhancing Technologies
Advances in Cryptology - EUROCRYPT 2006, 25thAnnual International Conference on the Theory and Applications of CryptographicTechniques, St. Petersburg, Russia, May 28 - June 1, 2006, Proceedings (LectureNotes in Computer Science) , Serge Vaudenay (Ed.), Vol. 4004. Springer, 373–390.https://doi.org/10.1007/11761679_23[25] Mike Ryan. 2013. Bluetooth: With Low Energy Comes Low Security. In
Presentedas part of the 7th USENIX Workshop on Offensive Technologies
Proceedingsof the 3rd International Conference on Mobile Systems, Applications, and Services . USENIX Association, Santa Clara, CA, 37–54.[28] Davide Toldo. 2019. Analyzing the macOS Bluetooth Stack.[29] Maximilian von Tschirschnitz, Ludwig Peuckert, Fabian Franzen, and JensGrossklags. 2020. Method Confusion Attack on Bluetooth Pairing. In