Introducción a JCA (JDK 1.7)
Seguridad y Cifrado (JCA) es uno de las partes más importantes de la plataforma Java, contiene una arquitectura de "proveedores" y APIs para firma digital, generación de hashes en mensajes, certificados y validación de certificados, cifrados (simétricos/asimétricos, para recursos de I/O de modo bloque o de flujo), generación de claves y su almacenamiento/recuperación/distribución, generación segura de numeros aleatorios, por nombrar unos pocos. Estas APIs permiten a los desarrolladores una via de integrar seguridad en el código. JCA ha sido diseñada bajo los siguientes principios:
-
Independiente de la implementación: ADentro de una aplicación no es necesario implementar algoritmos de seguridad. En su lugar, realizaremos llamadas a servicios provenientes de la plataforma. Estos servicios contienen la implementación de seguridad de diverentes "proveedores", que son accedidos por la plataforma Java a través de una interfaz. De esta manera, una aplicación puede estar ligada de más de un "proveedor" de seguridad de manera independiente, para la puesta en marcha de la capa de seguridad.
-
Interoperatibilidad entre implementaciones: Los diferentes proveedores de seguridad que aporta JCA, pueden interoperar en la aplicación. De forma concreta, una aplicación no esta ligada a un proveedor específico, de la misma forma que un proveedor no se asocia a una aplicación específica.
-
Posibilidad de extender algoritmos de seguridad : JCA incluye una serie de "proveedores de seguridad integrados por defecto en la plataforma", los cuales incluyen un conjunto básico de implementaciones de seguridad, ofrecidos como servicios (a través de interfaces), la mayoría usados comúnmente en la actualidad. Sin embargo, algunas aplicaciones pueden depender de nuevos estándards de seguridad que no hayan sido integradas en la plataforma, aún no implementadas ó procedentes de terceros. JCA soporta la instalación de "proveedores propietarios" que ofrezcan una implementación a las interfaces.
Existen otras librerias de comunicación cifrada en el JDK. Dichas librerias hacen uso de la arquitectura de "proveedores de seguridad" que ofrece JCA. Entre estas:
Java Secure Socket Extension (JSSE) contiene las implementaciones de Socket Layer (SSL) y Transport Layer Security (TLS) . Java Generic Security Services (JGSS) implenta el mecanismo de seguridad Kerberos (para securizar por ejemplo una comunicación via SMTP), y Simple Authentication and Security Layer (SASL) . Utilizadas para para securizar el intercambio de mensajes en comunicaciones.
Ciertos aspectos de la tecnología
-
Antes del JDK 1.4, Java Comunications Encryption, se tenia en cuenta como un elemento fuera de JCA, sin embargo ahora JCE se encuentra incluido en el JDK, y utiliza la misma arquitectura que JCA, por lo que debería ser considerado como una parte de JCA. JCA que se incluye en JDK, consta de 2 componentes:
- Por un lado el framework que soporta los diferentes servicios que los distintos "proveedores de seguridad" implementan. Este framework consta entre otros de los siguientes paquetes:
java.security
,javax.crypto
,javax.crypto.spec
, yjavax.crypto.interfaces
. - Por otro lado las verdaderas implementaciones de los proveedores como puede ser:
Sun
,SunRsaSign
,SunJCE
Al referirnos a un proveedor de seguridad específico de JCA, lo haremos de forma explícita por su nombre.
- Por un lado el framework que soporta los diferentes servicios que los distintos "proveedores de seguridad" implementan. Este framework consta entre otros de los siguientes paquetes:
Importante: JCA facilita integrar caracteristicas de seguridad en una aplicación. Sin embargo, en este documento no hablaremos de la teoría de seguridad/criptografía mas alla una introducción básica, que aclare los conceptos de uso de la API JCA. Esto implica que no hablaremos de las fuerzas/puntos débiles de algoritmos concretos, ni de especificacion de protocolos. Para profundizar más acerca de criptografía:
Es aconsejable comprender bien lo que estamos haciendo y por qué: NO COPIAR de forma ^C/^V, código al hazar de manera que esperemos que resuelva nuestro caso de uso. Muchas aplicaciones desarrolladas, contienen importantes problemas de seguridad o rendimeinto, debido a un componente o algoritmo de cifrado elegido.
Open Q:
ResponderEliminarWorking in use case where 3rd trusted identity verification is required (ie. In a device).
What would it be the correctness, validity of trusted ring (asymetric) acks? What in case of one or many of ring elements want to remove trust of the element to identify?
Thx