Creación dunha Infraestructura de chave pública (PKI): Diferenzas entre revisións

De Wiki do Ciclo ASIR do IES de Rodeira
Saltar á navegación Saltar á procura
 
(Non se amosan 50 revisións do historial feitas polo mesmo usuario.)
Liña 129: Liña 129:
# Certificado da CA
# Certificado da CA
openssl req -new -x509 -extensions v3_ca -days 3650 -key private/ca.key -out ca.crt
openssl req -new -x509 -extensions v3_ca -days 3650 -key private/ca.key -out ca.crt
#
# Certificado do CRL
openssl ca -config ../openssl.cnf -gencrl -out crl/crl.pem
#
#
# Chave Privada e solicitude de certificado para o servidor OCSP
# Chave Privada e solicitude de certificado para o servidor OCSP
Liña 158: Liña 161:
</source>
</source>
Si quixeramos non cifrar a chave privada, non especificaríamos ''-newkey'', poñendo no seu lugar ''-new -nodes''. A solicitude <u>''nome_certificado.csr''</u> se envía a autoridade de certificación, por correo electrónico, FTP... etc.
Si quixeramos non cifrar a chave privada, non especificaríamos ''-newkey'', poñendo no seu lugar ''-new -nodes''. A solicitude <u>''nome_certificado.csr''</u> se envía a autoridade de certificación, por correo electrónico, FTP... etc.

Cando creamos a solicitude de firma (CSR), o sistema irá preguntando pola información a incluír no certificado. Pode resultar máis práctico que colla esta información preparando un ficheiro coa información. Vexamos un exemplo:

<source lang='text'>
# Creamos o ficheiro my_site.com.csrconfig
[req]
distinguished_name = req_distinguished_name
req_extensions = v3_req
prompt = no

[req_distinguished_name]
C = ES
ST = Galiza
L = Cangas do Morrazo
O = IES de Rodeira
OU = Departamento de Informática
CN = www.company.com

[v3_req]
#keyUsage = keyEncipherment, dataEncipherment
#extendedKeyUsage = serverAuth
subjectAltName = @alt_names


[alt_names]
DNS.1 = www.company.com
DNS.2 = company.com
DNS.3 = www.company.net
DNS.4 = company.net

</source>

A petición a poderíamos facer así:
''openssl req -config my_site.com.csrconfig -new -nodes -keyout nome_chave_privada.key -out nome_certificado.csr''


2.- '''A Autoridade de Certificación''', previa comprobación acorde ao nivel de seguridade solicitado pola entidade, firma o certificado.
2.- '''A Autoridade de Certificación''', previa comprobación acorde ao nivel de seguridade solicitado pola entidade, firma o certificado.
Liña 173: Liña 210:


Podemos especificar ''-policy seccion'' para indicar o tipo de información a gardar no certificado segundo o arquivo ''/etc/ssl/openssl.cnf''
Podemos especificar ''-policy seccion'' para indicar o tipo de información a gardar no certificado segundo o arquivo ''/etc/ssl/openssl.cnf''



{{boxinfo|Existen 3 niveis de certificación:
{{boxinfo|Existen 3 niveis de certificación:
Liña 199: Liña 237:
openssl ca -config ../openssl.cnf -revoke correo.iesrodeira.com.pem
openssl ca -config ../openssl.cnf -revoke correo.iesrodeira.com.pem
</source>
</source>

== Creación dunha CA Intermedia ==
Unha autoridade de certificación intermedia é unha entidade que pode firmar certificados en lugar da CA raíz. A CA raíz firma o certificado da CA intermedia, formando unha cadea de confianza.

O principal propósito das CA intermedias é a seguridade. A chave privada da CA raíz pode gardarse fora de liña (sin conexión á rede) e ser utilizada o menos posible. Si se ve comprometida a chave privada da CA intermedia, a CA raíz pode revocar o certificado e crear un novo.

Para crear unha CA intermedia, deberíamos crear unha estructura PKI completa e indicar como política no openssl.conf "policy_loose", en lugar do máis restrictivo "policy_strict" do CA raíz (O policy indica que información debe presentar o certificado e cómo, para poder ser firmado). A continuación crearemos a parella chave privada-solicitude de certificado:

<source lang='text'>
openssl genrsa -aes256 -out private/intermediate.key 4096

openssl req -config ../openssl.cnf -new -sha256 \
-key private/intermediate.key.pem \
-out private/intermediate.csr
</source>

{{boxinfo|A información suministrada para o CSR debería coincidir coa do CA raíz, salvo o ''Common Name'', que debe ser distinta.}}

A continuación se "enviaría" o CSR a CA raíz para a súa firma (no noso caso o poñemos na carpeta certs da CA raíz). Unha vez que estamos no CA raíz, firmaríamos o CSR indicando que a firma é para unha CA intermedia mediante o parámetro ''-extensions v3_intermediate_ca'':

<source lang='text'>
# openssl ca -config ../openssl.cnf -extensions v3_intermediate_ca \
-days 3650 -notext -md sha256 \
-in certs/intermediate.csr \
-out certs/intermediate.crt
</source>

A continuación podemos comprobar a validez do certificado:

<source lang='text'>
openssl x509 -noout -text -in certs/intermediate.cert.pem

openssl verify -CAfile ca.crt certs/intermediate.crt
</source>

Cando unha aplicación (como un navegador web) intente verificar un certificado firmado pola CA intermedia debe verificar o certificado intermedio mediante o certificado da CA raíz. Polo tanto é necesario crear unha cadea de certificados para presentar a aplicación:

<source lang='text'>
cat certs/intermediate.crt ca.crt > certs/ca-chain.crt
</source>

Agora podemos enviar de volta a CA intermedia o certificado e a cadea de certificación....

{{boxinfo|É necesario crear unha cadea de certificación para que se inclúa o certificado da CA raíz e non necesitemos que os navegadores ou a aplicación correspondente teñan que instalar dúas CA. Unha opción mellor, en particular nunha intranet, é instalar o certificado do CA raíz en todos os clientes, nese caso únicamente necesitaríamos o certificado da CA intermedia.}}


=== Uso na Web ===
=== Uso na Web ===
O uso de certificados criptográficos na Web é o xeito máis utilizado de asegurar tanto a identidade dos servidores web, como de garantizar a seguridade da información intercambiada. Cando un cliente web intenta o acceso a un servidor que fai uso de cerfificados (https, normalmente baixo o porto 443) o servidor responde en primeiro lugar co seu certificado, o cliente intentará comprobar a validez do mesmo utilizando os certificados das autoridades de certificación recoñecidas para verificar a firma, o que garantiza a identidade do servidor.
O uso de certificados criptográficos na Web é o xeito máis utilizado de asegurar tanto a identidade dos servidores web, como de garantizar a seguridade da información intercambiada. Cando un cliente web intenta o acceso a un servidor que fai uso de certificados (https, normalmente baixo o porto 443) o servidor responde en primeiro lugar co seu certificado, o cliente intentará comprobar a validez do mesmo utilizando os certificados das autoridades de certificación recoñecidas para verificar a firma, o que garantiza a identidade do servidor.


Si o certificado pasa os requerimentos do cliente, a comunicación se realizará de forma cifrada, de xeito que o servidor cifrará a información a enviar coa chave privada e o cliente o fará coa pública. Esto garantiza a privacidade da comunicación.
Si o certificado pasa os requerimentos do cliente, a comunicación se realizará de forma cifrada garantizando a privacidade da comunicación.


==== Configuración de HTTPS en Apache Web Server====
Precisaremos un certificado e a chave privada correspondente. Como o servidor ''Apache'' necesita acceder á chave privada, se queremos evitar ter que suministrar a ''password'' da mesma en cada inicio, podemos xerar unha chave privada sen protección:
<source lang='text'>
openssl req -nodes -newkey rsa:4096 -keyout nome_chave_privada.key -out nome_certificado.csr
</source>
Tamén é posible eliminar a protección unha vez xerada a chave con:
<source lang='text'>
openssl rsa -in nome_chave_privada.key -out nome_chave_privada.net.key.insecure
</source>
Unha vez firmada a solicitude de certificado '''.csr''' pola autoridade de certificación e obtido o certificado ('''.pem''' ou '''.crt'''), necesitamos ter activo o módulo ''ssl'':
<source lang='text'>
a2enmod ssl
</source>


Unha configuración típica dun sitio virtual baixo ''SSL'' sería, copiando previamente a nosa chave privada ''server.key'' e o certificado firmado ''server.crt'' en ''/etc/ssl/certs/'':
==== HTTPS ====
<source lang='text'>
// Creación de chave sen cifrado


// Eliminación da chave do certificado
openssl rsa -in secure.debiantutorials.net.key -out secure.debiantutorials.net.key.insecure
NameVirtualHost a.b.c.d:80
NameVirtualHost a.b.c.d:80
<VirtualHost a.b.c.d:80>
<VirtualHost a.b.c.d:80>
Liña 229: Liña 322:
SSLEngine on
SSLEngine on
SSLCertificateFile /etc/ssl/certs/server.crt
SSLCertificateFile /etc/ssl/certs/server.crt
SSLCertificateKeyFile /etc/ssl/certs/server.pem
SSLCertificateKeyFile /etc/ssl/certs/server.key
SetEnvIf User-Agent ".*MSIE.*" nokeepalive ssl-unclean-shutdown
SetEnvIf User-Agent ".*MSIE.*" nokeepalive ssl-unclean-shutdown
CustomLog /var/log/apache2/ssl_request_log \
CustomLog /var/log/apache2/ssl_request_log \
Liña 237: Liña 330:
</VirtualHost>
</VirtualHost>


</source>
==== Certificados de Cliente ====
O primeiro ''VirtualHost'' non é máis que unha redirección de maneira que os accesos baixo ''http'' se redirixan de xeito automático ao ''VirtualHost'' baixo ''https''.
openssl pkcs12 -export -clcerts -inkey amiñachave.key -in meucert.crt -out meucert.pkcs12


E necesario indicar a IP (''a.b.c.d'') porque normalmente únicamente se soporta un único sitio virtual baixo SSL por cada IP do servidor, xa que é necesario o certificado do sitio para saber o sitio solicitado. Sen embargo, as últimas versións dos navegadores e de Apache soportan a extensión ''TLS'' '''''Server Name Indication (SNI)''''' que permite o uso de varios sitios virtuais distintos baxio ''https''. Necesitaremos:


*Editar '''/etc/apache2/ports.conf''' para indicar:
A EXTENSION TEN QUE SER nome.pkcs12 OBLIGATORIAMENTE PARA ICEWEASEL
<source lang='text'>
<IfModule mod_ssl.c>
NameVirtualHost *:443
Listen 443
</IfModule>


<IfModule mod_gnutls.c>
During the conversion dialog you will be asked for an export password; enter anything you can remember, but don't let it be empty. What you get now is a file which not only keeps the certificate, but also your private Key. Copy this file to your workstation (Windows/Linux/Mac OS X), start Mozilla and go through the browsers menu structure like
NameVirtualHost *:443
Listen 443
</IfModule>
</source>


*Debemos asegurarnos que no ''VirtualHost'' por defecto e nos VirtualHosts baixo SSL está especificado ''<VirtualHost *:443>''.


Si o cliente (navegador) non soporta as extensións '''SNI''', podemos negarlle o acceso descomentando a liña
Now enter your formerly chosen export password, then the passphrase of your previously generated private key, which is contained in the P12 file. Finished! But still there's a catch: the browser does not know anything about the CA which created and signed your new user certificate. To complete this task we have to import the root CA certificate as well. This is very easy, although it took me 2h to find out how to do with Mozilla :). Just put the garexCA.CRT on a public http port 80 webserver, enter the URL in your browser and click on the garexCA.CRT.
<source lang='text'>
SSLStrictSNIVHostCheck On
</source>
ao final de ''/etc/apache2/mods-enabled/ssl.conf''.


==== Certificados de Cliente ====
http://www.garex.net/garexCA.CRT
Os ''Certificados de Cliente'' permiten a identificación dun cliente por parte dun servidor web, de xeito que se lle podan otorgar privilexios de acceso especiais. Cando o sitio web precisa identificar ao cliente, lle envía unha solicitude de certificado. O cliente enviará o certificado correspondente ao sitio, e o servidor web, previa comprobación do mesmo, garantizará ou denegará o acceso.
and - what a surprise - the browser recognizes this certifiacte as a new root CA certificate and offers you to import this certificate to your root CA chain. :))


Para configurar este comportamento no Apache, necesitaremos configurar un sitio baixo https, e indicarlle que imos requerir un certificado do cliente mediante a directiva ''SSLVerifyClient require''. O servidor, ao recibir o certificado, realizará unha verificación da ''cadea de confianza'' ata a profundidade indicada pola directiva ''SSLVerifyDepth''.
Internet Explorer, the thing from a different world
Once again Microsoft's Internet Explorer has its own standards: it only accepts certificates of the type DER. Therefore we have to convert our user certificate and the root CA certificate:


Con esta configuración, a Apache lle bastaría calqueira certificado válido, polo que é necesario configurar un filtro de certificados que descarte os que non sirvan a partir da súa informació, do seguinte xeito:
# openssl x509 -inform PEM -in garex.CRT -outform DER -out garex.CRT.der
<source lang='text'>
# openssl x509 -inform PEM -in garexCA.CRT -outform DER -out garexCA.CRT.der
SSLRequire %{SSL_CLIENT_S_DN_O} eq "IES de Rodeira" and %{SSL_CLIENT_S_DN_OU} in {"Departamento de Informatica"}
</source>


Unha posible configuración para unha carpeta dun sitio Web sería:
<source lang='text'>
<VirtualHost *:443>
ServerName servidor.iesrodeira.com
DocumentRoot /var/www/servidor


SSLEngine on
Apache
SSLCertificateFile /etc/ssl/private/msdn.iesrodeira.com.crt
SSLCertificateKeyFile /etc/ssl/private/msdn.iesrodeira.com.key
SSLCACertificateFile /etc/ssl/certs/myca.crt


<FilesMatch "\.(cgi|shtml|phtml|php)$">
Ok, we got an installed webserver certificate and we got an imported user certificate. But how can we force apache to not accept any certificate a user browser might come with? At this moment, our apache accepts any SSL connection. Therefore we have to force him to crosscheck whether the presented user certificate is valid, allowed to connect and if a username/password combination was verified successfully. For this, we change the following apache configuration options:
SSLOptions +StdEnvVars
</FilesMatch>
BrowserMatch "MSIE [2-6]" \
nokeepalive ssl-unclean-shutdown \
downgrade-1.0 force-response-1.0
# MSIE 7 and newer should be able to use keepalive
BrowserMatch "MSIE [17-9]" ssl-unclean-shutdown
<Directory /var/www/servidor/restricted>
# Restinxido mediante certificado de cliente
SSLRequireSSL
SSLVerifyClient require
SSLVerifyDepth 2
SSLRequire %{SSL_CLIENT_S_DN_O} eq "IES de Rodeira" and %{SSL_CLIENT_S_DN_OU} in {"Departamento de Informatica"}
</Directory>
</VirtualHost>
</source>


Existen múltiples directivas de xestión de certificados que permiten o uso de listas de revocación ou servidores OCSP, podes consultalas na [http://httpd.apache.org/docs/2.2/mod/mod_ssl.html documentación de Apache]
SSLVerifyClient require
SSLVerifyDepth 2
Usually, apache would verify the whole certificate chain up and down, e.g. if you bought a commercial certificate at VeriSign it would verify the signer of this VeriSign certificate, then the signer of VeriSign's root certificate, then the signer's signed certificate and so on. You see, it's a chain, a so called "web of trust". Apache's default value is 10, so in terms 10 root CA in the chain. Here the depth level of 2 is enough, as we only have one CA and one webserver/user certificate.


O certificado de cliente permite o acceso únicamente aos navegadores que dispoñan dun certificado válido admitido polo servidor, pero non verifica a identidade da persoa utilizando o mesmo. Para garantizar a identidade da persoa, se debería engadir un sistema de autenticación do xeito indicado [[Servidores_Web_e_Servidores_de_Aplicacións#Autenticaci.C3.B3n|neste documento]].
OK folks, but now we want only certain certificates to be allowed to connect. How can we manage this? Very easy, as we are now going to modify settings concerning the document root of our small SSL webserver. After the "DocumentRoot" directive we add:


Nos clientes web, será necesario instalar os certificados de cliente para enviar. O '''''firefox/mozilla''''' acepta os certificados en formato '''pkcs12''', que inclúen tanto o certificado como a súa chave privada, polo que será necesario exportar o certificado firmado a este formato e importalo logo ao navegador, xunto co certificado da autoridade de certificación.
...
<Directory "/www/hidden/docs">
<IfDefine SSL>
SSLRequireSSL
SSLRequire %{SSL_CLIENT_S_DN_O} eq "garex AG" and
%{SSL_CLIENT_S_DN_OU} in {"Fun dept."}
</IfDefine>
...
</Directory>
...
You see, if the "Organisation" we defined earlier in the openssl.cnf does not match the webserver certificate AND the user certificate AND the root CA certificate, EVERY request to this webserver will be dropped!!!


{{boxinfo|Firefox/Iceweasel únicamente acepta certificados coa extensión ''.pkcs12''}}
Effectively, the certificate content - the certificate string hidden within your certificate - will be checked; in this case we broke the check down to several components like organisation and organizational unit. Therefore it is a MUST, that the client certificate is verified against these two conditions, e.g. organisation equals to "garex AG" and organizational unit to "Fun dept." If you want to add other departments, just add them at the end of the verification line.


<source lang='text'>
But we are not finished yet. Certificates are a nice thing, but what if the person leaves the room for a short time and a "bad guy" sits in front of the unlocked PC? So we add an "AuthConfig" line after the upper "</IfDefine>":
openssl pkcs12 -export -clcerts -inkey chaveprivada.key -in meucert.crt -out meucert.pkcs12
</source>


{{boxinfo|Para importar o certificado da autoridade de certificación, bastará con facelo dispoñible nun enlace a través da web. O navegador recoñecerá automáticamente que é un certificado e procederá a súa instalación}}
AllowOverride AuthConfig
Order deny,allow
Allow from all


'''''Internet Explorer''''' traballa dun modo lixeiramente distinto. Os certificados deben estar en formato '''DER''', Polo que necesitaremos convertir a ese formato tanto o noso certificado como o certificado da autoridade de certificación:
AuthType Basic
<source lang='text'>
AuthName "Authentication required"
openssl x509 -inform PEM -in meusitio.CRT -outform DER -out meusitio.CRT.der
AuthUserFile /opt/apache-1.3.26-ssl/etc/passwd
openssl x509 -inform PEM -in RodeiraCA.CRT -outform DER -out RodeiraCA.CRT.der
AuthGroupFile /opt/apache-1.3.26-ssl/etc/group
</source>
require valid-user
require group support
Satisfy all
Last but not least we create a passwd file and a group file:


=== Uso no E-mail ===
# mkdir /opt/apache-1.3.26-ssl/etc
Os certificados poden ser utilizados no correo electrónico tanto para a realización de firmas (asegurar autoría e integridade), como para o cifrado do seu contido e asegurar así a privacidade. A configuración ven determiñada polo cliente de correo electrónico, aínda que é similar en todos eles.
# /opt/apache-1.3.26-ssl/bin/htpasswd -c \
/opt/apache-1.3.26-ssl/etc/passwd garex
The group file looks like this:


Normalmente se deben importar (no sistema ou no cliente de correo, según a integración do cliente) o certificado da autoridade de certificación como autoridade de certificación, e os certificados persoais a utilizar na conta de correo en '''formato pkcs12'''. Unha vez incorporados os certificados, nas opcións de seguridade da conta de correo, se indicarán os certificados a utilizar para o cifrado e firma S/MIME.
support: garex
NOW we have to restart apache for the new settings. You have to do a hard stop/start, as changes to the SSL configuration will otherwise not be loaded, as mod_ssl is already loaded by the httpd. And NOW you will see, that only an user with the proper certificate and username/password can get access to this webserver's content! Of course what is missing are so-called "Certificate Revocation Lists", which allows us to disable a user certificate with openssl, export this list into a file, load this file into apache and - voila! - the former valid user certificate is invalid.


O funcionamento é o seguinte:
=== Uso no E-mail ===
;Desexamos enviar un correo firmado e cifrado a outro usuario: A firma se realizará co noso certificado, pero para enviar o correo cifrado precisamos ter instalado o certificado de usuario do destiñatario (a súa chave pública). O destiñatario deberá ter o noso certificado para comprobar a firma, e descifrará o correo facendo uso do seu propio certificado.
==== Firma de Correos ====

==== Cifrado de Correos ====
;Recibimos un correo firmado e cifrado: Para verificar a firma necesitamos o certificado do firmante (a súa chave pública), e para descifralo bastará co noso propio certificado.


=== Cifrado e Firmado de documentos ===
=== Cifrado e Firmado de documentos ===
Outro uso dos certificados é a firma e cifrado de documentos. En realidade é o mesmo procedemento que se realiza na firma e cifrado de correos electrónicos.

Por exemplo, para cifrar pequenas cantidades de texto mediante o algoritmo ''RSA'' (axeitado para información de pouca lonxitude) e descrifralo posteriormente poderíamos facer o seguinte:

<source lang='text'>
#Obtemos a chave pública correspondente a nosa chave privada
openssl rsa -in chaveprivada.key -out chavepublica.pkey -outform PEM -pubout

#Cifrado
openssl rsautl -inkey chavepublica.pkey -pubin -encrypt -in ficheiro.txt > ficheiro.txt.cifrado

#Descifrado
openssl rsautl -inkey chaveprivada.key -decrypt -in ficheiro.txt.cifrado
</source>


De xeito similar, para firmar un documento, necesitaremos tamén a chave pública correspondente

<source lang='text'>
#Firma
openssl dgst -sha1 -sign chaveprivada.key file.txt > file.txt.firma

#Comprobación da firma
openssl dgst -sha1 -verify chavepublica.pkey -signature file.txt.firma file.txt
</source>

O algoritmo ''RSA'' non é axeitado para cifrar grandes documentos, polo que unha solución habitual é utilizar unha chave simétrica para o cifrado, e cifrar mediante RSA a chave de cifrado. Deste xeito, a outra parte poderá descifrar a chave e a continuación o documento.

<source lang='text'>
#Creación da chave simétrica de cifrado
MYKEY="" ; for((a=1;a<=100;a++)) do MYKEY=$MYKEY$RANDOM ; done ; echo $MYKEY > file.txt.symkey ; MYKEY=""
#Cifrado do ficheiro coa chave simétrica
openssl des3 -e -kfile file.txt.symkey -in file.txt -out file.txt.symenc
#Ciframos a chave simétrica
openssl rsautl -inkey chavepublica.pkey -pubin -encrypt -in file.txt.symkey > symkey.cifrada

# A outra parte recibiría symkey.cifrada e file.txt.symenc

#Descifrado da chave simétrica
openssl rsautl -inkey chaveprivada.key -decrypt -in symkey.cifrada > file.txt.symkey
#Descifrado do ficheiro mediante a chave simétrica
openssl des3 -d -kfile file.txt.symkey -in file.txt.symenc
</source>

=== O DNIe e as tarxetas criptográficas ===
=== O DNIe e as tarxetas criptográficas ===
O punto débil do cifrado de chave pública está na distribución dos certificados e no almacenamento de chave pública. Si alguén consigue acceso a unha chave privada, poderá suplantar ao seu propietario. Ademáis, si necesitamos firmar documentos e proporcionar a nosa identidade dende distintos equipamentos, necesitaremos portar os nosos certificados, co conseguinte problema de seguridade.

Unha solución a este problema é o uso de tarxetas criptográficas. As tarxetas criptográficas ou ''SmartCards'' son pequenas pezas de plástico, normalmente do tamano dunha tarxeta de crédito que inclúen unha memoria e un procesador con capacidades criptográficas. Na súa memoria se poden almacenar documentos que únicamente serán accesibles para o seu microprocesador, co que é un bo xeito de transportar e utilizar certificados e chaves privadas. Para protexer o acceso ao microprocesador e as súas funcións empregase normalmente un '''PIN''' ''(Personal Identification Number)''.

Se poden establecer varias clasificacións de tipos de SmartCards:
;Con e sin contacto: As tarxetas ''de contacto'' precisan dun elemento que suministre enerxía eléctrica ao microprocesador, e polo tanto teñen que insertarse nun dispositivo, mentras que as tarxetas ''sin contacto'' funcionan mediante radio frecuencia (''RFID''), e obteñen a enerxía necesaria da propia conexión de radio. Tamén existen tarxetas mixtas que incorporan os dous métodos. As tarxetas con contacto utilízanse normalmente como identificación, mentras que as tarxetas sin contacto se empregan para funcións como a apertura de portas.
;De Memoria e con Microprocesador: ''As tarxetas de memoria'' teñen unha ''EEPROM'' e un microcontrolador que permite o acceso a ela. Os datos se bloquean mediante un PIN, pero non poden realizar transformacións criptográficas. Utilízanse para funcións como monedeiros electrónicos ou crédito telefónico. ''As tarxetas con microprocesador'' son como pequenos ordenadores con RAM, ROM e EEPROM, cun pequeno sistema operativo en ROM que manexará o acceso aos ficheiros almacenados na EEPROM e executará funcións na RAM. Este tipo de tarxetas poden realizar funcións criptográficas polo que habitualmente se utilizan para identificación.

A maior parte das ''SmartCards'' teñen sistemas operativos propios o que fai complexo a creación de aplicacións que soporten múltiples tipos de tarxetas e que den acceso a máis funcións das ofrecidas nos estándares '''ISO7816'''. Os sistemas máis empregados hoxe en día son ''JavaCard'', desenvolto por ''Sun'' (hoxe ''Oracle''), ''MULTOS'' deseñado para alta seguridade ou a versión de Microsoft, ''SmartCard for Windows''.

Os usuarios poden interactuar coas ''SmartCards'' a través de diversos ''API''. Os máis comúns son:
;[[wikipedia:CT-API|CT-API]]: Este API proporciona funcións xenéricas que permiten a comunicación con tarxetas de memoria e de microprocesador, cumplindo os estándares '''ISO7816'''.
;PC/SC ([[wikipedia:PC/SC|Personal Computer/Smart Card]]): Son un conxunto de especificacións desenvoltas por polo ''PC/SC Workgroup''. Existen implementacións de este ''API'' baixo ''Windows'', ''Linux'' e ''OS/X''.
;[[wikipedia:OpenCard_Framework|OpenCard]]: E un API basado en Java para o acceso a ''SmartCards''.

Baixo Linux o mellor soportado é '''PC/SC''', mediante ''pcscd''. En ''Debian'' deberemos instalar os paquetes ''pcscd'' e ''pcsc-tools''. As operacións coas tarxetas realízanse co software ''opensc''. E aconsellable ter instalado algún medio gráfico de solicitude de PIN como ''pinentry-gtk2''.

A configuración de smartcards realízase habitualmente co software propietario que suministra o fabricante, polo que sería unha boa idea mercar tarxetas soportadas por ''opensc'', de xeito que funcione correctamente baixo Linux. Si configuramos unha tarxeta cun software, únicamente será posible modificar a configuración con ese mesmo software.

En España, a Dirección Xerál da Policía implementou un sistema de identificación basado en certificados de chave pública e o uso de SmartCards denominado ''DNIe'' ou ''DNI Electrónico''. Mediante esta tarxeta, e previa solicitude da creación dos certificados, é posible identificarse en numerosas web e realizar firmas criptográficas de documentos con unha completa validez legal.

O DNIe español realizou un módulo en código pechado para o seu uso con opensc, ao que opensc non da soporte. Recentemente liberouse o código e lanzouse o proxecto '''opendnie'''. Deste xeito existen dúas maneiras de traballar co DNIe: a través do oficial, da ''Dirección General de la policía y de la Guardia Civil (DGP)'' basada en ''OpenSC-0.11.8'' e xa non mantida, e mediante a implementación libre ''OpenDNIe'', que está pendente da súa integración na rama principal de ''OpenSC''. Recoméndase o uso de ''OpenDNIe'' para o uso do DNIe español, podes ver o seu código fonte na [https://github.com/clopez/OpenSC-OpenDNIe-Debian Páxina do Proxecto].

Podes consultar a [[Instalación_do_DNIe_en_Linux|Guía de Configuración do DNIe en Linux]] para máis información.


== GnuPGP (PGP) ==
== GnuPGP (PGP) ==
Liña 319: Liña 504:
gpg --gen-key
gpg --gen-key
</source>
</source>
Esta operación creará unha parella de chaves asimétricas (pública e privada), almacenado por defecto a información ''GPG'' relativa ao usuario na carpeta ''.gnupg'' dentro do ''home'' de usuario.

* Listado de chaves
* Listado de chaves
<source lang='text'>
<source lang='text'>
gpg --list-keys
gpg --list-keys
</source>
</source>
Esta operación listará o conxunto de chaves públicas ''GPG'' que temos almacenadas e nas que confiamos.

* Exportación da chave pública
* Exportación da chave pública
<source lang='text'>
<source lang='text'>
gpg --armor --export usuario@dominio > mypublickey.pkey
gpg --armor --export usuario@dominio > mypublickey.pkey
</source>
</source>
Esta operación exportará unha chave pública a un ficheiro, de xeito que podamos distribuíla.

* Importación dunha chave pública para o seu uso automático
* Importación dunha chave pública para o seu uso automático
<source lang='text'>
<source lang='text'>
gpg --import ficheiro.pkey
gpg --import ficheiro.pkey
</source>
</source>
Esta operación importará unha chave pública ao noso anel de confianza


Existen varios entornos gráficos de usuario, como '''seahorse''' útiles para xestionar as chaves ''GPG''.
O problema principal da criptografía asimétrica é determiñar ata que punto nos podemos fiar das chaves públicas que recopilamos no noso sistema.


O problema principal da criptografía asimétrica é determiñar ata que punto nos podemos fiar das chaves públicas que recopilamos no noso sistema. Para solucionar este problema, se recurre normalmente a ''cadeas de confianza'', nas que confiaremos nos certificados nos que confía alguén da nosa confianza. Para indicar confianza nunha chave se firma coa chave privada, deste xeito si unha chave pública está firmada por unha persoa na que confiamos, podemos fiarnos relativamente que a chave é lexítima.


A distribución de chaves públicas pode facerse por multitude de medios, pero o máis sinxelo é o uso de servidores de chaves públicas como [http://pgp.mit.edu este].
=== Cifrado e Firma de E-mail ===


En este [[Introducción_a_GnuPrivacyGuard|documento]] atoparás unha descripción máis detallada de GPG.
=== Cifrado e Firma de Documentos ===
gpg --output doc.gpg --encrypt --recipient arancha@nav.es doc


gpg --output doc --decrypt doc.gpg


=== Cifrado e Firma de E-mail ===
gpg --output doc.gpg --symmetric doc
[[Image:GPGID.png|400px|center]]
Para firmar os correos electrónicos bastará con indicar na configuración de seguridade o ID GPG a utilizar. O ID o podemos obter como indica a imaxe.
Si queremos cifrar o correo, precisaremos a chave pública do destiñatario. No momento do envío do correo indicamos si queremos cifrar, firmar ou as dúas cousas.


=== Cifrado e Firma de Documentos ===
gpg --output doc.sig --sign doc
*Cifrado de '''doc'''
gpg --output doc.gpg --encrypt --recipient arancha@nav.es doc


*Descifrado de '''doc.gpg'''
Una firma digital certifica un documento y le añade una marca de tiempo. Si posteriormente el documento fuera modificado en cualquier modo, el intento de verificar la firma fallaría. La utilidad de una firma digital es la misma que la de una firma escrita a mano, sólo que la digital tiene una resistencia a la falsificación. Por ejemplo, la distribución del código fuente de GnuPG viene firmada con el fin de que los usuarios puedan verificar que no ha habido ninguna manipulación o modificación al código fuente desde que fue archivado.
gpg --output doc --decrypt doc.gpg


*Cifrado simétrico de '''doc'''
Para la creación y verificación de firmas, se utiliza el par público y privado de claves en una operación que es diferente a la de cifrado y descifrado. Se genera una firma con la clave privada del firmante. La firma se verifica por medio de la clave pública correspondiente. Por ejemplo, Javier haría uso de su propia clave privada para firmar digitalmente la entrega de su última ponencia a la Revista de Química Inorgánica. El editor asociado que la recibiera, usaría la clave pública de Javier para comprobar la firma, verificando de este modo que el envío proviene realmente de Javier, y que no ha sido modificado desde el momento en que Javier lo firmó. Una consecuencia directa del uso de firmas digitales es la dificultad en negar que fue el propio usuario quien puso la firma digital, ya que ello implicaría que su clave privada ha sido puesta en peligro.
gpg --output doc.gpg --symmetric doc


*Descifrado
La opción de línea de órdenes --sign se usa para generar una firma digital. El documento que se desea firmar es la entrada, y la salida es el documento firmado.
gpg --output doc -d doc.gpg
ou, simplemente
gpg doc.gpg


*Firma de '''doc'''
javier:~$ gpg --output doc.sig --sign doc
gpg --output doc.sig --sign doc


*Firma e cifrado de '''doc'''
You need a passphrase to unlock the private key for
gpg --output doc.gpg --encrypt --sign --recipient arancha@nav.es doc
user: "Javier (Paramo S.L.) <javier@casa.es>"
1024-bit DSA key, ID D58711B7, created 1999-09-24


Unha firma dixital certifica un documento e lle engade unha marca de tempo. Si se modificara o documento, a verificación da firma fallaría. Para a creación e verificación de firmas se utiliza o par público/privado de chaves. Se xenera unha firma coa chave privada do firmante, que pode ser verificada pola chave pública correspondente.l
Enter passphrase:
El documento se comprime antes de ser firmado, y la salida es en formato binario.
Con un documento con firma digital el usuario puede llevar a cabo dos acciones: comprobar sólo la firma o comprobar la firma y recuperar el documento original al mismo tiempo. Para comprobar la firma se usa la opción --verify. Para verificar la firma y extraer el documento se usa la opción --decrypt. El documento con la firma es la entrada, y el documento original recuperado es la salida.


Cando temos un documento con firma dixital podemos levar a cabo dúas accións: únicamente comprobar a firma, ou comprobar a firma e recuperar o documento orixinal. Para comprobar a firma utilízase a opción '''--verify'''. Para verifica-la firma e extraer o documento se usa a opción '''--decrypt'''. O documento coa firma é a entrada, e o documento orixinal recuperado é a salida.

<source lang='text'>
arancha% gpg --output doc --decrypt doc.sig
arancha% gpg --output doc --decrypt doc.sig
gpg: Signature made Fri Sep 24 12:02:38 1999 CDT using DSA key ID D58711B7
gpg: Signature made Fri Sep 24 12:02:38 1999 CDT using DSA key ID D58711B7
gpg: Good signature from "Javier (Paramo S.L.) <javier@casa.es>"
gpg: Good signature from "Javier (Paramo S.L.) <javier@casa.es>"
</source>
== Referencias ==
[http://www.ietf.org/rfc/rfc3280.txt RFC de X.509]


[http://www.madboa.com/geek/openssl/ Referencia de comandos openssl]
=== Servidores públicos de Chaves ===

Lo ideal sería que pudiéramos distribuir nuestra clave entregándosela en persona a nuestros corresponsales. Sin embargo, en la práctica las claves se distribuyen a menudo por correo electrónico o algún otro medio de comunicación electrónica. La distribución por correo electrónico es una buena práctica sólo cuando tengamos unos pocos corresponsales, e incluso si tuviéramos muchos corresponsales, podríamos usar un medio alternativo como puede ser publicar nuestra clave pública en nuestra página en internet. Pero esto es inútil si las personas que necesitan nuestra clave pública no saben dónde encontrar nuestra página.

Para solventar este problema existen los servidores de claves públicas que recolectan y distribuyen las claves públicas. Cuando un servidor recibe una clave pública, bien la añade a la base de datos o bien la fusiona con una copia de la clave. Cuando alguien requiere al servidor una clave pública, éste la busca en la base de datos y, si la encuentra, la envía a quien se la haya solicitado.

Los servidores de claves también son útiles cuando hay muchas personas que firman las claves de otras con frecuencia. Sin un servidor de claves, cuando Arancha firmara la clave de Javier, debería enviar a éste una copia de la clave firmada por ella de manera que Javier pudiera añadir la clave firmada a su anillo de claves, así como distribuirla a todos sus corresponsales. Mediante este proceso Javier y Arancha sirven a la totalidad de la comunidad construyendo lazos en forma de anillos de confianza o lo que es lo mismo, mejorando la seguridad de PGP. De todos modos esto es una molestia si se firman las claves con frecuencia.

El uso de un servidor de claves facilita este proceso. Después de firmar la clave de Javier, Arancha puede enviar la copia firmada por ella al servidor de claves. El servidor de claves añade la firma de Arancha a la copia que ya existente de la clave pública de Javier. Las personas que estén interesadas en actualizar su copia de la clave de Javier consultan al servidor por propia iniciativa para obtener la clave actualizada. Javier no necesita distribuir la clave y puede obtener las firmas en su clave requiriéndolas al servidor.

Se puede enviar una o más claves usando la opción de la línea de órdenes --send-keys. Esta opción toma uno o más especificadores de clave, y envía las claves especificadas al servidor de claves. El servidor al que se envían las claves es especificado con la opción de la línea de orden --keyserver. Paralelamente, la opción --recv-keys se usa para obtener claves desde un servidor de claves, pero la opción --recv-keys requiere el uso de un identificador de clave para poder especificar la clave deseada. En el siguiente ejemplo Javier actualiza su clave pública con nuevas firmas desde el servidor de claves certserver.pgp.com y acto seguido envía su copia de la clave pública de Arancha al mismo servidor de claves para que se actualice con las claves que él mismo pueda haber añadido.

javier:~$ gpg --keyserver certserver.pgp.com
--recv-key D58711B7
gpg: requesting key D58711B7 from certserver.pgp.com ...
gpg: key D58711B7: 1 new signature


[https://jamielinux.com/docs/openssl-certificate-authority Exemplo de Creación de Autoridade de Certificación e autoridade intermedia]
gpg: Total number processed: 1
gpg: new signatures: 1
javier:~$ gpg --keyserver certserver.pgp.com
--send-key arancha@nav.es
gpg: success sending to 'certserver.pgp.com' (status=200)
Existen varios servidores de claves en funcionamiento en todo el mundo. Los servidores más importantes están sincronizados de modo que es posible elegir un servidor de claves cercano a nosotros en Internet y usarlo de forma regular para enviar y recibir claves.

Revisión actual feita o 12 de decembro de 2017 ás 10:40

Introducción

Boxinfo info.png
PKI (Public Key Infrastructure) e un sistema construído sobre protocolos, servizos e estándares que se utilizan para proporcionar autenticación, confidencialidade, integridade, non-repudio e control de acceso a datos dixitais
Cifrado e Firma Dixita
Cifrado e Firma Dixital

Tradicionalmente a seguridade se garantizaba co segredo. O habitual era o uso dunha chave segreda que únicamente coñecían as partes involucradas na comunicación (chave compartida, ou shared key) que se utilizaba para cifrar e descifrar a información (cifrado simétrico). Hoxe en día, cos PIN e as passwords utilizamos tamén unha chave compartida entre nos e o equipo ou servizo ao que accedemos para obter os permisos necesarios. Estas chaves compartidas precisan de completa confianza entre as partes que se comunican, xa que no caso de que a chave quede exposta por calqueira dos dous lados se perdería completamente a seguridade na comunicación.

Hoxe en día, existen alternativas, como as baseadas nas infraestructuras de chave pública ou PKI (Public Key Infraestructure). PKI utiliza criptografía asimétrica de chave pública; con este sistema, as partes involucradas na comunicación necesitan unha parella de chaves de xeito que a información cifrada con unha das chaves únicamente poda ser descifrada pola outra. A chave que se utiliza para cifrar non serve para descifrar. Unha das chaves é para uso único do seu propietario e é mantida en segredo (chave privada, ou Private Key), e a outra se distribúe a todo o mundo que queira manter co usuario unha comunicación confidencial (chave pública ou Public Key).

Deste xeito, si un usuario cifra un documento ou unha parte de él (normalmente un hash obtido a partir do contido do documento) coa chave privada (firma dixital) , os receptores do mesmo poden estar seguros de quen é remitente, xa que únicamente a chave pública do mesmo é capaz de descifrar o documento. Si por outra parte, un usuario cifra un documento coa chave pública, únicamente o propietario da chave privada poderá acceder á información (cifrado). A PKI nos proporciona a posibilidade de firma dixital e de cifrado de información.

A principal debilidade deste sistema atópase na distribución das chaves públicas. Si un usuario malicioso distribúe unha chave pública atribuíndoa a un terceiro (por exemplo, un banco), o resto dos usuarios poden chegar a pensar que están realizando unha comunicación segura co banco, cando en realidade a información está sendo decodificada polo falsificador. Para evitar esto, se utilizan os certificados.

Boxinfo info.png
Os certificados dixitais son documentos que proporcionan información sobre a entidade certificada (como o seu nome, nif... etc) e a súa chave pública. Este documento está a súa vez firmado dixitalmente por un terceiro de confianza (Autoridade de Certificación ou CA) que previamente á firma verifica con seguridade a corrección dos datos e a propiedade do certificado.

As autoridades de certificación firman con varios niveis de seguridade (fortaleza a hora de comprobar a identidade real do autor da solicitude do certificado), que van de o 1 (menos comprobacións) ao 3 (comprobacións máis exhaustivas). E posible conseguir firmas de certificados de nivel 1 por autoridades de certificación recoñecidas como www.startssl.com de modo gratuito. Nun último nivel, depende do propio usuario aceptar ou rexeitar o uso dun certificado a partir da reputación do firmante do mesmo.

E posible tamén que unha autoridade de certificación (CA Raíz) delegue en outras autoridades subordinadas o firmado de algúns tipos de certificados.

Boxinfo info.png
O termo Cadea de Confianza se utiliza para describir as relacións de confianza entre identidades cando se utilizan CA subordinadas ou intermedias. O obxectivo é permitir a emisión de certificados por parte das CA subordinadas. Deste xeito, si establecemos unha relación de confianza cunha CA, confiaremos tamén en todos os certificados nos que esa CA confía.

As compoñentes máis habituais dunha PKI son:

As autoridades de certificación (CA) (raíz e subordinadas): Son as encargadas de emitir e revocar certificados, dando lexitimidade á relación dunha chave pública coa identidade real dun usuario ou servizo. A fortaleza desa relación parte da confianza que o usuario teña na autoridade certificadora.

A autoridade de rexistro (RA): Depende da autoridade de certificación e é a responsable das comprobacións necesarias para verificar a relación entre a chave pública dun certificado e a identidade dos seus titulares.

A autoridade de validación: Mantén o repositorio de listas de revocación de certificados. As listas de revocación de certificados (CRL) almacenan os certificados que por algún motivo deixaron de ser válidos antes da súa data de caducidade. Normalmente proporcionan un servicio de validación on-line a través do protocolo OCSP.

Os usuarios e entidades finais: Os usuarioson aqueles que poseen unha parella de chaves asimétricas e un certificado asociado a súa chave pública. As entidades finais son todos aqueles que aceptan e confían na validez dos certificados dixitais emitidos.

Boxinfo info.png
O certificado electrónico ou dixital é un conxunto de datos que permiten a identificación do titular do certificado, intercambiar información con outras persoas e entidades de maneira segura e firmar electrónicamente os datos que se envían de xeito que se poida comprobar a súa integridade e procedencia

Os certificados dixitais máis utilizados polas PKI seguen o estándar X.509, e deben conter a seguinte información:

  • Número de serie do certificado
  • Nome, Dirección e Domicilio do suscritor.
  • Identificación do suscriptor.
  • Nome,Dirección e Localidade da autoridade de certificación emisora.
  • Data de emisión e Data de caducidade do certificado.
  • Chave pública do suscritor.
  • Métodos para a comprobación da validez do certificado (URL do OCSP)
  • Versión do formato
  • Número de serie otorgado pola entidade emisora
  • Parámetros e identificador do algoritmo de firma

Un exemplo de PKI de uso común en España é o DNIe

Instalación e Configuración

OpenSSL consiste nun conxunto de ferramentas que permiten unha completa xestión de certificados. Para a súa manipulación utilízase a orde openssl, que admite gran cantidade de operacións:

  • ca - Xestión de unha autoridade de certificación (CA).
  • crl - Xestión da lista de revocación de certificados (CLR).
  • crl2pkcs7 - Conversións de CRL a PKCS#7.
  • dgst - Cálculo de resúmenes.
  • passwd - Xeneración de contrasinais.
  • pkcs12 - Xestión de certificados PKCS#12.
  • pkcs7 - Xestión de certificados PKCS#7.
  • req - Xestión de solicitudes de certificados X.509 (Certificate Signing Request, CSR)
  • rsa - Xestión de chaves RSA.

Crearemos unha autoridade de certificación que nos permitirá expedir certificados dixitais para os distintos servizos ofrecidos pola rede, como a Web ou o Correo.

1.- Creación da estructura de ficheiros: Existen varias alternativas, pero a estructura máis común e similar a da figura:

PKI Infraestructure.png


Dentro do directorio PKI gardaremos unha copia de /etc/openssl.conf que persoalizaremos ao noso gusto.


O Directorio CA almacenará a infraestructura que consistirá en:


  • O certificado da autoridade de certificación (CA) que contén a súa chave pública.
  • A carpeta private, que almacenará a chave privada da autoridade de certificación.
  • A carpeta clr, que almacenará a infraestructura de revocación de certificados.
  • A carpeta certs, que almacenará os certificados asinados pola CA e as solicitudes correspondentes.
  • A carpeta newcerts, que almacenará os certificados asinados pola CA, o nome será o número de serie do certificado e extensión .pem
  • O ficheiro 'serial', para levar o control do número de serie para os certificados asinados


A infraestructura de revocación almacenada en clr conterá:


  • O ficheiro 'clrnumber', que levará a conta das revocacións
  • O ficheiro 'index.txt', que almacenará a base de datos dos certificados revocados.
  • O 'certificado da autoridade de revocación'





2.- Persoalización de openssl.conf: Copiamos o ficheiro /etc/ssl/openssl.conf dentro da carpeta PKI, para poder persoalizalo cos datos da autoridade certificadora. Aparte de eses datos, as liñas importantes a modificar son:

 [ CA_default ]
 dir             = /root/PKI/CA          # Where everything  is kept
 certs           = $dir/certs            # Where the issued certs are kept
 crl_dir         = $dir/crl              # Where the issued crl are kept
 database        = $crl_dir/index.txt    # database index file.
 #unique_subject = no                    # Set to 'no' to allow creation of
                                         # several ctificates with same subject.
 new_certs_dir   = $dir/newcerts         # default place for new certs.
 certificate     = $dir/ca.pem           # The CA certificate
 serial          = $dir/serial           # The current serial number
 crlnumber       = $crl_dir/crlnumber    # the current crl number
                                         # must be commented out to leave a V1 CRL
 crl             = $crl_dir/crl.pem      # The current CRL
 private_key     = $dir/private/ca.key   # The private key
 RANDFILE        = $dir/private/.rand    # private random number file

3.- Si queremos dar servicio de validación de certificados mediante OCSP, deberemos engadir a openssl.conf, dentro da sección [ usr_cert ] a liña:

 authorityInfoAccess = OCSP;URI:http://<uri to server>
E unha nova sección:
 [ v3_OCSP ]
 basicConstraints = CA:FALSE
 keyUsage = nonRepudiation, digitalSignature, keyEncipherment
 extendedKeyUsage = OCSPSigning

4.- Inicialización do serial. Poñemos un 01 no ficheiro serial e /crl/crlnumber:

 echo '01' > serial
 echo '01' > crl/crlnumber

5.- Creación das chaves e certificados da CA e da autoridade de validación. Levaremos a cabo as seguintes ordes dende o directorio CA:

 # Chave Privada da CA
 openssl genrsa -des3 -out private/ca.key 4096
 #
 # Certificado da CA
 openssl req -new -x509 -extensions v3_ca -days 3650 -key private/ca.key -out ca.crt
 #
 # Certificado do CRL
 openssl ca -config ../openssl.cnf -gencrl -out crl/crl.pem
 #
 # Chave Privada e solicitude de certificado para o servidor OCSP
 openssl req -config ../openssl.cnf -new -nodes -out ocsp/ocsp.server.com.csr -keyout ocsp/ocsp.server.com.key -extensions v3_OCSP
 # 
 # Firma do certificado OCSP
 openssl ca -config ../openssl.cnf -in ocsp/ocsp.server.com.csr -out ocsp/ocsp.server.com.crt -extensions v3_OCSP

Funcionamento

Cando unha entidade ou individuo precisa identificarse e/ou transmitir información confidencial mediante certificados de chave pública, o primeiro que ten que facer é crear a súa propia chave privada que deberá almacenar en segredo. Paralelamente a esa chave privada, a entidade deberá crear unha solicitude de certificado, que incorporará a chave pública correspondente coa chave privada anteriormente creada. Esa solicitude de certificado se deberá enviar a unha Autoridade de Certificación de confianza, que despois de realizar as oportunas comprobacións de seguridade, enviará un certificado firmado coa súa chave privada.

Deste xeito, a Autoridade de Certificación certifica a correspondencia do certificado emitido coa entidade solicitante.

Boxinfo info.png
As Autoridades de Certificación deben inscribirse nun rexistro de seguridade e cumplir cunha normativa específica como a Directiva 93/1999.

Firma de Certificados

O proceso sería o seguinte:

1.- A Entidade/Usuario crea a súa chave privada e a súa solicitude de certificado

  # Chave privada con cifrado des3 e 4096 bits
  openssl genrsa -des3 -out nome_chave_privada.key 4096
  # Solicitude de certificado
  openssl req -new -key nome_chave_privada.key -out nome_certificado.csr

alternativamente:

  # Crea a chave privada e a solicitude de certificado
  openssl req -newkey rsa:4096 -keyout nome_chave_privada.key -out nome_certificado.csr

Si quixeramos non cifrar a chave privada, non especificaríamos -newkey, poñendo no seu lugar -new -nodes. A solicitude nome_certificado.csr se envía a autoridade de certificación, por correo electrónico, FTP... etc.

Cando creamos a solicitude de firma (CSR), o sistema irá preguntando pola información a incluír no certificado. Pode resultar máis práctico que colla esta información preparando un ficheiro coa información. Vexamos un exemplo:

# Creamos o ficheiro my_site.com.csrconfig
[req]
distinguished_name = req_distinguished_name
req_extensions = v3_req
prompt = no

[req_distinguished_name]
C = ES
ST = Galiza
L = Cangas do Morrazo
O = IES de Rodeira
OU = Departamento de Informática
CN = www.company.com

[v3_req]
#keyUsage = keyEncipherment, dataEncipherment
#extendedKeyUsage = serverAuth
subjectAltName = @alt_names


[alt_names]
DNS.1 = www.company.com
DNS.2 = company.com
DNS.3 = www.company.net 
DNS.4 = company.net

A petición a poderíamos facer así: openssl req -config my_site.com.csrconfig -new -nodes -keyout nome_chave_privada.key -out nome_certificado.csr

2.- A Autoridade de Certificación, previa comprobación acorde ao nivel de seguridade solicitado pola entidade, firma o certificado.

  openssl x509 -req -days 365  -CA ca.pem -CAkey ca.key 
               -CAcreateserial -CAserial ../serial 
               -in nome_certificado.csr -out nome_certificado.pem

ou tamén:

  openssl ca -config ../openssl.cnf -in nome_certificado.csr -out nome_certificado.crt

Podemos especificar -policy seccion para indicar o tipo de información a gardar no certificado segundo o arquivo /etc/ssl/openssl.cnf


Boxinfo info.png
Existen 3 niveis de certificación:
  • DV (Domain Validation) - Se verifica únicamente o dereito a utilizar o dominio/e-mail para o que se expide o certificado.
  • OV (Organization Validation) - Ademáis do anterior, se verifica a información da organización solicitante, que se inclúe no certificado.
  • EV (Extended Validation) - Ademáis de todo o anterior, se levan a cabo unhas verificacións extra, como a existencia legal, física e operativa da entidade solicitante, que a mesma coincide coa información oficial, que a entidade ten o dereito exclusivo de uso para o que se expide o certificado, etc.

3.- A Autoridade de Certificación envía o certificado firmado á Entidade/Usuario.

Lista de Revocación e Servicio de Validación

Os distintos certificados firmados por unha autoridade de certificación poden perder a súa validez en varios casos, como pode ser a perda ou acceso non autorizado á chave privada correspondente. Neses casos, pode solicitarse a revocación do certificado á autoridade de validación. Para facer esto, a autoridade de certificación mantén unha lista de certificados revocados que pode ser consultada solicitando acceso á lista ou mediante un servidor OCSP. OpenSSL proporciona un servidor OCSP que permite a comprobación da validez dos certificados emitidos pola CA. O servidor no porto 8888 se inicia co seguinte comando:

  openssl ocsp -index crl/index.txt -port 8888 -rsigner ocsp/ocsp.iesrodeira.com.crt 
               -rkey ocsp/ocsp.iesrodeira.com.key -CA ca.pem -text -out log/log.txt

Un cliente poderá comprobar a validez do certificado correo.iesrodeira.com.pem co comando:

  openssl ocsp -CAfile ca.pem -issuer ca.pem -cert correo.iesrodeira.com.pem -url http://ocsp.iesrodeira.com:8888 -resp_text

A revocación do certificado correo.iesrodeira.com.pem realízase co seguinte comando:

  openssl ca -config ../openssl.cnf -revoke correo.iesrodeira.com.pem

Creación dunha CA Intermedia

Unha autoridade de certificación intermedia é unha entidade que pode firmar certificados en lugar da CA raíz. A CA raíz firma o certificado da CA intermedia, formando unha cadea de confianza.

O principal propósito das CA intermedias é a seguridade. A chave privada da CA raíz pode gardarse fora de liña (sin conexión á rede) e ser utilizada o menos posible. Si se ve comprometida a chave privada da CA intermedia, a CA raíz pode revocar o certificado e crear un novo.

Para crear unha CA intermedia, deberíamos crear unha estructura PKI completa e indicar como política no openssl.conf "policy_loose", en lugar do máis restrictivo "policy_strict" do CA raíz (O policy indica que información debe presentar o certificado e cómo, para poder ser firmado). A continuación crearemos a parella chave privada-solicitude de certificado:

openssl genrsa -aes256 -out private/intermediate.key 4096

openssl req -config ../openssl.cnf -new -sha256 \
      -key private/intermediate.key.pem \
      -out private/intermediate.csr
Boxinfo info.png
A información suministrada para o CSR debería coincidir coa do CA raíz, salvo o Common Name, que debe ser distinta.

A continuación se "enviaría" o CSR a CA raíz para a súa firma (no noso caso o poñemos na carpeta certs da CA raíz). Unha vez que estamos no CA raíz, firmaríamos o CSR indicando que a firma é para unha CA intermedia mediante o parámetro -extensions v3_intermediate_ca:

# openssl ca -config ../openssl.cnf -extensions v3_intermediate_ca \
      -days 3650 -notext -md sha256 \
      -in certs/intermediate.csr \
      -out certs/intermediate.crt

A continuación podemos comprobar a validez do certificado:

openssl x509 -noout -text -in certs/intermediate.cert.pem

openssl verify -CAfile ca.crt certs/intermediate.crt

Cando unha aplicación (como un navegador web) intente verificar un certificado firmado pola CA intermedia debe verificar o certificado intermedio mediante o certificado da CA raíz. Polo tanto é necesario crear unha cadea de certificados para presentar a aplicación:

cat certs/intermediate.crt  ca.crt > certs/ca-chain.crt

Agora podemos enviar de volta a CA intermedia o certificado e a cadea de certificación....

Boxinfo info.png
É necesario crear unha cadea de certificación para que se inclúa o certificado da CA raíz e non necesitemos que os navegadores ou a aplicación correspondente teñan que instalar dúas CA. Unha opción mellor, en particular nunha intranet, é instalar o certificado do CA raíz en todos os clientes, nese caso únicamente necesitaríamos o certificado da CA intermedia.

Uso na Web

O uso de certificados criptográficos na Web é o xeito máis utilizado de asegurar tanto a identidade dos servidores web, como de garantizar a seguridade da información intercambiada. Cando un cliente web intenta o acceso a un servidor que fai uso de certificados (https, normalmente baixo o porto 443) o servidor responde en primeiro lugar co seu certificado, o cliente intentará comprobar a validez do mesmo utilizando os certificados das autoridades de certificación recoñecidas para verificar a firma, o que garantiza a identidade do servidor.

Si o certificado pasa os requerimentos do cliente, a comunicación se realizará de forma cifrada garantizando a privacidade da comunicación.

Configuración de HTTPS en Apache Web Server

Precisaremos un certificado e a chave privada correspondente. Como o servidor Apache necesita acceder á chave privada, se queremos evitar ter que suministrar a password da mesma en cada inicio, podemos xerar unha chave privada sen protección:

   openssl req -nodes -newkey rsa:4096 -keyout nome_chave_privada.key -out nome_certificado.csr

Tamén é posible eliminar a protección unha vez xerada a chave con:

  openssl rsa -in nome_chave_privada.key -out nome_chave_privada.net.key.insecure

Unha vez firmada a solicitude de certificado .csr pola autoridade de certificación e obtido o certificado (.pem ou .crt), necesitamos ter activo o módulo ssl:

  a2enmod ssl

Unha configuración típica dun sitio virtual baixo SSL sería, copiando previamente a nosa chave privada server.key e o certificado firmado server.crt en /etc/ssl/certs/:

NameVirtualHost a.b.c.d:80
<VirtualHost a.b.c.d:80>
	ServerAdmin webmaster@meudominio.org
	DocumentRoot /sitios/sitioSSL
	ServerName ssl.midominio.org
	ServerAlias midominio.org
	Redirect 301 / https://ssl.midominio.org/
	CustomLog /var/log/apache2/nossl_access_log combined
	Errorlog /var/log/apache2/nossl_error_log
</VirtualHost>
NameVirtualHost a.b.c.d:443
<VirtualHost a.b.c.d:443>
	ServerAdmin webmaster@midominio.org
	DocumentRoot /sitios/sitioSSL
	ServerName ssl.midominio.org
	ScriptAlias /cgi-bin/ /sitios/sitioSSL/cgi-bin/
	SSLEngine on
	SSLCertificateFile /etc/ssl/certs/server.crt
	SSLCertificateKeyFile /etc/ssl/certs/server.key
	SetEnvIf User-Agent ".*MSIE.*" nokeepalive ssl-unclean-shutdown
	CustomLog /var/log/apache2/ssl_request_log \
	"%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b"
	CustomLog /var/log/apache2/ssl_access_log combined
	Errorlog /var/log/apache2/ssl_error_log
</VirtualHost>

O primeiro VirtualHost non é máis que unha redirección de maneira que os accesos baixo http se redirixan de xeito automático ao VirtualHost baixo https.

E necesario indicar a IP (a.b.c.d) porque normalmente únicamente se soporta un único sitio virtual baixo SSL por cada IP do servidor, xa que é necesario o certificado do sitio para saber o sitio solicitado. Sen embargo, as últimas versións dos navegadores e de Apache soportan a extensión TLS Server Name Indication (SNI) que permite o uso de varios sitios virtuais distintos baxio https. Necesitaremos:

  • Editar /etc/apache2/ports.conf para indicar:
<IfModule mod_ssl.c>
    NameVirtualHost *:443
    Listen 443
</IfModule>

<IfModule mod_gnutls.c>
    NameVirtualHost *:443
    Listen 443
</IfModule>
  • Debemos asegurarnos que no VirtualHost por defecto e nos VirtualHosts baixo SSL está especificado <VirtualHost *:443>.

Si o cliente (navegador) non soporta as extensións SNI, podemos negarlle o acceso descomentando a liña

 SSLStrictSNIVHostCheck On

ao final de /etc/apache2/mods-enabled/ssl.conf.

Certificados de Cliente

Os Certificados de Cliente permiten a identificación dun cliente por parte dun servidor web, de xeito que se lle podan otorgar privilexios de acceso especiais. Cando o sitio web precisa identificar ao cliente, lle envía unha solicitude de certificado. O cliente enviará o certificado correspondente ao sitio, e o servidor web, previa comprobación do mesmo, garantizará ou denegará o acceso.

Para configurar este comportamento no Apache, necesitaremos configurar un sitio baixo https, e indicarlle que imos requerir un certificado do cliente mediante a directiva SSLVerifyClient require. O servidor, ao recibir o certificado, realizará unha verificación da cadea de confianza ata a profundidade indicada pola directiva SSLVerifyDepth.

Con esta configuración, a Apache lle bastaría calqueira certificado válido, polo que é necesario configurar un filtro de certificados que descarte os que non sirvan a partir da súa informació, do seguinte xeito:

SSLRequire %{SSL_CLIENT_S_DN_O}  eq "IES de Rodeira" and  %{SSL_CLIENT_S_DN_OU} in {"Departamento de Informatica"}

Unha posible configuración para unha carpeta dun sitio Web sería:

<VirtualHost *:443>
 ServerName servidor.iesrodeira.com
 DocumentRoot /var/www/servidor

 SSLEngine on
 SSLCertificateFile    /etc/ssl/private/msdn.iesrodeira.com.crt
 SSLCertificateKeyFile /etc/ssl/private/msdn.iesrodeira.com.key
 SSLCACertificateFile  /etc/ssl/certs/myca.crt

 <FilesMatch "\.(cgi|shtml|phtml|php)$">
     SSLOptions +StdEnvVars
 </FilesMatch>
 BrowserMatch "MSIE [2-6]" \
        nokeepalive ssl-unclean-shutdown \
        downgrade-1.0 force-response-1.0
 # MSIE 7 and newer should be able to use keepalive
 BrowserMatch "MSIE [17-9]" ssl-unclean-shutdown
 
 <Directory /var/www/servidor/restricted>
 # Restinxido mediante certificado de cliente
    SSLRequireSSL
    SSLVerifyClient require
    SSLVerifyDepth  2
    SSLRequire %{SSL_CLIENT_S_DN_O}  eq "IES de Rodeira" and  %{SSL_CLIENT_S_DN_OU} in {"Departamento de Informatica"}
 </Directory>
</VirtualHost>

Existen múltiples directivas de xestión de certificados que permiten o uso de listas de revocación ou servidores OCSP, podes consultalas na documentación de Apache

O certificado de cliente permite o acceso únicamente aos navegadores que dispoñan dun certificado válido admitido polo servidor, pero non verifica a identidade da persoa utilizando o mesmo. Para garantizar a identidade da persoa, se debería engadir un sistema de autenticación do xeito indicado neste documento.

Nos clientes web, será necesario instalar os certificados de cliente para enviar. O firefox/mozilla acepta os certificados en formato pkcs12, que inclúen tanto o certificado como a súa chave privada, polo que será necesario exportar o certificado firmado a este formato e importalo logo ao navegador, xunto co certificado da autoridade de certificación.

Boxinfo info.png
Firefox/Iceweasel únicamente acepta certificados coa extensión .pkcs12
openssl pkcs12 -export -clcerts -inkey chaveprivada.key -in meucert.crt -out meucert.pkcs12
Boxinfo info.png
Para importar o certificado da autoridade de certificación, bastará con facelo dispoñible nun enlace a través da web. O navegador recoñecerá automáticamente que é un certificado e procederá a súa instalación

Internet Explorer traballa dun modo lixeiramente distinto. Os certificados deben estar en formato DER, Polo que necesitaremos convertir a ese formato tanto o noso certificado como o certificado da autoridade de certificación:

  openssl x509 -inform PEM -in meusitio.CRT -outform DER -out meusitio.CRT.der
  openssl x509 -inform PEM -in RodeiraCA.CRT -outform DER -out RodeiraCA.CRT.der

Uso no E-mail

Os certificados poden ser utilizados no correo electrónico tanto para a realización de firmas (asegurar autoría e integridade), como para o cifrado do seu contido e asegurar así a privacidade. A configuración ven determiñada polo cliente de correo electrónico, aínda que é similar en todos eles.

Normalmente se deben importar (no sistema ou no cliente de correo, según a integración do cliente) o certificado da autoridade de certificación como autoridade de certificación, e os certificados persoais a utilizar na conta de correo en formato pkcs12. Unha vez incorporados os certificados, nas opcións de seguridade da conta de correo, se indicarán os certificados a utilizar para o cifrado e firma S/MIME.

O funcionamento é o seguinte:

Desexamos enviar un correo firmado e cifrado a outro usuario
A firma se realizará co noso certificado, pero para enviar o correo cifrado precisamos ter instalado o certificado de usuario do destiñatario (a súa chave pública). O destiñatario deberá ter o noso certificado para comprobar a firma, e descifrará o correo facendo uso do seu propio certificado.
Recibimos un correo firmado e cifrado
Para verificar a firma necesitamos o certificado do firmante (a súa chave pública), e para descifralo bastará co noso propio certificado.

Cifrado e Firmado de documentos

Outro uso dos certificados é a firma e cifrado de documentos. En realidade é o mesmo procedemento que se realiza na firma e cifrado de correos electrónicos.

Por exemplo, para cifrar pequenas cantidades de texto mediante o algoritmo RSA (axeitado para información de pouca lonxitude) e descrifralo posteriormente poderíamos facer o seguinte:

#Obtemos a chave pública correspondente a nosa chave privada
openssl rsa -in chaveprivada.key -out chavepublica.pkey -outform PEM -pubout

#Cifrado
openssl rsautl -inkey chavepublica.pkey -pubin -encrypt -in ficheiro.txt  > ficheiro.txt.cifrado

#Descifrado
openssl rsautl -inkey chaveprivada.key -decrypt -in ficheiro.txt.cifrado


De xeito similar, para firmar un documento, necesitaremos tamén a chave pública correspondente

#Firma
openssl dgst -sha1 -sign chaveprivada.key file.txt > file.txt.firma

#Comprobación da firma
openssl dgst -sha1 -verify chavepublica.pkey -signature file.txt.firma file.txt

O algoritmo RSA non é axeitado para cifrar grandes documentos, polo que unha solución habitual é utilizar unha chave simétrica para o cifrado, e cifrar mediante RSA a chave de cifrado. Deste xeito, a outra parte poderá descifrar a chave e a continuación o documento.

#Creación da chave simétrica de cifrado
MYKEY="" ; for((a=1;a<=100;a++)) do MYKEY=$MYKEY$RANDOM ; done ; echo $MYKEY > file.txt.symkey ; MYKEY="" 
#Cifrado do ficheiro coa chave simétrica
openssl des3 -e -kfile file.txt.symkey -in file.txt -out file.txt.symenc 
#Ciframos a chave simétrica
openssl rsautl -inkey chavepublica.pkey -pubin -encrypt -in file.txt.symkey  > symkey.cifrada

# A outra parte recibiría  symkey.cifrada e  file.txt.symenc

#Descifrado da chave simétrica
openssl rsautl -inkey chaveprivada.key -decrypt -in symkey.cifrada > file.txt.symkey
#Descifrado do ficheiro mediante a chave simétrica
openssl des3 -d -kfile file.txt.symkey -in file.txt.symenc

O DNIe e as tarxetas criptográficas

O punto débil do cifrado de chave pública está na distribución dos certificados e no almacenamento de chave pública. Si alguén consigue acceso a unha chave privada, poderá suplantar ao seu propietario. Ademáis, si necesitamos firmar documentos e proporcionar a nosa identidade dende distintos equipamentos, necesitaremos portar os nosos certificados, co conseguinte problema de seguridade.

Unha solución a este problema é o uso de tarxetas criptográficas. As tarxetas criptográficas ou SmartCards son pequenas pezas de plástico, normalmente do tamano dunha tarxeta de crédito que inclúen unha memoria e un procesador con capacidades criptográficas. Na súa memoria se poden almacenar documentos que únicamente serán accesibles para o seu microprocesador, co que é un bo xeito de transportar e utilizar certificados e chaves privadas. Para protexer o acceso ao microprocesador e as súas funcións empregase normalmente un PIN (Personal Identification Number).

Se poden establecer varias clasificacións de tipos de SmartCards:

Con e sin contacto
As tarxetas de contacto precisan dun elemento que suministre enerxía eléctrica ao microprocesador, e polo tanto teñen que insertarse nun dispositivo, mentras que as tarxetas sin contacto funcionan mediante radio frecuencia (RFID), e obteñen a enerxía necesaria da propia conexión de radio. Tamén existen tarxetas mixtas que incorporan os dous métodos. As tarxetas con contacto utilízanse normalmente como identificación, mentras que as tarxetas sin contacto se empregan para funcións como a apertura de portas.
De Memoria e con Microprocesador
As tarxetas de memoria teñen unha EEPROM e un microcontrolador que permite o acceso a ela. Os datos se bloquean mediante un PIN, pero non poden realizar transformacións criptográficas. Utilízanse para funcións como monedeiros electrónicos ou crédito telefónico. As tarxetas con microprocesador son como pequenos ordenadores con RAM, ROM e EEPROM, cun pequeno sistema operativo en ROM que manexará o acceso aos ficheiros almacenados na EEPROM e executará funcións na RAM. Este tipo de tarxetas poden realizar funcións criptográficas polo que habitualmente se utilizan para identificación.

A maior parte das SmartCards teñen sistemas operativos propios o que fai complexo a creación de aplicacións que soporten múltiples tipos de tarxetas e que den acceso a máis funcións das ofrecidas nos estándares ISO7816. Os sistemas máis empregados hoxe en día son JavaCard, desenvolto por Sun (hoxe Oracle), MULTOS deseñado para alta seguridade ou a versión de Microsoft, SmartCard for Windows.

Os usuarios poden interactuar coas SmartCards a través de diversos API. Os máis comúns son:

CT-API
Este API proporciona funcións xenéricas que permiten a comunicación con tarxetas de memoria e de microprocesador, cumplindo os estándares ISO7816.
PC/SC (Personal Computer/Smart Card)
Son un conxunto de especificacións desenvoltas por polo PC/SC Workgroup. Existen implementacións de este API baixo Windows, Linux e OS/X.
OpenCard
E un API basado en Java para o acceso a SmartCards.

Baixo Linux o mellor soportado é PC/SC, mediante pcscd. En Debian deberemos instalar os paquetes pcscd e pcsc-tools. As operacións coas tarxetas realízanse co software opensc. E aconsellable ter instalado algún medio gráfico de solicitude de PIN como pinentry-gtk2.

A configuración de smartcards realízase habitualmente co software propietario que suministra o fabricante, polo que sería unha boa idea mercar tarxetas soportadas por opensc, de xeito que funcione correctamente baixo Linux. Si configuramos unha tarxeta cun software, únicamente será posible modificar a configuración con ese mesmo software.

En España, a Dirección Xerál da Policía implementou un sistema de identificación basado en certificados de chave pública e o uso de SmartCards denominado DNIe ou DNI Electrónico. Mediante esta tarxeta, e previa solicitude da creación dos certificados, é posible identificarse en numerosas web e realizar firmas criptográficas de documentos con unha completa validez legal.

O DNIe español realizou un módulo en código pechado para o seu uso con opensc, ao que opensc non da soporte. Recentemente liberouse o código e lanzouse o proxecto opendnie. Deste xeito existen dúas maneiras de traballar co DNIe: a través do oficial, da Dirección General de la policía y de la Guardia Civil (DGP) basada en OpenSC-0.11.8 e xa non mantida, e mediante a implementación libre OpenDNIe, que está pendente da súa integración na rama principal de OpenSC. Recoméndase o uso de OpenDNIe para o uso do DNIe español, podes ver o seu código fonte na Páxina do Proxecto.

Podes consultar a Guía de Configuración do DNIe en Linux para máis información.

GnuPGP (PGP)

PGP (Pretty Good Privacy) é un sistema de cifrado de chave asimétrica ampliamente empregado para o cifrado e firma de documentos, especialmente correo electrónico. As operacións máis importantes son:

  • Creación da parella de chaves
   gpg --gen-key

Esta operación creará unha parella de chaves asimétricas (pública e privada), almacenado por defecto a información GPG relativa ao usuario na carpeta .gnupg dentro do home de usuario.

  • Listado de chaves
gpg --list-keys

Esta operación listará o conxunto de chaves públicas GPG que temos almacenadas e nas que confiamos.

  • Exportación da chave pública
gpg --armor --export usuario@dominio > mypublickey.pkey

Esta operación exportará unha chave pública a un ficheiro, de xeito que podamos distribuíla.

  • Importación dunha chave pública para o seu uso automático
gpg --import ficheiro.pkey

Esta operación importará unha chave pública ao noso anel de confianza

Existen varios entornos gráficos de usuario, como seahorse útiles para xestionar as chaves GPG.

O problema principal da criptografía asimétrica é determiñar ata que punto nos podemos fiar das chaves públicas que recopilamos no noso sistema. Para solucionar este problema, se recurre normalmente a cadeas de confianza, nas que confiaremos nos certificados nos que confía alguén da nosa confianza. Para indicar confianza nunha chave se firma coa chave privada, deste xeito si unha chave pública está firmada por unha persoa na que confiamos, podemos fiarnos relativamente que a chave é lexítima.

A distribución de chaves públicas pode facerse por multitude de medios, pero o máis sinxelo é o uso de servidores de chaves públicas como este.

En este documento atoparás unha descripción máis detallada de GPG.


Cifrado e Firma de E-mail

GPGID.png

Para firmar os correos electrónicos bastará con indicar na configuración de seguridade o ID GPG a utilizar. O ID o podemos obter como indica a imaxe. Si queremos cifrar o correo, precisaremos a chave pública do destiñatario. No momento do envío do correo indicamos si queremos cifrar, firmar ou as dúas cousas.

Cifrado e Firma de Documentos

  • Cifrado de doc
 gpg --output doc.gpg --encrypt --recipient arancha@nav.es doc
  • Descifrado de doc.gpg
 gpg --output doc --decrypt doc.gpg
  • Cifrado simétrico de doc
 gpg --output doc.gpg --symmetric doc
  • Descifrado
 gpg --output doc -d doc.gpg 
  ou, simplemente
 gpg doc.gpg
  • Firma de doc
 gpg --output doc.sig --sign doc
  • Firma e cifrado de doc
 gpg --output doc.gpg --encrypt --sign --recipient arancha@nav.es doc

Unha firma dixital certifica un documento e lle engade unha marca de tempo. Si se modificara o documento, a verificación da firma fallaría. Para a creación e verificación de firmas se utiliza o par público/privado de chaves. Se xenera unha firma coa chave privada do firmante, que pode ser verificada pola chave pública correspondente.l

Cando temos un documento con firma dixital podemos levar a cabo dúas accións: únicamente comprobar a firma, ou comprobar a firma e recuperar o documento orixinal. Para comprobar a firma utilízase a opción --verify. Para verifica-la firma e extraer o documento se usa a opción --decrypt. O documento coa firma é a entrada, e o documento orixinal recuperado é a salida.

arancha% gpg --output doc --decrypt doc.sig
gpg: Signature made Fri Sep  24 12:02:38 1999 CDT using DSA key ID D58711B7
gpg: Good signature from "Javier (Paramo S.L.) <javier@casa.es>"

Referencias

RFC de X.509

Referencia de comandos openssl

Exemplo de Creación de Autoridade de Certificación e autoridade intermedia