El JDK 1.2 contiene una mejora sustancial de las caracter�sticas de seguridad: basado en pol�tica, f�cilmente configurable, concesi�n fina de control de acceso, nuevos servicios de criptograf�a y manejo de certificados y claves; y tres nuevas herramientas. Estos t�pios se cubren en las siguientes secciones.
�Extensiones de la Arquitectura de Seguridad
El control de acceso ha evolucionado para ser m�s fino que en versiones anteriores de la plataforma Java.
El modelo original de seguridad proporcionado por la plataforma Java, conocido como el modelo "sandbox", existi� para proporcionar un entorno muy restrictivo en el que ejecutar c�digo no firmado obtenido desde una red abierta. En este modelo, mostrado en el siguiente diagrama, el c�digo local tiene total acceso a los recursos vitales del sistema, como el sistema de ficheros, pero el c�digo descargado remotamente (un applet) s�lo puede tener acceso a recursos limitados proporcionados dentro del sandbox. Un controlador de seguridad es el responsable en cada plataforma de determinar qu� accesos a recursos est�n permitidos.
Modelo de Seguridad del JDK 1.0:
El JDK 1.1 introdujo el concepo de "applet firmado", como ilustra la siguiente figura. Un applet firmado digitalmente es tratado como c�digo local, con total acceso a los recursos, si se usa la clave p�blica para verificar la firma. Los applets no firmados a�n se ejecutan dentro del sandbox. Los applets firmados se env�an con sus respectivas firmas, en ficheros JAR (Java ARchives) firmados.
Modelo de Seguridad del JDK 1.1:
El JDK introduce un gran n�mero de mejoras sobre el JDK 1.1. Primero, todo el c�digo, sin importar si es local o remoto, puede ahora esta sujeto a una pol�tica de seguridad. Esta pol�tica define un conjunto de permisos disponibles para el c�digo de varios firmantes o direcciones y puede ser configurado por el usuario o un administrador de sistemas. Cada permiso especifica un acceso permitido a un recurso particular, como accesos de lectura y escritura a un fichero o directorio especifico o acceso de conexi�n a un host dado y a un puerto.
El sistema de ejecuci�n organiza el c�digo en dominios individuales. cada uno de ellos encierra un conjunto de clases cuyos ejemplares pueden acceder al mismo conjunto de permisos. Un dominio puede configurarse como un sandbox, por eso los applets a�n se pueden ejecutar en entornos restrictivos si el usuario o el administrador lo eligen as�. Por defecto, las aplicaciones se ejecutan sin restriciones, pero opcionalmente ahora pueden estar sujetas a una pol�tica de seguridad.
La nueva arquitectura de seguridad en el JDK 1.2 se ilustra en la siguiente figura. La flecha de la izquierda se refiere a un dominio cuyo c�digo tiene total acceso a los recursos; la flecha de la derecha se refiere al extremo opuesto: un dominio restringido exactamente igual que en el sandbox original. Los dominios entremedias tienen m�s accesos permitidos que el sandbox pero menos que el acceso toal.
Modelo de Seguridad del JDK 1.2:
�Extensiones de Arquitectura Criptogr�fica
La primera versi�n del API de seguridad del JDK en JDK 1.1 presento la Java cryptography architecture (JCA), que se refiere al marco de trabajo para acceder y desarrollar funcionalidades de criptograf�a para la plataforma Java. El JCA incluye un proveedor de arquitectura que permite m�ltiples e interpolables implementaciones criptogr�ficas. El t�rmino cryptographic service provider (CSP), o simplemente proveedor, se refiere a un paquete (o conjunto de paquetes) que suministran una implementaci�n concreta de un subjuego de aspectos de criptografia del API de Seguridad del JDK.
En el JDK,por ejemplo, un proveedor podr�a contener una implementaci�n de uno o m�s algoritmos de firmas digitales, o de message digest, y algoritmos de generaci�n de claves, el JDK 1.3 a�ade cinco tipos m�s de servicios:
- Creacci�n y manejo de bases de claves
- Algoritmo de manejo de par�metros
- Algoritmo de generaci�n de par�metros
- F�brica de Claves para convertir entre las diferentes representaciones de una clave.
- F�brica de Certificados para generar certificados y listas de revocaci�n de certificados (CRLs) para sus c�digos.
El JDK 1,2 tambi�n permite a un proveedor suministrar algoritmos de generaci�n de n�meros aleatorios (RNG).
La versi�n de SUN del JRE viene de serie con un proveedor por defecto, llamado SUN. Este paquete incluye implementaciones de un n�mero de servicios de DSA (Digital Signature Algorithm), implementaciones de los algoritmos de MD5 (RFC 1321) y SHA-1 (NIST FIPS 180-1), una f�brica de certificados para certificados X.509 y una lista de revocaci�n de certificados, un algoritmo de generaci�n de n�meros pseudo-aleatorios, y una implementaci�n de un almacen de claves.
El Java Cryptography Extension (JCE) ampl�a el JDK para que incluya el API para encriptaci�n, intercambio de claves, y c�digo de autentificaci�n de mensajes (MCA). Junto con el JCE y los aspectos de criptografia del JDK proporciona un completo API de criptografia independiente de la plataforma. El JCE es una extensi�n separada del JDK, en concordancia con las regulaciones de control de la exportaci�n del gobierno de los U.S., y no se cubre en esta secci�n.
La siguiente figura ilustra varios m�dulos JCA. La capa SPI (service provider interface), que representa m�todos que deben ser implementados para proveedores de servicios de criptografia, se describe en la siguiente secci�n
�Servicios de Criptografia
Se ha a�adido un gran n�mero de clases "motor" al JDK 1.2 para las clases Signature, MessageDigest, y KeyPairGenerator disponibles en el JDK 1.1. Una clase motor define un servico criptogr�fico de una forma abstracta (sin una implementaci�n concreta). Una clase motor define m�todos del API que permiten a las aplicaciones acceder a tipos espec�ficos de servicios criptogr�ficos que proporciona, como un algoritmo de firma digital. Las implementaciones reales de uno o m�s proveedores, son aquellas para algoritmos espec�ficos.
Los interfaces de aplicaci�n suministrados por una clase motor son implementados en t�rminos de un service provider interface (SPI). Es decir, cada clase motor tiene una correspondiente clase asbstracta SPI que define los m�todos del interface proveedor del servicio, que el proveedor del servicio criptogr�fico debe implementar.
Por ejemplo, un cliente API podr�a pedir y usar un ejemplar de la clase motor Signature para acceder a la funcionalidad de un algoritmo de firma digital para firmar digitalmente un ficheo. La implementaci�n real suministrada en una subclase SignatureSpi ser�a aquella para un tipo algoritmo de firma espec�fico, como SHA-1 con DSA o MD5 con RSA.
Cada ejemplar de una clase motor encapsula un ejemplar de su correspondiente clase SPI como implementada por un proveedor de servicio criptogr�fico. Cada m�todo API de una clase motor invoca al correspondiente m�todo SPI del objeto SPI encapsulado.
�Interfaces y Clases para Certificados
El JDK 1.2 presenta interfaces para manejar y analizar certificados y proporciona una implementaci�n X.509 v3 de los interfaces de certificados. Un certificado es b�sicamente un sentencia firmada digitalmente desde una entidad (persona, compa��a, etc.) diciendo que la clave p�blica de otra entidad tiene un valor particular.
Algunas de las clases relacionadas con certificados (todas del paquete java.security.cert) son las siguientes.
- Certificate - Esta clase es una abstraci�n para certificados que tienen varios formatos pero tienen usos comunes importantes. Por ejemplo, varios tipos de certificados, como X.509 y PGP, comparten funcionalidades de certificado generales, como codificaci�n y verificaci�n, y algunos tipos de informaci�n como una clave p�blica. Los certificados X.509, PGP, y SDSI pueden ser implementados con una subclase de Certificate, incluso aunque contengan diferentes conjuntos de informaci�n y almacenen y recuperen la informaci�n de formas diferentes.
- CertificateFactory - Esta clase define la funcionalidad de un f�brica de certificados, que se usa para generar objetos certificados y listas de revocaci�n de certificados (CRL) de sus c�digos.
- X509Certificate - Esta clase abstracta para certificados X.509 proporciona una forma est�ndard de acceder a todos los atributos de un certificado de este tipo.
�Interfaces y Clases para Manejo de Claves
El JDK 1.1 present� los interfaces abstractos Key. El JDK 1.2 a�ade.
- Una clase KeyStore (una clase motor) que suministra interfaces bien definidos para acceder y modificar informaci�n en un almacen de claves, que es un repositorio de claves y certificados. Son posibles m�ltiples implementaciones concretas diferentes, donde cada implementaci�n es para un tipo diferente de keystore. Un tipo de keystore define el almacenamiento y el formato de los datos de la informaci�n de las claves.
- Una implementaci�n de KeyStore por defecto, que implementa el keystore como un fichero, usando un formato de keystores propietario llamado JKS. La implementaci�n de keystore protege cada clave privada con su password particular y tambi�n protege la integridad del keystore completa con un password (posiblemente diferente).
- Interfaces de Especificaci�n de Claves, que son usados para representaciones "transparentes" del material clave que constituye la clave. Este material podr�a ser, por ejemplo, la propia clave y los par�metros del algoritmo usado para calcularla. Una representaci�n "transparente" de claves significa que podemos acceder al valor material de cada clave individualmente.
- Una herramienta (keytool) para manejar claves y certificados.
�Herramientas Relacionadas con la Seguridad
El JDK presenta tres nuevas herramientas.
- Keytool usada para crear pares de claves p�blica/privada, para importar y mostrar cadenas de certificados, para exportar certificados y peticiones de certificados que pueden ser enviados a una autoridad de certificaci�n.
- Jarsigner usada para firmar ficheros JAR y verificar la autenticidad de las firmas de estos ficheros.
- Policy Tool crea y modifica la configuraci�n de lsos ficheros de pol�tica que definen la pol�tica de seguridad de nuestra instalaci�n.