Seguridad en java

Informe de investigacion seguridad en Java Camilo Castelblanco, Carlos Gaona, Alejandro Rodriguez Introduccion: Como ya bien sabemos la nueva generacion de profesionales que esta surgiendo actualmente de las instituciones educativas, se ve cada vez mas ligada al los distintos avances tecnologicos que como era de esperarse influye en el mercado laboral y de igual forma en el “como” se debe enfrentar a tales cambios para mantenerse a la vanguardia de tales cambios.

Obviamente el ingeniero de sistemas, es el primer senalado a estar en constante sinergia con tal cambio, ya que unicamente el desarrollo de un aplicativo, el modelado de una solucion informatica, la utilizacion de la infraestructura adecuada, o la buena distribucion de los recursos y su direccion no es lo unico en lo que se debe estar enfocando a la hora de cumplir con los requerimientos de cualquier cliente; es en este momento en que la seguridad cobra (como ha venido haciendolo por practicamente 2 decadas) un papel primordial en el proceso de produccion de soluciones en las T.

I. Actualmente dos de los lenguajes mas populares para el manejo de la informacion, en una solucion software a nivel empresarial se pueden ver representados en JAVA y . NET, los cuales

Lo sentimos, pero las muestras de ensayos completos están disponibles solo para usuarios registrados

Elija un plan de membresía
con caracteristicas muy similares en algunos casos, comparten el amplio espectro de software para el flujo control y almacenamiento de la informacion. Por ende a continuacion se busca resaltar en campos y que medidas toman estos dos lenguajes en sus implementaciones, para asegurar su confidencialidad, mitigar su vulnerabilidad, y rindarle al desarrollador distintas herramientas para proteger su producto desde el punto de vista funcional y de propiedad intelectual. Marco Teorico: I. Breve introduccion acerca de JAVA Origenes: En 1991 Sun Microsystems, empezo a desarrollar un proyecto de lenguaje, con el codigo GREEN, bajo la direccion de James Goslin, inicialmente con el proposito de administrar y controlar interactivamente los dispositivos conectados a las redes. Surgieron algunas situaciones frustrantes, pero por suerte, en pocos anos se empezo a popularizar Internet.

El proyecto se convirtio en un intento de resolver simultaneamente, todos los problemas que se le planteaban a los desarrolladores de software por la diversidad de arquitecturas incompatibles, los sistemas operativos y lenguajes de programacion y la dificultad de crear aplicaciones distribuidas en Internet. Evolucion: Java fue inicialmente desarrollado en C++, pero paulatinamente se fue independizando, escribiendo su propio lenguaje denominado Oak, que finalmente termino convirtiendose en Java.

En 23 de Mayo de 1995 fue lanzado al mercado el HotJava Browser, y ese mismo ano Netscape decidio habilitar a Java en su version 2. 0 de 1996. Es a partir de esa oportunidad que Java empezo a popularizarse en todo el mundo. Las caracteristicas mas importantes de Java son: 1. Es de arquitectura portable, neutral y robusta. | 2. Es simple, orientada a objeto y muy versatil. | 3. Es interpretado. El interprete Java (system run-time) puede ejecutar directamente el codigo objeto. El Applet de Java: El applet  se define como un programa dinamico e interactivo que puede ser ejecutado dentro de un archivo HTML y mostrado por un navegador con capacidad Java. Un programa Java puede ser ejecutado por si mismo. En todos los casos, bajo una jerarquia de Clase, Sub-Clase o Super Clase. Virus en Java: Con todas estas caracteristicas previamente mencionadas, los creadores de virus pensaron tambien en Java, como un medio para producir especies virales.

Debido a ciertas restricciones definidas en las propiedades de seguridad, tanto de los sistemas operativos, asi como de los navegadores, hasta la fecha existen solamente 2 virus de Java notables: Java. Beanhive: La tecnologia empleada en este virus tiene varias ventajas. La forma multi-componente de infeccion permite al virus esconder su codigo en los archivos infectados: su longitud crece en muy pequenos valores y despues de una ligera observacion el codigo insertado pareciera no ser danino. Java. StarngeBrew: Este es el primer virus conocido que infecta archivos Java Classes.

Fue reportado en Agosto de 1998 y tiene la capacidad de auto copiarse unicamente en el caso de que el acceso a unidades de disco este permitido en las Propiedades del navegador y el sistema operativo. El archivo infectado se ejecuta como una aplicacion nativa de Java y no como un Applet. II. Problemas de Seguridad en el desarrollo de aplicaciones Como primera medida, antes de hablar de las vulnerabilidades que los lenguajes de programacion puedan traer, sobre su misma implementacion, tambien cabe destacar las malas practicas en las que todos osotros podemos caer en el momento de desarrollar un aplicativo, malas practicas que si son detectadas a tiempo contribuyen a una mayor solides en el producto desarrollado, y que de la mano de las herramientas propias del lenguaje de programacion para solventar los problemas de seguridad conocidos, mitiguen los riesgos dentro del area de las tecnologas de informacion de una organizacion. Con el objeto de mencionar unos cuantos problemas que influyen en las brechas de seguridad en los aplicativos se puede tener en cuenta lo siguiente: * Ausencia infraestructura seguridad * Errores administrador/usuario Exploits * entender como funcionan las cosas * aprender buenas politicas * aprender trampas habituales Desbordamientos: El desbordamiento es un problema habitual y muy conocido no solo por parte del desarrollador de aplicaciones, el cual como su nombre lo indica desborda las estructuras de almacenamiento de datos y genera un grave problema en el manejo y acotacion de los mismos, los eventos mas relacionados con este problema se mencionan a continuacion: * Es extremadamente sencillo equivocarse * Mal diseno del lenguaje * Malas practicas de programacion * Hay lenguajes inmunes, pero no siempre podremos usarlos. En C (aunque no concierne a esta investigacion), se debe prestar especial cuidado con: strcpy, strcat,sprintf, gets, scanf. El desbordamiento del buffer: Los desbordamientos de buffer se basan en introducir el codigo en el espacio reservado para las variables locales (los argumentos de un metodo / funcion) y despues modificar la direccion de retorno/regreso (RET), donde regresa la informacion, para que apunte a un offset en donde hemos introducido nuestro codigo fuente. Este codigo puede ser – por ejemplo – una ShellCode, : bash, sh, entre otros. III. Principales Componentes de la plataforma Java

Entorno de ejecucion proporcionado por la Maquina Virtual Java (Java VM o JVM): Este entorno de ejecucion no es ni interpretado ni compilado; es un sistema hibrido. Los programas se compilan en un formato independiente de la maquina denominado bytecode y son interpretados por la Maquina Virtual, que es el unico componente de Java que depende de la plataforma en la que trabajamos (y, por lo tanto, debe ser portada a cada arquitectura). La implementacion de la JVM es la responsable de la seguridad incorporada en Java, por lo que es importante que su implementacion sea adecuada.

Conjunto de interfaces y arquitecturas: proporcionadas por la Interfaz con el programador de aplicaciones Java (API de Java). El API de Java es una coleccion de componentes software, agrupados en bibliotecas o paquetes de componentes relacionados, que proporcionan multitud de capacidades utiles para el diseno de interfaces graficos, acceso a redes, gestion de E/S, etc. En lo que respecta a la seguridad el API de Java nos proporciona paquetes que implementan o dan acceso a herramientas de seguridad de alto y bajo nivel como algoritmos de encriptacion, firmas electronicas, gestion de certificados, etc.

IV. Modelado de los API’s ( Interfaces de programacion de las aplicaciones) Con el fin de facilitar el manejo de la seguridad, los APIs, fueron creados alrededor de los siguientes tres principios: * Independencia de la implementacion: Las aplicaciones no necesitan implementar su seguridad por si mismas, sino que pueden adquirir esta funcionalidad a modo de plugins que ofrecen diferentes proveedores en el mercado. * Interoperabilidad de la implementacion: Los proveedores son interoperables a traves de las aplicaciones, es decir que una aplicacion no esta limitada a un proveedor y viceversa. Extensibilidad de los algoritmos: Ademas de permitir que se utilicen diferentes tipos de proveedores de seguridad, Java tambien permite que se implementen nuevas metodologias, o que se acondicionen las existentes a los requerimientos actuales de una empresa. V. Metodos incorporados enfocados a la seguridad en JAVA Algunos de los metodos incorporados al lenguaje Java para corregir los problemas relacionados con los accesos a memoria ilegales son:

Eliminacion de la aritmetica con punteros: Java la elimina por completo la aritmetica con punteros, que es una de las mayores fuentes de accesos ilegales a memoria en otros lenguajes. De cualquier forma, esto no quiere decir que Java no disponga de la nocion de puntero, la incluye dandole el nombre de referencia. Usando referencias podemos definir estructuras dinamicas complejas como listas, colas, arboles, etc. igual que en otros lenguajes. Comprobacion de rangos en el acceso a vectores: En Java se controlan todos los accesos a vector y se lanza una excepcion cuando intentamos un acceso fuera de rango.

En los lenguajes que esto no se hace, el programador puede acceder a memoria que esta mas alla de la reservada para el vector y modificar valores de otras variables de forma no controlada. De hecho, el intentar provocar estas salidas de rango en los buffers empleados en las aplicaciones es uno de los sistemas empleados para romper la seguridad de los programas. Definicion del comportamiento de las variables sin inicializar: En otros lenguajes los valores de las variables no inicializadas estan indeterminados, por lo que si accedemos a ellas antes de darles un valor podemos obtener resultados impredecibles.

Esto en Java no es asi, toda la memoria del heap se inicializa automaticamente, y la memoria de la pila, que es la que emplean las variables locales, debe ser inicializada por el programador (si en un programa se intenta usar una variable local antes de asignarle un valor el compilador genera un error). Eliminacion de la liberacion de memoria controlada directamente por el programador: En otros lenguajes, cuando un objeto creado dinamicamente deja de ser necesario el responsable de liberar la memoria que tiene asignada es el programador.

Es evidente que, de algun modo, es obligatorio el liberar la memoria, ya que si no lo hacemos, nuestra aplicacion consumiria mucha mas de la necesaria en un momento dado. El problema de esta liberacion es que nos podemos equivocar y liberar objetos que aun necesitamos (con lo que, al acceder a ellos, ya no estan y leemos datos de otros objetos o simplemente basura) e incluso intentar liberar mas de una vez la misma memoria (segun el lenguaje, compilador y sistema esto puede liberar memoria empleada por otros objetos, causar la muerte del programa, etc. . Java elimina este problema no proporcionando funciones de liberacion de memoria; cuando las variables u objetos ya no son referenciadas la memoria que ocupan es liberada por un sistema de recoleccion de basura automatico (garbage collection), que es parte del sistema de ejecucion. Ademas de lo anterior tambien se deben mencionar otras caracteristicas del lenguaje que contribuyen a escribir codigo seguro como: * El sistema de verificacion de tipos en tiempo de compilacion, que garantiza que las variables son de los tipos correctos. Los niveles de acceso a los miembros de las clases, que permite controlar la visibilidad de atributos y metodos. * El modificador final, que permite impedir que se definan subclases cuando se aplica a una clase o que se puedan redefinir atributos cuando se les aplica a ellos. VI. Areas de implementacion de seguridad en JAVA Seguridad en la plataforma: La seguridad en el lenguaje Java desde el punto de vista de la maquina virtual se refleja en las siguientes caracteristicas: * Lenguaje fuertemente tipado * Chequeo de acceso a las posiciones de un array (evita el buffer overflow). * Gestion automatica de la memoria Verificacion del bytecode que evita codigo hostil que pueda corromper la JVM. * Carga de clases segura que previene la ejecucion de codigo que no es de confianza. Criptografia: A continuacion se mencionan las distintas formas en que java brinda soporte al proceso de encriptacion en la implementacion de su codigo: * Firmas digitales (digital signatures) * Resumenes de mensajes (message digest) * Encriptadores (ciphers) * Simetricos y asimetricos * De flujo y de bloque * Codigos de autenticacion de mensajes (Message Authentication Codes, MACs) * Generadores de claves * Estandares: RSA, DSA, AES, Triple DES, SHA, PKCS#5, RC2, RC4, PCKS#11…

Autenticacion: APIs abstractas de autenticacion que pueden usar diferentes implementaciones concretas * Tarjetas inteligentes (Smartcards). * Kerberos. * usuario / password con LDAP o NIS bases de datos. Control de acceso: API de permisos que permite a los desarrolladores crear aplicaciones que necesitan un control de acceso de grano-fino a ciertos recursos basado en: * La identidad del usuario que ejecuta la aplicacion. * El lugar de donde viene la aplicacion (Web, disco duro…) * El que firma (sign) el programa. Comunicaciones Seguras: APIs para gestionar comunicaciones seguras basadas en los principales estandares: Transport Layer Security (TLS) * Secure Sockets Layer (SSL) * Kerberos (accesible a traves de GSS-API) * Simple Authentication and Security Layer (SASL) * HTTPS sobre SSL/TSL De esta forma se permite identificar los extremos de una comunicacion y protege la integridad y privacidad de la informacion transmitida entre ellos. Infraestructura de llave publica: Herramientas y APIs para gestionar claves y certificados: * Certificados y listas de revocacion de certificados X. 509 * Creadores y verificadores de certificados PKIX (RFC 3280) * On-line Certificate Status Protocol (OCSP) Almacenes de claves: PKCS#11, PKCS#12 * Almacenes de certificados: LDAP. VII. Modelo sandBox como arquitectura de seguridad. La esencia de este modelo describe al codigo local como confiable de tal manera que tiene permitido el acceso completo a los recursos vitales del sistema, mientras que el codigo descargado remotamente no es confiable y puede acceder unicamente a recursos limitados provistos dentro del sandbox. Estos recursos limitados son definidos por un manejador de seguridad (Security Manager). Algunas de las funciones que prohibe el sandbox son: * Leer o escribir en el disco duro. Realizar una conexion con cualquier host, excepto el originario del applet que se este ejecutando. * Creacion de nuevos procesos. * Cargar una libreria dinamica y hacer llamados a metodos nativos. Este fue el primer modelo de seguridad que se utilizo en Java, (version jdk 1. 0). A partir de alli se fue evolucionando, para que el manejo de recursos en la maquina ejecutora del applet fuera un poco mas flexible, es decir, a partir de firmas digitales y/o politicas se podria tener acceso a mas recursos, mas alla de los que permitia la “caja de arena”. El modelo SandBox cuenta con 5 elementos principales, que se encuentran a continuacion:

Permisos: Cada clase Java contiene varios tipos de permisos que definen las actividades que puede ejecutar. A partir de dichos permisos, se definen los parametros del sandbox. Un permiso esta compuesto por un tipo (que es obligatorio), un nombre y unas acciones (que son opcionales). Los tipos de permiso mas comunes son: File permission, socket permission, runtime permission, porperty permission, awt permission, net permission, security permission, serializable permission y all permission. Keystores: Las firmas de codigo, son una forma en la cual el codigo puede ser garantizado.

El codigo firmado depende de los certificados de llaves publicas. Los certificados estan guardados en una ubicacion (archivo) llamado keystore, el cual puede ser consultado para encontrar un certificado para firmar un codigo, o para revisar quien es el firmante del codigo que se esta ejecutando en un momento dado. Fuentes de codigo: Las fuentes de codigo son un combinacion de bases de codigo y de firmas. El campo para firmas debe coincidir con un alias listado previamente en el keystore. Bases de codigo: Las cuales pueden ser cualquier direccion valida URL, en la cual se puede especificar desde donde se ha cargado una clase.

La ubicacion, es especificada como una direccion URL dentro del mismo sistema, o puede ser una direccion de red. Las fuentes de codigo son utilizadas para dar permisos de acceso a un archivo o a un directorio. Dominios de proteccion: Un dominio de proteccion es una asociacion de permisos con un codigo fuente determinado. Los dominios de proteccion, son el concepto basico del sandbox, y permiten conocer que tiene permitido hacer el codigo cargado desde algunos sitios, por ejemplo se podria establecer que el codigo cargado desde www. sun. com tiene permitido leer archivos del disco.

Archivos de politicas: Son el elemento administrativo que controla el sandbox. Contienen una o mas entradas que definen un dominio de proteccion. Generalmente se encuentran dos archivos de politicas en uso: un archivo de politicas global, el cual es usado por todas las instancias de la maquina virtual; y un archivo especifico de politicas de usuario. Todos los archivos de politicas, son archivos de texto simple que pueden ser editados por el policytool, o a mano. VIII. Modelo de applets firmados Mas que un modelo, es una extension que se hizo al Sandbox, para disminuir un poco su rigidez, debido a que el sandbox en el jdk 1. era demasiado restrictivo con los programas remotos, y no se permitia que hicieran nada util. Al introducir los applets firmados, se permitio que estos siguieran siendo ejecutados con los recursos del Sandbox, sin embargo, tambien se permitia establecer permisos especiales para recursos mas alla de la restriccion, es decir, a estos applets se le permitia el acceso a todos los recursos. De esta manera, desde el jdk 1. 1, se podia tener acceso a un rango mas amplio de recursos, previamente configurando en la instalacion del jdk las firmas que se deseaban permitir.

Adicion del control de acceso de granularidad fina: Debido a que el modelo anterior, solamente contemplaba dos niveles de accesos de recursos: el primero el acceso a los recursos con la restriccion del sandbox y el segundo el acceso de todos los recursos (solo a los applets firmados), se introdujo un sistema de control de permisos de grano fino, el cual permitia dar permisos a segmentos de codigo especificos para acceder a recursos del sistema especificos por medio de la autenticacion de su firmante.

Para obtener estos permisos, se hizo indispensable el manejo de politicas, que eran las encargadas de establecer el acceso a los recursos, desde el total de ellos, hasta los que se tenia en la “caja de arena” Esta adicion de las politicas se hizo presente a partir del jdk 1. 2. Este manejo de permisos para el codigo, se hizo aplicable tanto para el codigo local como para el codigo remoto. En la figura 5 se puede observar que el codigo (local o remoto) pasa por una serie de politicas para el acceso a los recursos de la maquina, por lo tanto, se hizo mucho mas facil la administracion de las politicas y permisos en el sistema.

IX. El entorno de ejecucion en JAVA La ejecucion de un programa Java consiste en interpretar los bytecodes, es decir, en transformarlos en codigo del sistema y ejecutar ese codigo conforme se va interpretando. La JVM es la encargada de realizar esta tarea. Por suerte, el codigo a interpretar no es un lenguaje de alto nivel, los bytecodes son en realidad codigo maquina escrito para el juego de instrucciones de la JVM, por lo que el proceso de interpretacion es mas rapido que el de otros lenguajes.

Ademas, la maquina virtual puede emplear los denominados JIT (Just In Time Compiler), que traducen los bytecodes a codigo nativo optimizado una sola vez de modo que cada vez que la JVM vuelve a invocarlo se ejecuta directamente la version ya interpretada. Antes de que la JVM comience este proceso de interpretacion debe realizar una serie de tareas para preparar el entorno en el que el programa se ejecutara. Este es el punto en el que se implementa la seguridad interna de Java. Hay tres componentes en el proceso: Cargador de clases: Este elemento se encarga de separar las clases que carga para evitar ataques.

En Java 2 se definen tres grupos de clases asociados a distintas rutas de busqueda: clases del sistema (asociadas a la ruta de arranque o boot class path), clases de extension del sistema (asociadas a la ruta de extension o extension class path) y clases del usuario o la aplicacion (asociadas a la ruta de clases del usuario o la aplicacion user class path). El orden de busqueda de las clases es: sistema, extension y usuario. Cuando una clase se encuentra se detiene la busqueda (una aplicacion solo podria reemplazar una clase del sistema modificando la ruta de arranque, y eso no es posible sin tener acceso total al sistema).

El cargador de clases es una clase Java y puede ser extendida para definir cargadores de clases especiales, pero solo por las aplicaciones; si un applet pudiera definir su propio cargador podria modificar el cargador del sistema y potencialmente tomar la maquina en la que se ejecuta el navegador. Verificador de archivos de clases: La funcion de este componente es validar los bytecodes. Aunque esta tarea podria parecer absurda, no lo es, ya que no todos los bytecodes tienen por que ser correctos, pues se pueden generar a mano o empleando compiladores modificados.

El sistema distingue entre codigo en el que se confia (generalmente las clases del sistema y las validadas por el usuario) y codigo en el que no se confia. Las clases consideradas seguras no se validan, pero el resto si. El verificador de archivos de clases forma parte de la JVM y, por lo tanto, solo puede ser reemplazado cambiando la maquina virtual. Gestor de seguridad: Se encarga de comprobar el acceso en tiempo de ejecucion. Es una clase del sistema y puede ser extendida por las aplicaciones. La implementacion por defecto de Java 2 define un sistema basado en politicas de acceso.

A continuacion se resume el proceso de seguridad interna de java por medio de la siguiente figura: Desde su creacion el entorno Java ha tenido presentes los problemas de seguridad y ha definido un modelo para controlar y limitar el acceso a los recursos desde los programas y aplicaciones. El modelo de seguridad ha ido evolucionando con las distintas versiones del Entorno de Desarrollo Java (de aqui en adelante denominado JDK, por sus siglas en ingles), pasando de un modelo muy sencillo y restrictivo, el del JDK 1. 0, a uno mas complejo y flexible desde la aparicion del JDK 1. 2. X. Mecanismos de seguridad en JAVA

Java fue disenado para ofrecer las siguientes medidas de seguridad basicas: Integracion de un sistema de control de permisos para los programas: Java define un mecanismo (denominado mecanismo del cajon de arena) que permite controlar que se le permite hacer a un programa y controlar como accede a los recursos. Encriptacion y uso de certificados: Se definen mecanismos para que los programadores puedan firmar el codigo, de manera que los usuarios puedan verificar quien es el propietario del codigo y que este no ha sido modificado despues de ser firmado. La seguridad se basa en tres componentes fundamentales del entorno de ejecucion:

El cargador de clases (Class Loader): El cual determina como y cuando pueden cargar codigo los programas y garantiza que los componentes del sistema no han sido reemplazados. El verificador de archivos de clases (Class file verifier): encargado de garantizar que el codigo tiene el formato correcto, que el bytecode no viola las restricciones de seguridad de tipos de la JVM, que las pilas internas no puedan desbordarse ni por arriba ni por abajo y que las instrucciones en bytecode tengan parametros de tipos correctos. El gestor de seguridad (Security Manager): disponible para controlar el acceso a los recursos en tiempo de ejecucion.

Los recursos sobre los que tiene control son multiples: E/S de red y ficheros, creacion de cargadores de clases, manipulacion de hilos de ejecucion, ejecucion de programas externos (del SO), detener la JVM, cargar codigo nativo en la maquina virtual, realizar determinadas operaciones en el entorno de ventanas o cargar ciertos tipos de clases. XI. Seguridad en el JDK 1. 0 El modelo de seguridad original de la plataforma Java es el conocido como el modelo del cajon de arena (sandbox model), que proporcionaba un entorno muy restringido en el que ejecutar codigo no fiable obtenido de la red.

En este modelo trabajamos con dos niveles de acceso a los recursos: total, para programas locales, o muy restringido, para programas remotos. La seguridad se consigue gracias al empleo del cargador de clases, el verificador de clases y el gestor de seguridad. El obstaculo fundamental de este modelo es que es demasiado restrictivo, ya que no permite que los programas remotos hagan nada util, por estar restringidos al modelo del cajon de arena. XII. Seguridad en el JDK 1. 1 Como el modelo del JDK 1. era demasiado restrictivo se introdujo el concepto de codigo remoto firmado, que sigue garantizando la seguridad de los clientes, pero permite que codigo obtenido remotamente salga del cajon y tenga acceso a todos los recursos, siempre y cuando este firmado por una entidad en la cual cliente confia. Aunque esto mejora un poco la situacion, sigue siendo un control de dos niveles: total para codigo local o remoto firmado y restringido para codigo remoto sin firma o con firmas no validadas por el cliente. Ademas del codigo firmado, el JDK 1. 1 introdujo otras mejoras de seguridad:

Las herramientas: programas que responden al nombre de jar y javakey. El primero de ellos no es mas que un programa archivador con un formato compatible con el zip, que permite reunir un conjunto de clases y otros ficheros (como por ejemplo imagenes o texto) en un solo archivo, almacenado normalmente con la extension . jar. Esto hace posible la transferencia de aplicaciones de un modo compacto, en una sola conexion, y el firmado de los programas de modo conjunto. El programa javakey es el que permite el firmado de clases en los ficheros jar.

El API de seguridad introdujo paquetes de clases que proporcionan funciones criptograficas a los programadores, permitiendo el desarrollo de aplicaciones que usen estas tecnicas de modo estandar. El API estaba disenada para ser extensible e incluia herramientas para: generar firmas digitales, resumenes de mensajes, gestion de claves y el uso de listas de control de accesos (ACLs). Los algoritmos criptograficos se proporcionaban separados en la Extension Criptografica de Java (JCE), como un paquete adicional al JDK estandar, principalmente por los problemas de exportacion de los EEUU. XIII.

Seguridad en JDK 1. 2 En el JDK 1. 2 se han introducido nuevas caracteristicas que mejoran el soporte y el control de la seguridad: Control de acceso de grano fino: Uno de los problemas fundamentales de la seguridad en el JDK 1. 1 es que el modelo solo contempla dos niveles de permisos: acceso total o cajon de arena. Para solventar el problema el JDK 1. 2 introduce un sistema de control de permisos de grano fino que peremite dar permisos especificos a trozos de codigo especificos para acceder a recursos especificos en el cliente, dependiendo de la firma del codigo y/o el URL del que este se obtuvo.

Control de acceso aplicado a todo el codigo: El concepto de codigo firmado es ahora aplicable a todo el codigo, independientemente de su procedencia (local o remoto). Facilidad de configuracion de politicas de seguridad: La nueva arquitectura de seguridad permite el ajuste sencillo de los permisos de acceso usando un fichero de politicas (policy file) en el que se definen los permisos para acceder a los recursos del sistema para todo el codigo (local o remoto, firmado o sin firmar). Gracias a ello, el usuario puede bajar aplicaciones de la red, instalarlas y ejecutarlas asignandoles solo los permisos que necesiten.

Estructura de control de acceso extensible: En versiones anteriores del JDK cuando se deseaba crear un nuevo tipo de permiso de acceso era necesario anadir un nuevo metodo check a la clase del gestor de seguridad. Esta version permite definir permisos tipo que representan un acceso a recursos del sistema y el control automatico de todos los permisos de un tipo correcto, lo que repercute en que, en la mayoria de casos, se hace innecesario anadir metodos al gestor de seguridad. En la figura mostrada a continuacion se presenta el modelo de seguridad de Java 2.

Al igual que sucedio con el JDK 1. 1 en el Java 2 han aparecido o se han mejorado las herramientas y el API de seguridad. En Java 2 se incluyen cuatro herramientas de seguridad: * jar. Esta es basicamente la misma herramienta que aparecio en el JDK 1. 1 y se emplea para generar ficheros JAR. * keytool. Esta es una herramienta para la generacion de pares de claves (publicas y privadas), importar y exportar certificados X. 509 (versiones 1, 2 y 3), generar certificados X. 509 V1 autoformados y gestionar almacenes de claves (keystores). * jarsigner.

Este programa se emplea para firmar ficheros JAR y verificar las firmas de ficheros JAR ya firmados. La herramienta emplea los almacenes de claves para buscar los datos que necesita para firmar ficheros (una clave privada), verificar firmas (clave publica) o verificar claves publicas (certificados). Esta herramienta junto a a la anterior reemplazan al antiguo javakey. * policytool. Esta utilidad se emplea para crear y modificar los ficheros de configuracion de politicas de seguridad del cliente de modo sencillo. El API de seguridad se ha incrementado con nuevos subpaquetes que mejoran el soporte de certificados X. 09 y permiten crear Listas de Revocacion de Certificados (CRLs) y Peticiones de Firmado de Certificados (CSRs). XIV. Dominios protegidos El concepto de dominio protegido es fundamental para la seguridad de los sistemas. El alcance de un dominio esta definido por el conjunto de objetos que estan directamente accesibles para un principal, donde principal es una entidad en el sistema informatico a la que se le han asignado permisos. El cajon de arena del JDK 1. 0 es un ejemplo de dominio de proteccion con limites fijos. El concepto de dominio protegido proporciona un mecanismo adecuado para agrupar y aislar unidades de proteccion.

Por ejemplo, se pueden separar dos dominios de forma que la interaccion entre ambos unicamente sea posible a traves de codigo del sistema o de un protocolo explicito para la comunicacion entre ambos. Los dominos protegidos se dividen generalmente en dos categorias: 1. Dominios del sistema, que controlan el acceso a los recursos del sistema (sistema de archivos, acceso a la red, E/S). 2. Dominios de aplicacion, que controlan el acceso a los recursos de una aplicacion. Conceptualmente un dominio incluye un conjunto de clases cuyas instancias tienen asignados los mismos permisos.

Los dominios de proteccion se determinan mediante la politica de seguridad activa en cada momento. El entorno Java mantiene una asociacion entre el codigo (clases e instancias) y sus dominios de proteccion. Esta relacion es de varios a uno, es decir, distintas clases pueden pertenecer a un mismo dominio, pero cada clase solo esta asociada un dominio. Para los dominios de proteccion se emplea otra tabla que relaciona cada dominio con sus permisos correspondientes. Evidentemente esta asociacion es de muchos a muchos, varios dominios pueden tener el mismo permiso y cada dominio puede tener multiples permisos.

Un hilo de ejecucion puede trabajar unicamente en un dominio protegido o puede ir pasando del dominio de la aplicacion al del sistema y viceversa. Esto tiene implicaciones importantes en la seguridad, se plantean dos escenarios: 1. Si una aplicacion accede al sistema y solicita una operacion que requiere permisos del dominio del sistema, se debe garantizar que la aplicacion no tendra acceso directo al dominio del sistema, es decir, que su domino de proteccion no obtendra ningun permiso del dominio del sistema. 2.

Si una clase del sistema invoca un metodo de la aplicacion, es esencial que los permisos de ese metodo cuando se ejecute sean los del domino de la aplicacion, no los del sistema. En definitiva, el modelo de dominios protegidos debe garantizar que un dominio menos poderoso no pueda obtener permisos adicionales al invocar o ser invocado por otro dominio mas poderoso. Ocasionalmente sera necesario que codigo fiable de acceso temporal a mas recursos de los que normalmente estan disponibles para la aplicacion que lo invoco.

Por ejemplo, una aplicacion no tiene porque tener acceso directo a los ficheros que contienen los tipos de letra, pero la utilidad del sistema que muestra un documento debe conseguir esos tipos. Para solucionarlo se emplea el metodo doPrivileged, que esta disponible en todos los dominios. Cuando un fragmento de codigo llama al metodo doPrivileged, se considera que el conjunto de permisos activo incluye un permiso si lo permite el domino protegido del codigo invocante y todos los dominios en los que se entra a continuacion.

Durante la ejecucion, cuando se solicita acceso a un recurso del sistema, el codigo de gestion de recursos invoca directa o indirectamente a un metodo especial de la clase AccessControler que evalua la peticion y decide si debe concederse o no el acceso. Si se concede el permiso la ejecucion continua y si no se lanza una excepcion de seguridad. XV. Modelo de permisos Los permisos en Java son clases que representan accesos a recursos del sistema. La clase fundamental es java. security. Permission, que es una clase abstracta de la que se deben definir subclases para representar accesos especificos.

Un permiso consta de un objetivo y una accion, aunque puede omitirse cualquiera de los dos. Por ejemplo, para acceder al sistema de ficheros local el objetivo puede ser un directorio o un fichero y las acciones pueden ser: leer, escribir, ejecutar y borrar. Generalmente, una clase de permiso pertenece al paquete en el cual sera usada. Por ejemplo, el permiso que representa el acceso al sistema de ficheros local es java. io. FilePermission. Como ejemplo de permiso, el siguiente fragmento de codigo se puede emplear para generar un permiso de lectura del archivo «abc» en el directorio /tmp: perm = new java. io.

FilePermission(«/tmp/abc», «read»); Si queremos definir nuevos permisos es crucial implementar el metodo abstracto implies. Basicamente, la afirmacion a implica b tiene el significado intuitivo, si una clase tiene el permiso a tiene tambien el permiso b. Esto es muy importante a la hora de tomar decisiones de control de acceso. La clase abstracta java. security. Permission tiene asociadas dos clases importantes: La clase abstracta java. security. PermissionCollection, que representa una coleccion de objetos de tipo Permission de una misma categoria (como por ejemplo de acceso a ficheros), para simplificar el agrupamiento.

La clase final java. security. Permissions, que representa una coleccion de colecciones de objetos Permission. Antes del acceder a un recurso se toma la decision de control de acceso al recurso, basada en los permisos que el codigo en ejecucion tiene. Aunque cualquier codigo puede crear sus propios objetos de permisos, esto no implica que tales objetos obtengan los correspondientes permisos de acceso. Solo los objetos de permisos que gestiona el sistema en tiempo de ejecucion de Java obtienen los permisos que representan. Los permisos definidos por el JDK 1. 2 son: AllPermission Es un permiso que asigna todos los demas permisos.

AWTPermission Permisos para el AWT (acceso al portapapeles, a los eventos, etc. ). FilePermission Un permiso java. io. FilePermission representa permisos de acceso a archivos o directorios y consta de un nombre de ruta y un conjunto de acciones validas para esa ruta. Si la ruta tiene el valor * se considera que el permiso se asigna a todos los ficheros del directorio acutal y si tiene el valor -, se refiere a los archivos del directorio actual y, recursivamente, a todos lo ficheros del directorio actual. Las acciones posibles son: read, write, execute y delete. NetPermission Un permiso java. net.

NetPermission es para varios permisos de red. Un permiso de red contiene un nombre pero no tiene lista de acciones, o se tiene el permiso o no se tiene. PropertyPermission Permisos para manipular properties. ReflectPermission Permisos para efectuar operaciones reflectivas. Son permisos sin acciones. RuntimePermission Permisos para tiempo de ejecucion (acceso a ClassLoaders, SecurityManager, Threads, etc). Son permisos sin acciones. SecurityPermission Permisos relacionados con la seguridad. Son permisos sin acciones. SerializablePermission Permisos relacionados con la serializacion de objetos.

Son permisos sin acciones. SocketPermission Un permiso java. net. SocketPermission representa un acceso a la red a traves de sockets. Un SocketPermission consta de una direccion de host y un conjunto de acciones especificando formas de conectar. La especificacion de la direccion del host se hace del siguiente modo: host = (nombreHost | dirIP)[:rangoPuertos] rangoPuertos = numPuerto | -numPuerto | numPuerto-[numPuerto] El nombre del host puede ser segun el DNS o en formato IP. El rango de puertos es opcional. Las formas de conectar posibles son: accept, connect, listen y resolve. XVI. Politicas de Seguridad

En el JDK 1. 2 las politicas de seguridad se especifican en uno o mas ficheros de configuracion de politicas. Estos ficheros especifican que permisos estan habilitados para el codigo obtenido de los origenes de codigo especificados. Un archivo de politicas de seguridad se puede escribir directamente con un editor de texto ascii o usando la herramienta policytool del JDK. Por defecto hay un archivo de politicas del sistema y, opcionalmente, otro archivo de politicas del usuario. El objeto Policy por defecto se inicaliza la primera vez que se invoca su metodo getPermissions() o cuando se invoca su metodo refresh().

La inicializacion supone el analisis (parsing) de los archivos de configuracion de politicas y la configuracion del objeto Policy. Se puede encontrar una discusion sobre las politicas de seguridad en la documentacion sobre seguridad del JDK 1. 2: http://java. sun. com/products/jdk/1. 2/docs/guide/security/PolicyFiles. html. XVII. Verificador de archivos de clases Cualquier maquina virtual Java contiene un verificador de clases que asegura que las clases cargadas tienen la estructura interna correcta. Si el verificador de clases descubre un problema dentro de una clase genera una excepcion. Debido a que una clase es una secuencia de ytes, la maquina virtual no puede saber si una clase en particular es realmente un bytecode correcto o no. Como consecuencia de esto, todas las implementaciones de la maquina virtual disponen de un verificador de clases que puede ser invocado sobre clases no seguras, asegurando de esta forma su correccion. Uno de los objetivos del verificador de clases es ayudar a obtener aplicaciones robustas. Si un programador malintencionado generara una clase que contuviera un metodo cuyo codigo en bytes incluyera una instruccion de salto al final del metodo podria causar que la maquina virtual no funcionara si el metodo es invocado.

La especificacion recomienda que la verificacion del bytecode de las aplicaciones se realice justo despues de que la clase halla sido cargada. El verificador de clases lleva a cabo su tarea de comprobacion en dos fases: * La primera fase tiene lugar justo despues de cargar la clase. En ella el verficador de clases comprueba la estructura interna de la clase, incluyendo la comprobacion de la integridad de los bytecodes. * La segunda fase se lleva a cabo mientras se ejecuta el bytecode de la clase. En esta el verificador de clases confirma la existencia de las referencias simbolicas a clases, campos y metodos. XVIII.

Cargador de clases El cargador de clases es el responsable de encontrar y cargar los bytecodes que definen las clase. Una vez que se cargan, los bytecodes son verificados antes de que se puedan crear las clases reales. Los cargadores de clases son a su vez clases Java, pero, ? como se carga el primero?. En principio una maquina virtual Java debe incluir un cargador de clases primario, que es el encargado de arrancar el sistema de carga de clases. Este cargador estara escrito en un lenguaje como el C y no aparece en el contexto Java. El cargador primario carga las clases del sistema de archivos local de modo dependiente del sistema.

El cargador de clases cumple tambien varias tareas relacionadas con la seguridad: * El responsable de cargar las clases del paquete java. * es el cargador primario, de hecho, todas las clases de este paquete tienen un cargador de clases null. Este hecho es importante para la seguridad por dos razones: en primer lugar nos garantiza que se cargaran correctamente, algo muy importante, ya que son basicas para el correcto funcionamiento del sistema, y en segundo tambien nos asegura que se cargaran del sistema de archivos local, lo que evita que una aplicacion remota pueda reemplazarlas. El cargador de clases proporciona espacios de nombres diferentes para clases cargadas de origenes diferentes, lo que evita que haya colisiones de nombres entre clases cargadas desde origenes distintos. Clases cargadas de fuentes diferentes no pueden comunicarse dentro del espacio de la maquina virtual, lo que evita que programas no fiables obtengan informacion de otros que si lo son. La implementacion por defecto del ClassLoader del JDK busca las clases segun los siguientes pasos: * Comprueba que la clase no esta cargada. * Si la clase no esta cargada y el cargador actual tiene un cargador padre, se la pide a este y si no al argador principal. * Llama a un metodo personalizable para intentar encontrar la clase de otra forma. * Si despues de estos pasos la clase no se ha encontrado se lanza una excepcion ClassNotFound. El sistema determina el tipo de cargador a emplear del siguiente modo: * Cuando se carga una aplicacion, se emplea una nueva instancia de la clase URLClassLoader. * Cuando se carga un applet, se emplea una nueva instancia de la clase AppletClassLoader. * Cuando se llama directamente al metodo java. lang. Class. ForName, se emplea el cargador principal. * Si la solicitud de carga la realiza una clase existente, se emplea el cargador de esa clase.

Para crear un ClassLoader personalizado basta implementar el metodo loadClass en una subclase: protected abstract Class loadClass(String name, boolean resolve) throws ClassNotFoundException En el metodo hay que realizar cinco operaciones: 1. Comprobar si la clase esta cargada 2. Si no lo esta, cargamos los datos de la clase segun el metodo que queramos (por ejemplo mediante una consulta a una base de datos). 3. Llamamos al metodo defineClass() para convertir los bytes en una clase. 4. Resolver la clase invocando el metodo resolveClass(). 5. Retornamos la nueva clase creada.

Para evitar tener que escribir nuesto propio cargador de clases el JDK 1. 2 introduce el URLClassLoader, que es una subclase de SecureClassLoader. Con esta clase podemos cargar cualquier clase que pueda ser localizada mendiante un URL (file:, http:, jar:, etc). Si lo que necesita el programador es hacer una operacion como encriptar u obtener la clase de una BDA, puede hacerlo con una subclase de la clase URLClassLoader. Para usar un URLClassLoader solo es necesario decirle al cargador donde estan las clases, no hace falta hacer una subclase a menos que se tengan requisitos muy especiales.

Los URLs que terminan con /se consideran directorios y cualquier otra cosa se intenta cargar como archivo JAR. XIX. Gestor de seguridad en JAVA Actualmente, todo el codigo del sistema del JDK invoca metodos del Gestor de seguridad para determinar la politica de seguridad activa y realizar verificaciones de control de acceso. Por defecto, cuando se ejecutan applets siempre se carga una implementacion del gestor de seguridad, pero cuando se lanzan aplicaciones esto no es asi. Si el usuario desea que se instale uno debe invocar la maquina virtual definiendo la propiedad java. ecurity. manager: java -Djava. security. manager NomApp o la aplicacion debe invocar el metodo setSecurityManager de la clase java. lang. System para instalar un gestor. Si se le asigna valor a la propiedad java. security. manager se instalara el gestor de seguridad especificado: java -Djava. security. manager=iti. GestorSeguridad NomApp Un aspecto muy importante del gestor de seguridad es que una vez cargado no se puede reemplazar, de modo que ni las applets ni las aplicaciones pueden instalar el suyo cuando el usuario (applicaciones) o el sistema (applets) ya han cargado uno.

Por ultimo hay que senalar que el gestor de seguridad esta muy relacionado con la clase AccessControler: la clase SecurityManager representa el concepto de un punto central de control de acceso, mientras que la clase AccessControler implementa un algoritmo concreto de control de acceso con caracteristicas especiales como el metodo doPrivileged(). En versiones del JDK anteriores a la 1. 2, los programadores redefinian el gestor de seguridad cuando necesitaban metodos de control de acceso especificos, pero ahora el metodo adecuado para hacer esto es emplear el AccessController.

XX. Ficheros de configuracion La politica de seguridad se configura a traves de al menos dos ficheros del sistema: $JAVA_HOME/lib/security/java. policy $JAVA_HOME/lib/security/java. security donde $JAVA_HOME es el directorio raiz del jdk1. 2. A continuacion describiremos el formato de los dos ficheros, comenzando por sus caracteristicas comunes. XXI. Variables en los ficheros de configuracion Tanto el fichero java. policy como el fichero java. security pueden incorporar variables que les permiten hacer mas dinamica la configuracion de la politica de seguridad.

Las variables de extension son similares a las variables del shell de Unix, por ejemplo la linea permission java. io. FilePermission «${user. home}», «read» permite que cualquier usuario disponga de permiso de lectura sobre su directorio home. La propiedad ${user. home} tomara el valor del directorio del usuario. Otra variable muy util es ${/}, cuyo valor sera el caracter de separacion de directorios propio del sistema operativo, es decir, en Unix equivale a / y en DOS a . Nota: No se pueden anidar propiedades, por ejemplo ${user. ${foo}}, no funcionaria bien incluso si foo tuviera el valor home.

El fichero java. policy: La politica de seguridad del sistema se configura a partir de uno o mas ficheros de configuracion. Estos ficheros indican que permisos se conceden a que codigo y para que recursos especificos. El fichero de configuracion de la politica de seguridad esencialmente contiene una lista de entradas. Puede contener una entrada keystore y una o mas entradas grant. El keystore es la base de datos de claves privadas y sus certificados asociados. La entrada keystore sirve para indicar donde consultar las claves publicas de las entidades firmantes especificadas en las entradas grant del fichero.

La entrada keystore debe aparecer en el fichero si cualquier entrada grant especifica el alias de una entidad que firma. El fichero java. security: En este fichero se almacena las propiedades necesarias para configurar la seguridad del sistema. En el se almacenan propiedades tan necesarias como los proveedores de seguridad instalados en el sistema, la ubicacion de los ficheros de configuracion, nombre de la clase que implementa la politica de seguridad, etc. Los proveedores instalados se registran anadiendo al fichero una linea con el formato: security. provider. =nombre_clase_provider donde n indica el numero de proveedor. XXII. Herramientas de seguridad Java 2 incluye una serie de herramientas de seguridad que simplifican la gestion de la misma por parte de los usuarios. Keytool : La herramienta keytool se emplea para gestionar un almacen de claves (keystore), entre otras cosas permite: * Crear pares de claves (publica y privada). * Emitir solicitudes de certificados (que se envian al CA apropiado). * Importar replicas de certificados (obtenidos del CA contactado). * Designar claves publicas de otros como de confianza.

El almacen de claves es una base de datos protegida que contienen claves y certificados para un usuario o grupo de usuarios. El acceso al mismo esta protegido por un sistema de contrasenas y ademas, cada clave privada puede protegerse con una contrasena individual. Jar: La herramienta jar se emplea para crear archivos JAR. El formato JAR permite reunir multiples ficheros (clases, imagenes, textos) en un unico archivo. Cuando se desea firmar una aplicacion o applet se usa el programa jar para empaquetarla y luego se firma el resultado usando el programa jarsigner.

Jarsigner: La herramienta jarsigner se emplea para firmar y validar la firma de archivos JAR. La herramienta jarsigner emplea el almacen de claves que crea y gestiona el programa keytool para buscar las claves privadas y certificados que necesita para firmar archivos JAR. Como los accesos al almacen de claves y a las claves privadas estan protegidos con contrasena, solo los usuarios que los conozcan podran acceder a las claves para firmar archivos JAR. Policytool: La herramienta policytool se emplea para crear y modificar los archivos de configuracion de politicas.

La herramienta tiene una interfaz grafica comoda para trabajar con estos ficheros, lo que la hace preferible a la edicion manual. Algoritmo: Un algoritmo es una implementacion de un motor. P. ej. el algoritmo MD5 es una implementacion del motor de algoritmos de resumen de mensajes. La implementacion interna puede variar dependiendo del codigo que proporcione la clase MD5. Proveedor: Un proveedor es el encargado de proporcionar la implementacion de uno o varios algoritmos al programador (es decir, darle acceso a una implementacion interna concreta de los algoritmos).

La JCA define el concepto de proveedor mediante la clase Provider del paquete java. security. Se trata de una clase abstracta que debe ser redefinida por clases proveedor especificas. El constructor de una clase proveedor ajusta los valores de varias propiedades que necesita el API de seguridad de Java para localizar los algoritmos u otras facilidades implementadas por el proveedor. La clase Provider tiene metodos para acceder al nombre del proveedor, el numero de version y otras informaciones sobre las implementaciones de los algoritmos para la generacion, conversion y gestion de claves y la generacion de firmas y resumenes.

Para entender como funcionan los proveedores daremos un ejemplo. Supongamos que un programa necesita una implementacion del algoritmo MD5. Para obtenerla el programador necesita crear una instancia del mismo y lo hara escribiendo la siguiente linea de codigo: MessageDigest m = MessageDigest. getInstance(«MD5»); Internamente, el metodo getInstance() solicita a la clase java. security. Security que le proporcione el objeto solicitado. Como no se ha especificado proveedor la clase Security consulta a todos los proveedores disponibles, solicitando una implementacion del algoritmo «MD5», hasta que encuentra una o se queda sin proveedores.

La consulta se realiza segun la lista de proveedores del archivojava. security, que por defecto solo contiene la entrada: Security. provider. 1=sun. security. provider. Sun Si se encuentra una implementacion se retorna una instancia de la clase retornada por el proveedor y si no se genera la excepcion NoSuchAlgorithmException. En caso de que se haya obtenido una implementacion, para generar el resumen de un vector de bytes (p. ej. buf) con el MD5 bastara invocar el metodo update() del algoritmo. Para obtener el vector resumen invocaremos el metododigest(): m. update(buf); byte[] resumen = m. digest();

Por ultimo solo nos queda saber como se gestionan los proveedores, es decir, como se instalan o eliminan. Existen dos modos de hacerlo: Estaticamente, editando las entradas del fichero java. security Dinamicamente, invocando desde el programa los metodos addProvider() o insertProvider() de la clase java. security. Security para anadirlos o al metodo removeProvider() Si un programador desea saber los proveedores disponibles puede emplear los metodos getProvider(«nombre») (para saber si un proveedor concreto esta instalado) o getProviders() (que retorna un vector de cadenas con los nombres de los proveedores). XXIV. Certificados en JAVA

Java ofrece un manejo de certificados, por medio de las clases que vienen con el jdk, pero este manejo de certificados, no es completo, ya que las clases de java permiten crear certificados, y a su vez estos son firmados por el propietario, pero para continuar con el proceso correcto en la creacion del certificado, se deberia proceder a enviar el certificado creado por java a una autoridad certificadora competente, porque de otra manera, si se utilizan unicamente los certificados creados con la herramienta de java, sin hacer su validacion con la autoridad certificadora el proceso queda a mitad y se corren muchos riesgos de seguridad.

XXV. Clases para el manejo de certificados en JAVA Las clases para el manejo de los certificados en java, aparecieron desde la version 1. 1 del jdk. Para esta primera version de java, fue introducida la interfaz java. security. Certificate, La cual debia ser implementada por clases especificas de las aplicaciones. A continuacion en la version Java 2, aparecio una nueva clase abstracta llamada java. security. cert. Certificate para reemplazar a la interfaz java. ecurity. Certificate, y comenzo a ser utilizada en todas las aplicaciones que se desarrollaban en la plataforma java 2 ya que era mas facil de usar que su predecesora y soportaba nuevas operaciones. En esta version de java, tambien aparecieron las clases para manejar listas de anulacion de certificados (CRL), las cuales resuelven el problema de los certificados perdidos o robados, y son listas que contienen conjuntos de certificados no validos.

A continuacion se presenta el conjunto de clases que permiten manejar los certificados en java, las cuales en su mayoria son abstractas, y algunos de sus metodos deben ser implementados dentro de la aplicacion que se van a utilizar. Clase java. security. cert. Certificate Esta es una clase abstracta, debido a que en la actualidad existen muchos tipos de ceritificados, y se basa en la nocion generica de lo que es un certificado. Clase CertificateFactory Esta clase permite importar en un programa uno o varios certificados que se encuentran en un archivo determinado, y se encuentra en el paquete java. ecurity. cert. Clase X509Certificate Ofrece una implementacion para el manejo de certificados X509, que son los mas conocidos actualmente. Esta es la unica implementacion especifica que ofrece java, si se desea soportar otro tipo de certificados dentro de una aplicacion, se debe realizar una implementacion propia. Clase X509CRLEntry Es una clase abstracta, que implementa a la interface X509Extension, la cual trabaja con certificados de tipo X509, y representa a los certificados anulados del mismo tipo. Clase X509CRL

Esta es la clase que permite trabajar con las listas de revocacion de certificados, y contiene muchos metodos similares a los utilizados para la clase certificado, tales como verify, getVersion, getIssuerDN, getSignature, getSigAlgName, getSigAlgOID, getSigAlgParams, con el fin de poder verificar la veracidad de la CRL Conclusiones: * El amplio espectro que java brinda a sus desarrolladores para enfrentar problemas de seguridad conocidos, refleja la necesidad tanto de los usuarios como de los proveedores de la implementacion de distintas medidas de seguridad a los servicios prestados en las tecnologias de la informacion. Nos podemos dar cuenta que gracias a que Java es un lenguaje robusto, y fuertemente tipificado, es mas dificil que por errores en la programacion, se atente contra la disponibilidad del sistema. * A medida que el medio va cambiando, y surgen nuevos requerimientos, se van agregando nuevas extensiones brindando una mayor seguridad, con el fin de poder llegar a tener todas las caracteristicas que deben cumplir los programas seguros. Referencias: * http://www. programacion. net/java/tutorial/security1dot2/1/#SecurityAPI Cracking DES: Secrets of Encryption Research, Wiretap Politics, and Chip Design . O’Reilly ; Associates, 1998. * Feghhi, Jalal; Feghhi, Jalil; Williams, Peter. Digital Certificates: applied Internet Security. Addison Wesley, 1999. * java. sun. com/docs/books/tutorial/security1. 2/. * ftp://ftp. javasoft. com/docs/jdk1. 2/security-spec. pdf. * http://sunsite. org. uk/rfc/rfc2246. txt. * http://www. rsa. com/rsalabs/faq/. * Schneier, Bruce. Applied Cryptography: Protocols, Algorithms, and Source Code in C, 2nd.

Edition. John Wiley ; Sons, 1996. * java. sun. com/products/jdk/1. 2/docs/guide/security/SecurityToolsSummary. html. * http://www. uv. es/~sto/cursos/seguridad. java/html/sjava. html#toc6 * http://java. sun. com/j2se/1. 4. 2/docs/guide/security/spec/security-specTOC. fm. html * http://www. programacion. com/java/tutorial/security1dot2/1/ * http://java. sun. com/developer/onlineTraining/Security/Fundamentals/Security. html#secIntro * http://www. alixa. org/? /Tutoriales/java4