PKI

CAPITULO 1: CONCEPTOS BASICOS

1.1. INTRODUCCION
La fortaleza de la criptografa de clave secreta moderna se deriva de mantener secretas las
claves, no los algoritmos. Esta caracterstica es ms una imposicin que una eleccin. Los
algoritmos deben ser pblicos para soportar un anlisis tcnico profundo. En ausencia de este
escrutinio detallado, el algoritmo puede ocultar sus debilidades y, adems, tarde o temprano
alguien, mediante un proceso de ingeniera inversa, podr averiguar el algoritmo.
Las claves secretas deben distribuirse entre las partes que se desean comunicar y su
transporte requiere el establecimiento de canales seguros. El concepto de criptografa de clave
pblica ofrece un mecanismo flexible y escalable que permite resolver el problema de la
distribucin de claves secretas.
En la criptografa de clave pblica, cada usuario dispone de dos claves:

la clave pblica y

la clave privada.
La clave privada slo debe ser conocida por el usuario que la gener, mientras que la clave
pblica se distribuye libremente.
Una de las premisas es que sea computacionalmente inviable calcular la clave privada a partir
de la pblica. Adems, la criptografa de clave pblica ofrece varios servicios adicionales:
firmas digitales, no-repudio, integridad de los datos,. . . .
El requisito de la distribucin libre de la clave pblica tiene un coste que consiste en confiar en
que la clave pblica se ha asociado con su legtimo usuario. Una solucin contrastada consiste
en el uso de los certificados y, adicionalmente, de toda la infraestructura que los soporta.
"Una Infraestructura de Clave Pblica (Public Key Infrastructure, PKI) es una
infraestructura que proporciona servicios de seguridad a las aplicaciones
informticas y sus usuarios mediante el uso de tcnicas de clave pblica de un modo
transparente al usuario".
Entre los beneficios ms destacados que proporciona una PKI se incluyen el ahorro de costes y
la interoperabilidad de soluciones.
Este estudio pretende analizar los distintos aspectos que se deben considerar al implantar un
sistema de certificados (PKI). Para ello nos basaremos en los pasos que una empresa u
organizacin debe dar para implantar una PKI.
Al igual que cualquier otro proyecto de tecnologas de la informacin (IT) llevado a cabo por
una empresa u organizacin, la implantacin de un sistema de certificados puede subdividirse
en 4 etapas claves:

Evaluacin

Diseo

Despliegue

Mantenimiento
Debe quedar claro que el objetivo del proyecto no es implantar un sistema de certificados en
una organizacin, sino analizar los distintos puntos que se deben considerar al implantar una
PKI.
Las 4 etapas claves de un proyecto de IT sirven simplemente como un armazn en el cual se
encajan los distintos aspectos a estudiar. Puesto que se trata de un proyecto terico, no
centrado en ninguna organizacin o empresa real, se darn ideas y pautas generales.

Debido a todo lo dicho anteriormente, el actual estudio seguir la siguiente estructura:

En el primer captulo, tras una breve introduccin histrica, se explicarn los

diferentes componentes que constituyen una PKI y las funciones que realizan.

El segundo captulo se ocupa de la fase de evaluacin. Se estudiarn los beneficios

que produce una PKI y las motivaciones que inducen a una organizacin a su
implantacin, se comentar la utilidad de los documentos CP y CPS, se presentar
un estudio de los costes que se derivan de la implantacin y posterior
mantenimiento de la PKI, se presentarn criterios para decidir si se externaliza o no
el servicio y la eleccin del proveedor o fabricante.

El tercer captulo trata del diseo tecnolgico y despliegue de la solucin PKI. Se

considerarn cuestiones relativas a las diferentes arquitecturas PKI existentes, el
diseo de certificados, los parmetros que se deben configurar en un servidor,
cuestiones relativas a interoperabilidad, as como cuestiones relativas a su
integracin con el entorno IT existente y el desarrollo de aplicaciones o mdulos PKI
a medida.

El captulo dedicado al mantenimiento detallar todas las operaciones que una PKI
completa debe llevar a cabo de una forma rutinaria. Estas actividades constituyen lo
que se denomina ciclo de vida de certificados y claves. Adems se describirn los
protocolos que se han definido para llevar a cabo dichas operaciones. Por ltimo,
este captulo incluir algunas consideraciones sobre temas como soporte a usuarios,
formacin de usuarios y administradores, backups y prevencin de desastres.

El ltimo captulo analizar un ejemplo concreto de PKI: el Documento Nacional de

Identidad electrnico (DNI-e). Adems, examinar las tendencias actuales en el
desarrollo de las PKIs y realizar algunas consideraciones sobre su viabilidad futura.
1.2. LA HISTORIA DE LAS PKI
Oficialmente la "Criptografa de Clave Pblica" ("Public Key Cryptography", PKC) comienza en
1976 cuando Whitfield Diffie y Martin E. Hellman, de la Universidad de Stanford, publican un
artculo visionario titulado "New Directions in Cryptography"1. Paralelamente, pero de forma
independiente, Ralph C. Merkle propuso ideas similares. Sin embargo, hay una cierta
controversia.
De acuerdo con documentos publicados por el gobierno britnico en 1997, la PKC fue
originariamente inventada en el GCHQ (Government Communications Headquarters). El GCHQ
es la organizacin secreta britnica que se cre durante la Segunda Guerra Mundial y que,
entre otros xitos, consigui descifrar el sistema ENIGMA usado por los nazis. Brevemente, Jim
Ellis tuvo la idea de la criptografa de clave pblica en 1970. En 1973 Clifford Cocks invent
una variante de RSA y unos meses ms tarde Malcolm Williamson invent un sistema similar al
intercambio de claves de Diffie-Hellman. Sin embargo, los documentos publicados por el
gobierno britnico no muestran ninguna referencia a las firmas digitales.2
La historia no acaba ah, pues parece que la estadounidense National Security Agency (NSA)
tambin haba hecho el mismo descubrimiento unos aos antes.
Volviendo a la historia oficial, Diffie y Hellman vaticinan en su artculo que est a punto de
producirse una revolucin en el campo de la criptografa debido a que el desarrollo de
hardware barato la libera de costosos dispositivos mecnicos y, a su vez, permite su aplicacin
en simples terminales de ordenadores o cajeros automticos. En dicho artculo tambin
proponen un sistema que minimiza la necesidad de canales seguros para la distribucin de
claves y prevn la posibilidad del equivalente a una firma escrita. Durante milenios se haba
admitido unnimemente que para que dos partes establecieran una comunicacin segura
deban previamente intercambiar una clave secreta de algn tipo; el artculo de Diffie y
Hellman acaba con esa creencia.

"Nuevas Direcciones en Criptografa"

Si se desea encontrar una explicacin algo ms detallada sobre el descubrimiento de la criptografa de
clave pblica por parte de los servicios secretos britnicos puede ser til consultar el enlace http:
//cryptome. org/ukpk - alt.htm.
2

El algoritmo de intercambio de claves propuesto por Diffie, Hellman y Merkle proporcionaba un

mecanismo seguro para la distribucin de claves, pero no implementaba firmas digitales.
Tras leer el artculo de Diffie y Hellman, tres investigadores del MIT, Ronald Rivest, Adi Shamir
y Leonard Adleman (RSA), comenzaron la bsqueda de una funcin matemtica que
implementara un sistema PKC completo. Finalmente descubrieron un algoritmo elegante
basado en la multiplicacin de dos nmeros primos que encajaba exactamente en los
requisitos para implementar un sistema PKC. Acababa de nacer el algoritmo RSA. RSA es el
sistema de clave pblica ms ampliamente usado. Puede usarse para proporcionar
confidencialidad y firmas digitales y su seguridad se basa en la dificultad de factorizar enteros.
En 1978, Loren M. Kohnfelder en su tesis de licenciatura en el MIT titulada "Towards a practical
Public Key Cryptosystem"3 dirigida por Len Adleman propone el concepto de certificado para
simplificar la implementacin de RSA y soslayar algunos problemas relacionados. A partir de
ese momento, los certificados y los sistemas de clave pblica se desarrollaron en paralelo.
Otro hito histrico destacado tuvo lugar en 1985 cuando Victor S. Miller y Neal Koblitz sugieren
el uso de las curvas elpticas en la PKC.
Buena parte del inters en el desarrollo de las PKIs es el resultado del crecimiento de Internet.
Concretamente, el aumento del comercio electrnico ha provocado una toma de conciencia
relativa a las cuestiones de seguridad lo que, a su vez, ha incrementado el esfuerzo dedicado a
estandarizar todos los aspectos de las PKIs.
Estndares y especificaciones PKI
En 1988 se publica la primera versin de la recomendacin X.509 que proporciona un formato
normalizado para certificados y CRLs (Certificate Revocation List). Peridicamente han ido
apareciendo nuevas versiones del estndar para incorporar nuevas funcionalidades.
La IETF, responsable de los estndares que gobiernan la operacin de Internet, ha escrito una
serie de RFCs para el uso de una PKI en Internet basada en el estndar X.509. Tal conjunto de
documentos se engloban bajo el nombre de PKIX. La misma IETF ha propuesto otro esquema
de certificado ms simple que el X.509 denominado SPKI ("Simple Public Key Infrastructure"),
pero que no ha tenido una amplio seguimiento.
El grupo ISO TC68 ha adaptado los certificados X.509 al sector financiero.
ANSI X9F ha publicado un significativo nmero de estndares tambin relativos al sector
bancario.
Otras comunidades, si bien no definen estndares, especifican la implementacin de productos
a un cierto nivel, como por ejemplo:

el "U.S. Federal Public-Key Infrastrucute" o

el "Government of Canada Public-Key Infrastructure".

Cabe decir que en el campo de los estndares se ha progresado significativamente y se ha
alcanzado una madurez que permite una slida implementacin, despliegue e interoperacin.
Evolucin comercial de las PKIs
La evolucin comercial de las PKIs es algo ms irregular. A la publicacin del artculo de Diffie
y Hellman, le sigui un periodo de gran expectacin que provoc una sobrevaloracin de lo que
la nueva tecnologa poda aportar. Esta sobrevaloracin contribuy a un posterior desencanto
auspiciado tambin por el coste de implementacin de la tecnologa, la falta de personal
especializado y la incomprensin de los gestores. La consecuencia fue el abandono de muchos
3

"Hacia un Criptosistema de Clave Pblica prctico"

3

proyectos de implantacin de PKIs. Este perodo de crisis se refleja en la desaparicin de la

empresa Baltimore Technologies que pocos aos antes haba visto como su cotizacin en bolsa
se disparaba debido a que su rea de negocio en el campo de los certificados digitales era vital
para el comercio electrnico. A pesar de todo, algunas organizaciones persistieron en el uso de
la tecnologa hasta que consiguieron que cumpliera sus requisitos.
Poco a poco la tecnologa se ha ido asentando y su implementacin se ha ido simplificando de
modo que ha recuperado la confianza de la mayora.
Crticas a PKI
Sin embargo, las PKIs tambin tienen sus detractores y entre ellos destaca Bruce Schneier. En
un trabajo escrito junto con Carl Ellison titulado "Ten risks of PKI: What youre not been told
about Public Key Infrastructure"4 critica la tecnologa y refuta el argumento de la necesidad de
las PKIs para el florecimiento del comercio electrnico.
Sin embargo, a medida que mejora la comprensin de la tecnologa se van rebatiendo los
puntos de vista de Bruce Schneier. Hay un cierto consenso en la actualidad sobre el hecho de
que los beneficios de una PKI compensan el coste de su mantenimiento y tambin sobre el
hecho de que las PKIs abren un horizonte de nuevas posibilidades de negocio que antes eran
inviables por riesgos de seguridad, legislacin, etc.
1.3. CERTIFICADOS
En pocas palabras:
"Los certificados de clave pblica son estructuras de datos firmadas que se usan
para asociar el nombre de una entidad (y otros atributos adicionales relacionados
con la entidad) con la correspondiente clave pblica."
A lo largo del tiempo se han estandarizado diferentes formatos de certificados de clave
pblica:

Certificados de clave pblica X.509

Certificados SPKI (Simple Public Key Infrastructure)

Certificados PGP (Pretty Good Privacy)

Certificados CV (Card Verifiable)

Entre todos ellos, los certificados de clave pblica X.509 son los que han sido ms
ampliamente adoptados. Estos certificados han ido evolucionando con el tiempo originando
diferentes versiones. Los certificados de clave pblica de la versin 1 son un subconjunto de
los certificados de la versin 2 y stos a su vez son un subconjunto de los de la versin 3.
Debido a que la versin 3 incluye numerosas extensiones opcionales, estos certificados se han
instanciado a su vez para adaptarse a aplicaciones especficas dando lugar, por ejemplo, a los
certificados PKIX que se usan en Internet y a los certificados SET usados para pagos con
tarjetas de crdito. La prctica totalidad de las PKIs usa certificados de clave pblica X.509 v3
(versin 3) y es por ello que este trabajo se centra en dicho tipo de certificados.
Originalmente el documento X.509 especificaba los mecanismos de autenticacin para el
directorio X.500. El directorio X.500 requera mecanismos fuertes de autenticacin para
asegurar que slo usuarios autorizados podan modificar o acceder a sus datos. La primera
versin del documento publicada en 1988 contena la versin 1 de los certificados X.509. Con
el tiempo, el objeto de atencin del documento X.509 dej de ser el directorio (que nunca ha
llegado a implementarse) para pasar a ser una PKI de propsito general.
La versin 1 de los certificados presentaba problemas relativos a la renovacin de certificados
de CAs y una notable inflexibilidad para soportar atributos adicionales, por lo que en 1993
apareci la versin 2 que agregaba dos campos al formato antiguo. Los intentos de usar este
4 "Diez riesgos de PKI: Lo que no te han dicho acerca de la infraestructura de clave pblica"

nuevo formato en una PKI para el "Internet Privacy Enhanced Mail" resultaron infructuosos y
revelaron deficiencias.
En respuesta a los nuevos requisitos, la ISO junto con IEC e ITU, desarrollaron la versin 3 de
los certificados X.509 en 1997. Esta versin incluye el poderoso mecanismo de las extensiones
que, de modo flexible, permite incluir en los certificados informacin no soportada en los
campos bsicos. Las nuevas versiones del documento X.509 simplemente han aadido nuevas
extensiones y han especificado los "Certificados de Atributos" sobre los que se construye las
"Privilege Management Infrastructures" (PMI), pero no han alterado las ideas de la versin 3.
La ltima versin del documento X.509 es de Noviembre del 2008.
La IETF ("Internet Engineering Task Force") ha adaptado los certificados X.509 v3 para su uso
en Internet promoviendo el uso de algunas extensiones y desaconsejando el uso de otras,
entre ellas las que dieron lugar a los certificados X.509 v2. La IETF ha generado las
recomendaciones PKIX para adaptar una PKI al entorno de Internet. De hecho, aunque los
estndares PKIX estn dirigidos principalmente a la comunidad de Internet, algunas de sus
recomendaciones pueden aplicarse al entorno de la empresa y mantener de este modo la
consistencia.
1.3.1. Estructura y semntica de los certificados
La figura 1.1 representa el contenido de un certificado.

A continuacin se detallan los diferentes campos que constituyen los certificados X.509 v3.
Version. Este campo indica la versin a la cual se ajusta el formato del certificado. Puede
referirse a la:

versin 1 (valor 0),

versin 2 (valor 1), o

versin 3 (valor 2).

Serial Number. Es un entero asignado por la CA al certificado en el momento de su emisin y
debe ser nico dentro del mbito de cada CA.
Signature Algorithm. Este campo identifica el algoritmo criptogrfico usado por la autoridad
emisora al firmar el certificado. Para ello especifica el OID ("Object Identifier") del algoritmo y
sus parmetros asociados. Uno de los ms usados hasta la fecha es SHA-1 con cifrado RSA.
Este campo aparece dos veces en el certificado (dentro y fuera de la porcin firmada). Los
valores de los dos campos deben coincidir.

Issuer Name. Es el "Nombre Distinguido" ("Distinguished Name", DN) de la CA que emiti el

certificado y debe estar siempre presente. Este campo es comn a todos los certificados
emitidos por la misma CA. La combinacin de "Serial Number" e "Issuer Name" identifican
unvocamente un certificado.
Validity Period. Indica la ventana de tiempo en la que el certificado es considerado vlido
salvo que haya sido revocado. Se representa como una secuencia de 2 fechas. La primera
componente de la fecha marca el inicio del periodo de validez, mientras que la segunda marca
el final del periodo de validez.
Subject Name. Indica el DN del propietario del certificado y puede ser nulo en el caso de que
se use un formato alternativo de nombre en las extensiones.
Subject Public Key. Este campo es una secuencia de 2 campos. Uno de ellos representa el
valor real de la clave pblica certificada, el otro es el OID del algoritmo asociado a la clave.
Issuer Unique Identifier. Es un campo opcional que identifica universalmente la autoridad
que firma el certificado. Se usa slo en las versiones 2 y 3. Su uso no est recomendado.
Subject Unique Identifier. Es un campo opcional que identifica el sujeto del certificado. Se
usa slo en las versiones 2 y 3. Su uso no est recomendado.
Las extensiones son un mecanismo disponible en los certificados de versin 3 que aade
flexibilidad y que permite confeccionar diferentes mecanismos de seguridad y protocolos. Cada
extensin del certificado se asocia con un flag de criticidad y, casi siempre, son los propios
estndares los que imponen la criticidad de las diversas extensiones.

Una extensin que se ha marcado como crtica debe ser procesada y comprendida
cuando se valida el certificado, de lo contrario se descarta el certificado.

Una extensin marcada como no crtica que no es comprendida cuando se valida el

certificado se ignora y se procede como si no estuviera presente. En cambio, si se
comprende la extensin no crtica debe ser procesada del mismo modo que si se
hubiera marcado como crtica.
A continuacin se pasa a describir las extensiones ms importantes.

Authority Key Identifier. Es un identificador nico de la clave que se debe utilizar

para verificar la firma digital del certificado. Distingue entre las mltiples claves del
mismo emisor de certificados.

Subject Key Identifier. Es un identificador nico asociado con la clave pblica

contenida en el certificado. Distingue entre las mltiples claves del mismo
propietario de certificados.

Key Usage. Es una cadena de bits usada para identificar las funciones que soporta
la clave pblica del certificado. Por ejemplo: firmas digitales, cifrado de claves,
cifrado de datos, firma de certificados, firma de CRLs,. . .

Extended Key Usage. Es una secuencia de OIDs que identifican usos especficos de
la clave pblica certificada. Por ejemplo: proteccin de e-mail, firma de cdigo,
autenticacin de servidor TLS, autenticacin cliente TLS,. . .

CRL Distribution Point. Indica la ubicacin donde reside la CRL asociada al

certificado.

Private Key Usage Period. Indica la ventana de tiempo en la que la clave privada
correspondiente a la clave pblica del certificado puede ser usada. Est pensado
para claves de firmas digitales. El uso juicioso de esta extensin puede proporcionar
un margen de tiempo entre el instante en el que la clave privada expira y el instante
en que el certificado expira. Esto ayuda a eliminar casos en los que firmas digitales
vlidas son cuestionadas debido a que los periodos de vida de las claves son muy
prximos o incluso idnticos.

Certificate Policies. Indican una secuencia de uno o ms OIDs de polticas

asociadas con la emisin y uso subsiguiente del certificado. Si esta extensin se
marca crtica, la aplicacin debe adherirse al menos a una de las polticas indicadas o
el certificado es descartado.

Policy Mappings. Indica la equivalencia entre OIDs de polticas definidos en dos

dominios de CAs. Slo estn presentes en certificados de CAs.
Subject Alternative Name. Indica nombres alternativos del poseedor del
certificado. Los formatos comnmente usados de nombres alternativos son
direcciones de e-mail, direcciones IP, nombres de servicios DNS,. . .
Issuer Alternative Name. Indica nombres alternativos asociados al emisor del
certificado. Algunos formatos usados son, como en la extensin anterior, direcciones
de e-mail o direcciones IP.
Basic Constraints. Permite distinguir el certificado de una CA del de una entidad
final. Debe aparecer en todos los certificados de CAs para afirmar que se trata de un
certificado de CA. Adicionalmente esta extensin puede contener un campo opcional
para indicar el mximo nmero de certificados de CAs que pueden seguir a este
certificado en un camino de certificacin.
Name Constraints. Una extensin slo presente en certificados de CA. El propsito
de esta extensin es restringir el espacio de nombres de los sujetos que emanan del
certificado de CA y es aplicable tanto al campo Subject Name como a la extensin
Subject Alternative Name.
Policy Constraints. Esta extensin est slo presente en certificados de CAs y
puede usarse para prohibir Policy Mappings o para requerir que cada certificado en el
camino de validacin tenga unos OIDs de polticas determinados.
Inhibit Any Policy. Esta extensin est slo presente en certificados de CAs e
indica que el OID correspondiente a Any Policy no debe ser considerado como un
identificador de polticas.
Freshest CRL Pointer. Proporciona un puntero a la informacin de CRL ms
reciente. En la prctica se trata de un puntero a una Delta CRL.

Segn el estndar X.509 se pueden introducir extensions privadas para campos de aplicacin
especficos. El grupo de trabajo del PKIX ha introducido extensiones privadas para su uso en
Internet. A continuacin se detallan algunas de ellas.

Authority Information Access. Especifica cmo se puede obtener informacin o

servicios ofrecidos por el emisor del certificado. Se usa, por ejemplo, para servicios
de validacin on-line basados en OCSP.

Subject Information Access. Especifica cmo se puede obtener informacin o

servicios ofrecidos por el sujeto del certificado. Se usa, por ejemplo, para identificar
la ubicacin del repositorio donde la CA publica informacin de certificado y CRL.
Cualquier cambio de la informacin contenida en un certificado antes de que expire obliga a
que el certificado sea revocado y se emita un nuevo certificado. Por tanto, debe procurarse
que la informacin de los certificados sea esttica para evitar una innecesaria revocacin y
reemisin de certificados.
Ejemplo de Certificado:

A continuacin se dan valores concretos de los diferentes campos que constituyen los
certificados X.509 v3, para el certificado digital mostrado:
Campo
Version
Serial Number
Signature
Algorithm

Valor
V3
45 b6 f7 f6 88 c8 77 c3 93 93 cd 44 ea 8c 8d 0f
sha1RSA
CN = VeriSign Class 3 Secure Server CA - G3
OU = Terms of use at https://www.verisign.com/rpa (c)10
OU = VeriSign Trust Network
O = VeriSign, Inc.
C = US
Mircoles, 13 de Julio de 2011 09:00:00 p.m.
Jueves, 08 de Agosto de 2013 08:59:59 p.m.
CN = sierras.cba.gov.ar
OU = Member, VeriSign Trust Network
OU = Authenticated by CertiSur S.A.
OU = Terms of use at www.certisur.com/rpa (c) 04
OU = Secretaria General de la Gobernacion de la Provincia de Cordoba
O = Secretaria General de la Gobernacion de la Provincia de Cordoba
L = Ciudad de Cordoba
S = Cordoba
C = AR

Issuer
Valid from
Valid to

Subject

RSA (1024 Bits)

Subject Public Key

Basic Constraints
Key Usage
CRL
Point

Distribution

Certificate Policies

Enhenced

Key

30 81 89 02 81 81 00 b8 6e 56 13 f6 a2 f9 ed 73 94
60 17 82 0f a0 72 0a 79 c2 be 89 ec ff 71 65 15 54
b0 6a 18 1f 2d db 8c 45 d1 2c 5b 66 e3 1b d0 ca c8
77 24 a0 30 ff e1 7e 98 37 2d da 6b 7f 58 e9 cc 5f
05 0a f7 ba ec c8 e7 27 dd ed b5 01 3d 73 12 cc 85
b8 c0 89 dc 01 8e bb 81 c2 60 1e
Subject Type=End Entity
Path Length Constraint=None
Digital Signature, Key Encipherment (a0)
: [1]CRL Distribution Point
Distribution Point Name:
Full Name:
URL=http://SVRSecure-G3-crl.verisign.com/SVRSecureG3.crl
[1]Certificate Policy:
Policy Identifier=2.16.840.1.113733.1.7.23.3
[1,1]Policy Qualifier Info:
Policy Qualifier Id=CPS
Qualifier:
https://www.certisur.com/rpa
Server Authentication (1.3.6.1.5.5.7.3.1)

45
3e
73
b0
19

09
26
93
5f
65

eb
27
01
4e
95

80
b0
05
34
de

c5
1c
15
7e
aa

14
58
2d
65
25

Usage
Authority
Identifier

Client Authentication (1.3.6.1.5.5.7.3.2)

Key

KeyID=0d 44 5c 16 53 44 c1 82 7e 1d 20 ab 25 f4 01 63 d8 be 79 a5

: [1]Authority Info Access

Authority
Information Access

1.3.6.1.5.5.7.1.12

Thumbprint
algorithm
Thumbprint

Access Method=On-line Certificate Status Protocol (1.3.6.1.5.5.7.48.1)

Alternative Name:
URL=http://ocsp.verisign.com
[2]Authority Info Access
Access Method=Certification Authority Issuer (1.3.6.1.5.5.7.48.2)
Alternative Name:
URL=http://SVRSecure-G3-aia.verisign.com/SVRSecureG3.cer
30 60 a1 5e a0 5c 30 5a
0`.^.\0Z
30 58 30 56 16 09 69 6d
0X0V..im
61 67 65 2f 67 69 66 30
age/gif0
21 30 1f 30 07 06 05 2b
!0.0...+
0e 03 02 1a 04 14 4b 6b
......Kk
b9 28 96 06 0c bb d0 52
.(.....R
38 9b 29 ac 4b 07 8b 21
8.).K..!
05 18 30 26 16 24 68 74
..0&.$ht
74 70 3a 2f 2f 6c 6f 67
tp://log
6f 2e 76 65 72 69 73 69
o.verisi
67 6e 2e 63 6f 6d 2f 76
gn.com/v
73 6c 6f 67 6f 31 2e 67
slogo1.g
sha1
99 f3 49 46 31 0c 5c 2f 9d a4 c0 d6 32 e0 ff cf b8 a9 8c 7b

1.4. Revocacin de certificados

En ocasiones puede ser necesario deshacer la asociacin entre entidad y clave pblica que
establece un certificado antes de que expire. En tal caso se procede a revocar el certificado.
Las circunstancias que obligan a revocar un certificado son muy variadas y, entre ellas, se
pueden citar el compromiso de la clave privada, compromiso de la CA, el empleado abandona
la compaa,.. .
Las formas ms comunes de implementar la revocacin de certificados son:

Mecanismos de publicacin peridicos, tales como Listas de Revocacin de

Certificados (Certificate Revocation Lists, CRLs), o

Mecanismos de consulta on-line tales como el Online Certificate Status Protocol

(OCSP).
A continuacin se exploran ambas soluciones.
1.4.1. CRLs: Certificate Revocation Lists (Listas de Revocacin de Certificados)
En pocas palabras:
Las CRLs son estructuras de datos firmadas que contienen una lista de certificados
revocados.
La firma digital agregada en la CRL proporciona mecanismos de autenticidad e integridad.
Siempre que las polticas lo permitan, las CRLs pueden ser almacenadas en memoria y facilitar
la verificacin de certificados off-line. Normalmente el emisor del certificado y de la CRL son la
misma autoridad, pero no siempre ocurre as.
Actualmente hay definidas 2 versiones de CRLs en el estndar X.509.

La versin 1 presenta varios defectos: problemas de escalabilidad, posibilidad de

ataques de sustitucin que reemplazan una CRL por otra sin ser detectado,.. .

La versin 2 corrige estos problemas mediante el mecanismo de las extensiones. En

el caso de las CRLs hay dos tipos de extensiones:

las aplicables slo a una entrada de la lista y

las aplicables globalmente a la CRL.

Cada extensin se asocia con una criticidad:

Una extensin marcada como no crtica puede ser ignorada por la aplicacin.

Cuando una aplicacin procesando una CRL no reconoce una extensin marcada
como crtica que slo aplica a un campo de la lista considerar el certificado como
revocado y realizar las acciones adicionales que marque la poltica.
Cuando una aplicacin procesando una CRL no reconoce una extensin marcada
como crtica que aplica globalmente a la CRL considerar los certificados
identificados como revocados, pero adems considerar que la lista no es completa y
actuar adicionalmente como indique la poltica.

Del mismo modo que ocurre con las extensiones de los certificados, las extensiones de CRL
pueden ser adaptadas para un entorno concreto, tal es el caso de la recomendacin RFC5280
del PKIX del IETF que ajusta las CRLs para su uso en Internet.
Estructura y semntica de las CRLs
A continuacin se van a detallar los diferentes campos que constituyen las CRLs. La figura
representa el contenido de una CRL v2.

Figura: Elementos de una CRL X.509 v2

A continuacin se detallan los diferentes campos que constituyen las CRL v2.

Version. Indica la versin de la CRL. Si el campo no est presente indica que se

trata de una CRL v1; si el campo est presente su valor debe ser el entero 1,
indicando que se trata de una CRL v2.

Signature Algorithm. Indica el OID del algoritmo usado para calcular la firma
digital de la CRL. Debe coincidir con el campo Signature Algorithm perteneciente a la
porcin no firmada.

Issuer Name. Se trata del DN del emisor de la CRL, es decir, quin firma la CRL.
Debe estar siempre presente y ser nico.

This Update. Indica la fecha y hora en la que se emiti la CRL.

Next Update. Campo opcional segn X.509 que indica la fecha y hora en la que se
emitir la siguiente CRL.

Revoked Certificates. Se trata de la lista de los certificados revocados. Cada

entrada contiene el Serial Number del certificado revocado, la fecha y hora en la que
se revoc el certificado y, opcionalmente, puede incluir extensiones aplicables a la
entrada concreta de la lista.

Extensions. Son las extensiones aplicables a la CRL globalmente.

Extensiones X.509 aplicables a una entrada. El estndar X.509 define varias

extensiones aplicables a una entrada de la lista. Estas extensiones permiten
agregar informacin adicional a cada revocacin y la ms importantes son:

10

Reason Code. Razn por la cual el certificado fue revocado (compromiso de

la clave privada, compromiso de la CA, cambio de algn dato,. . . ).

Certificate Issuer. Es el nombre del emisor del certificado.

Hold Instruction. Permite soportar la suspensin temporal de un

certificado.

Invalidity Date. Es la fecha y hora en la que el certificado deja de ser

vlido.

Extensiones X.509 aplicables globalmente. El estndar X.509 define varias

extensiones aplicables globalmente a una CRL. A continuacin se detallan
algunas de ellas.

Authority Key Identifier. Es el identificador nico de la clave que debe

usarse para verificar la firma digital. Distingue entre mltiples claves del
mismo emisor de CRLs.

Issuer Alternative Name. Contiene uno o ms nombres alternativos del

emisor de la CRL.

CRL Number. Contiene un nmero de secuencia creciente para cada CRL

emitida por un emisor de CRL. Permite detectar fcilmente cuando una CRL
reemplaza a otra.

CRL Scope. Proporciona un mtodo flexible para particionar CRLs. Las CRLs
se pueden partir de muchas maneras (tipo de certificado, razn de
revocacin, nmeros de serie,. . . )

Status Referral. Esta extensin est presente en CRLs que no llevan

informacin
sobre
certificados
revocados.
Simplemente
transporta
informacin para asegurar que se usa la informacin de revocacin
apropiada. Por un lado proporciona informacin dinmica sobre la particin
de CRLs y, por otro lado, publica una lista de CRLs actuales que se utilizan
para establecer si ya se dispone de dicha informacin.
CRL Stream Identifier. Identifica el contexto en el cual el CRL Number es nico.
Por ejemplo, un CRL Stream Identifier se puede asignar a cada CRL Distribution
Point. Combinando el Stream Identifier con el CRL Number se proporciona un
identificador nico para cada CRL emitida por una CA.
Ordered List. Indica si la lista de certificados revocados est en orden ascendente
por Serial Number o fecha de revocacin.
Delta Information. Esta extensin proporciona la ubicacin de la Delta CRL
correspondiente a esta CRL.
Issuing Distribution Point. Esta extensin identifica el CRL Distribution Point para
esta CRL en concreto y el tipo de certificado contenido en la CRL (certificados de CA
o certificados de entidad final).
Delta CRL Indicator. Indica que esta CRL es una Delta CRL relativa a la CRL base
referenciada.
Base Update. Se usa en Delta CRLs para indicar la fecha y hora despus de la cual
la Delta CRL proporciona revocaciones.
Freshest CRL. Identifica cmo obtener la Delta CRL ms reciente para la CRL base
que contiene esta extensin.

Emisin de las CRL

La mayora de CAs emiten sus propias CRLs, es decir, la CA emite los certificados y las CRLs.
CRLs completas: Peridicamente la CA emite un nica CRL que cubre toda su poblacin de
certificados. Tales CRLs se denominan CRLs completas. Sin embargo, el uso de las CRLs
completas tiene importantes limitaciones: el tamao de las CRLs puede crecer mucho, la
periodicidad de publicacin de las CRLs debe ser grande para evitar la degradacin de los
recursos de red. Esto obliga a buscar soluciones alternativas.
CRLs CARL y EPRL: Para evitar que la CRL crezca demasiado, la CA puede dividir la poblacin
segn el tipo de sujeto.

Una CARL es una CRL dedicada exclusivamente a revocar certificados de CAs. En una
PKI jerrquica la revocacin de una CA superior impacta en todas las CAs
11

subordinadas y en todas las entidades finales que caen bajo cualquiera de las CAs
afectadas.
Una EPRL es una CRL dedicada exclusivamente a la revocacin de entidades finales.

CRL Distribution Points: Los CRL Distribution Points tambin permiten que la informacin de
revocacin de una nica CA se distribuya en varias CRLs. Los certificados apuntan a la
ubicacin de la CRL, de modo que la aplicacin que valida el certificado no necesita conocer a
priori dnde se encuentra la CRL. Un inconveniente asociado con el uso de los CRL Distribution
Points es que una vez se ha emitido el certificado el CRL Distribution Point est fijado durante
toda la vida del certificado. Las extensiones CRL Scope y Status Referral permiten flexibilizar el
mecanismo de los CRL Distribution Points.
CRLs del estndar X.509: El estndar X.509 define dos tipos adicionales de CRLs: las Delta
CRL y las CRLs indirectas.

Una Delta CRL slo contiene informacin de revocacin no disponible cuando se

emiti una CRL base o bien desde un determinado instante de tiempo. Esto permite
la publicacin de Delta CRLs relativamente pequeas que pueden ser emitidas con
mucha mayor frecuencia que la CRL base optimizando los objetivos, a menudo
contradictorios, de rendimiento e informacin actualizada. Para disponer de toda la
informacin de revocacin disponible en un instante de tiempo dado basta con la
CRL base y la ltima Delta CRL. No hay que acumular las Delta CRLs emitidas con
anterioridad. El coste adicional de las Delta CRLs es que la validacin de certificados
es ms compleja.

Por otro lado, las CRL indirectas permiten que informacin de revocacin de
mltiples CAs se emita en una nica CRL. Las CRL indirectas reducen el nmero de
CRLs que se necesitan recuperar cuando se est validando un certificado. Por
ejemplo, un nico dominio PKI puede tener varias CAs y en lugar de usar varias
CRLs, una para cada CA, el dominio puede usar una CRL Indirecta para mejorar la
eficiencia.
El estndar X.509 tambin introduce el concepto de Delta CRL indirecta que combina los dos
conceptos anteriores.
1.4.2. Mecanismos de consulta on-line
La principal diferencia entre los mecanismos de publicacin peridica y los mecanismos de
consulta on-line consiste en que la parte que analiza un certificado debe estar on-line. Los
mecanismos de publicacin peridica son ms adecuados para operar off-line porque la
informacin de revocacin puede guardarse en memoria. El grupo PKIX del IETF ha dedicado
un esfuerzo significativo a definir el OCSP (On-line Certificate Status Protocol, RFC2560) que
constituye el mecanismo de consulta on-line ms usado. Recientemente el grupo PKIX ha
explorado los requisitos de Delegated Path Discovery (DPD) y Delegated Path Validation (DPV)
y ha desarrollado el protocolo Simple Certificate Validation Protocol (SCVP).
OCSP (On-line Certificate Status Protocol, RFC2560)
OCSP es un protocolo solicitud-respuesta relativamente simple que permite una manera de
obtener informacin de revocacin on-line de una entidad fiable denominada OCSP responder.
Una solicitud OCSP consiste en:

la versin del protocolo,

el tipo de servicio solicitado y

uno o ms identificadores de certificado.

El identificador de certificado consiste, a su vez, en:

el hash del DN del emisor,

el hash de la clave pblica del certificado y

el Serial Number del certificado.

Las respuestas consisten en:
12

el identificador del certificado,

el estado del certificado (good, revoked o unknown) y
el intervalo de validez de la respuesta.

Las respuestas OCSP deben estar firmadas digitalmente para que la parte solicitante pueda
confiar en ellas. Segn el protocolo las solicitudes pueden estar firmadas o no.
OCSP slo verifica si el certificado ha sido revocado o no. No verifica el periodo de validez ni si
el certificado es vlido en el contexto de uso. Por otro lado, OCSP no es ms que un protocolo
y no especifica la infraestructura que respalda el servicio; es decir, no elimina necesariamente
las CRLs u otros mtodos para recoger la informacin de revocacin de los certificados.
SCVP (Simple Certificate Validation Protocol)
SCVP permite DPV (Delegated Path Validation) y DPD (Delegated Path Discovery) en el
entorno de Internet. DPV permite delegar en otro componente el proceso de validacin de un
certificado. Por otro lado, DPD permite delegar el proceso de la construccin del camino de los
certificados. Esto puede ser particularmente til en el caso de dispositivos en los que la
validacin local es inviable por motivos de rendimiento como es el caso de los telfonos
mviles.
1.5. COMPONENTES DE UNA PKI
En esta seccin se introducen los componentes de una PKI y se describen sus funcionalidades.
Las funcionalidades deben estar presentes en cualquier PKI, pero las implementaciones
especficas pueden agruparlas de forma diferente.
Por ejemplo, la Certification Authority (Autoridad de Certificacin, CA) y la Registration
Authority (Autoridad de Registro, RA) en ocasiones se combinan en un nico componente.
Esto no afecta qu funciones se realizan, sino dnde se realizan. Las PKIs se construyen con
varios componentes, cada uno diseado para realizar unas pocas tareas particularmente bien.
La figura presenta un modelo simplificado de los componentes de una PKI basado en el que se
describe en el RFC5280 del PKIX del IETF:

Figura: Esquema simplificado PKI

13

Figura: Entidades PKI (RFC 5280 PKIX Certificate and CRL Profile)
A continuacin se explica el esquema someramente.
Peticin de certificado:

Los usuarios finales (end entities), usando transacciones de gestin, envan su

peticin de certificado a la RA para su aprobacin.

Si la peticin es aprobada, se pasa a la CA para ser firmada.

La CA revisa la peticin de certificado y, si supera la revisin, se firma la peticin y

se genera el certificado.

Para publicar el certificado, la CA lo enva al repositorio de certificados.

Observaciones:

El diagrama tambin muestra que los usuarios finales pueden comunicarse

directamente con la CA de manera que toda la funcionalidad est implementada en
la CA.

Del mismo modo, el diagrama muestra que CA y RA envan los certificados al

repositorio.

La implementacin debe escoger una de las alternativas.

Revocacin de certificados: La revocacin de certificados sigue un curso similar al de la
generacin:

Los usuarios finales piden a la RA que revoque su certificado,

La RA decide y reenva la solicitud a la CA.

La CA actualiza la Certificate Revocation List (Lista de Certificados Revocados, CRL) y

la publica en el repositorio de la CRL.
Finalmente, los usuarios finales pueden verificar la validez de un certificado especfico usando
un protocolo operativo.
1.5.1. Certification Authority
La CA es el componente esencial de una PKI. Una CA es un conjunto de hardware, software y
el personal que los opera. Una CA realiza cuatro funciones bsicas:
14

Emisin de certificados: crea los certificados y los firma.

Mantenimiento de la informacin de estado y emisin CRLs: Mantener
informacin del estado de los certificados y emitir CRLs.
Publicacin de certificados y CRLs: Publicar los certificados y CRLs de manera
que los usuarios puedan obtener la informacin que necesitan para implementar los
servicios de seguridad.
Mantenimiento de archivos: Mantener archivos sobre la informacin de estado de
los certificados expirados o revocados que emiti.

Emisin de certificados: Una CA puede emitir certificados a usuarios, otras CAs o ambos:

Cuando una CA emite un certificado est afirmando que el sujeto (entidad

nombrada en el certificado) tiene la clave privada que corresponde a la clave pblica
del certificado. Si la CA incluye informacin adicional en el certificado, la CA est
dando por cierto que dicha informacin corresponde al sujeto. Esta informacin
adicional podra ser informacin de contacto (por ejemplo, email) o informacin de
poltica (por ejemplo, los tipos de aplicaciones en los que se puede usar la clave
pblica).

Cuando el sujeto del certificado es otra CA, la CA emisora est afirmando que se
puede confiar en los certificados emitidos por la CA sujeto.
Responsabilidades de la CA respecto de la Emisin de certificados:

La primera responsabilidad de una CA es proteger su clave privada. Si un

atacante consiguiera la clave privada de una CA podra suplantarla y emitir
certificados como si fuera la misma CA. Para proteger la clave privada la CA utiliza
un mdulo criptogrfico. Los mdulos criptogrficos:

generan claves,

implementan algoritmos criptogrficos y

protegen las claves.

Pueden implementarse en hardware, software o una combinacin de ambos. Los
mdulos criptogrficos de hardware (smart cards, tarjetas PCMCIA, . . . ) realizan
las operaciones criptogrficas en un procesador externo y guardan la clave privada
fuera de la memoria del sistema. El "National Institute of Standards and
Technology" (NIST) desarroll el estndar FIPS 140, "Security Requirements for
Cryptographic Modules", que especifica cuatro niveles de seguridad progresivos para
los mdulos criptogrficos. Se recomienda que una CA utilice siempre un mdulo
criptogrfico de hardware de, al menos, nivel 2 de acuerdo con el FIPS 140 para
generar y proteger su clave privada.

La segunda responsabilidad de una CA es verificar que la informacin del

certificado es cierta (informacin del sujeto, informacin del contacto,
informacin de poltica, . . . ). Si bien la CA puede verificar mediante la firma digital
que el sujeto posee la clave privada correspondiente, el resto de la informacin
debe verificarse externamente ya que depende de informacin proporcionada por
agentes externos a la CA.

La tercera responsabilidad de una CA es asegurar que todos los certificados

y CRLs que emite cumplen con un perfil. Por ejemplo, si una CA se disea para
emitir certificados para e-mail, no puede emitir un certificado que autorice al sujeto
a la firma de contratos. Para asegurar el cumplimiento de esta responsabilidad, la
CA debe verificar que todos y cada uno de los certificados y CRLs que firma cumplen
con el perfil. Por otro lado, la CA tambin debe proteger la integridad del perfil y
restringir su acceso. La restriccin del acceso puede ser fsica (acceso a travs de
tarjeta al recinto), lgica (firewall) o procedimental (se requieren dos miembros del
personal que atiende la CA para modificar el sistema).
Mantenimiento de la informacin de estado y emisin CRLs: Al igual que con los
certificados, los contenidos de las CRLs deben ser correctos para ser tiles: una omisin en
una CRL puede provocar que un usuario acepte un certificado revocado, mientras que, una
revocacin incorrecta puede resultar en una denegacin de servicio.
Responsabilidades de la CA respecto del Mantenimiento de la informacin de estado y emisin
CRLs:

15

La cuarta responsabilidad de una CA es mantener una lista de certificados

en los que no se debe confiar. Proteger esta informacin es similar a proteger el
perfil, mientras que modificar el estado de un certificado depende de informacin
proporcionada desde el exterior de la CA.

Publicacin de certificados y CRLs: Los certificados y CRLs que emite una CA slo son tiles
si estn disponibles de manera que los usuarios puedan implementar los servicios de seguridad
que requieren.
Responsabilidades de la CA respecto de la Publicacin de certificados y CRLs:

La quinta responsabilidad de una CA es distribuir sus certificados y CRLs. En

general, la distribucin de los certificados es ms un problema de rendimiento y
disponibilidad que de seguridad; no se requiere restringir el acceso a certificados y
CRLs puesto que tal informacin no es secreta. Sin embargo, en ocasiones, la CA
puede querer denegar el acceso a los certificados a personas ajenas a la
organizacin por simples motivos deseguridad.
Mantenimiento de archivos: Finalmente, la CA necesita mantener informacin para
identificar la firma de un documento antiguo cuyo certificado ya ha expirado. Para soportar
este objetivo el archivo debe demostrar que el certificado era vlido en el momento en que se
firm del documento. Esto puede requerir el uso de un servidor de tiempo criptogrfico.
Responsabilidades de la CA respecto del Mantenimiento de archivos:

La sexta responsabilidad de una CA es el mantenimiento de suficiente

informacin de archivo para establecer la validez de certificados despus
de que hayan expirado. La principal dificultad de esta funcin es que la
informacin debe mantenerse durante largos periodos de tiempo.
Delegacin de responsabilidad
Es difcil disear un sistema que satisfaga simultneamente todos los requisitos. Una CA suele
cumplir los ms prioritarios y delegar el resto.
La responsabilidad principal de una CA es proteger la clave o claves privadas usadas para
firmar certificados y CRLs. Para satisfacer este requisito la CA debe construir un permetro con
controles de seguridad fsica, tecnolgica y procedimental. Este permetro permite tambin
alcanzar los requisitos tercero y cuarto.
Este permetro de seguridad impide el cumplimiento de las restantes responsabilidades. Los
tres componentes restantes de la infraestructura se disean para aceptar esas
responsabilidades en lugar de la CA:

Registration Authority (RA): Una entidad que verifica el contenido de los

certificados se denomina Registration Authority (RA). Una RA tambin puede asumir
algunas de las responsabilidades para revocar certificados. En la prctica, una CA
puede disponer de muchas RAs; por ejemplo, una para cada grupo de usuarios.

Repositorio: Una entidad que distribuye certificados y CRLs se llama repositorio y

se disea para maximizar rendimiento y disponibilidad. Los repositorios a menudo se
duplican para maximizar la disponibilidad e incrementar el rendimiento.

Archivo: La entidad que proporciona almacenamiento seguro a largo plazo se

denomina archivo. Esta entidad no requiere un elevado rendimiento ni tampoco que
se mantengan mltiples archivos.
1.5.2. Registration Authority (RA)
El propsito de una RA es verificar el contenido de los certificados en lugar de la CA. De igual
modo que una CA, una RA es una coleccin de hardware, software y las personas que lo
operan. Cada CA mantiene una lista de RAs acreditadas y verificando la firma de una RA en un
mensaje una CA puede estar segura de que una RA acreditada proporcion la informacin y,
por tanto, es fiable. Por consiguiente, es importante que una RA proporcione proteccin
adecuada para su clave privada. Se recomienda que las RAs usen mdulos criptogrficos de
hardware validados segn el estndar FIPS 140.
16

Hay dos modelos bsicos para que una RA verifique el contenido de un certificado:

En el primer modelo la RA recoge y verifica la informacin antes de presentar a la CA

la solicitud para el certificado.

En el segundo modelo, la CA recibe una solicitud de certificado que enva a la RA. La

RA revisa el contenido y determina si la informacin es correcta. La RA responde a la
peticin de la CA con un simple S o No.
El primer modelo se usa cuando el usuario se persona en la RA. En tal caso, se puede verificar
la identidad del usuario mediante el DNI o el permiso de conducir. Si el usuario ha generado su
par de claves, la RA solicita el certificado a la CA con la informacin apropiada.
Alternativamente, la RA puede proporcionar un valor secreto al usuario. El usuario genera su
par de claves, emite la solicitud a la CA y se autentifica con el valor secreto. Este modelo
puede tambin usarse cuando la RA posee el mdulo criptogrfico de hardware
correspondiente al usuario. En general es preferible que los usuarios se generen su propio par
de claves, pero la generacin de claves puede ser una tarea muy exigente en trminos de
recursos computacionales. Para limitar el coste del mdulo criptogrfico puede ser deseable
generar pares de claves usando un hardware especial y cargar la clave privada en el mdulo
de hardware del usuario en la RA. En este caso es la RA quien genera el par de claves y crea
una solicitud de certificado con la clave pblica y el resto de informacin. Tras obtener el
certificado de la CA, la RA entrega el mdulo criptogrfico al usuario.
El segundo modelo se usa cuando el usuario no puede ser identificado de antemano y genera
la solicitud de certificado. En este caso el usuario solicita que el certificado contenga cierta
informacin. La CA puede determinar que el usuario posee las claves pblica y privada, pero
no puede saber si el resto de la informacin es correcta. La CA traspasa la solicitud a la RA que
la aceptar o rechazar y proporcionar el resultado a la CA.
1.5.3. Repositorio
Un repositorio acepta certificados y CRLs de una o ms CAs y los hace disponibles a las partes
que necesitan implementar servicios de seguridad bajo peticin. Los repositorios se disean
para proporcionar mxima disponibilidad y rendimiento, ya que los mismos datos establecen
su integridad. Los repositorios necesitan restringir el conjunto de usuarios que pueden
actualizar la informacin, ya que, de lo contrario, un atacante podra sustituir los certificados
con basura y provocar un ataque de denegacin de servicio.
1.5.4. Archivo
Un archivo asume la responsabilidad del almacenamiento a largo plazo de informacin en lugar
de la propia CA. Un archivo declara que la informacin era correcta en el momento en que se
recibi y que no ha sido modificada. El archivo protege la informacin a travs de mecanismos
tcnicos y procedimientos. Si se suscita una disputa, la informacin del archivo puede usarse
para verificar firmas de documentos viejos en fechas posteriores.
1.5.5. Usuarios
Hay dos tipos de usuarios soportados por una PKI:

Poseedores de certificados: Los poseedores del certificado son los sujetos del
certificado y mantienen la clave privada.

Partes confiantes: Las partes confiantes usan la clave pblica de un certificado

para verificar la firma o cifrar datos.
En la prctica, la mayora de entidades soportan ambos papeles.
Del mismo modo, CAs y RAs son tambin usuarios ya que generan y verifican firmas y
transmiten claves entre ellas mismas o con los propios usuarios.
Poseedores de certificados

17

Los poseedores de certificados obtienen certificados de la infraestructura y usan sus claves

privadas para implementar servicios de seguridad. Generan firmas digitales, descifran datos
(por ejemplo claves simtricas) y usan sus claves privadas para establecer claves simtricas a
travs de protocolos de acuerdo de claves.
Para cumplir estos objetivos el poseedor de un certificado debe realizar las siguientes
acciones:

Identificar la CA que emite los certificados.

Solicitar el certificado directamente o a travs de una RA.

Incluir el certificado en las transacciones que as lo requieran.

En ocasiones los poseedores de un certificado necesitarn interactuar con el repositorio para
obtener su certificado, aunque no de una manera regular.
Partes confiantes
Las partes confiantes usan la PKI para implementar servicios de seguridad utilizando la clave
pblica en el certificado. Pueden verificar firmas digitales, cifrar datos (claves simtricas) y
usar la clave pblica para establecer claves simtricas a travs de protocolos de acuerdo de
claves.
Para implementar estos servicios de seguridad, una parte confiante debe realizar las siguientes
acciones:
Identificar una CA como su punto inicial de confianza.

Verificar firmas de certificados y CRLs.

Obtener certificados y CRLs del repositorio.

Construir y validar caminos de certificacin.

Una parte confiante interacta con el repositorio regularmente. Sus interacciones con las CAs
se limitan a la seleccin de los puntos de confianza y no interaccionan con las RAs.

18

CAPITULO 2: Evaluacin
2.1. Introduccin
En ltima instancia, el despliegue de una PKI en una organizacin est motivado por
necesidades de seguridad avanzada en las comunicaciones a travs de la red o en el
almacenamiento de informacin.
Durante la fase de evaluacin de la necesidad de una PKI, se analizan los requisitos de
seguridad presentes y futuros de la organizacin. Previamente puede ser necesario recoger
informacin mediante una auditora de seguridad o un test de penetracin.
A continuacin nos centraremos en las reas claves de la fase de evaluacin:

anlisis de los requisitos de negocio,

beneficios que aporta una PKI,

documentos CP y CPS y

estudio de costes.
Tambin se proporcionarn criterios sobre la externalizacin y sobre la seleccin del producto o
el proveedor del servicio.
2.2. Anlisis de los requisitos de negocio
Cmo afecta la organizacin o empresa a la PKI? La organizacin o empresa va a afectar de
distintos modos a la PKI, pero la influencia ms decisiva es mediante las razones de negocio
que provocarn su despliegue. La razn o razones de negocio que motivan el despliegue de
una PKI tendrn impacto en cada etapa del proyecto y determinarn la inversin que una
empresa est dispuesta a realizar, ya que sta depender de la importancia de los procesos
cuyo nivel de seguridad se quiere aumentar por medio de la PKI.
Hay muchos artculos en Internet que dan razones muy variadas que justifican la implantacin
de una PKI. Por ejemplo:

El Dartmouth College promueve el uso de PKIs en instituciones educativas superiores

para mejorar la seguridad y fomentar una colaboracin mucho ms estrecha entre
ellas que la actual. Las redes educativas son muy abiertas y estn expuestas a
hackers, virus y spam; adems, los usuarios suelen tener comportamientos
arriesgados como, por ejemplo, compartir passwords. Una PKI permite combatir
estos inconvenientes.

El gigante industrial Johnson & Johnson decidi implantar una PKI para reducir los
gastos derivados del mantenimiento de las passwords. Segn sus estimaciones
19

costaba 37$ por empleado y ao soportar los cambios y resets de passwords. El

cambio fue muy complejo ya que se incluy adaptar aplicaciones de software de
diferentes fabricantes (Siebel, SAP, J.D. Edwards,. . . ) e implantar un servicio de
directorio (Active Directory de Windows 2000).
Otra causa comn de implantacin de PKIs, sobretodo en organizaciones
gubernamentales, es la firma digital. La posibilidad de firmar digitalmente un
documento electrnico permite ahorrar tiempo y papel.
El Bank of Bermuda tena como objetivo proporcionar acceso electrnico seguro y
econmico a sus servicios tanto a personal propio como a clientes en cualquier lugar
del mundo y en cualquier momento.

En ocasiones, los requisitos de seguridad de algunas empresas u organizaciones no precisan

una solucin basada en certificados y se pueden resolver de forma ms simple. Por otro lado,
no todas las soluciones basadas en certificados requieren el despliegue de una PKI, algunas
compaas pueden decidir simplemente comprar un conjunto limitado de certificados de una
Autoridad de Certificacin (CA) comercial.
La organizacin tiene otras implicaciones en los requisitos que debe cumplir la PKI:

Disponibilidad. Qu disponibilidad necesita la PKI en la organizacin? Pensemos

en un banco, por ejemplo, que requiere que sus servicios funcionen 24 horas al da
los 365 das del ao. Esto repercutir en el diseo de las CAs, directorio,. . .

Escalabilidad. Necesita la PKI ser escalable? Crecer rpidamente el nmero de

certificados? Se prevn fusiones con otras empresas? Se desplegarn muchas
aplicaciones PKI en el futuro?

Rendimiento. Las operaciones criptogrficas pueden requerir hardware especial o

obligar a actualizar el hardware.

Coste. Las organizaciones o empresas tienen un presupuesto limitado que puede

condicionar la eleccin de la PKI.
Todas estas implicaciones hacen que la implantacin de una PKI en una organizacin sea un
proceso fuertemente depediente de la organizacin y prcticamente nico. Los beneficios que
aporta una PKI se hallan ntimamente relacionados con el anlisis de requisitos.
2.3. Beneficios de una PKI
En este apartado se pretende aportar las razones que justifican la implantacin de una PKI,
tanto las razones tcnicas como las puramente de negocio.
Se pretende responder a la pregunta siguiente: cmo mejorar una organizacin la
implantacin de una PKI? Una implantacin con el nico propsito de disponer de la ltima
tecnologa est condenada al fracaso. El diseador de una solucin PKI debe tener una visin
clara de cmo la PKI ayuda a mejorar la organizacin o empresa. Esta visin puede focalizar la
implantacin en un rea que proporcione resultados tangibles inmediatos y que asegure el
xito del proyecto. Muchas organizaciones, particularmente empresas, no se conformarn con
simples razones tcnicas para llevar a cabo la implantacin. Las empresas desean conocer
razones de negocio, es decir, cmo ahorrar dinero una PKI, o ms concretamente, una CA o
una smart card? Tal vez, la etapa ms crtica en cualquier proyecto es proporcionar slidas
justificaciones de negocio para llevarlo a cabo.
Los beneficios que una PKI ofrece se derivan del propio concepto de PKI y de los servicios que
ofrece. Una PKI es una solucin global de seguridad, no un conjunto de soluciones puntuales
diferentes, y ofrece una nica infraestructura de seguridad que puede ser usada por muchas
aplicaciones en los entornos ms heterogneos. Especficamente, ofrece servicios de
confidencialidad, integridad, autenticacin y no repudio en numerosos contextos.
He aqu una lista de los beneficios que ofrece una PKI:

Gestin de passwords y Single-Sign-On. Hay muchos problemas ocasionados por

el sistema tradicional de usernames y passwords. Una PKI resuelve estos problemas
de una manera consistente y sencilla para los usuarios y administradores.

20

Firmas digitales. Una PKI permite firmar digitalmente documentos. Las firmas
tienen un reconocimiento legal. En conjunto se consigue sustituir el papel con
formularios electrnicos, ms velocidad y trazabilidad en los procesos de negocios y
una seguridad mejorada en las transacciones electrnicas.
Cifrado. Fcil cifrado de datos para cada individuo (sin intercambio previo de
informacin) mediante el acceso al certificado que contiene la clave pblica.
Comodidad del usuario. Menos passwords. Mecanismo consistente de
autenticacin que basta con aprender una vez. Procedimientos sencillos para cifrar,
firmar y autenticar.
Administracin coherente de seguridad en la empresa. Emisin y revocacin
centralizada de credenciales de usuario. Identificacin consistente de usuario cuando
se emiten las credenciales. Idntico mecanismo de autenticacin para todas las
aplicaciones o servicios de red. Aprovechamiento de la inversin en smart cards o
tokens USB al ser usados por muchas aplicaciones.
Interoperabilidad con otras instituciones. La confianza entre organizaciones y/o
empresas permite firmar y cifrar correos, firmar documentos, autenticacin en
aplicaciones compartidas,. . .
Solucin basada en estndares. Los estndares proporcionan interoperabilidad
entre fabricantes diferentes. Muchas implementaciones disponibles. Los estndares
permiten que haya cdigo libre.
Amplio soporte. En sistemas operativos: Windows, Linux, UNIX,. . . .
Almacenamiento de claves en software y hardware. En aplicaciones: Apache, IIS,
Oracle, SSL,. . . . Cdigo abierto y comercial.
Entornos variados. Las PKI son soluciones ampliamente aceptadas en la industria
(Johnson & Johnson, Microsoft,. . . ), organizaciones gubernamentales,.. .

Estas ventajas tcnicas se traducen en ventajas de negocio, aunque su cuantificacin concreta

es difcil:

Mejoras en la eficiciencia del workflow. Se pueden conseguir ahorros

significativos de tiempo mediante el manejo electrnico de documentos.

Optimizacin de los recursos humanos. El usuario puede centrarse en su trabajo

en lugar de gastar tiempo en detalles asociados con la infraestructura de seguridad.

Reduccin de los recursos humanos. La operacin de una arquitectura unificada

en lugar de mltiples soluciones puntuales requiere menos recursos administrativos.

Reduccin del papel. Se puede ahorrar en costes de material, en el espacio

necesario para almacenarlo, en reduccin de residuos y en menor intrusin
ambiental.

Menos carga administrativa. Los usuarios finales requieren menos asistencia

(help-desk,. . . ).

Reduccin de prdidas por robo electrnico. Los datos corporativos estn

protegidos, lo que reduce el riesgo de que sean revelados sin autorizacin.

Ahorros en telecomunicaciones. La capacidad de crear redes privadas virtuales

(Virtual Private Networks, VPN) sobre una red pblica como Internet es ms barata
que alquilar lneas privadas.

Generacin de ingresos. Una PKI puede usarse para generar ingresos. Por
ejemplo, una organizacin financiera puede ofrecer servicios de validacin de
transacciones basados en firmas digitales y certificados.
En cualquier caso, el robo y fraude electrnico van en aumento y deben buscarse soluciones.
Las empresas perciben la seguridad como algo necesario y, por tanto, le dedican cierta
atencin. Cualquier solucin global de seguridad debe contemplar los recursos corporativos y
las comunicaciones, tanto externas como internas. Qu ocurrira si le robasen el porttil al
CEO de la empresa y la informacin sensible no estuviera cifrada? Es difcil de cuantificar el
dao econmico que sufrira la empresa si esa informacin cayera en malas manos. Se puede
argumentar que no hace falta una PKI para cifrar la informacin de un porttil, pero una PKI
ofrece tambin la posibilidad de recuperar la informacin cifrada si el CEO, por ejemplo,
sufriera una incapacidad transitoria. El valor de una PKI que protege y permite recuperar
informacin crtica es muy elevado, incluso si sus beneficios cuantitativos son casi imposibles
de medir con precisin.
21

Una PKI es una infraestructura y, como tal, slo produce beneficios cuando es utilizada. De
hecho, son las aplicaciones quienes se conectan a la infraestructura, la utilizan y provocan
beneficios. Los tipos de certificados que sern necesarios y las entidades a las cuales se
emitirn (usuarios, mquinas,. . . ) dependen de las aplicaciones que vaya a soportar la PKI.
Es importante conocer las principales aplicaciones que pueden aprovechar la PKI y
proporcionar una seguridad fuerte ya que la organizacin o empresa querr usar algunas de
ellas. Algunas aplicaciones estn inmersas en el sistema operativo y otras no. He aqu algunas
de las principales aplicaciones:

Web segura. En una intranet corporativa o en una extranet se pueden usar

certificados para proporcionar seguridad fuerte mediante los protocolos SSL y TLS.
Ambos protocolos proporcionan autenticacin de cliente, autenticacin de servidor y
confidencialidad de datos.

Correo seguro. El protocolo Secure/Multipurpose Internet Mail Extensions (S/MIME)

tambin est basado en criptografa de clave pblica y certificados. Este protocolo
permite firmar y cifrar mensajes. Muchas aplicaciones de e-mail proporcionan un
sistema dual de claves para firmar y cifrar.

Cifrado del sistema de ficheros. Proporciona cifrado a nivel del sistema de

ficheros. Como medida de seguridad, conviene que permita la recuperacin de los
datos por una persona adicional.

Firma de cdigo. Protege contra descargas de cdigo alterado (hackers) de

websites.

Smart card logon. Proporciona autenticacin fuerte de 2 factores (posesin de la

smart card y conocimiento del PIN (Personal Identification Number)). A diferencia de
las passwords, los PINs no se envan a travs de la red, lo cual es una medida
adicional de seguridad.

Virtual Private Network. IPSec es un protocolo que funciona a nivel IP con

certificados y se usa para autenticar los extremos de la comunicacin.

Cualquier aplicacin. Los fabricantes proporcionan APIs con las que adaptar
cualquier aplicacin para que use la PKI.
2.4. CP (Certificate Policy) y CPS (Certification Practice Statements)
Qu grado de confianza otorgo a un certificado concreto?
Hay dos tipos de documentos que describen las polticas y procedimientos asociados a una
PKI:

el primer documento se denomina Certificate Policy (Poltica de Certificados, CP) y

el segundo Certification Practice Statements (Prcticas de Certificacin, CPS).

Estos documentos tienen un formato comn pero diferentes objetivos y audiencias. Existe una
relacin directa entre el contenido de las extensiones de polticas de los certificados X.509 v3 y
los
documentos CP.
Una poltica es un conjunto de reglas establecidas para gobernar un cierto aspecto del
comportamiento de una organizacin, concretamente describen qu debe hacerse para
alcanzar, por ejemplo, los objetivos de la organizacin.
Una Security Policy (Poltica de Seguridad, SP) describe objetivos, responsabilidades y
requisitos generales para la proteccin de recursos especficos (por ejemplo, algunos datos).
Las polticas de seguridad se implementan a travs de una combinacin de mecanismos y
procedimientos. Los mecanismos y procedimientos describen cmo se alcanzan los requisitos
de seguridad descritos en la poltica.
Una CP es un documento de alto nivel que describe una poltica de seguridad para emitir
certificados y mantenerlos. Describe las operaciones de CAs y sus componentes de soporte y
las responsabilidades de los usuarios al solicitar y usar los certificados. Una CP puede describir
el comportamiento de una nica CA y sus componentes de soporte, este es el caso cuando una
nica CA da servicio a una organizacin. Puede darse tambin el caso de que una nica CP
22

describa el comportamiento de mltiples CAs y sus componentes de soporte. Es el caso de

mltiples CAs mantenidas por una organizacin a travs de una PKI en malla. Tambin una CP
puede describir una o varias PKI jerrquicas.
Una CP tiene distintos usos. En primer lugar, se usa como gua para el desarrollo de los CPSs
de cada CA. Otras organizaciones revisarn la CP antes de hacer una cross-certificacin. Los
auditores de seguridad tomarn la CP como base de las auditoras. Los propietarios de una
aplicacin estudiarn la CP para determinar si los certificados son apropiados para la
aplicacin.
Un CPS es un documento con un alto grado de detalle que explica cmo una CA implementa
una CP especfica. Un CPS determina los procedimientos con los que se usarn productos
especficos. Un CPS incluye suficientes detalles operativos para demostrar que una CP se
satisface con una combinacin de mecanismos y procedimientos. Un CPS se aplica a una nica
CA y sus componentes de soporte y puede considerarse como el manual de operaciones de la
CA. Los auditores de seguridad usan los CPS como un complemento a las CP durante las
auditoras de seguridad. Sin embargo, un CPS no necesita ser publicado. Cada CP puede ser
implementada por muchos diferentes CPSs y un CPS puede cumplir los requisitos de ms de
una CP.

2.11. Desarrollo de una PKI

En esta seccin se pretende esbozar el guin que se debera seguir en la implantacin de una
PKI.
El primer paso en el desarrollo de una PKI consiste en comprender los objetivos de negocio y
los requisitos que provocan la necesidad de la implantacin de una PKI. Conviene revisar los
procesos de negocio y proponer una arquitectura para el sistema. El documento SP (Security
Policy, Poltica de Seguridad) de la organizacin debe ser una importante fuente de
informacin durante esta etapa. Con toda esta informacin se define el mbito y otros
parmetros significativos de la PKI.
Seguidamente se deben analizar las aplicaciones y los datos que la organizacin debe proteger
y evaluar las amenazas y riesgos a los que estn sujetos. Se debe considerar el impacto de un
compromiso de la seguridad;por ejemplo, el perjuicio que podra provocar la revelacin de
informacin confidencial a un competidor o el acceso incontrolado a datos financieros. En
ocasiones las leyes obligan a proteger los datos de los clientes y, en tal caso, una brecha en la
seguridad puede implicar sanciones y multas. La redaccin de una CP sin haber planteado
previamente estas cuestiones provocar ineludiblemente el fracaso del proyecto. La CP
tambin debe adecuarse a los datos y aplicaciones que debe proteger. Si la CP no es apropiada
ser demasiado cara o dejar datos crticos desprotegidos. Hay una correlacin entre el nivel
de seguridad y el coste de la PKI. Una CP muy segura requerir ms personal y procedimientos
ms complejos que una CP menos exigente.
Algunas veces puede ser necesario desarrollar ms de un documento CP, particularmente
cuando las transacciones que se desean proteger tienen requisitos de seguridad muy
diferentes. Pensar, por ejemplo, en una organizacin que deba mantener, por un lado, una
VPN para vendedores que facturen pequeos importes y, por otro, transacciones financieras de
millones de euros llevadas a cabo por los contables de la compaa. En estos casos la
organizacin tiene dos opciones: implementar dos polticas diferentes o soportar ambos tipos
de transacciones con la poltica ms estricta. La compaa debe comparar los costes y
beneficios de ambas estrategias y tomar una decisin.
Esta informacin tambin puede usarse para analizar los costes y beneficios de un seguro de
responsabilidad. La compaa puede contratar una pliza de seguro para cubrir las
responsabilidades que resulten de errores del personal de la PKI.

23

Antes de redactar el documento CP conviene proveerse de una copia de documentos CP de

otras organizaciones con objetivos similares. Tambin es til revisar los distintos apartados en
los que se divide el documento CP y determinar qu puntos son aplicables en nuestro entorno.
En general estos documentos son fciles de obtener ya que las organizaciones suelen
publicarlos.
Si se prev que la PKI se va a cross-certificar con PKIs de otras organizaciones, se deben
investigar los perfiles de certificados y CRLs que usan dichas PKIs. Hacer el perfil de nuestros
certificados y CRLs consistente con los de las otras organizaciones reducir los problemas de
compatibilidad posteriormente.
Se deben considerar aspectos como las extensiones crticas, algoritmos y los mtodos para
localizar informacin de revocacin.
Con todas estas consideraciones ya se est en condiciones de redactar uno o varios
documentos CPs adecuados para nuestra organizacin. En el ejemplo presentado
anteriormente de la compaa que debe proveer seguridad para contables y vendedores, los
contables pueden usar mdulos criptogrficos hardware validados contra FIPS 140-1 Level 2 o
superiores, mientras que el personal de ventas tendra suficiente con mdulos criptogrficos
software validados contra FIPS 140-1 Level 1. El documento CP puede requerir una
identificacin presencial cuando un contable obtiene sus credenciales, mientras que un correo
certificado puede ser suficiente para autenticar un vendedor.
El paso siguiente sera decidir si la propia organizacin opera la PKI o, simplemente, la
subcontrata. Para operar la PKI la compaa necesita una instalacin segura para sus
operaciones y una instalacin remota para almacenar backups. Si la organizacin no dispone
de estas instalaciones, su construccin puede ser muy costosa. En ocasiones puede ser
rentable realizar algunas operaciones de la PKI localmente y subcontratar las restantes. Por
ejemplo, las RAs y el directorio pueden operarse localmente, mientras que las operaciones de
CA pueden ser externalizadas. Si se decide operar la PKI, a continuacin se deben seleccionar
los productos que pueden usarse para implementar la poltica.
Diferentes productos PKI se disean con diferentes objetivos. La cuestin clave es seleccionar
productos que implementen la poltica de seguridad redactada en el documento CP. Si los
productos no soportan los objetivos del documento CP, se debern disear procedimientos
complejos para soslayar los inconvenientes de los productos con el consiguiente
encarecimiento del mantenimiento de la PKI.
Los estudios de costes se hallan estrechamente ligados con los pasos anteriores. Se pueden
realizar varios estudios de costes comparando diferentes productos y comparando la operacin
interna de la PKI con la externalizacin. Todo este proceso puede requerir varias pasadas
hasta conseguir disear una solucin PKI adecuada.
El paso final de la documentacin consiste en redactar los documentos CPSs. Si la propia
organizacin va a operar las CAs, los CPSs deben indicar la ubicacin que se usar. Los CPSs
adems especifican cmo se usan los controles proporcionados por los productos PKI para
cumplir los objetivos descritos en el documento CP. Si, por el contrario, se externalizan los
servi cios, el proveedor del servicio ya tendr probablemente escrito el documento CPS y debe
demostrar que sus controles y procedimientos cumplen con la CP.
A continuacin, ya se est en condiciones de desplegar fsicamente la PKI en la organizacin.
Conviene comenzar por adiestrar el personal y realizar unas pruebas piloto con un pequeo
conjunto de usuarios. A menudo, estas experiencias iniciales resultan en revisiones de los
documentos CPSs. Limitando el conjunto inicial de usuarios se consigue que la mayora de
usuarios se beneficie de su experiencia. Una vez se ha conseguido el documento CPS definitivo
ya se puede inciar el despliegue masivo de la PKI.

24

ANEXO: NIVELES DE SEGURIDAD PARA MODULOS CRIPTOGRAFICOS DEL FIPS 140,

"Security Requirements for Cryptographic Modules"
1.1 Security Level 1
Security Level 1 provides the lowest level of security. It specifies basic security requirements
for a cryptographic module (e.g., the encryption algorithm must be a FIPS approved
algorithm), but it differs from the higher levels in several respects. No physical security
mechanisms are required in the module beyond the requirement for production-grade
equipment.
Examples of Level 1 systems include Integrated Circuit (IC) cards and add-on security
products. It is commonly felt that IC cards enhance the security of most systems. IC cards
may be used as a secure storage medium when distributing cryptographic keys and may also
implement cryptographic algorithms. Many vendors produce personal computer (PC)
encryption boards which will meet the Level 1 requirements. NIST has validated the correct
implementation of NIST cryptographic standards in several IC cards and encryption boards.
Level 1 allows software cryptographic functions to be performed in a general purpose personal
computer (PC). NIST believes that such implementations are often appropriate in low-level
security applications. The implementation of PC cryptographic software may be more costeffective than hardware-based mechanisms. This will enable agencies to avoid the situation
that exists today whereby the decision is often made not to cryptographically protect data
because hardware is considered too expensive.
1.2 Security Level 2
Security Level 2 improves the physical security of a Security Level 1 cryptographic module by
adding the requirement for tamper evident coatings or seals, or for pick-resistant locks.
Tamper evident coatings or seals, which are available today, would be placed on a
cryptographic module so that the coating or seal would have to be broken in order to attain
physical access to the plaintext cryptographic keys and other critical security parameters
within the module. Pick-resistant locks would be placed on covers or doors to protect against
unauthorized physical access. These requirements provide a low cost means for physical
security and avoid the cost of the higher level of protection involving hard opaque coatings or
significantly more expensive tamper detection and zeroization circuitry.
Level 2 provides for role-based authentication in which a module must authenticate that an
operator is authorized to assume a specific role and perform a corresponding set of services.
Level 2 also allows software cryptography in multi-user timeshared systems when used in
conjunction with a C2 or equivalent trusted operating system. The ratings C2, B1 and B2
ratings are in accordance with the TCSEC (see Appendix C). Many security experts feel that a
trusted operating system is needed in order for software cryptography to be implemented with
a level of trust comparable to hardware cryptography. This enables multi-user timeshared
systems to implement cryptographic functions in software when this level of security is cost
effective.
1.3 Security Level 3
Security Level 3 requires enhanced physical security which is generally available in many
existing commercial security products. Unlike Security Level 2 which employs locks to protect
against tampering with a cryptographic module, or employs coatings or seals to detect when
tampering has occurred, Level 3 attempts to prevent the intruder from gaining access to
critical security parameters held within the module. For example, a multi-chip embedded
module must be contained in a strong enclosure, and if a cover is removed or a door is
opened, the critical security parameters are zeroized. As another example, a module must be
enclosed in a hard, opaque potting material to deter access to the contents.

25

Level 3 provides for identity-based authentication, which is stronger than the role basedauthentication used in Level 2. A module must authenticate the identity of an operator and
verify that the identified operator is authorized to assume a specific role and perform a
corresponding set of services.
Level 3 provides stronger requirements for entering and outputting critical security
parameters. The data ports used for critical security parameters must be physically separated
from other data ports. Furthermore, the parameters must either be entered into or output
from the module in encrypted form (in which case they may travel through enclosing or
intervening systems) or be directly entered into or output from the module (without passing
through enclosing or intervening systems) using split knowledge procedures.
Level 3 allows software cryptography in multi-user timeshared systems when a B1 or
equivalent trusted operating system is employed along with a trusted path for the entry and
output of critical security parameters. A B1 or better trusted operating system with a trusted
path would have the capability to protect cryptographic software and critical security
parameters from other untrusted software that may run on the system. Such a system could
prevent plaintext from being mixed with ciphertext, and it could prevent the unintentional
transmission of plaintext keys.
1.4 Security Level 4
Security Level 4 provides the highest level of security. Although most existing products do not
meet this level of security, some products are commercially available which meet many of the
Level 4 requirements. Level 4 physical security provides an envelope of protection around the
cryptographic module. Whereas the tamper detection circuits of lower level modules may be
bypassed, the intent of Level 4 protection is to detect a penetration of the device from any
direction. For example, if one attempts to cut through the enclosure of the cryptographic
module, the attempt should be detected and all critical security parameters should be zeroized.
Level 4 devices are particularly useful for operation in a physically unprotected environment
where an intruder could possibly tamper with the device.
Level 4 also protects a module against a compromise of its security due to environmental
conditions or fluctuations outside of the module's normal operating ranges for voltage and
temperature. Intentional excursions beyond the normal operating ranges could be used to
thwart a module's defense during an attack. A module is required to either include special
environmental protection features designed to detect fluctuations and zeroize critical security
parameters, or to undergo rigorous environmental failure testing that provides a reasonable
assurance that the module will not be affected by fluctuations outside of the normal operating
range in a manner that can compromise the security of the module.
Level 4 allows software cryptography in multi-user timeshared systems when a B2 or
equivalent trusted operating system is employed. A B2 trusted operating system provides
additional assurances of the correct operation of the security features of the operating system.

26