Intercambio de claves con una parte no confiable

  

Este esquema, sin embargo, no trata el hecho de que el agente no está seguro contra ataques físicos, en cuyo caso, las claves públicas / privadas serían robadas del agente. Entonces, cualquiera podría imitar al agente y enviar solicitudes de registro con las claves robadas.

Si el atacante tiene acceso físico a la computadora del agente, el atacante puede operar la computadora del agente y enviar cualquier solicitud en su identidad.

  

¿Hay alguna forma, sin saberlo, de la comunicación, de que la parte es el agente, sin almacenar las claves criptográficas en el agente localmente?

Bueno, aún debe usar claves criptográficas para protegerse contra ataques virtuales, pero puede haber otras soluciones que se puedan usar además de la criptografía.

Algunas ideas que vienen a la mente.

1. Puede requerir que la conexión se origine desde una dirección IP específica que solo está disponible conectándose al cable de red en la estación del Agente. De esta manera, el atacante tendría que falsificar solicitudes en el sitio y no podría simplemente copiar las claves para su uso posterior en otro lugar.

2. Dependiendo de su computadora del Agente, es posible que los ataques requieran la interrupción del sistema operativo para acceder a los datos internos. Si ese es un componente necesario del ataque, entonces puede usar un canal de comunicación continuo para detectar cuándo se termina el sistema operativo. El servidor puede asumir que es un ataque (sin saberlo) y las credenciales pueden ser descalificadas.

   La anulación del administrador se puede usar para indicar que la interrupción fue un problema técnico (como un problema de conexión a Internet o reinicio del enrutador) en lugar de un ataque, en cuyo caso las credenciales se pueden calificar nuevamente.

3. Use un dispositivo de contraseña de un solo uso separado que el usuario tenga en su poder. YubiKey o GAuthenticator son posibles implementaciones de esto. Esto no es una bala de plata, pero haría más difícil que un atacante falsifique una solicitud, ya que tendría que instalar un programa que espera y, finalmente, hace uso de la Contraseña de un solo uso. Su servidor puede aplicar la prevención de Replay Attack para que el atacante sea menos invisible.

Nuevamente, sus opciones están limitadas cuando el atacante tiene acceso físico a la máquina, pero tal vez esto ayude. ¡Bienvenido a Security Stack Exchange!

La criptografía es la única forma en que se puede establecer ese tipo de confianza, y si eso se quita, no queda nada. Podrías pararte físicamente en la computadora del agente, pero has dicho que esa computadora podría haber sido pirateada, por lo que eso no probaría nada.

Tendrá que hacer algo diferente para evitar poner toda su confianza en la computadora del agente. Considere separar las llaves de la máquina. Podría darle al agente una tarjeta inteligente con las llaves. El agente insertaría las llaves en la computadora solo cuando las esté utilizando, pero las guardará en su bolsillo cuando no las use.

También puede usar un Módulo de seguridad de hardware (HSM) en la computadora del agente y requerir que el agente use algo como la autenticación de dos factores para acceder a las claves para iniciar la comunicación con el servidor.

  

¿Hay alguna forma, sin saberlo, de la comunicación, de que la parte es el agente, sin almacenar las claves criptográficas en el agente localmente?

Bueno, si el agente tiene que usar el secreto para autenticarse en el servidor, entonces el agente debe tener algún tipo de acceso al secreto en el momento de la autenticación, y es vulnerable a los ataques de suplantación de identidad en menos durante ese lapso. Entonces es realmente una pregunta de cómo podemos:

1. Minimice el formulario del acceso del agente al secreto;
2. Minimice el intervalo de tiempo para que el secreto también esté disponible.

Una técnica para hacer el # 1 es darle al agente un módulo de seguridad de hardware - un módulo de hardware aislado y reforzado que genera y almacena claves, pero que no permite que los secretos escapen de él. En este caso, el agente no puede ver realmente las claves secretas; todo lo que puede hacer es enviar datos al HSM y solicitarle que realice operaciones con las claves almacenadas.

Una búsqueda rápida de "Módulo de seguridad de hardware de Raspberry Pi" muestra algunos enlaces, que es posible que desee leer. ( Este es el que me parece más interesante, personalmente). es posible que también desee buscar información sobre la interfaz de Raspberry Pi con tarjetas inteligentes o dispositivos como Yubikeys, que también son procesadores criptográficos externos.

Una técnica para # 2 es proteger el secreto de autenticación primario del agente con un segundo secreto o factor, externo al agente. Una solución podría ser:

1. Proteja con contraseña la clave de autenticación del agente, por ejemplo, mediante el cifrado basado en contraseña;
2. Tenga mucho cuidado de que el agente no almacene ninguna copia de contraseña o secreto de larga duración; Bórrelos inmediatamente de la memoria en cuanto haya terminado con ellos.

El inconveniente aquí es que cuando se requiere autenticación, el usuario debe ingresar la contraseña.

Para una aplicación real de estas ideas, considere Guía de seguridad de iOS de Apple . Las llaves maestras del teléfono o tableta viven dentro del "Enclave seguro" (un HSM):

  

El Enclave seguro es un coprocesador fabricado en el procesador A-series de Apple A7 o posterior. Utiliza memoria cifrada e incluye un generador de números aleatorios de hardware. El enclave seguro proporciona todas las operaciones criptográficas para la administración de claves de protección de datos y mantiene la integridad de la protección de datos incluso si el núcleo ha sido comprometido. La comunicación entre el Enclave seguro y el procesador de la aplicación se aísla en un buzón controlado por interrupciones y en buffers de datos de memoria compartida. [pag. 7]

Cuando el teléfono está bloqueado, descarta o encripta las claves maestras para que las aplicaciones no puedan realizar operaciones con ellas:

  

Si Touch ID está desactivado, cuando un dispositivo se bloquea, las claves de la clase de protección de datos completada, que se guardan en el enclave seguro, se descartan. Los archivos y elementos de llavero en esa clase son inaccesibles hasta que el usuario desbloquee el dispositivo ingresando su código de acceso. [pag. 9]