## API y Herramientas usadas para Código Seguro e Intercambio de Ficheros

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: Firmar Código y Concederle Permisos e Intercambiar Ficheros. La utilización del API se explica en la lección Generar y Verificar Firmas.

Esta lección contiene las sigueintes secciones:

- Seguridad de Código y Documentos
- Notas del API y las Herramientas
- Uso del API de Seguridad del JDK para Firmar Documentos
- Uso de Herramientas para Firmar Codigo o Documentos

### Seguridad de Código y Documentos

> Si le enviámos electrónicamente a algguien 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 kaystores nos ayudan a conseguir la seguridad d elos ficheros que enviamos.

### Firmas Digitales

> La idea básica del uso de las firmas digitales es la siguiente:
> 1. 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.

> 2. Enviámos a la otra persona, el "receptor", el documento o código y la firma.

> 3. También le suministramos al receptor la clabve pública correspondiente a la clave privada usada para generar la firma, si el usuario no la tiene todavía.

> 4. El receptor usa la clave pública para verificar la autenticidad de la firma y la interidad del documento/código.

> Un receptor necesitar asegurarse de que la propia clave pública es auténtica antes de utilizarla para comprobar la autencidad de la firma. Además es más 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 trata 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ódig del país.

> - Una firma digital. Un certificado está firmado por una entidad, el emisor, para velar por le echo de que la clabe 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 para la comprobación cuando alcancemos una clave pública en la que creamos y la utilicemos para almacerar la firma delcertificado correspondiente.

> Si el receptor no puede establecer una cadena verdadera (por ejemplo, porque el emisor del certificado no esta disponible), se pueden calvular la huellas dactilares del certificado, con elcomando -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 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 conoces 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). Cualquiere que crea en la emisión de la clave pública del CA puede verificar la firma del certificado. En muchos caos 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 (alamcen 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 policía específica que el acceso a ese recursos 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 ficheor JAR.

> Si estamos enviando dcocumentos o código firmados a otras personas, necesitamos suministralo con el certificado que contiene la clave pública correspondiente a la clave privada usada para firmalo. 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 se enviado a cualquiera que lo necesite. Una persona que reciva 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 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 mediantes diferentes alias. Un alias es nombrado 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 JDKm 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. Estato 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 policía 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 abrevidad 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 jeystore un certificado de autenticidad de la clave pública correspondiente a la clav eprivada 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 uno 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 mustra 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 le 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 policía 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 otra persona recibiendo el contrato, la firma y el certificado de la clave pública pod´ria 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, usnado 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 policía 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 dle 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, 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 ise 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 inportar 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-firmaod.

> El fichero cacerts representa un keystores 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 normalment 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 es 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 asrgurarnos 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 reempalzado 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 elcertificado de respuesto 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, suponfamos 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 devuelte 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 desee el keystore y opcionalmente usando los certificados configurados en el fichero cacerts (si se especifica la opción -trustcacerts). Cada certificad 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 detalladas 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:

> - keytool documentation with Windows examples
> - keytool documentation with UNIX examples

Ozito