6.3 Modelos de Seguridad en Java

Desde su creación 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 aquí en adelante denominado JDK, por sus siglas en inglés), pasando de un modelo muy sencillo y restrictivo, el del JDK 1.0, a uno más complejo y flexible desde la aparición del JDK 1.2.

En este apartado describiremos brevemente los mecanísmos de seguridad incorporados en Java y luego trataremos los modelos de seguridad definidos en las sucesivas versiones del JDK. Terminaremos dando una tabla comparativa de los distintos modelos de seguridad.

En siguientes apartados nos centraremos en la seguridad en Java 2 (JDK 1.2), que es la que tiene un modelo más completo y, en definitiva, incluye todos los anteriores.

Mecanísmos de seguridad

Java fue diseñado para ofrecer las siguientes medidas de seguridad básicas:

• Uso de un lenguaje de programación seguro. El lenguaje de programación Java está diseñado para ser seguro, como hemos comentado en el apartado anterior.
• Integración de un sistema de control de permisos para los programas. Java define un mecanismo (denominado mecanismo del cajón de arena) que permite controlar que se le permite hacer a un programa y controlar como accede a los recursos.
• Encriptación y uso de certificados. Se definen mecanísmos para que los programadores puedan firmar el código, de manera que los usuarios puedan verificar quien es el propietario del código y que este no ha sido modificado despues de ser firmado.

La seguridad se basa en tres componentes fundamentales del entorno de ejecución:

1. El cargador de clases (Class Loader), que determina como y cuando pueden cargar código los programas y garantiza que los componentes del sistema no han sido reemplazados.
2. El verificador de archivos de clases (Class file verifier), que garantiza que el código tiene el formato correcto, que el bytecode no viola las restriciones de seguridad de tipos de la JVM, que las pilas internas no puedan desbordarse ni por arriba ni por abajo y que las instucciones en bytecode tengan parámetos de tipos correctos.
3. El gestor de seguridad (Security Manager), que controla el acceso a los recursos en tiempo de ejecución. Los recursos sobre los que tiene control son multiples: E/S de red y ficheros, creación de cargadores de clases, manipulación de hilos de ejecución, ejecución de programas externos (del SO), detener la JVM, cargar código nativo en la máquina virtual, realizar determinadas operaciones en el entorno de ventanas o cargar ciertos tipos de clases.

En apartados posteriores se describirá que son y como funcionan estos componentes.

Seguridad en el JDK 1.0

El modelo de seguridad original de la plataforma Java es el conocido como el modelo del cajón de arena (sandbox model), que proporcionaba un entorno muy restringido en el que ejecutar código 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.

La pega fundamental de este modelo es que es demasiado restrictivo, ya que no permite que los programas remotos hagan nada útil, por estar restringidos al modelo del cajón de arena.

Seguridad en el JDK 1.1

Como el modelo del JDK 1.0 era demasido restrictivo se introdujo el concepto de código remoto firmado, que sigue garantizando la seguridad de los clientes, pero permite que código obtenido remotamente salga del cajón y tenga acceso a todos los recursos, siempre y cuando esté firmado por una entidad en la el cliente confía.

Aunque esto mejora un poco la situación, sigue siendo un control de dos nivels: total para código local o remoto firmado y restringido para código remoto sin firma o con firmas no validadas por el cliente.

Además del código firmado, el JDK 1.1 introdujo otras mejoras de seguridad:

1. Un par de herramientas de seguridad.
2. Un API para programación segura.

Las herramientas son los programas jar y javakey. El primero de ellos no es más que un programa archivador con un formato compatible con el zip, que permite reunir un conjunto de clases y otros fecheros (como por ejemplo imágenes o texto) en un solo archivo, almacenado normalmente con la extensión .jar. Esto hace posible la transferencia de aplicaciones de un modo compacto, en una sola conexión, 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 criptográficas a los programadores, permitiendo el desarrollo de aplicaciones que usen estas técnicas de modo estándar. El API estaba diseñada para ser extensible e incluía herramientas para: generar firmas digitales, resumenes de mensajes, gestión de claves y el uso de listas de control de accesos (ACLs).

Los algoritmos criptográficos se proporcionaban separados en la Extensión Criptográfica de Java (JCE), como un paquete adicional al JDK estándar, principalmente por los problemas de exportación de los EEUU.

Seguridad en Java 2

En el JDK 1.2 se han introducido nuevas características 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 sólo contempla dos niveles de permisos: acceso total o cajón de arena. Para solventar el problema el JDK 1.2 introduce un sistema de control de permisos de grano fino que peremite dar permisos específicos a trozos de código específicos para acceder a recursos específicos en el cliente, dependiendo de la firma del código y/o el URL del que este se obtuvo.
• Control de acceso aplicado a todo el código. El concepto de código firmado es ahora aplicable a todo el codigo, independientemente de su procedencia (local o remoto).
• Facilidad de configuración de políticas de seguridad. La nueva arquitectura de seguridad permite el ajuste sencillo de los permisos de acceso usando un fichero de políticas (policy file) en el que se definen los permisos para acceder a los recursos del sistema para todo el código (local o remoto, firmado o sin firmar). Gracias a ello, el usuario puede bajar aplicaciones de la red, instalarlas y ejecutarlas asignándoles sólo 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 añadir un nuevo método check a la clase del gestor de seguridad. Esta versión permite definir permisos tipo que representan un acceso a recursos del sistema y el control automático de todos los permisos de un tipo correcto, lo que repercute en que, en la mayoría de casos, se hace innecesario añadir métodos al gestor de seguridad.

En la figura Seguridad en el JDK 1.2 se presenta el modelo de seguridad de Java 2.

Seguridad en el JDK 1.2

Al igual que sucedió 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:

1. jar. Esta es básicamente la misma herramienta que apareció en el JDK 1.1 y se emplea para generar ficheros JAR.
2. keytool. Esta es una herramienta para la generación de pares de claves (públicas y privadas), importar y exportar certificados X.509 (versiones 1, 2 y 3), generar certificados X.509 V1 autofirmados y gestionar almacenes de claves (keystores).
3. 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 pública) o verificar claves públicas (certificados). Esta herramienta junto a a la anterior reemplazan al antiguo javakey.
4. policytool. Esta utilidad se emplea para crear y modificar los ficheros de configuración de políticas de seguridad del cliente de modo sencillo.

El API de seguridad se ha incrementado con nuevos subpaquetes que mejoran el soporte de certificados X.509 y permiten crear Listas de Revocación de Certificados (CRLs) y Peticiones de Firmado de Certificados (CSRs). Los nuevos subpaquetes son el java.security.cert y java.security.spec y los discutiremos en puntos posteriores.

Evolución del modelo de seguridad

En la tabla comparación modelos de seguridad se comparan los modelos de seguridad de Java en función de varias características.