PKI Aplicada V1.3

1st Peruvian Workshop on IT Security
29.Dic.2003

Colaboración
PKI aplicada
Roger Carhuatocto
http://escert.upc.es

Miembro esCERT -UPC
Responsable de Servicios Educacionales

Instituto de Investigación UNI -FIIS
http://www.uni.edu.pe esCERT-UPC
C/ Jordi Girona, 1-3. Campus Nord, UPC
08034 Barcelona ~ España
Tel. (34)934015795 ~ Fax. (34)934017055
1

Servicio de seguridad

Confidencialidad, sólo autorizados acceden a la información
Integridad, asegurar la no alteración
Autenticación, corroborar la identidad
Autenticación de mensajes, conocer el origen del mensaje
Firma, ligar identidad con información
Autorización, permiso de acceso a recursos
Validación, evento (limitada en tiempo y espacio) de autorización
Control de acceso, ingreso privilegiado
Certificación, aval de entidad de confianza
Testificación, aval extra de una entidad ajena a la primaria )
Sello de Tiempo (TIME STAMPING), registro de tiempo de un evento
Recibo, constancia de entrega para el emisor
Título de propiedad (OWNERSHIP), transferencia legal de un derecho de uso
Anonimicidad, la no relación de una identidad con una entidad
No repudio, prevenir negación de actos realizados
Revocación, cese de certificación

2
PKI Aplicada / Roger Carhuatocto
2 WALC 2003 - VI ESCUELA LATINOAMERICANA DE REDES

Servicios de Seguridad

Las amenazas se reducen implantando Servicios de
Seguridad

Los servicios de seguridad están basados sistemáticamente
en el uso de técnicas criptográficas .

3

Infraestructura. ¿Por qué?.

Usuarios necesitan claves públicas de otros usuarios.
¿Cómo se accede a claves públicas de otros
usuarios?.
Se debería disponer de una base de datos de clave
públicas asociadas a identidades de los usuarios que
las poseen.
Los usuarios accederían a la BDs y obtendrían las
claves necesarias.

4

Infraestructura. Conclusión

Amenaza:
Si se trata de una BD de acceso público, podría ser fácil cambiar sus
contenidos, por ejemplo, cambiar la identidad asociada a una cla ve
pública o viceversa.
Solución:
Asegurar los depósitos de claves (seguridad no absoluta)
Asegurar las asociaciones claves públicas- identidades (Certificados
digitales).
La BDs resultante “garantiza” (acto de fe/confianza) que una
determinada clave pública pertenece a un determinado usuario.

5

Certificado y CA

1. Da garantía: Firma digitalmente la
relación clave pública e identidad
Autoridad de
Certificación (CA) del poseedor de la clave.
2. Dicha relación se añade a la
Almacén estructura del CERTIFICADO
seguro 3. Gestiona la estructura de
información (CERTIFICADO)

CERTIFICADO
• La clave pública.
• La identidad del poseedor.
• La identidad de la CA. NO HAY INFORMACIÓN
• Una fecha de validez para esta CONFIDENCIAL.
asociación.
• Firma digital (para protegerlo de
manipulaciones malintencionadas)

6

Certificado y CA

Autoridad de 1. Da garantía: Firma digitalmente la
Certificación (CA) relación/asociación clave pública e
identidad del poseedor de la clave.
Almacén 2. Dicha relación se añade a la
seguro estructura del CERTIFICADO
3. Gestiona la estructura de
información (CERTIFICADO)

CERTIFICADO
• La clave pública.
• La identidad del poseedor.
• La identidad de la CA.
• Una fecha de validez para esta NO HAY INFORMACIÓN
asociación. CONFIDENCIAL.
• Identificación de la asociación
• Firma digital (para protegerlo de
manipulaciones malintencionadas)
• Versión del formato
• Algoritmos usados en firma y hash
7

Certificado, Firma y cifrado
Alice descarga el certificado de Bob del almacén seguro
Alice firma el mensaje con su Kpriv, usará la Kpub de Bob si envía dicho mensaje de
forma cifrada
Bob verifica la firma electrónica del mensaje y luego el certificado del remitente
Autoridad de
Certificación (CA)

Almacén
seguro

KAlice pública
KAlice privada

Verificación
de Firma SI?
Digital
Firma
Digital

8

Validación de mensajes firmados

Validación de mensaje + Validación Certificado
Verificar la validez del certificado del remitente.
Existencia del certificado
Dentro del período de validez.
Certificado no revocado.
Firma electrónica de la CA correcta.
Verificar la firma electrónica del mensaje con la clave pública del
remitente
Es necesario que el destinatario y el remitente pertenezcan al mismo
circulo de confianza, es decir que ambas claves pública deben estar en
“posesión” de una misma CA

9

Infraestructura. Ldap

Un lugar idóneo para guardar certificados es la base de datos
distribuida X.500 (directorio).
X.500 asocia una entrada de una base de datos distribuida y
organizada jerárquicamente según un árbol, a cada agente del
sistema.
Cada usuario puede depositar su certificado en su entrada del
directorio y el resto de usuarios puede acceder a dicha
entrada y recogerlo.

10

Infraestructura. Ldap
Autoridad de
Certificación (CA)

Almacén
seguro

X.500

Usuario A Usuario B

11

Ldap

CA Raíz
X.500: Estructura de directorios
jerárquica.
Cada entrada se etiqueta con un CA Sub A CA Sub B
Nombre Distintivo (Distinguished
Name -DN-).
Un DN contiene valores de atributos: CA Sub A.1

País
C=PE C=ES
Organización
Unidad organizativa O=UNI-FIIS
Nombre de usuario OU=ACME

CAs y usuarios pueden depositar sus CN=Roger Carhuatocto
certificados en el directorio X.500

12

Certificados y CRLs

Los certificados tienen una vida limitada. Al finalizar el período de validez,
expiran.
Un certificado puede dejar de ser válido por varios motivos (REVOCADO):
Si se sospecha que alguien ha tenido acceso a la clave privada, debe
revocarse el certificado con la correspondiente clave pública.
Cuando el poseedor de un certificado cambia de empresa su DN no es
válido.
En tales casos, la CA debe realizar las operaciones necesarias para
REVOCAR el certificado.
Una alternativa es disponer de Listas Firmadas (CRL) por la CA en las que se
incluyan los certificados generados y revocados por ella o referencias a éstos.
Estas listas pueden depositarse en la entrada de la CA en el directorio X.500.

13

Certificados, CRLs y verificación

La verificación de un certificado implicará pues, la
inspección de estas listas por ver si el certificado en cuestión
está o no revocado.
Proceso:
Recepción de mensaje firmado.
Acceso a X.500 para recoger certificado de usuario.
Comprobación de que no está revocado.
Si el certificado NO ha sido expedido por una CA conocida,
ír hacia arriba en el árbol de X.500 hasta dar con una en la
que confiemos.
14

Conclusiones

En sistemas complejos: jerarquías de CAs.
Necesidad de verificar secuencias de certificados de CAs hasta llegar al
de una CA en la que se confíe.
Usuarios y CAs intercambiarán mensajes de gestión de certificados
(para solicitar certificados, entregarlos, solicitar revocación,
confirmarla, etc.).
Al hablar de infraestructura pues, estamos refiriéndonos a agentes
presentes, mensajes intercambiados y “reglas de juego”:
Servicios, plataformas, algoritmos, normas, protocolos,
responsabilidades, estructutras

15

Certificado X.509

Definición en ASN.1. Codificación DER.

Certificate ::= SIGNED SEQUENCE {
version [0] Version DEFAULT v1,
serialNumber CertificateSerialNumber ,
signature AlgorithmIdentifier ,
issuer Name,
validity Validity,
subject Name,
subjectPublicKeyInfo SubjectPublicKeyInfo,
issuerUniqueId [1] IMPLICIT UniqueIdentifier OPTIONAL,
subjectUniqueI [2] IMPLICIT UniqueIdentifier OPTIONAL,
extensions [3] Extensions OPTIONAL }

16

Certificado Reconocido (Qualified Cert.)

Tipo de certificados que debe usarse para generar Firmas
Electrónicas Avanzadas (según la Directiva Europea)
Es un perfil de certificado definido a partir del formato
X.509, en el que se describen una serie de Extensiones que
deben aparecer obligatoriamente.

17

Certificado Reconocido (Qualified Cert.)

Definición en ASN.1. Codificación DER.

Certificate ::= SIGNED SEQUENCE {
version [0] Version DEFAULT v1,
serialNumber CertificateSerialNumber ,
signature AlgorithmIdentifier ,
issuer Name,
validity Validity,
subject Name,
subjectPublicKeyInfo SubjectPublicKeyInfo,
issuerUniqueId [1] IMPLICIT UniqueIdentifier OPTIONAL,
subjectUniqueI [2] IMPLICIT UniqueIdentifier OPTIONAL,
extensions [3] Extensions OPTIONAL }
AuthorityKeyId
SubjectKeyId
KeyUsage
CertPolicies
CRLDistributionPoint

18

Public Key Cryptography Standards

Necesidad de estándares: asegurar la INTEROPERABILIDAD entre aplicaciones que
aplican Criptografía de Clave Pública, desarrolladas por fabricantes diferentes.
Desarrollados por RSA Security y fabricantes (Microsoft, Sun, Apple, etc)
Qué se ha estandarizado?:
la sintaxis de los mensajes
los algoritmos
Qué asuntos quedan abiertos, a criterio del desarrollador

19

Public Key Cryptography Standards
Public-Key Cryptography Standards
http://www.rsasecurity.com/rsalabs/pkcs/index.html

20

Aplicaciones. email

Autenticación del Origen
Integridad del Contenido
Confidencialidad del Contenido
No Repudio del Origen
PEM (Privacy enhancen mail) fue la primera propuesta realizada en
Internet para asegurar mensajes de correo electrónico haciendo uso de
firmas digitales y certificados X.509. No tuvo éxito porque no era
compatible con MIME. Sólo permite firma y cifrado de parte del mail
S/MIME (Multipurpose Internet Mail Extensions ), igual que anterior,
soporte MIME
PGP J

21

Aplicaciones. Web seguro

Firma de formularios, Firma de páginas web, Firma de código
Autenticación
SSL
Desarrollado por Netscape Communications Corp.
Permite proteger cualquier comunicación de cualquier aplicación que opere sobre
TCP (http, FTP, Telne, cualquier tunel SSL)
Ofrece servicios de Seguridad para Sesiones entre cliente/servidor
Autenticación del Servidor
Autenticación del Cliente
Integridad del Contenido transferido
Confidencialidad

22

Aplicaciones. Transacciones seguras

Pasarelas/medios de pago
e-commerce, e-business, m-commerce
e-gambling, e-voting (avanzada)
Firma y cifrado con XML, web services
Autenticación: SSO, Kerberos
Tokens : SmartCards de memoria y criptográfica, JavaCards

23

PKI: Ejemplos

Autoridades de Certificación
OpenCA – http://www.openca.org
Linux, GPL, basado en OpenSSL, Apache, Perl, MySQL y Ldap
NewPKI – http://www.newpki.org
Windows, GPL, C/C++, desarrollo propietario, MySQL y Ldap
EJBCA – http://ejbca.sourceforge.net
Multiplataforma(Java), basada en API Criptográfico de Java, J2EE/Jboss,
MySQL y Ldap
BDs y Ldap
MySQL – http://www.mysql.org
Postgres – http://www.postgres.org
OpenLdap – http://www.openldap.org
Servidores web, application server
Apache – http://www.apache.org
JBoss – http://www.jboss.org 24

June 2003 Survey on PKI Obstacles
Objetivo
Identificar principales obstáculos para el despliegue y uso
de PKI
Cómo
Web-based survey deployed June 9 to 22, 2003 (OASIS)
Invitation distributedthrough PKI standards bodies, trade
groups, user associations, etc.
Encuestados
216 valid responses, many with careful text comments
44% IT management and staff, remainder developers,
consultants, etc.
PrimaryWork Location: 61% North America, 24%
Europe, 6% Asia
Over 75% with 5 or more years experience in
InfoSec/Privacy
90% either helped deployPKI or developedPKI-related
software

Ver encuesta
http://www.ietf.org/proceedings/03nov/slides/pkix-2/pkix-2.ppt
25

PKI Aplicada V1.3

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Ähnlich wie PKI Aplicada V1.3

Ähnlich wie PKI Aplicada V1.3 (20)

Mehr von Roger CARHUATOCTO

Mehr von Roger CARHUATOCTO (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (10)

PKI Aplicada V1.3