11 Integración de la autorización basada en certificados de atributos para SSH Victor Manuel Fernández Albor

OPEN-SSH Proyecto e Integrantes 22 - Proyecto IFEC - Estudio, diseño y desarrollo de una infraestructura de Firma digital cualificada basada en una infraestructura de gestión de privilegios y una autoridad de sellado de tiempos. INTEGRANTES

OPEN-SSH Criptografía 33 - Hoy día la criptografía se basa en problemas matemáticos con difícil resolución. - Criptografía simétrica - Como compartimos las claves? - Para N usuarios: N(N-1)/2 pares de claves - Ejemplos: AES, Blowfish

OPEN-SSH Criptografía 44 - Criptografía asimétrica - 2 Claves: Una pública y otra privada. - Para N usuarios: N pares de claves - Menos fuerte que la simétrica. - Ejemplos: RSA, DSA, ElGamal, Elliptic Curve Compartir secretos - Muestra híbrida entre los esquemas simétricos-asimétricos. - No repudio - Envío autenticación - Firma Digital

Root CA Sub-CA 55 OPEN-SSH Criptografía - La identidad de los certificados está conectado a la clave pública con una identidad. - El certificado necesita ser firmado para asegurar la conexión. - La firma es realizada con una clave asimétrica, y necesita de otro certificado para certificar al que firma. - Esto genera una cadena, y al final de la cadena existe una autoridad que se autofirma su propio certificado. - El usuario ha decidido si confía en la autoridad o no. - Normalmente estas autoridades son bien conocidas y soportadas por los gobiernos. Root CA Sub-CA

OPEN-SSH Criptografía 66 Cada usuario tiene un conjunto de roles o atributos Una política de autorización verifica las acciones mostradas con los roles atributos La política no incrementa con el número de usuarios

OPEN-SSH 77 Capa de transporte Capa de Autenticación del usuario Capa de conexión Intercambio de claves Define concepto de canales Autenticación del cliente Autenticación del servidor Provee un número de métodos de autenticación Cifrado

88 OPEN-SSH Arquitectura necesaria Necesidades de Open-SSH con PMI - Usuario del SSH - Certificado de identidad - Certificado de atributos - SSH Client - PMI - Institución del Usuario - Certificado de SOA - Certificado de Usuario - Servidor PMI - Gestor de políticas - Proveedor de servicios - Gestor de políticas (Todavía no disponible) - SSH Server - PMI

99 OPEN-SSH PMI Arquitectura necesaria

OPEN-SSH Problemática en el desarrollo y modificación del protocolo 10101010 OPEN-SSH Problemática en el desarrollo y modificación del protocolo Estes son los principales problemas encontrados en la realización del proyecto: 1) La falta de documentación acerca del código ssh, escrito integramente en C puro. Por un lado SSHD, y por otro SSH cliente, con sus diferentes capas. Conexion - Authenticación – Transporte connect ---- authXX ---- kex Mezcla de capas en ficheros ssh.c y sshd.c. Utilización de algunos ficheros C, tanto por parte del cliente como por parte del servidor, da lugar a confusiones. 2) Una vez conseguido desencriptar código: ¿ Como es la comunicación entre el cliente y el servidor? Definidos en el RFC de SSH, las nomenclaturas no coincidian. Los nombres de los códigos enviados entre cliente y servidor, no coincidian en muchos de los casos.

OPEN-SSH Problemática en el desarrollo y modificación del protocolo 11111111 Estes son los principales problemas encontrados en la realización del proyecto: 3) Una vez se consigue comunicar SSHD y SSH client, se necesita enviar certificados ¿Como los envio? Funciona por Sockets, se creo una secuencia de códigos específica para el envio: mensaje códigoNumericoMensaje 4) Una vez enviados los certificados, el SSHD necesita verificarlos, SSH, no permitia escribirlos en ficheros, ni poder verificarlos, ni siquiera acceder a archivos del sistema. -Cambio del CHROOT -Borrar permisos de escritura-lectura en disco (setGid, setUid)‏ -Duplicación de procesos -Memoria compartida

OPEN-SSH Problemática en el desarrollo y modificación del protocolo 12121212 Estes son los principales problemas encontrados en la realización del proyecto: 5) Una vez que tenemos los certificados, necesitabamos conectar una aplicación en C puro, con otra en java para la obtención de una respuesta, varias alternativas, Pruebas Axis c++, GCJ, Gsoap, Swig, Jace, JVM en C en linux. - Llamada app Java directamente, pero se necesitaba pasarle los certificados a) Primera versión en ficheros → operativa b) Segunda versión a través de stdin, stdout → problemas con caracteres de fin de fichero existentes en certificados, mala interpretación de las funciones tanto de C como de Java. → Operativa.

13131313 OPEN-SSH Estructura diagrama

OPEN-SSH Validación-Verificación 14141414 OPEN-SSH Validación-Verificación Get Information of PMI Validate every chain with OCSP or CRL in middleware Validate att certificate with OCSP or CRL in PMI Verify the dates of chain certificates, Soa certificate and Att Certificate Load the trustStore and validate sign of Certificates. Verify the XACML policy

15151515 XACML Now i explain that is the XACML (Extensible access control marcup languaje) that is used by the proyect. The first Point “The targets.” Each policy has a target, which helps determine if the policy is relevant to the answer. 2) The Rules, have a conditions that estates on the attributes that return value was True, False or Indeterminate. The Rules, hava efects that are the result of satisfiying the rules, it can take the values Permit o Deny. And the last point is a target, that as in the policy case help in any situations where the rule is not relevant for the response. 3) Rule-combining algorithms, combining the effects of every rules in a final decisions of the policy. 4) The obligations is in the used of XACML, because a objectives of XACML is provider access control at the finest level for Deny and Permit decisions. The PDP is the most important of XACML policy. It is the policy decision point that return a response with the answer to request. The other important part in the XACML policy is PEP which to create the Request for PDP.

PROYECTO IFEC 16161616 Now i explain that is the XACML (Extensible access control marcup languaje) that is used by the proyect. The first Point “The targets.” Each policy has a target, which helps determine if the policy is relevant to the answer. 2) The Rules, have a conditions that estates on the attributes that return value was True, False or Indeterminate. The Rules, hava efects that are the result of satisfiying the rules, it can take the values Permit o Deny. And the last point is a target, that as in the policy case help in any situations where the rule is not relevant for the response. 3) Rule-combining algorithms, combining the effects of every rules in a final decisions of the policy. 4) The obligations is in the used of XACML, because a objectives of XACML is provider access control at the finest level for Deny and Permit decisions. The PDP is the most important of XACML policy. It is the policy decision point that return a response with the answer to request. The other important part in the XACML policy is PEP which to create the Request for PDP. Víctor Manuel Fernández Albor (victormanuel.fernandez@usc.es) Luis Manuel Carril Rodríguez (luismanuel.carril@usc.es) Tomás Fernández Pena Universidad de Santiago de Compostela Andrés Gómez, Ignacio López Cabido {agomez,nlopez}@cesga.es Centro de Supercomputación de Galicia Sergio Rodríguez Juan Manuel Alonso Alonso Aldaba Soluciones y Proyectos Felipe Gil Castiñeira Jorge Javier Castaño Universidade de Vigo