back

Finding Eastereggs in Broadcom's Bluetooth Random Number Generator

Does your Bluetooth chip's RNG produce random numbers? Maybe. Sometimes. It's random.

If you suspend your transcription on amara.org, please add a timestamp below to indicate how far you progressed! This will help others to resume your work!

Please do not press “publish” on amara.org to save your progress, use “save draft” instead. Only press “publish” when you're done with quality control.

Video duration
00:41:32
Language
English
Abstract
-

Does your Bluetooth chip's RNG produce random numbers? Maybe. Sometimes. It's random.

The 90 day deadline for CVE-2020-6616 exactly passes during this Easterhegg \o/

According to the Bluetooth specification, the chip is required to contain a proper RNG. This RNG is used for key generation within the chip, but also exposed to the operating system. This is a great feature for embedded devices, which otherwise might not have access to a good RNG.

When analyzing the source code of Broadcom's RNG, we found that it accesses a Hardware Random Number Generator (HRNG) but has a Pseudo Random Number Generator (PRNG) fallback.

The HRNG looked good at least at first sight, and since it is a black box coming out of some memory mapped hardware registers, it is hard to analyze. It is missing some properties like a warm-up, which means reading out a couple of values during initialization before using it. However, the hardware might also do this internally.

Way more interesting is the PRNG, analyzed by @matedealer. The PRNG takes a couple of values which are not random at all. The most random value is the chip's clock. In most contexts within the code that require randomness, the PRNG is called multiple times in a row, thus, the clock is basically constant except from the initial value. Similar issues apply to the other registers and values the PRNG takes as input. The PRNG code was changed multiple times over the years of firmware dumps that we have, such as an additional caching behavior, different input values, etc.—and dropped in the most recent version.

On one development board, we found that the RNG function might run into the PRNG when calling it multiple times in a row. However, this seems to be an issue within the RNG cache of that specific development board.

When reporting this issue to Broadcom with CVE-2020-6616 already assigned by MITRE, they claimed all their chips had a HRNG and there was no reason ever to use the PRNG. That code was just there but would never be used. However, this is not true, and at least one comparably recent chip of a popular smartphone released in 2017 is missing a HRNG. Ooops :)

So we might have something like the KNOB attack here with slightly less entropy reduction but present in the hardware…

Talk ID
divoc20-6
Event:
Hidden_Service
Day
1
Room
Feinler
Start
9 p.m.
Duration
00:45:00
Track
None
Type of
Talk
Speaker
jiska
Talk Slug & media link
DiVOC-6-finding_eastereggs_in_broadcom_s_bluetooth_random_number_generator
English
0.0% Checking done0.0%
0.0% Syncing done0.0%
0.0% Transcribing done0.0%
100.0% Nothing done yet100.0%
  

Work on this video on Amara!

English: Transcribed until

Last revision: 8 months, 1 week ago