CONCEPTOS DE SEGURIDAD
.Una aplicación será segura si cumple con los siguientes objetivos de seguridad: Confianza – Confidencialidad – Integridad – Autenticación – Autorización – No repudiación – Auditoría.
.-Confianza. Cuando dos partes van a comunicarse, por ejemplo un Banco y un cliente de ese Banco, primero se ha de establece una relación de confianza entre las dos partes, para ello se recurre a certificados oficiales que aseguren que el Banco es quien dice ser y a que el usuario se identifique y si las dos partes están debidamente autenticadas y se comunican a traves de un canal seguro, entonces podemos decir que hay una relación de confianza. ¿Me fío de trabajar contigo?.
.-Confidencialidad. Su objetivo es proteger datos sensibles de recursos o entidades no autorizados. ¿Pueden los ojos cotillas verlo?.
.-Integridad. Su objetivo es asegurar que ninguna entidad no autorizada haya podido modificar los datos que estamos tratando. Al recibir la información se analizará si ha sufrido cambios accidentales (fallos) o intencionados. ¿Me ha llegado alterado o no?.
.-Autenticación. Su objetivo es el de asegurar que la persona/entidad que quiere entrar en el sistema, es quien dice ser. Esto se suele hacer usando Usuario/Password aunque existen otros mecanismos más seguros de identificación personal biométricos. ¿Eres quién dices ser?.
.-Autorización. Su objetivo es el de asegurar que cierta persona/entidad puede realizar una acción en concreto (si tiene permisos para realizar esa acción), una vez que a entrado al sistema. ¿Tienes permiso para tenerlo?.
.-No repudiación. Su objetivo es asegurar que las acciones de un usuario han sido realizadas realmente por ese usuario. ¿Puedes decir: “Yo no he sido” y mentir?.
.-Auditoría. ¿Puedes probar lo que ha ocurrido sin tener que llamar a los de C.S.I.?.
HERRAMIENTAS DE SEGURIDAD
.-Digest: Resumenes de mensajes (reducciones criptográficas), esto quiere decir que por cada documento, mensaje, contexto, bytes de lo que sea, vas a generar una digest, resumen que te servirá para saber que el documento, mensaje, etc. no ha sido modificado. Cuando te llegue el documento, mensaje, etc. para saber si lo han modificado, puedes volver a generar el digest y compararlo con el que ofrece el documento y si son distintos, pues es que ha sido modificado (por un error, por estar corrompido, etc.). Dos mensajes, documentos, etc. distintos no podrán generar el mismo digest.
.-Firma: ¿Qué es una firma digital? Es lo que utilizamos para comprobar que un mensaje lo ha generado una entidad determinada. Es como los sellos en la Edad Media. Cada Rey tenía su sello, único, personal e intrasferible y por ello se le reconocía, eso es una firma. No confundir con una password, que es para autenticar no para firmar. Autenticar es verificar una identidad, es decir, confirmar que el señor J es realmente el señor J, no es lo mismo que la firma que es para decir que el señor J escribió el mensaje.
.-Generadores de numeros aleatorios seguros: Es un algoritmo que genera una serie de números partiendo de una semilla dada por el usuario o calculada por el sistema. Generará tantos valores como se le pidan. La semilla no cambia hasta que la cambiemos.
.-Identificadores únicos globales o universales: UUID o GUID, no se repiten, es decir, un UUID pertenecerá a un único elemento.
.-Canal de comunicación seguro como por ejemplo SSL (anteriormente TSL).
ALGORITMOS DE CIFRADO DE MENSAJES/FIRMAS/DOCUMENTOS/ETC.
.-Hash : one way hash algorithm, encriptación de una sola dirección y sin clave. No se podrá volver a descifrar. Servirá para volver a generar el hash y comparar si es el mismo para por ejemplo ver que no han modificado un texto, una password etc.
.-Clave simétrica : misma clave para cifrar que para descifrar. Se entiende que la clave es secreta.
.-Clave asimétrica : una clave para cifrar y otra para descifrar. Lo normal suele ser una pública y otra privada en función de lo que se quiera. Si cifras con la clave privada y cualquiera puede descifralo con la pública, diremos que estamos firmando. Si cifro con la clave pública, y sólo se puede descrifrar mi mensaje con una clave privada que tiene el señor X (mi banco por ejemplo), sólo el señor X podrá leer mi mensaje.
CON LAS FIRMAS DIGITALES CONSEGUIMOS:
.-Integridad: Si la información firmada es modificada, la validación de la firma fallará.
.-No repudiación: La entidad que firmo la información no puede luego decir que no lo hizo. La firma digital se forma a partir de una clave secreta, se verifica utilizando la clave pública. La firma digital se realiza sobre un mensaje e indica que el mensaje ha sido producido por una persona en concreto, así verificamos la no repudiación.
.-Autentificación: Sabemos qué entidad es la que realizó la firma, pues lo podemos validar con su clave pública.
.-Además podemos conseguir confidencialidad(cifrado) con el par de claves pública/privada, pues lo que se encripta con la clave privada sólo puede ser descifrado con la clave pública.
MOTOR CRIPTOGRÁFICO DE JAVA
.Arquitectura JCA. Introducida en la JDK 1.1, proporciona funciones criptográficas para: encriptar la información (confidencialidad), asegurar que los datos enviados no son alterados por entidades no autorizadas (integridad), mantenimiento de claves y certificados, uso de algoritmos de distintos proveedores de forma encapsulada. JCA será el core o motor criptográfico del API de seguridad (del API criptográfico) de Java. JCA nos provee una serie de estándares a implementar por cada proveedor de servicio.
.Clases del motor criptográfico:
.-MessageDigest: Uso de los digest en Java.
.-Signature: Para tratar las firmas digitales en Java.
.-KeyPairGenerator: Mecanismo para generar claves públicas y privadas.
.-KeyFactory: Factoría para el manejo de claves seguras.
.-CertificateFactory: Mantenimiento de certificados.
.-KeyStore: Mantenimiento de un depósito de almacenamiento seguro de claves.
.-AlgorithmParameters: Maneja parámetros para un algoritmo en particular, incluyendo codificación y decodificación de parámetros.
.-AlgorithmParameterGenerator: Crea parámetros de algoritmos.
.-SecureRandom: Creación de números aleatorios.
.-CertPathBuilder: Construcción de certificados.
.-CertPathValidator: Validación de certificados.
.-CertStore: Recuperación de certificados de un repositorio.
PROVEEDORES DE SEGURIDAD DE JAVA
.Java ofrece varios proveedores de seguridad:
.-sun.security.provider.Sun
.-sun.security.rsa.SunRsaSign
.-com.sun.net.ssl.internal.ssl.Provider
.-com.sun.crypto.provider.SunJCE
.-sun.security.jgss.SunProvider
.-com.sun.security.sasl.Provider
.-org.jcp.xml.dsig.internal.dom.XMLDSigRI
.-sun.security.smartcardio.SunPCSC
.-sun.security.mscapi.SunMSCAPI
.-El proveedor de seguridad ‘sun.security.provider.Sun’ proporciona implementación de DSA (algoritmo de firma digital), MD5 (algoritmo de resumen del mensaje 5), SHA-1 (algoritmo de Hash seguro), así como, generación de claves (key pair) pública y privadas para DSA, Factoría de claves que soporta conversión de claves públicas a privadas, generación de números aleatorios SHA1PRNG (algoritmo de generación de números seudoaleatorios utilizados por SHA-1), construcción de certificados X.509.
.-Podemos utilizar más de un proveedor de seguridad dentro de nuestra aplicación, para ello, modificamos el fichero java.security que está en lib/security. El formato sería: security.provider.1=sun.security.provider.Sun
security.provider.2=sun.security.rsa.SunRsaSign
security.provider.3=com.sun.net.ssl.internal.ssl.Provider
security.provider.4=com.sun.crypto.provider.SunJCE
security.provider.5=sun.security.jgss.SunProvider
security.provider.6=com.sun.security.sasl.Provider
security.provider.7=org.jcp.xml.dsig.internal.dom.XMLDSigRI
security.provider.8=sun.security.smartcardio.SunPCSC
security.provider.9=sun.security.mscapi.SunMSCAPI
El orden es importante.
.-También podemos añadir un proveedor durante la ejecución de la aplicación llamando a addProvider() de Security.
CLAVES EN JAVA
.Administración de claves.
Para que un sistema sea seguro debe basarse en claves secretas, o en pares de clave pública/privada. Para adminisatrarlas utilizaremos el API Java Security.
.Para representar una clave usamos la clase Key del paquete java.security. La clase Key es un interfaz Serializable (para poder almacenar o enviar las claves de forma serializada) que contiene tres métodos: getAlgorithm() (devuelve el algoritmo usado), getFormat() (devuelve el formato con el que está codificada la clave), getEncoded() (devuelve la clave como un array de bytes).Existen dos interfaces de marcación que implementan la interface Key, que son PublicKey y PrivateKey. Cada algoritmo definirá su propia interfaz que utiliza las interfaces PrivateKey y PublicKey.
.Generación de claves. Para generar claves pública y privadas, java.security, proporciona la clase KeyPairGenerator que genera objetos del tipo KeyPair, que a su vez contiene un objeto del tipo PublicKey y otro del tipo PrivateKey. El método initialize(), de KeyPairGenerator, nos permite darle un tamaño a la clave, cuanto más grande, más seguro y mayor consumo de recursos.
Bájate el ejemplo:
.Numeros Aleatorios. Para la construcción de claves se utilizan números pseudo-aletorios generados con los métodos de la clase java.security.SecureRandom ya que son mucho menos PREDECIBLES que los generados con las clases Math o Random y por tanto aumentará la seguridad de los procesos en los que se utilicen.
Bátaje el ejemplo:
RESUMEN DE MENSAJES Y FIRMAS DIGITALES EN JAVA
.Dos algoritmos de resumen de mensaje que encontramos dentro del JDK son MD5 (algoritmo de reducción criptográfico de 128 bits. Genera un hash de 128 bits. Cuidado, el MD5 es menos seguro que el SHA-1) y SHA-1 (Secure Hash Algorithm, Algoritmo de Hash Seguro. Genera un hash de 160 bits (20 bytes)) .
.Pasos para realizar una firma en Java.
.-Obtener la referencia (Reference) partiendo de una instancia de XMLSignatureFactory.
.-Obtener la información de la firma (SignedInfo).
.-Obtener la información de la clave de la firma.
.-Firmar el documento.
Bájate el ejemplo:
.Firmas digitales XML. Con la incorporación de la especificación JSR105, podemos realizar el tratamiento de firmas digitales en documentos XML. El paquete javax.xml.crypto del JDK, ofrece implementación de firmas digitales XML. Esto permite firmar digitalmente un documento XML y validarlo.
.Paquetes relacionados con la Firma digital de documentos XML:
.-javax.xml.crypto = Clases comunes de la firma.
.-javax.xml.crypto.dor = Manejo de los objetos DOM.
.-javax.xml.crypto.dsig = Validación de la firma digital.
.-javax.xml.crypto.dsig.keyinfo = Manejo de los objetos KeyInfo.
.-javax.xml.crypto.dsig.spec = Parámetros de entrada para la firma y la validación.
.Existen tres formas de realizar una firma digital para documentos XML:
.-Firma XML externa o separada (detached); se utiliza para firmar un recurso fuera del documento XML que la contiene.
.-Firma envolvente (enveloping); contiene los datos firmados dentro de sí mismo.
.-Firma envuelta (enveloped); se utiliza para firmar una parte del documento que la contiene.
Bájate el ejemplo:
.Validar Firma Digital. Para validar la firma obtendremos el contexto deonde está incluida y revisaremos el objeto Signature para ver si es correcto.
Bájate el ejemplo:
.Extensión JCE. Java Cryptography Extensión, está basado en JCA y contiene servicios que completan los servicios de seguridad existentes en java.security. Está en el JDK y se llama SunJCE. Soporta algoritmos criptográficos adicionales como: RC2, Rijndael, IDEA, MD5, SHA-1, RIPEMD-160, etc.
. Clase Cipher. Realiza servicios de encriptación y desencriptación.
Bájate el ejemplo:
SERVICIOS DE AUTENTICACIÓN Y AUTORIZACIÓN JAAS
.Java Authentication and Authorization Service, autentica y autoriza en función del control de acceso por identidad o control de acceso a sujetos. Los sujetos son objetos del tipo javax.security.auth.Subject. Los sujetos pueden corresponder a personas o sistemas. Cada Subject contiene un Set o conjunto de objetos del tipo Principal, que contendrán los datos que le identifiquen (nombre de la persona, identificación, etc.), otro Set o conjunto con las credenciales públicas del Subjetc y otro con las credenciales privadas.
. Autenticación, contexto de conexión LoginContext. Sigue el patrón PAM (Pluggable Autenthication Module). El contexto de conexión para realizar la autenticación se basa en el sujeto Subject. La clase LoginContext permite realizar la conexión y desconexión del sujeto, usando los métodos login() y logout(). Una vez realizado el login() correctamente, se pasa a la segunda fase de validación que se realiza llamando a commit(). Si login() falla, se llama a abort(). Para finalizar el proceso de autenticación de un sujeto se llama a logout() y se elimina todo el sujeto, sus credenciales, etc.
.Configuración del modulo de conexión. Al crear el contexto de conexión debemos establecer su configuración. Es necesario pasarle la configuración de autenticación al servicio, así como definir qué servicios van a realizar la autenticación. Primero se crea un fichero que contenga los módulos de autenticación que utilizará la aplicación. Cada módulo de autenticación estará contenido en una configuración (se explica en el ejemplo).
Bájate el ejemplo:
Deja un comentario