heyitsmass / bequest-interview-question-1

Tamper Proof Data

At Bequest, we require that important user data is tamper proof. Otherwise, our system can incorrectly distribute assets if our internal database is breached. Only the user is able to update their own data. There are 2 parties that read the data, the user and our server.

How does the client insure that the data has not been tampered with?
If the data has been tampered with, how can the client recover the lost data?

** See development branch **

Proof of concept implementation, crypto.webcrypto.SubtleCrypto shouldn't really be used for this purpose and would be converted to a more cryptographically secure library.

A) We need to create a way to verify and sign data that ensures it's coming from both the server and client

• To do this, we'll start by creating an assymetric RSA key for both the client and the server. We then generate an RSA-PSS key to sign the data as the server.
• We'll share the client's public key with the server, using it to encrypt a symmetric AES key and signature shared between the two
• We encrypt the AES key and the signature with the client's public key, sending it back at which time the client saves it and the connection has been secured.
  • If the server has a static encryption key then we can save the signature and assume for future connections, this is the expected server signature.
• Anytime data comes from the server, it's encrypted with the shared AES key and signed with the server's private RSA key
• We can verify the data is coming from a trusted server using the signature
• From here we'll check the hash signature of the data. If the data has been tampered with, Data on the client won't match the hash signature of data provided by the server.
• This implies the data has been tampered with on the server, in which case we will assume the data stored on the client is the expected data.

B) In the event the data has been tampered with, We'll keep a redundant copy on the client's localStorage.

• To do this, Whenever the client sends data to the server.

• Upon sending it to the server, assuming the client signature matches and decryption is successful, the server will update the values in the database.

• Once the data has been updated on the server, we store the hash and a redundant copy of the data in localStorage.

• This ensures we assume the data on the server has always been tamepered with and only the data on the client's local side is data we take for certain.

  • This has limitations, the 5MB limit of the browsers localStorage prevents us from storing any additional variables.
  • A potential solution is to store the encrypted data on the server. Once the client connects, only they provide the key to decrypt it upon secure connection. If the data is at rest, it doesn't need to be visible in plaintext on the server. If the client is connected, the server can then decrypt the data using the shared symmetric key at which time the data is viable for transit.

• This has it's own problems! If the client deletes their localStorage, we lose the data! We can try to circumvent this by requesting persistent storage from the user.

To run the apps:

npm run start in both the frontend and backend