Seguridad en la Plataforma Java 2 JDK 1.2

El JDK 1.2 contiene una mejora sustancial de las caractersticas de seguridad: basado en poltica, fcilmente configurable, concesin fina de control de acceso, nuevos servicios de criptografa y manejo de certificados y claves; y tres nuevas herramientas. Estos tpios se cubren en las siguientes secciones.

.Extensiones de la Arquitectura de Seguridad

El control de acceso ha evolucionado para ser ms 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 cdigo no firmado obtenido desde una red abierta. En este modelo, mostrado en el siguiente diagrama, el cdigo local tiene total acceso a los recursos vitales del sistema, como el sistema de ficheros, pero el cdigo descargado remotamente (un applet) slo 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 estn 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 cdigo local, con total acceso a los recursos, si se usa la clave pblica para verificar la firma. Los applets no firmados an se ejecutan dentro del sandbox. Los applets firmados se envan con sus respectivas firmas, en ficheros JAR (Java ARchives) firmados.

Modelo de Seguridad del JDK 1.1:

El JDK introduce un gran nmero de mejoras sobre el JDK 1.1. Primero, todo el cdigo, sin importar si es local o remoto, puede ahora esta sujeto a una poltica de seguridad. Esta poltica define un conjunto de permisos disponibles para el cdigo 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 conexin a un host dado y a un puerto.

El sistema de ejecucin organiza el cdigo 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 an 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 poltica 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 cdigo 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 ms accesos permitidos que el sandbox pero menos que el acceso toal.

Modelo de Seguridad del JDK 1.2:

.Extensiones de Arquitectura Criptogrfica

La primera versin 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 criptografa para la plataforma Java. El JCA incluye un proveedor de arquitectura que permite mltiples e interpolables implementaciones criptogrficas. El trmino cryptographic service provider (CSP), o simplemente proveedor, se refiere a un paquete (o conjunto de paquetes) que suministran una implementacin concreta de un subjuego de aspectos de criptografia del API de Seguridad del JDK.

En el JDK,por ejemplo, un proveedor podra contener una implementacin de uno o ms algoritmos de firmas digitales, o de message digest, y algoritmos de generacin de claves, el JDK 1.3 aade cinco tipos ms de servicios:

  • Creaccin y manejo de bases de claves
  • Algoritmo de manejo de parmetros
  • Algoritmo de generacin de parmetros
  • Fbrica de Claves para convertir entre las diferentes representaciones de una clave.
  • Fbrica de Certificados para generar certificados y listas de revocacin de certificados (CRLs) para sus cdigos.

El JDK 1,2 tambin permite a un proveedor suministrar algoritmos de generacin de nmeros aleatorios (RNG).

La versin de SUN del JRE viene de serie con un proveedor por defecto, llamado SUN. Este paquete incluye implementaciones de un nmero de servicios de DSA (Digital Signature Algorithm), implementaciones de los algoritmos de MD5 (RFC 1321) y SHA-1 (NIST FIPS 180-1), una fbrica de certificados para certificados X.509 y una lista de revocacin de certificados, un algoritmo de generacin de nmeros pseudo-aleatorios, y una implementacin de un almacen de claves.

El Java Cryptography Extension (JCE) ampla el JDK para que incluya el API para encriptacin, intercambio de claves, y cdigo de autentificacin 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 extensin separada del JDK, en concordancia con las regulaciones de control de la exportacin del gobierno de los U.S., y no se cubre en esta seccin.

La siguiente figura ilustra varios mdulos JCA. La capa SPI (service provider interface), que representa mtodos que deben ser implementados para proveedores de servicios de criptografia, se describe en la siguiente seccin

.Servicios de Criptografia

Se ha aadido un gran nmero 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 criptogrfico de una forma abstracta (sin una implementacin concreta). Una clase motor define mtodos del API que permiten a las aplicaciones acceder a tipos especficos de servicios criptogrficos que proporciona, como un algoritmo de firma digital. Las implementaciones reales de uno o ms proveedores, son aquellas para algoritmos especficos.

Los interfaces de aplicacin suministrados por una clase motor son implementados en trminos de un service provider interface (SPI). Es decir, cada clase motor tiene una correspondiente clase asbstracta SPI que define los mtodos del interface proveedor del servicio, que el proveedor del servicio criptogrfico debe implementar.

Por ejemplo, un cliente API podra 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 implementacin real suministrada en una subclase SignatureSpi sera aquella para un tipo algoritmo de firma especfico, 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 criptogrfico. Cada mtodo API de una clase motor invoca al correspondiente mtodo SPI del objeto SPI encapsulado.

.Interfaces y Clases para Certificados

El JDK 1.2 presenta interfaces para manejar y analizar certificados y proporciona una implementacin X.509 v3 de los interfaces de certificados. Un certificado es bsicamente un sentencia firmada digitalmente desde una entidad (persona, compaa, etc.) diciendo que la clave pblica 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 abstracin 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 codificacin y verificacin, y algunos tipos de informacin como una clave pblica. Los certificados X.509, PGP, y SDSI pueden ser implementados con una subclase de Certificate, incluso aunque contengan diferentes conjuntos de informacin y almacenen y recuperen la informacin de formas diferentes.
  • CertificateFactory - Esta clase define la funcionalidad de un fbrica de certificados, que se usa para generar objetos certificados y listas de revocacin de certificados (CRL) de sus cdigos.
  • X509Certificate - Esta clase abstracta para certificados X.509 proporciona una forma estndard 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 aade.

  • Una clase KeyStore (una clase motor) que suministra interfaces bien definidos para acceder y modificar informacin en un almacen de claves, que es un repositorio de claves y certificados. Son posibles mltiples implementaciones concretas diferentes, donde cada implementacin es para un tipo diferente de keystore. Un tipo de keystore define el almacenamiento y el formato de los datos de la informacin de las claves.
  • Una implementacin de KeyStore por defecto, que implementa el keystore como un fichero, usando un formato de keystores propietario llamado JKS. La implementacin de keystore protege cada clave privada con su password particular y tambin protege la integridad del keystore completa con un password (posiblemente diferente).
  • Interfaces de Especificacin de Claves, que son usados para representaciones "transparentes" del material clave que constituye la clave. Este material podra ser, por ejemplo, la propia clave y los parmetros del algoritmo usado para calcularla. Una representacin "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 pblica/privada, para importar y mostrar cadenas de certificados, para exportar certificados y peticiones de certificados que pueden ser enviados a una autoridad de certificacin.
  • Jarsigner usada para firmar ficheros JAR y verificar la autenticidad de las firmas de estos ficheros.
  • Policy Tool crea y modifica la configuracin de lsos ficheros de poltica que definen la poltica de seguridad de nuestra instalacin.

COMPARTE ESTE ARTÍCULO

ENVIAR A UN AMIGO
COMPARTIR EN FACEBOOK
COMPARTIR EN TWITTER
COMPARTIR EN GOOGLE +
ARTÍCULO ANTERIOR

¡SÉ EL PRIMERO EN COMENTAR!
Conéctate o Regístrate para dejar tu comentario.