2

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" ?

Guillaume Lhermitte
  • 21
  • 3
  • I'm not saying this question is exactly a duplicate, but you really want to read the answers here: https://security.stackexchange.com/questions/1786/how-to-achieve-non-repudiation. The answer from Thomas Pornin tells you the technical means to achieve what you want to do. The answer from D.W. tells you it is more than just a technical issue. – D.H. May 30 '17 at 11:45

3 Answers3

2

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?

ISMSDEV
  • 3,272
  • 12
  • 22
  • He says the user can tell him: But I never owned such key. You generated, you signed it. And he is looking for a way how to proof the key was owned by the user. But as I am reading it again and again I am getting lost too :) – Fis May 30 '17 at 11:33
  • X509 certificates are the best way then (either publically CA signed or via a private PKI). I am not sure why he seems to be attempting to solve authentication issues that have already largely been solved within the industry? Maybe I have misunderstood the problem. – ISMSDEV May 30 '17 at 11:37
  • 1
    Yep. I am lost too :D – Fis May 30 '17 at 11:39
  • Nope, @Fis got it right. I want to avoid a user telling "But I never owned such key". Maybe X509 certs could be what I am looking for but as far as I know how it works I don't see it (I am ready to fully admit to my own ignorance). Gonna look it ut again. – Guillaume Lhermitte May 30 '17 at 13:06
  • With your update/edit you made to the OP I now say the answer is even more likely to be an X509 certificate in which you have a suitable process for enrolling the users on the system to prove they did (at one point in time) have access to that certificate (and therefore private key) – ISMSDEV May 30 '17 at 13:13
  • @ISMSDEV I mostly ask this out of sheer ignorance. Security is not my main field and is not the easiest one to dive into either ;) – Guillaume Lhermitte May 30 '17 at 13:14
1

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.

Community
  • 1
Serge Ballesta
  • 25,636
  • 4
  • 42
  • 84
0

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.

Lie Ryan
  • 31,089
  • 6
  • 68
  • 93