Implementacion Pki Plataformas Moviles PDF

INSTITUTO TECNOLÓGICO Y DE ESTUDIOS
SUPERIORES DE MONTERREY
Escuela de Graduados de Ingenieria y Arquitectura

Maestrı́a en Ciencias Computacionales
“Diseño e Implementación de una Autoridad

Certificadora en Plataformas Móviles”
Tesis presentada por
Guillermo Martı́nez Silva
para obtener el grado de Maestro
en Ciencias Computacionales
Director de tesis:
Dr. Francisco Rodrı́guez Henrı́quez
México D.F. verano de 2005

INSTITUTO TECNOLÓGICO Y DE ESTUDIOS
SUPERIORES DE MONTERREY
Escuela de Graduados de Ingenieria y Arquitectura

Maestrı́a en Ciencias Computacionales
“Diseño e Implementación de una Autoridad

Certificadora en Plataformas Móviles”
Tesis presentada por

para obtener el grado de Maestro
en Ciencias Computacionales
Comisión de tesis:
Nombre del Presidente

Presidente
Nombre Sinodal I
Sinodal
Nombre Sinodal II
Sinodal
México D.F. junio de 2005

Tesis sustentada por
para obtener el grado de
Maestro en Ciencias Computacionales.
Dr. Nombre del Presidente

Presidente
Dr. Nombre Sinodal I Dr. Nombre Sinodal II

Sinodal Sinodal
Dr. Francisco Rodrı́guez Dra. Patricia Rayón Villela

Henrı́quez Director del Programa de
Titular de la Materia Maestrı́a
3 de junio de 2005
i
Agradecimientos
Gracias a todos los que hicieron esto posible.

Dedicatoria
texto
Resumen
El presente trabajo implementa una Autoridad Certificadora en un dispositivo móvil
PDA(Asistente Personal Digital) con la particularidad de incluir información biométri-
ca de huella digital en los campos de extensión de un certificado digital basado en el
estándar X.509 V3. Los criptosistemas empleados para la generación de certificados son
RSA (1024 bits) y ECC (criptografı́a de curva elı́ptica) utilizando las curvas 163k, 192p,
224p, 233k.
iv
Índice general
Agradecimientos II
Dedicatoria III
Resumen IV
Introducción 1
1. Criptografı́a de llave pública y funciones hash 3
1.1. Principios de criptosistemas basados en llave pública . . . . . . . . . . 6
1.2. Intercambio de llaves Diffie-Hellman . . . . . . . . . . . . . . . . . . . . 9
1.3. Criptosistema RSA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.4. Criptografı́a de curva elı́ptica ECC . . . . . . . . . . . . . . . . . . . . 11
1.4.1. Grupos de curva elı́ptica sobre R . . . . . . . . . . . . . . . . . 12
1.4.2. Grupos de curva elı́ptica sobre Fp . . . . . . . . . . . . . . . . . 15
1.4.3. Grupos de curva elı́ptica sobre F2m . . . . . . . . . . . . . . . . 18
1.4.4. Criptosistema basado en ECC . . . . . . . . . . . . . . . . . . . 20
1.5. Funciones hash . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
1.6. Aplicaciones de criptosistemas de llave pública . . . . . . . . . . . . . . 23
1.6.1. Autenticación . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
1.6.2. Intercambio de llaves . . . . . . . . . . . . . . . . . . . . . . . . 24
v
ÍNDICE GENERAL vi
1.6.3. Confidencialidad . . . . . . . . . . . . . . . . . . . . . . . . . . 25
1.6.4. No-repudio y firmas digitales . . . . . . . . . . . . . . . . . . . . 25
1.6.5. Integridad de datos . . . . . . . . . . . . . . . . . . . . . . . . . 27
2. Servicio de autenticación 28
2.1. Servicios de seguridad informática en ambientes inalámbricos . . . . . . 30
2.2. Ataques a la autenticación de entidades . . . . . . . . . . . . . . . . . . 32
2.2.1. Ataque del intruso de en medio . . . . . . . . . . . . . . . . . . 32
2.2.2. Usurpación de identidad . . . . . . . . . . . . . . . . . . . . . . 32
2.3. Métodos de autenticación . . . . . . . . . . . . . . . . . . . . . . . . . 33
2.3.1. Autenticación mediante entidades de confianza . . . . . . . . . . 33
2.3.2. Autenticación biométrica . . . . . . . . . . . . . . . . . . . . . . 36
3. PKI (Infraestructura de llave pública) 39
3.1. Introducción a PKI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.2. Componentes PKI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
3.2.1. Autoridades Certificadoras (ACs) . . . . . . . . . . . . . . . . . 44
3.2.2. Autoridad de Registro (AR) . . . . . . . . . . . . . . . . . . . . 46
3.2.3. Repositorio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
3.2.4. Emisor CRL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
3.2.5. Entidades Finales . . . . . . . . . . . . . . . . . . . . . . . . . . 47
3.3. Arquitecturas PKI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
3.4. Estructuras de datos PKI . . . . . . . . . . . . . . . . . . . . . . . . . 50
3.4.1. Certificados X.509 . . . . . . . . . . . . . . . . . . . . . . . . . 50
3.4.2. Listas de revocación de certificados . . . . . . . . . . . . . . . . 53
3.5. Servicios adicionales PKI . . . . . . . . . . . . . . . . . . . . . . . . . . 57

ÍNDICE GENERAL vii
4. Implementación del sistema 58
4.1. Descripción del sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
4.2. Arquitectura de la aplicación . . . . . . . . . . . . . . . . . . . . . . . . 60
4.2.1. Dispositivo móvil . . . . . . . . . . . . . . . . . . . . . . . . . . 60
4.2.2. Biblioteca criptografı́ca RCT . . . . . . . . . . . . . . . . . . . . 61
4.2.3. Biblioteca biométrica BioAPI . . . . . . . . . . . . . . . . . . . 63
4.2.4. Biblioteca ASN.1 y estándar X.509v3 . . . . . . . . . . . . . . . 66
4.3. Proceso de generación de un certificado digital . . . . . . . . . . . . . . 68
4.4. Proceso de verificación de un certificado digital . . . . . . . . . . . . . 69
5. Análisis de desempeño 72
5.1. Resultados obtenidos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
5.1.1. Generación de llaves . . . . . . . . . . . . . . . . . . . . . . . . 73
5.1.2. Firma digital . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
5.1.3. Verificación de firma digital . . . . . . . . . . . . . . . . . . . . 74
5.1.4. Tamaño de certificados digitales . . . . . . . . . . . . . . . . . . 74
5.2. Análisis de resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
5.2.1. Generación de llaves . . . . . . . . . . . . . . . . . . . . . . . . 76
5.2.2. Firma digital . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
5.2.3. Verificación de firma digital . . . . . . . . . . . . . . . . . . . . 77
5.2.4. Tamaño de certificados digitales . . . . . . . . . . . . . . . . . . 77
Conclusiones 80
A. ASN.1 (Abstract Syntax Notation One) 83
A.1. Tipos de datos básicos en ASN.1 . . . . . . . . . . . . . . . . . . . . . 85
A.1.1. Tipo BOOLEAN . . . . . . . . . . . . . . . . . . . . . . . . . . 85

ÍNDICE GENERAL viii
A.1.2. Tipo INTEGER . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
A.1.3. Tipo ENUMERATED . . . . . . . . . . . . . . . . . . . . . . . 86
A.1.4. Tipo OCTET STRING . . . . . . . . . . . . . . . . . . . . . . . 86
A.1.5. Tipo BIT STRING . . . . . . . . . . . . . . . . . . . . . . . . . 87
A.1.6. Tipo IA5String . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
A.1.7. Tipo PrintableString . . . . . . . . . . . . . . . . . . . . . . . . 87
A.1.8. Tipo UTCTime . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
A.1.9. Tipo OID (OBJECT IDENTIFIER) . . . . . . . . . . . . . . . 88
A.2. Estructura de datos construidos . . . . . . . . . . . . . . . . . . . . . . 89
A.2.1. Tipo SEQUENCE . . . . . . . . . . . . . . . . . . . . . . . . . 89
A.2.2. Tipo SEQUENCE OF . . . . . . . . . . . . . . . . . . . . . . . 89
A.2.3. Tipo SET . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
A.2.4. Tipo CHOICE . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
A.3. Descripción de la sintaxis ASN.1 de un certificado X.509 V3 . . . . . . 90
A.3.1. Tipo tbsCertificate . . . . . . . . . . . . . . . . . . . . . . . . . 90
A.3.2. Tipo signatureAlgorithm . . . . . . . . . . . . . . . . . . . . . . 92
A.3.3. Tipo signatureValue . . . . . . . . . . . . . . . . . . . . . . . . 92
B. Ejemplos de certificados X.509v3 93
B.1. Certificado RSA sin datos biométricos . . . . . . . . . . . . . . . . . . 93
B.2. Certificado ECC con datos biométricos . . . . . . . . . . . . . . . . . . 99
C. Funcionamiento del sistema 108
C.1. Descripción de la interfaz gráfica . . . . . . . . . . . . . . . . . . . . . 109
C.1.1. Pantalla de Datos . . . . . . . . . . . . . . . . . . . . . . . . . . 110
C.1.2. Pantalla de Biometric . . . . . . . . . . . . . . . . . . . . . . . . 110
C.1.3. Pantalla de RSA . . . . . . . . . . . . . . . . . . . . . . . . . . 112

ÍNDICE GENERAL ix
C.1.4. Pantalla de ECC . . . . . . . . . . . . . . . . . . . . . . . . . . 113
C.1.5. Pantalla de Verificación . . . . . . . . . . . . . . . . . . . . . . 113
C.2. Generación de certificados X.509 v3 . . . . . . . . . . . . . . . . . . . . 115
Referencias 116
Índice alfabético 122

Índice de tablas
2.1. Diferentes tipos de autenticación y sus propiedades . . . . . . . . . . . 29
4.1. iPAQ Pocket PC - Tasa de Falsos Positivos y Falsos Negativos . . . . . 66
5.1. Tiempo de generación de llaves. . . . . . . . . . . . . . . . . . . . . . . 73
5.2. Tiempos requeridos para firma digital de un mensaje aleatorio de 1KB. 74
5.3. Verificación de la fima digital de un mensaje de 1KB. . . . . . . . . . . 74
5.4. Comparación de tamaño en bytes de los certificados X.509 v3 . . . . . 75
B.1. Explicación de la sintaxis ASN.1 de un certificado RSA sin información
biométrica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
B.2. Explicación de la sintaxis ASN.1 de un certificado ECC con información
biométrica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
C.1. Caracterı́sticas principales del dispositivo móvil iPAQ h5550. . . . . . . 108
x
Índice de figuras
1.1. Confidencialidad en sistemas de llave secreta . . . . . . . . . . . . . . . 5
1.2. Primitivas de los criptosistemas de llave pública . . . . . . . . . . . . . 7
1.3. Confidencialidad en criptosistemas de llave pública . . . . . . . . . . . 8
1.4. Adición de puntos sobre R . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.5. Doblado de puntos sobre R . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.6. Curva elı́ptica y 2 = x3 + x sobre F23 . . . . . . . . . . . . . . . . . . . . 16
1.7. Esquema de firma y veriificación digital . . . . . . . . . . . . . . . . . . 26
2.1. Ataque del “intruso de en medio” al protocolo Diffie-Hellman . . . . . 32
2.2. Autenticación a través de una tercera parte de confianza . . . . . . . . 34
3.1. Componentes PKI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.2. Arquitecturas PKI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
3.3. Certificado digital X.509 versión 3 . . . . . . . . . . . . . . . . . . . . 54
3.4. Estructura de una CRL . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
4.1. Diagrama a bloques de la aplicación . . . . . . . . . . . . . . . . . . . . 60
4.2. Módulos ECDSA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
4.3. Obtención de llave privada . . . . . . . . . . . . . . . . . . . . . . . . . 62
4.4. Obtención de parámetros de generación del certificado digital . . . . . . 69
xi
ÍNDICE DE FIGURAS xii
4.5. Firma digital del certificado . . . . . . . . . . . . . . . . . . . . . . . . 69
4.6. Generación del certificado digital X.509 . . . . . . . . . . . . . . . . . . 70
4.7. Separación de las estructuras básicas de un certificado digital . . . . . . 70
4.8. Verificación del certificado digital . . . . . . . . . . . . . . . . . . . . . 71
5.1. Tiempos requeridos para la generación de llaves en Curva Elı́ptica. . . . 76
5.2. Generación de firma digital de un mensaje de 1KB. . . . . . . . . . . . 77
5.3. Comparación en verificación de firma digital . . . . . . . . . . . . . . . 78
5.4. Comparación de certificados con y sin información biométrica . . . . . 79
C.1. Pantalla principal de la aplicación . . . . . . . . . . . . . . . . . . . . . 109
C.2. Llenado de datos de la entidad final . . . . . . . . . . . . . . . . . . . . 110
C.3. Selección del periódo de validez del certificado . . . . . . . . . . . . . . 111
C.4. Opciones de la pantalla de Datos . . . . . . . . . . . . . . . . . . . . . 111
C.5. Captura de huella digital . . . . . . . . . . . . . . . . . . . . . . . . . . 112
C.6. Generación del certificados RSA . . . . . . . . . . . . . . . . . . . . . . 113
C.7. Generación de certificados ECDSA . . . . . . . . . . . . . . . . . . . . 114
C.8. Selección de certificados almacenados en la PDA . . . . . . . . . . . . . 114
C.9. Verificación de certificados emitidos por la AC . . . . . . . . . . . . . . 115

Introducción
La utilización masiva de las computadoras y redes como medios para almacenar,
transferir y procesar información se ha incrementado espectacularmente en los últimos
años, al grado de convertirse en un elemento indispensable para el funcionamiento de
la sociedad actual. Como consecuencia, la información en todas sus formas y estados
se ha convertido en un activo de considerable valor, el cual se debe proteger y asegurar
para garantizar su integridad, confidencialidad y disponibilidad, entre otros servicios de
seguridad.
Actualmente se ha incrementado en nuestro paı́s el uso de aplicaciones electrónicas
que abarcan: correo, comercio, transacciones, acceso seguro a bancos de información,
comunicaciones seguras, entre otras. Por tal motivo, los requerimientos de seguridad
son cada vez mayores, presentándose ası́ un problema que la Seguridad Informática,
haciendo uso fundamentalmente de técnicas criptográficas, trata de resolver implemen-
tando diversas servicios de seguridad.
Desgraciadamente los avances tecnológicos también han propiciado la proliferación de
fraudes y robo de información vı́a electrónica. Debido a esto es necesario ofrecer tecno-
logı́as para asegurar la información que viaja electrónicamente en Internet. Actualmente
los certificados digitales ofrecen autenticación con cierto grado de confiabilidad, ya que
se basan en dos caracterı́sticas muy importantes:
1
Introducción 2
Algo que el usuario sabe (una contraseña)
Algo que el usuario tiene (su llave pública)
El presente trabajo se enfoca a resolver algunos de los aspectos necesarios para
que un sistema de comercio electrónico tenga las herramientas necesarias para brindar
servicios indispensables de seguridad y primordialmente fortalecer la autenticación de
usuarios mediante el uso de información biométrica.

Capı́tulo 1
Criptografı́a de llave pública y

funciones hash
El comercio electrónico es un campo de rápido crecimiento en la Internet. Existen
varias difierencias entre el comercio en el mundo real y el comercio en lı́nea, y quizás
el aspecto más fundamental es la confianza y la seguridad. Un consumidor camina a
la tienda y compra bienes, se presenta fı́sicamente, se identifica y elige la forma de
pago. Pero en el comercio electrónico ambas partes, el comprador y el vendedor tienen
dificultades para probar la identidad de su contraparte. ¿Cómo puede un comprador
estar seguro de transmitir información de manera confidencial al vendedor? ¿Cómo sabe
un vendedor si una orden de compra es legı́tima? ¿Cómo pueden saber ambas partes si
una tercera entidad copia o modifica la información de la transacción? Estas preguntas
y muchas otras describen los aspectos que afectan las transacciones electrónicas en las
redes de datos.
Para construir aplicaciones seguras de comercio electrónico, es necesario establecer
varios requerimientos de seguridad. A continuación se listan los requerimientos funda-
mentales para la seguridad de la información en los sistemas de comercio electrónico.
1. Confidencialidad. Las entidades no autorizadas no podrán tener acceso a la
información protegida del sistema.
3
CAPÍTULO 1. CRIPTOGRAFÍA DE LLAVE PÚBLICA Y FUNCIONES HASH 4
2. Integridad de datos. La información no podrá ser alterada por entidades o
medios desconocidos.
3. Autenticación. Permite la verificación de la identidad de las partes involucradas
en la transacción.1
4. No-repudio. Este servicio previene el incumplimiento o desmentido de acciones
realizadas en la información por cualquier entidad en sistema.
Un sistema que implementa estos servicios de seguridad es considerado como seguro.
La herramienta computacional que estudia la implementación de los requerimientos
anteriores es la Criptografı́a, la cual puede ser definida como sigue:
Definición 1.1. La Criptografı́a es el estudio de técnicas matemáticas relacionadas
a los aspectos de seguridad de la información tales como confidencialidad, integridad
de datos, autenticación y no-repudio.
Los criptosistemas convencionales basados en criptografı́a simétrica o sistemas de
llave secreta requieren que el remitente y el destinatario compartan una llave la cual
solamente ellos deben de conocer. El conocimiento de esta llave permite el decifrado del
texto, de ahı́ la razón de que la llave permanezca en secreto. La figura §1.1 muestra el
proceso de cifrado y descifrado en un sistema simétrico.
El algoritmo más comunmente utilizado en sistemas de llave secreta es DEA (Data
Encryption Algorithm) definido en el estándar DES 2 (Data Encryption Standar ). Otros

1
Este servicio contempla diferentes variantes (autenticación de entidad, de mensaje, de llave, etc.)
las cuales serán explicadas en detalle en el capı́tulo §2.
2
El estándar DES tiene una longitud de llave de 56 bits. A pesar de ser considerado muy seguro en el
tiempo de su creación a mediados de 1970, los avances tecnológicos han asistido al desarrollo de técnicas
para romper las llaves en tiempos relativamente cortos. En 1999 un proyecto de cómputo distribuido
rompió DES en 22 horas y 15 minutos. En la actualidad DES no es considerado suficientemente robusto
para llaves de alta seguridad. Por esta razón se ideó Triple DES el cual ofrece el doble de seguridad
equivalente a 112 bits.
Llave Llave
secreta Mensaje secreta
cifrado
!"#$%¨*][Ñ[]_:@!
abcdefghijklmno abcdefghijklmno
"#$*][Ñ[]_:@!"#$
pqrstuvwxyz012 pqrstuvwxyz012
%&()=¨*][Ñ[]_:@!
3456789abcdefg 3456789abcdefg
"#$%&()=¨*][Ñ[]_
hijklmnopqrstuv hijklmnopqrstuv
:_,;[~!3432:@[Ñ[
wxyz012345678 wxyz012345678
]_:@![Ñ[]_:@![Ñ[
9abcdefghijklmn 9abcdefghijklmn
]_:@![Ñ[]_:@![Ñ[
opqrstuvwxyz01 opqrstuvwxyz01
]_:@![Ñ[]_:@! x3
Mensaje en
Mensaje en claro
claro
Algoritmo de Cifrado Algoritmo de Descifrado
(AES, DES, IDEA, etc.) (AES, DES, IDEA, etc.)
Figura 1.1: Confidencialidad en sistemas de llave secreta
esquemas incluyen Triple DES, AES3 , IDEA, RC4, RC5, Blowfish y Twofish. A pesar
que estos sistemas brindan una alta seguridad y eficiencia computacional, sufren de
muchas desventajas:
Distribución e intercambio de llaves. La llave debe de permanecer en secreto
y debe ser conocida por el remitente y el destinatario. Las dos partes involucradas
deben de tener gran cuidado en el intercambio para prevenir que la llave pueda
ser interceptada por una entidad no autorizada.4
Manejo de llaves. En el intercambio de información entre varias entidades,
existen muchas llaves a ser administradas. Para garantizar la seguridad, las llaves
deben ser cambiadas frecuentemente y preferentemente en cada sesión.
Debido a esto, los sistemas clásicos de llave secreta tienen grandes debilidades. Más
aún, los requerimientos de autenticación y no-repudio discutidos anteriormente son

3
Las llaves de AES pueden ser de 128, 192 ó 256 bits de longitud. A partir del año 2000 AES
ha venido sustituyendo paulatinamente a DES. Si existiera un generador de llaves que fuera capaz
de descubrir 1 llave DES cada segundo, este tardarı́a aproximadamente 149 mil billones de años en
encontrar una sola llave AES de 128 bits.
4
En un sistema de llave secreta con n usuarios se necesita un intercambio de n(n−1)
2 llaves para
que todas las entides puedan comunicarse unas con otras de manera confidencial.
imposibles de lograr en estos criptosistemas [Sch96]. Un parteaguas en la Criptografı́a
ocurrió en 1976 con la invención de la Criptografı́a de llave pública por parte de Diffie
y Hellman5 [DH76]. Esta invención resolvió no sólo el problema de la distribución y
manejo de llaves, también proporcionó las herramientas necesarias para los servicios de
autenticación y no-repudio.
1.1. Principios de criptosistemas basados en llave
pública
Los algoritmos de llave pública están basados en funciones matemáticas en lugar de
sustituciones o permutaciones. Y lo más importante, la Criptografı́a de llave pública es
asimétrica lo cual implica que existan dos llaves separadas, a diferencia de los algoritmos
de llave secreta en los cuales sólo existe una llave. El uso de las llaves tiene consecuencias
considerables en lo referente a los servicios de confidencialidad, no-repudio y autentica-
ción.
Los sistemas de llave pública requieren que cada usuario A tenga un par de llaves:
una llave pública, Kpub (A) la cual es publicada, y una llave privada Kprv (A) la cual es
mantenida en secreto. Un mensaje cifrado (con el conjunto de reglas E) usando una llave
pública, sólo puede ser descifrado (con el conjunto de reglas D) con su correspondiente
llave privada. Esto elimina la necesidad de compartir una llave secreta.
Las primitivas en criptosistemas de llave pública son las siguientes:
1. Generación de llaves. Esta primitiva crea las llaves publicas y privadas de los
usuarios.
5
Diffie y Hellman fueron los primeros en publicar los conceptos de criptografı́a de llave pública.
Sin embargo, en 1997 una agencia de seguirdad británica (CESG, National Technical Authority for
Information Assurance) dió a conocer documentos en los cuales se demuestra que en 1970, James Ellis
descubrió la criptografı́a de llave pública [Way97, TW01].
Criptografía de llave pública
Generación de Firma/Descifrado Verificación/Cifrado

llaves (operación privada) (operación pública)
Figura 1.2: Primitivas de los criptosistemas de llave pública
2. Operación pública. Utilizada para cifrar o verificar mensajes.
3. Operación privada. Utilizada para firmar o descifrar mensajes.
La Criptografı́a de llave pública permite la implementación de las tres primitivas
(figura §1.2); las cuales a su vez, permiten satisfacer los servicios fundamentales de la
seguridad informática (confidencialidad, integridad, autenticación, y no-repudio).
Supongamos que Alicia quiere enviar un mensaje m a Benito. Alicia usa la lla-
ve pública de Benito para cifrar el mensaje (operación pública, denotada como c =
EKpub (Benito) (m)) obteniendo como resultado c. Benito, una vez recibido el mensaje
cifrado c utiliza su llave privada para descifrar (operación privada, denotada como
m = EKprv (Benito) (c)), lo cual le permite recuperar el mensaje en claro m.
Para entender el concepto, se puede usar la analogı́a del sistema de correo. Nosotros
podemos enviar un correo a cualquier persona conociendo únicamente su dirección.
Una vez que el correo está en el buzón sólo el destinatario puede leerlo (asumiendo que
únicamente el destinatario puede abrir el buzón). La figura §1.3 muestra el esquema de
confidencialidad en sistemas de llave pública.
Teóricamente, los sistemas de llave pública pueden ser construidos utilizando fun-
ciones matemáticas especiales denominadas ”trapdoor one-way functions” (funciones de
sólo ida con pasadizo secreto).

Anillo de
llaves
publicas
Benito Carlos
Llave pública Llave privada

de de
Alicia Mensaje Alicia
cifrado
!"#$%¨*][Ñ[]_:@!
abcdefghijklmno abcdefghijklmno
"#$*][Ñ[]_:@!"#$
pqrstuvwxyz012 pqrstuvwxyz012
%&()=¨*][Ñ[]_:@!
3456789abcdefg 3456789abcdefg
"#$%&()=¨*][Ñ[]_
hijklmnopqrstuv hijklmnopqrstuv
:_,;[~!3432:@[Ñ[
wxyz012345678 wxyz012345678
]_:@![Ñ[]_:@![Ñ[
9abcdefghijklmn 9abcdefghijklmn
]_:@![Ñ[]_:@![Ñ[
opqrstuvwxyz01 opqrstuvwxyz01
]_:@![Ñ[]_:@! x3
Operación Pública Operación Privada

Mensaje en Mensaje en
claro Algoritmo de Cifrado claro
Algoritmo de Descifrado
(RSA, ECC)
(RSA, ECC)
Figura 1.3: Confidencialidad en criptosistemas de llave pública
Matemáticamente, una funcion f de sólo ida o en un sentido es aquella en la cual
f (x) es fácil de calcular para cualquier entrada x, pero el cálculo de f −1 (x) es extre-
madamente complicado. Una función de sólo ida con pasadizo secreto es en la cual
la función f −1 (x) es fácilmente calculable si se tiene cierta información adicional (una
puerta oculta “trapdoor”). Los siguientes dos problemas son considerados los candidatos
más comunes para la creación de funciones trapdoor one-way.
Problema de factorización de enteros: Dado un número entero n. Encon-
trar sus factores primos. Es decir, obtener n = p1 e1 p2 e2 p3 e3 · · · pk ek , donde pi es un
número primo y ei ≥ 1.
Encontrar números primos grandes6 es una tarea relativamente fácil, pero el pro-
blema de factorizar el producto de esos números primos es considerado compu-
tacionalmente no realizable para el estado del arte actual [RSA05].
Problema del logaritmo discreto: Dado un número primo p, un generador g
de Zp ∗ , y un elemento a ∈ Zp ∗ . Encuentre el número entero único i, 0 ≤ i < p − 1,

6
En este contexto un número grande es considerado como áquel que tiene al menos 512 bits.
tal que a ≡ g i (mod p). La utilidad del problema del logaritmo discreto en la
Criptografı́a es que encontrar logaritmos discretos es difı́cil. El método de fuerza
bruta para calcular g j (mod p) para 1 < j ≤ p−1 no es computacionalmente viable
para valores grandes de p. Sin embargo, la operación inversa de exponenciación
puede ser calculada eficientemente. De tal forma g i (mod p) es una función de sólo
ida con pasadizo secreto para valores convenientemente elegidos de p.
La mayorı́a de los criptosistemas de llave pública están basados en la dificultad
de resolver los problemas anteriores. En las siguientes secciones se describen imple-
mentaciones de criptosistemas de llave pública que son basados en los problemas de
factorización y logaritmo discreto.
1.2. Intercambio de llaves Diffie-Hellman
El propósito del algoritmo es permitir que dos usuarios intercambien llaves de una
manera segura con el objetivo de que la llave sea usada para un subsecuente cifrado
de mensajes. El algoritmo fundamenta su efectividad en la dificultad de calcular los
logaritmos discretos en el grupo Zp ∗ .
Supongamos que A y B desean establecer una secreto compartido en un canal no
seguro. Los pasos necesarios en el protocolo Diffie-Hellman son los siguientes:
1. Los parámetros p y α son seleccionados y publicados . donde p, es número primo
y α, es un elemento generador7 de Zp ∗ (2 ≥ α ≥ p − 2).
2. A elige un número aleatorio a, 0 ≤ a < p − 1.

7
El orden de un elemento g en un grupo G es definido como el entero positivo más pequeño m tal
que g m = 1. Un elemento g ∈ G cuyo orden n es igual al número de elementos no cero en G se dice
que es generador si y sólo si, su exponenciación repetitiva produce todos los elementos de grupo G.
3. B elige un número aleatorio b, 0 ≤ b < p − 1.
4. A calcula u = g a mod p, se envı́a u a B
5. B calcula v = g b mod p, se envı́a v a A
a
6. A calcula K = (g b ) mod p
7. B calcula K = (g a )b mod p
El resultado de este proceso es que A y B intercambiaron su llave secreta K de una
forma segura y manteniendo en secreto a y b.
1.3. Criptosistema RSA
El esquema RSA inventado por Ron Rivest, Adi Shamir, y Len Adleman fue de-
sarrollado en 1977 y publicado en 1978. RSA está basado en la idea de que factorizar
enteros en sus factores primos es un problema de alta complejidad. A continuación se
resume el algoritmo RSA.
La generación de llaves en RSA8 :
1. Se seleccionan dos números primos p, q
2. Se calcula el producto n = (p)(q) , n es llamado módulo
3. Se calcula φ(n) = (p − 1)(q − 1)
4. Se selecciona un entero e (1 < e < φ(n)), tal que e sea primo relativo9 de φ.
5. Se calcula d , d = e−1 mod φ(n)

8
La implementación del criptosistema RSA en el presente trabajo de tesis utiliza llaves de 1024
bits. Lo cual garantiza hoy dı́a un margen de seguridad aceptable.
9
Dos enteros a, b son primos relativos si el máximo común divisor M CD(a, b) = 1.
6. La llave pública es Kpub = (e, n)
7. La llave privada es Kprv = (d, e)
Cifrado en RSA
El texto en claro es cifrado en bloques, cada bloque debe detener un valor binario
menor que n.
1. Texto claro: M < n
2. Texto cifrado: C = M e (mod n)
Descifrado en RSA
1. Texto cifrado: C
2. Texto claro: M = C d (mod n)
1.4. Criptografı́a de curva elı́ptica ECC
El fundamento básico de los sistemas de llave pública es la gran dificultad de resol-
ver computacionalmente problemas como el del logaritmo discreto y la factorización.
Estos problemas están definidos sobre un grupo finito, principalmente en Zn y Zp ∗ .
Teóricamente se puede considerar cualquier grupo mientras los problemas anteriores
estén bien definidos. Hay dos razones principales por las cuales se deben de considerar
alguna otra variedad de grupos. Primero, las operaciones requeridas en ciertos grupos
pueden ser implementadas más fácilmente en software o hardware que en otros grupos.
Segundo, los problemas computacionales que son la base de los criptosistemas pueden
ser más dificiles de resolver en otros campos finitos. De tal forma, se puede usar un gru-
po finito G más pequeño que Zn o Zp ∗ pero con el mismo o mejor nivel de seguridad.
Como resultado se obtienen tamaños de llave más pequeños y/o implementaciones más
eficientes.
Las curvas elı́pticas [KC98, V.86, Sti95] definidas sobre campos finitos producen
un grupo tal que el problema del logaritmo discreto es intratable. Estas curvas fueron
propuestas por primera vez en aplicaciones criptográficas por Neal Koblitz y Victor
Miller [V.86] en 1985.
En las siguientes secciones se explica la aritmética básica necesaria para la utiliza-
ción de las curvas elı́pticas en aplicaciones criptográficas. La primera sección aborda
la aritmética de curvas elı́pticas definidas sobre los números reales de forma geométri-
ca para ası́ poder explicar de una manera mucho más intuitiva la adición y doblado
de puntos. Las secciones posteriores explican la definición de curvas sobre los campos
finitos Fp y F2m .
1.4.1. Grupos de curva elı́ptica sobre R
Una curva elı́ptica sobre R es definida como el conjunto de puntos (x, y) que satis-
facen la ecuación §(1.1)
y 2 = x3 + ax + b (1.1)
Las variables a, b pertenecen a R y la modificación de los valores de a y b producen
diferentes curvas elı́pticas.
Si x3 +ax+b no tiene factores repetidos; es decir, si el determinante ∆ = 4a3 +27b2 6=
0 10 , entonces la curva elı́ptica definida en §(1.1) puede ser usada para formar un grupo.
Un grupo de curva elı́ptica sobre los números reales esta conformado por los puntos que
10
La condicion de que ∆ 6= 0 asegura que la curva elı́ptica sea suave; es decir, que no existan puntos
en los cuales la curva tenga dos o más lı́neas tangentes. Esta propiedad es muy importante, ya que la
operación de doblado de puntos utiliza la lı́nea tangente a la curva en el punto a doblar.
satisfacen la curva, junto con un punto especial O denomidado punto al infinito.
Los grupos formados por curvas elı́pticas son grupos aditivos; es decir, su función
básica es la adición. La adición de dos puntos en una curva elı́ptica puede ser definida
geométricamente.
El negativo de un punto P = (xp , yp ) es su reflexión sobre el eje x, de tal forma
−P = (xp , −yp ). Debido a la simetrı́a de la curva respecto al eje x, el punto −P
también forma parte de la curva.
Adición de puntos en curva elı́ptica sobre R
Suponga que P y Q son puntos distintos de la curva elı́ptica, y que el punto P 6= −Q.
Para sumar los puntos P y Q, se traza una lı́nea a través de los dos puntos. Esta lı́nea
intersecta la curva elı́ptica en exactamente otro punto, denotado −R. El punto −R es
reflejado con respecto al eje x para obtener R. Un ejemplo de adición de puntos en una
curva elı́ptica definida sobre R se muestra en la figura §1.4 [HMV03].
En el caso particular P = −Q la lı́nea a través de P y −P es vertical, la cual no
produce intersección con otro punto de la curva elı́ptica; consecuentemente los puntos
P y −P no pueden ser sumados de la forma anteriormente definida. Debido a esta razón
la curva elı́ptica incluye un punto al infinito O. Por definición, P + (−P ) = O. Como
resultado de esta ecuación se obtiene P + O = P. O es llamado elemento neutro del
grupo.
Doblado de puntos en curva elı́ptica sobre R
Para sumar un punto P a sı́ mismo, se traza una lı́nea tangente a la curva en el punto
P . Si Py 6= 0 , entonces la lı́nea tangente intersecta a la curva elı́ptica en exactamente
otro punto, denotado −R. Este punto es reflejado respecto al eje x para obtener R.
Esta operación es llamada doblado de punto (P + P = 2P = R). Un ejemplo de la

Suma: P + Q = R
8
6 Q (x2 , y2)
-R (x3 , -y3)
y 4
–4 –2 2 4 6
x
–2
P (x1 , y1)
–4
R (x3, y3)
–6
–8 y^2 = x^3 - 7x
Figura 1.4: Adición de puntos sobre R
operación de doblado de punto en una curva elı́ptica definida sobre los números reales
R se muestra en la figura §1.5 [HMV03].
Si el punto P es tal que Py = 0, la lı́nea tangente a la curva elı́ptica en el punto P es
vertical por lo cual no intersecta la curva elı́tpica en ningún otro punto. Por definición,
2P = O para un punto P con Py = 0. Si se requiere calcular 3P , se puede sumar
2P + P , lo cual es lo mismo que O + P = P, de tal forma que 3P = P .

Doblado: P + P = R
8
6
-R
y 4
P(x1,y1)
–4 –2 2 4 6
x
–2
–4
R(x3,y3)
–6
–8 y^2 = x^3 - 7x
Figura 1.5: Doblado de puntos sobre R
Multiplicación escalar de puntos
La operación de exponenciación de un punto P , es denotada por la multipicación
escalar del punto definida como kP = P + P + P + · · · + P (k veces), esto es debido
a que la operación básica del grupo es la adición.
1.4.2. Grupos de curva elı́ptica sobre Fp
Las operaciónes sobre los números reales son lentas e inexactas debido a errores de
redondeo del punto flotante. Las aplicaciones criptográficas requieren una aritmética
11
rápida y precisa; debido a esto los grupos usados en la práctica son Fp y F2m .
Una curva elı́ptica definida sobre Fp puede ser obtenida mediante la asignación de
valores de las variables a y b que estén dentro del campo Fp . El grupo de curva elı́ptica
incluye todos los puntos (x, y) que satisfacen la ecuación §(1.2) sobre Fp junto con el
punto al infinito O.
y 2 (mod p) ≡ x3 + ax + b (mod p) (1.2)
Un ejemplo de una curva elı́ptica sobre Fp se muestra en la figura §1.6.
y^2 (mod 23) = x^3 + x (mod 23)

22
21
20
19
18
17
16
15
14
13
12
11
10
9
8
7
6
5
4
3
2
1
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22
Figura 1.6: Curva elı́ptica y 2 = x3 + x sobre F23
11
El campo Fp usa números de 0 a p − 1, y los cálculos de sus operaciones son realizadas en módulo
p.
Aritmética en grupos de curva elı́ptica sobre Fp
Existen grandes diferencias entre los grupos Fp y los reales R. Los grupos sobre
Fp son finitos debido a que las curvas consisten de una serie de puntos discretos de
la curva. Geométricamente las operaciones no son claras como en R. Sin embargo, las
reglas algebraicas para la aritmética pueden ser adaptadas para curvas elı́pticas sobre
Fp .
Adición de puntos
Si P (xP , yP ) y Q(xQ , yQ ) son puntos diferentes tal que, P 6= −Q, la suma P + Q =
R(xR , yR ) está definida de la siguiente forma:

(yP −yQ )
s= (xP −xQ )
mod p
xR = s2 − xP − xQ mod p
yR = −yP + s(xP − xR ) mod p
Nótese que s es la pendiente de los puntos P y Q.
Doblado de puntos
Si yP 6= 0, el doblado de P es 2P = R donde
(3xP 2 +a)
s= (2yP )
mod p
xR = s2 − 2xP mod p
yR = −yP + s(xP − xR ) mod p
A continuación se muestra el algoritmo utilizado para la multiplicación escalar de
los elementos del grupo de curva elı́ptica sobre Fp .

Multiplicación de puntos para curvas sobre Fp
Entrada: k = (kt−1 , . . . , k1 , k0 )2 , P ∈ E(Fq )

Salida: kP
1. Q ← O
2. De i = 0 hasta t − 1 haz
2.1 Si ki = 1 entonces Q ← Q + P
2.2 P ← 2P
3. Regresa (Q)
1.4.3. Grupos de curva elı́ptica sobre F2m
Los elementos del campo F2m son cadenas de m-bits. Las reglas para la aritmética
sobre F2m pueden ser definidas ya sea por representación polinomial 12 o por represen-
tación de base normal óptima (ONB)13 . Debido a que F2m opera sobre cadenas de bits,
los cálculos aritméticos pueden realizarse muy eficientemente [ECC04].
Una curva elı́ptica sobre F2m esta definida por la ecuación §(1.3), donde los elementos
a y b pertenecen a F2m y b 6= 0.
y 2 + xy = x3 + ax2 + b (1.3)
El grupo de curva elı́ptica incluye todos los puntos (x, y) los cuales satisfacen la
ecuación §(1.3) sobre F2m junto con el punto al infinito O.
Aritmética en grupos de curva elı́ptica sobre F2m
Los grupos de curva elı́ptica sobre F2m son grupos finitos y su aritmética no involucra
errores por redondeo al igual que Fp . Esto en combinación con la naturaleza binaria del
12
Los elementos de F2m son polinomios de grados menores que m, con coeficientes en F2 ; es decir,
am−1 xm−1 + am−2 xm−2 + · · · + a2 x2 + a1 x + a0 . Estos elementos pueden ser escritos en forma de
vectores de la forma (am−1 · · · a1 a0 ). El número de elementos de F2m es 2m .
13
Una base óptima proporciona una alternativa para la definición de la multiplicación de los ele-
mentos del campo [ECC04].
campo, permite que la aritmética pueda ser implementada muy eficientemente por una
computadora [ECC04].
Adición de puntos
El negativo del punto P = (xP , yP ) es el punto −P = (xP , xP + yP ). Si P (xP , yP ) y
Q(xQ , yQ ) son puntos diferentes tal que, P 6= −Q, entonces P + Q = R donde

(yP −yQ )
s= (xP +xQ )
x R = s2 + s + x P + x Q + a
yR = s(xP + xR ) + xR + yP
Al igual que las curvas elı́pticas sobre R, P +(−P ) = O, el punto al infinito. Además,
P + O = P para todos los puntos P .
Doblado de puntos
Si xP = 0, entonces 2P = O. Si xP 6= 0 el doblado de P es 2P = R donde

yP
s = xP + xP
x R = s2 + s + a
yR = xP 2 + (s + 1)xR
El algoritmo de multiplicación escalar sobre F2m es el mismo que en Fp . La diferencia
radica únicamente en la aritmética utilizada en cada grupo.

Multiplicación de puntos para curvas sobre F2m
Entrada: k = (kt−1 , . . . , k1 , k0 )2 , P ∈ E(F2m )

Salida: kP
1. Q ← O
2. De i = 0 hasta t − 1 haz
2.1 Si ki = 1 entonces Q ← Q + P
2.2 P ← 2P
3. Regresa (Q)
1.4.4. Criptosistema basado en ECC
El siguiente es un ejemplo de un criptosistema basado en curva elı́ptica sobre el
campo finito Fp .
Definición 1.2. Sea un número p > 3. La curva elı́ptica en Fp (denotada como E(Fp ))
es el conjunto de soluciones (x, y) en Fp × Fp que satisfacen:
y 2 (mod p) ≡ x3 + ax + b (mod p) (1.4)
donde a, b estan en Fp y el discriminante ∆ = 4a3 + 27b2 6= 0 mod(p). Entonces,
el grupo de cuva elı́ptica esta definido por los puntos (Px , Py ) ∈ Fp que satisfacen la
ecuación §(1.4) junto el punto especial O denominado punto al infinito.
De tal forma, el problema del logaritmo discreto en curvas elı́pticas se reduce a lo
siguiente:
14
Dada una curva elı́ptica E definida en Fp , un punto P ∈ E(Fp ) de orden n y un
punto Q ∈ E(Fp ), determine el entero k, 0 < k < n − 1, tal que Q = kP , sabiendo que
tal entero existe.

14
El orden de una curva elı́ptica E sobre Fp es definido como el número de puntos (x, y) ∈ E(Fp ),
denotado como #Fp [HMV03].
De tal forma, las primitivas de un criptosistema basado en curva elı́ptica son defi-
nidas de la siguiente forma:
Generación de llaves
Una vez seleccionada la curva elı́ptica sobre un campo finito Fp , la generación de
llaves en curva elı́ptica consta de los siguientes pasos:
1. Selección de un punto conveniente P ∈ E(Fp ) de orden n.
2. Selección de un entero único e impredecible k, 0 < k ≤ n − 1.
3. Se calcula Q = kP
4. La llave pública es conformada por (E, P, n, Q)
15
5. Se mantiene en secreto la llave privada k
Operación privada
Dado un mensaje m, los parámetros de la curva (E, P, n), y la llave privada k, el
procedimiento de firma digital es el siguiente:
1. Selección de un entero único e impredecible i, 0 < i ≤ n − 1.
2. Calcular iP = (x1 , y1 )
3. Calcular r = x1 mod n
4. Calcular s = i−1 (m + kr) mod n
5. La firma de m esta formada por la pareja (r, s)

15
Como comparación, un sistema basado en curva elı́ptica con un punto P cuyo orden es un número
primo de 160 bits ofrece aproximadamente el mismo nivel de seguiridad que el sistema RSA con un
modulo n de 1024 bits.
Operación pública
Dado un mensaje m, los parámetros de la curva (E, P, n, Q), el procedimiento de
verificación de firma digital es el siguiente:
1. Calcular s−1 mod n
2. Calcular u1 = ms−1 mod n
3. Calcular u2 = rs−1 mod n
4. Calcular u1 P + u2 Q = (x1 , y1 )
5. Calcular v = x1 mod n
6. La firma es aceptada si v = r
En el capı́tulo §4 se abordará otros aspectos de la Criptografı́a de Curva Elı́ptica
como por ejemplo: los tipos de curva utilizadas en la implementación de la Autori-
dad Certificadora, el esquema de firma y la verificación digital de acuerdo al estandar
ECDSA.
1.5. Funciones hash
Una funcion hash en Criptografı́a, toma como entrada un mensaje de longitud arbi-
traria y produce como salida una digestión del mensaje de longitud fija. Las propiedades
que debe cumplir este tipo de funciones son:
Dado un mensaje m, la digestión del mensaje h(m) puede ser calculada muy
rápidamente.
Dado una digestion del mensaje y, computacionalmente no es posible encontrar
un mensaje m tal que h(m) = y.
Es computacionalmente imposible encontrar colisiones entre mensajes (m1 6= m2 ,
tal que h(m1 ) = h(m2 )).
La implementación de la Autoridad Certificadora en esta tesis utiliza los algoritmos
hash MD5 (Message Digest Algorithm) y SHA-1 (Secure Hash Algorithm).
El algoritmo hash MD516 fue desarrollado por Ron Rivest. Recibe de entrada un
mensaje de tamaño arbitrario y produce una salida de 128 bits. La entrada es procesada
en bloques de 512 bits.
El algormitmo hash SHA fue desarrollado por NIST17 y publicado como FIPS PUB
180 18 en 1993. Posteriormente se revisó en 1995 generando la especificación FIPS PUB
180-2 conocida como SHA-1. El algoritmo es alimentado con un mensaje de longitud
máxima de 264 bits y produce una salida de 160 bits 19

. La entrada al igual que MD5
es procesada en bloques de 512 bits.
1.6. Aplicaciones de criptosistemas de llave pública
Actualmente la seguridad de navegación y compra de bienes y servicios en Internet es
soportada por protocolos como SSL (Secure Sockets Layer) desarrollado por Netscape,
y TLS (Transport Layer Security) propuesto por IETF20 , en lo referente a transacciones
seguras con tarjetas de crédito el protocolo SET (Secure Electronic Protocol) diseñado
16
El algoritmo MD5 es descrito a detalle en el RFC 1321, http://www.ietf.org/rfc/rfc1321.txt
17
National Institute of Standards and Technology, http://www.nist.org
18
Federal Information Processing Standards Publications, http://www.itl.nist.gov/fipspubs/
19
En febrero de 2005 se dio a conocer un nuevo ataque sobre el algoritmo SHA-1. Los autores afirman
que su análisis muestra que las coalisiones de SHA-1 pueden ser encontradas con una complejidad
menor a 269 operaciones hash. Este es el primer ataque al algoritmo completo de SHA-1 con complejidad
menor a 280 [WYY05].
20
Internet Engineer Task Force, http://www.ietf.org
por VISA y MasterCard, sustenta este tipo de transferencias bancarias. Por supuesto,
estos protocolos están fundamentados en criptosistemas de llave pública.
A continuación se mencionan los servicios fundamentales de la seguridad informática
y las ideas básicas de la Criptografı́a de llave pública y las funciones hash que permiten
su implementación en aplicaciones reales.
1.6.1. Autenticación
La autenticación es el proceso de verificar la identidad de alguien o algo (usuario,
servidor, comporación, etc.). La autenticación es muy importante en transacciones de
comercio electrónico que involucren a un cliente y a un servidor, ya que los clientes
desean confirmar la identidad del servidor antes de enviar información confidencial
como su número de tarjeta de crédito. El siguiente ejemplo es la forma en la cual el
protocolo SSL utiliza técnicas de criptografı́a de llave pública para la autenticación.
Supongamos que A quiere autenticar a B:
A envı́a un mensaje aleatorio r a B
B cifra r usando su llave privada y envı́a el resultado a A
A descifra el dato enviado por B usando la llave pública de B y lo compara con
el original
Debido a que la llave privada de B solo es conocida por él mismo, B es la única
entidad que pudo haber cifirado el mensaje r si es que la comparación fue exitosa.
1.6.2. Intercambio de llaves
Como se mencionó anteriormente, el intercambio de llaves fue la primera aplicación
de la Criptografı́a de llave pública. Se requiere compartir una llave secreta (conocida en

la práctica como llave de sesión), la cual pueda ser usada posteriormente para cifrar y
descifrar mensajes mediante un sistema de llave secreta como DES. Los siguientes son
los pasos a realizar:
A genera un número alearorio k para ser usado como llave secreta (llave de sesión)
A cifra k usando la llave pública de B y envı́a el resultado a B
Después de recibir, B descifra el mensaje usando su llave privada
Debido a que la llave privada de B únicamente es conocida por B, cualquier atacante
que obtenga de alguna forma los mensajes no podrá conocer el secreto compartido21 .
1.6.3. Confidencialidad
Un criptosistema de llave pública puede ser utilizado para mantener y asegurar la
confidencialidad de los datos, pero en la práctica, este tipo de esquema no es utilizado
debido a que los sistemas de llave secreta son aproximadamente 100 a 200 veces más
rápidos [Moh04]. De tal forma, los criptosistemas de llave pública son usados como
una herramienta para que los sistemas de cifrado simétrico puedan establecer su llave
secreta.
1.6.4. No-repudio y firmas digitales
Los sistemas de llave pública proporcionan firmas digitales las cuales no pueden
ser repudiadas. El concepto es muy similar al proceso del mundo real donde se firma
un documento para legalizarlo y para especificar a la persona o entidad responsable

21
Para que este esquema de intercambio de llaves tenga éxito es necesario asegurar la autenticación
de las entidades, ya que de otra forma el esquema puede ser vı́ctima de alguna entidad maliciosa
mediante ataques como “el intruso de en medio ”, “usurpación de identidad ” entre otros. Este tipo
de debilidades de los sistemas de llave pública son discutidas en el capı́tulo §2.
Alicia Benito
M M M
E E E
N N N
S S S Hash h(m)
A A A
J J J Firma NO
E E E Válida
no si
Anillo de ¿iguales?
llaves
publicas
Llave
privada
Hash de Alicia
Firma Verificada
Llave pública
de Alicia
h(m) h´(m)
Operación Privada Operación Pública
Firma Digital
Figura 1.7: Esquema de firma y veriificación digital
por el documento; pero es más poderoso pues también protege contra alteraciones del
documento original. El esquema de firma digital se basa en dos algoritmos, uno de firma
y otro de verificación. Este proceso es muy similar al de autenticación.
A cifra el mensaje m con su llave privada (EKprv (A) (m))
A cifra el resultado utilizando la llave pública de B y envı́a el resultado a B
(c = EKpub (B) (EKprv (A) (m)))
B recupera m mediante m = DKpub (A) (DKprv (B) (c))
Debido a que B es capaz de recuperar m usando la llave pública de A, B puede
verificar que A firmó el mensaje con su llave privada. Y debido a que la firma depende
del contenido del mensaje, nadie más puede usar la fima con otro mensaje.
La firma digital en el mundo real (figura §1.7) no se realiza directamente sobre el
mensaje; lo que se hace es calcular el resumen hash del mensaje (h(m)) y éste es el que
se firma. La siguiente sección lo ejemplifica.

1.6.5. Integridad de datos
Las firmas digitales también pueden ser usadas para validar la integridad de datos
firmados. Por ejemplo, el protocolo SSL utiliza funciones hash para procesar el mensaje
de tal forma que el algorimo firma únicamente el valor hash del mensaje, en lugar de
firmar el mensaje completo.
A calcula el hash del mensaje y lo cifra con su llave privada
A envı́a el mensaje m y el hash cifrado a B
Después de recibir, B extrae el mensaje m y calcula el valor hash del mensaje.
También extrae el valor hash cifrado y lo descifra utilizando la llave pública de A
B compara el valor hash calculado con el valor que recibió. Si son idénticos,
entonces se ha validado la integridad de los datos.
En la práctica la Criptografı́a de llave pública necesita una infraestructura la cual le
permita proveer plenamente los servicios anteriores, sobre todo los servicios de autenti-
cación para evitar ataques como el intruso de en medio y la usurpación de identidad. El
capı́tulo §2 es dedicado a explicar la necesidad de contar con un sistema de autenticación
confiable para ası́ evitar este tipo de ataques.

Capı́tulo 2
Servicio de autenticación
La Autenticación es un proceso que tiene como finalidad verificar la información
referente a un determinado objeto, como la identidad del remitente (ya sea un disposi-
tivo electrónico y/o un usuario), la integridad de la información enviada, el momento
de envı́o de la información, la validez de la firma, etc.
La Autenticación es uno de los objetivos más importantes en la seguridad de la
información. A mediados de 1970 se creı́a que la autenticación y la confidencialidad
estaban ligadas intrı́nsecamente, pero con el descubrimiento de las funciones hash, las
firmas digitales y los adelantos en reconocimiento de patrones biométricos se ha logrado
una separación de estos servicios de seguridad.
En la Seguridad Informática existen diversos tipos de autenticación [MOV01]:
Autenticación del mensaje. Este término es usado análogamente con autenti-
cación del origen de datos y consiste en la verificación de que una de las partes
es la fuente original del mensaje, es decir, autentica la procedencia de un men-
saje creado en un determinado momento. Este tipo de autenticación asegura la
integridad del mensaje.
Autenticación de entidad. Consiste en el proceso donde una parte se asegura
de la identidad de la segunda parte involucrada en el protocolo de comunicación.
28
CAPÍTULO 2. SERVICIO DE AUTENTICACIÓN 29
La identidad es asegurada en base a la corroboración de información especifica
obtenida en el protocolo.
Autenticación de llave. Este tipo de autenticación permite que una parte se
asegure que ninguna otra entidad no confiable pueda tener acceso a la llave privada
correspondiente.
Autenticación de transacción. Este tipo de autenticación provee autenticación
de mensaje y adicionalmente garantiza la existencia única y temporal de los datos.
La existencia única y temporal se logra a través del uso de parámetros variantes
en el tiempo TVPs1
La tabla § 2.1 resume las propiedades de los diferentes tipos de autenticación
[MOV01].
⇒ Propiedad Identificación Integridad Tiempo

⇓ Tipo de autenticación del origen de datos o unicidad
autenticación de mensaje si si -
autenticación de transacción si si si
autenticación de entidad si - si
autenticación de llave si si deseable
Tabla 2.1: Diferentes tipos de autenticación y sus propiedades
La autenticación es un proceso activo el cual utiliza herramientas criptográficas y
protocolos de comunicación para llevar a cabo su objetivo. La autenticación proporciona
un servicio de protección de sistemas de información contra ataques tanto pasivos como
activos.
Las primitivas criptográficas necesarias para poder ofrecer el servicio de autenticación
son las siguientes:

1
TVPs (Time-Variant Parameters), estos parámetros incluyen números aleatorios, estampas de
tiempo, secuencias, etc., en respuesta a retos involucarados en el protocolo de comunicación.
1. Funciones hash (SHA1, MD5)
2. Cifradores simétricos (AES, DES, TDES)
3. Firma digital (RSA, ECDSA)
Una de las aplicaciones más comunes e importantes en la Seguridad Informática es
el Control de Acceso, el cual se otorga en base a la autenticación de de la entidad que
quiere acceder a la información.
La autenticación de un usuario puede ser lograda en base a uno o varios de los
siguientes aspectos:
Algo que el usuario conozca (una palabra clave, un NIP, nombre de usuario, etc.)
Algo que el usuario posea (una tarjeta inteligente, un certificado digital)
Algo que el usuario sea (huella digital, reconocimiento de voz, la anatomı́a del
rostro, análisis de DNA, etc.)
El trabajo de ésta tesis se enfoca principalmente a la creación de una infraestructu-
ra la cual permita realizar autenticación de entidad ; es decir, identificación de usuarios
involucrados en una transferencia de información electrónica a través de algo que el
usuario conozca, algo que posea y algo que sea.
2.1. Servicios de seguridad informática en ambientes
inalámbricos
La comunicación inalámbrica es el proceso de transmisión de información a través
de ondas electromagnéticas que viajan por el espacio libre. Los mensajes inalámbricos
viajan por el medio ambiente utilizando un determinado espectro electromagnético el
cual está regulado por las autoridades correspondientes.
Dispositivos inalámbricos como asistentes digitales personales (PDAs), teléfonos ce-
lulares, pagers son lógicamente menos seguros que sus contrapartes alámbricos. Esto
es debido en parte a las limitaciones tanto en capacidad de procesamiento, memoria
y el ancho de banda restringido para transmisión. Otra razón de gran importancia es
que estos dispositivos envı́an información a través del medio ambiente donde cualquier
entidad con la tecnologı́a apropiada puede interceptarla.
La tecnologı́a inalámbrica, por su misma naturaleza, viola los principios fundamenta-
les de la seguridad informatica. Esta no asegura la identidad del usuario (autenticación),
tampoco previene que el remitente del mensaje refute que ha enviado el mensaje (no-
repudio). La tecnologı́a inalámbrica no es nueva, pero sus aplicaciones contemporaneas
son aún inmaduras.
Para solucionar los inconvenientes mencionados anteriormente es de gran importan-
cia fortalecer los servicios de seguridad informática en ambientes inalámbricos sobre
todo en dispositivos con poder computacional restringido. Debido a esto, el presente
trabajo de tesis hace hincapié en el uso de criptosistema ECC el cual permite obte-
ner exelentes grados de seguridad a un precio computacional menor que algoritmos
como RSA; además, se propone el uso de información biométrica para complementar el
servicio de autenticación. En resumen, se creó una infraestructura que robustece el ser-
vicio de autenticación de usuarios, y que es especialmente conveniente para dispositivos
móbiles en ambientes inalámbricos.

2.2. Ataques a la autenticación de entidades
La presente sección brinda un panorama de los principales ataques que comprometen
el servicos de autenticación de entidades.
2.2.1. Ataque del intruso de en medio
Supongamos que Ana quiere establecer una sesión segura con Beto para el envı́o
de información confidencial. Para esto, utiliza un protocolo de llave pública para el
intercambio de llaves. Si un atacante, Carlos, se hace pasar por Beto sin que Ana
lo advierta, entonces podrá descifrar la información confidencial sin problema alguno.
Existen varias formas en las cuales Carlos puede llevar a cabo el ataque. La figura §2.1
ilustra este tipo de ataque al protocolo Diffie-Hellman.
ga (mod p) gx (mod p)
Ana Carlos Beto
gx (mod p) gb (mod p)
KAC = (ga)x (mod p) KCB = (gb)x (mod p)
Figura 2.1: Ataque del “intruso de en medio” al protocolo Diffie-Hellman
Nótese que en ningún momento se rompió el criptosistema de llave pública, Carlos
únicamente hizó creer a Ana que realmente es Beto y viceversa.
2.2.2. Usurpación de identidad
La usurpación de identidad consiste primordialmente en la subplantación de llaves
autenticas por llaves apócrifas. Supongamos que Beto envı́a a Ana su llave pública
mediante una red de datos. El atacante Carlos puede interceptarla y reemplazarla
con su propia llave pública. De igual forma Carlos puede también lograr la misma
meta si Ana descarga la llave pública de Beto de algún servidor en la red mediante la
sustitución previa de las llaves. En resumen, Carlos puede intentar distribuir su propia
llave pública como si perteneciera realmente a Beto.
2.3. Métodos de autenticación
Debido al tipo de ataques presentados en la sección anterior, es nesesario contar
con una infraestructura adicional a la criptografı́a de llave pública, la cual permita
resolver estos problemas. Esta sección explica diferentes métodos para lograr brindar
eficientemente el servicio de autenticación.
2.3.1. Autenticación mediante entidades de confianza
Ana y Beto necesitan intercambiar información de una manera segura y confidencial.
Con el objetivo de no ser propensos a ataques como el intruso de en medio y usurpación
de entidad, deciden que una tercera parte en la cual ambos confian, “certifique” que las
llaves públicas usadas para el cifrado y firma digital de la información correspondan a los
usuarios que afirman ser los legitimos dueños. De esta forma una nueva entidad aparece
en el esquema de autenticación, la cual tiene la tarea de verificar que que el vı́nculo
entre la persona posedora de la llave pública y su identidad sean correctos. A través
de esta nueva entidad tanto Ana como Beto están seguros que estan intercambiando
información con la persona adecuada. La figura §2.2 muestra la relación de confianza
entre Ana, Beto y la tercera entidad de confianza.
La manera en la cual la tercera entidad de confianza logra certificar que las llaves
publicas corresponden a Ana y a Beto es a través de la firma digital de un documento

Entidad
de
Confianza
Ana Beto
Figura 2.2: Autenticación a través de una tercera parte de confianza
elctrónico denominado “certificado digital ” el cual contiene información de la identidad
del usuario y su llave pública respectiva. De esta forma, si tanto Ana como Beto confian
en la entidad de confianza, no existe duda de la autenticidad de las partes en el proceso
de comunicación.
La Criptografı́a de Llave Pública es una herramienta que permite la implementa-
ción de servicios de seguridad como autenticación, confidencialidad, integridad de datos
y no-repudio. En estas aplicaciones, la llave pública se hace de conocimiento general,
pero cuando una parte utiliza la llave pública de la contraparte, no se tiene certeza
real de que la llave pertenezca a quien dice ser. Debido a esto, se requiere una sistema
el cual contenga el registro de las llaves públicas y sus respectivos propietarios entre
otros servicios. Este sistema es conocido en la Internet cómo Infraestructura de Llave
Pública (PKI, Public Key Infraestructure) y su principal tarea es permitir la autenti-
cación confiable de entidades mediante el uso de Certificados Digitales basados en el
estándar X.509. En este contexto, la entidad de confianza es denominada “Autoridad
Certificadora” y es el módulo principal de la infraestructura PKI.
Un certificado digital apegado al estándar X.509 contiene la información necesaria
para vincular una entidad con su respectiva llave pública. A continuación se muestran
algunos campos del certificado X.509.

Nombre de la entidad certificada
Nombre de la autoridad certificadora
Periodos de validez y expiración
Información de los algoritmos criptográficos utilizados
Llave pública de la entidad certificada
Firma digital de la autoridad certificadora
Si un usuario verifica la válidez del certificado mediante la verificación de la firma
digital de la autoridad certificadora, entonces tendrá certeza de la identidad de su
contraparte.
Los certificados digitales ofrecen autenticación con cierto grado de confiabilidad, ya
que se basan en dos caracterı́sticas muy importantes:
Algo que la entidad conoce (la palabra clave que le permite recuperar su llave
privada)
Algo que la entidad tiene (la contraparte de la llave pública certificada, es decir,
su llave privada)
El presente trabajo de tesis trata de extender la seguridad de la autenticación de
los certificados digitales mediante la adición de la propidedad algo que la entidad
sea. Para lograr esta meta se require métodos de autenticación biométrica, los cuales
son tratados en la siguiente sección.
El capı́tulo §3 ofrece una amplia descripción de certificados digitales, autoridades
certificadoras y demás entidades que conforman la infraestructura de llave pública
(PKI).
2.3.2. Autenticación biométrica
Los sistemas de autenticación biométrica identifican usuarios mediante las medicio-
nes de sus caracterı́sticas humanas [JBP99] ya sea fisiológicas como por ejemplo: huella
digital, iris, retina, rostro, etc., o de conducta como la forma en la que escribe, su firma
manuscrita, como teclea en su computadora, etc.
Una apropiada identificación de usuarios es esencial para un control de acceso con-
fiable. Los sistemas de computo generalmente usan tres métodos de identificación. La
autenticación tradicionalmente se ha basado en algo que el usuario tiene (como su llave
privada, una tarjeta magnética o un chip), algo que el usuario sabe (como su palabra
clave). Estos sistemas tradicionales no identifican al usuario como tal. Los objetos o
secretos que se usan pueden ser perdidos, difundidos u olvidados.
El tercer método de autenticación es el biométrico el cual identifica a un usuario
como tal. La Biometrı́a es un conjunto de métodos automatizados de autenticación
basados en la medición de caracterı́sticas fı́sicas o psicológicas de los humanos. Las
caracterı́sticas biométricas deben de ser únicas, no copiables y no transferibles.
Debido a que muchas caracaterı́sticas fisiológicas o de conducta son distintivas en
cada persona, los identificadores biométricos son lógicamente más confiables y capaces
que los sitemas knowledge-based 2 y token-based 3 en la diferenciación de una perso-
na autorizada y de un presunto impostor. Actualmente, existen una gran variedad de
técnicas biométricas en uso. Estas incluyen, imagenes faciales (ópticas e infrarojas),
geometrı́a de manos, métodos basados en reconocimiento de ojos (iris y retina), firma
manuscrita, voz, geometrı́a de venas, huellas digitales, entre otros.
El reconocimiento de huellas digitales es uno de los métodos más estudiados e imple-
mentados en aplicaciones reales, es reconocido como un prueba legitima de identidad

2
knowledge-based, son sitemas que basan su autenticación en algo que el usuario conoce.
3
token-based, son sistemas que basan su autenticación en algo que el usuario tiene.
en asuntos legales en todo el mundo.
El esta tesis se utiliza autenticación biométrica de huellas digitales para poder ofrecer
el servicio de autenticación de usuarios en los tres niveles de seguridad.
Consorcio BioAPI
El Consorcio BioAPI4 (Biometric Application Program Interface) fue fundado en
abril de 1998 y su principal objetivo consiste en desarrollar una biblioteca de progra-
mación biométrica (API, por sus siglas en inglés) la cual permita tener independencia
para los programadores de aplicaciones y proveedores de servicios biométricos.
El consorcio BioAPI está conformado por un grupo de aproximadamente 90 com-

5
pañı́as y organizaciones , las cuales tienen en comuún el interés de promocionar el
crecimiento del mercado biométrico.
BioAPI ha desarrollado una especificación y una implementación de referencia de
la biblioteca estándar (API), la cual es compatible con una amplia gama de programas
y aplicaciones biométricas.
La implementación del estándar BioAPI permite:
Rápido desarrollo de aplicaciones biométricas
Desarrollo flexible en lo referente a plataformas biométricas y sistemas operativos.
Permite la implementación de diferentes alternativas biométricas (huella digital,
iris, voz, rostro, etc.)
6
Los beneficios que otorga el estándar en lo referente a negocios son:
4
El sitio oficial del consorcio es www.bioapi.org.
5
Entre estas organizaciones se pueden mencionar Hewlett-Packard, NIST, Intel, Microsoft, NSA,
Atmel, ST Microelectronics, entre otras.
6
Muchas caracterı́sticas dependen de la implementación comercial del estándar BioAPI. En este
caso particular se usa la implementación por HP de biometrı́a de huella digital en el dispositivo móvil
h5500.
Interfaces de aplicación simples y sencillas
Acceso modular y estándar para funciones, algoritmos y dispositivos biométricos.
Sistema seguro y robousto para el manejo y almacenamiento de lecturas biométri-
cas.
Soporte para identificación biométrica en ambientes de computo distribuido.
En la implementación de este trabajo de tesis se utilizo la biblioteca biométrica
BioAPI desarrollada por Hewllet-Packard para la serie de dispositivos móviles PDAs
(serie h5400). En el capı́tulo de la implementación §4 se explica con más detalle las
caracterı́sticas y funciones de la biblioteca.
El capı́tulo siguiente explica los módulos que conforman la Infraestructura de Llave
Pública, los estándares y protocolos que la regulan.

Capı́tulo 3
PKI (Infraestructura de llave

pública)
Los algoritmos asimétricos como Diffie-Hellman, RSA, ECC han sido un parteaguas
en la Criptografı́a, han permitido resolver los problemas de no-repudio y autenticación,
los cuales no podrı́an ser implementados usando criptosistemas simétricos1 . Pero por
sı́ mismos, los algoritmos de llave pública no garantizan seguridad absoluta. Por ejem-
plo, en el capı́tulo anterior se menciono que el intercambio de llaves Diffie-Hellman es
propenso a varios ataques. Si no se tiene la seguridad en el intercambio de llaves no
importa que todo lo demás sea seguro; el sistema está comprometido.
Para permitir que la Criptografı́a de llave pública pueda ayudar a cumplir los servi-
cios fundamentales de la Seguridad Informática es necesario crear una infraestructura la
cual permita cubrir los huecos de los criptosistemas. A esta infraestructura se le cono-
2
ce como PKI (Infraestructura de Llave Pública). Actualmente la construcción de la
infraestrucutura de llave pública es uno de los aspectos más importantes en las aplica-
1
El problema de intercambio de llaves en un criptosistema simétrico ha sido resuelto con ayuda de la
Criptografı́a Cuántica. Esta tecnologı́a hace uso de un principio fundamental de la Fı́sica Cuántica --
la observación causa perturbación -- ası́ que el intercambio de llaves a través de redes de fibra
óptica puede realizarze con absoluta seguridad ya que el medio de intercambio es un canal seguro. Para
más información véase el sitio oficial de ID Quantique, http://www.idquantique.com/qkd.html
2
Public Key Infraestructure, http://www.pki-page.org/
39
CAPÍTULO 3. PKI (INFRAESTRUCTURA DE LLAVE PÚBLICA) 40
ciones criptográficas, especialmente en la interconexión de la Internet y los dispositivos
móviles.
Para comprender la necesidad de la PKI y como funciona a continuación se exponen
algunos de los problemas más importantes que surgen a causa de la implementación de
criptosistemas de llave pública sin uso de infraestructuras adicionales.
3.1. Introducción a PKI
Los problemas que surgen del uso de algoritmos asimétricos sin el respaldo de in-
fraestructuras adicionales pueden dividirse en cuatro áreas [Sch03]:
1. Autenticidad de llave. El objetivo primario de la autentificación de la llave
pública de una entidad es fundamentalmente evitar ataques como intruso de en
medio y usurpación de identidad discutidos en el capı́tulo anterior §2.2.
2. Revocación de llaves. C ha robado la llave privada de la computadora de A.
Esto significa que C es capaz de usarla para leer todos los mensajes que fueron
cifrados con la llave pública de A. Además C puede generar firmas digitales a
nombre de A. La única forma que tiene A para protegerse es generar un nuevo
par de llaves y no continuar utilizando las anteriores (esta acción es llamada
revocación de llaves). Pero aún existe un problema, ¿Cómo saben las personas
que envı́an correo electrónico a A, que su par de llaves han sido revocado?
3. No-repudio. El propósito de una firma digital es asegurar el no-repudio. Si A
mantiene su llave privada en secreto, significa que nadie más puede generar una
firma digital de un documento más que A mismo. Sin embargo, A puede no aceptar
su firma digital afirmando simplemente que la llave con la cual se generó la firma
no es la suya.
El problema es que no hay forma de probar que la llave particular que generó la
firma digital pertenece realmente a A.
4. Aplicación de polı́ticas. Supongamos que una compañı́a quiere utilizar las
ventajas de la Criptografı́a de llave pública. Quiere asignar un par de llaves a cada
empleado, de manera tal que cada empleado podrá cifrar y firmar información.
Los requerimientos necesarios son los siguientes:
Cada empleado debe de tener únicamente un par de llaves.
Todas las llaves publicas deben de estar registradas de manera centralizada.
Las llaves utilizadas deben de usar un tamaño de longitud de llave adecuada.
Cada par de llave debe ser cambiado despúes de un determinado perı́odo de
validez.
Si un empleado deja de laborar en la compañı́a, su respectiva llave pública
debe de ser revocada automáticamente.
El problema de esta implementación, es que las polı́ticas anteriormente descritas
solamente pueden ser cumplidas con ayuda de sistemas externos a la Criptografı́a
de llave pública.
Para que la Criptografı́a de llave pública pueda ser usada con éxito en aplicacio-
nes comerciales en redes como Internet, es necesario contar una infraestructura que
mantenga vı́nculos con las llaves publicas utilizadas y sus respectivas entidades que las
posean.
La infraestructura de llave pública (PKI) vı́ncula llaves con entidades a través de
certificados digitales, permite que otras entidades verifiquen los vı́nculos con las llaves
publicas, y provee los servicios necesarios para la administración continua de las llaves
en un sistema distribuido.
3.2. Componentes PKI
La Infraestructura de Llave Pública (PKI) es una combinación de software, tecnólo-
gias de cifrado, y servicios que permiten proteger la seguridad de las transacciones de
información en un sistema distribuido. PKI integra certificados digitales, criptografı́a
de llave pública y autoridades de certificación en una arquitectura de seguridad.
Un Certificado Digital es un documento que vı́ncula una llave pública con una
entidad final y que es firmado por una autoridad certificadora para demostrar su validez
e integridad. A continuación se listan los componentes fundamentales [KHPC01] que
conforman la Infrestructura de Llave Pública (PKI):
Entidad final. Es el término genérico para denotar a los usuarios finales o cual-
quier entidad que pueda ser identificada (personas, servidores, compañı́as, etc.)
mediante un certificado digital expedido por una Autoridad Certificadora.
Autoridad Certificadora (AC). La AC es la entidad que expide los certificados
digitales, ası́ como también la lista de revocación (CRL). Adicionalmente puede
soportar funciones administrativas, aunque generalmente estas son delegadas a
una o varias Autoridades de Registro.
Autoridad de Registro (AR). Una AR es componente opcional que puede
asumir funciones administrativas de la CA. Las funciones de la AR están frecuen-
temente asociadas con la afiliación de las entidades finales, pero adicionalmente
puede asistir en otras áreas.
Repositorio. El repositorio es el término genérico utilizado para denotar cual-
quier método para almacenamiento de certificados y listas de revocación (CRLs)
que permita el acceso por parte de las entidades finales a dichos documentos.
Emisor CRL. El emisor CRL es un componente opcional el cual puede ser utili-
zado por una AC para delegar las tareas de publicacion de las listas de revocación.
La figura §3.1 muestra los componentes que integran la infraestructura de llave
pública.
R
e
Consulta de certificados y CRL Entidad Final
p
o
s
i
t
o
r
i Autoridad de Registro * Registro de usuarios
o AR * Inicio de certificación
* Recuperación de llaves
Publicación
* Solicitudes de revocación
d de certificados
e
c
e Autoridad Certificadora
r (AC)
t
i
Publicación de certificados y CRL
f
i Certificación
c entre una o
a más ACs
d
o
s Publicación
de CRLs
y
Emisor CRL
C Autoridad Certificadora
R (AC)
L
Figura 3.1: Componentes PKI

3.2.1. Autoridades Certificadoras (ACs)
Una Autoridad Certificadora, es el componenete fundamental de la infraestructura
de llave pública. Es una combinación de hardware, software, y personas que conforman
una arquitectura de seguridad. La AC es conocida por sus dos atributos más importan-
tes: su llave pública y su nombre o identificador.
La AC expide certificados de llave pública para cada entidad, confirmando plena-
mente la identidad del suscriptor con sus respectivos documentos de identidad. Un
certificado digital incluye la llave pública, información acerca de la identidad del sus-
criptor que posee la llave privada, un perı́odo de validez del certificado, y la firma digital
de la propia autoridad certificadora. El certificado puede contener otros campos como
por ejemplo: información adicional sobre la autoridad certifiadora o información acerca
de usos recomendados para la llave pública. Un suscriptor es un individuo o entidad
de negocio que ha contratado a una AC para recibir un certificado digital el cual le
permita verificar su identidad para transacciones firmadas digitalmente.
Una AC también debe de expedir y procesar listas de revocación de certificados
(CRLs), las cuales son listas de los certificados que han sido invalidados. Los certificados
pueden ser revocados por distintas razones, por ejemplo, si un propietario ha perdido
su llave privada; la compañı́a que posee el certificado cambia de nombre; o simplemente
el propietario de la llave privada abandona la empresa para la cual trabaja. Las CRLs
también deben de documentar el estado de revocación de los certificados; al igual que
el perı́odo de validez de un certificado digital, la lista de revocación debe de especificar
la fecha exacta en la cual el certificado fue revocado.
Una Autoridad Certificadora desempeña cuatro funciones básicas en PKI:
Expedición de certificados digitales.
Expedición de listas de revocación.

Publicación de sus certificados digitales y su lista de revocación.
Almacenamiento del estado de los certificados expirados que ha expedido.
Estos cuatro requerimientos son dı́ficiles de satisfacer simultáneamente. Para cumplir
con estos requerimientos, una AC puede delegar ciertas funciones a otros componentes
de la infraestructura.
Una AC puede expedir certificados a usuarios, a otras ACs, o a ambos. Cuando
una AC expide un certificado, esta asegurando que el sujeto (la entidad nombrada en
el certificado) posee la llave privada que corresponde a la llave pública contenida en
el certificado digital. Si la AC incluye información adicional en el certificado, la AC
está también afirmando que que la información corresponde a la misma entidad. Esta
información adicional puede ser una dirección de correo electrónico, o información de
polı́ticas para el tipo de aplicaciones en las cuales puede ser utilizada la llave pública.
Cuando el sujeto del certificado es otra AC, el emisor está afirmando que los certificados
de la otra AC son de confianza.
La AC inserta su nombre en cada certificado y CRL que genera, y los firma con su
llave privada. Una vez que los usuarios establecen que confı́an en la AC (directamente,
o a través de una ruta de certificación) ellos pueden confiar en los certificados expedidos
por dicha AC. Los usuarios fácilmente pueden identificar los certificados expedidos por
la AC simplemente por la comparación del nombre. Para asegurar que el certificado
es genuino, ellos pueden verificar la firma utilizando la llave pública de la AC. Como
resultado, es extremadamente importante que la AC brinde una protección adecuada
para su propia llave privada3 .

3
Las Autoridades Certificadoras Gubernamentales en Estados Unidos, deben usar siempre módulos
criptográficos los cuales han sido validados con la norma FIPS 140. En el caso particular de esta tesis,
las llaves privadas de la autoridad certificadora son almacenadas de forma cifrada utilizando AES con
longitud de llave de 128 bits.
3.2.2. Autoridad de Registro (AR)
Una AR es diseñada para verificar el contenido de un certificado para la AC. El
contenido del certificado puede reflejar información presentada por la entidad solicitante
del certificado, tal como licencia de manejo, o recibos de pagos recientes. también puede
reflejar información proporcionada por una tercera parte. Por ejemplo, el lı́mite de
crédito asignado a una tarjeta de crédito refleja la información obtenida del buró de
crédito. La AR conjunta estos datos de entrada y proporciona la información de una
forma digerida a la AC.
Cada AC mantiene una lista de las ARs acreditadas; es decir, las ARs que son
confiables. Una AR es conocida por la AC por su nombre y llave pública. Mediante la
verificación de la firma digital de la AR una AC puede estar segura que la AR es una
entidad acreditada. Al igual que una AC, la AR debe de tener un cuidado extremo en
la protección de su llave privada.
3.2.3. Repositorio
El término repositorio es frecuentemente asociado con un directorio, pero este no es
necesariamente el caso. En el contexto de PKI, un repositorio es un término génerico
usado para denotar cualquier metódo para almacenamineto y recuperación de informa-
ción referente a PKI tal como los certificados de llave pública y las CRLs. Un repositorio
puede estar basado en la especificación X.500 con acceso para clientes a través de (Ligh-
tweight Directory Access Protocol) (LDAP), o incluso puede estar basado en algo mucho
más sencillo como la descarga de un archivo plano de un servidor remoto vı́a FTP, o
HTTP.
4
El grupo de trabajo IETF PKIX se ha dedicado al desarrollo de protocolos
4
El grupo de trabajo PKIX fue establecido en 1995 con el propósito de desarrollar estandares de
Internet necesarios para soportar una infraestructura de llave pública, http://www.ietf.org/html.
operacionales para fácilitar la distribución de certificados de llave pública y CRLs,
incluyendo LDAP, HTTP, y FTP.
También es posible delegar ciertas funciones de los sistemas del cliente a terceras
5
partes confiables. Por ejemplo, el protocolo OCSP puede ser usado para preguntar a
una tercera parte acerca del estado de revocación de uno o más certificados.
En cualquier caso, el funcionamiento clave del repositorio es que las entidades finales
tengan algún mecanismo para obtener información de certificados y CRLs, o en otro
caso que sean capaces de solicitar que esta tarea sea realizada en su representación.
3.2.4. Emisor CRL
El emisor CRL tal como su nombre lo dice, es el encargado de emitir la lista de
revocación. Tı́picamente la AC que expide los certificados es también la responsable de
expedir la lista de rebocación asociada con esos certificados. Sin embargo, es posible
para una AC delegar esa funcionalidad a otra entidad.
3.2.5. Entidades Finales
Las entidades finales PKI son organizaciones o individuos que usan PKI, pero no
emiten certificados. Los entidades dependen de otros componentes PKI para obtener
certificados, y para verificar certificados de otras entidades.
Las entidades finales algunas veces se confunden con usuarios finales. A pesar que
frecuentemente esto es el caso, el término entidad final significa algo bastante más
génerico. Una entidad final puede ser un usuario final, un dispositivo como un ruteador
o un servidor, incluso una AR o cualquier entidad que pueda ser identificado en el
nombre del sujeto de un certificado de llave pública.

charters/pkix-charter.html
5
Online Certificate Status Protocol [RFC2560], http://www.ietf.org/rfc/rfc2560.txt
Las entidades finales estan ligadas a los certificados, y éstas deben de inscribirse a
la infraestructura de llave pública antes que puedan participar como miembros PKI.
3.3. Arquitecturas PKI
Las entidades finales de PKI pueden obtener certificados de diferentes ACs, de-
pendiendo de la organización o comunidad en la cual ellos son miembros. Una PKI
está tı́picamente compuesta de muchas ACs vinculadas por “rutas de confianza”. Una
ruta de confianza conecta a un componente confiable con una o más terceras partes
confiables, de tal forma que todas las partes puedan tener confianza en la validez de
un certificado. Un destinatario de un mensaje firmado, el cual no tiene relación con
la AC que emitió el certificado del remitente puede aún validar el certificado del re-
mitente mediante una ruta entre su respectiva AC y la que expidió el certificado. Es
importante resaltar que los usuarios finales confı́an en sus respectivas ACs que a su vez
tambieñ confı́an en otras ACs, de aquı́ el término de “ruta de confianza”.
El reto inicial es el despliegue de la infraestructura de llave pública de tal forma
que pueda ser utilizada a través de empresas o agencias gubernamentales. Existen dos
arquitecturas PKI tradicionales las cuales permiten alcanzar esta meta, las arquitecturas
jerárquica y de malla. Más recientemente, varias empresas están buscando vincular sus
propias PKIs con las de sus socios de negocio. Una tercer método, la arquitectura de
puente está siendo desarrollada para atacar este problema. Estas tres arquitecturas son
descritas en los párrafos siguientes.
Jerárquica: Las Autoridades son organizadas jerárquicamente bajo una AC raı́z
la cual expide certificados a las ACs subordinadas. Estas ACs pueden expedir
certificados a las ACs y/o usuarios de nivel inferior a su jerarquı́a. En el modelo
jerárquico de PKI, cada parte conoce la llave pública de la AC de nivel superior.

Cualquier certificado puede ser verificado a través de la ruta de certificación esta-
blecida entre la AC subordinada y la AC raı́z. En la figura §3.2 (a) se muestra un
ejemplo de la arquitectura jerárquica donde Alicia trata de validar el certificado
de Benito. El certificado de Benito fue emitido por la AC4 , el certificado de la
AC4 a su vez fue expedido por la AC2 , y finalmente el certificado de la AC2 fue
emitido por la AC1 (la AC raı́z), cuya llave pública es conocida por la AC de
Alicia permitiendole ası́ verificar el certificado de Benito.
3
2 3
2 5
Alicia
Alicia
4 5
Benito
Benito
a. Infraestructura Jerárquica b. Infraestructura de Malla
Figura 3.2: Arquitecturas PKI
Malla: En este esquema las ACs se certifican una con otra, resultando en una
malla de relaciones de confianza entre las ACs. La figura §3.2 (b) ilustra un ejemplo
de la arqutectura de malla donde Alicia trata de verificar el certificado de Benito.
Alicia conoce la llave pública de la AC3 , mientras Benito conoce la llave pública
de la AC4 . Existen diversas rutas de certificación que pueden tomarse para llegar
de Benito a Alicia; a continuación se explica la ruta más corta. El certificado de
la AC4 fue expedido por la AC5 y finalmente el certificado de la AC5 fu expedido
por la AC3 . La AC3 es la misma AC que expidió el certificado de Alicia por lo

cual ella conoce su llave pública la cual le permite realizar la tarea de verificación.
Puente: La arquitectura de puente fue diseñada para conectar diversas PKIs sin
importar su arquitectura. Esto es realizado mediante la introducción de una nueva
AC, llamda AC puente, la cual tiene el único proposito de establecer relaciones
entre las diversas PKIs. A diferencia de las otras arquitecturas, la AC puente no
expide certificados directamente a entidades finales. La idea básica es que todos
los usuarios PKI consideren la AC puente como un intermmediario el cual es
capaz de establecer relaciones uno-a-uno con las diferentes PKIs. Estas relaciones
pueden ser combinadas para formar un puente de confianza que permita conectar
los usuarios de las distintas PKIs.
Si el dominio de confianza es implementado como una PKI jerárquica, la AC
puente establece una relación con la AC raı́z. Si el dominio es implementado
como una PKI de malla, la AC puente establece una relación con sólo una de las
ACs. En este caso, la AC que establece confianza con la AC puente se denomina
AC principal.
3.4. Estructuras de datos PKI
Las estructruras de datos básicas utilizadas en PKI son los certificados de llave
pública y la lista de revocación de certificados [HPFS02].
3.4.1. Certificados X.509
El certificado de llave pública en PKI es definido de acuerdo al estandar X.509
[HPFS02, For01]. El certificado X.509 ha evolucionado para ser más flexible y poderoso
y puede ser usado para portar una gran variedad de información, mucha de la cual
es opcional. El certificado de llave pública X.509 está protegido por la firma digital
del emisor. Los usuarios del certificado saben que el contenido no ha sido corrompido
mediante la verificación del mismo. Los certificados contienen un conjunto de campos
comunes, y también pueden incluir opcionalmente una variedad de extensiones. Existen
diez campos comunes, seis de los cuales son obligatorios y cuatro opcionales. Los campos
obligatorios son: número serial, identificador de algoritmo de la firma, nombre del emisor
del certificado, perı́odo de validez, llave pública, y el nombre del sujeto. Los cuatro
campos opcionales son: número de versión, identificadores únicos tanto de emisor como
sujeto, y las extensiones. Los campos opcionales aparecen únicamente en los certificados
X.509 v2 y X.509 v3.
A continuación se explica a detalle la función de cada campo de un certificado digital
X.509.
Versión. El campo de versión describe la sintaxis del certificado. Exisiten tres
tipos de versiones de certificados. Cuando el campo de versión es omitido, el certificado
está codificado en la versión 1. La versión 1 no incluye identificadores ni extensiones.
La versión 2 incluye identificadores pero no extensiones. En la versión 3 se incluyen las
extensiones y es la versión más utilizada hoy en dı́a.
Número serial. El número serial es un número entero asignado por el emisor del
certificado (la AC). Este número debe de ser único para cada certificado generado. La
combinación del número serial y el nombre del emisor identifica únicamente a cualquier
certificado.
Firma. El campo de firma indica cual fue el algoritmo de firma digital que fue uti-
lizado para proteger el certificado. Un ejemplo son los dos tipos de firma utilizados en
esta tesis RSA-con-SHA1 y ECDSA-con-SHA1. La primera parte identifica al cripto-
sistema de llave pública utilizado mientras que la segunda parte identifica al algoritmo
hash usado para proteger la integridad del certificado.

Emisor. Este campo contiene el nombre de la entidad que expidió el certificado
digital. Este nombre es proporcionado de acuerdo al estándar X.5006 .
Validez. El campo de validez indica las fecha en la cual el certificado llega a ser
válido y la fecha en la cual el certificado expira.
Sujeto. El campo del sujeto contiene el nombre que identifica al propietario de la
llave privada que corresponde a la llave pública que se encuentra en el certificado. El
sujeto puede ser cualquier entidad (usuario final, dispositivos de hardware, compañı́as,
etc.).
Información de llave pública. Este campo contiene la llave pública del sujeto,
parámetros opcionales y el identificador del algoritmo. La llave pública contenida en
este campo es utilizada para verificar las firmas digitales del sujeto.
Identificador único del emisor y del sujeto. Estos campos contienen identifi-
cadores, y aparecen únicamente en las versiones 2 ó 3. Los identificadores del sujeto y
del emisor son utilizados para la reutilización del nombre del emisor y el nombre del
sujeto. Sin embargo, se ha probado que este mecanismo no es una solución satisfactoria.
Actualmente el RFC3280 [HPFS02] no recomienda el uso de estos campos.
Extesiones. Este es un campo opcional y sólo aparece en los certificados X.509
versión 3. Si el campo está presente, entonces el certificado contiene una o más exten-
siones de certificado; cada extensión incluye un identificador de extensión, una bandera
que indica si la extensión es crı́tica o no-crı́tica, y el valor de la extensión. Comunmente
las extensiones de los certificados han sido definidas por el ISO7 y ANSI8 y la razón
de su existencia es proporcionar mayor flexibilidad del certificado digital. Cualquier or-
ganización puede definir una extension privada para poder cumplir sus requerimientos
6
X.500 es un estándar de la ISO (International Organization for Standardization) y el ITU (Inter-
national Telecommunication Union) que define la estructuración jerárquica de los directorios globales.
7
International Organization for Standardization, http://www.iso.org/
8
American National Standards Institute, http://www.ansi.org/
especificos9 . Esta flexibilidad crea un nuevo inconveniente: un certificado digital X.509
v3 puede no ser completamente leible por las implementaciones que soportan certifica-
dos X.509 v3. Cuando alguna extensión de certificado no es conocida por la aplicación
que lo recibe, la incompatibilidad se hacén presente. Esta es la razón por la cual existe
la bandera que indica si una extensión es crı́tica o no crı́tica. Si la extensión es marcada
como no-crı́tica la aplicación lo único que hace es ignorar esa extensión; por otro lado, si
es marcada como crı́tica el resultado es que el certificado no puede ser utilizado debido
a que se desconoce la funcionabilidad de la extensión10 .
La figura §3.3 muestra los campos de un certificado X.509 v3.
3.4.2. Listas de revocación de certificados
Los certificados digitales tienen una fecha de expiración establecida. Desafortuna-
damente, los datos en un certificado digital puede dejar de ser confiables antes del
vencimiento del certificado. Por ejemplo, si una entidad final cambia la la dirección
de internet de su compañı́a la cual esta especificada en el certificado digital; o si la
llave privada de una usuario fue comprometida. Debido a estas causas, los emisores
de certificados necesitan un mecanismo para proporcionar un estado actualizado de
los certificados que han emitido. Este mecanismo es denominado X.509 Certification
Revocation List (Lista de Recovación de Certificados) X.509.
La CRL está protegida por la firma digital del emisor CRL. Si la firma puede ser
verificada, el usuario CRL sabe que el contenido no ha sido corrompido desde que la
firma fue generada. Las CRLs contienen varios campos comunes, y al igual que los
9
En los certificados generados en esta tesis se hace uso de dos extensiones privadas, una para
almacenar la información biométrica y otra para agilizar el procesamiento del filtrado de campos. En
el capı́tulo §4 se discutirá más ampliamente los detalles de la implementación.
10
En la presente tesis se utilizan dos extensiones de certificado las cuales se marcan como no-crı́ticas
con el objetivo de mantener la compatibilidad.
Certificado X.509 V.3

Versión
Número de Serie
Identificador Llave privada de
del Algoritmo Algoritmo la Autoridad
de Firma Certificadora
Parámetros
Digital
Entidad Emisora
(Autoridad Certificadora)
Período de No antes de ... Generación

Validez
No despues de ... de firma
digital
Nombre del Usuario
(X.500)
text
Llave Algoritmo
Pública a Parámetros
certificar
Lave Pública
Identificador Único del
Emisor (opcional)
Identificador Único del
Usuario (opcional)
Extensiones
(opcional)
Algoritmo
Parámetros
Firma digital de la AC
Identidifcador Crítico/No Valor del campo

de Extension Crítico de extensión
...
...
...

Figura 3.3: Certificado digital X.509 versión 3

certificados de llave pública también pueden contener extensiones opcionales.
Los campos que contiene una CRL X.509 son los siguientes:
Versión. Este es un campo opcional y describe la sintaxis de la CRL. La versión
más utilizada es la versión 2.
Firma. El campo de firma contiene el identificador del algoritmo utilizado por el
emisor CRL para la generación de la firma digital.
Emisor. El campo contiene el nombre X.500 del emisor CRL.
Actualización actual. Este campo indica la fecha de emisión de la CRL.
Actualización siguiente. Este campo indica la fecha de la emisión de la siguiente
actualización.
Certificados revocados. El campo contiene una lista de todos los certificados re-
vocados. Por cada certificado revocado se encuentra una entrada que indica el número
serial del certificado revocado, la fecha de revocación, y las entradas de extensiones
opcionales CRL. Las entradas de extensiones son empleadas para proporcionar infor-
mación sobre la revocación de un certificado especı́fico y solamente aparece en la versión
2.
Extensiones CRL Este campo es utilizado para proporcionar información adicio-
nal acerca de toda la lista de revocación. Aparece únicamente en la versión 2 de las
CRLs.
En la figura §3.4 se muestran los campos de una lista de revocación X.509.
El ITU y ANSI han definido varias extenciones para las CRL X.509. Cada extensión
al igual que las extensiones de certificados de llave pública pueden ser marcadas como
crı́ticas o no-crı́ticas. La verificación de una CRL falla si se desconoce alguna extensión
crı́tica. Sin embargo, las extensiones no reconocidas que son no-crı́ticas simplemente
son ignoradas.
Lista de Revocación de Certificados

X.509
Versión (del formato CRL)
Algoritmo de Firma (del

emisor del CRLs)
Emisor CRL
(Nombre X.500) Llave privada
Acutualización Actual del Emisor CRL
(Fecha/Hora)
Acutualización Próxima
(Fecha/Hora) opcional
Número Serial Fecha de

Generación
del Certificado Revocación
de firma
Entradas de Extensiones CRL digital

Certificados Entradas de Extensiones CRL

Revocados .
.
.
Entradas de Extensiones CRL
Extensiones CRL
Firma digital del emisor

CRL
Figura 3.4: Estructura de una CRL

3.5. Servicios adicionales PKI
En adición a los servicios de seguridad como: no-repudio, autenticación, confidencia-
lidad e integridad; la infraestructura de llave pública puede proporcionar otros servicios.
Dos servicios importantes son la recuperación de llaves y autorización.
Recuperación de llaves. Si un empleado pierde su llave, agencias y empresas
deben aún ser capaces de recobrar los datos que el empleado habı́a cifrado, lo cual puede
ser únicamente hecho mediante la recuperación de la llave de cifrado. Razones para
recuperar llaves pueden incluir el olvidó su frase clave de un usuario para desbloquear
un archivo cifrado, la muerte de un empleado el cual ha cifrado información, o algún
intento de esconder actividad criminal. Para asegurar la capacidad de recobrar datos
cifrados, las llaves de cifrado deben ser respaldadas y almacenadas de una forma segura.
Sin embargo, las llaves para firmas digitales, no deben ser respaldadas debido a que esto
evitaria que PKI asegurara el no-repudio.
Autorización. Los certificados pueden ser usados para garantizar la identidad de
un usuario y también para especificar los privilegios que goza. La idea fundamental en
este trabajo de tesis es crear un infraestructura que permita la autenticación biométrica
de usuarios mediante certificados digitales.

Capı́tulo 4
Implementación del sistema
En los capı́tulos anteriores se ha mostrado que existen diversos tipos de ataques
al servicio de autenticación; por lo cual, es necesario contar con una infraestructura
adicional complementaria a la criptografı́a de llave pública; la cual, permita ofrecer
eficientemente este servicio. La infraestructura de llave pública (PKI) logra resolver
esta problemática basándose en dos caracterı́sticas fundamentales para la autenticación
de entidades: algo que el usuario conozca (una frase clave) y algo que el usuario posea
(un certificado digital).
La finalidad de esta tesis es la robustecer el servicio de autenticación mediante la
creación de una infraestructura que permita autenticar a un usuario no solamente por
algo que conozca o posea; si no también, por algo único en él, algo que sea; por ejemplo,
la información biométrica de su huella digital.
A continuación se listan las directivas tomadas para el diseño e implementación de
la autoridad certificadora móvil que se desarrolló en la presente tesis.
Crear la infraestructura necesaria para permitir el servicio de autenticación me-
diante algo que el usuario conozca, algo que el usuario posea, y algo que el usuario
sea.
Ofrecer ubicuidad mediante la implementación del software en un dispositivo
58
CAPÍTULO 4. IMPLEMENTACIÓN DEL SISTEMA 59
móvil con lector biométrico integrado.
Ofrecer compatibilidad de la información biométrica y los certificados digitales
generados por la aplicación a través de los estandares BioAPI y X.509v3.
Las siguientes secciones proporcionan una descripción del sistema y explica de-
talladamente el diseño e implementación de la Autoridad Certificadora Móvil que se
desarrolló.
4.1. Descripción del sistema
El sistema como tal es una Autoridad Certificadora Móvil desarrollada en len-
guaje C + +, la cual permite la generación de certificados digitales compatibles con el
estándar X.509v3. Los certificados pueden ser creados ya sea utilizando el criptosistema
RSA o ECC (curva elı́ptica). Además existe la opción de poder incorporar información
biométrica de huella digital en el certificado, a través del uso de extensiones definidas
en el estándar X.509. Con la inclusión de la información biométrica del usuario en las
extensiones del certificado digital, se puede lograr el objetivo de permitir la autentica-
ción en los tres niveles; es decir, a través de algo que el usuario sea, algo que conozca y
algo que posea.
Las lecturas biométricas de la huella digital de los usuarios finales es realizada con el
mismo dispositivo móvil que ejecuta el software de generación de certificados. El PDA
(iPAQ h5550) cuenta con hardware biométrico, el cual permite la realización de lecturas
de huellas digitales.
El apéndice §C explica con mayor detalle el funcionamiento y las opciones del sistema
desarrollado.
Autoridad Certificadora Móvil
Biblioteca biométrica Biblioteca Criptográfica

(BioAPI) (RCT) Biblioteca ASN.1
Estandares
de Criptografía
de Llave Pública
RSA
Hardware biométrico ECDSA
(iPAQ h5550) RFC3279
RFC3280
FIPS 182-2
Criptografía de llave Criptografía de llave
Funciones de resumen
pública secreta
ECC
RSA AES SHA-1 MD5
(curva elíptica)
Figura 4.1: Diagrama a bloques de la aplicación
4.2. Arquitectura de la aplicación
La figura §4.1 muestra el diagrama a bloques de los principales módulos que con-
forman la aplicación de la Autoridad Certificadora Móvil.
A continuación se describen las caracterı́sticas principales del dispositivo móvil uti-
lizado y posteriormente se explican las funciones respectivas de cada módulo que con-
forma la autoridad certificadora.
4.2.1. Dispositivo móvil
El PDA utilizado para la implementación de la AC móvil es el iPAQ h5550 de Hew-
lett Packard. La figura §C.1 del apéndice §C muestra una fotografı́a de ese dispositivo.
Las caracterı́sticas del PDA son listadas en la tabla §C.1.

4.2.2. Biblioteca criptografı́ca RCT
La biblioteca criptográfica utilizada en la implementación de la AC móvil es RCT
(Renewable Cryptography Toolkit [ERHK02] ) la cual fue desarrollada en la universidad
de Oregon State. Esta contiene una amplia variedad de criptosistemas tanto de llave
pública como de llave secreta. A continuación se mencionan únicamente los criptosiste-
mas utilizados para esta tesis.
Criptosistemas de llave pública
Se utilizó RSA y ECC para la generación y verificación de firmas digitales. El cripto-
sistema RSA desarrollado en [ERHK02] está basado en el estándar PCKS #1 [KS98]. En
lo referente al criptosistema de curvas elı́pticas ECC la biblioteca RCT lo implementa
apegado al estándar ECDSA [JMV01] (Elliptic Curve Digital Signature). La figura §4.2
muestra un diagrama a bloques de los módulos implementados en la biblioteca RCT que
son necesarios para la generación de firmas digitales basadas en el estándar ECDSA.
Para ampliar la información referente a los estándares que regulan los criptosistemas
RSA y ECC véase [KS98, JMV01, DK00a] .
ECDSA
Algoritmo de
Firma Digital con
Curva Elíptica
Números
Generación de
Grandes y Aritmética de
Números
Aritmética Curva Elíptica
Aleatorios
Modular
Aritmética de
Campos Fq
Figura 4.2: Módulos ECDSA

Criptosistemas de llave secreta
Se utilizó el criptosistema simétrico AES de 128 bits para la protección de las llaves
privadas (RSA y ECC) tanto de los usuarios finales como de la propia AC Móvil. La
figura §4.3 muestra la forma en la cual se descrifra la llave privada para ser utilizada
posteriormente en la firma digital de un certificado. Nótese que la llave AES es generada
a través de la digestión de una frase clave proporcionada por el propietario de la llave
privada.
Para más información referente al criptosistema AES véase el RFC3268 [Cho01].
Llave privada
cifrada
llave AES (128 bits)

Frase Clave MD5
AES Llave
(Descifrado)
privada
en claro
Figura 4.3: Obtención de llave privada
Funciones hash
El algoritmo de resumen MD5 fue utilizado para la obtención de la llave secreta
(AES de 128 bits) que protege la confidencialidad de las llaves privadas RSA y ECC.
La figura §4.3 ilustra el proceso.
El algoritmo SHA-1 (160 bits) fue utilizado como función resumen para asegurar la
integridad de los certificados digitales firmados por la AC.
Para más información sobre estos algoritmos de digestión véase [Riv92, DK00b].
4.2.3. Biblioteca biométrica BioAPI
En esta sección se aborda los detalles de la integración de la tecnologı́a de autentica-
ción biométrica la cual está basada en la implementación del estándar BioAPI [Bio00]
por parte de Hewlett Packard en su plataforma de dispositivos móviles iPAQ Pocket
PC h5000 series [Bio02].
El dispositivo móvil iPAQ Pocket PC h5550 integra tecnologı́a de captura de hue-
llas digitales conocida como FingerChip desarrollada por Atmel Corporation1 . La tec-
nologı́a de reconocimiento de patrones biométricos es provista por Cogent Systems,
Inc.2 .
La lectura de huella digital en la iPAQ h5550 es realizada mediante un sensor térmi-
co3 el cual realiza un mapeo analógico de temperatura a una imagen digital. El sensor
detecta las diferencias de temperatura entre los bordes y valles de la huella digital.
La implementación para la iPAQ h5500 soporta únicamente un subconjunto de la
especificación completa de BioAPI.
Las siguientes son definiciones necesarias para explicar un poco más en detalle la
implementación de esta tecnologı́a por parte de HP.
BIR - Biometric Identification Record, estructura básica en la cual se al-
macena la infomación de la huella digital.
FAR - False Accept Rate, tasa de falsos positivos (el usuario fue autenticado
erróreamente como otro usuario) en la autenticación de huellas digitales.

1
Empresa lı́der en el desarrollo de semiconductores para tecnológia biométrica.
http://www.atmel.com
2
Empresa lı́der en sistemas autenticación mediante huellas digitales.
http://www.cogentsystems.com
3
El sensor térmico es una gran ventaja sobre otros métodos de lectura, ya que es casi imposible de
engañar mediante medios artificiales [Bio02].
FRR - False Reject Rate, tasa de falsos negativos (el usuario que es quien dice
ser fue identificado como un impostor) en la autenticación de huellas digitales.
Plantilla, las lecturas biométricas son muestreadas y convertidas a un formato
manejable por la aplicación. A estas muestras procesadas se les denomina planti-
llas.
Las funciones básicas del la implementación del estándar BioAPI son las siguientes:
Captura, permite obtener una lectura biométrica de la huella digital del usuario
mediante un sensor de temperatura instalado en el dispositivo móvil.
Verificación, es utilizada cuando un usuario afirma estar registrado. El sistema
compara los datos biométricos del usuario con el registro almacenado en su base
de datos (comparación uno a uno).
Identificación, también llamada búsqueda o reconocimiento, ocurre cuando la
identidad de un usuario no es conocida. El sistema compara los datos biométricos
del usuario contra todos los registros de su base de datos (comparación uno a
muchos).
Almacenamiento, permite una forma eficiente de almacenamiento de información
de huellas digitales. La información almacenada no es guardada como imagen4 .
A continuación se mencionan algunos procesos necesarios para el adecuado desem-
peño de las funciones de alto nivel descritas anteriormente.

4
Se realiza un proceso de transformación de la imagen, produciendo finalmente 1024 bytes de
información en lugar de los aproximandamente 200 Kbytes de la imagen originalmente capturada.
Procesamiento de imagen, los algoritmos implementados en la biblioteca biométri-
ca permiten analizar las imágenes de huellas digitales y extraer la información que puede
ser usada para la identificación única de una persona. El procesamiento consta de dos
partes. Primero, la imagen es transformada a otra imagen la cual facilita la detección
de caracterı́sticas particulares. Segundo, la imagen es analizada para la detección de
caracterı́sticas locales y globales como el flujo de las protuberancias, puntos detallados,
patrones de huella digital, número de protuberancias, etc. Los resultados de este análisis
son pasados al control de calidad de imagen.
Control de calidad de imagen, este procedimiento es necesario para mantener la
calidad de los datos recolectados. Es muy importante ya que una buena confiabilidad
en la calidad de datos influye directamente en la precisión de la verificación. El control
de calidad de imagen es usado por las funciones de captura y verificación.
Generación de plantilla, en el proceso de captura, extracción de caracterı́sticas,
puntos detallados y conteo de bordes, son organizados en plantillas. Estas son llamadas
plantillas de referencia.
Durante la verificación, cuando se ingresa la huella digital, una plantilla similar es
creada, esta es llamada plantilla muestra.
Proceso de comparación de plantillas, durante la comparación, la plantilla mues-
tra es comparada con un conjunto de plantillas referencia. Debido a que una similitud
del 100 % no es común debido a varios factores, se establece una margen de proba-
bilidad. Esto es realizado mediante algoritmos de comparación que prueban diversas
orientaciones de la imagen extraida y el grado de correspondencia de los detalles. El
algoritmo asigna un valor númerico a la comparación. Posteriormente el valor es com-
parado contra un margen de error pre-establecido. Si el valor númerico es superior del

margen, se declara que se ha obtenido un reconocimiento positivo.
Se definie la ventana de error mediante la configuración del sistema de autenticación.
Se puede seleccionar uno de tres niveles: regular, alto y extra alto.
La tabla 4.1 muestra el desempeño del sistema de autenticación de la iPAQ h5540
para sus diferentes niveles de seguridad.
Falsos Falsos Número

Nivel de
Negativos Positivos promedio de
Seguridad
(FRR) (FAR) intentos
Regular 0.2331 % (1 de 429) 0.0010 % (41 de 4054737) 1.081967
Alto 0.4662 % (2 de 429) 0.0001 % (4 de 4054737) 1.107573
Extra Alto 0.6993 % (3 de 429) 0.0000 % (0 de 4054737) 1.153226
Tabla 4.1: iPAQ Pocket PC - Tasa de Falsos Positivos y Falsos Negativos
4.2.4. Biblioteca ASN.1 y estándar X.509v3
A través de las secciones anteriores se han descrito los módulos principales que con-
forman la Autoridad Certificadora Móvil (hardware, bibilioteca criptográfica, biblioteca
BioAPI). La siguiente sección aborda las técnicas necesarias para dar formato a los
datos del certificado digital apegándose al estándar X.509v3.
El RFC2380 [HPFS02] (Internet X.509 Public Key Infrastructure Certificate and
Certificate Revocation List Profile) especifica a detalle el formato de un certificado di-
gital X.509v3. Este formato está definido a través del lenguaje ASN.1 [ASN02] (Abstract
Syntax Notation One). Debido a esto, es necesario contar una biblioteca que permita
la codificación y decodificación de datos utilizando la sintaxis ASN.1.
ASN.1 es una norma estándar para representación de datos que utilizan muchas
aplicaciones y dispositivos en el sector tecnológico y que permite la normalización y
la comprensión de datos entre distintas plataformas. Si no se está familiarizado con

este lenguaje y con los componentes de un certificado digital X.509v3, se recomienda
ampliamente revisar el apéndice §A el cual proporciona una breve introducción.
Para esta tesis se desarrolló una biblioteca subconjunto del lenguage ASN.1 espe-
cificado en el estándar RFC3280. La biblioteca implementa un codificador y un de-
codificador, los cuales son necesarios para la generación y análisis de los certificados
digitales.
Codificador ASN.1
Este módulo es el encargado de dar formato a todos los datos del certificado digital
(nombre de la entidad final, perı́odo de validez, llave pública, identificador de algoritmo,
etc.). La realización del módulo se fundamentó principalmente en un compilador open
source descrito en [ASN04].
Decodificador ASN.1
El módulo decodificador es utilizado para la verificación y manipulación de los certi-
ficados previamente generados. La implementación está basada en el trabajo realizado
por Peter Gutmann y es descrito en [Gut97].
Para obtener más información de la normatividad ASN.1, consulte la recomendación
X.680 ITU-T [ASN02].
Una vez descritas todos los componentes que conforman la Autoridad Certifica-
dor Móvil se puede explicar los procesos de generación y verificación de certificados
digitales.
4.3. Proceso de generación de un certificado digital
Para poder generar un certificado digital mediante la Autoridad Certificadora Móvil
son necesarios los siguientes pasos:
1. Captura de la información correspondiente a la entidad final (nombre, correo
electrónico, organización, etc.).
2. Selección del perı́odo de validez del certificado digital.
3. Captura de huella digital del usuario final (únicamente en caso que se haya selec-
cionado la generación con información biométrica).
4. Selección del algorimo de firma digital RSA o ECDSA. En el caso de haber selec-
cionado el algoritmo ECDSA se debe seleccionar la curva a utilizar (163k, 192p,
224p, 233k).
Un certificado digital está compuesto por tres estructuras fundamentales [HPFS02]:
certificado TBS (TBSCertificate), identificador de algoritmo (signatureAlgorithm) y
firma digital (signatureValue).
La figura §4.4 muestra cómo se realiza la generación de la estructura TBSCertificate
mediante la información capturada a través de las interfaces gráficas del software. Una
vez terminado el proceso de captura de datos y selección del algoritmo de firma digital
se procede a la generación de llaves y finalmente sólo resta codificar esta información
utilizando la sintaxis ASN.1.
Una vez generada la estructura del certificado TBS se procede a la firma digital
§4.5. Cabe mencionar que la llave privada fue descifrada utilizado el algoritmo AES,
este proceso fue explicado anteriormente §4.3.
Finalmente se genera el certificado digital a partir de las tres estructuras que lo
conforman §4.6.
Versión
Número de Serie
Algoritmo
Parámetros
Entidad Emisora
(Nombre X.500)
No antes de ... Codificador

ASN.1 Certificado TBS
No despues de ...
Entidad Final
(Nombre X.500)
Algoritmo
Parámetros
Lave Pública
Información biométrica
(BioAPI)
iPAQ h5550 Información para generación del

Interfaz gráfica y lector biométrico certificado digital
Figura 4.4: Obtención de parámetros de generación del certificado digital
Llave privada
de la
Autoridad
Certificadora
160 bits
Certificado TBS
SHA-1 Firma digital de la AC
Operación Privada
Algorimo de firma digital

(RSA, ECDSA)
Figura 4.5: Firma digital del certificado
4.4. Proceso de verificación de un certificado digital
Para el proceso de verificación es nesesario seleccionar el certificado digital a ve-
rificar. Posteriormente el software realiza un análisis del certificado para separarlo en
sus tres componentes pricipales (TBSCertificate, signatureAlgorithm, signatureValue)
§4.7. Una vez identificada la estructura TBSCertificate se pasa a través de una función
resumen del tipo SHA-1 y se procede con la verificación digital. La figura §4.8 muestra
el proceso. Nótese que únicamente se está validando la firma digital, una aplicación real
necesita verificar además el perı́odo de validez del certificado digital.

Certificado TBS
Certificado X.509
Certificado TBS
Codificador
Identidicador de Algorit mo ASN.1 Identidicador de Algorit mo
Figura 4.6: Generación del certificado digital X.509
Certificado TBS
Certificado X.509
Certificado TBS
Decodificador
ASN.1 Identidicador de Algoritmo
Identidicador de Algoritmo
Figura 4.7: Separación de las estructuras básicas de un certificado digital
El siguiente capı́tulo muestra el análisis de desempeño de la implementación de la
AC móvil. Además se presenta una comparación entre los criptosistemas RSA y curva
elı́ptica ECC.
Certificado TBS SHA-1 h(m)
Certificado
corrupto
Firma digital de la AC no si
Anillo de ¿iguales?
llaves
publicas
Certificado
verificado
Llave pública
de la AC
h´(m)
Operación Pública
Figura 4.8: Verificación del certificado digital

Capı́tulo 5
Análisis de desempeño
Una de las motivaciones principales para utilizar algoritmos de curva elı́ptica en esta
tesis es la limitante del poder de computo de los dispositivos móviles. En [GGCS02]
se ha verificado que el criptosistema de curva elı́ptica se desempeña en varios aspectos
mejor que el criptosistema RSA.
En este capı́tulo se análiza el desempeño de la implementación de la Autoridad Cer-
tificadora y se compara el criptosistema RSA contra ECDSA. La comparación consiste
en la medición de tiempos en la generación de llaves, generación de firma digital, verifi-
cación de firma, y finalmente el tamaño en bytes de los certificados X.509 v3 generados
(con y sin información biométrica).
En lo que se refiere a esta implementación de la Autoridad Certificadora en un
dispositivo móvil es de gran importancia los tiempos de generación de llaves, ya que esta
operación es la más demandante en el criptosistema RSA. Por ejemplo, la generación
de llaves con RSA de 2048 bits tardó aproximadamente 51 segundos en el PDA HP
5550h, por lo cual se decidió utilizar únicamente RSA de 1024 bits.
El PDA utilizado para las pruebas es el Hewllet-Packard modelo iPAQ h5550. Cuen-
ta con un procesador Intel Xcale de 400 Mhz, 48 MB de ROM, 128 MB de SDRAM,
lector biométrico de huella digital, entre otras cosas.
72
CAPÍTULO 5. ANÁLISIS DE DESEMPEÑO 73
5.1. Resultados obtenidos
5.1.1. Generación de llaves
Para esta prueba se utilizó el software desarrollado con una ligera modificación,
la cual permite medir con mayor exactitud y presición el tiempo de generación de
llaves públicas y privadas en los algoritmos ECDSA y RSA. La prueba consistió en la
selección del algoritmo y la consiguiente generación de 100, 1000 y 2000 pares de llaves.
Los resultados obtenidos son mostrados en la tabla §5.1
Criptosistema de llave públia Tiempo
ECDSA (curva 163k) 12,5 ms

ECDSA (curva 192p) 81,0 ms
RSA (1024 bits) 3650 ms
Tabla 5.1: Tiempo de generación de llaves.
5.1.2. Firma digital
Esta prueba mide el tiempo necesario para firmar un documento digital. Para este
propósito se generó un mensaje aleatorio de 1KB y luego se procedió con la firma digital
RSA y ECDSA. El algoritmo de digestión que se utilizó tanto en RSA como ECDSA
es SHA-1.
Una vez seleccionado el algoritmo de la firma digital y de la generación de sus
respectivas llaves, se generó el mensaje aleatorio, y finalmente se llamaron las rutinas
de firma digital 100, 1000, y 10000 veces. Los tiempos obtenidos fueron consisentes en
los tres casos. Los resultados obtenidos son mostrados en la tabla §5.2
Algoritmo de firma digital Tiempo

RSA (1024 bits) 37,0 ms
Tabla 5.2: Tiempos requeridos para firma digital de un mensaje aleatorio de 1KB.
5.1.3. Verificación de firma digital
Esta prueba mide el tiempo necesario para verificar la firma de un documento digital
de 1KB. Para este propósito se utilizó el mismo mensaje de la prueba de firma digital.
Las rutinas de firma digital fueron ejecutadas 100, 1000, y 10000 veces. Los resul-
tados se muestran en la tabla §5.3
Algoritmo de verificación digital Tiempo

RSA (1024 bits) 8,3 ms
Tabla 5.3: Verificación de la fima digital de un mensaje de 1KB.
5.1.4. Tamaño de certificados digitales
Esta prueba mide únicamente el tamaño en bytes de los certificados X.509 v3 genera-
dos por la Autoridad Certificadora. Los resultados de la tabla §5.4 muestran certificados
generados con RSA y ECDSA con y sin información biométrica de huella digital.
Criptosistema de Sin información Con información

llave públia Biométrica biométrica
ECDSA
592 bytes 1635 bytes
(curva 163k)
ECDSA
(curva 192p)
ECDSA
(curva 224p)
ECDSA
( curva 233k)
RSA
(1024 bits)
Tabla 5.4: Comparación de tamaño en bytes de los certificados X.509 v3
5.2. Análisis de resultados
Esta sección compara los resultados obtenidos con RSA, ECDSA, y la inclusión de
la información biométrica en el certificado digital.
Como era de esperarse ECDSA fue más rápido y eficiente que RSA [GGCS02], de
ahı́ la conveniencia de utilizar este algoritmo especialmente tratándose de dispositivos
relativamente restringidos. En general se puede decir que el mejor desempeño lo tuvo
ECDSA con la curva elı́ptica 163k. Esta curva permitió lograr los mejores tiempos en las
tres pruebas (generación de llaves, firma digital, y verificación de firma digital). Además
debido a los parámetros de la curva 163k, el tamaño del certificado digital generado es
el más pequeño. Todas estas propiedades hacen que ECDSA con la curva 163k sea ideal
para aplicaciones inalámbricas y dispositivos con poco poder computacional. Por otro
lado, esta es la curva que brinda menor seguridad.

5.2.1. Generación de llaves
El algoritmo RSA para generación de llaves es extremadamente lento en compa-
ración a cualquier modalidad de curva elı́ptica (en algunos casos casi en dos ordenes
de magnitud). En la figura §5.1 se muestra una comparación considerando únicamente
ECDSA en las diferentes curvas implementadas.
Generacion de llaves
130 125 ms
120
110
100
90
82 ms
80
Tiempo
70
60
50
40
30
22.5 ms
20
12.5 ms
10
0
163 K 192 P 224 P 233 K
Figura 5.1: Tiempos requeridos para la generación de llaves en Curva Elı́ptica.
5.2.2. Firma digital
En la generación de firma digital el algoritmo más rápido fue ECDSA con la curva
163K. Esto es lógico ya que la curva es tipo Koblitz1 . El algorimo RSA es el más lento
debido al tamaño de su llave privada. La figura §5.2 muestra la comparación entre los
algoritmos.
1
Las curvas Koblitz son una clase de curvas elı́pticas definidas sobre F2m cuyas ecuaciones tienen
coeficientes en F2 . Este tipo de curvas permite realizar muy eficientemente el algoritmo de multiplica-
ción escalar (kP ), lo cual produce un considerable aumento en la velocidad de procesamiento [ECC97].
Generacion de firma digital

37 ms
35
30
25
Tiempo
20
15
10
6.4 ms
5.0 ms
5 3.1 ms 3.4 ms
0
163 K 192 P 224 P 233 K RSA–1024
Figura 5.2: Generación de firma digital de un mensaje de 1KB.
5.2.3. Verificación de firma digital
En esta prueba RSA es mucho más competitivo que en las anteriores. RSA tuvo el
segundo mejor tiempo para la verificación. Esto se debe a una elección conveniente del
exponente público utilizado en la generación de llaves (0x01,0x00,0x01,0x03). Una vez
más el mejor tiempo lo obtuvo ECDSA con la curva 163k. La figura §5.3 muestra la
comparación.
5.2.4. Tamaño de certificados digitales
Aquı́ se realiza la comparación del tamaño en bytes de los certificados generados
con RSA (1024) y ECDSA (163k, 192p, 224p, 233k). La diferencia en tamaño de los
certificados digitales RSA y ECDSA es realmente poca. RSA y ECDSA con la curva
163k solamente tienen una diferencia de 21 bytes. Incluso el tamaño de los certificados
RSA es menor que ECDSA con las curvas 192p, 224p, y 233k. La razón que los certifi-
Verificacion de firma digital

17.9 ms
18
16.5 ms
16
14
Tiempo
12 11.7 ms
10
8.0 ms 8.3 ms
8
0 163 K 192 P 224 P 233 K RSA–1024
Figura 5.3: Comparación en verificación de firma digital
cados de curva elı́ptica sean incluso de mayor tamaño que los de RSA es debido a que el
estándar ECDSA requiere que toda la información de la curva elı́ptica (coeficientes a y
b, orden, cofactor, campo caracterı́stico, polinomio generador, etc.) utilada apararezca
en el certificado digital. La figura §5.4 muestra el tamaño en bytes de los certificados
generados con RSA y ECDSA con y sin información biométrica de huella digital.2
2
En el apéndice A se muestran los vaciados ASN.1 y hexadecimal de los certificados en los cuales
se realizó esta prueba.
Comparacion de Certificados X.509v3 [C/S] Informacion Biometrica

1702 * 1706 *
1635 * 1661 * 1656 *
1600
1400
1200
1000
Bytes
800
663
592 618 613
600 569
400
200
0 163 K 192 P 224 P 233 K RSA–1024

* Certificados con informacion de huella digital
Figura 5.4: Comparación de certificados con y sin información biométrica

Conclusiones
El presente trabajo de tesis consiste en el diseño e implementación de una Autoridad
Certificadora en un dispositivo móvil (PDA), capaz de incluir información biométrica
de huella digital en los campos de extensión de los certificados digitales emitidos bajo
el estándar X.509 v3.
El objetivo primario de la tesis es el de proporcionar la infraestructura necesaria para
robustecer el servicio de autenticación en transferencias electrónicas tanto en ambientes
alámbricos como inalámbricos mediante el uso de certificados digitales. El software
desarrollado aunado al dispositivo móvil permiten la implementación y/o modificación
de protocolos de comunicación que requieran un sistema sólido de autenticación de
entidades en tres niveles; es decir, autenticación en base de algo que el usuario conozca
(frase clave o contraseña), algo que el usuario posea (certificado digital), y algo que el
usuario sea (información biométrica de huella digital) .
Los certificados digitales emitidos por la Autoridad Certificadora pueden ser genera-
dos utilizando criptografı́a de llave pública basada en el criptosistema de curva elı́ptica
ECC (curvas 163k, 192p, 224p, y 233k) o en el algoritmo RSA (1024 bits). La integri-
dad de los datos contenidos en los certificados digitales está respaldada por el algoritmo
de digestión SHA-1 (160 bits). Las llaves privadas tanto de la autoridad certificadora
como la de los usuarios están protegidas con el algoritmo simétrico AES con longitud
de llave de 128 bits; los 128 bits de la llave AES son obtenidos mediante el algoritmo
80
Conclusiones 81
de digestión MD5 que recibe como entrada la frase clave del propietario.
Las contribuciones del presente trabajo de tesis pueden sumarizarse como sigue:
Proveer la infraestructura necesaria para robustecer el servicio de autenticación en
transferencias electrónicas mediante la incorporación de información biométrica
a un certificado digital X.509 v3.
Permitir la ubicuidad de Autoridad Certificadora a través del PDA con lector
biométrico integrado.
Implementación de una biblioteca subconjunto del lenguage ASN.1 para la gene-
ración de certificados digitales compatibles con el estándar X.509v3.
Desarrollo de funciones de alto nivel en lenguaje C++ Embedded para la utiliza-
ción de la biblioteca criptográfica RCT [ERHK02].
Trabajo a futuro
Existen varios aspectos que pueden mejorar considerablemente este trabajo de tesis.
Debido a que la tesis únicamente construyó la infraestructura para robustecer el
servicio de autenticación, el paso siguiente es la implementación de una aplicación
que utilice esta plataforma. Por ejemplo, se puede hacer una ligera modificación
al protocolo WTLS para que permita autenticación biométrica entre las entidades
que tratan de intercambiar información.
Dependiendo el tipo de aplicación puede ser necesario generar una lista de revo-
cación de certificados (CRL). Esto implicarı́a también la implementación de un
repositorio que permita el acceso a dicha lista más el desarrollo de las entidades
que necesarias para dar mantenimiento al CRL.

Conclusiones 82
Serı́a extremadamente conveniente que la autoridad certificadora soportará el
estándar PKCS12. Este estándar permite la manipulación de certificado digitales,
y llaves privadas de manera segura en un archivo único, el cual es compatible con
navegadores como Netscape e Internet explorer.
La información biométrica que se incluye en los certificados digitales es de 1KB.
Esta información puede ser comprimida para reducir el tamaño del certificado
hasta un 50 %.
Apéndice A
ASN.1 (Abstract Syntax Notation

One)
El propósito de esta sección es el de brindar una breve introducción a la Notación
de Sintaxis Abstracta Uno (ASN.1) para ası́ poder entender de una mejor forma la
generación de los certificados digitales X.509. Si se desea profundizar a detalle sobre
ASN.1 se recomiendan [Lar99, Gro04, ASN04, Dub00, ASN02].
ASN.1 es un lenguaje usado para describir formalmente la semántica de los datos
transmitidos a través de una red. Las diferentes entidades que se comunican en un
sistema distribuido pueden tener diferentes representaciones de sus respectivos tipos de
datos; por ejemplo, el número de bits requeridos para representar un número flotante.
Debido a esto, es importante tener una forma de describir datos de una manera que sea
independiente del la representación particular de cada sistema.
Entre las principales cualidades de ASN.1 se encuentran las siguientes:
Es un estándar internacional, independiente de plataformas, de vendedores, y de
notaciones de lenguaje.
Es soportado por reglas las cuales determinan los patrones de bits exactos, para
representar los valores de las estructuras de datos; cuando éstas, tienen que ser
83
APÉNDICE A. ASN.1 (ABSTRACT SYNTAX NOTATION ONE) 84
transferidas sobre una red de computadoras.
Es soportado por herramientas disponibles para muchas plataformas (Unix, Linux,
Win32, etc.) y varios lenguajes de alto nivel que mapean la notación ASN.1,
a través de un compilador, en estructuras de datos definidas en el lenguaje de
programación de elección; por ejemplo, C++, Java, Pascal, etc.
ASN.1 proporciona una gama de estructuras de datos la cual es generalmente
mucho más rica que la de los lenguajes de programación genéricos, tales como
tamaño de enteros, asignación de nombre a estructuras, tipos de caracteres y
tipos de cadenas.
Para poder explicar de una forma intuitiva el lenguaje ASN.1 consideremos el si-
guiente ejemplo:
Rectangulo ::= SEQUENCE {

alto INTEGER,
ancho INTEGER
}
La especificación ASN.1 anterior, describe un tipo de dato construido denominado
Rectangulo, el cual contiene dos campos enteros. Esta especificación es una clase de
estructura de dato que cualquier entidad puede enviar o recibir dentro de un siste-
ma distribuido. Por ejemplo, Rectangulo puede ser codificado y enviado a un destino
utilizando el protocolo TCP.
Para que la especificación de Rectangulo sea procesada por un compilador ASN.1
y se genere el código fuente en el lenguaje deseado (C++, Java, entre otros), se debe
de insertar en un módulo de la siguiente forma:

EjemploModulo1
{ iso org(3) dod(6) internet(1) private(4)
enterprise(1) spelio(9363) software(1)
asn1c(5) docs(2) usage(1) 1 }
DEFINITIONS AUTOMATIC TAGS ::=
BEGIN
-- Este es un comentario
Rectangulo ::= SEQUENCE {

alto INTEGER,
ancho INTEGER
}
END
El módulo consiste en un encabezado, el cual es su propio nombre (EjemploMo-
dulo1), el Indentificador de Objeto (OID) que esta entre llaves [iso org(3) dod(6) ...
docs(2) usage(1) 1] y que es explicado en la siguiente sección; DEFINITIONS es una
palabra reservada de ASN.1 al igual que AUTOMATIC TAGS. La sentencia ::= BEGIN,
indica el inicio del las definiciones ASN.1, mientras que la sentencia END finaliza el
módulo. Para más información sobre la compilación y sintaxis del lenguaje ASN.1 véase
[Lar99, Dub00, ASN02]
A continuación se explica brevemente los tipos de datos ASN.1 utilizados en la
presente tesis para la generación de certifiados X.509.
A.1. Tipos de datos básicos en ASN.1
A.1.1. Tipo BOOLEAN
El tipo BOOLEAN es utilizado para la representación de valores binarios (CIER-
TO/FALSO, ENCENDIDO/APAGADO, SI/NO, etc.). En esta tesis se utiliza este tipo

de dato para especificar que la extensión de un certificado digital X.509 v3 es “CRÍTICA
O NO CRÍTICA ”.
A.1.2. Tipo INTEGER
El tipo INTEGER es usado para representar números enteros sin restricción en su
tamaño. Los siguientes son unos ejemplos de las diferentes formas de definir un entero
en ASN.1:
EnteroSimple ::= INTEGER -- entero sin restricciones

EnteroPositivo ::= INTEGER (0..127) -- entero con longitud limitada
EnteroNegativo ::= INTEGER (MIN..0) -- entero negativo
El tipo INTEGER es utilizado en la generación del certificado X.509 para especificar
el número serial del certificado expedido por la autoridad certificadora.
A.1.3. Tipo ENUMERATED
Este tipo es el equivalente semántico al tipo INTEGER pero con valores enteros
explicitamente nombrados. Ejemplo:
TipoDeCertificadoX509 ::= ENUMERATED {

Version1, -- adquiere el valor 0
Version2, -- adquiere el valor 1
Version3 -- adquiere el valor 2
}
A.1.4. Tipo OCTET STRING
Este tipo de dato permite representar secuencias de bytes, las cuales pueden ser
utilizadas para transmitir datos serializados a través de un sistema distribuido; por

ejemplo, archivos de video, imágenes, voz, etc. OCTET STRING es utilizado en esta
tesis para representar algunos parámetros en los certificados basados en curva elı́ptica
(coeficientes de la curva, cofactor).
A.1.5. Tipo BIT STRING
Este tipo de dato permite la representación de cadenas de bits y es principalmente
utilizado para aplicaciones de seguridad. En este caso particular, se utiliza el tipo BIT
STRING para la representación de las firmas digitales generadas por los algoritmos
RSA y ECDSA.
A.1.6. Tipo IA5String
Este tipo de cadena está compuesto por caracteres ASCII. Cada carácter utiliza los
siete bits menos significativos de un byte; por lo cual, existen 128 caracteres diferentes.
En el certificado X.509 se utiliza este tipo para las direcciones de correo electrónico
tanto de la entidad final como la entidad emisora.
A.1.7. Tipo PrintableString
Este es un tipo de cadena que cuenta únicamente con un alfabeto imprimible. Este
alfabeto está compuesto por los siguientes caracteres: “’”, “( ”, “) ”, “+ ”, “, ”, “- ”, “.
”, “/ ”, digitos (“0 ”... “9 ”), “: ”, “= ”, “? ”, letras mayúsculas y minúsculas (“A ”..
“Z ”y “a ”.. “Z ”).
El tipo de dato PrintableString es utilizado para especificar el nombre de la entidad
final y la entidad emisora.

A.1.8. Tipo UTCTime
Este tipo de dato permite la manipulación de la fecha y hora. Los valores que puede
tomar este tipo de dato son cadenas de caracteres del siguiente tipo:
yymmddhhmmZ
yymmddhhmmssZ
yymmddhhmm+hhmm
yymmddhhmm-hhmm
yymmddhhmmss+hhmm
yymmddhhmmss-hhmm
“yymmdd ”representa el año (00 .. 99), mes (01 .. 12), dı́a (01 .. 31), y “hhmmss
”son horas (00 .. 23), minutos (00 .. 59), segundos (00 ..59).
La “Z ”es usada comunmente como sufijo que indica que los valores fueron tomados
de acuerdo al GMT (Greenwich Mean Time). Si está presente el “+hhmm ”o el “-hhmm
”entonces el tipo de dato expresa un valor de tiempo local y está referenciado al GMT
[Lar99].
En la generación de los certificados digitales por la autoridad certificadora imple-
mentada en esta tesis se utiliza el tiempo GMT para la asignación de los perı́odos de
validez del certificado.
A.1.9. Tipo OID (OBJECT IDENTIFIER)
El OID es usado para representar un identificador único de cualquier objeto. Existe
una organización (ASN.1 Information Site) la cual se encarga de asignar los OID de
acuerdo a un árbol jerárquico. Por ejemplo, el OID que identifica el algoritmo de firma
digital con curva elı́ptica y SHA-1 (ECDSA-with-SHA-1 ) es el siguiente:

ecdsa-with-SHA1 OBJECT IDENTIFIER ::= {

iso(1) member-body(2) usa(840) ansi-x962(10045)
signatures(4) id-ecSigType(1)
}
Para más información de la jerarquı́a y asignaciones de OIDs véase [ASN05].
A.2. Estructura de datos construidos
Existe una gran variedad de datos construidos pero en esta sección sólo se mencionan
los que son utilizados en la generación de certificados digitales X.509.
A.2.1. Tipo SEQUENCE
Este tipo representa una colección ordenada de otros tipos de datos simples (IN-
TEGER, BOOLEAN, PrintabeString, etc) o construidos. El tipo de dato construido
SEQUENCE es muy similar a la sentencia struct del lenguaje C.
A.2.2. Tipo SEQUENCE OF
Este tipo representa una lista de tipos construidos. Por ejemplo:
MuchosRectangulos ::= SEQUENCE OF Rectangulo
A.2.3. Tipo SET
Al igual que el tipo SEQUENCE, este es una colección de tipos simples o complejos
con la particularidad que el orden no es imporante.

A.2.4. Tipo CHOICE
Este tipo permite la elección entre varios subtipos especificados. CHOICE es similar
a la sentencia union del lenguaje C. El siguiente ejemplo define un tipo de código de
respuesta, el cual puede ser ya sea un entero o un valor binario.
CodigoDeRespuesta ::= CHOICE {

codigoEntero INTEGER,
codigoBoleano BOOLEAN
}
A.3. Descripción de la sintaxis ASN.1 de un certi-
ficado X.509 V3
Un certifiado X.509 v3 es definido mediante ASN.1 de la siguiente forma [HPFS02]:
Certificate ::= SEQUENCE {

tbsCertificate TBSCertificate,
signatureAlgorithm AlgorithmIdentifier,
signatureValue BIT STRING
}
Para el cálculo de la firma digital, los datos firmados deben de estar codificados
usando ASN.1 (DER) [X.690] [?, HPFS02]. La codificación ASN.1 DER está basada en
etiquetas, longitud de campos y codificación de valores para cada elemento.
A.3.1. Tipo tbsCertificate
El tipo tbsCertificate contiene los nombres de la entidad final y el emisor, la llave
pública asociada a la entidad final, un perı́odo de validez, extensiones, versión, número

serial, entre otros campos. A continuación se muestra la sintaxis para este tipo de dato
compuesto.
TBSCertificate ::= SEQUENCE {

version [0] EXPLICIT Version DEFAULT v1,
serialNumber CertificateSerialNumber,
signature AlgorithmIdentifier,
issuer Name,
validity Validity,
subject Name,
subjectPublicKeyInfo SubjectPublicKeyInfo,
issuerUniqueID [1] IMPLICIT UniqueIdentifier OPTIONAL,
-- If present, version MUST be v2 or v3
subjectUniqueID [2] IMPLICIT UniqueIdentifier OPTIONAL,
-- If present, version MUST be v2 or v3
extensions [3] EXPLICIT Extensions OPTIONAL
-- If present, version MUST be v3
}
Como se puede observar el tipo de dato tbsCertificate está compuesto a su vez,
por más tipos de datos compuestos. A continuación se listan algunos de estos campos
[HPFS02].
Version ::= INTEGER { v1(0), v2(1), v3(2) }

CertificateSerialNumber ::= INTEGER
Validity ::= SEQUENCE {
notBefore Time,
notAfter Time }
Time ::= CHOICE {
utcTime UTCTime,
generalTime GeneralizedTime }
UniqueIdentifier ::= BIT STRING
SubjectPublicKeyInfo ::= SEQUENCE {
algorithm AlgorithmIdentifier,
subjectPublicKey BIT STRING }
Extensions ::= SEQUENCE SIZE (1..MAX) OF Extension
Extension ::= SEQUENCE {
extnID OBJECT IDENTIFIER,

critical BOOLEAN DEFAULT FALSE,
extnValue OCTET STRING }
A.3.2. Tipo signatureAlgorithm
El campo signatureAlgorithm contiene el identificador para el algoritmo crip-
tográfico usado por la autoridad certificadora para firmar el certificado. El RFC3279
[PHB02] lista los algoritmos soportados.
La sintaxis ASN.1 es la siguiente:
AlgorithmIdentifier ::= SEQUENCE {

algorithm OBJECT IDENTIFIER,
parameters ANY DEFINED BY algorithm OPTIONAL }
A.3.3. Tipo signatureValue
El campo signatureValue contiene la firma digital del tbsCertificate. La codi-
ficación ASN.1 DER del tbsCertificate es usada como entrada para la función de
firma de la autoridad certificadora. El valor resultante es codificado como BIT STRING
e incluido en el campo de firma del certificado X.509. Para más información sobre la
codificación de firmas digitales RSA y ECDSA véase [PHB02].

Apéndice B
Ejemplos de certificados X.509v3
A continuación se muestran vaciados hexadecimales y ASN.1 de ejemplos de certifi-
cados (RSA y ECC) creados mediante la Autoridad Certificadora que se implementó en
este trabajo.
B.1. Certificado RSA sin datos biométricos
La tabla §B.1 es una pequeña explicación de como es mapeado un certificado digital
a la sintaxis ASN.1. En la tabla se muestra un listado de los tipos más importantes
de datos ASN.1 que componen el certificado digital basado en RSA. En la columna de
la izquierda se muestra el valor hexadecimal del byte en el cual inicia la codificación
ASN.1, mientras que la columna derecha proporciona una breve descripción.
Vaciado ASN.1
1 0000 30 261: SEQUENCE {
2 0004 30 1CA: SEQUENCE {
3 0008 A0 3: [CONTEXT-SPECIFIC 0] {
4 000A 02 1: INTEGER 2
5 : }
6 000D 02 3: INTEGER 7731050
7 0012 30 D: SEQUENCE {
8 0014 06 9: OBJECT IDENTIFIER
9 : sha1withRSAEncryption (1 2 840 113549 1 1 5)
10 001F 05 0: NULL
93
APÉNDICE B. EJEMPLOS DE CERTIFICADOS X.509V3 94
11 : }
12 0021 30 69: SEQUENCE {
13 0023 31 11: SET {
14 0025 30 F: SEQUENCE {
15 0027 06 3: OBJECT IDENTIFIER commonName (2 5 4 3)
16 002C 13 8: PrintableString ’Movil CA’
17 : }
18 : }
19 0036 31 B: SET {
20 0038 30 9: SEQUENCE {
21 003A 06 3: OBJECT IDENTIFIER countryName (2 5 4 6)
22 003F 13 2: PrintableString ’MX’
23 : }
24 : }
25 0043 31 24: SET {
26 0045 30 22: SEQUENCE {
27 0047 06 9: OBJECT IDENTIFIER emailAddress (1 2 840 113549 1 9 1)
28 0052 16 15: IA5String ’movil.ca@cinvestav.mx’
29 : }
30 : }
31 0069 31 D: SET {
32 006B 30 B: SEQUENCE {
33 006D 06 3: OBJECT IDENTIFIER localityName (2 5 4 7)
34 0072 13 4: PrintableString ’D.F.’
35 : }
36 : }
37 0078 31 12: SET {
38 007A 30 10: SEQUENCE {
39 007C 06 3: OBJECT IDENTIFIER organizationName (2 5 4 10)
40 0081 13 9: PrintableString ’ITESM CCM’
41 : }
42 : }
43 : }
44 008C 30 1E: SEQUENCE {
45 008E 17 D: UTCTime ’050221000000Z’
46 009D 17 D: UTCTime ’060329000000Z’
47 : }
48 00AC 30 71: SEQUENCE {
49 00AE 31 1B: SET {
50 00B0 30 19: SEQUENCE {
51 00B2 06 3: OBJECT IDENTIFIER commonName (2 5 4 3)
52 00B7 13 12: PrintableString ’Guillermo Martinez’
53 : }
54 : }
55 00CB 31 B: SET {
56 00CD 30 9: SEQUENCE {
57 00CF 06 3: OBJECT IDENTIFIER countryName (2 5 4 6)
58 00D4 13 2: PrintableString ’MX’
59 : }
60 : }
61 00D8 31 22: SET {
62 00DA 30 20: SEQUENCE {

63 00DC 06 9: OBJECT IDENTIFIER emailAddress (1 2 840 113549 1 9 1)
64 00E7 16 13: IA5String ’g_m_silva@yahoo.com’
65 : }
66 : }
67 00FC 31 D: SET {
68 00FE 30 B: SEQUENCE {
69 0100 06 3: OBJECT IDENTIFIER localityName (2 5 4 7)
71 : }
72 : }
73 010B 31 12: SET {
74 010D 30 10: SEQUENCE {
75 010F 06 3: OBJECT IDENTIFIER organizationName (2 5 4 10)
76 0114 13 9: PrintableString ’CINVESTAV’
77 : }
78 : }
79 : }
80 011F 30 9F: SEQUENCE {
81 0122 30 D: SEQUENCE {
84 012F 05 0: NULL
85 : }
86 0131 03 8D: BIT STRING 0 unused bits, encapsulates {
87 0135 30 89: SEQUENCE {
88 0138 02 80: INTEGER
89 : 1B 35 9E 03 29 B5 71 F2 3F 50 F5 29 0C AC B2 FA
90 : 8B 27 C4 BD 74 C3 BC 07 21 3C BE AE 56 A2 53 A8
91 : CB 94 20 1B 34 B9 18 21 83 33 BD 5D E7 49 2D B5
92 : 7C 92 F5 1E 5D 00 D4 0D 67 74 9B 58 E8 59 EE 6C
93 : AF 3F 21 C1 EA 55 7C ED 6E 2F 90 F6 D9 75 FA BD
94 : D8 BE 1F D7 C2 E3 C3 7D 04 15 2B D5 B3 B3 97 45
95 : 47 68 BA 2C F7 86 67 AD 57 B5 6C E2 1A 4E B5 F0
96 : 90 B5 48 0A E4 E9 0A F9 E3 17 57 87 4F 77 EF DF
97 01BB 02 4: INTEGER 16777477
98 : }
99 : }
100 : }
101 01C1 A3 F: [CONTEXT-SPECIFIC 3] {
102 01C3 30 D: SEQUENCE {
103 01C5 30 B: SEQUENCE {
104 01C7 06 5: OBJECT IDENTIFIER ’2 23 42 7 5 2’
105 01CE 04 2: OCTET STRING
106 : 00 00
107 : }
108 : }
109 : }
110 : }
111 01D2 30 D: SEQUENCE {
112 01D4 06 9: OBJECT IDENTIFIER

114 01DF 05 0: NULL
115 : }
116 01E1 03 81: BIT STRING 0 unused bits
117 : 05 B7 4F 75 92 56 54 86 B0 14 35 0A F3 7D 15 87
118 : DE 4C F9 07 DE 40 F2 F2 A6 CD 51 F2 F5 10 CA 60
119 : 69 5E 48 22 86 1D C7 46 17 91 E6 71 4D B5 7C 99
120 : CA BE A6 90 39 A1 57 0A CB A4 CF 87 A5 58 16 F1
121 : 83 78 09 5A A1 9E 58 CF A1 3C C9 56 A2 B8 C4 7C
122 : 28 55 53 48 C5 FE 9A 59 25 D6 11 32 EC A3 6C B5
123 : 18 0B BF 34 A5 0B D4 99 A1 59 1C 92 01 1D E3 39
124 : 39 49 B6 3C C9 FF 83 D8 C7 B4 BB E8 FE AA 2B D4
125 : }
Vaciado Hexadecimal
1 0000 30 82 02 61 30 82 01 CA A0 03 02 01 02 02 03 75
2 0010 F7 6A 30 0D 06 09 2A 86 48 86 F7 0D 01 01 05 05
3 0020 00 30 69 31 11 30 0F 06 03 55 04 03 13 08 4D 6F
4 0030 76 69 6C 20 43 41 31 0B 30 09 06 03 55 04 06 13
5 0040 02 4D 58 31 24 30 22 06 09 2A 86 48 86 F7 0D 01
6 0050 09 01 16 15 6D 6F 76 69 6C 2E 63 61 40 63 69 6E
7 0060 76 65 73 74 61 76 2E 6D 78 31 0D 30 0B 06 03 55
8 0070 04 07 13 04 44 2E 46 2E 31 12 30 10 06 03 55 04
9 0080 0A 13 09 49 54 45 53 4D 20 43 43 4D 30 1E 17 0D
10 0090 30 35 30 32 32 31 30 30 30 30 30 30 5A 17 0D 30
11 00a0 36 30 33 32 39 30 30 30 30 30 30 5A 30 71 31 1B
12 00b0 30 19 06 03 55 04 03 13 12 47 75 69 6C 6C 65 72
13 00c0 6D 6F 20 4D 61 72 74 69 6E 65 7A 31 0B 30 09 06
14 00d0 03 55 04 06 13 02 4D 58 31 22 30 20 06 09 2A 86
15 00e0 48 86 F7 0D 01 09 01 16 13 67 5F 6D 5F 73 69 6C
16 00f0 76 61 40 79 61 68 6F 6F 2E 63 6F 6D 31 0D 30 0B
17 0100 06 03 55 04 07 13 04 44 2E 46 2E 31 12 30 10 06
18 0110 03 55 04 0A 13 09 43 49 4E 56 45 53 54 41 56 30
19 0120 81 9F 30 0D 06 09 2A 86 48 86 F7 0D 01 01 05 05
20 0130 00 03 81 8D 00 30 81 89 02 81 80 1B 35 9E 03 29
21 0140 B5 71 F2 3F 50 F5 29 0C AC B2 FA 8B 27 C4 BD 74
22 0150 C3 BC 07 21 3C BE AE 56 A2 53 A8 CB 94 20 1B 34
23 0160 B9 18 21 83 33 BD 5D E7 49 2D B5 7C 92 F5 1E 5D
24 0170 00 D4 0D 67 74 9B 58 E8 59 EE 6C AF 3F 21 C1 EA
25 0180 55 7C ED 6E 2F 90 F6 D9 75 FA BD D8 BE 1F D7 C2
26 0190 E3 C3 7D 04 15 2B D5 B3 B3 97 45 47 68 BA 2C F7
27 01a0 86 67 AD 57 B5 6C E2 1A 4E B5 F0 90 B5 48 0A E4
28 01b0 E9 0A F9 E3 17 57 87 4F 77 EF DF 02 04 01 00 01
29 01c0 05 A3 0F 30 0D 30 0B 06 05 67 2A 07 05 02 04 02
30 01d0 00 00 30 0D 06 09 2A 86 48 86 F7 0D 01 01 05 05
31 01e0 00 03 81 81 00 05 B7 4F 75 92 56 54 86 B0 14 35
32 01f0 0A F3 7D 15 87 DE 4C F9 07 DE 40 F2 F2 A6 CD 51
33 0200 F2 F5 10 CA 60 69 5E 48 22 86 1D C7 46 17 91 E6
34 0210 71 4D B5 7C 99 CA BE A6 90 39 A1 57 0A CB A4 CF
35 0220 87 A5 58 16 F1 83 78 09 5A A1 9E 58 CF A1 3C C9
36 0230 56 A2 B8 C4 7C 28 55 53 48 C5 FE 9A 59 25 D6 11
37 0240 32 EC A3 6C B5 18 0B BF 34 A5 0B D4 99 A1 59 1C
38 0250 92 01 1D E3 39 39 49 B6 3C C9 FF 83 D8 C7 B4 BB
39 0260 E8 FE AA 2B D4
HEX: Dato ASN.1 Descripción
Esta secuencia encapsula todo el certificado digital; es

0000: SEQUENCE decir, las tres partes que lo conforman: tbsCertificate,
signatureAlgorithm, y signatureValue.
Aquı́ inicia el tipo tbsCertificate el cual tiene una lon-
0004: SEQUENCE
gitud de 0x1CA bytes.
El valor 2 indica que se trata de un certificado X.509
000A: INTEGER
versión 3 (0 → v1, 1 → v2, 2 → v3).
000D: INTEGER El valor 7731050 es el número serial del certificado.
Identificador del algoritmo de firma digital utilizado

0014: OBJECT ID
(sha1withRSAEncryption).
0021: SEQUENCE Inicia el nombre X.500 de la entidad emisora.
Inicia la especificación del perı́odo de validez del certifi-

008C: SEQUENCE
cado. Este SEQUENCE encapsula los valores UTCTime.
00AC: SEQUENCE Inicia el nombre X.500 de la entidad final (el usuario).
Inicia la información de la llave pública almacenada en

el certificado digital. Incluye el algorimo utilizado (RSA
011F: SEQUENCE
y SHA-1) y también la llave pública que está compuesta
por la pareja (n,e).
Inicia el campo para la inclusión de las extensiones del

01C1: CONTEXT-ESPECIF 3
certificado digital..
Identificador de objeto para la extensión. Esta extensión
01C7: OBJECT ID (2 23 42 7 5 2) es utilizada para agilizar el proceso de
parseo de la Autoridad Certificadora.
Inicia el campo que identifica al algoritmo utilizado para
01D2: SEQUENCE
la generación de la firma digital (signatureAlgorithm).
Campo que contiene el valor de la firma digital
01E1: BIT STRING
(signatureValue).
Tabla B.1: Explicación de la sintaxis ASN.1 de un certificado RSA sin información

biométrica
B.2. Certificado ECC con datos biométricos
La tabla §B.2 explica brevemente el vaciado ASN.1 del certificado digital.
Vaciado ASN.1
1 0000 30 6A6: SEQUENCE {
2 0004 30 652: SEQUENCE {
4 000A 02 1: INTEGER 2
5 : }
6 000D 02 3: INTEGER 7731168
7 0012 30 B: SEQUENCE {
8 0014 06 7: OBJECT IDENTIFIER ecdsa-with-SHA1 (1 2 840 10045 4 1)
9 001D 05 0: NULL
10 : }
11 001F 30 69: SEQUENCE {
12 0021 31 11: SET {
13 0023 30 F: SEQUENCE {
14 0025 06 3: OBJECT IDENTIFIER commonName (2 5 4 3)
15 002A 13 8: PrintableString ’Movil CA’
16 : }
17 : }
18 0034 31 B: SET {
19 0036 30 9: SEQUENCE {
20 0038 06 3: OBJECT IDENTIFIER countryName (2 5 4 6)
21 003D 13 2: PrintableString ’MX’
22 : }
23 : }
24 0041 31 24: SET {
25 0043 30 22: SEQUENCE {
26 0045 06 9: OBJECT IDENTIFIER emailAddress (1 2 840 113549 1 9 1)
27 0050 16 15: IA5String ’movil.ca@cinvestav.mx’
28 : }
29 : }
30 0067 31 D: SET {
31 0069 30 B: SEQUENCE {
32 006B 06 3: OBJECT IDENTIFIER localityName (2 5 4 7)
34 : }
35 : }
36 0076 31 12: SET {
37 0078 30 10: SEQUENCE {
38 007A 06 3: OBJECT IDENTIFIER organizationName (2 5 4 10)
39 007F 13 9: PrintableString ’ITESM CCM’
40 : }
41 : }
42 : }
43 008A 30 1E: SEQUENCE {
44 008C 17 D: UTCTime ’050221000000Z’
45 009B 17 D: UTCTime ’060329000000Z’

46 : }
47 00AA 30 71: SEQUENCE {
48 00AC 31 1B: SET {
49 00AE 30 19: SEQUENCE {
50 00B0 06 3: OBJECT IDENTIFIER commonName (2 5 4 3)
51 00B5 13 12: PrintableString ’Guillermo Martinez’
52 : }
53 : }
54 00C9 31 B: SET {
55 00CB 30 9: SEQUENCE {
56 00CD 06 3: OBJECT IDENTIFIER countryName (2 5 4 6)
57 00D2 13 2: PrintableString ’MX’
58 : }
59 : }
60 00D6 31 22: SET {
61 00D8 30 20: SEQUENCE {
62 00DA 06 9: OBJECT IDENTIFIER emailAddress (1 2 840 113549 1 9 1)
63 00E5 16 13: IA5String ’g_m_silva@yahoo.com’
64 : }
65 : }
66 00FA 31 D: SET {
67 00FC 30 B: SEQUENCE {
68 00FE 06 3: OBJECT IDENTIFIER localityName (2 5 4 7)
70 : }
71 : }
72 0109 31 12: SET {
73 010B 30 10: SEQUENCE {
74 010D 06 3: OBJECT IDENTIFIER organizationName (2 5 4 10)
75 0112 13 9: PrintableString ’CINVESTAV’
76 : }
77 : }
78 : }
79 011D 30 115: SEQUENCE {
80 0121 30 D2: SEQUENCE {
81 0124 06 7: OBJECT IDENTIFIER ecPublicKey (1 2 840 10045 2 1)
82 012D 30 C6: SEQUENCE {
83 0130 02 1: INTEGER 1
84 0133 30 1D: SEQUENCE {
86 : characteristic-two-field (1 2 840 10045 1 2)
87 013E 30 12: SEQUENCE {
88 0140 02 2: INTEGER 233
90 : tpBasis-characteristic-two (1 2 840 10045 1 2 3 2)
91 014F 02 1: INTEGER 74
92 : }
93 : }
94 0152 30 40: SEQUENCE {
95 0154 04 1E: OCTET STRING
96 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
97 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00
98 0174 04 1E: OCTET STRING
99 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
100 : 00 00 00 00 00 00 00 00 00 00 00 00 00 01
101 : }
102 0194 03 3E: BIT STRING 0 unused bits
103 : 04 01 72 32 BA 85 3A 7E 73 1A F1 29 F2 2F F4 14
104 : 95 63 A4 19 C2 6B F5 0A 4C 9D 6E EF AD 61 26 01
105 : DB 53 7D EC E8 19 B7 F7 0F 55 5A 67 C4 27 A8 CD
106 : 9B F1 8A EB 9B 56 E0 C1 10 56 FA E6 A3
107 01D4 02 1D: INTEGER
108 : 80 00 00 00 00 00 00 00 00 00 00 00 00 00 06 9D
109 : 5B B9 15 BC D4 6E FB 1A D5 F1 73 AB DF
110 01F3 02 1: INTEGER 4
111 : }
112 : }
113 01F6 03 3E: BIT STRING 0 unused bits
114 : 04 01 0A EB EA CC A8 19 97 60 CB 5B 69 3D 97 97
115 : 45 1B DE 0A 5A C8 2D 73 B7 C2 64 66 6E 7F 94 01
116 : 6C A5 E5 DE 79 3F 6E 19 83 93 7E 78 1D FD AA D9
117 : 06 48 E6 81 D5 13 BD DC FD 30 2A C3 D0
118 : }
120 023A 30 41C: SEQUENCE {
121 023E 30 B: SEQUENCE {
122 0240 06 5: OBJECT IDENTIFIER ’2 23 42 7 5 2’
123 0247 04 2: OCTET STRING
124 : 03 01
125 : }
126 024B 30 40B: SEQUENCE {
127 024F 06 5: OBJECT IDENTIFIER biometric-BIR (2 23 42 7 5 1)
128 0256 04 400: OCTET STRING
129 : 90 01 F4 01 F4 01 00 00 00 00 00 00 00 08 00 55
130 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
131 : 00 00 00 00 00 00 04 00 00 00 04 00 00 04 00 00
132 : 04 32 32 32 32 32 00 00 FF FF FF FF FF FF FF FF
133 : FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
164 : FF FF FF FF FF FF FF FF 00 00 00 0A 18 18 18 1A
165 : 1E 1E 1E 14 5E 2A 22 58 0C 27 88 38 BE 8D F7 EE
166 : 8D F7 4E 72 35 50 32 3D 88 B8 E0 C2 6D 12 DD 86
167 : 00 32 59 1E 3A 4C 3F 3B 73 33 42 68 36 5B 8F 0F
168 : 9B 8C 05 D7 74 09 DA 47 21 53 B3 E2 5E B5 D9 85
169 : 9E F5 96 A9 EB BD B4 EE EF B4 E8 09 62 12 11 8A
170 : FA 02 3A 20 0A 96 F3 18 90 F7 1C C4 E2 00 00 00
171 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
172 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
173 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
174 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
175 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
176 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
177 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
178 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
179 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
180 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
181 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
182 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
183 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
184 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
185 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
186 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
187 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
188 : 00 00 00 00 00 00 00 00 00 00 00 00 00 8A 58 45
189 : 00 74 77 58 68 46 7B 59 48 66 40 69 00 00 00 00
190 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
191 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
192 : 00 00 00 00 00 00 00 00 00 00 00 00 41 40 00 15
193 : }
194 : }
195 : }
196 : }
197 065A 30 B: SEQUENCE {
198 065C 06 7: OBJECT IDENTIFIER ecdsa-with-SHA1 (1 2 840 10045 4 1)

199 0665 05 0: NULL
200 : }
201 0667 03 41: BIT STRING 0 unused bits, encapsulates {
202 066A 30 3E: SEQUENCE {
203 066C 02 1D: INTEGER
204 : 12 68 63 DF A0 55 73 92 E2 D9 FE C6 E5 DA 98 32
205 : 04 21 3B 79 DC CF 71 96 80 38 98 A0 91
206 068B 02 1D: INTEGER
207 : 36 AC 32 5E 06 01 1A 6B 56 B6 56 93 F3 99 25 A4
208 : 30 3B 88 1A 2F 03 F1 73 6A F2 B2 02 37
209 : }
210 : }
211 : }
Vaciado Hexadecimal
1 0000 30 82 06 A6 30 82 06 52 A0 03 02 01 02 02 03 75
2 0010 F7 E0 30 0B 06 07 2A 86 48 CE 3D 04 01 05 00 30
3 0020 69 31 11 30 0F 06 03 55 04 03 13 08 4D 6F 76 69
4 0030 6C 20 43 41 31 0B 30 09 06 03 55 04 06 13 02 4D
5 0040 58 31 24 30 22 06 09 2A 86 48 86 F7 0D 01 09 01
6 0050 16 15 6D 6F 76 69 6C 2E 63 61 40 63 69 6E 76 65
7 0060 73 74 61 76 2E 6D 78 31 0D 30 0B 06 03 55 04 07
8 0070 13 04 44 2E 46 2E 31 12 30 10 06 03 55 04 0A 13
9 0080 09 49 54 45 53 4D 20 43 43 4D 30 1E 17 0D 30 35
10 0090 30 32 32 31 30 30 30 30 30 30 5A 17 0D 30 36 30
11 00a0 33 32 39 30 30 30 30 30 30 5A 30 71 31 1B 30 19
12 00b0 06 03 55 04 03 13 12 47 75 69 6C 6C 65 72 6D 6F
13 00c0 20 4D 61 72 74 69 6E 65 7A 31 0B 30 09 06 03 55
14 00d0 04 06 13 02 4D 58 31 22 30 20 06 09 2A 86 48 86
15 00e0 F7 0D 01 09 01 16 13 67 5F 6D 5F 73 69 6C 76 61
16 00f0 40 79 61 68 6F 6F 2E 63 6F 6D 31 0D 30 0B 06 03
17 0100 55 04 07 13 04 44 2E 46 2E 31 12 30 10 06 03 55
18 0110 04 0A 13 09 43 49 4E 56 45 53 54 41 56 30 82 01
19 0120 15 30 81 D2 06 07 2A 86 48 CE 3D 02 01 30 81 C6
20 0130 02 01 01 30 1D 06 07 2A 86 48 CE 3D 01 02 30 12
21 0140 02 02 00 E9 06 09 2A 86 48 CE 3D 01 02 03 02 02
22 0150 01 4A 30 40 04 1E 00 00 00 00 00 00 00 00 00 00
23 0160 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
24 0170 00 00 00 00 04 1E 00 00 00 00 00 00 00 00 00 00
25 0180 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
26 0190 00 00 00 01 03 3E 00 04 01 72 32 BA 85 3A 7E 73
27 01a0 1A F1 29 F2 2F F4 14 95 63 A4 19 C2 6B F5 0A 4C
28 01b0 9D 6E EF AD 61 26 01 DB 53 7D EC E8 19 B7 F7 0F
29 01c0 55 5A 67 C4 27 A8 CD 9B F1 8A EB 9B 56 E0 C1 10
30 01d0 56 FA E6 A3 02 1D 80 00 00 00 00 00 00 00 00 00
31 01e0 00 00 00 00 06 9D 5B B9 15 BC D4 6E FB 1A D5 F1
32 01f0 73 AB DF 02 01 04 03 3E 00 04 01 0A EB EA CC A8
33 0200 19 97 60 CB 5B 69 3D 97 97 45 1B DE 0A 5A C8 2D
34 0210 73 B7 C2 64 66 6E 7F 94 01 6C A5 E5 DE 79 3F 6E
35 0220 19 83 93 7E 78 1D FD AA D9 06 48 E6 81 D5 13 BD
36 0230 DC FD 30 2A C3 D0 A3 82 04 20 30 82 04 1C 30 0B
37 0240 06 05 67 2A 07 05 02 04 02 03 01 30 82 04 0B 06
38 0250 05 67 2A 07 05 01 04 82 04 00 90 01 F4 01 F4 01
39 0260 00 00 00 00 00 00 00 08 00 55 00 00 00 00 00 00
40 0270 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
41 0280 04 00 00 00 04 00 00 04 00 00 04 32 32 32 32 32
42 0290 00 00 FF FF FF FF FF FF FF FF FF FF FF FF FF FF
43 02a0 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
44 02b0 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
45 02c0 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
46 02d0 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
47 02e0 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
48 02f0 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
49 0300 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
59 03a0 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
60 03b0 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
61 03c0 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
62 03d0 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
63 03e0 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
64 03f0 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
74 0490 FF FF 00 00 00 0A 18 18 18 1A 1E 1E 1E 14 5E 2A
75 04a0 22 58 0C 27 88 38 BE 8D F7 EE 8D F7 4E 72 35 50
76 04b0 32 3D 88 B8 E0 C2 6D 12 DD 86 00 32 59 1E 3A 4C
77 04c0 3F 3B 73 33 42 68 36 5B 8F 0F 9B 8C 05 D7 74 09
78 04d0 DA 47 21 53 B3 E2 5E B5 D9 85 9E F5 96 A9 EB BD
79 04e0 B4 EE EF B4 E8 09 62 12 11 8A FA 02 3A 20 0A 96
80 04f0 F3 18 90 F7 1C C4 E2 00 00 00 00 00 00 00 00 00
81 0500 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
82 0510 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
83 0520 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
84 0530 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
85 0540 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
86 0550 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
87 0560 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
88 0570 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
89 0580 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90 0590 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
91 05a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
92 05b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
93 05c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
94 05d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
95 05e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
96 05f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
97 0600 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
98 0610 00 00 00 00 00 00 00 8A 58 45 00 74 77 58 68 46
99 0620 7B 59 48 66 40 69 00 00 00 00 00 00 00 00 00 00
100 0630 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
101 0640 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
102 0650 00 00 00 00 00 00 41 40 00 15 30 0B 06 07 2A 86
103 0660 48 CE 3D 04 01 05 00 03 41 00 30 3E 02 1D 12 68
104 0670 63 DF A0 55 73 92 E2 D9 FE C6 E5 DA 98 32 04 21
105 0680 3B 79 DC CF 71 96 80 38 98 A0 91 02 1D 36 AC 32
106 0690 5E 06 01 1A 6B 56 B6 56 93 F3 99 25 A4 30 3B 88
107 06a0 1A 2F 03 F1 73 6A F2 B2 02 37
HEX: Dato ASN.1 Descripción
Esta secuencia encapsula todo el certificado digital; es

0000: SEQUENCE decir, las tres partes que lo conforman: tbsCertificate,
signatureAlgorithm, y signatureValue.
Aquı́ inicia el tipo tbsCertificate el cual tiene una lon-
0004: SEQUENCE
gitud de 0x652 bytes.
000A: INTEGER El valor 2 indica que se trata de un certificado X.509v3.
000D: INTEGER El valor 7731168 es el número serial del certificado.

Identificador del algoritmo de firma digital utilizado
0014: OBJECT ID
(ecdsa-with-SHA1).
001F: SEQUENCE Inicia el nombre X.500 de la entidad emisora.
Inicia la especificación del perı́odo de validez del certifi-
008A: SEQUENCE
cado. Este SEQUENCE encapsula los valores UTCTime.
00AA: SEQUENCE Inicia el nombre X.500 de la entidad final (el usuario).
Inicia la especificación de la llave pública de la entidad
final. La llave está compuesta los parámetros (E, P, n, Q)
011D: SEQUENCE (identificador de algoritmo, versión, campo caracterı́sti-
co, cofactor, coeficiente a, coeficiente b, punto generador,
orden, etc.).
Inicia los campos de las extensiones encapsuladas en el
0236: CONTEXT-SPECF 3
certificado digital.
Identificador de objeto de la extensión. Esta extensión (2
0240: OBJECT ID 23 42 7 5 2) es utilizada para agilizar el proceso de parseo
de la Autoridad Certificadora.
Identificador de objeto de la extensión biométrica. Esta
024F: OBJECT ID extensión (2 23 42 7 5 1) es utilizada para incorporar la
información de huella digital del usuario final.
Inicia el valor de la extensión de información biométrica,
0256: OCTET STRING
su longitud es de 0x400 (1024 bytes).
Inicia el campo que identifica al algoritmo utilizado para
065A: SEQUENCE
la generación de la firma digital (signatureAlgorithm).
Campo que contiene el valor de la firma digital
0667: BIT STRING (signatureValue), el cual está compuesto por la pareja
(r, s). En 066C inicia el valor r y en 068B el valor s
Tabla B.2: Explicación de la sintaxis ASN.1 de un certificado ECC con información

biométrica
Apéndice C
Funcionamiento del sistema
El sistema cuenta con una interfaz gráfica que permite la selección de las diferentes
opciones de generación del certificado digital. La tabla §C.1 muestra las caracterı́sticas
principales del PDA que ejecuta la aplicación.
iPAQ Pocket PC h5550
Sistema Operativo Microsoft Windows

R Pocket
R PC 2003 Premium.
Procesador Intel XScale

R de 400 MHz.
SDRAM de 128 MB.
Memoria
ROM de 48 MB.
Incluye software de desarrollo para Visual C++ Embed-
Lector biométrico ded compatible con el estándar BioAPI [Ded04].
Red inalámbrica WLAN 802.11 y BluetoothTM .
Dimensiones y Peso (13.8 x 8.4 x 1.59) cm. y 206.8 gramos.
Display Cristal lı́quido de 65,536 colores.
Tabla C.1: Caracterı́sticas principales del dispositivo móvil iPAQ h5550.
La siguiente sección explica a detalle la interfaz gráfica y las opciones de generacióin
de certificados digitales a través de la autoridad certificadora móvil implementada en
esta tesis.
108
APÉNDICE C. FUNCIONAMIENTO DEL SISTEMA 109
C.1. Descripción de la interfaz gráfica
La figura §C.1 muestra la pantalla principal de la aplicación. Como se puede ob-
servar existen diversas opciones las cuales pueden ser accedidas a través de las cinco
diferentes pantallas de la aplicación (Datos, Biometric, RSA, ECC, y Verificación). A
continuación se describe cada pantalla.
Generar certificado Período de validez

auto-firmado
(AC)
Botón para aceptar los

datos y parámetros de
generación
Incluir información
biométrica
Teclado
iPAQ
Pantalla de captura
de datos de
la entidad final
Pantalla de verificación
de certificados
RSA y ECC
Pantalla de captura de
huella digital
Pantalla para
generación de
certificados ECC
Pantalla para
generación de Lector de huella digital
certificados RSA
Figura C.1: Pantalla principal de la aplicación

C.1.1. Pantalla de Datos
Esta pantalla permite la caputura de los datos de la entidad final (nombre, correo
electrónico, paı́s, localidad) y permite seleccionar algunas opciones de generación; por
ejemplo, si el certificado es auto-firmado, o si se desea incluir información biométrica. La
figura §C.2 muestra cómo se utiliza el teclado de la iPAQ para poder llenar los campos.
La figura §C.3 muestra la selección del perı́odo de validez del certificado digital, y
finalmente la figura §C.4 muestra la información capturada y las opciones seleccionadas
para la generación del certificado digital.
Figura C.2: Llenado de datos de la entidad final
C.1.2. Pantalla de Biometric
Esta interfaz permite la captura de la huella digital a través del hardware de la
iPAQ h5500. Para iniciar la captura sólo hay que presionar el botón Capturar. Al
iniciar la captura se cuenta con aproximadamente 25 segundos antes que termine el

Figura C.3: Selección del periódo de validez del certificado
Figura C.4: Opciones de la pantalla de Datos

proceso automáticamente. En caso que la captura sea exitosa, aparecerá un mensaje en
la pantalla y entonces se podrá proceder a la selección del algoritmo de firma digital a
utilizar.
Es importante comentar que la captura consiste en pasar el dedo de arriba hacia
abajo en el lector biométrico y en caso que la captura no sea existosa, aparecerá un
mensaje en la pantalla, y se deberá intentar una vez más. La figura §C.5 muestra este
proceso.
Figura C.5: Captura de huella digital
C.1.3. Pantalla de RSA
Esta interfaz (figura §C.6) permite la generación del certificado digital utilizando el
algoritmo RSA (1024 bits).
Es necesario que previamente se hayan capturado los datos de la entidad final,
perı́odo de validez, y las opciones de generación. En caso que alguna de estas no esté cap-
turada aparecerá un mensaje en el cual se pide la captura de la información faltante.

Figura C.6: Generación del certificados RSA
C.1.4. Pantalla de ECC
Esta interfaz (figura §C.7) permite la generación del certificado digital utilizando el
algoritmo de curva elı́ptica utilizando las curvas 163k, 192p, 224p ó 233k.
Es necesario que previamente se hayan capturado los datos de la entidad final,
perı́odo de validez, y las opciones de generación. En caso que alguna de estas no esté cap-
turada aparecerá un mensaje en el cual se pide la captura de la información faltante.
C.1.5. Pantalla de Verificación
A través de esta interfaz se puede verificar los certificados expedidos anteriormente
(RSA o ECC). La figura §C.8 muestra la lista de certificados almacenados en el dis-
positivo móvil. La figura §C.9 muestra el mensaje de “certificado válido o certificado
corrupto ”según sea el caso al momento de hacer la verificación.

Figura C.7: Generación de certificados ECDSA
Figura C.8: Selección de certificados almacenados en la PDA

Figura C.9: Verificación de certificados emitidos por la AC
C.2. Generación de certificados X.509 v3
Antes de poder expedir certificados digitales X.509 v3 a las entidades finales, es
necesario que se creen los certificados auto-firmados (self-signed ) por la propia auto-
ridad certificadora. En caso de que los certificados de la AC no existan, la aplicación
mostrará un mensaje en el cual solicita su creación. La figura §C.1 muestra la pantalla
principal de la aplicación; en la cual, se puden ingresar las opciones de generación de
certificados: generación de certificados auto-firmados, captura de información biométri-
ca para certificados de usuarios finales, perı́odo de validez, datos de la entidad final, y
selección del algoritmo criptográfico (RSA o ECDSA) para la generación de la firma
digital.
Referencias
[ASN02] Abstract syntax notation one (asn.1): Specification of basic notation, 2002.
ITU-T Rec. X.680 (2002) ,ISO/IEC 8824-1:2002.
[ASN04] The opensource asn.1 compiler, 2004.
http://lionet.info/asn1c.
[ASN05] ASN.1 Site - Tools - OID tree. 2005.
http://asn1.elibel.tm.fr/.
[Asp02] Fredrik Asplund. Parsing of X.509 certificates in a WAP environment.
2002. Master thesis, URL for electronic version:
http://www.ep.liu.se/exjobb/isy/2002/3288/.
[Bio00] BioAPI Specification Version 1.00. March 2000. The BioAPI Consortium,
http://www.bioapi.org.
[Bio02] ipaq pocket pc developer program. November 2002. Biometrics API.
[CC02] Tin-Wo Cheung and Samuel T. Chanson. Design and Implementation
of a PKI-based End-to-End Secure Infrastructure for Mobile E-Commerce.
IEEE, 2002. Hong Kong University of Science & Technology.
116
REFERENCIAS 117
[Cho01] P. Chown. Advanced Encryption Standard (AES) Ciphersuites for Transport
Layer Security (TLS). 2001. Skygate Technology,
http://www.ietf.org/rfc/rfc3268.txt.
[CPV00] Liqun Chen, Siani Pearson, and Athanasios Vamvakas. On Enhancing Bio-
metric Authentication with Data Protection. 2000. IEEE.
[Ded04] Douglas Dedo. Windows mobile-based devices and security: Protecting sen-
sitive business information, February 2004. Mobile Devices Division Micro-
soft Corporation,
http://www.microsoft.com/windowsmobile/.
[DH76] W. Diffie and M.E. Hellman. New directions in cryptography. In IEEE
Transactions in Information Theory., pages 644–654, 1976.
[DK00a] William M. Dal and Raymond G. Kammer. Digital Signature Standard
(DSS). January 2000. Federal Information Processing Standards Publica-
tion,
http://www.nist.org.
[DK00b] William M. Dal and Raymond G. Kammer. Secure Hash Standard). January
2000. Federal Information Processing Standards Publication,
http://www.nist.org.
[DLMO03] Ed Dawson, Javier López, Jose A. Montenegro, and Eiji Okamoto. BAAI:
Biometric Authentication and Authorization Infrastructure. 2003. IEEE.
[Dub00] Olivier Dubuisson. ASN.1 Communication Between Heterogeneous Systems.
Morgan Kaufmann Publishers, 2000.
http://asn1.elibel.tm.fr/en/book/.
REFERENCIAS 118
[ECC97] The elliptic curve cryptosystem, 1997. Certicom Corp.
http://www.certicom.com/.
[ECC04] Ecc cryptography tutorial - 5.0 elliptic curve groups and the discrete loga-
rithm problem, 2004.
http://www.certicom.com/.
[ECD98] Public Key Cryptography For The Financial Services Industry: The Elliptic
Curve Digital Signature Algorithm (ECDSA) .

c September 1998. American
National Standards Institute X9.62-1998.
[ERHK02] E.Sanvas, F. Rodrı́guez-Henrı́quez, and C. Koc. RCT, RSA and ECC Tool-
kit. ISL Group, Oregon State University, March 2002.
[For01] Internet Engineer Task Force. Public-key infrastructure (x.509) (pkix),
2001.
http://www.ietf.org/html.charters/pkix-charter.html.
[GGCS02] V. Gupta, S. Gupta, S. Chang, and D. Stebila. Performance analysis of
elliptic curve cryptography for ssl. pages 87–94, September 2002.
[Gro04] ITU-T Study Group-17. Languages for telecommunication systems, 2004.
http://www.itu.int/ITU-T/studygroups/com17/languages/.
[Gut97] Peter Gutmann. ASN.1/cryptlib. October 1997. Basado en un programa
de David Kemp,
http://www.cs.auckland.ac.nz/∼pgut001/dumpasn1.c.
[HMV03] Darrel Hankerson, Alfred Menezes, and Scott Vanstone. Guide to Elliptic
Curve Cryptography. Springer, 2003.

REFERENCIAS 119
[HPFS02] R. Housley, W. Polk, W. Ford, and D. Solo. RFC3280: Internet X.509
Public Key Infrastructure Certificate and Certificate Revocation List (CRL)
Profile. April 2002.
[HPi03] Biometric Security with the iPAQ Pocket PC h5400 series. January 2003.
Hewlett-Packard Company
http://www.hp.com.
[IM03] Russell Impagliazzo and Sara Miner More. Anonymous Credentials with
Biometrically-Enforced Non-Transferability. ACM, october 2003.
http://www.acm.org.
[iP02] iPAQ PockePC. h5000 seriesbiometrics api plataform.
http://www.bioapi.org, 2002.
[ISO01] IEC ISO. Biometric data interchange formats - part 3: Finger pattern based
interchange format. In ISO/IEC WD 19794-3, pages 93–106, 2001.
[JBP99] A.K Jain, R. Bolle, and S Pankanti. Personal identification in a networket
society. Kluwer Academic Publishers, 1999.
[JMV01] Don Johnson, Alfred Menezes, and Scott Vanstone. The Elliptic Curve
Digital Signature Algorithm (ECDSA). 2001. Certicom Corporation,
http://www.certicom.com.
[KC98] R. Kumanduri and Romero C. Number Theory with Computer Applications.
Prentice Hall,, NJ, 1998.

REFERENCIAS 120
[KHPC01] Richard Kuhn, Vincent Hu, Timothy Polk, and Shu-Jen Chang. Introduc-
tion to public key technology and the federal pki infrastructure. NIST,
February 2001.
[KM04] Neal Koblitz and Alfred J. Menezes. A Survey of Public-Key Cryptosystems.
August 2004. Overview of the most important public-key cryptosystems.
[KS98] B. Kaliski and J. Staddon. RFC2437: PKCS #1: RSA Encryption. October
1998.
[Lar99] John Larmouth. ASN.1 Complete. Open Systems Solution, 1999.
[Moh04] Pradosh Kumar Mohapatra. Public key cryptography.
http://www.acm.org/crossroads/xrds7-1/crypto.html, 2004.
[MOV01] Alfred Menezes, Paul Oorscht, and Scott Vanstone. Handbook of Applied
Cryptography. CRC Press, 2001.
[NL02] Randall K. Nichols and Panos C. Lekkas. Wireless Security. McGraw-Hill
TELECOM, 2002. Models, Threats, and Solutions.
[Pez05] Carlos Eduardo López Peza. Sistema de Seguridad para Intercambio de
Datos en Dispositivos Móviles. Marzo 2005.
[PHB02] W. Polk, R. Housley, and L. Bassham. RFC3279: Algorithms and Identifiers
for the Internet X.509 Public Key Infrastructure Certificate and Certificate
Revocation List (CRL) Profile. April 2002.
REFERENCIAS 121
[Riv92] R. Rivest. The MD5 Message-Digest Algorithm. April 1992. MIT Labora-
tory for Computer Science and RSA Data Security,Inc. ,
[RSA05] RSA Laboratories. 2005.
http://www.rsasecurity.com/rsalabs/.
[Sch96] B. Schneier. Applied Cryptography. John Wiley & Sons, 2nd edition, 1996.
[Sch03] Klaus Schmeh. Cryptography and Public Key Infrastructure on the Internet.
John Wiley & Sons, 2003.
[Sti95] D.R. Stinson. Cryptography, Theory and Practice. CRC Press,, Boca Raton,
FL, 1995.
[TW01] Wade Trappe and Lawrence C. Washington. Introduction to Cryptography
with coding theory. Prentice Hall,, 2001.
[Uch00] Kaoru Uchida. Fingerprint-based User-friendly Interface and Pocket-PID
for Mobile Authentication. 2000. Computer and Communication Media
Research, NEC Corporation.
[V.86] Miller V. Uses of elliptic curves in cryptography. In Advances in Cryptology
CRYPTO’85., pages 417–426, 1986.
[Way97] Peter Wayner. British document outlines early encryption discovery, 1997.
http://www.nytimes.com/library/cyber/week/122497encrypt.html.
[WYY05] Xiaoyun Wang, Yiqun Lisa Yin, and Hongbo Yu. Collision search attacks
on sha1. February 2005.

Índice alfabético
ASN.1, 83 ECC
BIT STRING, 87 Fp , 15
BOOLEAN, 85 F2m , 18
ENUMERATED, 86 R , 12
IA5String, 87 FAR
INTEGER, 86 False Accept Rate, 63
OCTET STRING, 86 FFR
OID, 88 False Reject Rate, 64
Printable String, 87 Funciones hash, 22
UTCTime, 88 Integridad de datos, 27
Algoritmo de firma digial Intercambio de llaves, 24
ECDSA, 61 No-repudio, 25
Arquitectura de la aplicación, 60 PDA
Ataques a servicios de autenticación Especificaciones, 60
intruso de en medio, 32 PKI, 39
usurpación de identidad, 32 X.509
Autenticación v3, 50
, 24, 28
Biométrica, 36
entidades de confianza, 33
Biblioteca ASN.1, 66
Biblioteca criptográfica
RCT, 61
BioAPI
Implementación por HP, 63
Conclusiones, 80
Confidencialidad, 3, 25
Criptografı́a
Aplicaciones, 23
de curva elı́ptica, 11
de llave pública, 3
Criptosistema
Curva elı́ptica, 20
RSA , 10
122

Implementacion Pki Plataformas Moviles PDF

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Implementacion Pki Plataformas Moviles PDF

Hochgeladen von

Copyright:

Verfügbare Formate

INSTITUTO TECNOLÓGICO Y DE ESTUDIOS

Escuela de Graduados de Ingenieria y Arquitectura

“Diseño e Implementación de una Autoridad

Tesis presentada por

Guillermo Martı́nez Silva

para obtener el grado de Maestro

Dr. Francisco Rodrı́guez Henrı́quez

México D.F. verano de 2005

Escuela de Graduados de Ingenieria y Arquitectura

“Diseño e Implementación de una Autoridad

Guillermo Martı́nez Silva

Nombre del Presidente

México D.F. junio de 2005

Guillermo Martı́nez Silva

para obtener el grado de

Maestro en Ciencias Computacionales.

Dr. Nombre del Presidente

Dr. Nombre Sinodal I Dr. Nombre Sinodal II

Dr. Francisco Rodrı́guez Dra. Patricia Rayón Villela

Gracias a todos los que hicieron esto posible.

El presente trabajo implementa una Autoridad Certificadora en un dispositivo móvil

PDA(Asistente Personal Digital) con la particularidad de incluir información biométri-

ca de huella digital en los campos de extensión de un certificado digital basado en el

1. Criptografı́a de llave pública y funciones hash 3

1.1. Principios de criptosistemas basados en llave pública . . . . . . . . . . 6

1.2. Intercambio de llaves Diffie-Hellman . . . . . . . . . . . . . . . . . . . . 9

1.3. Criptosistema RSA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

1.4. Criptografı́a de curva elı́ptica ECC . . . . . . . . . . . . . . . . . . . . 11

1.4.1. Grupos de curva elı́ptica sobre R . . . . . . . . . . . . . . . . . 12

1.4.2. Grupos de curva elı́ptica sobre Fp . . . . . . . . . . . . . . . . . 15

1.4.3. Grupos de curva elı́ptica sobre F2m . . . . . . . . . . . . . . . . 18

1.4.4. Criptosistema basado en ECC . . . . . . . . . . . . . . . . . . . 20

1.5. Funciones hash . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

1.6. Aplicaciones de criptosistemas de llave pública . . . . . . . . . . . . . . 23

1.6.2. Intercambio de llaves . . . . . . . . . . . . . . . . . . . . . . . . 24

1.6.4. No-repudio y firmas digitales . . . . . . . . . . . . . . . . . . . . 25

1.6.5. Integridad de datos . . . . . . . . . . . . . . . . . . . . . . . . . 27

2.1. Servicios de seguridad informática en ambientes inalámbricos . . . . . . 30

2.2. Ataques a la autenticación de entidades . . . . . . . . . . . . . . . . . . 32

2.2.1. Ataque del intruso de en medio . . . . . . . . . . . . . . . . . . 32

2.2.2. Usurpación de identidad . . . . . . . . . . . . . . . . . . . . . . 32

2.3. Métodos de autenticación . . . . . . . . . . . . . . . . . . . . . . . . . 33

2.3.1. Autenticación mediante entidades de confianza . . . . . . . . . . 33

2.3.2. Autenticación biométrica . . . . . . . . . . . . . . . . . . . . . . 36

3. PKI (Infraestructura de llave pública) 39

3.1. Introducción a PKI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

3.2. Componentes PKI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

3.2.1. Autoridades Certificadoras (ACs) . . . . . . . . . . . . . . . . . 44

3.2.2. Autoridad de Registro (AR) . . . . . . . . . . . . . . . . . . . . 46

3.2.4. Emisor CRL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

3.2.5. Entidades Finales . . . . . . . . . . . . . . . . . . . . . . . . . . 47

3.3. Arquitecturas PKI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

3.4. Estructuras de datos PKI . . . . . . . . . . . . . . . . . . . . . . . . . 50

3.4.1. Certificados X.509 . . . . . . . . . . . . . . . . . . . . . . . . . 50

3.4.2. Listas de revocación de certificados . . . . . . . . . . . . . . . . 53

3.5. Servicios adicionales PKI . . . . . . . . . . . . . . . . . . . . . . . . . . 57

4. Implementación del sistema 58

4.1. Descripción del sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

4.2. Arquitectura de la aplicación . . . . . . . . . . . . . . . . . . . . . . . . 60

4.2.1. Dispositivo móvil . . . . . . . . . . . . . . . . . . . . . . . . . . 60

4.2.2. Biblioteca criptografı́ca RCT . . . . . . . . . . . . . . . . . . . . 61

4.2.3. Biblioteca biométrica BioAPI . . . . . . . . . . . . . . . . . . . 63