Modelos de Seguridad en Java

Desde su creacin 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 ".#, a uno m$s comple%o y fle&ible desde la aparicin del JDK ".'. En este apartado describiremos brevemente los mecansmos de seguridad incorporados en Java y luego trataremos los modelos de seguridad definidos en las sucesivas versiones del JDK. (erminaremos dando una tabla comparativa de los distintos modelos de seguridad. En siguientes apartados nos centraremos en la seguridad en Java ' (JDK ".'!, que es la que tiene un modelo m$s completo y, en definitiva, incluye todos los anteriores.

Mecansmos de seguridad
Java fue dise)ado para ofrecer las siguientes medidas de seguridad b$sicas*

Uso de un lenguaje de programacin seguro. El lengua%e de programacin Java est$ dise)ado para ser seguro, como hemos comentado en el apartado anterior. Integracin de un sistema de control de permisos para los programas. Java define un mecanismo (denominado mecanismo del cajn de arena! que permite controlar que se le permite hacer a un programa y controlar como accede a los recursos. Encriptacin y uso de certificados. +e definen mecansmos para que los programadores puedan firmar el cdigo, de manera que los usuarios puedan verificar quien es el propietario del cdigo y que este no ha sido modificado despues de ser firmado.

,a seguridad se basa en tres componentes fundamentales del entorno de e%ecucin* ". El cargador de clases (Class Loader!, que determina como y cuando pueden cargar cdigo los programas y garanti-a que los componentes del sistema no han sido reempla-ados. '. El verificador de archivos de clases (Class file verifier!, que garanti-a que el cdigo tiene el formato correcto, que el bytecode no viola las restriciones de seguridad de tipos de la J./, que las pilas internas no puedan desbordarse ni por arriba ni por aba%o y que las instucciones en bytecode tengan par$metos de tipos correctos. 0. El gestor de seguridad (Security Manager!, que controla el acceso a los recursos en tiempo de e%ecucin. ,os recursos sobre los que tiene control son multiples* E1+ de red y ficheros, creacin de cargadores de clases, manipulacin de hilos de e%ecucin, e%ecucin de programas e&ternos (del +2!, detener la

J./, cargar cdigo nativo en la m$quina virtual, reali-ar 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 !"

El modelo de seguridad original de la plataforma Java es el conocido como el modelo del cajn de arena (sandbox model!, que proporcionaba un entorno muy restringido en el que e%ecutar cdigo no fiable obtenido de la red. En este modelo traba%amos con dos niveles de acceso a los recursos* total, para programas locales, o muy restringido, para programas remotos. ,a seguridad se consigue gracias al empleo del cargador de clases, el verificador de clases y el gestor de seguridad. ,a pega fundamental de este modelo es que es demasiado restrictivo, ya que no permite que los programas remotos hagan nada 3til, por estar restringidos al modelo del ca%n de arena.

Seguridad en el JDK !
4omo el modelo del JDK ".# era demasido restrictivo se introdu%o el concepto de cdigo remoto firmado, que sigue garanti-ando la seguridad de los clientes, pero permite que cdigo obtenido remotamente salga del ca%n y tenga acceso a todos los recursos, siempre y cuando est firmado por una entidad en la el cliente confa. 5unque esto me%ora un poco la situacin, sigue siendo un control de dos nivels* total para cdigo local o remoto firmado y restringido para cdigo remoto sin firma o con firmas no validadas por el cliente. 5dem$s del cdigo firmado, el JDK "." introdu%o otras me%oras de seguridad* ". 6n par de herramientas de seguridad. '. 6n 578 para programacin segura. ,as 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 con%unto de clases y otros fecheros (como por e%emplo im$genes o te&to! en un solo archivo, almacenado normalmente con la e&tensin .jar. Esto hace posible la transferencia de aplicaciones de un modo compacto, en una sola cone&in, y el firmado de los programas de modo con%unto. El programa javakey es el que permite el firmado de clases en los ficheros jar. El 578 de seguridad introdu%o 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 578 estaba dise)ada para ser e&tensible e inclua herramientas para* generar firmas digitales, resumenes de mensa%es, gestin de claves y el uso de listas de control de accesos (54,s!.

,os algoritmos criptogr$ficos se proporcionaban separados en la E&tensin 4riptogr$fica de Java (J4E!, como un paquete adicional al JDK est$ndar, principalmente por los problemas de e&portacin de los EE66.

Seguridad en Java #
En el JDK ".' se han introducido nuevas caractersticas que me%oran el soporte y el control de la seguridad*

$ontrol de acceso de grano fino. 6no de los problemas fundamentales de la seguridad en el JDK "." es que el modelo slo contempla dos niveles de permisos* acceso total o ca%n de arena. 7ara solventar el problema el JDK ".' introduce un sistema de control de permisos de grano fino que peremite dar permisos especficos a tro os de cdigo especficos para acceder a recursos especficos en el cliente, dependiendo de la firma del cdigo y1o el 69, del que este se obtuvo. $ontrol de acceso aplicado a todo el cdigo. El concepto de cdigo firmado es ahora aplicable a todo el codigo, independientemente de su procedencia (local o remoto!. %acilidad de configuracin de polticas de seguridad. ,a nueva arquitectura de seguridad permite el a%uste sencillo de los permisos de acceso usando un fic!ero de polticas (policy file! en el que se definen los permisos para acceder a los recursos del sistema para todo el cdigo (local o remoto, firmado o sin firmar!. :racias a ello, el usuario puede ba%ar aplicaciones de la red, instalarlas y e%ecutarlas asign$ndoles slo los permisos que necesiten. Estructura de control de acceso e&tensi'le. 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 versin 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 mayora de casos, se hace innecesario a)adir m todos al gestor de seguridad.

En la figura +eguridad en el JDK ".' se presenta el modelo de seguridad de Java '.

+eguridad en el JDK ".' 5l igual que sucedi con el JDK "." en el Java ' han aparecido o se han me%orado las herramientas y el 578 de seguridad. En Java ' se incluyen cuatro herramientas de seguridad*
1. jar. Esta es b$sicamente la misma herramienta que apareci en el JDK "." y se

emplea para generar ficheros J59.

2. keytool. Esta es una herramienta para la generacin de pares de claves

(p3blicas y privadas!, importar y e&portar certificados ;.<#= (versiones ", ' y 0!, generar certificados ;.<#= ." autofirmados y gestionar almacenes de claves ("eystores!.
3. jarsigner. Este programa se emplea para firmar ficheros J59 y verificar las

firmas de ficheros J59 ya firmados. ,a herramienta emplea los almacenes de claves para buscar los datos que necesita para firmar ficheros (una clave privada!, verificar firmas (clave p3blica! o verificar claves p3blicas (certificados!. Esta herramienta %unto a a la anterior reempla-an al antiguo javakey.
4. policytool. Esta utilidad se emplea para crear y modificar los ficheros de

configuracin de polticas de seguridad del cliente de modo sencillo. El 578 de seguridad se ha incrementado con nuevos subpaquetes que me%oran el soporte de certificados ;.<#= y permiten crear Listas de #evocacin de Certificados (49,s! y $eticiones de %irmado de Certificados (4+9s!. ,os nuevos subpaquetes son el java.security.cert y java.security.spec y los discutiremos en puntos posteriores.

Evolucin del modelo de seguridad

En la tabla comparacin modelos de seguridad se comparan los modelos de seguridad de Java en funcin de varias caractersticas. JDK !" JDK ! Java # SDK >asado en poltica

$aracterstica 5cceso a los recursos del cdigo local sin firma 5cceso a los recursos del cdigo local firmado 5cceso a los recursos del cdigo remoto sin firma 5cceso a los recursos del cdigo remoto firmado

+in restricciones +in restricciones ?o disponible

+in restricciones si fiable o >asado en restringido por el sandbox poltica

9estringido por el >asado en 9estringido por el sandbox sandbox poltica ?o disponible +in restricciones si fiable o >asado en restringido por el sandbox poltica J45 (D+5! J4E "." J45 (D+5! J4E ".'

+ervicios de firmado digital ?o disponibles de cdigo +ervicios criptogr$ficos ?o disponibles

Dominios protegidos( modelo de permisos y polticas de seguridad

En este punto e&plicaremos que son los dominios protegidos, como funciona el modelo de permisos de Java ' y como se definen las polticas de seguridad.

Dominios protegidos
El concepto de dominio protegido es fundamental para la seguridad de los sistemas. El alcance de un dominio est$ definido por el con%unto de ob%etos que estan directamente accesibles para un principal, donde principal es una entidad en el sistema inform$tico a la que se le han asignado permisos. El cajn de arena del JDK ".# es un e%emplo de dominio de proteccin con lmites fi%os. El concepto de dominio protegido proporciona un mecanismo adecuado para agrupar y aislar unidades de proteccin. 7or e%emplo, se pueden separar dos dominios de forma que la interaccin entre ambos 3nicamente sea posible a trav s de cdigo del sistema o de un protocolo e&plcito para la comunicacin entre ambos. ,os dominos protegidos se dividen generalmente en dos categorias* ". Dominos del sistema, que controlan el acceso a los recursos del sistema (sistema de archivos, acceso a la red, E1+!. '. Dominios de aplicacin, que controlan el acceso a los recursos de una aplicacin.

4onceptualmente un dominio incluye un con%unto de clases cuyas instancias tienen asignados los mismos permisos. ,os dominios de proteccin se determinan mediante la poltica de seguridad activa en cada momento. El entorno Java mantiene una asociacin entre el cdigo (clases e instancias! y sus dominios de proteccin. Esta relacin es de varios a uno, es decir, disitintas clases pueden pertenecer a un mismo dominio, pero cada clase slo est$ asociada un dominio. 7ara los dominios de proteccin se emplea otra tabla que relaciona cada dominio con sus permisos correspondientes. Evidentemente esta asociacin es de muchos a muchos, varios dominios pueden tener el mismo permiso y cada dominio puede tener multiples permisos. 6n hilo de e%ecucin puede traba%ar 3nicamente en un dominio protegido o puede ir pasando del dominio de la aplicacin al del sistema y viceversa. Esto tiene implicaciones importantes en la seguridad, se plantean dos escenarios* ". +i una aplicacin accede al sistema y solicita una operacin que requiere permisos del dominio del sistema, se debe garanti-ar que la aplicacin no tendr$ acceso directo al dominio del sistema, es decir, que su domino de proteccin no obtendr$ ning3n permiso del dominio del sistema. '. +i una clase del sistema invoca un m todo de la aplicacin, es esencial que los permisos de ese m todo cuando se e%ecute sean los del domino de la aplicacin, no los del sistema. En definitiva, el modelo de dominios protegidos debe garanti-ar que un dominio menos poderoso no pueda obtener permisos adicionales al invocar o ser invocado por otro dominio m$s poderoso. 2casionalmente ser$ necesario que cdigo fiable de acceso temporal a m$s recursos de los que normalmente est$n disponibles para la aplicacin que lo invoc. 7or e%emplo, una aplicacin no tiene porque tener acceso directo a los ficheros que contienen los tipos de letra, pero la 3tilidad del sistema que muestra un documento debe conseguir esos tipos. 7ara solucionarlo se emplea el m todo doPrivileged, que est$ disponible en todos los dominios. 4uando un fragmento de cdigo llama al m todo doPrivileged, se considera que el con%unto de permisos activo incluye un permiso si lo permite el domino protegido del cdigo invocante y todos los dominos en los que se entra a continuacin. Durante la e%ecucin, cuando se solicita acceso a un recurso del sistema, el cdigo de gestin de recursos invoca directa o indirectamente a un m todo especial de la clase AccessControler que evalua la peticin y decide si debe concederse o no el acceso. +i se concede el permiso la e%ecucin continua y si no se lan-a una e&cepcin de seguridad.

Modelo de permisos
,os permisos en Java son clases que representan accesos a recursos del sistema. ,a clase fundamental es java.security.Permission, que es una clase abstracta de la que se deben definir subclases para representar accesos especficos.

6n permiso consta de un objetivo y una accin, aunque puede omitirse cualquiera de los dos. 7or e%emplo, para acceder al sistema de ficheros local el objetivo puede ser un directorio o un fichero y las acciones pueden ser* leer, escribir, e%ecutar y borrar. :eneralmente, una clase de permiso pertenece al paquete en el cual ser$ usada. 7or e%emplo, el permiso que representa el acceso al sistema de ficheros local es java.io.FilePermission. 4omo e%emplo de permiso, el siguiente fragmento de cdigo se puede emplear para generar un permiso de lectura del archivo "abc" en el directorio /tmp*
perm = ne java.io.FilePermission!"/tmp/abc"" "read"#$

+i queremos definir nuevos permisos es crucial implementar el m todo abstracto implies. >$sicamente, la afirmacin 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. ,a clase abstracta java.security.Permission tiene asociadas dos clases importantes*
1. ,a clase abstracta java.security.PermissionCollection, que representa una

coleccin de ob%etos de tipo Permission de una misma categora (como por e%emplo de acceso a ficheros!, para simplificar el agrupamiento. 2. ,a clase final java.security.Permissions, que representa una coleccin de colecciones de ob%etos Permission. 5ntes del acceder a un recurso se toma la decisin de control de acceso al recurso, basada en los permisos que el cdigo en e%ecucin tiene. 5unque cualquier cdigo puede crear sus propios ob%etos de permisos, esto no implica que tales ob%etos obtengan los correspondientes permisos de acceso. +lo los ob%etos de permisos que gestiona el sistema en tiempo de e%ecucin de Java obtienen los permisos que representan. ,os permisos definidos por el JDK ".' son* )ll*ermission Es un permiso que asigna todos los dem$s permisos. )+,*ermission 7ermisos para el 5@( (acceso al portapapeles, a los eventos, etc.!. %ile*ermission 6n permiso java.io.FilePermission representa permisos de acceso a archivos o directorios y consta de un nombre de ruta y un con%unto de acciones validas para esa ruta.

+i 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. ,as acciones posibles son* read, rite, e'ecute y delete. -et*ermission 6n permiso java.net.(etPermission es para varios permisos de red. 6n permiso de red contiene un nombre pero no tiene lista de acciones, o se tiene el permiso o no se tiene. *roperty*ermission 7ermisos para manipular properties. .eflect*ermission 7ermisos para efectuar operaciones reflectivas. +on permisos sin acciones. .untime*ermission 7ermisos para tiempo de e%ecucin (acceso a 4lass,oaders, +ecurity/anager, (hreads, etc!. +on permisos sin acciones. Security*ermission 7ermisos relacionados con la seguridad. +on permisos sin acciones. Seriali/a'le*ermission 7ermisos relacionados con la seriali-acin de ob%etos. +on permisos sin acciones. Soc0et*ermission 6n permiso java.net.)ocketPermission representa un acceso a la red a trav s de socAets. 6n )ocketPermission consta de una direccin de host y un con%unto de acciones especificando formas de conectar. ,a especificacin de la direccin del host se hace del siguiente modo*
host = !nombre*ost + dir,P#-.rangoPuertos/ rangoPuertos = numPuerto + &numPuerto + numPuerto& -numPuerto/

El nombre del host puede ser seg3n el D?+ o en formato 87. El rango de puertos es opcional. ,as formas de conectar posibles son* accept, connect, listen y resolve.

En http*11%ava.sun.com1products1%dA1".'1docs1guide1security1permissions.html se pueden encontrar tablas con los permisos definidos en el %dA".' y las implicaciones de seguridad que tiene asignarlos.

*olticas de seguridad
En el JDK ".' las polticas de seguridad se especifican en uno o m$s ficheros de configuracin de polticas. Estos ficheros especifican que permisos est$n habilitados para el cdigo obtenido de los origenes de cdigo especificados. 6n archivo de polticas de seguridad se puede escribir directamente con un editor de te&to ascii o usando la herramienta policytool del JDK. 7or defecto hay un archivo de polticas del sistema y, opcionalmente, otro archivo de polticas del usuario. El ob%eto Policy por defecto se inicali-a la primera ve- que se invoca su m todo getPermissions!# o cuando se invoca su m todo re0resh!#. ,a iniciali-acin supone el an$lisis (parsing! de los archivos de configuracin de polticas y la configuracin del ob%eto Policy.

El gestor de seguridad
5ctualmente, todo el cdigo del sistema del JDK invoca m todos del :estor de seguridad para determinar la politica de seguridad activa y reali-ar verificaciones de control de acceso. 7or defecto, cuando se e%ecutan applets siempre se carga una implementacin del gestor de seguridad, pero cuando se lan-an aplicaciones esto no es as. +i el usuario desea que se instale uno debe invocar la m$quina virtual definiendo la propieda java.security.manager*
java &1java.security.manager (omApp

o la aplicacin debe invocar el m todo set)ecurity2anager de la clase java.lang.)ystem para instalar un gestor. +i se le asigna valor a la propiedad java.security.manager se instalar$ el gestor de seguridad especificado*
java &1java.security.manager=iti.3estor)eguridad (omApp

6n aspecto muy importante del gestor de seguridad es que una ve- cargado no se puede reempla-ar, 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.

7or 3ltimo hay que se)alar que el gestor de seguridad est$ muy relacionado con la clase AccessControler* la clase )ecurity2anager 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 caractersticas especiales como el m todo doPrivileged!#. En versiones del JDK anteriores a la ".', los programadores redefinian el gestor de seguridad cuando necesitaban m todos de control de acceso especficos, pero ahora el m todo adecuado para hacer esto es emplear el AccessController.

INTERFACES DE SEGURIDAD
El pa1uete java.security
El paquete java.security consiste b$sicamente en clases abstractas e interfaces que encapsulan conceptos de seguridad como certificados, claves, resumenes de mensa%es y firmas digitales. En el J45 "." los proveedores pueden implementar tres clases*
4eyPair3enerator. +e emplea para crear claves p3blicas y privadas. 2essage1igest. 7rorciona la funcionalidad de algoritmos de resumen

de

mensa%es como el /D< y el +B5.

)ignature.

+e emplea para el firmado digital de mensa%es.

6na aplicacin puede solicitar una implementacin con el m todo get,nstance!#, como por e%emplo*
4eyPair3enerator kpg = 4eyPair3enerator.get,nstance !"1)A"#$

C el sistema busca un proveedor que nos devuelva una implementacin del mismo, como ya hemos e&plicado al comentar la arquitectura de seguridad de Java '. +i se desea una implementacin especfica se puede obtener llamando a get,nstance!# con m$s par$metros, por e%emplo si deseamos el algoritmo D+5 del proveedor 8(8 haremos la siguiente llamada*

4eyPair3enerator kpg = 4eyPair3enerator.get,nstance !"1)A"" ",5,"#$

El J45 ".' ampla considerablemente el n3mero de clases que pueden implementar los proveedores*
AlgorithmParameter3enerator.

+e emplea para generar un con%unto de parametros adecuado para usar con algun algoritmo. AlgorithmParameters. +e emplea como representacin opaca de los parametros de un algoritmo.
4eyFactory.

,as factorias de claves se emplean para convertir claves (claves criptogr$ficas opacas de tipo 4ey! en especificaciones de claves (representaciones transparentes de las claves! y viceversa.
4ey)tore.

Esta clase representa una coleccin de certificados y claves en

memoria.
)ecure6andom.

Esta clase proporciona un generador de n3meros pseudo aleatorios criptogr$ficamente seguro.

El pa1uete java.security.spec
El paquete java.security.spec, introducido en la versin ".' del J45, a)ade interfaces y clases que describen formatos de especificacin de claves. Estas clases permiten crear claves de seguridad en Java basadas en par$metros generados por herramientas e&ternas al JDK. Entre otras, e&isten clases para representar par$metros y claves de los algoritmos D+5 y 9+5 y claves codificadas seg3n la especificacin del ;.<#=.

El pa1uete java.security.cert
El paquete java.security.cert a)ade soporte para generar y usar certificados, as como leerlos de lugares como archivos J59 a trav s de las clases 7ar869Connection y 7ar:ntry. 5demas incluye clases e interfaces especficas para soportar certificados ;.<#=. ,as clases m$s importantes incluidas en paquete son*

Certi0icateFactory.

+e emplea para generar certificados y listas de

revocacin (49,!. Certi0icate. 4lase abstracta para gestionar certificados. Es una clase para agrupar certificados de diferentes formatos pero usos comunes importantes, como por e%emplo funciones de codificacin y verificacin o datos como claves p3blicas.
C69.

4lase abstracta para gestionar distitos tipos de listas de revocacin de certificados.

;<=>Certi0icate.

4lase abstracta para representar certificados ;.<#=. 7roporciona un m todo estandar para acceder a los atributos de un certificado ;.<#=.
;<=>:'tension. ;<=>C69.

Es una interfa- para las e&tensiones del formato ;.<#=.

4lase abstracta para una lista de revocacin de certificados ;.<#=. Es una clase abstracta para las entradas de las listas de

;<=>C69:ntry.

revocacin.

El pa1uete java.security.interfaces
,a versn "." del J45 inclua en este paquete interfaces para usar el algoritmo D+5. El J45 ".' ampli la clase para incluir interfaces para el algoritmo 9+5. ,as interfaces incluidas en paquete son*
1)A4ey. 8nterfa- para una clave D+5 p3blica o privada. 1)A4ey3enerator. 8nterfa- para un ob%eto capa- de generar

pares de claves

D+5.
1)A4ey.

8nterfa- para una clave D+5 p3blica o privada. 8nterfa- para un con%unto de par$metros especficos del claves de 8nterfa- para una clave privada D+5.

1)AParams.

tipo D+5.
1)APrivate4ey. 1)APublic4ey.

8nterfa- para una clave p3blica D+5.

6)APrivateCrt4ey.

8nterfa- para una clave privada 9+5, como se define en el est$ndar 7K4+D", usando valores de informacin del (eorema 4hino del 9esto (49(!.
6)APrivate4ey. 6)APublic4ey.

8nterfa- para una clave privada 9+5.

8nterfa- para una clave p3blica 9+5.

El pa1uete java.security.acl

El paquete java.security.acl define soporte para listas de control de acceso que se pueden emplear para restringir el acceso a recursos de cualquier manera deseada. El paquete consta de interfaces y e&cepciones. ,as implementaciones actuales en el JDK "." de +6? est$n en el paquete sun.security.acl. En el JDK ".' las clases de este paquete han sido reempla-adas por clases del paquete java.security como la clase Permision.

El pa1uete javax.crypto
7roporciona las clases e interfaces para reali-ar operaciones criptogr$ficas. ,as operaciones criptogr$ficas definidas en este paquete incluyen encriptacin, generacin de claves y acuerdo de claves y generacin de cdigos de autentificacin de mensa%es (/54!. El soporte para encriptacin incluye algoritmos de cifrado sim tricos, asim tricos, por bloques y de flu%o. ,a mayora de clases incluidas en este paquete se basan en proveedores, las clases slo definen el 578. ,as clases m$s importantes incluidas en paquete son*
Cipher. 9epesenta un algoritmo de cifrado. 4eyAgreement. 7roporciona la funcionalidad

de un protocolo de acuerdo o

intercambio de claves.
4ey3enerator. 2ac.

7ropociona las funciones de un generador de claves sim tricas.

7roporciona las funciones de un generador de cdigos de autentificacin de mensa%es.

)ecret4eyFactory.

9epresenta un factora de claves secretas.

El pa1uete javax.crypto.spec
7roporciona clases e interfaces para especificaciones de claves y par$metros de algoritmos. ,as especificaciones de claves son representaciones transparentes de las claves. ,as claves se pueden especificar de un modo especfico del algoritmo o en un formato de codificacin independiente del algoritmo, como el 5+?.". Este paquete contiene especificaciones de claves para claves DiffieEBellman publicas y privadas, claves DE+, (riple DE+ y claves secretas 7>E. ,a especificacin de par$metros de un algoritmo son representaciones transparentes del con%unto de par$metros empleados con el algoritmo. Este

paqute contiene especificaciones de par$metros para los algoritmos DiffieE Bellman, DE+, (riple DE+, 7>E, 94' y 94<.

El pa1uete javax.crypto.interfaces
7roporciona interfaces para claves DiffieEBellman como se definen en el 7K4+ D0 de los laboratorios 9+5. ,as interfaces incluidas en este paquete son*
1*4ey. 8nterfa- con una clave DiffieEBellman. 1*Private4ey. 8nterfa- con una clave privada 1*Public4ey.

DiffieEBellman.

8nterfa- con una clave p3blica DiffieEBellman.

www.uv.es/~sto/cursos/seguridad.java/html/sjava-33.html