J2ME Tutorial Parte X Final

Certificados de Seguridad en MIDP 2.0

OBJETIVOS

Una de las características que hacen de MIDP una buena plataforma para dispositivos móviles es la seguridad que ofrece. La seguridad se ve incrementada en MIDP 2.0 y podemos considerar que las siguientes fuentes de dicha seguridad son: La seguridad implícita en el modelo de programación de Java (máquina virtual de Java). La nueva interfaz javax.microedition.pki que permite trabajar con certificados de seguridad para autentificar la información en conexiones seguras. Esto resulta imprescindible en MIDP 2.0 ya que implementa en el paquete javax.microedition.io conexiones seguras (tanto sobre HTTP como sobre sockets). La posibilidad que ofrece de definir distintos permisos y dominios de protección en el entorno de desarrollo J2ME Wireless Toolkit 2.0 Con la implementación de protocolos de conexión seguros cada vez son más la aplicaciones que deben ser descargadas desde un servidor para ser ejecutadas en nuestro terminal. Cobra, por tanto, una gran importancia el hecho de poder asegurar que el código descargado sea exactamente el que queremos y que no presente un comportamiento malicioso. El código descargado será especialmente peligroso cuando desconocemos su autor, su fin o su procedencia. Como ya se dijo anteriormente, Java ofrece un alto grado de seguridad en este aspecto a través de su máquina virtual, ya que el código descargado no se ejecutará directamente sobre el sistema operativo sino sobre dicha máquina virtual. Sin embargo, partiendo de la base de que nunca conseguiremos un sistema cien por cien seguro, la máquina virtual de Java no será suficiente y se deben implementar nuevos mecanismos de seguridad. Es en este punto dónde MIDP 2.0 supone un considerable avance respecto a su predecesor. Como ya se ha dicho nos permite definir distintos dominios protección, cada uno de ellos con un nivel de seguridad determinado. MIDP 2.0 define muy vagamente cómo deben ser definidos estos dominios pero sí sugiere que estén basados en firmas criptográficas y certificados de seguridad. MIDP 2.0 define a través del MIDP X.509 Certificate Profile (perfil de certificados X.509 de MIDP) cómo debe ser el formato y la utilización de los certificados. Las aplicaciones DEBEN soportar los certificados X.509 (son los más extendidos y se denominan así porque se definen en la recomendación X.509 de CCITT) y el algoritmo de cifrado RSA utilizando SHA-1. Además, PUEDEN soportar (o no) cualquier otro tipo de certificados (dependerá de la implementación).

CERTIFICADOS DE SEGURIDAD

A la hora de establecer una conexión segura, por ejemplo para descargar una aplicación en nuestro terminal móvil, debemos estar seguros de la identidad del otro participante en la conexión o del autor o propietario que nos ofrece la aplicación. La solución adoptada es la de utilizar certificados de seguridad y consiste básicamente en autenticar mutuamente a ambos extremos de la comunicación a través de una autoridad de certificación en la que confían ambos. Así pues, la Autoridad de certificación actúa como un tercero de confianza en la comunicación entre clientes, cliente y servidor, etc. El escenario en el que nos encontramos es el siguiente: A pretende establecer una conexión segura con B (o viceversa, B propone la conexión). A no puede garantizar que es B realmente quien se encuentra en el otro extremo de la comunicación, es decir, B no está autenticado frente a A. La autoridad de certificación AC reconoce a B y por lo tanto, puede garantizar que es quien dice ser. AC es una autoridad de certificación reconocida por A. Figura 1: Establecimiento de conexión segura e intercambio de certificado El proceso de autenticación es el siguiente: cuando se va a establecer la conexión segura, por ejemplo, cuando A va a descargar en el terminal una aplicación desde el servidor B, solicitará que le sea enviado el certificado de seguridad. Una vez recibido, el usuario A comprobará cuál es la autoridad de certificación que expidió el certificado (en nuestro caso es AC) y si es una autoridad de certificación reconocida se lo reenviará. Si AC reconoce el certificado como el propio de B estará en condiciones de autenticarle frente a A y, dado que éste confía en la autoridad de certificación, aceptará el establecimiento de la conexión. Por último comentar que los certificados contienen información adicional importante en la autenticación de usuarios (como por ejemplo marcas de tiempo o "timestamps" con las que hacer que los certificados tengan un tiempo de validez finito). Algunos de estos datos se verán con más detalle al tratar el interfaz Certificate.

EL INTERFAZ Certificate

El interfaz Certificate abstrae una serie de datos contenidos en los certificados como son: el tema, el emisor, el tipo, la versión, el número de serie, el algoritmo de firmado digital, fechas de validez y número de serie.
Ya se ha explicado que los certificados de seguridad se intercambian a la hora de establecer una conexión segura. Si volvemos a la página de este tutorial referente al paquete javax.microedition.io veremos que cualquier conexión segura (HTTPS o SSL) tiene asociado un objeto SecurityInfo. Es en este objeto donde podemos encontrar el certificado recibido y en función del cuál se pudo establecer correctamente la conexión segura:

HttpsConnection conexionSegura = (HttpsConnection)Connector.open("........");
SecurityInfo si = conexionSegura.getSecurityInfo();
Certificate c = si.getServerCertificate();

Los distintos métodos que ofrece este interfaz están encaminados a poder acceder a los distintos datos que ofrece el certificado:

• getIssuer(): devuelve el nombre del emisor del certificado. El valor devuelto NO DEBE ser null.
  
• getNotAfter(): devuelve la fecha, en milisegundos, a partir de la cuál el certificado dejará de ser válido. Devolverá un número positivo (long) o la constante Long.MAX_LONG_VALUE si el certificado no tiene fecha de caducidad.
  
• getNotBefore(): devuelve el tiempo, en milisegundos, a partir del cuál se podrá aceptar el certificado. Devolverá un número positivo (long) o cero si la validez del certificado no está sujeta a restricciones temporales.
  
• getSerialNumber(): devuelve un String que contiene el número de serie del certificado. Dado que dicho número de serie está codificado en binario, será necesario darle el formato adecuado para que pueda ser imprimido. Por tanto la salida de este método será un String con valores hexadecimales separados por ":".
  
• getSigAlgName(): devuelve el nombre del algoritmo utilizado para firmar el certificado.
  
• getSubject(): devuelve el tema del certificado. El valor devuelto NO DEBE ser null.
  
• getType(): devuelve un String indicando de que tipo de certificado se trata. Para certificados X.509 el valor devuelto es "X.509". El valor devuelto NO DEBE ser null.
  
• getVersion(): indica cuál es la versión del certificado. A los certificados X.509 les corresponde el valor 2. El valor devuelto NO DEBE ser null.