2

I've just started reading about SSH and how it's used for authentication. From this website, it says:

The private key is able to generate signatures. A signature created using your private key cannot be forged by anybody who does not have that key; but anybody who has your public key can verify that a particular signature is genuine.

So you generate a key pair on your own computer, and you copy the public key to the server. Then, when the server asks you to prove who you are, PuTTY can generate a signature using your private key. The server can verify that signature (since it has your public key) and allow you to log in. Now if the server is hacked or spoofed, the attacker does not gain your private key or password; they only gain one signature. And signatures cannot be re-used, so they have gained nothing.

My question is what kind of message is used in real life, along with your private key, to generate the digital signature? And once the server applies its public key to generate the original message, how does it know whether that message is correct? Is the message publicly available?

Or when you try to connect, does the server send out a one-time-use message for you to create the digital signature from using your private key?

4

Consulting RFC 4252 on the SSH authentication protocol, we find in section 7 (on pages 8 and 9):

To perform actual authentication, the client MAY then send a signature generated using the private key... The signature is sent using the following packet:

 byte      SSH_MSG_USERAUTH_REQUEST
 string    user name
 string    service name
 string    "publickey"
 boolean   TRUE
 string    public key algorithm name
 string    public key to be used for authentication
 string    signature

That much you knew already, more or less, but we haven't actually found out what the final string field signature contains. The section immediately following actually answers your question:

The value of 'signature' is a signature by the corresponding private key over the following data, in the following order:

 string    session identifier
 byte      SSH_MSG_USERAUTH_REQUEST
 string    user name
 string    service name
 string    "publickey"
 boolean   TRUE
 string    public key algorithm name
 string    public key to be used for authentication

By consulting sections 1, 5, and 6, we can understand the meaning of these values:

  • the session identifier (a per-connection value obtained prior to the client authentication protocol),

  • the username used by the client,

  • the name of the service being requested (here, "ssh-userauth"),

  • the client's public key, and

  • some static values ("publickey", TRUE, SSH_MSG_USERAUTH_REQUEST (which is the value 50)).

  • Thanks! For clarification, what does "a signature by the corresponding private key over the following data" mean precisely? Does it mean you are encrypting the following data using the private key? – shimizu Dec 31 '14 at 22:07
  • To be exact, SSH (like nearly everything else) uses hybrid cryptography; the public-key signature, such as RSA, is computed on a hash of the signed data. And even for RSA it's inaccurate to describe signature as 'encrypting with private key'; it is partly similar but NOT the same, and for other signature algorithms (DSA and ECDSA) it's totally meaningless. – dave_thompson_085 Jan 4 '15 at 0:12
  • @shimizu "[generating] a signature by the corresponding private key over the following data" means "signing the following data using the private key that corresponds to the public key being sent." As mentioned above, you don't encrypt with a private key, you sign with a private key. (Also as mentioned above, signing is generally only practical over hashes, not whole data, so you'll really just sign the hash, and send { data, Sign(Hash(data)) }. The recipient can compute Hash(data) and verify that the signature applies to data.) – apsillers Jan 4 '15 at 2:24
4

My question is what kind of message is used in real life, along with your private key, to generate the digital signature?

The message can be anything, it doesn't really matter.

...once the server applies its public key to generate the original message, how does it know whether that message is correct? Is the message publicly available?

The purpose of a digital signature is to ensure:

  • Authenticity of the sender
  • Validity of the message

We can do this by generating a HMAC (keyed using our private key) and sending this along with the original message.

The use of the PK here provides non-repudiation because only the corresponding public key can decrypt the MAC therefore we know at least whoever sent the message has access to the private key (note - we have no way of knowing whether the PK has been compromised, we can only assume the sender is who they say they are based on them having access to the PK)

Once decrypted, we would generate a MAC of the original message, compare that to the decrypted MAC and if they match we know the message hasn't been tampered with and is therefore valid.

...does the server send out a one-time-use message for you to create the digital signature from using your private key?

In order for the client to generate a digital signature it requires knowledge of it's PK - how that PK is delivered to the client is completely up to you (client certificate, OTP, hand delivered etc.).

The key to making a signature non-reusable (one-time-message) is to use a nonce. The type of nonce you use depends on the lifespan you want your message to have. For example, time-based nonces can be used to provide a time window in which messages must be used - this is useful in scenarios where requests may take a considerable amount of time to complete (OAuth requests are a good example)

In summary, the only thing required to generate a digital signature is a key & a message. The key itself can be anything (GUID, random number etc.) just as long as it's kept secure and only known by authorised senders. The content of the message is only relevant in ensuring the integrity of the data, it doesn't help clarify who sent the message, the private/public keys are used for this.

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.