Creación dunha Infraestructura de chave pública (PKI)

Introducción

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 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.

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.

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.

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:

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
 #
 # 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.

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.

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

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

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.

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.

HTTPS

// 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 <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.pem 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>

Certificados de Cliente

openssl pkcs12 -export -clcerts -inkey amiñachave.key -in meucert.crt -out meucert.pkcs12

A EXTENSION TEN QUE SER nome.pkcs12 OBLIGATORIAMENTE PARA ICEWEASEL

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

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.

http://www.garex.net/garexCA.CRT 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. :))

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:

1. openssl x509 -inform PEM -in garex.CRT -outform DER -out garex.CRT.der
2. openssl x509 -inform PEM -in garexCA.CRT -outform DER -out garexCA.CRT.der

Apache

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:

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.

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:

... <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!!!

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.

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>":

   AllowOverride AuthConfig
   Order deny,allow
   Allow from all

   AuthType Basic
   AuthName "Authentication required"
   AuthUserFile /opt/apache-1.3.26-ssl/etc/passwd
   AuthGroupFile /opt/apache-1.3.26-ssl/etc/group
   require valid-user
   require group support
   Satisfy all

Last but not least we create a passwd file and a group file:

1. mkdir /opt/apache-1.3.26-ssl/etc
2. /opt/apache-1.3.26-ssl/bin/htpasswd -c \

 /opt/apache-1.3.26-ssl/etc/passwd garex

The group file looks like this:

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.

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

• Listado de chaves

gpg --list-keys

• Exportación da chave pública

gpg --armor --export usuario@dominio > mypublickey.pkey

• Importación dunha chave pública para o seu uso automático

gpg --import ficheiro.pkey

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.

Servidores públicos de Chaves

sks