Introducción a las Características de Seguridad en Java 2 JDK 1.2
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.
Tutoriales
