How to prove a user is actually the perpetrator of certain actions?

Question

TL;DR : What is the best and most "by the book" way to accheive non repudiation of origin.

I have a system in which users can perform actions (register/unregister/...)

Those actions are signed by my users with private keys they own. They also save their public keys in their profile.

What prevents a user to tell me that I made actions in h{is,er} name, pretending that they don't know that "public/private key thingy" (in case they are malicious).

Thing is I will never be able to prove that they DID own the private key. They could throw it away (or just never disclose it).

I thought i could ask them a question that

• only them know
• is hard to guess
• easy to verify

But I can't seem to find out what question that could be.

I thought I could ask for a photo of their Id/Driver Licence taken in front of an app-generated image on their screen. But is it "proof enough" ?

Answer 1

Not sure I totally see the problem. Are you concerned that a user could claim you used their private key because you have access to all users keys?

Private keys should ideally be stored one for each user and not in the system itself. I don't know the ins and outs of your system, but could you not get each operation to require the user to attach their private key to complete the operation (this could even by handled client side in some sitations so you can maintain a true 'Trust No One' approach)

If you are concerned users will claim they never owned the private key can't you make a step in the operations to require proof of private key. Such as requiring the users to decrypt something your system encrypts using the public keys?

Answer 2

That is an interesting question, but it can be read at 2 different levels.

1. How can I prove that the owner of that key/X509 certificate is M. X?

   Well you cannot... unless you have procedures that prove it. For example for x509 user certificates, there is often a face to face operation where the signer controls the identity of the recipient, and has him manually sign a document claiming that he received a certificate for a key he (and only he) owns from Y the day of month, year. Now you can prove (even to a legal court) that the owner of the key of the cert is M. X . But this assumes that you cannot know the key.

2. What can the admin. of a system do on a key file?

   Unfortunately plenty of things! A admin can rewrite the file, put a new key in it, change the dates (access, modification and creation) of the file. The only thing that an admin cannot do is to read the content of an encrypted file if the secret is not in the system.

That means that if you want to be able to prove that a user is the perpetrator of an action, you will have to setup a procedure that guarantees that you cannot know the private key, but know the public key (x509 certificates can be a nice solution). But the key should never exist in decrypted form on your machine, because you as the admin could get it even from a process memory, or via system call hooks.

That is the reason why it is often said that a user should not use a machine he does not trust, and he cannot trust a machine if he cannot trust the administrator. Said differently, you will never find a purely technical way to prove that a user did perpetrate an action if the key lies in a disk on which you have administrator priviledges. The solution here is legal and not technical. The only technical way requires that the key is only installed on the user's machine and not on yours.

---

BTW the secret question way is also a dead end. The user could say: yes I did answer this to that question, but it was about that other action... Once he has given the secret answer to you, the secret is no longer his own but is shared between him and you.

Answer 3

There isn't a purely technical solution to this. Non-repudiation is a legal matter, so you need a combination of technical and non technical measures to enforce non-repudiation.

The primary technical measure is to use asymmetric cryptography, as you've mentioned. But technical measures is not sufficient for non-repudiation.

The non technical measure needed is user training of how asymmetric cryptography works and how it's used in the system to achieve non repudiation and a contract signed by the user that they've understood the training materials and that any misuse of their private key would be their responsibility. What this allows you to do is block the user from pleading ignorance of the technical measures. The contract should allow you to at least charge the user for gross negligence if they have used the key in manners that would've been obviously forbidden by the training material or if they leaked their private key, deliberately or not, and they'd also make it easier for you to prove malice as you have a record of the user's knowledge and can more easily prove many actions could not have been done without deliberate malicious intent.