Evaluación de cryptosystem para autenticación y cambio de clave

1

Soy un estudiante de maestría en informática que trabaja a tiempo parcial con mi propia compañía como consultor.

Mi último proyecto se basa en mi tesis de licenciatura que se encarga de todo, excepto la seguridad. La aplicación será auditada por una empresa mucho más grande que los que me contrataron y un requisito en la auditoría es la doble capa de seguridad en todos los canales.

La primera capa será, por supuesto, ssl / tls. En cuanto al segundo, he encontrado lo siguiente.

  • Autenticación de acceso de compilación HTTP: para el intercambio de credenciales
  • DHKE: para crear un secreto compartido que luego se usa para transportar una clave AES.
  • RSA: para firmar digitalmente la respuesta del servidor para garantizar que no haya ningún hombre en el medio.

Mi primer pensamiento fue utilizar RSA para transportar la clave de manera segura. Pero pensé que podría reducir los gastos generales utilizando DHKE en su lugar. Corrígeme si me equivoco.

El protocolo funcionaría algo como esto:

Client-> (username + public information for DHKE) -> Server
Server-> (B from DHKE, salt for HTTP digest, AES key encrypted with DHKE secret) -> Client
                 (Whole message signed with server private key)
Client-> AES(Hashed information for HTTP digest) -> Server
Server-> AES(Session token) -> Client

Una vez iniciada la sesión, todos los mensajes se cifrarán con la clave AES. Probablemente estoy pensando demasiado y me faltan muchos detalles y agradecería enormemente algunos consejos.

Saludos cordiales Johan Risch

    
pregunta Risch 19.04.2014 - 18:00
fuente

1 respuesta

2

Dices esto:

  

un requisito en la auditoría es la doble capa de seguridad en todos los canales

y eso lo dice todo. Sus auditores no entienden cómo funciona realmente la criptografía o incluso la seguridad. Si fueran médicos, duplicarían las dosis de todos los medicamentos; cuando trasplantan un riñón, tratan de enganchar un riñón adicional; cuando tienen que cortar una pierna, también quitan la otra, solo para estar seguros.

Dado que la auditoría se realizará bajo auspicios tan irracionales, lo mejor que puede esperar es hacer algo que formalmente cumpla con el ritual de "doble capa", pero que sea lo suficientemente inofensivo. Esto apuntaría a encapsular dos SSL: dentro de un túnel SSL, simplemente ejecute otro (con algoritmos distintos, para que los auditores no se den cuenta de lo ridículos que son). Si realmente quieres sobresaltarlos, usa otra biblioteca para el SSL interno, por ejemplo. OpenSSL en el exterior y GnuTLS en.

Hacer tu propia implementación de un protocolo existente está plagado de peligros; Diseñando tu propio protocolo aún más. No lo hagas si puedes evitarlo. Reutilizar los protocolos existentes y las implementaciones existentes le ahorrará mucho tiempo y producirá muchas menos vulnerabilidades.

    
respondido por el Tom Leek 19.04.2014 - 20:49
fuente

Lea otras preguntas en las etiquetas