search

DP-3T / documents

Decentralized Privacy-Preserving Proximity Tracing -- Documents
2.24k stars 180 forks source link

Add basic pre-compromise security #251

Open Fiona-J-W opened 4 years ago

Fiona-J-W commented 4 years ago

As far as I can tell the current thread model does not cover attackers who get unauthorized access to a device. Let Alice be the device owner and Bob the Adversary. Once Bob learns SK_t, he can immediately recognize from the published list that it was Alice who was sick on day t. This attack can of course not reasonably be prevented once Bob has SK_t, but it would be easy to make it much harder for Bob to acquire SK_t:

Since the next party that may need SK_tis the health authority (HA) and only the HA, it seems very reasonable to encrypt SK_t with a public key of the health authority (Let c be the resulting ciphertext). Since Alice's device now only stores c, a compromise will not reveal SK_t, as long as Bob has not also received the secret key from the HA which would be much harder than getting access to only Alice's device.

Note that this strictly strengthens the security: In the worst case in which the secret key of the HA becomes fully public, we end up with the same scenario that we have right now anyways.

The computational overhead would essentially be negligible at one encryption per day on Alice's device and 14 decryptions (up to one per infectious day) per actual infected patient on the side of the HA.

The primary scenario in which this protection might come into play would be Alice and Bob living together (for example as a family) where Bob might either be able to get access to the device without Alice knowing or by compulsion.

lbarman commented 4 years ago

Hi @Florianjw, thanks for the input! This sound similar to https://github.com/DP-3T/documents/issues/251, if so could we move the discussion there ? Thanks

akuckartz commented 4 years ago

This sound similar to #251

@lbarman Yes, the current issue is 251... ;-)

lbarman commented 4 years ago

I see I can't fool you with these simple diversions ;)

Thanks, I meant "Securing the EphID Store" on https://github.com/DP-3T/documents/issues/63

Fiona-J-W commented 4 years ago

sorry, I had actually searched for such an issue, but did not find that one.

Fiona-J-W commented 4 years ago

Actually after reading the issue there entirely I feel that these are different enough to warrant two distinct issues: #63 is about securing the ephemeral tokens at possibly substantial computational cost; this one is about securing the actual seed at essentially negligible cost.

There is of course always another attack that one can defend against at the cost of more computational work and clearly a line that denotes an insufficient return of investment has to be drawn somewhere; given the comments on the other issue I don't feel qualified to judge on which side that suggestion lies, but I feel that the RoI of this is sufficiently different to be discussed independently.