Security hardening against wormhole attacks

[stcz]

Thanks for your great work on the CWA app.

We are a group of researchers from TU Braunschweig. As part of a research project, we have studied wormhole attacks against Corona contact tracing, especially on the Google and Apple Exposure Notification backend (GAEN). A paper of this research can be found here. We want to share our findings with you and, if possible, help improve the CWA app or GAEN.

First, our analysis shows that the effort for a successful wormhole attack on the Corona Warn App is quite high, rendering an attack less likely. Nevertheless, there are simple improvements that could make the app more robust against this particular attack.

Improve RPI lifetime

Current Implementation

Currently, the lifetime of a Rolling Proximity Identifier (RPI) is 10 minutes. From the perspective of resistance against a wormhole attack a shorter lifetime would be better.

Suggested Enhancement

Reduce the RPI lifetime so that a single RPI cannot lead to a high-risk warning. That is, always two RPIs from the same TEK are necessary to create a false high risk warning. Be aware of the clock drift here.

Expected Benefits

An attacker cannot randomly collect RPIs and replay them to a victim. This increases the attacker's collection effort a lot.

Expected Disadvantages

The costs are a decrease in performance and an increased battery consumption during the key matching. Furthermore, the memory consumption during the collection increases.

Reduce Clock Drift windows

Current Implementation

Currently, the GAEN implements two windows for clock drift. First, as you can see here, RPIs can contribute twice their lifetime to the Exposure Window. Second, RPIs are valid 2 hours before and after their rolling period.

Suggested Enhancement

The time period how long RPIs are valid and can contribute to an exposure window should be as short as possible. An improvement might be to reduce the tkMatchingClockDriftRollingPeriods to 1 and instead add a warning to the app if the system time is out of sync. Because an internet connection is necessary to receive the diagnosis keys, an offline only mode is not needed, and a correct time could be checked there.

Expected Benefits

An attacker cannot replay RPIs for an extended time period, which increases the effort of wormhole attacks.

Expected Disadvantages

The exposure notification only works within the clock drift windows. If devices are out of sync, they might miss valid RPIs.

Add a threshold for RPIs per scan window

Current Implementation

An arbitrary high amount of RPIs per scan window is valid. That is, an attacker can flood the app within the limits of the Bluetooth bandwidth.

Suggested Enhancement

Allow only a realistic amount of RPIs per scan window (e.g. 100). Higher values of RPIs per scan window should not occur at normal circumstances. Higher amounts of RPIs per scan window should be dropped, either with or without user interaction.

Expected Benefits

During an attack, a high value of RPIs is necessary for success. This would reduce the risk of wormhole attacks considerably and limit the possibility of the attacks to a very high incidence (1000 for an incidence of 100).

Further, this would make the app more robust against denial of service attacks.

Expected Disadvantages

None

---

Internal Tracking ID: EXPOSUREAPP-12159

[dsarkar]

Dear @stcz,

Thank you very much for your suggestions. We will forward this internally, Internal Tracking ID: EXPOSUREAPP-12159.

Best wishes, DS

---

Corona-Warn-App Open Source Team

[stcz]

:heart: If you have any questions, feel free to contact us.

[Ein-Tim]

@stcz

Did you also send your research to Apple / Google?

Point 1 & 3 must be implemented by them. Reg. Point 2, I'm unsure whether this can be implemented be the CWA team.

[stcz]

Not jet. :see_no_evil: I wanted to write the issue also to https://github.com/google/exposure-notifications-internals but this is not possible anymore. Currently, I'm searching for the best way to get in contact with the Google Developers. If you have a hint for me I would be very glad. I'm going to write them an E-Mail.

[MikeMcC399]

@stcz

I'm searching for the best way to get in contact with the Google Developers. If you have a hint for me I would be very glad.

Google used to have an e-mail address exposure-notifications-feedback@google.com. I can't say if this is still active though.