Decentralised storage for the contacts log of general user

[PangKung2018]

The contact tracking log(list of pairs key)of general user would be stored in local device. The application regularly upload the data and match the local contact log with the contact log of diagnosed cases in centralised DB but no need to the store the general data in centralised server.

[cskeogh]

Note: the encounter tokens are stored in browser localStorage in #21

[JakeBrown]

In a security-by-design implementation we should be concerned about what data is stored, and whether it is encrypted or not.

If encounter tokens are stored in plan text then one potential vulnerability is for an attacker to (1) steal two phones and (2) read the locally stored encounter tokens on both to see if there is a match.

We can overcome this by using asymmetric encryption. The back-end broadcasts a public key, and the front-end uses this to encrypt the encounter token before storing it. We should encrypt it with some random data (i.e. salt) to ensure that no two encounter tokens are identical once encrypted.

[cskeogh]

And to enhance the security further, the back-end sends a unique public key to each front-end, and the server deletes the public key. The only person/system that can decrypt is the server and strictly only when the front-end consents by providing the unique public key back to server.

[JakeBrown]

@cskeogh is my understanding here correct?

• Server generates a key-pair
• Stores the private key
• Gives the public key to the client then deletes it

[cskeogh]

@cskeogh is my understanding here correct?

* Server generates a key-pair

* Stores the private key

* Gives the public key to the client then deletes it

Yes. Using RSA, strictly it doesn't matter if the server deletes the server's public key or not. The server can only decrypt when the client provides their public keys anyways. (Client public keys will be provided with the upload table.)