En SSL / TLS , el cliente utiliza la clave pública del servidor. Como en general el cliente no conoce la clave pública del servidor por adelantado, espera obtenerla a través de la magia de Infraestructura de clave pública : la clave pública del servidor se presentará en un certificado y el cliente podrá verificar que:
- el contenido del certificado es genuino (eso es validation : las firmas y los nombres y las extensiones de certificado son correctos y se vinculan a una raíz confiable);
- el certificado es propiedad del servidor deseado (el nombre del servidor esperado aparece en la extensión
Subject Alt Name del certificado, o su nombre común si no hay una extensión SAN).
Ahora, todo esto es una complicación innecesaria si el cliente ya conoce la clave pública; Si se conoce esa clave a priori , entonces el cliente solo puede usarla y simplemente ignorar el certificado enviado por el servidor.
En aras de la compatibilidad con la especificación formal del protocolo, y para reutilizar más fácilmente las bibliotecas y la implementación existentes, probablemente sea incluso más sencillo hacer lo que sugiere, es decir, verificar que el certificado del servidor es bit a bit. certificado esperado, y deje que el código extraiga la clave pública de eso. La "huella digital", si se calcula con una función hash que es resistente a las segundas preimágenes (por ejemplo, SHA-1), puede usarse para esa verificación. Esto está bien.
En su caso, entiendo que el servidor es el dispositivo , y el cliente es su aplicación. Su aplicación no se dejará engañar (hablar con un dispositivo falso) solo mientras el atacante no haya comprometido la clave privada del dispositivo, es decir, la haya extraído de un dispositivo. Si tiene varios dispositivos, entonces cada dispositivo debe tener su propio par de claves privada / pública. Si todos los dispositivos tienen el mismo par de claves, entonces la clave privada no puede considerarse "privada": un secreto que conocen más de dos o tres personas no es un secreto, sino un rumor.
La forma "segura" es tener algún tipo de fase de inicialización, en condiciones controladas, donde la instancia de la aplicación aprende las huellas digitales de los dispositivos a los que se conectará posteriormente (tal vez la aplicación genere los pares de claves públicas / privadas y los certificados autofirmados, y los importa en los dispositivos).
Este es el modelo de seguridad utilizado en SSH : la primera conexión de un cliente a un servidor determinado requiere una confirmación explícita (el cliente muestra la huella digital de la clave pública del servidor y se supone que el usuario humano debe verificarla, por ejemplo, llamando al administrador del servidor); después, el cliente confía en esa clave pública porque recuerda la huella digital.
El modelo "recordar la clave" funciona bien, pero debe tener en cuenta que pierde la característica PKI conocida como revocación : un mecanismo automático fuera de banda para transmitir información de contención de daños. Si la clave privada de uno de los dispositivos se ve comprometida, el ladrón puede ejecutar un dispositivo falso y engañar a su aplicación para que se conecte a él; para evitar que esta situación persista, se debe advertir de alguna manera a la aplicación que ya no se debe aceptar una huella digital de un certificado determinado. Las verificaciones de revocación, con respuestas de CRL u OCSP publicadas regularmente, son un método automático para hacerlo. Cuando haya recordado las huellas dactilares, no hay PKI, por lo tanto no hay CRL. Pero la necesidad puede seguir ahí.
Si sigue la ruta sin PKI, con las huellas digitales de los certificados incrustados, debe decidir si necesita algo para garantizar el trabajo que normalmente realiza la CRL.