This example of an inner payload that is designed to work exclusively with the Herald envelope payload provides additional security and privacy guarantees over and above the Herald simple inner payload example.
Click here to View the Formal Specification for the Secured Payload
This payload was driven by two somewhat competing desires:-
The data we support for both is described in the following two sections. Later follows a detailed explanation of how the payload works.
DRAFT This is a draft payload description currently under review.
We wanted to support these extended contact tracing approaches:-
This places some restrictions on the outer payload:-
This also requires the inner payload to provide the following information:-
Privacy is an issue when an organisation can request, warrant, or extract the contact information from a health authority and identify the individual phones or users behind the ClientIDs passed during contact event sharing. I.e. knowing the identity between the ‘nodes’ on a contact graph.
Ideally we want to share a solid and verifiable contact graph with a national health authority without them knowing both sides of the contact graph, even if both sides declare themselves as ill and submites their contact information to the same health authority.
The way to do this is to provide edge information to the health authority, and a persistent but unregistered identifier (Node ID) for the contacts. The way to ensure that the exposure is a valid one and only acted upon is to verify the tokens shared between the two phones locally, and encrypted so only they know the content shared, and verifiable with secrets only stored in the secre enclave of each phone.
Basically we do this:-
Identity information is managed as follows:-
Below is a visual representation of what each phone and health authority knows:-
NOTE: Please see the Interoperability page on how the secured payload ensures security and privacy whilst working between multiple countries.
Confidentiality - Yes. Provided by encrypting all data between both phones, and from phones to health service, preventing interception, spoofing, relay and replay attacks. A one time use Diffie-Hellman-Merkle symmetric key agreement is used to encrypt the data. Uses phones’ built in secure enclave for storage of cryptographic material where provided.
Integrity - Yes. By using a TOTP code that the health authority can decrypt and an exposure confirmation token the transmitting phone can only decrypt, the transmitting phone knows that both phones and its health authority have all been involved in the exchange, and the data has been verified. Data cannot leak or be extracted and use by another device as the transmitting device checks the time and tokens it issued, ensuring integrity. Even if data passes via a health authority of a hostile state actor it cannot be manipulated to cause the exposure of incorrect or targetted individuals and groups of the originating country.
Availability - Yes. Bluetooth provides built in CRC checks of data, so by the time Herald sees the data it has already been validated. Supporting both read and write approaches to Bluetooth data exchange ensures the maximum support of mobile phones, as some phones can discover and read and write from others, but not be discoverable and readable/writable themselves (~35% of Android phones in the UK do not support advertising ).
Non-repudiation - Yes. The original transmitter can verify that the exposure token was from the exact phone they communicated with and that their data was decrypted and interpreted by their own health authority, and that the time of the contact is valid. All three participants (Transmitter, Receiver, Transmitter’s health authority) are authenticated in this approach. Authentication of the receivers health authority if left to the communication channel between those authorities.
Please see the Formal secured payload specification page for full details