Device Attestation

[christian-kirschnick]

(onhold due to waiting for Google/Apple spec)

When the user sends the diagnosis keys, we need to verify whether the request came from a legitimate source.

• Accept the "platform" attribute in the incoming request. Must either be "ios" or "android". Needed for the device verification payload below:
• Device Verification Payload: This is either Android SafetyNet device attestation or iOS DeviceCheck attestation.

Problem: This highly depends whether data privacy team is OK with this. I will sync with them.

[kbobrowski]

@christian-kirschnick you mentioned that Device Attestation will be used for sending diagnosis keys, is it also planned for downloading diagnosis keys?

[christian-kirschnick]

Downloading diagnosis keys will not be restricted.

[sventuerpe]

What could happen in the worst case if any entity such as a rogue app instance were able to submit any set of diagnosis keys?

related discussion: corona-warn-app/cwa-documentation#102

[christian-kirschnick]

Uploading is protected by different safeguards, most prominently is the requirement of a TAN. A TAN can only be used once.

TAN's are issued by the system after a COVID-19 positive test result, and is then shared with the mobile client, which will use it to gain authorization for uploading keys.

[christian-kirschnick]

But to answer your original question: Even if an attacker gets a hold on a valid TAN somehow; the worst case scenario would be false-positive warnings on your mobile phone, telling you that you were in proximity of a COVID-19 positive tested patient in the past 14 days. But for that to happen, the attacker needs to generate diagnosis keys, which match tracing keys received by other users.

[christian-kirschnick]

Device attestation will be out of scope unless scoping team will decide otherwise. The fields will stay present in the submission API in order to ensure compatibility to the official spec, but the backend will not process those fields in case they are filled.