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
1
$\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).

| improve this answer | |
$\endgroup$
0
$\begingroup$

All "deployment-grade" signature schemes on the market are only secure if they're secure under EUF-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.

| improve this answer | |
$\endgroup$
-1
$\begingroup$

This is a kind of blind signatures. Most of the context of blind signatures are unsecure, but there are few interesting use cases. For you case, Alice can just hash the random server challenge before signing and the server hashes as well the challenge during verification/authentication.

| improve this answer | |
$\endgroup$
  • $\begingroup$ This is not a blind signature. In this system, after issuing a signature, the signer can tell whether any candidate message was the message they just signed; in a blind signature scheme, the signer can't distinguish the message they just signed from any other message. $\endgroup$ – Squeamish Ossifrage Oct 24 '19 at 3:51
  • $\begingroup$ I'm using the blind signatures definition from here: medium.com/cryptium/… Of course, there's the blind signatures definition from David Chaum (a cryptographic primitive used for privacy on votes & payments): hit.bme.hu/~buttyan/courses/BMEVIHIM219/2009/… Blind signatures can even be used to decrypt RSA messages when the same key pair is used for both signing & encryption operations: en.wikipedia.org/wiki/… $\endgroup$ – Marco Aurélio da Silva Oct 24 '19 at 18:40

Your Answer

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