2
$\begingroup$

With regards to user authentication...

  • The server sends Alice a randomly chosen number.
  • Alice signs the number and sends the signature back to the server.
  • The server checks the signature using Alice's public key. If it's valid, the server accepts her connection request.

Suppose that Alice uses the same private key to log in to the server and sign her emails. The authentication mechanism signs the bare challenge without hashing, while Alice signs the hash of the email message.

Apparently, the server can forge emails from Alice under this scheme? If so, how could this be prevented?

$\endgroup$
  • 1
    $\begingroup$ Hint; check the e-mail and the random number signatures. Wellcome here. Apparently, this seems homework. Please clarify that. $\endgroup$ – kelalaka Nov 2 '18 at 9:12
  • $\begingroup$ There's yet another problem - if Alice doesn't authenticate the server, then anyone can query Alice's signing oracle. This is probably not our concern here. $\endgroup$ – DannyNiu Nov 2 '18 at 9:31
  • $\begingroup$ All "deployment-grade" signature schemes on the market are only secure under UUF-CMA - which means you have to somehow prevent the server from querying the signature of hashes of your messages. $\endgroup$ – DannyNiu Nov 2 '18 at 9:40
0
$\begingroup$

All "deployment-grade" signature schemes on the market are only secure under UUF-CMA - which means you have to somehow prevent the server from querying the signature of hashes of your messages.

One way to do that, is that make sure the hash of your messages are of different length than the challenges (prepending/appending to challenge/hash some fixed/randomized string).

Another way is to devise a more secure handshake protocol - sign a (ephemeral) key exchange publickey to use with the server.

$\endgroup$
0
$\begingroup$

Regardless of the possible answers here, which probably focus on some technical difference between the signature scheme for authentication vs the signature scheme for non-repudiation, the practical way to prevent this is to have at least two key pairs for the different use cases.

Alice would have a private key and matching certificate to perform the authentication. Preferably she would even have multiple ones for each use case, with access conditions matching the use case. Although this scheme uses signatures, it uses them just to authenticate Alice at a particular time and the signatures do not need to last.

Alice would have another private key and matching certificate to perform the signatures for non-repudiation. Non-repudiation is used for documents to show that a specific person has signed it; that person nor others cannot repute the signature: it must have been set by somebody who has access to the private key. These signatures are stored with the document so that they can be accessed later.

The private keys for non-repudiation generally need higher security than those for authentication. Signatures are stored, so the key size needs to be future proof. This difference is reflected in the certificate, which may for instance have to adhere to an established Certificate Practice Statement to be accepted - a self signed certificate created on your computer cannot be used to buy a house.

Old style Government ID cards commonly have three private keys and matching certificates on them: one key for authentication (to the OS, TLS or applications), one key for non-repudiation (a digital signature to replace the written signature you are used to) and one for decryption (to keep messages send to you confidential).

$\endgroup$

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.