Mecanismos de Seguridad en Java: Herramienta Keytool Construcción de Sockets Seguros SSL en Java

Transcripción

1 Pág. 1 08/10/2014 Luis Mengual (C)

2 Podemos decir que la seguridad en java se concentra en tres extensiones básicas: JCE, Java Cryptography Extension: Proporciona facilidades de cifrado, resúmenes (funciones hash), mecanismo de firma y gestión de claves. JSSE, Java Secure Sockets Extension. El API de JSSE define un conjunto de clases utilizadas para ejecutar las operaciones necesarias para invocar el protocolo SSL desde el código fuente de java. Estas clases serán una extensión de las conocidas clases de sockets tradicionales. JAAS, Java Authentivation and Authorization Service : Proporciona autenticación dentro de la plataforma Java. Todas las facilidades principales del diseño de la seguridad en Java están pensadas para proteger a los usuarios finales de las influencias de los desarrolladores: los usuarios finales dan permiso a los desarrolladores a acceder a los recursos en la máquina del usuarios final. JAAS permite a los desarrolladores obtener (o no) el acceso a sus programas basándose en las credenciales de autenticación proporcionadas por el usuario. Nuestro interés se centrará en las dos primeras extensiones que nos permitirán construir aplicaciones de usuario en un entorno distribuido incorporando mecanismos y servicios de seguridad. Pág. 2 08/10/2014 Luis Mengual (C)

3 Los certificados X.509 tiene un estandar PKCS#6 pueden almacenarse en formato binario DER con extensiones.crt,.cer,.der. Tambíen pueden alamcenarse en formato PEM con extension.pem. La claves privada al igual que los certificados pueden estar en formato DER o PEM. Y las extensiones de los ficheros serían.der o.pem. El formato de las claves sigue el estandar PKCS#8. El formato PEM es la conversión base64 del formato DER a la que se añaden unos delimitadores del tipo -BEGIN CERTIFICATE- y -END CERTIFICATE Los archivos con extensión.p12 se utilizan para almacenar en un único fichero cifrado el certificado de clave pública de un usuario y su clave privada. La extensión.pfx (Personal information exchange) es similar que la *.p12 en el entorno windows. El formato de estos ficheros sigue el estándar PKCS#12. El entorno Openssl nos permite convertir formatos de certificados segun sean requeridos por nuestras aplicaciones Pág. 3 08/10/2014 Luis Mengual (C)

4 Pág. 4 08/10/2014 Luis Mengual (C)

5 Keytool es una utilidad de gestión de certificados y claves. Permite a los usuarios crear y administrar su propio par de claves pública/privada y el certificado asociado para autenticarse frente a otros usuarios e implementar mecanismos y servicios de seguridad. Keytool también gestiona los certificados de las otras entidades, así como solicitudes de firma de certificados por Autoridades de Certificación reconocidas. Keytool almacena las claves y los certificados en un llamado almacén (keystore). La implementación por defecto del almacén es un fichero que protege las claves privadas con una password. Pág. 5 08/10/2014 Luis Mengual (C)

6 Hay dos diferentes entradas en un almacén (keystore) 1. Private Key entries : Contiene información de claves criptográfica muy sensible, que es almacenada en formato protegido para evitar accesos no autorizados. Típicamente las claves almacenadas en esta entrada son claves privadas acompañadas por el certificado asociado a la clave pública. 2. Trusted Certificate Entries : Contiene un certificado simple de clave pública perteneciente a otra entidad. Es llamado certificado seguro Trusted certificate ya que el propietario del almacén es el que asegura que la clave pública del certificado pertenece a la identidad que aparece en el propietario del certificado. El emisor del certificado avala esto con su firma. Dicho de otro modo el propietario del almacén se fía de la entidad que firma el certificado. Pág. 6 08/10/2014 Luis Mengual (C)

7 ConestecomandodelaherramientaKeytool generamos el par de claves RSA (publica-privada) quedando almacenadas de forma segura en un fichero AlmacenCL protegido por un clave La herramienta keytool maneja almacenes que tienen, como hemos comentado, dos tipos de entradas: o bien almacenan claves privadas (key-entry) con un certificado asociado o bien almacenas certificados de clave publica (cerytificate entry) creados a partir de la importación de un certificado existente. Pág. 7 08/10/2014 Luis Mengual (C)

8 Vemos en esta figura el resultado del primer comando del paso 1: Generamos el par de claves pública-secreta y las almacenamos en el almacén CertificadoCL. Pág. 8 08/10/2014 Luis Mengual (C)

9 Vemos en esta figura el resultado del segundo comando del paso 1: Listamos el contenido del AlmacenCL. Vemos que aparece una entrada de tipo PrivateKeyEmtry. Pág. 9 08/10/2014 Luis Mengual (C)

10 La herramienta Keytool permite la exportación en un fichero binario (DER) del certificado de clave pública contenida en el almacén. Pág /10/2014 Luis Mengual (C)

11 Mostramos en la figura el resultado de la exportación del fichero.. Pág /10/2014 Luis Mengual (C)

12 Una vez que tenemos el certificado de clave publica en un fichero binario CertAutofirma.cer podemos realizar el proceso inverso: la importación del fichero a un almacén. Este proceso es muy común cuando implementemos aplicaciones que utilicen el protocolo SSL. El almacén AlmacenCLTrust puede ser un almacén de certificados fiables para nuestro cliente SSL. Con la herramiente Keytool podemos fáclimente realizar este proceso de importación. Pág /10/2014 Luis Mengual (C)

13 En la figura se observa el importación en el que nos pregunta si confiamos en el certificado. Pág /10/2014 Luis Mengual (C)

14 Si ahora listamos el contenido del almacén AlamcenCLTrust observamos que tiene una entrada del tipo trustedcertentry y que ha sido almacenado correctamente. Pág /10/2014 Luis Mengual (C)

15 Pág /10/2014 Luis Mengual (C)

16 Las clases CertificateFactory y X509certificate nos permiten manejar certificados de clave pública en nuestro código java. En la figura se muestra como utilizarlas conjuntamente para la lectura de un fichero que contenga un certificado. Pág /10/2014 Luis Mengual (C)

17 El ejemplo propuesto de la figura consiste en la lectura de un certificado desde un fichero y su incorporación y lectura desde codigo java. La clase CertificateFactory del paquete java.security.cert se utiliza para generar y manejar un certificado que podemos tener en forma de fichero con diferentes extensiones. Vamos a empezar considerar un fichero de certificado de claves pública. A partir de ese fichero nos creamos un objeto FileInputStream, flujo de datos correspondiente al fichero que contiene el certificado. FileInputStream obtiene los bytes de entrada del fichero. Con el método getinstance de la clase CertificateFactory nos creamos una instancia de la clase. Con el método generatecertificate, tomando como parámetro de entrada el objeto FileinputStream que contiene los bytes del fichero de certificado nos creamos un objeto de tipo X509Certificate que ya podemos manejar en nuestro programa Por ejemplo podemos acceder a sus campos o podemos imprimir el certificado completo en forma de string.. Pág /10/2014 Luis Mengual (C)

18 En la figura se observa como acceder a diferentes campos de un certificado, como son el propietario, emisor, número de serie etc Pág /10/2014 Luis Mengual (C)

19 En la figura se muestra el resultado de la lectura del certificado por nuestro código java.. Pág /10/2014 Luis Mengual (C)

20 Pág /10/2014 Luis Mengual (C)

21 El protocolo SSL (Secure Sockets Layer) es el protocolo de seguridad más extendido en Internet. t La inmensa mayoría de aplicaciones i en lared utilizan este protocolo para proporcionar servicios de seguridad. Vamos a estudiar a continuación cómo construir aplicaciones en java que incorporen el protocolo SSL en su código. El protocolo SSL siempre requiere que el servidor envíe su certificado. Este certificado permitirá crear un canal seguro. El cliente cifra la información con una clave de sesión que es enviada al servidor cifrada con la clave pública del servidor extraída de su certificado. Vamos a estudiar ejemplos sencillos en los que el certificado enviado por el servidor es un certificado autofirmado y luego posteriormente aprenderemos a crear certificados firmados por una Autoridad de Certificación (CA, Certification Authority). El servidor opcionalmente puede exigir al cliente que se autentifique. En este caso el cliente está obligado a enviar un certificado digital y una firma electrónica. Vamos pues a estudiar pues todos los casos posibles a la hora de construir aplicaciones SSL: Con y sin autenticación de cliente y utilizando certificados autofirmados o firmados por una CA. Pág /10/2014 Luis Mengual (C)

22 El protocolo de seguridad SSL (Secure Sockets Layer) es bien conocido. Consta de 4 fases de intercambio: En la primera fase el cliente y el servidor negocian la familia de cifradores a utilizar en el intercambio. En la segunda fase el servidor envía un certificado de clave pública con el que autenticarse frente al cliente. El cliente se asegurará que ese certificado recibido es fiable y además protege el sitio web al que trata de conectarse el cliente. Opcionalmente el servidor pude solicitar en esta fase al cliente que envíe un certificado para que se autentifique. Enlatercerafaseelclienteutiliza el certificado de clave pública del servidor para cifrar las claves de sesión con la clave pública del servidor garantizando de este modo la confidencialidad en la distribución de las claves. Si el servidor solicitó al cliente autenticación en la fase anterior, el cliente está obligado en esta fase a enviar un certificado de clave pública firmado por una entidad que para el servidor sea fiable..además el cliente hará una firma de los mensajes En la ultima fase se actualizan los cifradores negociados y se envía el primer mensaje cifrado y autenticado con las claves acordadas Pág /10/2014 Luis Mengual (C)

23 Para que nuestras aplicaciones desarrolladas en código java puedan utilizar el protocolo SSL deben invocar las clases de sockets modificadas incorporando el protocolo SSL. Estas son entre otras las clases SSLSocket y SSLServerSockets que se utilizaran en los ejemplos que veremos a continuación. Para implementar los mecanismos de seguridad propios del protocolo SSL se utilizan certificados de clave pública. En java estos certificados normalmente se obtienen de los almacenes de claves que hemos estudiado en ejemplos anteriores. En SSL se van a utilizar dos tipos de Almacenes: El llamado TrustStore es el almacén que tiene las certificados de las Autoridades de Certificación que se consideran fiables. El llamado KeyStore es el almacén que contiene la clave privada y el certificado del servidor y/o el cliente que se utilizan en el transcurso del protocolo SSL Hay tres formas de cargar en nuestras aplicaciones los almacenes TrustStore protocolo SSL. Por defecto, hay un almacén en $JREHOME/lib/security/cacerts que tiene los certificados de las Autoridades de Certificación más comunes. Este almacén se carga por defecto, sino se especifica un almacén distinto a través de las Java System Properties. Una tercera forma es expresamente indicar por código java un almacén diferente. Respecto de los almacenes KeyStore se especifican a través de las Java System Properties o bien hay que expresamente indicar por código java el almacén a considerar. Pág /10/2014 Luis Mengual (C)

24 JSSE introduce la noción de un truststore que es una base de datos que maneja certificados. De hecho un truststore tiene el mismo formato que un keystore ; ambos son administrados con keytool y ambos representados como instancias de la clase KeyStore. La diferencia es su funcionalidad. El Servidor en una conversación SSL debe tener una clave privada y un certificado que verifica su identidad. La clave privada es usada por el servidor como entrada del algoritmo de intercambio de clave y el certificado es enviado al cliente para decirle quien es el servidor. (la clave privada es usada también para descifrar la clave de sesión enviada por el cliente y cifrada con la clave pública del servidor). Toda esta información (clave privada y certificado) es obtenida del keystore. La clave privada nunca es enviada del servidor al cliente. Los servidores SSL pueden pedir al cliente que se autentifique. En este caso el cliente debe tener su propio keystore con su clave privada y certificado. El truststore es usado por el cliente para verificar el certificado que es enviado por el servidor. Este certificado normalmente es firmado por una autoridad de certificación confiable( o puede ser una cadena de certificados donde el último está firmado por una autoridad d fiable). Cuando un cliente SSL recibe un certificado del servidor, debe de verificar el certificado que recibe, lo cual significa que el certificado de la CA debe de estar en el fichero local truststore. En general todos los clientes SSL tienen que tener un fichero truststore. En el caso de que un servidor SSL requiera autenticación de un cliente, entonces el servidor deberá tener también un fichero truststore con el certificado CA que firma el certificado del cliente. El truststore y el keystore pueden ser (y a menudos son) el mismo fichero. Sin embargo es más fácil manejar las claves si ellas están separadas: El truststore puede contener los certificados de clave pública de CAs confiables y puede ser fácilmente compartido, mientas que el keystore puede contener la clave privada y el certificado de la organización local y puede ser almacenado en una localización protegida. Además es más fácil para JSSE manejar el keystore si contiene un solo alias. Si contiene varios alias la programación se complica. Pág /10/2014 Luis Mengual (C)

25 Keystores y truststores son gestionados por clases que implementan las interfaces KeyManager y trustmanager. Por defecto trust manager asume que los certificados de clave pública estan en el fichero $JREHOME/lib/security/jssecacerts. Sielficheronoexisteseasumequeestaen $JREHOME/lib/security/cacerts. Este fichero-almacen contiene los certificados raiz de conocidas Cas. Si se quiere elegir otro almacen diferente que contenga los certificados fiables hay que hacerlo modificando las propiedades del sistema Java -Djavax.net.ssl.trustStore=AlmacenCL Cliente Este comando establece que el fichero AlmacenCL contiene el certificado del servidor. Parece ser que no hay que poner clave Para meter un CERTIFICADO DE LA CA EN LOS CERTIFICADOS FIABLES DEL SISTEMA: keytool -import -alias CertificadoCA -file cacert.pem -keystore "C:\Archivos de programa\java\jre1.5.0_04\lib\security\cacerts" -storepass changeit keytool -list -v -keystore "C:\Archivos de programa\java\jre1.5.0_04\lib\security\cacerts") Pág /10/2014 Luis Mengual (C)

26 La implementación por defecto del Key Manager no usa un Keystore por defecto; No existe un $JREHOME/keystore. Para usar un keystore especifico se debe de modificar las propiedades del sistema Y PONER COMO PASSWORD DEL ALMACEN DE CLAVES LA MISMA CLAVE QUE SE TIENE EN LA KEY ENTRY QUE CONTIENE EL CERTIFICADO Y CLAVE DEL SERVIDOR Java -Djavax.net.ssl.keyStore=AlmacenSR - Djavax.net.ssl.keyStorePassword=pppppp EchoServer En resumen, pues podemos decir que en una comunicación SSL convencional (sin autenticación de cliente) tenemos dos ficheros: El fichero keysstore que contiene el certificado y la clave privada que da fe la identidad ( es el server keystore). Por otro lado el cliente contiene otro almacen denominado truststore file que contiene solo el certificado ( es el truststore del cliente). Pág /10/2014 Luis Mengual (C)

27 Pág /10/2014 Luis Mengual (C)

28 Vamos a construir la aplicación cliente servidor de Eco implementada con la interfaz sockets de java orientada a conexión (protocolo TCP). Como se ve en la figura la estructura de la programación en java de las comunicaciones es sencilla: En el cliente utilizamos la clase Socket() para establecer la conexión y en el servidor la clase ServerSocket() y el método accept para esperar la llegada de conexiones de clientes. Como parámetros de la clase Socket del cliente ponemos la direcciónió IP yel puerto del servidor. Como parámetros de la clase ServerSocket() del servidor ponemos simplemente el puerto donde el servidor espera las conexiones de los clientes. Pág /10/2014 Luis Mengual (C)

29 En este segundo ejemplo TCP vamos a construir un cliente-servidor de eco. En la figura se muestra parte del código del cliente. Utilizamos de forma ilustrativa dos clases BufferedReader y Scanner para leer por teclado la dirección IP y puerto a las cuales se va a conectar nuestro cliente. Pág /10/2014 Luis Mengual (C)

30 En esta figura se muestra cómo construimos los streams de entrada/salida para que el socket TCP lea caracteres de la entrada estándar, los envíe por el socket y espere recibir la contestación en eco del servidor. Así, utilizamos el objeto bufferedreader para leer del teclado los caracteres que introduce el cliente y que espera recibir en eco. Utilizamos el objeto bufferedwriter para mandar esos caracteres por el socket creado. Nótese que el objeto bufferedwriter viene del objeto outputstreamwriter que a su vez viene del objeto outputstream creado con el método getoutputstream de la clase Socket. Finalmente, utilizamos el objeto bufferedreader2 para recibir los caracteres en eco que nos devuelve el servidor. Nótese que el objeto bufferedreader2 viene del objeto inputstreamreader2 que a su vez viene del objeto inputstream2 creado con el método getinputstream de la clase Socket. El cliente puede salir del bucle while introduciendo un retorno de carro. Pág /10/2014 Luis Mengual (C)

31 La figura muestra parte del código del servidor de eco. Inicialmente el servidor crea el socket pasivo TCP mediante el objeto ServerSocket(), inicializándolo en el puerto A continuación se invoca el método accept() de la clase ServerSocket dejando al servidor en un espera bloqueante a la espera de una petición de un cliente... En el servidor utilizamos el objeto bufferedreader para recibir los caracteres que nos envía el cliente y que debemos de reenviar en eco. Nótese que el objeto bufferedreader viene del objeto inputstreamreader que a su vez viene del objeto inputstream creado con el método getinputstream de la clase Socket. Utilizamos el objeto bufferedwriter para mandar esos caracteres por el socket creado y devolvérselos en eco al cliente. Nótese que el objeto bufferedwriter viene del objeto outputstreamwriter que a su vez viene del objeto outputstream creado con el método getoutputstream de la clase Socket. Pág /10/2014 Luis Mengual (C)

32 Como hemos visto, para la construcción de una aplicación SSL tenemos que realizar una primera tarea relativa a la construcción de los almacenes de claves necesarios para la ejecución del protocolo SSL. Esta quizás sea la parte más compleja. Lógicamente tenemos que realizar una segunda tarea que está referida al código java necesario para recoger estos almacenes de claves e incorporarlos a nuestra aplicación concreta. Para construir este código java vamos a utilizar factorías de sockets que implementan el protocolo SSL. Estas clases va a extender de las clases SocketFactory y ServerSocketFactory En concreto, en el lado del cliente la clase SSLSocketFactory nos permitirá la construcción de una factoría de sockets con las mismas características. Al arrancar la factoría con el método getdefault estamos asignando a la factoría de sockets activos la configuración por defecto. Esta configuración por defecto implica la carga de certificados de clave pública asociados a la sesión SSL. Esta carga de certificados se hace mediante almacenes Esto significa que arrancaríamos los almacenes por defecto bien sean los del sistema (cacerts) o bien los incorporados con las Java System properties o bien los especificados por código java. SSLSocketFactory sslsocketfactory = (SSLSocketFactory) SSLSocketFactory.getDefault(); SSLSocket sslsocket = (SSLSocket) sslsocketfactory.createsocket(dirip, ptoint); SSLSession sesion = sslsocket.getsession(); En el lado del servidor la clase SSLServerSocketFactory nos permitirá la construcción de una factoría de sockets pasivos con las mismas características. Al arrancar la factoría con el método getdefault estamos asignando a la factoría de sockets pasivos la configuración por defecto. SSLServerSocketFactory sslserversocketfactory =(SSLServerSocketFactory SSLServerSocketFactory.getDefault(); SSLServerSocket sslserversocket =(SSLServerSocket) sslserversocketfactory.createserversocket(9999); SSLSocket sslsocket = (SSLSocket) sslserversocket.accept(); SSLSession sesion = sslsocket.getsession(); Pág /10/2014 Luis Mengual (C)

33 Cada conexión SSL lleva asociada una sesión SSL, pero una sesión puede ser usada en varias cconexiones. Las factorías de sockets permiten la creación de nuevos sockets SSL que podrian compartir la misma sesión. Para acceder a la sesion SSL actual hay que acceder a la clase SSLSession. Para ello una vez obtenido un socket SSL (en la figura sslsocket) se invoca el método getsession() obteniendo un objeto ed la clase SSLSession. SSLSession sesion = sslsocket.getsession(); Como se aprecia en la figura ahora podemos acceder a las caracteristicas de la sesion SSL. Pág /10/2014 Luis Mengual (C)

34 Pág /10/2014 Luis Mengual (C)

35 La utilización de los Sockets SSL en java requiere el manejo de los ficheros de almacenes de certificados y claves. Estos almacenes son los que permiten implementar los servicios de seguridad en las comunicaciones con sockets. En la figura presentamos el ejemplo más sencillo de comunicaciones SSL. En este ejemplo consideramos que el certificado del Servidor que se utiliza en la comunicación SSL es un certificado Autofirmado creado por el servidor con la herramienta Keytool. Este certificado y su clave privada asociada son almacenadas en el almacén AlmacenSR como una entrada Key Entry. Para que el cliente pueda considerar fiable este certificado debe utilizar un almacén denominado AlmacenTrust que contiene el certificado autofirmado del servidor ( TrustedCertEntry ). Los dos almacenes AlmacenTrust y AlmacenSR tienen el mismo certificado de clave pública; la diferencia entre ambos está en que el AlmacenTrust no tiene la clave privada del certificado. Efectivamente sólo el servidor va a tener la clave privada del certificado. Como es sabido el cliente genera una clave de sesión (premaster-secret) que cifra con la clave pública del servidor. Esta clave de sesión se utiliza para cifrar la comunicaciones con un algoritmo de cifrado simétrico. Únicamente el servidor con su clave privada podrá descifrar las comunicaciones. Para que las sesiones SSL utilicen los almacenes de claves se pueden instanciar los almacenes de certificados desde el código java (como veremos en ejemplos posteriores), o bien, se puden utilizar las JSSE Java System Properties para modificar las porpiedades por defecto de las sesiones ssl. Para usar JSSE (Java Secure Sockets Extension) se necesitan especificar varias propiedades del contexto SSL: javax.net.ssl.truststore : El nombre del fichero que contiene el objeto KeyStore que se quiere que utilice por defecto el TrustManager. El valor por defecto es jssecacerts o cacerts. Este es el fichero que contiene los certificados que se consideran fiables a la hora de autenticar a otra entidad. javax.net.ssl.keystore : El nombre del fichero que contiene el objeto KeyStore que se quiere que utilice por defecto el KeyManager. No hay un valor por defecto y, por consiguiente, hay que especificarlo expresamente. Este es el almacen que contiene el certificado y la clave privada asociada. javax.net.ssl.keystorepassword : Es la password del objeto KeyStore que se quiere que utilice por defecto el KeyManager. Una vez especificado en el cliente el almacentrust y en el servidor almacensr con las Java Systems Properties : System.setProperty("javax.net.ssl.trustStore","AlmacenTrust"); System.setProperty("javax.net.ssl.keyStore","AlmacenSR"); S S System.setProperty("javax.net.ssl.keyStorePassword","oooooo");..podemos crear un socket SSL que utilice los almacenes especificados a la hora de implementar los mecanismos de seguridad. Un socket SSL lo vamos a crear utilizando la factoría de sockets SSL (SSLSocketFactory). Esto nos permite crear un conjunto de sockets SSL con la mismas características. La creación propia del socket se hace como indica la figura con el método createsocket. El socket SSL obtenido ya tiene asociados los almacenes establecidos en el contexto Pág /10/2014 Luis Mengual (C)

36 Para poder implementar este ejemplo sencillo de SSL debemos en primer lugar crear los almacenes del cliente almacentrust y el almacén del servidor AlmacenSR. Como hemos comentado antes el almacén del servidor AmacenSR contiene un certificado y la clave privada asociada a este certificado. El servidor presentara al cliente durante el protocolo SSL el certificado contenido en el almacensr como acreditación suya y además para que el cliente envié un clave de sesión cifrada con la clave pública de este certificado. El cliente utilizará el almacén almacentrust para verificar la fiabilidad del certificado recibido por el servidor. En general, este almacén deberá contener el mismo certificado del servidor o bien deberá contener el certificado de la Autoridad de Certificación que firma el certificado del servidor. Como en este ejemplo tenemos un certificado autofirmado el almacén almacentrust tendrá el mismo certificado que el servidor. El proceso de crear los almacenes lo vamos a dividir en tres fases: En la fase 1 generamos un par de claves privada-secreta y un certificado autofirmado, como hemos hecho en ejemplos anteriores. Utilizaremos el alias CertificadoAutofirmado y lo almacenamos en el AlmacenSR. Una vez creado el certificado, en la fase 2, lo exportamos a fichero CertAutofirmado.cer con la herramienta Keytool. Pág /10/2014 Luis Mengual (C)

37 En la fase 3, importamos el fichero CertAutofirmado.cer conteniendo el certificado de clave publica del servidor al almacén AlmacenTrust Una vez completadas estas tres fases distribuimos el almacén AlmacenTrust a la entidad cliente y el almacén AlmacenSR a la entidad servidor. Para tener planificada la infraestructura de la conexion SSL faltaría que en el cliente invocaremos System.setProperty("javax.net.ssl.trustStore","AlmacenTrust"); Y en el servidor: System.setProperty("javax.net.ssl.keyStore","AlmacenSR"); System.setProperty( setproperty("javax.net.ssl.keystorepassword keystorepassword","oooooo"); Pág /10/2014 Luis Mengual (C)

38 La figura representa el resultado de la Fase 1 de creación del certificado Autofirmado Pág /10/2014 Luis Mengual (C)

39 En esta figura se aprecia el contenido del almacen AlmacenSR. Como se observa el Alias Certificadoautofirmado es un entrada del tipo KeyEntry y, por consiguiente, contiene un certificado de clave pública autofirmado y la clave privada asociada. Pág /10/2014 Luis Mengual (C)

40 En esta figura se aprecia el proceso de exportación a fichero del certificado autofirmado y, posteriormente, el proceso de importación al almacén almacentrust Pág /10/2014 Luis Mengual (C)

41 En esta figura apreciamos el contenido del almacén almacentrust. De acuerdo a la figura se observa un alias certificadoautofirmado que se corresponde con una entrada del tipo TrustedCertEntry. Esto significa que contiene únicamente el certificado de clave pública sin la clave privada asociada Pág /10/2014 Luis Mengual (C)

42 Vamos a implementar ahora el código fuente del cliente SSL que utiliza el almacén truststore que nos hemos creado. Las java system properties se puede proporcionar por una línea de código System.setProperty("javax.net.ssl.trustStore","AlmacenTrust"),.. o, bien invocando estas propiedades en la línea de comandos: Java -Djavax.net.ssl.trustStore=AlmacenCL EchoClient Si quisiramos ii tener un debug del protocolo SSL podemos ademas añadir a la línea de comandos la opcion -Djavax.net.debug=ssl java -Djavax.net.debug=ssl -Djavax.net.ssl.trustStore=AlmacenCL EchoClient Respecto del código, las líneas esenciales se refieren a la creación de la factoría de sockets y al método createsockets que nos crea un socket SSL con el almacén "AlmacenTrust asociado y dispuesto a establecen una conexión/sesión SSL con el servidor. Pág /10/2014 Luis Mengual (C)

43 La parte del código del cliente de eco TCP/SSL es igual que el cliente de eco TCP convencional salvo que los stream de entradaysalidaseefectúansobreelsocket SSL sslsocket Pág /10/2014 Luis Mengual (C)

44 El código del servidor SSL que utiliza el almacén AlmacenSR que nos hemos creado aparece en la figura. Las java system properties se puede proporcionar de forma análoga al cliente por líneas de código: System.setProperty("javax.net.ssl.keyStore","AlmacenSR"); System.setProperty("javax.net.ssl.keyStorePassword","oooooo"); o, bien invocando estas propiedades en la línea de comandos: java -Djavax.net.ssl.keyStore=AlmacenSR - Djavax.net.ssl.keyStorePassword=pppppp EchoServer Si quisieramos tener un debug del protocolo SSL podemos además añadir a la línea de comandos la opcion -Djavax.net.debug=ssl Respecto del código, las líneas esenciales se refieren a la creación de la factoría de sockets del servidor SSLServerSocketFactory y al método createserversockets t que nos crea un socket servidor SSL ( en el puerto 9999) con el almacén "AlmacenSR asociado y dispuesto a atender a una conexión/sesión SSL un cliente. Al cliente al que se conecte el servidor enviara a lo largo del protocolo SSL el certificado del servidor incluido en el almacensr. Con la clase SSLsesion obtenemos las característica de la sesión SSL establecida. Así por ejemplo podemos obtener la dirección ip del cliente. Pág /10/2014 Luis Mengual (C)

45 En la figura aparece el resto del código fuente del seevidor TCP/SSL de eco en el cual se aprecia como del stream de entrada del socketssl se leen los datos que envía el cliente y por el stream de salida se devuelven los datos en eco Pág /10/2014 Luis Mengual (C)

46 Pág /10/2014 Luis Mengual (C)

47 Vamos a modificar el código inicial de nuestra aplicación Cliente/Servidor SSL, introduciendo una funcionalidad opcional que proporciona el protocolo SSL: la Autenticación del Cliente. El servidor puede solicitar al cliente que se autentifique mediante un certificado digital. Esta opción se codifica en java mediante el método setneedclientauth() de la clase sslserversocket según se indica en la figura. (sslserversocket.setneedclientauth(true);) De esta forma el servidor solicita en la sesión SSL que el cliente se autentifique mediante el envió de un certificado. Si el cliente no lo hace la sesión se cierra y java daría una excepción en el cliente y en el servidor: Excepción en Cliente: java.net.socketexception: Software caused connection abort: recv failed Excepción en Servidor: javax.net.ssl.sslpeerunverifiedexception: peer not authenticated Para poder crear la infraestructura necesaria para que el cliente se autentifique es necesario modificar la infraestructura de los almacenes de certificados creados en el ejemplo anterior en el cliente y en el servidor. En concreto, en el cliente es necesario incluir un almacén nuevo además del AlmacenTrust. Hay que añadir el AlmacenCL, conteniendo un certificado que pueda ser válido para la autenticación del cliente frente al servidor. En nuestro ejemplo este almacén va a ser el mismo que el AlmacenSR y, por tanto va a contener el mismo certificado Autofirmado y clave privada asociada que contiene el servidor. En general, este almacén deberá tener un certificado firmado por una Autoridad de Certificación considerada fiable por el servidor. Lo veremos en ejemplos posteriores. En la entidad servidora deberemos incluir el almacén AlmacenTrust además del ya existente AlmacenSR. El almacén AlmacenTrust es el mismo del cliente y contiene el certificado de clave publica del cliente. De esta forma se puede considerar fiable el certificado del cliente. Por último hay que cargar estos almacenes en la sesion SSL en el cliente y en el servidor. Esto se puede hacer como hemos visto en ejemplos anteriores con las System properties de java: En el cliente: System.setProperty("javax.net.ssl.trustStore","AlmacenTrust"); System.setProperty("javax.net.ssl.keyStore","AlmacenCL"); System.setProperty("javax.net.ssl.keyStorePassword","oooooo"); Y en el servidor: System.setProperty("javax.net.ssl.keyStore","AlmacenSR"); System.setProperty("javax.net.ssl.keyStorePassword","oooooo"); System.setProperty("javax.net.ssl.trustStore","AlmacenTrust"); Pág /10/2014 Luis Mengual (C)

48 En el ejemplo que estamos analizando, Cliente/Servidor SSL con autenticación de Cliente, podemos obtener los certificados intercambiados entre ambas entidades. Para ello utilizamos el código java de la figura. A partir de la clase SSLsesion podemos acceder a las propiedades de la sesión SSL establecida. Mediante el método getpeercertificates() obtenemos el certificado enviado por la entidad par X509Certificate certificate = (X509Certificate)sesion.getPeerCertificates()[0]; Podemos además imprimir el certificado del cliente o servidor en formato binario (DER) utilizando el método getencoded() de la clase X509Certificate como se aprecia en la figura Pág /10/2014 Luis Mengual (C)

49 Pág /10/2014 Luis Mengual (C)

50 El ejemplo que proponemos p desarrollar en esta figura representa una situación más habitual que las que hemos analizado con anterioridad. En este caso el certificado que utiliza el servidor para autenticarse y que el cliente usará para enviar las claves de sesión cifradas es un certificado firmado por una Autoridad de certificación (CA, Certification Authority). Para que este sistema funcione el fichero de certificados del servidor AlmacenSR debe de contener el certificado del servidor firmado por una CA (y su clave privada asociada, como siempre) y también el propio certificado de clave pública de la CA. En el cliente el almacén AlmacenTrust debe de contener ahora únicamente el certificado de clave pública de la CA. Este certificado avalará la firma del certificado del servidor intercambiado durante el protocolo SSL. Para analizar en profundidad el proceso de creación de los almacenes en el caso de certificados firmado por una CA vamos a ver el ejemplo completo en el cual incluiríamos la autenticación del cliente. Pág /10/2014 Luis Mengual (C)

51 En general, las aplicaciones Cliente-Servidor SSL van a utilizar certificados firmados por una Autoridad d de Certificación. ió Así pues para construir este tipo de aplicaciones necesitamos en primer lugar un certificado de una Autoridad de Certificación (un certificado Autofirmado). Una vez en posesión de este certificado de CA (Certification Authority) podemos crearnos certificados de cliente y servidor y posteriormente firmarlos con la clave privada de la Autoridad de Certificación. Para hacer todo este proceso utilizaremos la línea de comandos de OpenSSL. Pág /10/2014 Luis Mengual (C)

52 Para crear un certificado de CA utilizaremos la línea de comandos de OpenSSL yejecutaremos los mismos pasos que en el caso de la creación de un certificado autofirmado. Es decir, primero nos creamos un directorio en la Unidad C: de nuestra máquina virtual. En segundo lugar abrimos una ventana de MSDOS y la ubicamos en el anterior directorio. En tercer lugar ejecutamos dentro de la ventana MSDOS openssl. A partir de este momento estaremos en el entorno de Openssl y podremos ejecutar los comando que aparecen en la figura. Pág /10/2014 Luis Mengual (C)

53 Las fases de creación de los almacenes en la entidad servidora son exactamente iguales a como se hace en el cliente El almacén AlmacenSRTrust es el almacen que contiene el certificado de la CA. Es exactamente igual al fichero AlmacenCLTrust, puesto que suponemos que los certificados del cliente y el servidor los firma la misma CA. El almacén AlmacenSR es el almacén del servidor donde inicialmente creamos un entrada con el certificado del servidor autofirmado con el Alias CertificadoSR. De igual forma que el cliente generamos una solicitud it de firma del certificado autoafirmado: SR.csr. Es recomendable ejecutar estos comandos de la herramienta Keytool en el mismo directorio y desde la misma ventana MSDOS que hemos realizado la creación del certificado de la CA. Nótese que el primer comando de Keytool necesita el certificado de la CA Cacertificado.pem. Así pues este fichero debe de estar en el mismo directorio donde ejecutamos el comando Keytool y donde vamos a crear los almacenes. Pág /10/2014 Luis Mengual (C)

54 Los pasos 4, 5 y 6 son especialmente e complejos por lo que se recomienda e hacer despacio. En primer lugar, en el paso 4 se requiere nuevamente volver al entorno OpenSSL. Desde este entorno, desde la misma ventana MSDOS y desde el mismo directorio se debe de invocar este comando Openssl. Nótese que este comando necesita el fichero SR.csr (creado con la herramienta Keytool ) que contiene una solicitud de firma de un certificado y el fichero CAClavePrivada.pem (creado con la herramienta OpenSSL) que contiene la clave privada de la CA. En este paso pues se firma el certificado del servidor desde el entorno Openssl obteniéndose el fichero CertificadoSR_firmado.crt que contiene el certificado del servidor firmado por la CA. En el paso 5 salimos del entorno OpenSSL y volvemos a la herramienta Keytool. En este paso introducimos en el almacén del servidor AlmacenSR el certificado de la CA. Por último, en el paso 6 y continuando con la herramienta Keytool metemos el certificado firmado por la CA CertificadoSR_firmado.crt en el almacén AlmacenSR sustituyendo a la entrada original del certificado autofirmado. Pág /10/2014 Luis Mengual (C)

55 Pág /10/2014 Luis Mengual (C)

56 En la figura tenemos un ejemplo completo de una conexión/sesión TCP/SSL en la que tanto el servidor como el cliente disponen de certificados firmados por un CA. En el caso del servidor su certificado lo utilizará para autenticarse y dárselo al cliente, que a su vez, lo usará para cifrar las claves de sesión del protocolo SSL. El certificado del cliente será usado por éste para autenticarse frente al servidor. La estructura del código fuente en java será similar al de los ejemplos de Conexión SSL con Autenticación Cliente Certificado Servidor/Cliente autofirmado con la carga de los almacenes con las Java Systems Properties o por Código Java. No hay cambios en cómo se leen los almacenes aunque si hay cambio en el contenido propio de los almacenes. Pág /10/2014 Luis Mengual (C)

57 El proceso de creación de los almacenes conteniendo certificados firmados por una CA es complejo, aunque ha sido ya abordado en anteriores ejemplos. Vamos a suponer que utilizando el entorno Openssl disponemos de un certificado de CA en formato pem cacert.pem y de su clave privada asociada cakey.pem. Esta CA será la que firme los certificados que el cliente y el servidor generarán con la herramienta keytool. En el caso de la entidad cliente los pasos a seguir son los siguientes: En primer lugar, (Fase 1) vamos a meter el certificado de la CA en el almacén AlmacenCLTrust del cliente. De esta forma el cliente puede verificar el certificado que le envía el servidor durante el protocolo SSL. Para ello importamos el certificado al almacén AlmacenCLTrust : keytool -import -alias CertificadoCA -file cacert.pem -keystore AlmacenCLTrust A continuación (Fase 2) generamos un par de claves pública y secreta junto con el certificado asociado y lo metemos en el almacén AlmacenCL con el Alias CertificadoCL. Todo esto exactamente igual que vimos en los primeros ejemplos de uso de la herramienta keytool keytool -genkey -alias CertificadoCL -keyalg RSA -validity "100" -keystore AlmacenCL -keypass oooooo -storepass oooooo En la Fase 3, vamos a crear un fichero de solicitud de firma CL.csr. La solicitud de firma CSR (Certification Signing Request) es un proyecto de certificado que requiere la firma de una Autoridad de Certificación. Este proceso se estudio en ejemplos anteriores. keytool -certreq -alias CertificadoCL -keystore AlmacenCL -file CL.csr Pág /10/2014 Luis Mengual (C)

58 En la Fase 4 hacemos uso de la plataforma OpenSSL para generar la firma de la firma de la CA. Nótese que como parámetros de entrada utilizamos el fichero con la petición de firma CL.csr y los ficheros con el certificado de la CA cacert.pem y la clave privada de la CA cakey.pem. El resultado es el fichero CertificadoCL_firmado.crt que finalmente el certificado original del cliente firmado ahora por la CA Openssl> x509 -req -days 365 -in CL.csr -CA cacert.pem -CAkey cakey.pem - set_serial 02 -out CertificadoCL_firmado.crt Un paso fundamental para que el sistema funcione adecuadamente (Fase 5) es la importación del certificado de la CA en el almacén del cliente AlmacenCL. keytool -import -alias CertificadoCA -file cacert.pem -keystore AlmacenCL El último paso sería la importación del certificado firmado CertificadoCL_firmado.crt en el AlmacenCL. Nóetese que la importacion se hace con el mismo Alias (CertificadoCL) que teníamos en la Fase 2 cuando el cliente generó su certificado. Esto significa que lo que hacemos es sobrescribir esta entrada con el nuevo certificado ya firmado keytool -import -alias CertificadoCL -file CertificadoCL_firmado.crt -keystore AlmacenCL Pág /10/2014 Luis Mengual (C)

59 En la figura se observa el resultado de la Fase 1 en la que introducimos el certificado de la CA en el AlmacenCLTrust Pág /10/2014 Luis Mengual (C)

60 En la Figura se observa el resultado de la Fase 2, en la generacióndeclavesy de certificado del cliente. El resultado como se observa es un certificado autofirmado (propietario=emisor) Pág /10/2014 Luis Mengual (C)

61 En la figura se observan las fases 3 y 4, que corresponden al proceso de generación de firma. Pág /10/2014 Luis Mengual (C)

62 En la Fase 5 introducimos el certificado de la CA en el almacén AlmacenCL. Como se aprecia en la figura, en este momento tenemos dos certificados almacenados: el certificado autofirmado con la clave privada asociada (entrada Keyentry) y el certificado de la CA (entrada TrustedCertEntry). Pág /10/2014 Luis Mengual (C)

63 Finalmente en esta fase (Fase 6) introducimos os el certificado cado del cliente cetefirmado por la CA sustituyendo al original autofirmado. En la figura observamos como primera entrada el certificado de la CA.. Pág /10/2014 Luis Mengual (C)

64 En esta figura observamos el segundo certificado en el que se aprecia como emisor la identidad de la Autoridad de Certificación que firma el certificado. Pág /10/2014 Luis Mengual (C)

65 El cliente y el Servidor pueden utilizar certificados firmados por distintas Autoridades de Certificación. Los certificados de las Autoridades de Certificación se instalaran en los Almacenes correspondientes. En el AlmacenCLTrust se almacenará el certificado de la Autoridad que firma el certificado del servidor. En nuestro ejemplo CA1. En el AlmacenSRTrust se almacenará el certificado de la Autoridad que firma el certificado del cliente. En nuestro ejemplo CA2. Adicionalmente el certificado de la CA1 también se almacenará en el AlmacenCL, junto con el certificado firmado del cliente. El certificado de la CA2 se almacenará también en el AlmacenSR, junto con el certificado firmado del servidor Pág /10/2014 Luis Mengual (C)