 In this talk, Alexander and me will show you internals about Apple's new UltraWideBand technology. Apple built a new chip officially called U1 and internally called ROSE. The chip has been introduced with the iPhone 11 for spatial awareness. And since iOS 14, some functionality of the U1 chip is exposed through the nearby interaction framework. Even though it's been there for a while, nobody really knows what UltraWideBand is or does. UltraWideBand is only available on the latest generation of devices. So on Apple devices, jakemade-supported iPhones do not have the U1 chip. However, the AirTex have a U1 chip and at $30 they are cheaper than some UltraWideBand development boards. Another barrier for hackers is that typical, softly-defined radio setups do not allow to intercept UltraWideBand signals. The bandwidth is way too wide and the frequency is too high for a typical SDR setup. So overall, I guess, UltraWideBand seems to be a hacker proof. Apple's platform security guide is usually very, very detailed, but when it comes to UltraWideBand security, there is almost no documentation. It only states that address and frame sequences are randomized, which is fundamental to privacy and wireless systems. However, this does not tell anything about security features of UltraWideBand on a chip or operating system level. UltraWideBand is so secure they even put it into vehicles, and one application is to use it as a second factor for keys. Signals are limited by speed of light, meaning that they travel a constant time and being sent over the air or through a cable. This means that an attacker cannot simply replay or relay a signal from a key to shorten the distance. Such an attack would introduce a measurable delay. Using this property as a second factor is also called distance bonding. In practice, the direct line-of-sight path might not be as strong because objects are in between. So in such a case, a non-line-of-sight path from a reflection, like a wall or the ground, can be stronger. However, you still want to use your key and open your vehicle. So, Apple does not provide any non-line-of-sight accuracy for their UltraWideBand chip. An XP advertises their chip with plus-minus 10 cm non-line-of-sight accuracy. And when correlating paths, the signal strength of the shortest path might be lower than the indirect reflected non-line-of-sight path. The shortest path is earlier but weaker. And to compensate for this, there needs to be a back-search window in that the UltraWideBand chip looks for peaks. Any peak about the noise floor will be accepted as first path. An attack can trick this algorithm by injecting short peaks that slightly distort a signal in a way that makes four shorter paths appear within the back-search time window. And as of now, this attack has only been simulated because there is no affordable setup that would allow such an attack in practice. But considering that UltraWideBand secure-ranging is now being built into the newest generation of devices, this is still concerning. And with this, I'm handing over to Alexander, who is now going to show you a bit more about how UltraWideBand is being used on iOS from a user perspective, but also from a framework perspective. Thank you, Yuska, for the introduction. I will now continue to present the UltraWideBand features that are currently present in iOS and continue to dive a bit deeper into the internals of the implementation on iOS. The first feature that was made available using UltraWideBand is an extension to AirDrop. This extension mainly changed the user interface in a way that the device at which the user is pointing is shown in a circle in the middle. This helps users to identify the person they want to send a file to and could be another hint against malicious actors trying to steal files. With iOS 14, Apple has opened up their UltraWideBand interface to app developers. Developers are now able to use the nearby interaction framework to measure the distance and angle between two iPhones and to play games with this. Usage is quite limited, because we cannot access more details than this, and actually it requires a quite complicated setup in which you will detail later. Also, with the introduction of the AirTag, definedMyApp gained support for UltraWideBand. This is used to discover lost devices, and it shows you the distance and the direction in which your device is placed. So this is an option to find devices in your place, but it's not feasible for longer distances, as this has a maximum distance of around 10 meters. With iOS 15, Apple is opening up UltraWideBand even more. Now UltraWideBand can be added to anything if the manufacturer is certified by Apple. And now you can integrate UltraWideBand hardware into your house, for example to unlock it or to have certain smart home features. You can unlock your car with UltraWideBand using the digital car key. And also, UltraWideBand can now be used for the key to your TARDIS. And now, I will dive deeper into the AirTrap and nearby interaction parts of UltraWideBand. In this part, I will explain the two protocols in use. And then, now we start with AirTrap. So the first UltraWideBand use case that we want to look at is AirTrap. When users open AirTrap, a lot of things start happening in the background. The devices will start sending out UltraWideBand beacons, and it will also start sharing Bluetooth flow energy advertisements to inform users about the just started AirTrap. The first Bluetooth flow energy advertisement is the main AirTrap advertisement. This part is largely known by previous research, and when an iPhone tries to send something over AirTrap, it will send these ability advertisements. Those advertisements use a non-resolvable MAC address, so it cannot be identified even by devices that have been paired to this iPhone. The first part here identifies this as an AirTrap message. Then it just states the length of the whole advertisement, and then we have zero padding here. Then we get a version number, and this is followed up by four truncated hashes from email addresses like the Apple ID and from phone numbers that are also linked to this Apple account. Now all devices in the surrounding know if their potential contacts is trying to send something over AirTrap as they can compare the hashes here. They will start with the normal AirTrap protocol in the background, and now this UltraWideBand part of AirTrap is clearly separated from the normal AirTrap protocol. So for the UltraWideBand part, it's also sending a different kind of second BLE advertisement. This one uses actually a resolvable MAC address, and it's often a nearby action type. This nearby action type is used for multiple features, for example, the Wi-Fi password sharing and AirPlay. Then we have nearby action flags, and then we have a special type. In this case, it's the action type called point-to-share. This is directly linked to UltraWideBand, and it sends every time a device has started AirTrap. This informs nearby devices that this AirTrap device has started UltraWideBand beginning, and it's awaiting responses by potential other AirTrap users. Also, all nearby action messages contain an authentication tag in the end. So on the receiver side, the received BLE advertisements pass to the sharing D. Then the sharing D is now able to identify that there is a nearby device and what this device wants to do. But also, the sharing D needs to validate this authentication tag. This is possible because all previously connected devices share an identity resolving key. So all iOS devices are sharing these keys, and they are stored locally on device. So for every received message, they perform a SIP hash algorithm using the MAC address and one of those identity resolving keys, and then they check if the authentication tag matches. And if this is the case, this device has been seen before. So they know if this is actually a friend device. According to the Bluetooth specification, identity resolving keys or IR keys are used to resolve the actual Bluetooth address from the randomized address. Apple repurposes them here to generate those authentication tags. Now, the iPhone can be rather assured that the sending device is a friend's device. Therefore, it starts forwarding this information to the nearby D through the wrapper D. Here, iOS uses a trick to find friendly devices in ultra-wideband. They use the same randomized MAC address for ultra-wideband as for Bluetooth. So the nearby D initializes the U1 chip and wide lists the ultra-wideband MAC addresses. Now, the device can respond to the ultra-wideband beacons initiated by the AirDrop sending device. The sender gets information about the distance and the angle of nearby iPhones. This information is used to show the user, the person they are pointing the device at. So this is how AirDrop's implementation of ultra-wideband ranging and angle of arrival works. Now, we come to the second part, the nearby interaction framework. As shown with the nearby interaction framework, it is possible to range with nearby iPhones and measure the distance and angle to nearby devices. Furthermore, with iOS 15, Apple allows ranging with certified third-party ultra-wideband devices. To perform the ranging with nearby iPhones using the nearby interaction framework, both devices need to exchange NIDiscovery tokens. These tokens have to be exchanged using an out-of-band channel. This is left to the developers to implement it in a secure manner. The tokens are generated at random and the device which has the greater token will act as an initiator and the other device as an responder. And after the tokens have been exchanged, the user has to confirm the usage of ultra-wideband. Similarly to AirDrop, both devices will start sending out earlier advertisements. Those advertisements are different to the ones sent in AirDrop. So these advertisements are solely for ultra-wideband advertisements and they contain, as the other ones before, links and flags, but also an authentication tag and an ultra-wideband config. So only the initiator is sending the config and the responder device is only sending its authentication tag. But how are the devices now identifying each other? Both devices have a shared token. This token is used to identify the other devices using those BLE advertisements. Every token contains a 16 bytes randomly generated identity reserving key again. And similarly to AirDrop, this key is used to generate the authentication tag from the device's Bluetooth MAC address. They reuse the same Bluetooth MAC address for ultra-wideband again and this allows them to discover the correct device when performing ranging. After the devices have discovered their peer over Bluetooth energy, they can now perform ranging over ultra-wideband and continue. To secure this ranging, they use the so-called scramble timestamp sequences. Scramble timestamp sequences are used to generate multiple timestamps when receiving a message. Those timestamps can then be used to detect potential attacks on a protocol and additionally both devices can authenticate each other as they share the same STS values. To get an extra distance at both sides, they should perform double-sided ranging. The initiator sends the first message and then the responder replies to it. The responder replies with the time when he replied and the initiator has the time when this reply has been received. Therefore, the initiator can calculate by using the timestamp when the message has arrived and the time when the device replied and also they can deduct the processing times needed. The same procedure is handled on the other side and both devices have distances and angle of arrival measurements in the end. So, since the beginning of our research we wanted to receive actual frames from iOS. Until now, the whole system is really closed down. We do not get any packet logs from iOS and we do not get high-level reports of the measurements in the nearby daemon. So, to receive auto-write band signals we first need to know what our hardware should be capable of. In the system logs on a J-Brom device we can unveil a few things. So, from the nearby interaction packet we see the pre-ambles that are used and the channels that are supported and that they are using a hop pattern mask here. And also, we can see the usage of the scramble timestamp sequences. Many of those integers presented here are just an index in a list of supported configurations. So, when we check out those configurations we see that auto-write band here is using 64 MHz pulse repetition frequency and as auto-write band uses pulses to transmit data it can operate in different frequencies. And if they use the SCS values they need to use 64 MHz according to the standard. So, for 64 MHz we have 4 preamble codes and the indices are resulting to 3 which is here the preamble code number 12. The channels are also using indices so it supports the one chip supports channel 5 and 9 and here we see that the start channel is channel 9 and channel 5 is the alternative channel. So, next we need the write hardware now we need and we know that the development kits we wanted so we were looking for development kits that support the most recent standard and we found the one from Quavo which also uses the same channels as the one chip. Then Apple actually announced that they are supporting third party devices and they are also saying that the Quavo device we actually bought is one of the third party development kits they are supporting. So, we bought the write hardware here but to receive frames we also need to have the write configuration so this needs a set of parameters and most of them need to match otherwise the reception errors would occur and the frames would not be readable. Some parameters are clear from the logs like the channel and preamble code others are not known and they are likely hard-coded in the chip so they are basically the same for all transmissions. So, those which are not known here are the SES format and the SDF links. So, why is this important? Let's take a look at the ultra-wideband frame format. Here we see all frames start with a preamble. The preamble contains the specified preamble code and it can be repeated. So, this is why the preamble can have a variable length but with a wrong preamble code we would never receive any frame so the preamble would just not be detected. Then the preamble is followed by the start of frame delimiter or SFD. This start of frame delimiter is used to identify when the preamble ends. So, that's why the preamble it's not really important if we know how long it is we just need to check for the SFD. Then the SES value start and the SES also has is used for this then the SES starts the SES is used for the secure ranging and it can also have a variable length. So, it's quite difficult to identify when the SES ends and when the file header would start because it's not followed by something like an SFD. So, we need to know what the actual length is but not to receive any frames. Then to make this even more complicated there is a second mode for the STS so it can even be after the file header and also here it can have a variable length and then there's a third mode where the STS is after the SFD again but no data is shared. So, in this demo I want to show you how we have started sniffing against an actual iOS device with a U1 chip and for this we start this demo app from Apple which is using the nearby interaction framework and then the two devices start discovering each other and the user needs to confirm that the ultra-wideband is used and then they start ranging. We can see that they're ranging a distance here and we get a lot of locks on the left side from the iPhone and basically for every distance that is measured we get this one huge lock with the angle of arrival and the distance that's actually measured. On the right side we have seen the frames that are received by Wireshark so our frame, our Sniffer has been attached to Wireshark and we were able to receive some frames here. But even though this looked very nice on the first side from a closer look we see that it has still a couple of issues. So there are malformed packets everywhere received in Wireshark and even those packets that looked like they're not malformed have parts of those packets which are malformed or incorrect and also the data which is part of the packets looks very scrambled. So of course the scrambled data could be encrypted but those issues are most likely caused by misaligned STS value. So we tried every combination of lengths and mode but no one matched the Apple transmission modes. So Apple could have employed some custom STS links which is not supported by our device or they could have additional data after the STS which is not part of the official standardized frame format. So they could have used the custom frame format for example and I hope we will get more insights on this when the beta software from Quavo gets available so we can actually range with iPhones as supported with iOS 15 beta. So now we covered the two modes of interaction, Addrop and nearby interaction and Addrop's ultra wide band communication has been the first that was in iOS. And Addrop, one device sends ranging beacons and multiple devices can respond to it. Only the initiator or Addrop sender is able to get the distance information. For nearby interaction the ranging is performed in a peer-to-peer manner. Every device ranges with another and both receive the distance information as they are performing double-sided ranging. The devices participating in Addrop do not exchange any secrets and do not secure the actual ranging while on nearby interaction an initial off-band key exchange is necessary. Even though Addrop ranging is not secured by an STS value it should not be particularly dangerous to use Addrop. The ultra wide band part is just changes the order of how nearby people are shown in the user interface. And now I will hand over to Yisga again. Thank you. The nearby daemon is the one to start the distance and angle measurement no matter if this has been initiated by Addrop or the nearby interactions framework. For this it's using the rose controller lip which then calls functions in IOKit to communicate with the U1 chip. The chip initialization for the measurement is only done once. Then later on in return measurement tickets are sent multiple times containing the measurement data. The ticket data is not sent directly to other daemons. Instead the nearby daemon combines data with the so called rose neural engine sensor fusion and only forwards combined plausible measurements to other daemons. This still looks a bit like magic and so in the following I will explain how iOS interacts with the underlying hardware. The U1 chip actually consists of two main chips. Both of them are IAM. The application processor implements most functionality and it's only 32 bit. And then the signal processor runs on 64 bit IAM with ASLI. It does this more time critical tasks as well as the initial packet parsing. So for example the application processor generates the next STS and forwards it to the digital signal processor which needs it for the actual distance measurement and verification. The U1 chip has three receive antennas. This is required to get angular information and not only distance information. The three antennas are only required in the sensing aka receiving direction. So angles can still be displayed on an iPhone which communicates with an AirTag U1 chip even though the AirTag only has one receive antenna. All communication is routed through the always on processor. It keeps some basic state of the U1 chip and only wakes up the iOS kernel when needed. The iOS kernel in turn can set the other wideband communications route to either the application processor or the always on processor. While the U1 chip in the iPhone's home port mini and watch is very similar, the U1 chip in the AirTag is a bit different. It is the only U1 chip that is not powered by an iOS derivative and an always on processor. Because of this, the AirTag U1 application processor has a few additional features. Moreover, since it does not have a display it cannot show angular information and so has one receiver antenna only. More details about the AirTags and how to glitch the NRF chip that can then run custom firmware on them will be part of Thomas Talk hacking the Apple AirTags. All the chips I have shown previously run on the AirTags, which is a real-time operating system. Even if you have never heard of it it runs on almost every embedded device by Apple. There are some exceptions, so for example the NRF chip on the AirTags does not run RTK.OS. RTK.OS is very lightweight and maybe around 100 functions or a bit more. It is so small that even logging is implemented differently in every RTK.OS firmware. Note that there are RTK.OS debug builds with additional features. So for the U1 chip there exist debug builds in the wild and for example the iOS 13.3 on the iPhone 11 as well as the initial AirTag firmware both are U1 debug builds. You can find RTK.OS in almost every embedded Apple device. The AirPods 2 and Pro, the Pencil, the Siri Remote 2nd Generation, the Magic Keyboard variant for the iPads, the Always Processor and more. A few more details about RTK.OS with a focus on AirPods and Apple's own Bluetooth chip by documented in Dennis Teases. The iOS kernel has two drivers for the U1 chip. The Apple SPU Rows Driver User Client and the Apple SPU User Client. These drivers can be accessed from user space via IOCID and IOCID is a driver framework that takes care of exposing selected methods from the kernel to the user space. IOCID also validates the parameters that are passed to these methods. The Always On Processor has a equivalent to these two drivers which are called Rows and Rows Supervisor. So when the kernel goes to sleep and the Always On Processor takes over they are responsible. This principle is not unique to ultra-wideband. So you can also find it for various other chips and features such as Siri, even Apple's own which is available in AudioS for the HomePod Mini is managed by the Always On Processor. In the opposite direction, Rticket-based chips communicate with an RtBuddy in the kernel. This is mainly used for logging. Note that the RtBuddy is not directly exposed to IOCID. You can use the IORI command to check the driver hierarchy. This is very interesting since it does not only show the IOCID user client but also the IOCID interface name in the Always On Processor and the RtBuddy dependency. This is very useful to see which chips on an Apple device actually run RtKit OS. The nearby demon can directly send robot commands to the U1 chip. It still needs to use the IOCID framework. To do this it calls the function IOCONNECT call method and by setting the proper mach port it selects the Apple SPU The second argument is 5 which means that the function X-RowSticks is called in the kernel. Note that there are a lot, a lot, a lot of other functions in this driver. So for example the properties are being used during the RowsChipWood to get its unique identifier. And sending a row command to the kernel it still passes a few wrappers before eventually being forwarded to the AlwaysOnProcessor. In this specific example the AlwaysOnProcessor does not handle anything but forwards the command to the U1 chip. The application processor in the U1 chip then finally passes the command. However in some situations the AlwaysOnProcessor also needs to keep a state about what is happening in the U1 chip. In this case another driver is called the Apple SPU user client. In this example a property is said that affects the AlwaysOnProcessor state as well as the U1 application processor state. The Apple SPU user client exports fewer methods and they are primarily meant to get and set such properties that also affect the AlwaysOnProcessor. In this example the MAC address of the U1 chip is set. Note that this is simply two zero bytes concatenated with the Bluetooth address. So we have the same MAC address randomization as for Bluetooth. The 211 in this example is the MAC address but there are also various other settings available through this wrapper. Note that you should not switch the UltraWideband communications throughout out of context since communication with the U1 chip will no longer work until restarting the nearby daemon. The AlwaysOnProcessor also applies these properties and then also calls a handler in the U1 application processor to get this property set. You might have noticed that both the Apple SPU roles driver user client and the Apple SPU user client have a perform command method. However in this case of the Apple SPU user client these commands are not raw, they are only a few predefined commands. In our case this exclamation mark just means new service request and most of these commands also have a few parameters. The AlwaysOnProcessor then has a handler for these commands and it displays the settings and if needed also executes a command in the U1 application processor. The easiest option to start interaction with the U1 chip is using AirDrop. However as you can see as long as the other device is not in the contact list spatial information is not displayed in the user interface. Note that nonetheless some U1 interaction is triggered but this is not that helpful for debugging. Instead you can download the peekaboo example application from Apple. This is much more helpful and shows distance as well as angle information. In contrast to AirDrop it exchanges a peer token that is then also used for the STS in the U1 chip. What you can see here is the output of the nearby demon while the peekaboo app is running. So what you can see here is that we get regular measurements from the rose chip and everything is also sent to this sense of fusion to get a solution of the actual values. While the chip is idle the host sends a regular AP check-in. Once we start the peekaboo app it will take a moment and then the iPhones just cover each other and what you can see next is the service request and the ranging start. However the measurements are not sent via IOCID and this is why we do not see them. If you want to see more IOCID output you can change my script and reconfigure it to debug IOCID and with this you will see way more information. So this was the chip initialization and now we are starting the peekaboo app and as you can see here I will just quit this now we got a service request with a lot of information. On the left hand side you can see the most relevant log output from the nearby demon when using the nearby interactions framework. A new service request is scheduled and for this a general ranging packet is built that defines all transmission parameters. On the right hand side you can see the output of my free script. You can see the new service request in detail. Note that the STS output format in the original log is not very helpful. Apparently some developer decided to print each byte in variable length decimal without specifying a separator. When looking at this in hexadecimal it becomes clear that the STS is composed of contents of the nearby interaction peer tokens. To understand a bit more about the firmware we need to understand the format and load it into a disassembler. The U1 firmware is contained in every IPSW OTA image or peripheral image. You can simply extract it from the folder slash firmware slash rows. The f-tap format is rather simple and well known so there are even existing scripts to extract its contents. As of now I have encountered 5 different hardware variants the iPhone 11 vs. 12, the Apple Watch 6, the HomePod mini and the AirTek. The f-tap that you can download from Apple servers contains an application processor and digital signal processor image. Both of them can be statically analyzed with any reverse engineering tool of your choice. However the f-tap file stored on an iPhone after an update differs from the original f-tap file. It gets appended by a so-called AP ticket. This is a signature by Apple from the combination of this firmware and U1 chip. Each U1 chip has a unique ECID so you cannot simply boot a different firmware. I have not tried if it is possible to downgrade the firmware of the U1 chip yet but if it is possible then only if you have completed the according f-tap file from a jailbroken iPhone that is also signed by Apple. Next I am going to overwrite the firmware that I have with an older firmware from a different iPhone with a different iOS version with a different ECID. So first of all to get the chip into a clean state I am resetting it and now I am going to inject my firmware by pressing enter and now you should see that the chip is no longer starting and this is the case multiple times in a row until I am stopping my script so I will now stop my script here and you can now see that the chip is booting again so let's take a closer look into this. So actually we got some errors here and as you can see we see that the rows boot failed and we did not successfully boot the secure ROM. You can also see that we got some crash locks over here. A successful chip boot looks quite differently so you can see here that we are booting the chip and it is started including some parameters like this ECID so this is not written, this is just read so you cannot write this property, I tried this but this is all included in the boot process and also in the signature that is verified. The first thing I managed before understanding all the U1 internals was obtaining locks from the chip I simply did some static reverse engineering of the nearby and wondering how I could interact with the firmware I found a handler that always allows to trigger some fatal error handling. The same handler also contains another command to switch off the chip. This can be triggered through the iOS user interface by enabling flight mode. So I simply switched the implementation of switching off the chip and triggering a fatal error. As a result I got full crash locks and since this was on iOS 13.3 with a U1 RT KIT OSD bug build I also got packet locks. Note that in addition to triggering a fatal error it is also required to set a few more variables that make the nearby daemon believe it would be an internal build. Once I understood a bit more about the driver structure I found a better way to call such functions. The rose controller lip provides a lot of abstracted functionality for the nearby daemon. Since it is a shared library it even export symbols and the lip rose booter which is used during the chip startup also uses the rose controller lip and also export symbols. It is possible to directly call the function trigger crash lock in the rose controller lip and the second argument is the crash type as an integer. Alright, let's actually trigger a crash lock. So for this let's first of all watch that we are getting a new crash lock. So just check this on the right hand side and since we are running in Frida we can also just directly enter a command in this interface. So here I'm triggering the crash lock and now you can already see that the firmware is rebooting and on the right hand side we even got a new crash lock. So let's check this out. So the first thing you will notice is that the firmware locks with the packets are zero bytes because this is not a debug build and depending on the actual crash we only get an AP lock or also a DSP lock and we can see the crash reason in the summary so this is human readable. So as you can see here this was a code amp trigger that we caused on our own and actually it thinks that the firmware locks are enabled so I changed everything correctly within iOS but the chip just does not support this feature. With this I'm concluding the talk about Apple's new ultra-wideband chip. First of all Bluetooth and ultra-wideband are dependent on each other. They use the same MAC address and as of now ultra-wideband only works after initializing via Bluetooth. Apple's own Rticket based wireless chips are super super interesting and also have a lot of security features. Always on processor routing is great for saving energy and even though we cannot modify the U1 firmware as of now many features in the chip can be instrumented from user space on a jailbroken device. Some scripts that enable you to interact with the U1 chip will be available on GitHub on our groups page. Note that Defconn will not have a Q&A session this year so if you have further questions you can drop us a direct message or write an email. Thanks for watching.