Proof of at-risk status

[bdsl]

When someone gets a notification of their at-risk status, should they be able to prove to a third party that they have been identified as at-risk? e.g. to get testing, time away from work, or priority for home deliveries of supplies?

If so, does the protocol allow that?

If not, what's the threat from someone who tries to do it anyway?

[jasisz]

If what was published was ephids at risk (#14 might be in form of Bloom filters) - they would be able to prove that given at risk ephid was theirs, by using their sk_t private key.
I do not think this is possible now.

[maskeeter]

i think an additional digital certificate issued by the backend for this specific EphID of at-risk user and can be verified by the health authorities can work as a proof.

[bdsl]

But proof of what proposition? The back-end doesn't know user's names or biometrics, so it can't be proof that the person called John Smith who is 167cm tall and has a certain fingerprint is at-risk. It sounds like just proof that a person was identified as at risk at a certain time, but that has no information value.

So then presumably the proof isn't just the existence of the certificate, but the bearing of it - the proposition is that the person who presented this certificate was at risk of having coronavirus, which seems easy to subvert by passing the cert to someone else for them to present as if it was theirs. The certificate would effectively be a bearer instrument.

[bdsl]

By the way I didn't raise this issue just to suggest there should be a way to make this proof - I expect there are trade off for and against, but I would leave it mostly to people who's job it is to think about such things to work out exactly what they are. If someone is able to prove something, then potentially they can be compelled to prove it, reducing their privacy. That's part of why electoral systems try to ensure people can't prove that they voted one way or the other.

[snakehand]

Part of a proof might be to at regular intervalls the client makes a hash of all collected ephids, and sends the hash to be timestamped and signed by a trusted server. Then if a SK is published after the signing, the user can prove that the collected records have not been tampered with.

Edit : A hash tree can be a better solution, since only a small portion of the recored ephids needs to be revealed in order to prove that it was recorded.

[maskeeter]

@bdsl there are more than one way to use digital certificates as a registered instrument, the backend server doesn't need to know the biometrics of the person. within in the system boundaries, the person is Identified by EphID (to others) and by SK (to backend), using the decentralized nature of the system the healthcare authorities can validate everything the rest. the user's role in this is only to give consent to transfer "necessary" information from one entity to the other without being able to control or manipulate the content.

Using something like electronic seals that contains a document part to confirm the identity of the person (from backend perspective) and a valid seal to confirm his health-status can be enough to avoid most of the edge cases.

This can be elaborated with the following example:

• healthcare authority identify and test user, outside the system boundaries.
• In case of found infected, user reports infected to the application, backend server responds with encrypted/hashed form of user SK.
• user is directed to communicate to healthcare authorities, which issues an electronic seal to confirm positive test, the seal is generated by and attached to the encrypted SK.
• user sends the digital document received from healthcare authorities to backend server which does two things:
  • validates the authenticity and integrity of the seal which means that it was issued by the correct legal entity and was not changed (there are many ways to achieve that beyond the scope of this conversation).
  • decrypts the document part and verify that the SK is the same as sender's SK which means that it was not copied or published by a different person.

even if another person gives the healthcare authorities a fake or copied key and they issue him an infection digital seal, the backend will invalidate it because it will not match his own SK. Also healthcare authorities will not be able to match the physical identity of the user to his SK since they receive it in an encrypted form.

[lbarman]

Thank you all for your inputs !
As pointed out, only the health authorities can provide a "meaningful" proof (as in "John Smith is sick"), the backend knows no identities. Therefore, signatures/commitments will not solve the problem here, as two hackers (one infected and one not) can easily swap any credentials. This could be mitigated if we used TEEs on the phones.

Since solutions need to involve user identification and health authorities, this issue seems best solved outside the system (by keeping the diagnostic sheet the health authorities will give you).

Would this answer the question ?
Thanks