Autentificación de clave pública: ¿qué se firma?

Consulta RFC 4252 sobre el protocolo de autenticación SSH , que se encuentra en la sección 7 (en las páginas 8 y 9) :

  

Para realizar la autenticación real, el cliente PUEDE enviar una firma generada utilizando la clave privada ... La firma se envía utilizando el siguiente paquete:

 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

Eso ya lo sabías, más o menos, pero en realidad no hemos descubierto qué contiene el campo de cadena final signature . La sección que sigue inmediatamente en realidad responde a su pregunta:

  

El valor de 'firma' es una firma de la clave privada correspondiente en los siguientes datos, en el siguiente orden:

 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

Al consultar las secciones 1, 5 y 6, podemos entender el significado de estos valores:

• el identificador de sesión (un valor por conexión obtenido antes del protocolo de autenticación del cliente),

• el nombre de usuario utilizado por el cliente,

• el nombre del servicio que se solicita (aquí, " ssh-userauth "),

• la clave pública del cliente, y

• algunos valores estáticos ( "publickey" , TRUE , SSH_MSG_USERAUTH_REQUEST (que es el valor 50 )).

  

Mi pregunta es qué tipo de mensaje se usa en la vida real, junto con   ¿Tu clave privada, para generar la firma digital?

El mensaje puede ser cualquier cosa, realmente no importa.

  

... una vez que el servidor aplica su clave pública para generar el original   mensaje, ¿cómo sabe si ese mensaje es correcto? Es el   mensaje público disponible?

El propósito de una firma digital es garantizar:

• Autenticidad del remitente
• Validez del mensaje

Podemos hacer esto generando un HMAC (tecleado con nuestra clave privada) y enviándolo junto con el mensaje original.

El uso del PK aquí proporciona no repudio porque solo la clave pública correspondiente puede descifrar el MAC por lo tanto, sabemos que al menos quien envió el mensaje tiene acceso a la clave privada ( nota: tenemos No hay forma de saber si el PK ha sido comprometido, solo podemos asumir que el remitente es quien dice que está basado en que tienen acceso al PK )

Una vez descifrados, generaríamos un MAC del mensaje original, lo compararemos con el MAC descifrado y, si coinciden, sabemos que el mensaje no ha sido manipulado y por lo tanto es válido.

  

... ¿el servidor envía un uso único?   Mensaje para que cree la firma digital utilizando su   clave privada?

Para que el cliente genere una firma digital, debe conocerla. PK: la forma en que el PK se entrega al cliente depende completamente de usted (certificado del cliente, OTP, entrega en mano, etc.).

La clave para hacer que una firma no sea reutilizable (mensaje de una sola vez) es utilizar un nonce . El tipo de nonce que usa depende de la vida útil que desea que tenga su mensaje. Por ejemplo, los nonces basados en el tiempo se pueden usar para proporcionar una ventana de tiempo en la que se deben usar los mensajes; esto es útil en escenarios donde las solicitudes pueden tardar un tiempo considerable en completarse (las solicitudes de OAuth son un buen ejemplo)

En resumen, lo único que se requiere para generar una firma digital es una clave & un mensaje. La clave en sí puede ser cualquier cosa (GUID, número aleatorio, etc.) siempre y cuando se mantenga segura y solo sea conocida por los remitentes autorizados. El contenido del mensaje solo es relevante para garantizar la integridad de los datos, no ayuda a aclarar quién envió el mensaje, las claves privadas / públicas se utilizan para esto.