[SECURITY Question] DOS Attack / data flooding on bluetooth layer possible?

[sme-gmbh]

Thinking about the following scenario I have a question:

As the beacon packets are broadcast that are not to be answered by the receiver and there is no mechanism of encryption key exchange between the sender and the receiver it is possible to attack the receiver with a denial of service attack / data flooding.

Evil E could simply randomly calculate valid beacons in a very high amount. As verification only takes place after downloading the infected keys, all the receives beacons are stored on the receiver whether they are valid or not. As high rate of beacons will quickly fill the available storage space on the device, finally the device will fail due to lack of free storage. In fact all the sent keys may be invalid so these could never positively confirm an infection. Nevertheless they use up storage as they are stored for 14 days on the receiver device.

Of course the impact of devices in range of the evil bluetooth sender might be low as the transmission range of bluetooth is low. But think of a bluetooth sender with a decent power amplifier attached and a good antenna location... A sender with a few 100 Watts output power could quickly take all smartphones with the app installed out of service within some hours by sending gigabytes of random keys. The transmission range of such powerful sender might be a few hundred to few thousand kilometres, so half of a country's smartphones could possibly be taken out of service within hours. The output power of the amplifier could be set in a way to selectively take smartphones in a defined range out of service, so this could also be an attack vector to unwanted companies / cities as well.

So far the fictional scenario.

Now here comes my question as this is not desribed in the documentation: Is there any method of rate limiting / storage space limiting in place on the receiver to prevent that kind of flooding attack? As this app has been tested by data protection experts testing against data flooding should have been done, what were the results?

[mh-]

The received RPI/AEM beacons are not stored in the app, but within iOS or Google Play Services respectively. That is not Open Source, but at least on Android, you can (only with root permissions) analyze the LevelDB that is used to store the received beacons. I found that devices scan every ~4..5 minutes for 4 seconds and store up to 14 readings for each unique RPI. See also https://github.com/corona-warn-app/cwa-documentation/issues/207#issuecomment-640780797 Maybe you can re-do your math based on this information, and also please keep in mind that Google/Apple would have to devise a strategy in case memory is full, not the app developers here.

[daimpi]

This piece on maximum BLE beacon density might also be useful for your calculations: https://blog.ruuvi.com/bluetooth-beacon-density-maximum-92bcb947ee99

via https://threadreaderapp.com/thread/1271881305614057474.html via https://github.com/corona-warn-app/cwa-documentation/issues/273#issuecomment-645322925

[sme-gmbh]

So according to that document from TI it should be possible to get 1 MBit/s of payload data rate. Synchronisation between the packets can be done perfectly as in the described scenario there is only one sender which can be perfectly synchronize the packets to the available timeslots.

Also there is some overhead that is stored additionally to the payload data, such as RSSI values, timestamps and database structure. Let's assume this overhead to a factor 2, so we get 2 MBit/s data which will continuously be stored on the phone. The fact if that is within the app or within the operating system somewhere else doesn't really matter. If the available storage is full, the device gets unusable.

Let's further assume that someone has 1 GByte of free storage on the phone. Maybe some people have more and some have less, but thats not the point, is just about the order of magnitude.

The storage will be full after 1GByte / (0,2 MByte/s) = 5000 seconds (less then 2 hours).

At least I feel that as a kind of a threat as long as there are no other methods of ratelimiting than the bandwith of BLE itself.

According to https://github.com/corona-warn-app/cwa-documentation/issues/207#issuecomment-640780797 I understand that 4 second timeslot as the active interval of broadcasting. The receiver should be always on, otherwise it will miss important broadcasts which are not in sync with the active receiver interval. So the full datarate of BLE should be reached in my opinion in case of an 'always on' sender. Maybe someone has further information about that.

[daimpi]

According to #207 (comment) I understand that 4 second timeslot as the active interval of broadcasting. The receiver should be always on, otherwise it will miss important broadcasts which are not in sync with the active receiver interval. So the full datarate of BLE should be reached in my opinion in case of an 'always on' sender. Maybe someone has further information about that.

Afaik it's the other way around: we have permanent broadcasting (in 250ms intervals) but less frequent recording (every 4-5 min for 2-4 sec) (see here and here).

[mh-]

So according to that document from TI it should be possible to get 1 MBit/s of payload data rate.

Are you designing your own setup based on a TI CLE chip, or are you trying to understand how Google/Apple Exposure Notifications work? If your concern is about the latter, my comment above explains how much data the Google framework actually receives.

[SebastianWolf-SAP]

Dear @sme-gmbh, dear colleagues,

we discussed this and other issues related to the underlying Exposure Notification system and/or the Bluetooth stack. Unfortunately, our message is still the same as in https://github.com/corona-warn-app/cwa-documentation/issues/228#issuecomment-643340245: We can't address these issues.

The reason is simple: We are not bundling the respective libraries/functionality that implement the Exposure Notification system, the Bluetooth stack or any other component which might be affected or play a role in the issue which you are describing. We only use public and well-documented APIs. The underlying components exposing these APIs are within the responsibility of Apple and Google. Consequently, this and other issues also need to be addressed by these two responsible companies.

Following that, we will close this issue as well. Thank you for your understanding.

Mit freundlichen Grüßen/Best regards, SW Corona Warn-App Open Source Team