1
$\begingroup$

First some background. I am building an application where people send each other emails with messages inside that need their sign-off. Once the participants receive the email they're also given a callback link (the link is generated by cc-ing an email address tied to our app server, and then the app sever sends all the participants an email back with a link). Users click on that link, gets taken to a site, where the site's frontend generates a pair of keys locally inside the browser's localstroage, and the user can either say yes or no to the message, while signing his response + message with the key. We then store the signatures, should there be disputes later on they can search and find who agreed / disagreed to what when.

We've accounted for when the user flushes the browser or the browser flushes itself. The secret key is encrypted with the user's password and stored on the server (like protonmail), so if the user still remembers the password the secret key can be recovered locally in the browser.

But the problem is that I would expect most people won't be using this on a regular basis, so they will likely forget the password or that this site even exists in the first place. This means that their signatures are essentially worthless since there's nothing tying those signatures to these user's identity if they forget and resets their password and gets a new key pair.

One bit of information I do know is the user's email address. When they click on the link to agree / reject the message I right away know they are the owner of a particular email address. Let's assume for a minute that they're not likely to lose access to the email. With that assumption, is there some way I can tie a signature to a user's identity, even after that user has lost the private key (he 99% isn't even aware what a key is or that he has one) and lost his password to our site? To prove that, "Yes, that was you and only you who signed this message 1 year ago". Somehow tie the user's ability to access a particular email address to a signature?

The reason to use signatures is that it is not fakeable. If we only used regular logins then an argument can be made that the app server can just make up whatever it wants. But now we're saddled with a new problem which is how to reliably tie that signature to a user's identity.

Any help / ideas would be greatly appreciated!!

$\endgroup$
  • $\begingroup$ The general case of this problem is not solvable. It's a well known limit of digital signing. However, sometimes you can make do. How do you verify the identity of a user when you first give them the password? The level of verification taken there says a great deal of how much verification you need to do on a forgotten password. Related: what is your threat model? Are you just trying to stop accidental mistakes, or are you trying to stop a hacker? $\endgroup$ – Cort Ammon May 19 at 22:07
  • $\begingroup$ The initial verification is access to email, which means email is effectively the proof of identity. However that association between email and identity is enforced by the app server, so I wanted something that cannot be faked by the server. I'm unsure if this is a "threat" issue (not a crypto expert), the problem is that different parties could dispute what happened. e.g., 3 people agreed on email message X, but then 1 month later 1 guy out of the 3 said "what? I never saw that, I don't remember ever agreeing to X. You falsified that email." The goal is to minimize potential disputes. $\endgroup$ – reedvoid May 19 at 23:39
  • $\begingroup$ So the server doing all of these things is not trusted either? in particular, can it be trusted to verify that indeed a number was provided to it (from the user) that was only known to the server and the owner of the email address? Or is that not trustable either? $\endgroup$ – Cort Ammon May 19 at 23:42
  • $\begingroup$ Well I am going with a rather strict definition where no one and nothing can be trusted. The different parties that may use this service have no reason to trust this app server other than providing simple convenience. I guess an analogy could be - do you trust a service like DocuSign? They can technically just fake everything on their servers, yet they are a listed company worth tends of billions. $\endgroup$ – reedvoid May 19 at 23:47
  • $\begingroup$ If noone and nothing can be trusted, a user who lost their keys has lost their keys, and that's the end of the story. However, in almost all cases, there's a system of trust in palce. DocuSign is indeed trusted because they design their audit logs to make it hard for them to mess up, and because they have a LOT on the line if they're caught forging. $\endgroup$ – Cort Ammon May 20 at 0:49
1
$\begingroup$

The easiest way to manage this sort of situation is to send people an email confirming that they signed a document. This is akin to the standard password reset pattern of "if this was not you, please notify us immediately."

If you try to make it stronger, you run into the issue that the server is the only party here that is verifying identity. It is the entity that is saying "this signature came from someone who can read XYZ's email address." If the server cannot be trusted, then there is no trustable entity verifying anything. And, given your situation, its unlikely the users themselves are adding any verification into the system.

One other tool you can use to build up trust is to use a blockchain like approach for the records. When people sign contracts, they also sign the chain of contracts. That would make it much harder to forge a single signature from years ago without invalidating every other signature in that time. You could also require the users to review recent signatures, building more belief into the blockchain.

But in general, if you're not going to take the time to build in a full identification system (which involves an in-person meeting), then the strength of your system is built on its auditing, not in its initial signing algorithm.

| improve this answer | |
$\endgroup$
  • $\begingroup$ Thanks this is very helpful. This has been wracking around in my head for so many days and in the end, if the individual users aren't going to take the responsibility of maintaining their own keys and need to rely on a service to provide convenience, you end up sacrificing "trustless-ness" and is forced to trust someone / something / some company. $\endgroup$ – reedvoid May 20 at 1:22

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.