Diseño de un protocolo tipo SSH/SSL con tolerancia a fallas

1. Diseño de un protocolo tipo SSH/SSL con tolerancia a fallas Dr. Roberto Gómez C. Asesor de Tesis MS Adolfo Grego y Dr. Jesús Vázquez Gómez. Comité. Ricardo César Lira Plaza ITESM-CEM

2. Motivación/Reflexión • ¿Es suficiente la criptografía para garantizar la seguridad de nuestra información?* • Todas los sistemas criptográficos dependen de la seguridad de sus llaves, esto es una gran ventaja porque en lugar de pensar en asegurar una gran cantidad de información, ahora solo tenemos que asegurar una “pequeña” llave. “Theory and Practice of Verifiable Secret Sharing” MIT *PhD Rosario Gennaro

3. Motivación/Reflexión • Esta misma reflexión nos lleva a pensar que requerimos una técnica no criptográfica para asegurar nuestras llaves secretas, sino caemos en el problema de volver a tener una llave de la encripción de dicha llave.

4. Objetivo de la Investigación • Desarrollar un protocolo basado en el concepto de “Secret Sharing Scheme” desarrollado por Adi Shamir (MIT) que nos permita distribuir información sensitiva, en específico llaves secretas, de tal manera que se garantice durante su almacenamiento y transmisión: confidencialidad, integridad y disponibilidad.

5. Antecedentes • El desarrollo del esquema “Secret Sharing” fue motivado por la falta un de esquema seguro y confiable para el manejo y administraciónde llaves (secure key management, RSA Laboratories). • Adi Shamir, How to Share a Secret. Noviembre 1979. Communications of the ACM. (Association of Computer Machinery).

6. Características del Esquema Secret Sharing • Para recuperar la información original se requiere un número importante de secretos • La información orginal se puede recuperar a pesar de que varios de los secretos hayan sido violadas o vulnerados • El que recibe un secreto puede verificar que es correcto, aunténtico e íntegro.

7. Implicaciones de las llaves secretas • En ocasiones una sola llave nos puede dar acceso a demasiada información que pude ser confidencial y de alto riesgo. • ¿Qué sucede si la llave se pierde? • ¿Qué sucede si no se le protege de manera adecuada?

8. Funcionamiento esencial • La idea esencial del esquema de “secretos compartidos” es dividir la llave secreta en n partes y distribuirlas, en nuestro caso en equipos distintos ( a través de sockets) de tal forma que con solo una parte de ellos (m de n) sea suficiente para reconstruir la llave.

9. Punto de vista confidencialidad • Nuestro esquema se puede ver desde dos puntos de vista, el primero es que un equipo sea atacado y vulnerado, en cuyo caso la llave secreta podría dar acceso al atacante a un gran número de información valiosa. • Sin embargo, debido a que se distribuye la llave, y se requieren m de n partes, el tener solo una parte de la llave no permitirá al atacante conocer la información >> confidencialidad.

10. Punto de vista tolerancia a fallas • Desde otro punto de vista, podría ser que un equipo fallara y si es este el que tiene la llave secreta entonces tenemos una negación de servicio, ya que no se podrá encriptar ni desencriptar información. • Nuestro esquema ataca esta falla ya que solo necesitamos m de n partes de la llave para reconstruirla.

11. Trabajos relacionados • “BBN's SafeKeyper, for instance, is activated by a set of data keys, which are physical keys capable of storing digital information. The data keys use secret sharing technology so that several people must use their data keys to activate the SafeKeyper” http://www.rsasecurity.com/rsalabs/faq/4-1-3-13.html

12. Consideraciones y requerimientos • Utilizar el concepto de Secretos Compartidos para brindar tolerancia a fallas y garantizar la disponibilidad de la información. • Escoger de tal manera los parámetros (m,n) que nos permitan garantizar un equilibrio entre desempeño y seguridad. • Garantizar la integridad de la información distribuida a través de huellas digitales. • Distribuir la información de manera que se busque su confidencialidad.

13. Consideraciones y requerimientos • Pensar desde el principio y en todo momento que nuestro protocolo será tan seguro como la más débil de sus partes, por lo que durante su implementación debemos ser severos con los algoritmos a utilizar, por ejemplo: generación de números pseudo-aleatorios, huellas digitales, compilación (bugs). • La cadena de la seguridad es tan fuerte como el más débil de sus eslabones

14. Consideraciones y requerimientos • Implementar un canal seguro de comunicación entre los equipos a través de técnicas de encripción para el envío de secretos. Es por esto que se dice que es un protocolo tipo SSL/SSH. Necesitamos integridad, confidencialidad y autenticación durante la transmisión de los secretos. Proteger contra spoofing y sniffing.

15. Desarrollo/Investigación/Tesis 1 • Investigación sobre “Secret Sharing Schemes” • Investigación sobre esquemas de tolerancia a fallas. • Investigación sobre sistemas de encripción, tanto siméticos como asimétricos

16. Desarrollo/Investigación/Tesis 1 • Investigación sobre SSL y SSH • Investigación sobre Sockets y su programación. • Investigación sobre generación de números pseudo-aleatorios. • Investigación sobre esquemas matemáticos para compartir secretos, ej.: Polinomio de LaGrange.

17. Desarrollo/Tesis 1 • Diseño y desarrollo del protocolo en base a secretos compartidos considerando que el canal es seguro. • Depuración del programa. • Cambios y modificaciones.

18. Desarrollo/Tesis 2 • Diseño de un protocolo para obtener un canal seguro. • Diseño y desarrollo del protocolo en base a secretos compartidos considerando que el canal no es seguro. • Depuración del programa. • Cambios y modificaciones.

19. Conclusiones/ Etapa final tesis 2 • Conclusiones, pruebas y resultados. • Revisión general del reporte escrito.

20. Trabajo a futuro • Distribuir secretos compartidos de por lo menos 256 bits (32 bytes) para obtener inmunidad contra ataques de fuerza bruta. • Desarrollar un generador de números pseudo-aleatorios que nos permita obtener estos 256 bits con suficiente entropía y robusto, probablemente basado en Rijndael como función de mezcla fuerte.

21. Trabajo a futuro • Extender el protocolo para distribuir información, no solo llaves. • Por ejemplo, información confidencial que se distribuya bajo el mismo esquema, por lo que el penetrar un sistema no implica el tener acceso a la información. • Otro ejemplo, archivo de passwords o información suceptible a ataques de fuerza bruta.