This inner payload allows for minimum information sharing - just large enough to enable contact tracing. This makes it simple, but it’s not as secure as the Herald Secured payload, and really only supports decentralised contact tracing.
Click here to View the Formal Specification for the Simple Payload
In particular the simple payload:-
In addition to the information in the Herald envelope header, the simple inner paylod provides the following data.
Note: All numeric data is big endian.
Below is a visual representation of what each phone and health authority knows:-
Below is a simple security summary.
Confidentiality - No. The Contact ID can be intercepted in the clear by any Bluetooth device, allowing relay and replay attacks. Only the phone who generated the Contact ID will know who it belongs to. By rotating the Contact ID regularly (E.g. every 15 minutes) localised Bluetooth tracking can be reduced (E.g. adboard)
Integrity - Yes. Only the sequence of codes for a particular phone can be known by that phone for that time point as only that phone has the daily key seeds. Data could not be manipulated or predicted such that an individual phone could be targeted.
Availability - Maybe. Could be compromised by a brute for attack DDoS-ing the healthcare system using a fake network of pre-registered devices. Amplification attacks are possible in this approach. This can be somewhat mitigated by using a max number of notified contacts per ill person submission approach, but this doesn’t prevent the creation of a fake network with, say, 5 notifications each.
Non-repudiation - No. Neither the health authority nor receiving device are authenticated in this approach. The healthcare system and the transmitting phone also cannot verify that the person presenting the Contact ID is the one for whom it was initially transmitted to.
Please see the Formal simple payload specification page for full details