Esta lecci�n contiene informaci�n general para ayudarnos a entender para que son necesarias las firmas digitales, los certificados y los almacenes de claves. Esta lecci�n tambi�n compara el uso de las herramientas contra el API de Seguridad del JDK con respecto a la generaci�n de firmas. El uso de dichas herramientas se explica en las dos siguientes lecciones.
�Seguridad de C�digo y Documentos
Si le envi�mos electr�nicamente a alguien un documento (o unos documentos) importantes, o un applet o una aplicaci�n para que los ejecute, el receptor necesita una forma de verificar que el documento o el c�digo procede de nosotros y que no se ha modificado en el tr�nsito (por ejemplo, por un usuario malicioso que lo ha interceptado). Las firmas digitales, los certificados y los keystores nos ayudan a conseguir la seguridad de los ficheros que enviamos.
�Firmas Digitales
La idea b�sica del uso de las firmas digitales es la siguiente.
- Nosotros "firmamos" el documento o c�digo usando una de nuestras claves privadas, que podemos generar usando keytool o los m�todos del API de seguridad. Esto es, generamos una firma digital para el documento o el c�digo usando la herramienta jarsigner o los m�todos del API.
- Envi�mos a la otra persona, el "receptor", el documento o c�digo y la firma.
- Tambi�n le suministramos al receptor la clave p�blica correspondiente a la clave privada usada para generar la firma, si el usuario no la tiene todav�a.
- El receptor usa la clave p�blica para verificar la autenticidad de la firma y la integridad del documento/c�digo.
Un receptor necesita asegurarse de que la propia clave p�blica es aut�ntica antes de utilizarla para comprobar la autencidad de la firma. Adem�s es t�pico suministrar un certificado que contenga la clave p�blica en vez de s�lo la propia clave p�blica, como se explica en la siguiente secci�n.
Para m�s informaci�n sobre la terminolog�a y los conceptos de firma y verificaci�n, y una explicaci�n detallada de sus beneficios, puedes ver "Entender la firma y la verificaci�n" en la secci�n de "Archivos JAR".
�Certificados
Un certificado contiene
- Una clave p�blica.
- La informaci�n sobre el "nombre-distinguido" de la entidad (persona, compa�ia, etc) a qui�n pertenece el certificado. Esta entrada se puede tratar como el sujeto o el propietario del certificado. La informaci�n de nombre-ditinguido incluye los siguientes atributos: el nombre de la entidad, unidad organizativa, organizaci�n, poblaci�n, estado o provincia y c�digo del pa�s.
- Una firma digital. Un certificado est� firmado por una entidad, el emisor, para velar por le echo de que la clave p�blica encerrada es la clave p�blica real de otra entidad, el propietario.
- La informaci�n del nombre-distinguido del firmador (emisor).
Una forma de que un receptor pueda chequear si un certificado es v�lido, es verificando su firma digital, usando la clave p�blica del emisor. Esta clave tambi�n puede estar almacenada en otro certificado cuya firma puede ser verificada usando la clave p�blica del emisor del otro certificado. Podemos parar la comprobaci�n cuando alcancemos una clave p�blica en la que creamos y la utilicemos para almacenar la firma del certificado correspondiente.
Si el receptor no puede establecer una cadena verdadera (por ejemplo, porque el emisor del certificado no esta disponible), se pueden calcular la huellas dactilares del certificado, con el comando -printcert o -import de la herramienta keytool. Cada huella dactilar es un n�mero relativamente corto que es �nico e identifica el certificado. El receptor puede entonces llamar al propietario del certificado y comparar las huellas dactilares del certificado recibido con las enviadas por el cercificado.. Si las huellas coninciden, los certificados son iguales.
As� podemos asegurarnos de que un certificado no fue modificado durante el tr�nsito. Otra cosa incierta cuando se trabaja con certificados es la identidad del emisor. Algunas veces un certificado est� auto-firmado, es decir, est� firmado usando la clave privada correspondiente a la clave p�blica que hay en el certificado, el emisor es el mismo que el sujeto. Esto est� bien si el receptor conoce y da como bueno al emisor.
De otro modo el emisor necesita obtener un certificado de una tercera parte constrastada, referidas como Autoridades de certificaci�n (CA). Para hacer esto, enviamos una petici�n de certificado de firma auto-firmado (CSR) al CA. El CA verifica la firma del CSR y nuestra identidad, quiz�s comprobando nuestro carnet de conducir u otra informaci�n. El CA garantiza que nosotros somos los propietarios de la clave p�blica enviando un certificado firmado con su propia clave privada (la del CA). Cualquiera que crea en la emisi�n de la clave p�blica del CA puede verificar la firma del certificado. En muchos casos el env�o del propio CA puede tener un certificado de otro CA de mayor nivel en la jerqu�as de CA, empezando una cadena de certificados.
Los certificados de entidades en las que creemos normalmente se importan en nuestro keystore (almacen de claves) como "certificados verdaderos". La clave p�blica de dichos certificados puede ser utilizada para verificar las firmas generadas usando la correspondiente clave privada. Dichas verificaciones se pueden hacer mediante
- La herramienta jarsigner (si el documento o el c�digo firmado aparecen en un fichero JAR)
- Los m�todos del API, o
- El sistema de ejecuci�n, cuando se intenta el acceso a un recurso y el fichero de pol�tica espec�fica que el acceso a ese recurso est� permitido para le c�digo que lo intenta, el acceso s�lo se permite si la firma es aut�ntica. Los ficheros class y la firma deben estar en un fichero JAR.
Si estamos enviando dcocumentos o c�digo firmados a otras personas, necesitamos suministralos con el certificado que contiene la clave p�blica correspondiente a la clave privada usada para firmarlo. El comando -export de keytool o los m�todos del API pueden exportar nuestro certificado desde nuestro almacen de claves a un fichero, que puede ser enviado a cualquiera que lo necesite. Una persona que reciba el certificado puede importarlo dentro de su almacen de claves como certificado verdadero, usando, por ejemplo, los m�todos del API o el comando -import de keytool.
Si usamos la herramienta jarsigner para generar la firma de un fichero JAR, la herramienta recupera nuestro certificado y su correspondiente cadena de certificados desde nuestro almacen de claves. Luego, la herramienta los almacena, junto con la firma en el fichero JAR.
�Keystores (Almacenes de Claves)
Las claves privadas y sus certificados de claves p�blicas asociadas est�n almacenadas en unas bases de datos protegidas por passwords llamadas keystores. Un keystore puede contener dos tipos de entradas: las entradas de certificados verdaderos descritas anteriormente, y entradas clave/certificado, cada una de ellas contiene un clave privada y el correpondiente certificado de la clave p�blica. Cada entrada en el keystore est� identificada por un alias.
Un propietario de un keystore puede tener m�ltiples claves en �l, accedidas mediante diferentes alias. Un alias se nombra t�picamente seg�n las reglas particulares en las que el propietario del keystore usa las claves asociadas. Un alias tambi�n podr�a identificar el prop�sito de la clave. Por ejemplo, el alias signPersonalEmail podr�a usarse para identificar una entrada del keystore cuya clave privada es usada para firmar e-mail personales, y el alias signJarFiles podr�a usarse para identificar una entrada cuya clave privada se usara para firmar ficheros JAR.
La herramienta keytool puede usarse para.
- Crear claves privadas y sus certificados de claves p�blicas asociadas.
- Emitir peticiones de certificados, que enviamos a la autoridad de certificaci�n apropiada.
- Importar respuestas de certificados, obtenidos desde la autoridad de certificaci�n contactada.
- Importar certificados de claves privadas pertenecientes a otras partes como certificados verdaderos.
- Manejar nuestro keystore
Los m�todos del API tambi�n pueden usarse para acceder y modificar un keystore.
�Notas del API y las Herramientas
Debemos tener en cuenta los siguientes puntos para utilizar las herramientas y el API relacionado con las firmas digitales.
- Podemos usar el API de Seguridad del JDK, las herramientas, o una combinaci�n de ellas para generar claves y firmas y para importar certificados. Podemos usar ese API y las herramientas para el intercambio seguro de documentos con otras personas.
- Para usar las herramientas para el intercambio de documentos, los documentos deben situarse en un fichero JAR, que puede ser creado con la herramienta jar. Un fichero JAR es una buena forma de encapsular varios ficheros en uno s�lo. Cuando se "firma" un fichero, los bytes resultantes de la firma digital necesitan ser almacenados en alg�n lugar. Esto es lo que sucede cuando usamos el jarsigner para firmar un fichero JAR.
- Si estamos creando un applet que vamos a firmar, necesitamos situarlo en el fichero JAR. Esto mismo tambi�n es cierto para crear aplicaciones que podr�an ejecutarse de forma restingida con un controlador de seguridad. La raz�n por la que necesitamos un fichero JAR es que cuando un fichero de pol�tica especifica que el c�digo firmado por una entidad particular tiene permitidas una o m�s operaciones, como la lectura o escritura de un fichero, se espera que el c�digo provenga desde un fichero JAR firmado. (El t�rmino "c�digo frimado" es una forma abrevidada de decir "c�digo de un fichero class que aparece en un fichero JAR que fue firmado digitalmente").
- Para que el sistema de ejecuci�n pueda comprobar la firma del c�digo, la persona/organizaci�n que ejecutar� el c�digo primero necesita importar en su keystore un certificado de autentificaci�n de la clave p�blica correspondiente a la clave privada usada para firmar el c�digo.
- Para que la herramienta jarsigner pueda verificar la autenticidad de la firma de un fichero JAR, la persona/organizaci�n que recibe el fichero JAR primero necesita importa en su keystore un certificado de autenticidad de la clave p�blica correspondiente a la clave privada usada para firmar el c�digo.
- En este momento no existe un API para la creacci�n de certificados.
�Uso del API de Seguridad del JDK para Firmar Documentos
La lecci�n Generar y Verificar Firmas demuestra el uso del API de Seguridad del JDK con respecto a la firma de documentos. La lecci�n muestra que un programa, ejecutado por la persona que tiene el documento original, deber�a.
- generar claves,
- generar una firma digital para los datos usando la clave privada, y
- exportar la clave p�blica y la firma a ficheros.
Luego muestra un ejemplo de otro programa, ejecutado por el receptor de los datos, la firma y la clave p�blica, Muestra c�mo el programa podr�a.
- importar la clave p�blica y
- verificar la autenticidad de la firma.
La lecci�n tambi�n explica y demuestra las posibles alternativas para suministrar e importar claves, incluyendo certificados.
�Usar las Herramientas para Firmar C�digos y Documentos
La lecci�n Firmar C�digo y Conceder Permisos muestra el uso de las herramientas para que un desarrollador ponga el c�digo en un fichero JAR, firmarlo, y exportar la clave p�blica. Luego muestra el uso de las herramientas para alguien que ejecute el c�digo o para un administrador del sistema para importar el certificado de la clave p�blica del firmante y para a�adir una entrada en el fichero de pol�tica para conceder permiso al c�digo para acceder a los recursos que necesita.
La lecci�n Intercambiar Ficheros muestra el uso de las herramientas para que una persona firme un documento importante, como un contrato, y exporte el certificado de la clave p�blica correspondiente a la clave privada usada para firmar el contrato. Luego muestra a otra persona recibiendo el contrato, la firma y el certificado de la clave p�blica podr�a usar keytool para importar el certificado y jarsigner para verificar la firma.
Estas dos lecciones tienen mucho en com�n. En ambos casos, los dos primeros pasos para el emisor del c�digo o el documento son.
- Crear un fichero JAR que contenga el documento o fichero JAR, usando la herramienta jar.
- Generar claves (si no existen ya), usando el comando keytool -genkey.
Los dos siguientes pasos son opcionales.
- Usar el comando keytool -certreq; para enviar la petici�n de firma del certificado resultante a una autoridad de verificaci�n (CA) como VeriSign.
- Usar el comando keytool -import para importar la respuesta del CA.
Los dos siguientes pasos son necesarios.
- Firmar el fichero JAR, usando la herramienta jarsigner y la clave privada generada en el paso 2.
- Exportar el certificado de la clave p�blica, usando la el comando keytool -export. Luego suministrar el fichero JAR firmado y el certificado al receptor.
En ambos casos, el receptor del fichero JAR firmado y el certificado deber�a importar el certificado como un certificado verdadero, usando el comando keytool -import. El keytool intentar� construir una cadena de certificados verdaderos para importarla como un certificado verdadero en el keystore. Si esto falla, keytool mostrar� la huella del certificado y nos pedir� que la verifiquemos.
Si lo que se envi� fue c�digo, el receptor tambi�n necesita modificar le fichero de pol�tica para permitir los accesos a los recursos necesarios para el c�digo firmado por la clave privada correspondiente a al certificado de la clave p�blica importada. Se puede utilizar Policy Tool para hacer esto.
Si lo que se envi� fue uno o m�s documentos, el receptor necesita verificar la autenticidad de la firma del fichero JAR, usando la herramienta jarsigner.
Para m�s informaci�n sobre las herramientas, puedes ver Sumario de Herramientas.
Esta lecci�n explica los dos pasos opcionales. Los otros pasos se cubren en las siguientes lecciones, Firmar C�digo y Conceder Permisos e Intercambiar Ficheros.
�Generar una Petici�n de Firma de Certificado (CSR) para un Certificado de Clave P�blica
Cuando se usa keytool para generar una pareja de claves p�blica/privada, se crea una entrada en un keystore que contiene la propia clave privada y un certificado auto-firmado para la clave p�blica. (Es decir, el certificado esta firmado utilizando la correspondiente clave privada). Esto podr�a ser adecuado su la gente que va a recibir nuestro fichero firmado ya conoce y cree nuestra identidad.
Sin embargo, un certificado es algo m�s que creible por otros si est� firmado por una autoridad de certificaci�n (CA). Para obtener un certificado firmado por una CA, primero generamos un petici�n de firma de certificado (CSR), mediante un comando con este.
keytool -certreq -alias alias -file csrFile
Aqu� alias se usa para acceder a la entrada del keystore que contiene la clave privada y el certificado de la clave p�blica, y csrFile especifica el nombre a usar por el CSR creado por este comando.
Luego deber�amos enviar este fichero a una CA, como VeriSign, Inc. El CA nos autentificar�, el "sujeto", normalmente off-line, y luego firmar� y devolver� un certificado de autentificaci�n para nuestra clave p�blica. Es decir, el CA confirma que nosotros somos los propietarios de la clave p�blica firmando el certificado. (En algunos casos, el CA, devolver� una cadena de certificados, cada uno autentificando la clave p�blica del firmante del certificado anterior en la cadena.)
�Importar la Respuesta del CA
Si hemos enviado una petici�n de firma de certificado (CSR) a una autoridad de autenticidad (CA), necesitamos reemplazar el certificado original auto-firmado en nuestro keystore con un cadena de certificados importando el certificado (o cadena de certificados) devuelta por el CA.
Pero primero necesitamos una entrada "certificado verdadero" en nuestro keystore (o en el fichero cacerts, descrito abajo) que autentifica la clave p�blica del CA. Con est� la entrada de la firma del CA puede ser verificada. Es decir, la firma del CA en el certificado, o en el certificado final en la cadena que el CA env�a en respuesta a nuestro CSR, pueda ser verificada.
�Importar un Certificado desde un CA como un "Certificado Verdadero"
Antes de importar el certificado devuelto por un CA, necesitarmos uno o m�s "certificados verdaderos" en nuestro keystore o en el fichero cacerts.
- Si el certificado de respuesta es una cadena de certificados, necesitamos el certificado superior de la cadena -- el CA "ra�z" certifica la autenticidad de las claves p�blicas del resto de los CAs.
- Si la respuesta es un s�lo certicado, necesitamos un certificado para el CA emisor (uno firmado por ella). Si este certificado no est� auto-firmado, necesitas un certificado para su firmante, etc, hasta el certirficado del CA "ra�z" auto-firmado.
El fichero cacerts representa un keystore de amplio sistema con certificados de CAs. El fichero reside en el directorio de las propiedades de seguridad del JRE, java.home/lib/security, donde java.home es el directorio de instalaci�n del JRE.
El fichero cacerts se recibe con cinco certificados raices de VeriSign. Si enviamos una CSR a VeriSign, no necesitamos importar un certificado de VeriSign como certificado verdadero en nuesto keystore; podemos ir a la siguiente secci�n para ver �como importar el certificado de respuesta del CA.
Un certificado desde una CA normalmente est� auto-firmado o firmado por otra CA, en cuyo caso tambi�n necesitamos un certificado de autentificaci�n de la clave p�blica de la CA.
Debemos tener cuidado de que el certificado sea v�lido antes de importarlo como "certificado verdadero"! Debemos mirarlo primero (usando el comando keytool -printcert o el comando keytool -import sin la opci�n -noprompt), y asegurarnos de que las huellas del certificados mostradas corresponden con las esperadas. Podemos llamar a la persona que nos envi� el certificado y comparar la huella. S�lo si las huellas son iguales est� garantizado que el certificado no ha sido reemplazado en el tr�nsito por el certificado de otra persona (el atancante, por ejemplo).
Si creemos que el certificado es v�lido, podemos a�adirlo a nuesto keystore con un comando como este.
keytool -import -alias alias
-file ABCCA.cer -keystore storefile
Este comando crea un entrada de "certificado verdadero" en el keystore cuyo nombres es el especificado en storefile. La entrada contiene los datos del fichero ABCCA.cer, y est� firmada por el alias especificado.
�Importar el Certificado Devuelto por el CA
Una vez que hemos importado los certificados verdaderos requeridos, como se describe en la secci�n anterior, podemos importar el certificado de respuesta y por lo tanto reemplazar nuestro certificado auto-firmado con una cadena de certificados. Esta cadena puede ser una devuelta por el CA en respuesta a nuestra petici�n (si la respuesta del CA es una cadena) o una construida (si el CA devolvi� s�lo un certificado) usando el certificado devuelto y los certificados verdaderos que tenemos disponibles en el keystore o en el fichero cacerts.
Como ejemplo, supongamos que hemos enviado una petici�n de firma de certificado a VeriSign. Podemos importar la respuesta mediante el siguiente comando que asume que el certificado devuelto est� en el fichero especificado por certReplyFile.
keytool -import -trustcacerts -keystore storefile -alias alias -file certReplyFile
Debemos teclear el comando en una s�la l�nea.
El certificado de respuesta es validado usando certificados verdaderos desde el keystore y opcionalmente usando los certificados configurados en el fichero cacerts (si se especifica la opci�n -trustcacerts). Cada certificado de la cadena est� verificado, usando el certificado del siguiente nivel superior en la cadena. S�lo necesitamos creer en el certificado del CA superior en la cadena. Si realmente no creemos en �l, keytool mostrar� la huella dactilar del certificado y nos preguntar� si creemos en ella o no.
La nueva cadena de certificados de la entrada especificada por el alias reemplaza el viejo certificado (o cadena) asociado con esa entrada. La vieja cadena s�lo puede ser reempalzada si hay un keypass, se suministra la password usada para proteger la clave privada de la entrada. Si no se proporciona password o si la password de la entrada es diferente de la existente, se le pedir� al usuario.
Para informaci�n m�s detallada sobre la generaci�n de CSR y la importaci�n de las respuestas, puedes ver la documentaci�n de keytool en la web site p�blica de java.sun.com.