Autenticazione con chiave pubblica: cosa viene firmato?

Consulenza RFC 4252 sul protocollo di autenticazione SSH , che troviamo nella sezione 7 (alle pagine 8 e 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

Questo lo sapevi già, più o meno, ma non abbiamo in realtà scoperto cosa contiene il campo di stringa finale signature . La sezione che segue immediatamente risponde alla tua domanda:

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

Consultando le sezioni 1, 5 e 6, possiamo capire il significato di questi valori:

• l'identificatore di sessione (un valore per connessione ottenuto prima del protocollo di autenticazione del client),

• il nome utente utilizzato dal client,

• il nome del servizio richiesto (qui " ssh-userauth "),

• la chiave pubblica del client e

• alcuni valori statici ( "publickey" , TRUE , SSH_MSG_USERAUTH_REQUEST (che è il valore 50 )).

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

Il messaggio può essere qualsiasi cosa, non ha molta importanza.

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

Lo scopo di una firma digitale è garantire:

• Autenticità del mittente
• Validità del messaggio

Possiamo farlo generando un HMAC (con chiave utilizzando la nostra chiave privata) e inviando questo insieme con il messaggio originale.

L'uso del PK qui fornisce non-ripudio perché solo la corrispondente chiave pubblica può decifrare il MAC quindi sappiamo che almeno chiunque abbia inviato il messaggio ha accesso alla chiave privata ( note - abbiamo non c'è modo di sapere se il PK è stato compromesso, possiamo solo supporre che il mittente sia chi dice di essere basato su di essi che ha accesso al PK )

Una volta decifrato, genereremmo un MAC del messaggio originale, confrontiamolo con il MAC decrittografato e, se corrispondono, sappiamo che il messaggio non è stato manomesso ed è quindi valido.

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

Affinché il client generi una firma digitale richiede conoscenza del suo PK - in che modo il PK viene consegnato al cliente è completamente a te (certificato del cliente, OTP, consegnato a mano ecc.).

La chiave per rendere una firma non riutilizzabile (messaggio singolo) consiste nell'utilizzare un nonce . Il tipo di nonce che usi dipende dalla durata della vita che vuoi che il tuo messaggio abbia. Ad esempio, i nonces basati sul tempo possono essere utilizzati per fornire una finestra temporale in cui devono essere utilizzati i messaggi - questo è utile in scenari in cui le richieste possono richiedere molto tempo per essere completate (le richieste di OAuth sono un buon esempio)

In sintesi, l'unica cosa necessaria per generare una firma digitale è una chiave & un messaggio. La chiave stessa può essere qualsiasi cosa (GUID, numero casuale ecc.) Purché sia mantenuta sicura e conosciuta solo dai mittenti autorizzati. Il contenuto del messaggio è rilevante solo per garantire l'integrità dei dati, non aiuta a chiarire chi ha inviato il messaggio, le chiavi private / pubbliche sono utilizzate per questo.