Non-repudiation of customer data

Question

For our web application we are maintaining some data, pertaining to our subscribers, on our server. Some of this data is sensitive and we would like to implement some "security measures" for this data. One is encryption, and we know how to do that. The other is non-repudiation of the content, and we don't know how to implement that.

Specifically we would like to handle the following use case. On day X customer stores some data on our server. On day Y they claim that the data was not stored by them (and implying that someone else stored the data). How can we guard against that kind of repudiation challenge from a customer?

Can we use some kind of hash or something? Keep in mind that customers may occasionally forget their passwords, and passwords may have to be regenerated upon customer request.

Answer 1

It should be enough to make user application calculate hash of her data, sign it with hers private key and store those signature in your log. Then, if users denies ownership of the data, you can calculate hash on your own and compare it to users hash, decrypted with his public key. If they match, it would be possible only because user signed (and owned) the data. User can recalculate hash and sign it again with his private key, to verify if stored signature was hers.

Obviously, it would require managing public keys of users on your side, and users would have to securely store their private keys. Moreover user may claim, that hash in the log is not hers and refuse to recalculate it (or he may lose his private key). If you can't transfer such issues to the customer (i.e. within contract), probably it would be necessary to involve third party (to manage logs and assure their integrity).

You may want also consider using some implementation of blockchain to store log - it's distributed nature may help holding their integrity.

Answer 2

You will soon have a question of trust.

On most countries, legal non repudiation requires a digital signature using a certificate that has been at any time under the exclusive control of its owner. Concrete solutions commonly use smartcard certificate and an explicit procedure for face to face delivery from a trusted third party.

From that point, any information that is digitaly signed but that certificate is assumed to have been issued by them, unless they can prove that they could not possibly do it.

Unfortunately, most casual users either have no such smartcard certificate, or do not know how to use it to sign a document. And it is not easy to use it from a web application because the smartcard certificate can only be used client side, which implies a Javascript code able to find it.

A simpler (but far less secure) alternative way is to use a standard authentication procedure, and let the application add a digital signature including the data, the user id and a timestamp. That is enough to prove that the data was not altered after being written and is a serious hint that it was written by a specific user. The main difference it that the security zone includes the system and all its admins. Said differently, if your users do trust your organization, it can be enough. It can be used for example in internal corporate systems. But if your users are your customers, you could be complicated. It is up to you to decide whether you can accept that risk or not.