Skip to content
This repository has been archived by the owner on May 16, 2023. It is now read-only.

[SECURITY] False negative attack #322

Closed
pdehaye opened this issue Jun 21, 2020 · 3 comments
Closed

[SECURITY] False negative attack #322

pdehaye opened this issue Jun 21, 2020 · 3 comments
Labels
security Issue concerns security

Comments

@pdehaye
Copy link

pdehaye commented Jun 21, 2020

Issue #228 describes how the Tx power metadata can be modified (in a not necessarily fully deliberate way, there is some randomness involved).

The new cwa-risk-assessment.md file says that:

All exposures for a diagnosis key that lasted less than 10 minutes in total (regardless of how close the smartphones came during that time) or during which the smartphones were more than 8 meters (73 dB attenuation) apart on average (regardless of how long the exposure lasted) are discarded as harmless.

If an attacker listens to CW app signals and rebroadcasts the beacons with modified metadata, this will imply that the other CW apps will have many more values to average over. Depending on:

it might mean that some exposures are discarded that shouldn't have been.

I probably could make this more precise if the doc was itself more precise on how the average is calculated and how the thresholding works.

@pdehaye
Copy link
Author

pdehaye commented Jun 21, 2020

The Apple doc says

The attenuation (transmission power - RSSI) can vary during an exposure event. Attenuation values >0 are weighted by the duration at each risk level and averaged for the overall duration. The framework measures and calculates this value.

which seems to confirm what is described above.

@mh-
Copy link

mh- commented Jun 21, 2020

Well, I will leave it to @sventuerpe to ask the obvious questions.

@tkowark tkowark added the security Issue concerns security label Jun 21, 2020
@SebastianWolf-SAP
Copy link
Member

Dear @pdehaye, 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 #228 (comment): 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

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
security Issue concerns security
Projects
None yet
Development

No branches or pull requests

4 participants