Auracast, the new Bluetooth LE Broadcast Audio feature has gained some publicity in the past months. The Bluetooth SIG has introduced the LE Audio feature-set to the Bluetooth 5.2 Specification in 2019 and vendors are only now starting to implement it. Auracast facilitates broadcasting audio over Bluetooth LE to a potentially unlimited number of devices. It does not require pairing or interaction between the sender and the receivers.
We also presented this topic at 38c3. This blog post will contain similar contents albeit with some more details.
Auracast and its underlying technologies lend themselves to a number of interesting applications. It could also become a strong enabler of accessibility, for example, when hearing aids start to support it. We really like the idea and general design of Auracast. However, we identified a number of issues, both technical and with regard to the specification and documentation.
The goal of this first of two blog posts is to provide a general technical overview of Bluetooth Auracast. As we are mainly interested in the security of the protocol, the post will be from a security researcher’s perspective, but it may also be useful for developers. In the second part we will talk about more technical details and attacks against Auracast.
What is Bluetooth Auracast?
With the Bluetooth Core specification 5.2, the Bluetooth Special Interest Group (SIG) introduced a new technology. Audio over Bluetooth Low Energy (BLE). Previously, streaming audio was only possible via “Classic” Bluetooth (Bluetooth BR/EDR) and the specification didn’t really consider Audio over BLE. One exception is Apple’s proprietary Audio-over-BLE protocol for hearing aids which has been around for some time.
The Bluetooth Core Specification 5.2 introduced Bluetooth LE Isochronous Channels, which doe the heavy lifting to enable BLE audio streaming with very low latency. But this version of the specification also added a new physical channel, new logical transports, and quite a number of other new protocols. At the end, all of these make the Auracast technology which can be used to efficiently broadcast audio via BLE.
The terminology here is sometimes a bit confusing. It seems that the SIG introduced the term Auracast in hindsight, to better market the LE audio capabilities while focusing on the broadcasting part. The term Auracast only ever refers to audio broadcasts in official documents.
While the real-world adaptation is currently still low, the Bluetooth SIG already mentions a few use-cases for Auracast. For example, broadcast announcements at airports, music sharing at parties, as well as audio streaming for hearing aids1. LE audio in unicast mode is likely to replace the current way of streaming music from a playback device to users’ headphones. One great advantage of isochronous BLE audio is that different audio channels (e.g., the right and left audio channels) can be transmitted to each individual earpiece of a pair of true-wireless headphones independently. The synchronization between these channels within one stream is part of the protocol, thus vendors do not need to take care of synchronizing the buds themselves. This makes synchronization much easier and saves power.
Another new component of Auracast is the new Low Complexity Communication Codec (LC3). It apparently offers a lower latency and higher bit rates than the previous SBC codec2. The codec itself was not part of the scope of our research.
Auracast specifies three different roles. The Auracast transmitter, receiver, and assistant. The transmitter is a device that transmits the audio broadcast streams. The receiver is a device that receives these streams – this would usually be headphones or speakers. As many headphones do not really have a proper user interface, a third role – the assistant – is introduced. The assistant connects to the receiver and can be used to configure the receiver. For example, it can be used to join streams, change the volume or configure a Broadcast Code which is required for encrypted streams.
The image below (taken from the How to Build an Auracast Transmitter document) shows this relationship:
Broadcast Isochronous Streams (BIS)
Before getting into the technical details, we will first give a general overview over how Auracast broadcasts work. If you want to create a new broadcast source, you will need a broadcast name and, if you want to encrypt the stream, a so-called broadcast code. This code is required by clients to decrypt the stream and successfully decode the audio data.
Once the stream is started, the broadcast source will start advertising. The Bluetooth SIG created a concept view of how the discovery of such broadcasts might look like:
This mock-up looks similar to a Wi-Fi discovery screen. The intention is that Auracast broadcast are generally publicly discoverable and connectable.
On a Samsung S23, which is one of the devices that currently support joining Auracast streams, this looks very similar. The S23 acts as an Auracast Assistant, while the connected Galaxy Buds act as the Auracast Receiver.
Advertisements
The advertisement part of Auracast is where it starts to get interesting. It uses two different types of advertisements, one of which is a rather new type, the periodic advertisements that have been introduced in Bluetooth 5.0. In the primary advertisement, the device basically announces itself and points to an auxiliary advertisement. If the receiver is then interested to learn more about the device, it can follow the pointer to the auxiliary data. This part of the advertisement contains more information about the broadcast, e.g., its name, its ID and yet another pointer to the periodic advertisement.
Periodic Advertisements
In short, periodic advertisements are a way to periodically send out advertisements in a predictable sequence. Both the time of arrival and the channel (remember: Bluetooth does channel hopping) are known to subscribed devices. This allows the receiver to save energy by only receiving at the specified time and channel when a new message is expected. This allows transmitting and receiving periodic data very efficient.
BIGInfo
If the receiver decides to follow the periodic advertisements of an Auracast broadcast, it will receive the so-called BIGInfo and BASE packets. These contain information about the individual streams in a broadcast, as well as subscription information for the Isochronous stream itself. Similar to the subscription to periodic advertisements, the BIGInfo contains information about the timing and the channel hopping sequence of the Broadcast Isochronous Stream (BIS) packets.
The graphic below (taken from the official Auracast Transmitter Recommendations document) illustrates this chain of advertisements.
The cool thing here is that this process allows anyone in range of the broadcast to join and listen in without any type of interaction between the sender and receiver. This allows a potentially unlimited number of receivers to listen to the broadcast without the overhead of a pairing or an active synchronization process.
You might be wondering about spoofing at this point. We did too. Yes, there is no authentication here.
The BIS synchronization process is the same for both open and encrypted broadcasts. All packets and data that were mentioned until here are transmitted in plain text. Apart from a few individual fields that indicate an encrypted stream, the advertisements are the same. Only the BIS PDUs itself are encrypted.
Broadcast Isochronous PDUs (BIS PDUs)
BIS PDUs are constantly sent out by the Auracast transmitter at a fixed interval and according to the frequency hopping sequence. They can either hold audio data in BIS Data PDUs or hold control information in BIG Control PDUs.
Depending on whether the broadcast is encrypted, these PDUs are either encrypted or in plain text. The BIGInfo packet indicates the encryption status of the stream. It is sufficient to check the length of the BIGInfo, if it includes the GIV and GSKD fields the stream is encrypted.
An unencrypted BIS PDU includes a two byte header and the actual payload. The header holds one byte of meta information and one byte that specifies the payload length.
The payload of data PDUs is simply raw LC3 encoded audio data. For control PDUs the payload field carries a one byte Opcode and so called CtrData. The content and size of CtrData depends on the type of Control PDU identified by the OpCode.
The following animation illustrates the PDU transmission. Here we have a Broadcast Group (BIG) with two individual streams (BIS). These could be, for example, the left and right channels of an audio track. The group event (BIG Event) starts at the anchor point, pointed to by the BIGInfo. Then there are one or more packets per BIS. In the last of the three examples, a control PDU is sent, which is always sent last.
This layout can become much more complex with pretransmissions and retransmissions. To increase availability and resilience, packets can be sent multiple times and PDUs from future BIG events can be included in previous BIG events. This configuration is part of the BIGInfo and has to stay the same over the lifetime of a stream, as it determines timings and spacing between PDUs. The Samsung Galaxy S23, for example, will send a total of 18 BIS PDUs per BIG event. Nine PDUs per BIS with a number of retransmissions and pretransmissions.
This will become more relevant in the second part of this series, when we come to real-world attacks. For now, we’ll stick with the simple assumption of one PDU per BIS.
Security
Now that we have introduced Auracast on a conceptional level, let’s talk about Security!
We have mentioned before that there is something called a Broadcast Code, or Passcode, as the specification intends to call the code in user-facing applications. We also already mentioned that BIS PDUs can be encrypted. But before going any deeper into the encryption, let’s first take a step back and talk about what security concerns one might have with Bluetooth audio broadcasts and what security properties the specification guarantees.
Security Concerns
We searched through the specification and other official material around Auracast, but were not able to find a section that properly describes the security properties that the protocol is supposed to guarantee. So we tried to formulate a few security concerns one might have with Auracast. Later on, we’ll examine whether these concerns are addressed.
- Privacy: Broadcasts might be intended to be private, only available to a select group of recipients.
- Authenticity: Broadcast content should not be spoofable.
- Availability: Broadcasts should be resilient to accidental and deliberate interference.
Privacy
There is an FAQ regarding Auracast which contains a question about others listening in on the stream:
Can we control the overspill when using Auracast™ broadcast audio as a one-to-one counter system so others nearby cannot listen in?
Auracast™ broadcast audio is capable of using broadcast codes for secure conversations. Managing output power and spillover alone does not guarantee privacy. The use of broadcast codes is recommended for private access.
For users this description is probably fine. But on a technical level “secure conversations” and “private access” are not really meaningful. Let’s look at a few examples where Broadcast Codes are being used.
First, we have TV that has the passcode 123453, which, according to Wikipedia is only the 6th most common password. So it’s probably fine and a well-chosen example4.
The next one is an example of a Broadcast for “Mark’s Tasting Evening”, taken from the Auracast Transmitter Recommendation document. This time, the passcode is “PinotNoir”. Which is much better than 5 digits, but if it was used as a password, we’d probably still consider it insecure.
Lastly, the specification itself also gives an example of a Broadcast Code. However, this example is only here to illustrate how UTF8 is handled. It also mentions that “16 octets should be used for higher level of security”, which is the only indication towards the nature of the Broadcast Code.
Encryption
When an Auracast broadcast is encrypted and a Broadcast Code is in use, the BIS PDUs are encrypted using AES-CCM. AES-CCM is an authenticated encryption scheme, that essentially means AES in CTR mode is used for confidentiality and AES CBC-MAC is used for authentication. The encryption looks as follows:
As AES_CCM is an AEAD scheme it also supports MAC protection for associated data that will not be encrypted. BLE uses this feature to protect parts of the BIS PDU header. Specifically, the CSSN and CSTF fields are excluded, by setting them to zero before calculating and verifying the MAC respectively.
The question remains, what exactly is being used as the key for this encryption? We cannot just use something like “PinotNoir” as an AES key. Here comes the key derivation!
Key Derivation
The specification makes understanding the key derivation a bit more difficult than it could be. What you’ll initially find is the following:
The Group Session Key is essentially the AES key for the PDU encryption. You can see that there are three different functions h6, h7, and h8. Both h6 and h7 have existed before, while h8 has been introduced with Isochronous channels.
The definition of these functions can be found (at a different location) in the specification, and they are defined as follows:
- h6(W, keyID) = AES-CMACw(keyID)
- h7(SALT, W) = AES-CMACSALT(W)
- h8(K, S, keyID) = AES-CMACIK(keyID)
- with IK = AES-CMACS(K)
Graphically, the key derivation can be represented as follows:
The exact semantics of these functions is not that important here. What is important is to show that these are mainly just wrappers around AES-CMAC. If we “resolve” the H-functions to the actual AES-CMAC calls, the graph will look as follows:
If the Broadcast Code is shorter than 16 bytes, e.g., when it is “PinotNoir”, then it will be padded with null bytes to fill up the required 16 bytes for an AES key here. The GKSD value is chosen at random by the broadcast transmitter and included in the BIGInfo packet.
Privacy Guarantees
The encryption scheme based on AES-CCM is fine5. With a proper key it provides authenticated encryption. However, the key is the issue here. The key derivation method used is not sufficient for the use-case. Using AES-CMAC to derive keys based on, for example, shared secrets is a valid application. It is suitable wherever a key derivation with a PRF would be suitable. It is, however, not suitable for Key Stretching, which is what we would want to achieve here. Key Stretching adds a known number of bits to the expected difficulty of an exhaustive search attack. In other words, it makes cracking or brute-forcing much more costly and difficult. Password managers or vaults have similar requirements where they take the user’s password and derive a strong encryption key using a costly derivation function. However, they also have much stricter requirements for passwords. Which is another issue here.
For Broadcast Codes you are limited to 16 characters. The specification states that the Broadcast Code must be at least 4 bytes long. It also says that “for higher levels of security” a 16 byte Broadcast Code should be used. No other statements are made about the properties of the Broadcast Code. Moreover, the examples in official documentation and the specification indicate that it is okay to use Broadcast Codes consisting of only digits or simple words.
In combination with the very weak key derivation, the Broadcast Code is essentially to be treated as a raw AES key and therefore way too weak if chosen as 5-digit value or dictionary word. As a consequence, it is possible to easily brute-force Broadcast Codes that are not 16 bytes long.
In the video below an Auracast stream is started, and the Broadcast Code is cracked within fragments of a second. Our Auracast Hacker’s Toolkit is used to dump RAW BIS PDUs of the broadcast and our biscrack tool is used to crack the Broadcast Code with the given BIGInfo and a BIS PDU. More technical details about how this works will be given in part 2 of this series where we’ll introduce the Auracast Hacker’s Toolkit and biscrack.
What this means is that an attacker in range of the broadcast can synchronize to the broadcast, dump raw, encrypted BIS PDUs and then crack the Broadcast Code with just one BIS PDU and one BIGInfo packet. The cracking process can happen offline and is very efficient. On a mid-range Laptop it takes about 10s to go through each entry in rockyou.txt.
Once the attacker has cracked the Broadcast Code, they can listen in on the Auracast stream. But not only that! Auracast encryption does not have forward-secrecy. So an attacker can dump and store encrypted PDUs and decrypt them later once they have cracked the Broadcast Code. So even if the Broadcast Code is more complex and takes more time to brute-force, the attacker can still get access to information transmitted in the past.
Authenticity
In case of unencrypted broadcasts there is essentially zero authenticity. In order to synchronize to a broadcast, the listeners need to know all parameters that are related to the timing and spacing of the PDUs. Each participant thus has the ability to not only receive but also send PDUs at exactly the timings and channels that they are expected by other participants. This means that it is easily possible to overshadow individual PDUs. However, the attacker needs to have a stronger signal or be closer to the victim than the benign sender. The victim does not have the ability to differentiate PDUs originating from the benign sender and attacker.
Encrypted broadcasts use authenticated encryption. However, that does not automatically imply that the broadcasts themselves are authenticated. Individual PDUs are authenticated. But the authentication is based entirely on the Broadcast Code. So everyone that knows the Broadcast Code can create encrypted and authenticated BIS PDUs. This issue is similar to the one above, and combined with the one above, this again means that any participant with knowledge of the Broadcast Code can inject arbitrary encrypted BIS PDUs. We like to call this Perimeter Authentication, where there is a trust boundary between everyone that knows the Broadcast Code and everyone else that doesn’t. Everyone inside this boundary must trust each other, as the actual sender of PDUs cannot be verified. The concept is about as modern and effective as perimeter security in enterprise networks.
In combination with the previous issue this becomes more severe. If the Broadcast Code is easy to crack, this boundary is easily broken by an attacker. The attacker can get inside the perimeter without any of the participants noticing. They have no way of verifying whether the PDU comes from a benign source.
The lack of authentication has already been addressed in a paper in 2023. The BISON attack allows an attacker to overshadow PDUs and inject a control PDU in order to hijack the stream. The attacker can divert the victims to their own stream by sending a channel map update. The benign sender will continue sending PDUs in the old channel hopping sequence, but the victims will follow the adapted hopping sequence introduced by the attacker.
We’ll get into the attack in more detail in the next post, but you can also take a look at the original paper.
Availability
Availability in radio communication is a delicate problem. With enough money and resources it will always be possible to jam radio signals and violate the availability. However, there are nuances to this. Bluetooth is building resilience against jamming via its Adaptive Frequency Hopping (AFH) feature. The frequency hopping sequence is a property of a Bluetooth connection. Instead of sending PDUs on the same frequency, each PDU is sent on one of the 37 defined sub-channels. An attacker would either have to jam all sub-channels at once (which is expensive), or somehow guess the hopping sequence to jam each sub-channel individually at the correct time.
It is important to note that AFH is not an explicit security feature, it was introduced in Bluetooth to avoid collisions, but it turned out to also be beneficial for security.
This protection is lost with broadcasts. As every participant will need to know the hopping sequence to properly receive the PDUs, the hopping sequence can be considered “public”. An attacker can receive the BIGInfo packet and deduce the hopping sequence from it. This makes selective jamming much easier. However, this is a problem that is likely impossible to solve. As these broadcasts are intended to be used without interaction between receivers and transmitters, there is no way to negotiate hopping sequences and an attacker will always be able to obtain the sequence.
Unfortunately, the same applies to encrypted broadcasts. Regardless of the PDU encryption, the hopping sequence is transmitted in the BIGInfo in plain text. While an attacker might not be able to decrypt the PDUs, they can receive every PDU as the hopping sequence (as well as the timing information) is publicly known. Even though the PDUs are encrypted, the hopping sequence is not protected. This is a key part of why it is relatively easy to dump raw encrypted PDUs, which is required for the brute-force attack described above. If the hopping sequence was derived from the Broadcast Code, the attack would be significantly more difficult, as an attacker would have to brute-force the hopping sequence or spend a lot of resources to capture a PDU.
We also identified the possibility for an efficient denial-of-service attack. It requires an attacker to send only a very low number of PDUs to disconnect receivers in range from the broadcast. This attack only works against encrypted broadcasts. More details about this attack will be in the second part of this series.
So while availability can be considered an unsolvable issue in radio communication, there are certainly things that can be improved here. Especially the “public” hopping sequence in encrypted broadcasts as this would also affect other weaknesses in the protocol.
Summary and Conclusion
Auracast, and Isochronous channels in general are a great technology. The possibility to broadcast data via Bluetooth with this type of scalability is great. The automatic synchronization feature for both Connected, and Broadcast Isochronous Streams will make true wireless earbuds much more efficient, and probably even better, with less synchronization issues. Moreover, it’s not only limited to audio. Isochronous Channels could potentially be used for any kind of data!
However, there are many issues in regard to security. Our primary criticism is probably the lack of reasoning behind decisions in cryptography and security and the complete lack of discussions about the security properties of the protocol in general. For example, it is extremely difficult, if not impossible, to guarantee forward-secrecy in Broadcast Isochronous Streams. But this is a property that needs to be discussed in the specification. If this technology is to be used in critical infrastructure, which the advertised use-cases such as airports or hearing aids are, then the users and especially the vendors that implement Auracast products need to be aware of this.
As for the Broadcast Code cracking we have the following proposals towards the specifications:
- Improve the key derivation: The key derivation should involve proper key stretching. The derivation should be a costly operation. In the benign case, this operation only has to be executed once, but it will increase the time required to crack the Broadcast Code. Bluetooth LE devices, such as earbuds, are often low-power devices might lead to the argument that a costly derivation function is not possible. However, the derivation could also be moved to the Auracast Assistant. The Assistant is the entity that provides the Broadcast Code to the Auracast Receiver. So the actual derivation could be done on the Assistant’s side. Then the data submitted as Broadcast Code to the receiver would be the raw AES key. On the transmitter side we will usually not have low-power devices, so the derivation should not be a big issue here.
- Protect the hopping sequence: The hopping sequence should be derived from the Broadcast Code. This way, an attacker can no longer capture BIS PDUs as easily. The brute-forcing or cracking problem would now be online instead of offline and probably unfeasible in real-world situations.
But what can we do for now?
Vendors
Make sure to generate secure default Broadcast Codes. In the best case this is a 16-character code with random printable characters. Also introduce a minimum length, ideally 16 characters. Real-world usability requirements will probably make this difficult, but the goal should be to get as close as possible to that. Other ways of transmitting Broadcast Codes could also be a good option to have users accept complex codes. For example, a QR code that contains the Broadcast Code would even allow choosing 16 random bytes, as they would not need to be printable.
Users
If you have the possibility to set the Broadcast Code, set it to a random 16-character string. Treat the Broadcast Code like a password. So avoid easily guessable words and try to exhaust the whole space of printable characters. And don’t use Auracast for anything very sensitive. Remember that there is no forward secrecy and an attacker can efficiently brute-force the Broadcast Code when they capture packets.
Wrap-Up
In the next part of this series we’ll get into more technical details, especially regarding the actual attacks and the toolkit we’ve built to interact with Auracast streams. For now, you can already find some of the code in our GitHub Organization. At the time that this post is published the toolkit is still very much work in progress. We’ll get into the usage and how to reproduce our cracking example from the video above in the next part.
Until then, feel free to contact us on Mastodon (ttdennis@chaos.social, twillnix@infosec.exchange) or e-mail if you have any questions.