Victor Gayoso Martinez

Universidad Politécnica de Madrid
Escuela Técnica Superior de Ingenieros de Telecomunicación
Consejo Superior de Investigaciones Científicas

Instituto de Física Aplicada
Implementación en tarjetas
inteligentes Java Card de
protocolos de cifrado y descifrado
basados en curvas elípticas
Tesis Doctoral
Víctor Gayoso Martínez

Ingeniero de Telecomunicación
2010
Departamento de Matemática Aplicada a las
Tecnologías de la Información
Departamento de Tratamiento de la
Información y Codificación
Directores
Carmen Sánchez Ávila

Doctora en Ciencias Matemáticas
Luis Hernández Encinas

Doctor en Ciencias Matemáticas
Madrid
2010
TRIBUNAL CALIFICADOR
Tribunal nombrado por el Magfco. y Excmo. Sr. Rector de la Universidad Poli-

técnica de Madrid el día de de .
Presidente Dr. D.
Vocal Dr. D.
Vocal Dr. D.
Vocal Dr. D.
Secretario Dr. D.
Realizado el acto de lectura y defensa de la Tesis el día de

de en Madrid.
Calificación:
EL PRESIDENTE LOS VOCALES
EL SECRETARIO
Para Laura y Blanca.
THV6IGRlIG1pIHZpZGEgeSBhbGllbnRvIGRlIG1pIHNlci4=
I do not have a name. You can call me V.

Alan Moore. V for Vendetta.
Reputation is what other people know about you.

Honor is what you know about yourself.
Lois McMaster Bujold. A Civil Campaign.
ix
AGRADECIMIENTOS
En primer lugar me gustaría mostrar mi agradecimiento a mis tutores Luis Her-

nández y Carmen Sánchez por su esfuerzo continuo y su paciencia infinita revisando
cada borrador de esta Tesis, dándome siempre buenos y acertados consejos.
En especial, me gustaría agradecer a Luis la magnífica oportunidad de haber

podido trabajar con él estos dos últimos años en el Consejo Superior de Investiga-
ciones Científicas, tiempo del que siempre guardaré el mejor de los recuerdos y en
el que tanto he aprendido.
El resto de agradecimientos son para:
Mi mujer y mi hija, a las que tanto debo.
Mis padres, por apoyarme y ayudarme siempre que lo he necesitado.
Mi hermana, con la que a pesar de la distancia sigo compartiendo tantas cosas.
Mis amigos Óscar, Sixto, Enrique, Mónica, María José, Carlos Daniel, José Ig-
nacio, Blanca, Marta, David, Rafa, Enrique, Gema, Antonio, Ma Carmen y tantos
otros, por seguir siendo los mejores amigos en los buenos y los malos momentos.
La empresa NXP, y muy especialmente Juan Moreno, por proporcionarme las

tarjetas JCOP J3A empleadas en esta Tesis, sin las cuales no habría podido desa-
rrollar una parte importante de la investigación.
El departamento de Tratamiento de la Información y Codificación del Instituto

de Física Aplicada del CSIC, por la profesionalidad y compañerismo demostrados
en estos dos últimos años.
Índice general
Introducción 1
Antecedentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
Justificación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Metodología . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Clasificación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Estructura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Notas de estilo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1. Tarjetas inteligentes 19
1.1. Historia de las tarjetas inteligentes . . . . . . . . . . . . . . . . . . . 19
1.2. ¿Qué es una tarjeta inteligente? . . . . . . . . . . . . . . . . . . . . . 22
1.3. Tipos de tarjetas inteligentes . . . . . . . . . . . . . . . . . . . . . . . 25
1.3.1. Tarjetas de memoria . . . . . . . . . . . . . . . . . . . . . . . 25
1.3.2. Tarjetas con microprocesador . . . . . . . . . . . . . . . . . . 25
1.3.3. Tarjetas con coprocesador . . . . . . . . . . . . . . . . . . . . 28
1.4. Propiedades físicas y eléctricas . . . . . . . . . . . . . . . . . . . . . . 28
1.5. Estándares . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
1.5.1. La norma ISO/IEC 7816 . . . . . . . . . . . . . . . . . . . . . 31
1.5.2. La norma ISO/IEC 14443 . . . . . . . . . . . . . . . . . . . . 33
1.5.3. Las normas ETSI y 3GPP . . . . . . . . . . . . . . . . . . . . 33
1.5.4. Las normas Global Platform . . . . . . . . . . . . . . . . . . . 35
1.6. Sistemas operativos de tarjetas inteligentes . . . . . . . . . . . . . . . 35
xi
xii Índice general
1.6.1. Tarjetas Java Card . . . . . . . . . . . . . . . . . . . . . . . . 36

1.6.2. Tarjetas MULTOS . . . . . . . . . . . . . . . . . . . . . . . . 37
1.6.3. Tarjetas Windows for Smart Cards . . . . . . . . . . . . . . . 37
1.7. Arquitecturas de acceso a las tarjetas inteligentes desde PC . . . . . . 38
1.7.1. Arquitectura OpenCard Framework . . . . . . . . . . . . . . . 38
1.7.2. Arquitectura PC/SC . . . . . . . . . . . . . . . . . . . . . . . 40
1.8. Comunicación con la tarjeta inteligente . . . . . . . . . . . . . . . . . 41
1.8.1. APDU de tipo comando . . . . . . . . . . . . . . . . . . . . . 43
1.8.2. APDU de tipo respuesta . . . . . . . . . . . . . . . . . . . . . 46
2. Criptografía de clave pública basada en curvas elípticas 49

2.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
2.2. Aplicaciones de la criptografía de clave pública . . . . . . . . . . . . . 51
2.2.1. Establecimiento de clave . . . . . . . . . . . . . . . . . . . . . 51
2.2.2. Firma digital . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
2.2.3. Cifrado/descifrado . . . . . . . . . . . . . . . . . . . . . . . . 53
2.3. Seguridad en criptosistemas de clave pública . . . . . . . . . . . . . . 54
2.4. Principales esquemas de cifrado y establecimiento de clave . . . . . . 56
2.4.1. Establecimiento de clave Diffie-Hellman . . . . . . . . . . . . . 57
2.4.2. Criptosistema RSA . . . . . . . . . . . . . . . . . . . . . . . . 59
2.4.3. Criptosistema de El Gamal . . . . . . . . . . . . . . . . . . . . 64
2.5. Esquemas de cifrado híbrido DEM -KEM . . . . . . . . . . . . . . . . 68
2.5.1. Mecanismo de encapsulación de clave KEM . . . . . . . . . . 69
2.5.2. Mecanismo de encapsulación de datos DEM . . . . . . . . . . 69
2.5.3. Esquema de cifrado híbrido con etapas KEM -DEM . . . . . . 70
2.6. Criptografía basada en curvas elípticas . . . . . . . . . . . . . . . . . 70
2.6.1. Definición de curva elíptica . . . . . . . . . . . . . . . . . . . . 71
2.6.2. Estructura de grupo . . . . . . . . . . . . . . . . . . . . . . . 75
2.6.3. Curvas elípticas sobre cuerpos finitos . . . . . . . . . . . . . . 78
2.6.4. Bases polinómicas y bases normales . . . . . . . . . . . . . . . 86
2.6.5. Representación de los puntos de una curva elíptica . . . . . . . 88
Índice general xiii
2.6.6. Comprobación de los parámetros de una curva elíptica . . . . 90

2.6.7. Seguridad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
2.6.8. Estándares relacionados . . . . . . . . . . . . . . . . . . . . . 92
2.6.9. Patentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
3. Capacidades criptográficas en Java 99

3.1. Programación orientada a objetos . . . . . . . . . . . . . . . . . . . . 99
3.1.1. Encapsulación . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
3.1.2. Herencia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
3.1.3. Polimorfismo . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
3.2. El lenguaje Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
3.2.1. Introducción al lenguaje Java . . . . . . . . . . . . . . . . . . 100
3.2.2. Elementos del entorno Java . . . . . . . . . . . . . . . . . . . 103
3.2.3. Características criptográficas de Java . . . . . . . . . . . . . . 105
3.3. Bibliotecas criptográficas . . . . . . . . . . . . . . . . . . . . . . . . . 108
3.3.1. Cryptix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
3.3.2. Bouncy Castle . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
3.3.3. IAIK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
3.3.4. FlexiProvider . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
3.4. Java Card . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
3.4.1. Introducción al lenguaje Java Card . . . . . . . . . . . . . . . 113
3.4.2. Java Card API . . . . . . . . . . . . . . . . . . . . . . . . . . 114
3.4.3. Java Card Runtime Environment . . . . . . . . . . . . . . . . 117
3.4.4. Java Card VM . . . . . . . . . . . . . . . . . . . . . . . . . . 121
3.4.5. Limitaciones del lenguaje Java Card . . . . . . . . . . . . . . 122
3.4.6. Características criptográficas en Java Card . . . . . . . . . . . 123
3.5. Programación en Java Card . . . . . . . . . . . . . . . . . . . . . . . 126
4. Estudio y análisis del esquema de cifrado ECIES 129

4.1. Criptosistemas de curvas elípticas . . . . . . . . . . . . . . . . . . . . 129
4.2. Esquema de cifrado DHIES . . . . . . . . . . . . . . . . . . . . . . . 136
xiv Índice general
4.3. Componentes funcionales de ECIES . . . . . . . . . . . . . . . . . . . 138

4.3.1. Parámetros de la curva . . . . . . . . . . . . . . . . . . . . . . 139
4.3.2. Funciones resumen . . . . . . . . . . . . . . . . . . . . . . . . 140
4.3.3. Funciones de generación del secreto compartido . . . . . . . . 140
4.3.4. Funciones de derivación de claves . . . . . . . . . . . . . . . . 141
4.3.5. Función de cifrado simétrico . . . . . . . . . . . . . . . . . . . 145
4.3.6. Funciones generadoras de códigos de autenticación para men-
sajes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
4.4. Versiones de ECIES . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
4.4.1. Versión de ANSI X9.63 . . . . . . . . . . . . . . . . . . . . . . 147
4.4.2. Versión de IEEE 1363a . . . . . . . . . . . . . . . . . . . . . . 151
4.4.3. Versión de ISO/IEC 18033-2 . . . . . . . . . . . . . . . . . . . 155
4.4.4. Versión de SECG SEC 1 . . . . . . . . . . . . . . . . . . . . . 161
4.5. Diferencias en las versiones de ECIES . . . . . . . . . . . . . . . . . . 165
4.5.1. Diferencias entre DHIES y ANSI X9.63 . . . . . . . . . . . . . 165
4.5.2. Diferencias entre ANSI X9.63 e IEEE 1363a . . . . . . . . . . 166
4.5.3. Diferencias entre IEEE 1363a e ISO/IEC 18033-2 . . . . . . . 166
4.5.4. Diferencias entre ISO/IEC 18033-2 y SEC 1 . . . . . . . . . . 167
4.6. Comparación de las funciones permitidas en los estándares . . . . . . 168
4.7. Comparación de las configuraciones permitidas en los estándares . . . 170
4.8. Versión de ECIES compatible con todos los estándares . . . . . . . . 172
4.9. Seguridad de ECIES . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
4.9.1. Resistencia a la maleabilidad . . . . . . . . . . . . . . . . . . . 172
4.9.2. Ataques de subgrupos pequeños . . . . . . . . . . . . . . . . . 177
4.9.3. Elección dinámica de parámetros y funciones . . . . . . . . . . 178
4.10. Versión de ECIES segura . . . . . . . . . . . . . . . . . . . . . . . . . 178
5. Implementación de ECIES en entorno PC 181

5.1. Diseño del esquema ECIES a implementar . . . . . . . . . . . . . . . 181
5.1.1. Cifrado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
5.1.2. Descifrado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
Índice general xv
5.1.3. Aritmética de puntos de la curva y de elementos del cuerpo

finito . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
5.2. Diagrama de clases . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186
5.3. Descripción funcional de la aplicación . . . . . . . . . . . . . . . . . . 190
5.3.1. Ventana principal . . . . . . . . . . . . . . . . . . . . . . . . . 190
5.3.2. Menú Programa . . . . . . . . . . . . . . . . . . . . . . . . . . 191
5.3.3. Menú Modo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194
5.3.4. Menú Perfiles (modo avanzado) . . . . . . . . . . . . . . . . . 197
5.3.5. Menú Test (modo avanzado) . . . . . . . . . . . . . . . . . . . 201
5.3.6. Menú Curvas . . . . . . . . . . . . . . . . . . . . . . . . . . . 202
5.3.7. Menú Utilidades . . . . . . . . . . . . . . . . . . . . . . . . . 207
5.3.8. Menú Cuerpo GF(𝑝)/Cuerpo GF(2^m) . . . . . . . . . . . . . 214
5.3.9. Pestaña Configuración (en modo avanzado) . . . . . . . . . . 215
5.3.10. Pestaña Parámetros . . . . . . . . . . . . . . . . . . . . . . . 218
5.3.11. Pestaña Cifrado . . . . . . . . . . . . . . . . . . . . . . . . . . 222
5.3.12. Pestaña Descifrado . . . . . . . . . . . . . . . . . . . . . . . . 227
5.4. Ejemplos de utilización . . . . . . . . . . . . . . . . . . . . . . . . . . 234
5.4.1. Ejemplo de cifrado . . . . . . . . . . . . . . . . . . . . . . . . 234
5.4.2. Ejemplo de descifrado . . . . . . . . . . . . . . . . . . . . . . 237
6. Implementación de ECIES en Java Card 243

6.1. Elementos criptográficos de ECIES disponibles en Java Card . . . . . 243
6.1.1. Java Card 2.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . 244
6.1.2. Java Card 2.1.1 . . . . . . . . . . . . . . . . . . . . . . . . . . 244
6.1.3. Java Card 2.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . 244
6.1.4. Java Card 2.2.1 . . . . . . . . . . . . . . . . . . . . . . . . . . 244
6.1.5. Java Card 2.2.2 . . . . . . . . . . . . . . . . . . . . . . . . . . 244
6.1.6. Java Card 3.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . 245
6.2. Resumen de funcionalidad ECC en Java Card . . . . . . . . . . . . . 246
6.3. Entorno de desarrollo . . . . . . . . . . . . . . . . . . . . . . . . . . . 246
6.3.1. NetBeans . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247
xvi Índice general
6.3.2. Herramientas de línea de comandos de Sun . . . . . . . . . . . 247

6.3.3. Eclipse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248
6.4. Esquema de la aplicación . . . . . . . . . . . . . . . . . . . . . . . . . 248
6.5. Pruebas con tarjetas virtuales . . . . . . . . . . . . . . . . . . . . . . 253
6.6. Pruebas con tarjetas reales . . . . . . . . . . . . . . . . . . . . . . . . 255
6.7. Aplicación JCOPECIES . . . . . . . . . . . . . . . . . . . . . . . . . 256
6.8. Ejemplos de utilización . . . . . . . . . . . . . . . . . . . . . . . . . . 261
6.8.1. Cifrado y descifrado en tarjetas JCOP 41 y el complemento
de NXP para Eclipse . . . . . . . . . . . . . . . . . . . . . . . 263
6.8.2. Cifrado y descifrado en tarjetas JCOP J3A y la aplicación
JCOPECIES . . . . . . . . . . . . . . . . . . . . . . . . . . . 269
7. Resultados empíricos 271

7.1. Material utilizado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271
7.2. Configuraciones de prueba . . . . . . . . . . . . . . . . . . . . . . . . 275
7.3. Factor de expansión . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279
7.3.1. Factor de expansión con la configuración M1 . . . . . . . . . . 280
7.3.2. Factor de expansión con la configuración M2 . . . . . . . . . . 282
7.3.3. Factor de expansión con la configuración P1 . . . . . . . . . . 282
7.4. Tiempo de cifrado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288
7.4.1. Tiempo de cifrado en PC con la configuración M1 . . . . . . . 289
7.4.2. Tiempo de cifrado en PC y Java Card con la configuración M2 289
7.4.3. Tiempo de cifrado en PC con la configuración P1 . . . . . . . 289
7.4.4. Tiempo de cifrado en PC y Java Card con la configuración P2 294
7.4.5. Tiempo de cifrado en PC y Java Card con la configuración P3 294
7.5. Tiempo de descifrado . . . . . . . . . . . . . . . . . . . . . . . . . . . 299
7.5.1. Tiempo de descifrado en PC con la configuración M1 . . . . . 299
7.5.2. Tiempo de descifrado en PC y Java Card con la configuración
M2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299
7.5.3. Tiempo de descifrado en PC con la configuración P1 . . . . . 300
Índice general xvii

P2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 300
P3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307
7.6. Rendimiento comparado . . . . . . . . . . . . . . . . . . . . . . . . . 309
8. Conclusiones, aportaciones y trabajo futuro 313

8.1. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313
8.1.1. El esquema ECIES como estándar . . . . . . . . . . . . . . . . 314
8.1.2. Conjunto de parámetros compatibles con todos los estándares 314
8.1.3. Desarrollo de la implementación de ECIES para PC . . . . . . 315
8.1.4. Estudio de la eficiencia de la implementación PC . . . . . . . 316
8.1.5. Desarrollo de la implementación de ECIES en tarjetas Java
Card . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 318
8.1.6. Estudio de la eficiencia de la implementación Java Card . . . . 319
8.1.7. Comparativa entre las versiones PC y Java Card . . . . . . . . 324
8.1.8. Configuración de ECIES resistente a ataques . . . . . . . . . . 324
8.2. Aportaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325
8.3. Trabajo futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 327
Notación 331
Glosario 333
Referencias 339
Índice de figuras
1. Longitudes de clave en RSA y ECC . . . . . . . . . . . . . . . . . . . 2
1.1. Diners Club, la primera tarjeta de crédito del mundo . . . . . . . . . 20

1.2. Tarjeta con banda magnética . . . . . . . . . . . . . . . . . . . . . . 20
1.3. Prototipo de D.N.I. electrónico de España . . . . . . . . . . . . . . . 21
1.4. Tarjeta SIM de Telefónica movistar . . . . . . . . . . . . . . . . . . . 21
1.5. Tarjeta monedero Danmont de la serie emitida en 1994 . . . . . . . . 21
1.6. Ejemplo de tarjeta de salud de la República Federal Alemana . . . . 22
1.7. Control de acceso con tarjeta inteligente sin contactos . . . . . . . . . 22
1.8. Aspecto externo de una tarjeta inteligente . . . . . . . . . . . . . . . 23
1.9. Diagrama de bloques de una tarjeta inteligente . . . . . . . . . . . . . 23
1.10. Encapsulado del chip bajo los contactos . . . . . . . . . . . . . . . . . 24
1.11. Contactos de una tarjeta inteligente . . . . . . . . . . . . . . . . . . . 26
1.12. Esquema de una tarjeta inteligente sin contactos . . . . . . . . . . . . 27
1.13. Formato de tarjeta ID-1 . . . . . . . . . . . . . . . . . . . . . . . . . 29
1.14. Formato de tarjeta ID-00 . . . . . . . . . . . . . . . . . . . . . . . . . 29
1.15. Formato de tarjeta ID-000 (alternativamente plug-in o mini-SIM) . . 29
1.16. Formato de tarjeta Mini-UICC (alternativamente 3FF o micro-SIM) . 30
1.17. Diagrama de voltajes admisibles . . . . . . . . . . . . . . . . . . . . . 31
1.18. Arquitectura Global Platform . . . . . . . . . . . . . . . . . . . . . . 36
1.19. Arquitectura Java Card . . . . . . . . . . . . . . . . . . . . . . . . . 37
1.20. Arquitectura MULTOS . . . . . . . . . . . . . . . . . . . . . . . . . . 38
1.21. Consorcio OpenCard . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
1.22. Elementos de la arquitectura OCF . . . . . . . . . . . . . . . . . . . . 40
xix
xx Índice de figuras
1.23. Elementos de la arquitectura PC/SC . . . . . . . . . . . . . . . . . . 42

1.24. Modelo de comunicación con la tarjeta inteligente . . . . . . . . . . . 43
1.25. Esquema de una APDU de tipo comando . . . . . . . . . . . . . . . . 43
1.26. Posibles estructuras de un comando APDU . . . . . . . . . . . . . . . 45
1.27. APDU de tipo respuesta . . . . . . . . . . . . . . . . . . . . . . . . . 46
1.28. Posibles códigos de respuesta . . . . . . . . . . . . . . . . . . . . . . 47
2.1. Modelos de seguridad en criptosistemas de clave pública . . . . . . . 56

2.2. Curva 𝑦 2 = 𝑥3 con un nodo en el punto (0, 0) . . . . . . . . . . . . . . 72
2.3. Curva 𝑦 2 + 𝑥𝑦 − 𝑥3 = 0 con una cúspide en el punto (0, 0) . . . . . . 72
2.4. Curva elíptica 𝑦 2 = 𝑥3 − 10𝑥 + 15 . . . . . . . . . . . . . . . . . . . . 74
2.5. Curva elíptica 𝑦 2 = 𝑥3 − 10𝑥 + 9 . . . . . . . . . . . . . . . . . . . . . 74
2.6. Suma de puntos de la curva 𝑅 = 𝑃 + 𝑄 . . . . . . . . . . . . . . . . . 76
2.7. Suma de puntos de la curva 𝑅 = 𝑃 + 𝑄 = 𝒪 . . . . . . . . . . . . . . 77
2.8. Suma de puntos de la curva 𝑅 = 𝑃 + 𝑃 = 2𝑃 . . . . . . . . . . . . . 77
2.9. Suma de puntos de la curva 𝑅 = 𝑃 + 2𝑃 = 3𝑃 . . . . . . . . . . . . . 78
2.10. Suma de puntos 𝑅 = 𝑃 + 𝑄 sobre un cuerpo primo . . . . . . . . . . 83
2.11. Suma de puntos 𝑅 = 𝑃 + 𝑃 = 2𝑃 sobre un cuerpo primo . . . . . . . 84
2.12. Suma de puntos 𝑅 = 𝑃 + 2𝑃 = 3𝑃 sobre un cuerpo primo . . . . . . 84
3.1. Ediciones del lenguaje Java . . . . . . . . . . . . . . . . . . . . . . . 103

3.2. Ejemplo de utilización de proveedores criptográficos en Java . . . . . 106
3.3. Arquitectura Java Card y de su entorno de ejecución . . . . . . . . . 117
3.4. Métodos para la gestión del ciclo de vida de un applet Java Card . . 118
3.5. Métodos implicados en la gestión de un applet . . . . . . . . . . . . . 119
3.6. Compartición de objetos en Java Card . . . . . . . . . . . . . . . . . 120
3.7. Esquema de conversión a ficheros CAP . . . . . . . . . . . . . . . . . 121
3.8. Fases del desarrollo de un applet Java Card . . . . . . . . . . . . . . 127
4.1. Esquema de funcionamiento de DHIES . . . . . . . . . . . . . . . . . 137

4.2. Diagrama funcional del proceso de cifrado en ECIES . . . . . . . . . 138
4.3. Diagrama funcional del proceso de descifrado en ECIES . . . . . . . . 139
Índice de figuras xxi
4.4. Maleabilidad debido a la función XOR . . . . . . . . . . . . . . . . . 176
5.1. Diagrama de clases de la aplicación ECIES . . . . . . . . . . . . . . . 187

5.2. Ventana principal del entorno de desarrollo NetBeans . . . . . . . . . 190
5.3. Ventana principal de la aplicación . . . . . . . . . . . . . . . . . . . . 192
5.4. Opciones del menú Programa . . . . . . . . . . . . . . . . . . . . . . 192
5.5. Ejemplo de ventana con aspecto Nimbus . . . . . . . . . . . . . . . . 193
5.6. Ejemplo de ventana con aspecto Windows . . . . . . . . . . . . . . . 193
5.7. Ventana de la opción Ayuda . . . . . . . . . . . . . . . . . . . . . . . 194
5.8. Ventana de la opción Acerca de . . . . . . . . . . . . . . . . . . . . . 195
5.9. Pantalla de confirmación de la opción Salir . . . . . . . . . . . . . . . 195
5.10. Opción Sencillo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196
5.11. Opción Avanzado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197
5.12. Opciones del menú Perfiles . . . . . . . . . . . . . . . . . . . . . . . . 198
5.13. Submenú ISO/IEC del menú Test . . . . . . . . . . . . . . . . . . . . 201
5.14. Submenú SECG del menú Test . . . . . . . . . . . . . . . . . . . . . 202
5.15. Curvas correspondientes al submenú ANSI . . . . . . . . . . . . . . . 203
5.16. Curvas correspondientes al submenú Brainpool . . . . . . . . . . . . . 204
5.17. Curvas correspondientes al submenú NIST . . . . . . . . . . . . . . . 205
5.18. Curvas correspondientes al submenú SECG . . . . . . . . . . . . . . . 206
5.19. Opciones del menú Utilidades . . . . . . . . . . . . . . . . . . . . . . 207
5.20. Ventana de creación de los ficheros de claves . . . . . . . . . . . . . . 208
5.21. Ventana de generación de clave en cuerpos 𝔽𝑝 . . . . . . . . . . . . . 213
5.22. Ventana de generación de clave en cuerpos 𝔽2𝑚 . . . . . . . . . . . . . 213
5.23. Ventana de descompresión de puntos en cuerpos 𝔽𝑝 . . . . . . . . . . 214
5.24. Ventana de descompresión de puntos en cuerpos 𝔽2𝑚 . . . . . . . . . 215
5.25. Menú principal con el elemento Cuerpo GF(𝑝) activado . . . . . . . . 215
5.26. Menú principal con el elemento Cuerpo GF(2^m) activado . . . . . . 216
5.27. Pestaña Configuración . . . . . . . . . . . . . . . . . . . . . . . . . . 216
5.28. Pestaña Parámetros con el menú Cuerpo GF(𝑝) activado . . . . . . . 219
5.29. Pestaña Parámetros con el menú Cuerpo GF(2^m) activado . . . . . 220
xxii Índice de figuras
5.30. Pestaña Cifrado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222

5.31. Selección del fichero con la clave pública . . . . . . . . . . . . . . . . 224
5.32. Selección del fichero con el mensaje en claro . . . . . . . . . . . . . . 224
5.33. Selección del fichero donde se almacenará el criptograma . . . . . . . 224
5.34. Modalidades de identificación de la clave pública . . . . . . . . . . . . 225
5.35. Contenido del mensaje en claro no interpretable como texto . . . . . 226
5.36. Ejemplo de cifrado ECIES . . . . . . . . . . . . . . . . . . . . . . . . 227
5.37. Pestaña Descifrado . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228
5.38. Selección del fichero con la clave privada . . . . . . . . . . . . . . . . 229
5.39. Selección del fichero con el criptograma . . . . . . . . . . . . . . . . . 229
5.40. Selección del fichero donde se almacenará el mensaje en claro . . . . . 230
5.41. Modalidades de identificación de la clave privada . . . . . . . . . . . . 231
5.42. Ventana de solicitud del código de acceso . . . . . . . . . . . . . . . . 231
5.43. Enmascaramiento de la clave privada . . . . . . . . . . . . . . . . . . 231
5.44. Contenido del mensaje descifrado no interpretable como texto . . . . 232
5.45. Ejemplo de descifrado ECIES . . . . . . . . . . . . . . . . . . . . . . 233
5.46. Selección del fichero con la clave pública del destinatario . . . . . . . 234
5.47. Identificador de la clave pública del destinatario . . . . . . . . . . . . 235
5.48. Selección del fichero con el mensaje en claro . . . . . . . . . . . . . . 235
5.49. Identificador del fichero con el mensaje en claro . . . . . . . . . . . . 236
5.50. Selección del fichero para el criptograma . . . . . . . . . . . . . . . . 236
5.51. Identificador del fichero para el criptograma . . . . . . . . . . . . . . 237
5.52. Contenido de la caja de texto de la etiqueta . . . . . . . . . . . . . . 237
5.53. Ventana con el resultado del proceso de cifrado . . . . . . . . . . . . 238
5.54. Selección del fichero con la clave privada del destinatario . . . . . . . 238
5.55. Introducción de la contraseña para el acceso a la clave privada . . . . 239
5.56. Identificador de la clave privada del destinatario . . . . . . . . . . . . 239
5.57. Selección del fichero con el criptograma . . . . . . . . . . . . . . . . . 240
5.58. Identificador del fichero con criptograma . . . . . . . . . . . . . . . . 240
5.59. Selección del fichero para el mensaje descifrado . . . . . . . . . . . . 241
Índice de figuras xxiii
5.60. Identificador del fichero para el mensaje descifrado . . . . . . . . . . . 241

5.61. Contenido de la caja de texto de la etiqueta . . . . . . . . . . . . . . 241
5.62. Ventana con el resultado del proceso de descifrado . . . . . . . . . . . 242
6.1. Ventana principal del entorno de desarrollo Eclipse . . . . . . . . . . 249

6.2. Tamaño de los aplets JCOP-M2, JCOP-P2 y JCOP-P3 . . . . . . . . 257
6.3. Pestaña Configuración . . . . . . . . . . . . . . . . . . . . . . . . . . 258
6.4. Lectores de tarjetas disponibles . . . . . . . . . . . . . . . . . . . . . 259
6.5. Curvas implementadas en JCOP 41 y JCOP J3A . . . . . . . . . . . 259
6.6. Generación y recuperación de una clave pública de 192 bits . . . . . . 259
6.7. Pestaña Cifrado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260
6.8. Pestaña Descifrado . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261
6.9. Pestaña Acerca . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262
6.10. Errores asociados al lector, la curva o la tarjeta . . . . . . . . . . . . 262
6.11. Generación de nuevas claves en JCOP 41 . . . . . . . . . . . . . . . . 264
6.12. Parámetros de las claves de 193 bits de U en JCOP 41 . . . . . . . . 265
6.13. Parámetros de las claves de 193 bits de V en JCOP 41 . . . . . . . . 266
6.14. Comandos para cifrar un mensaje ejecutados por U en JCOP 41 . . . 268
6.15. Comandos de descifrado ejecutados por V en JCOP 41 . . . . . . . . 269
6.16. Ventana APDU con datos de descifrado . . . . . . . . . . . . . . . . . 270
7.1. Diagrama de los módulos P5CT072 y P5CD080 . . . . . . . . . . . . 273

7.2. Tarjetas JCOP y lector PC/SC empleados en las pruebas . . . . . . . 274
7.3. Frecuencias de trabajo en la interfaz con contactos y sin contactos . . 275
7.4. Factor de expansión en curvas sobre 𝔽2𝑚 con la configuración M1 . . 281
7.6. Factor de expansión en curvas sobre 𝔽𝑝 con la configuración P1 . . . 284
7.9. Tiempo de cifrado con curvas sobre 𝔽2𝑚 en PC (configuración M1) . . 290
xxiv Índice de figuras
7.11. Tiempo de cifrado con curvas sobre 𝔽2𝑚 en JCOP 41 e interfaz sin
contactos (configuración M2) . . . . . . . . . . . . . . . . . . . . . . . 292
7.12. Tiempo de cifrado con curvas sobre 𝔽2𝑚 en JCOP 41 e interfaz con
7.13. Tiempo de cifrado con curvas sobre 𝔽𝑝 en PC (configuración P1) . . . 294
7.15. Tiempo de cifrado con curvas sobre 𝔽𝑝 en JCOP J3A e interfaz sin
contactos (configuración P2) . . . . . . . . . . . . . . . . . . . . . . . 296
7.18. Tiempo de descifrado con curvas sobre 𝔽2𝑚 en PC (configuración M1) 300
7.20. Tiempo de descifrado con curvas sobre 𝔽2𝑚 en JCOP 41 e interfaz sin
7.21. Tiempo de descifrado con curvas sobre 𝔽2𝑚 en JCOP 41 e interfaz
con contactos (configuración M2) . . . . . . . . . . . . . . . . . . . . 303
7.22. Tiempo de descifrado con curvas sobre 𝔽𝑝 en PC (configuración P1) . 304
7.24. Tiempo de descifrado con curvas sobre 𝔽𝑝 en JCOP J3A e interfaz
sin contactos (configuración P2) . . . . . . . . . . . . . . . . . . . . . 306
7.27. Comparación del tiempo de ejecución en PC (configuraciones M1 y P1)309
7.28. Comparación del tiempo de ejecución entre las versiones PC y Java
Card (configuración M2) . . . . . . . . . . . . . . . . . . . . . . . . . 310
Card (configuración P2) . . . . . . . . . . . . . . . . . . . . . . . . . 310
Card (configuración P3) . . . . . . . . . . . . . . . . . . . . . . . . . 311
7.31. Comparación del tiempo de ejecución en las tarjetas JCOP 41 (con-
figuración M2) y JCOP J3A (configuración P2) al cifrar un mensaje
de 64 bytes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312
Índice de figuras xxv
7.32. Comparación del tiempo de ejecución en JCOP 41 (configuración M2)

y JCOP J3A (configuración P2) al cifrar un mensaje de 160 bytes . . 312
Índice de cuadros
1. Comparación de las longitudes de clave entre RSA y ECC . . . . . . 2

2. Comparación del rendimiento de ECC, RSA y los esquemas DLP
medido en unidades de tiempo necesarias para cada operación . . . . 3
3. Comparación de las implementaciones hardware de RSA y ECC . . . 4
1.1. Valores del byte CLA permitidos . . . . . . . . . . . . . . . . . . . . 44

1.2. Valores del byte CLA permitidos . . . . . . . . . . . . . . . . . . . . 45
2.1. Versiones simplificadas de la ecuación de Weierstrass . . . . . . . . . 82
3.1. Clases e interfaces del paquete javacard.security . . . . . . . . . . 125

3.2. Clases e interfaces del paquete javacardx.crypto . . . . . . . . . . . 125
4.1. Comparativa del proceso de cifrado en ECIES, PSEC y ACE . . . . . 133

4.2. Número de operaciones para el cifrado en ECIES, PSEC y ACE . . . 134
4.3. Rendimiento del cifrado en ECIES, PSEC y ACE . . . . . . . . . . . 135
4.4. Comparativa de longitudes en bytes para ECIES, PSEC y ACE . . . 135
4.5. Función HASH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
4.6. Función KA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
4.7. Función KDF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
4.8. Función ENC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
4.9. Función MAC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
4.10. Funciones comunes permitidas en los cuatro estándares . . . . . . . . 170
4.11. Combinaciones de parámetros admitidas al menos en un estándar . . 171
4.12. Comparativa de las configuraciones permitidas en cada estándar . . . 172
xxvii
xxviii Índice de cuadros
6.1. Funcionalidades ECC en Java Card . . . . . . . . . . . . . . . . . . . 246
7.1. Curvas elípticas empleadas en las configuraciones . . . . . . . . . . . 278

7.9. Tiempo de cifrado con curvas sobre 𝔽2𝑚 en JCOP 41 e interfaz sin
7.10. Tiempo de cifrado con curvas sobre 𝔽2𝑚 en JCOP 41 e interfaz con
7.18. Tiempo de descifrado con curvas sobre 𝔽2𝑚 en JCOP 41 e interfaz sin
7.19. Tiempo de descifrado con curvas sobre 𝔽2𝑚 en JCOP 41 e interfaz
Índice de cuadros xxix

8.1. Crecimiento del tiempo de cifrado y descifrado en PC (configuración

M1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317
8.2. Crecimiento del tiempo de cifrado y descifrado en PC (configuración
P1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 318
8.3. Crecimiento del tiempo de cifrado y descifrado en JCOP 41 e interfaz
sin contactos (configuración M2) . . . . . . . . . . . . . . . . . . . . . 320
8.4. Crecimiento del tiempo de cifrado y descifrado en JCOP 41 e interfaz
8.5. Crecimiento del tiempo de cifrado y descifrado en JCOP J3A e inter-
faz sin contactos (configuración P2) . . . . . . . . . . . . . . . . . . . 321
8.6. Crecimiento del tiempo de cifrado y descifrado en JCOP J3A e inter-
faz sin contactos (configuración P3) . . . . . . . . . . . . . . . . . . . 321
8.7. Incremento relativo del tiempo de ejecución en JCOP 41 e interfaz
sin contactos (configuración M2) . . . . . . . . . . . . . . . . . . . . . 323
8.8. Incremento relativo del tiempo de ejecución en JCOP 41 e interfaz
8.9. Incremento relativo del tiempo de ejecución en JCOP J3A e interfaz
8.10. Incremento relativo del tiempo de ejecución en JCOP J3A e interfaz
Índice de algoritmos
2.1. Establecimiento de clave Diffie-Hellman . . . . . . . . . . . . . . . . 58

2.2. Generación de claves RSA . . . . . . . . . . . . . . . . . . . . . . . . 60
2.3. Cifrado RSA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
2.4. Descifrado RSA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
2.5. Generación de claves para el criptosistema ElGamal . . . . . . . . . 65
2.6. Cifrado de mensajes en el criptosistema ElGamal . . . . . . . . . . . 66
2.7. Descifrado de mensajes en el criptosistema ElGamal . . . . . . . . . 66
2.8. Compresión de un punto 𝑃 = (𝑥, 𝑦) de la curva . . . . . . . . . . . . 89
2.9. Descompresión de un punto 𝑃 = (𝑥, 𝑦) de la curva . . . . . . . . . . 89
2.10. Generación aleatoria de una curva sobre 𝔽2𝑚 . . . . . . . . . . . . . 90
2.11. Comprobación de los parámetros de una curva . . . . . . . . . . . . 91
2.12. Validación de una clave pública 𝑄 . . . . . . . . . . . . . . . . . . . 91
4.1. Criptosistema Massey-Omura con curvas elípticas . . . . . . . . . . 130
4.2. Criptosistema ElGamal con curvas elípticas . . . . . . . . . . . . . . 130
4.3. Criptosistema Menezes-Vanstone con curvas elípticas . . . . . . . . . 131
4.4. Función ANSI-X9.63-KDF . . . . . . . . . . . . . . . . . . . . . . . 142
4.5. Función NIST-800-56-Concatenation-KDF . . . . . . . . . . . . . . . 143
4.6. Función KDF1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
4.7. Función KDF2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
4.8. Función HMAC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
4.9. Cifrado ECIES en ANSI X9.63 . . . . . . . . . . . . . . . . . . . . . 149
4.10. Cifrado ECIES en IEEE 1363a . . . . . . . . . . . . . . . . . . . . . 154
4.11. Fase KEM del cifrado ECIES en ISO/IEC 18033-2 . . . . . . . . . . 157
xxxi
xxxii Índice de algoritmos
4.12. Función DEM1 de la fase DEM del cifrado ECIES en ISO/IEC

18033-2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
18033-2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
18033-2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
4.15. Cifrado ECIES en SEC 1 . . . . . . . . . . . . . . . . . . . . . . . . 163
4.16. Cifrado ECIES compatible con los cuatro estándares (ECIES-4) . . . 173
4.17. Cifrado ECIES compatible con los cuatro estándares (ECIES-3) . . . 179
5.1. Cifrado ECIES en la versión PC (fase KEM ) . . . . . . . . . . . . . 182
5.2. Cifrado ECIES en la versión PC (fase DEM ) . . . . . . . . . . . . . 183
5.3. Descifrado ECIES en la versión PC (fase KEM ) . . . . . . . . . . . 184
5.4. Descifrado ECIES en la versión PC (fase DEM ) . . . . . . . . . . . 184
5.5. Generación de una semilla aleatoria . . . . . . . . . . . . . . . . . . 209
Introducción
Antecedentes
En 1976, Whitfield Diffie y Martin Hellman [61] desarrollaron los conceptos que
permitieron el nacimiento de la criptografía de clave pública. Desde entonces, nu-
merosos criptosistemas han sido propuestos, aunque sólo unos pocos han soportado
con éxito el escrutinio de la comunidad científica. Entre los elementos analizados
por los expertos destacan principalmente las características de eficiencia, compleji-
dad y seguridad de los algoritmos, las cuales dependen en gran medida del problema
matemático en que están basados. Algunos de los problemas relacionados con los
criptosistemas actuales son:
∙ Factorización en enteros (Integer Factorization Problem o IFP), fundamento

del criptosistema RSA [66, 232, 229].
∙ Logaritmo discreto (Discrete Logarithm Problem o DLP), base matemática

para el algoritmo ElGamal [69].
∙ Logaritmo discreto en curvas elípticas (Elliptic Curve Discrete Logarithm Pro-

blem o ECDLP), núcleo de la criptografía basada en curvas elípticas.
En 1985, Neal Koblitz [147] y Victor Miller [174] propusieron de forma inde-
pendiente el uso de curvas elípticas en criptografía (Elliptic Curve Cryptography o
ECC), cuya seguridad depende del ECDLP. Desde entonces, la ECC se ha aplicado
a campos tan diversos como la creación de criptosistemas para el cifrado y descifrado
de datos [16, 109, 136, 254], la generación y verificación de firmas digitales [15, 184],
la factorización de enteros [49, 159], las técnicas de primalidad [23, 49, 95], e incluso
ocupó un lugar destacado en la demostración del último teorema de Fermat por
parte de Andrew Wiles [269].
1
2 Introducción
Al igual que en el caso del IFP y del DLP, no se conoce ningún algoritmo que
resuelva de forma eficiente el ECDLP. De hecho, se estima que el ECDLP es el más
difícil de resolver de los tres problemas mencionados [37, 147, 168], lo que convertiría
la criptografía con curvas elípticas en el criptosistema más resistente.
Gracias a esta mayor resistencia, la longitud de las claves en ECC es sensible-
mente inferior que la necesaria en otros algoritmos para conseguir el mismo nivel
de seguridad (medido como la fortaleza proporcionada por un algoritmo de cifrado
simétrico que utilice una clave de 𝑛 bits), tal como se puede observar en el Cuadro 1
y la Figura 1 (cuyos datos han sido obtenidos de [99] y [184]), lo que favorece su
uso en sistemas con recursos limitados como por ejemplo los teléfonos móviles y las
tarjetas inteligentes.
Nivel de seguridad Longitud de la Longitud de la

(bits) clave RSA (bits) clave ECC (bits)
80 1024 160-223
112 2048 224-255
128 3072 256-283
192 7680 384-511
256 15360 512-571
Cuadro 1: Comparación de las longitudes de clave entre RSA y ECC
Debido a su reciente aparición, al menos en comparación con otros algoritmos de

clave pública como el propio criptosistema RSA, las propiedades y posibilidades de
utilización de la criptografía de curva elíptica han sido estudiadas en menor profun-
didad que otras opciones criptográficas, lo que ha motivado su menor implantación
en el entorno de las soluciones de seguridad.
Sin embargo, ello no impide que existan estudios que reflejen el rendimiento
comparado de RSA y ECC en operaciones de cifrado/descifrado y firma/verificación,
como por ejemplo el informe [233] realizado por RSA Labs, donde entre los datos
ofrecidos se encuentra el Cuadro 2. En dicho cuadro, las cantidades reflejadas hacen
referencia al número de unidades temporales necesarias para realizar las operaciones
citadas, tomando como unidad de referencia el tiempo necesario para realizar una
multiplicación modular de 1024 bits.
Por su parte, los autores de [38] presentaron una comparación entre ECC y RSA
utilizando dos implementaciones hardware distintas, diseñadas para conseguir la me-
jor optimización en el espacio ocupado y la velocidad de ejecución del proceso de
cifrado, respectivamente. Los resultados de dicho análisis se presentan en el Cua-
dro 3, donde se puede comprobar que el tiempo de procesamiento global (cifrado más
descifrado) de ECC mejora respecto al de RSA al pasar de utilizar implementaciones
software a emplear diseños hardware optimizados para las operaciones criptográficas
Introducción 3
Figura 1: Longitudes de clave en RSA y ECC
ECC 160 bits RSA 1024 bits (con CRT) DLP 1024 bits
Cifrado 120 17 480
Descifrado 60 384 240
Firma 60 384 240
Verificación 120 17 480
Cuadro 2: Comparación del rendimiento de ECC, RSA y los esquemas DLP medido en
unidades de tiempo necesarias para cada operación
4 Introducción
necesarias.
Optimización Tiempo (ms) Puertas lógicas

RSA 1024 4.90 34000
Espacio
ECC 163 0.66 3260
RSA 1024 2.60 150000
Velocidad
ECC 163 0.35 48400
RSA 3072 184 50000
Espacio
ECC 283 29 6660
RSA 3072 110 189200
Velocidad
ECC 283 1.3 80100
Cuadro 3: Comparación de las implementaciones hardware de RSA y ECC
En resumen, los datos presentados confirman las mejores prestaciones globales

de ECC respecto de RSA, por lo que es de esperar que los criptosistemas basados
en curvas elípticas aumenten su importancia y utilidad aún más en el futuro según
se incrementen en paralelo los requisitos de seguridad.
Justificación
A la vista de la situación planteada en el apartado anterior, y dada la escasez de
implementaciones software de ECC en general (y en tarjetas inteligentes en particu-
lar), se estimó la importancia de desarrollar diversas aplicaciones que implementaran
un protocolo de cifrado y descifrado sobre curvas elípticas en entornos PC y tarjetas
inteligentes, siendo Java el lenguaje de programación elegido debido a su populari-
dad y presencia en entornos comerciales (ver §3.2 y §3.4). A título informativo, la
cifra de desarrolladores Java supera en la actualidad los 6 millones, existiendo más
de 4.500 millones de dispositivos habilitados con tecnología Java (principalmente
ordenadores personales, teléfonos móviles y tarjetas inteligentes) [212].
El siguiente paso consistió en analizar los diferentes esquemas de cifrado exis-
tentes y seleccionar uno de los candidatos para su implementación. Los primeros
esquemas basados en curvas elípticas que surgieron fueron el equivalente de los sis-
temas Massey-Omura [205] y ElGamal [69], ambos presentados por Koblitz en 1985
[147]. Una de las principales desventajas de esos esquemas consiste en que asocian
cada mensaje a cifrar con un punto de la curva elíptica. Si bien es cierto que en las
curvas utilizadas habitualmente el número de puntos es un valor tan elevado que esta
limitación es más teórica que práctica, la obligatoriedad de construir tablas donde
se relacionen cada uno de los posibles mensajes (y que éstas sean previamente co-
nocidas por todos los usuarios) limita la utilidad de estos criptosistemas a entornos
Introducción 5
cerrados donde todos los posibles mensajes estén estipulados (empresas, pequeños
grupos, etc.).
El criptosistema Menezes-Vanstone [169] fue diseñado para solventar esa limi-
tación, puesto que en lugar de hacer corresponder cada mensaje con un punto de la
curva, este esquema representa los mensajes en claro como pares ordenados cuyos
componentes son elementos del cuerpo finito sobre el que se define la curva elíptica.
De esta manera, es posible dividir cualquier mensaje en claro en bloques, donde cada
bloque pueda ser codificado como un par ordenado (por ejemplo, convirtiendo una
cadena de caracteres o bytes en su equivalente numérico). Como contrapartida nega-
tiva, la longitud del criptograma resultante es variable y depende directamente de la
longitud del mensaje a cifrar (a diferencia de los criptosistemas Massey-Omura y El-
Gamal para curvas elípticas, donde el criptograma siempre tiene la misma longitud
independientemente del mensaje en claro).
En el esquema Menezes-Vanstone el factor de expansión (que se define como
el cociente entre la longitud del criptograma resultante y la longitud del mensaje
original) es 2, puesto que a partir del mensaje en claro compuesto por dos elementos
del cuerpo finito se obtiene un criptograma formado por cuatro elementos del mismo
cuerpo. En comparación, la variante de ElGamal con curvas elípticas tiene el mismo
factor de expansión si se considera que el mensaje en claro es un punto de la curva,
mientras que si se interpreta que el número total de mensajes posibles es igual
al número de puntos de la curva (que es del orden del número de elementos del
cuerpo finito), entonces el factor de expansión sería aproximadamente 4 (ver §4.1).
El hecho de tener un factor de expansión igual a 2 ó 4 conlleva que el cifrado de
volúmenes de información elevados generen criptogramas de tamaño mucho mayor
que si se utilizara un algoritmo de clave simétrica como por ejemplo AES (Advanced
Encryption Standard).
Otra desventaja derivada del diseño del criptosistema Menezes-Vanstone consis-
te en la realización de operaciones con los puntos de las curvas elípticas en cada
proceso de cifrado. Al ser necesario dividir los mensajes en claro de gran tamaño en
múltiples segmentos, y realizar un operación de cifrado asimétrico con cada uno de
ellos, la diferencia en tiempo de ejecución del esquema Menezes-Vanstone respecto
a un algoritmo de cifrado simétrico se incrementa conforme aumenta el número de
segmentos a cifrar, puesto que las operaciones con puntos son más lentas que los
cálculos realizados por los algoritmos de clave simétrica.
De manera adicional a las desventajas de carácter práctico señaladas, Klaus Kie-
fer demostró en 1998 que, bajo ciertas ciertas condiciones, el criptosistema Menezes-
Vanstone es inseguro [146]. Kiefer demostró además que, en contra de lo estipulado
en su especificación, este criptosistema no puede ser considerado un algoritmo de
cifrado probabilístico.
Debido a todas las razones comentadas, con el paso de los años la comunidad
académica ha ido abandonando el estudio de las versiones con curvas elípticas de
6 Introducción
los criptosistemas Massey-Omura, ElGamal y Menezes-Vanstone. Sin embargo, el

descubrimiento de las limitaciones de esos criptosistemas no significó que se abando-
nara la búsqueda de un criptosistema de curvas elípticas que fuera práctico y seguro,
sino que provocó un cambio de dirección, pasando a ocupar el centro de atención
los esquemas de cifrado híbridos (descritos en §2.5). Los principales esquemas híbri-
dos que emplean curvas elípticas son ECIES (Elliptic Curve Integrated Encryption
Scheme), PSEC (Provably Secure Elliptic Curve encryption scheme) [199, 243] y
ACE (Advanced Cryptographic Engine) [55, 243].
De los tres esquemas, ECIES es el que está presente en un mayor número de
estándares (ANSI X9.63 [16], IEEE 1363a [109], ISO/IEC 18033-2 [136] y SECG
SEC 1 [254]). Por su parte, PSEC se puede encontrar en ISO/IEC 18033-2 [136],
IETF RFC 4051 [68] y en el conjunto de algoritmos seleccionados por el proyecto
NESSIE (New European Schemes for Signatures, Integrity and Encryption) [195,
196], mientras que ACE está presente en ISO/IEC 18033-2 [136] y en la selección
final de NESSIE [195, 196].
Las principales diferencias entre los esquemas ECIES, PSEC y ACE, presentadas
en §4.1, son las siguientes:
∙ Tanto en ECIES como en PSEC, la clave pública del receptor del criptograma
es un punto de la curva, mientras que en ACE la clave pública está formada
por cuatro puntos.
∙ PSEC utiliza dos veces una función de derivación de claves, mientras que
ECIES y ACE sólo la utilizan una vez.
∙ ECIES y ACE utilizan la primera coordenada de un punto de la curva gene-

rado durante los cálculos intermedios (en lugar de las dos coordenadas) como
parámetro de entrada de la función de derivación de claves, mientras que en
PSEC es obligatorio utilizar las dos coordenadas.
∙ Los criptogramas de ECIES están formados por tres elementos (un punto de
la curva, el mensaje cifrado con una clave simétrica y un dato utilizado para la
autenticación del mensaje), mientras que los criptogramas de PSEC incluyen
además un elemento derivado de los cálculos intermedios (y representado como
una cadena binaria) y los criptogramas del esquema ACE añaden dos puntos
de la curva elíptica.
En la comparación de los esquemas ECIES, PSEC y ACE realizada en esta

Tesis (ver §4.1) se identificaron tres aspectos fundamentales: eficiencia, seguridad y
adaptabilidad a las plataformas hardware de trabajo.
Respecto a la eficiencia, tanto el número de operaciones necesarias como de ciclos
de reloj, el tiempo de proceso y el factor de expansión resultante muestran una clara
ventaja de ECIES frente a PSEC y ACE.
Introducción 7
La seguridad comparada de los tres esquemas candidatos es un tema sobre el que

no existe acuerdo en la comunidad académica. El informe final del proyecto NESSIE
seleccionó a PSEC y ACE como esquemas de cifrado asimétrico, dejando fuera de la
selección a ECIES. Ello se debió, entre otros factores, a que ECIES no es inmune a
problemas de maleabilidad benigna (ver §4.9.1.1) y que se trata de un esquema no
autenticado, es decir, no comprueba si los datos intermedios generados durante los
cálculos son correctos en función de los demás parámetros del criptograma, mientras
que en comparación PSEC y ACE son esquemas autenticados y no son susceptibles
de problemas de maleabilidad benigna.
Sin embargo, tal como se describe en §4.9 existen diversas soluciones para evitar
la maleabilidad benigna. Además, la utilidad en la práctica de la autenticación de los
datos intermedios del proceso de cifrado no está clara, puesto que los tres esquemas
emplean de forma adicional un algoritmo de autenticación de los datos a cifrar, por
lo que la primera autenticación podría considerarse redundante [58].
El último aspecto presente en la evaluación de los candidatos consiste en el grupo
de funcionalidades disponibles en los dispositivos sobre los que se implementará el
esquema de cifrado. Aunque ciertamente en la versión PC no existen limitaciones
a este respecto, puesto que cualquier función criptográfica puede ser codificada me-
diante el lenguaje Java, en cambio en Java Card existen importantes limitaciones,
puesto que por ejemplo en sus API (Application Programming Interface) no existen
métodos para realizar directamente operaciones de suma de puntos o productos de
un escalar por un punto de la curva, existiendo en cambio la posibilidad de utilizar
la función Diffie-Hellman sobre curvas elípticas, que se puede considerar equivalente
al producto escalar pero con la particularidad de que el API de Java Card define
como salida de dicha función la primera coordenada del punto de la curva que re-
presenta la multiplicación o bien el resultado de pasar dicha coordenada a través de
una función resumen (hash, en inglés).
Tras evaluar los tres criterios mencionados (rendimiento, seguridad y funcionali-
dad disponible en las plataformas PC y Java Card), en vista de sus características, y
considerando como elemento positivo adicional su mayor difusión en los estándares,
el esquema seleccionado para su implementación tanto en PC como en tarjetas Java
Card fue ECIES.
Una vez seleccionado el esquema de cifrado y el lenguaje de programación, la
siguiente decisión que era necesario tomar estaba relacionada con el tipo de desarrollo
software a realizar. En este sentido, el desarrollo de aplicaciones Java que utilicen
algoritmos ECC implica necesariamente una de las siguientes opciones:
1. Utilización de bibliotecas criptográficas de terceros adaptadas a la arquitectura

de seguridad Java.
2. Uso de bibliotecas criptográficas de terceros con clases y sintaxis propietarias,
no adaptadas a la arquitectura Java.
8 Introducción
3. Desarrollo propio de los algoritmos relacionados con la ECC y de las opera-

ciones aritméticas con los puntos de las curvas elípticas y con los elementos de
los cuerpos finitos.
La primera opción referida permite un desarrollo rápido, al utilizar paquetes crip-

tográficos (en la medida de lo posible de código abierto) ya probados y de notable
calidad. Sin embargo, esta opción limita la utilización de parámetros a los contem-
plados por dichas bibliotecas, que tal como se describirá en §3.3 no ofrecen todas
las combinaciones posibles de algoritmos y parámetros que se deseaban analizar en
esta Tesis.
La segunda opción es, probablemente, la menos recomendable, al crear una de-
pendencia respecto a unas clases no interoperables de otros proveedores, con la
dificultad inherente de una migración futura que tenga previsto utilizar software de
otro proveedor, manteniendo al mismo tiempo la limitación sobre las combinaciones
de algoritmos y parámetros incluidas en la distribución.
La última opción, por el contrario, permite un grado de flexibilidad superior,
al contemplar el desarrollo bajo demanda de las capacidades de la ECC necesarias,
incluyendo en el proceso las combinaciones de parámetros que requiera el proyecto.
El aspecto negativo de esta opción lo constituye el coste en tiempo y esfuerzo del
desarrollo en comparación con las soluciones ya existentes, aunque una vez comple-
tado el desarrollo de la biblioteca criptográfica, ésta se podría reutilizar en cualquier
desarrollo posterior.
En la presente Tesis Doctoral, se ha optado por el desarrollo propio para imple-
mentar una aplicación de PC que permita realizar las operaciones de cifrado y des-
cifrado empleando una elevada combinación de parámetros. Además de las ventajas
enunciadas anteriormente, este mecanismo aporta la flexibilidad adicional necesa-
ria para poder llevar a cabo las comparaciones con la implementación de ECIES a
realizar en tarjetas Java Card.
En cuanto a la implementación en tarjetas inteligentes, dadas las limitaciones
tanto en las API estándar de Java Card (ver §6.2) como en las funcionalidades dis-
ponibles en tarjetas reales (ver §7.1), únicamente ha sido posible desarrollar algunas
de las posibles combinaciones de parámetros y funciones de ECIES (ver §7.2).
El último paso antes de comenzar la implementación de ECIES consistió en com-
probar que los objetivos de la Tesis no hubieran sido logrados por otros autores. Tras
realizar las búsquedas correspondientes y analizar el contenido de otras tesis, pro-
yectos fin de carrera, artículos de investigación y ponencias de congresos, fue posible
identificar una serie de trabajos relacionados con implementaciones Java de curvas
elípticas en tarjetas inteligentes o plataformas PC. A continuación se detallan dichos
trabajos, adjuntando las razones por los que sus objetivos y desarrollos difieren de
los de la presente Tesis.
Introducción 9
∙ Elliptic curve cryptography on smart cards [218]: se trata de un Proyecto Fin

de Carrera presentado el año 2000 en el que, con el objetivo de comparar ECC
y RSA en tarjetas inteligentes, se muestra una implementación de los algo-
ritmos Nyberg-Rueppel de firma digital y Menezes-Vanstone de cifrado. La
implementación desarrollada emplea únicamente curvas definidas sobre cuer-
pos 𝔽2𝑚 , utilizando para la realización de las pruebas el emulador software
incluido en Java Card 2.1, sin presentar ningún resultado con tarjetas reales.
∙ Smart-card implementation of Elliptic Curve Cryptography and DPA-based at-

tacks [142]: este artículo analiza los ataques de canal lateral (también conocidos
como side channel attacks) diseñados específicamente para tarjetas inteligen-
tes que implementen criptografía de curva elíptica. El artículo se centra en
el análisis de seguridad, proponiendo algunas medidas para evitar ataques de
análisis de potencia (Differential Power Analysis o DPA) al utilizar curvas
sobre cuerpos 𝔽2𝑚 , pero sin tratar específicamente el esquema ECIES.
∙ Lessons learned on implementing ECDSA on a Java smart card [71]: artículo

que describe las dificultades de implementar clases propietarias para la eje-
cución del algoritmo de firma digital ECDSA [15, 184], y que concluye que
dicha implementación en tarjetas Java Card no es práctica, siendo preferible
que existan clases estándar incluidas en la tarjeta, y que éstas utilicen un co-
procesador. Como dato ilustrativo, el tiempo necesario para obtener el inverso
de un elemento de un cuerpo finito 𝔽𝑝 , con ⌈log2 𝑝⌉ = 50, es de 370 segundos.
∙ Implementation of ECC/ECDSA Cryptography Algorithms Based on Java Card

[98]: se trata de una implementación de ECDSA en una placa de simulación
NGICC (Next Generation Integrated Circuit Card) de 32 bits con coprocesa-
dor criptográfico y soporte nativo para funciones de ECC mediante API de
Java Card. Tras la implementación, los autores comparan el rendimiento de
ECDSA con RSA para concluir que la ejecución de ECDSA es más eficiente.
∙ Elliptic curve cryptosystems on smart cards [178]: artículo que describe de

forma teórica la implementación de un protocolo de acuerdo de clave para
tarjetas inteligentes basado en las operaciones del algoritmo de firma digital
ECDSA. Este trabajo presenta una comparación del rendimiento entre RSA y
ECDSA en un PC, pero no incluye comparaciones en tarjetas inteligentes ni
aporta detalles sobre el sistema operativo de las tarjetas a utilizar.
∙ Implementing Elliptic Curve Cryptography on PC and smart card [28]: artículo

en que los autores implementaron las clases necesarias para realizar aritmética
modular y de puntos en tarjetas Java Card 2.0 y 2.1. Como ejemplo del bajo
rendimiento de la implementación, la suma de dos puntos de una curva de 109
bits definida sobre 𝔽2𝑚 tardaba 10 minutos, debido a que la tarjeta empleada
no disponía de API especificas para ECC ni de coprocesador matemático. Este
trabajo reitera la imposibilidad de desarrollar implementaciones eficientes con
10 Introducción
curvas elípticas en tarjetas inteligentes sin utilizar las clases y los métodos
definidos en las API estándar de Java Card.
La lectura del material referido ofrece datos concluyentes respecto a las limitacio-
nes de las implementaciones que no utilicen las clases y API estándar de Java Card.
Aunque técnicamente es posible crear clases y métodos que realicen operaciones
comúnmente conocidas como “de bajo nivel” (por ejemplo, Petr Svenda ha creado
implementaciones del algoritmo AES y de la función resumen SHA-512 utilizando
código Java Card [258]), los resultados ofrecidos por implementaciones desarrolladas
sin acceso al coprocesador indican que dichas implementaciones no son de utilidad
para entornos comerciales, donde el tiempo de respuesta de las tarjetas a una ope-
ración no debería superar la cantidad de un segundo (compárese este dato, por
ejemplo, con los 10 minutos utilizados en la suma de dos puntos según [28], o con
el tiempo medio de 4 segundos al cifrar con AES un único bloque de datos con la
implementación descrita en [258]).
Objetivos
El objetivo general de la presente Tesis Doctoral consiste en implementar el
protocolo de cifrado ECIES (Elliptic Curve Integrated Encryption Scheme), tanto
en plataforma PC como en tarjetas inteligentes Java Card, a fin de:
∙ Analizar la viabilidad de diferentes implementaciones para determinadas com-

binaciones de parámetros.
∙ Comparar el rendimiento de las implementaciones en PC y Java Card, tanto

por separado como de forma conjunta.
∙ Recomendar combinaciones específicas para su utilización en distintos tipos de

dispositivos, en función de las características de los dispositivos y del nivel de
seguridad deseado.
Para conseguir este objetivo general, se pretenden alcanzar los siguientes obje-
tivos particulares:
1. Analizar el protocolo de cifrado y descifrado ECIES con el fin de determinar

hasta qué punto las diferentes propuestas hechas para el mismo conforman un
estándar coherente y homogéneo.
2. Proponer un conjunto (o conjuntos) de parámetros que sean compatibles con

todos los estándares analizados.
Introducción 11
3. Desarrollar una implementación de ECIES utilizando el lenguaje de progra-

mación Java sobre una plataforma PC que permita trabajar con los conjuntos
de parámetros propuestos y curvas definidas sobre cuerpos finitos primos y
binarios.
4. Estudiar la eficiencia en términos de tiempo de computación y de factor de

expansión de la implementación para PC.
5. Implementar el protocolo ECIES en tarjetas inteligentes de tipo Java Card,

según la oferta y disponibilidad de tarjetas existentes en el mercado, con curvas
definidas tanto sobre cuerpos finitos primos como binarios.
6. Caracterizar en términos de eficiencia la implementación realizada en las tar-

jetas Java Card utilizando curvas definidas sobre los dos cuerpos finitos ante-
riormente mencionados.
7. Comparar la implementación de ECIES llevada a cabo sobre la plataforma PC

con la desarrollada en Java Card, teniendo presentes las diferencias existentes
en sus respectivas arquitecturas, así como las características de programación
de cada una de las plataformas.
8. Recomendar una configuración de ECIES que asegure su resistencia a los di-

ferentes tipos de ataques conocidos, comprobando si dicha configuración es
aplicable tanto a la plataforma PC como a Java Card.
Es importante aclarar que queda fuera del ámbito de la presente Tesis el estudio
de la seguridad de las implementaciones ECC en Java Card para evitar ataques de
canal lateral. La existencia de este tipo de ataques es bien conocida en la comunidad
académica tanto en sus aspectos más generales [103, 145, 150, 151, 152], como de
manera específica para implementaciones de curvas elípticas [30, 92, 142, 181]. Sin
embargo, puesto que la implementación Java Card desarrollada en esta Tesis utiliza
tarjetas inteligentes comerciales de las que no se ha podido obtener información
sobre las soluciones implementadas para evitar este tipo de ataques, y dado que
el equipamiento necesario (equipos láser y de implantación iónica, laboratorio de
tratamientos químicos, etc.) para realizar este tipo de ataques es extremadamente
costoso, los análisis de ataques de canal lateral para las tarjetas empleadas quedan
reservados para organismos o instituciones dedicadas de forma preeminente a este
tipo de actividades.
Metodología
Teniendo en cuenta los objetivos señalados anteriormente, la metodología em-
pleada a lo largo de este trabajo de investigación ha consistido en estudiar el sistema
12 Introducción
de cifrado ECIES haciendo uso de la bibliografía general sobre criptografía y de los

estándares donde tal sistema es propuesto y presentado. Posteriormente se ha llevado
a cabo el diseño e implementación de este esquema de cifrado.
Para llevar a cabo estas tareas se han consultado las bibliotecas de diferentes
universidades y del Instituto de Física Aplicada del Consejo Superior de Investiga-
ciones Científicas, así como las principales bases de datos en Internet. También se
ha consultado y pedido opinión a investigadores y expertos nacionales y extranjeros,
entre los que cabe destacar al profesor Alfred Menezes.
En la parte del análisis del estándar ECIES, se ha llevado a cabo un estudio por-
menorizado de sus características, según la propuesta de cada uno de los organismos
que lo incluyen, y se han comparado tales propuestas, obteniéndose las conclusiones
apropiadas.
Con relación a la parte del diseño e implementación del software para ECIES en
Java, se ha recurrido al uso de las dos técnicas metodológicas típicas para este tipo
de trabajos de investigación y desarrollo: dividir el problema a resolver en problemas
menores y realizar pruebas de ensayo y error. Así, al margen del diseño del trabajo
a desarrollar, que ha sido estructurado de modo jerárquico, la implementación se ha
dividido en bloques de trabajo pequeños de modo que la estructura de la programa-
ción final fuera coherente, pero que permitiera, al mismo tiempo, probar cada una
de las tareas menores de forma independiente. En estas pruebas se ha hecho uso del
ensayo y error con el fin de ajustar cada uno de los resultados parciales y comprobar
su exactitud. Una vez que cada parte ha sido resuelta adecuadamente, se han unido
con el fin de obtener un resultado completo. Este proceso de unión ha conllevado un
nuevo estudio de cada una de las partes con el fin de lograr una mayor eficiencia a
la hora de ensamblar cada una de ellas.
Los costes derivados de las consultas bibliográficas y para la adquisición de ar-
tículos y libros han sido sufragados por diferentes proyectos y contratos de investiga-
ción del Departamento de Tratamiento de la Información y Codificación del Instituto
de Física Aplicada del CSIC.
Con cargo a los mismos proyectos y contratos se ha asistido y participado en
congresos nacionales e internacionales relacionados con el trabajo de la investigación,
donde se han publicado resultados parciales de esta memoria. Se ha hecho uso de
las instalaciones, de los equipos informáticos y de los programas de computación
de que dispone el Instituto de Física Aplicada. En particular, la mayor parte del
trabajo se ha desarrollado bajo el sistema operativo Windows XP, con programas
de edición de textos basados en LATEX y con entornos de programación para trabajar
en el lenguaje Java.
Introducción 13
Clasificación
El tema principal de la presente Tesis Doctoral, según la MSC (Mathematics
Subject Classification) 2010 de la AMS (American Mathematical Society) [13] es:
94A60 Cryptography
De acuerdo a la misma clasificación, a continuación se enumeran los identifica-

dores de los restantes temas asociados a esta Tesis, junto con la descripción propor-
cionada por la AMS.
03D15 Complexity of computation

11A05 Multiplicative structure; Euclidean algorithm; greatest common
divisors
11A07 Congruences; primitive roots; residue systems
11A25 Arithmetic functions; related numbers; inversion formulas
11A41 Primes
11A51 Factorization; primality
11G05 Elliptic curves over global fields
11G20 Curves over finite and local fields
11N05 Distribution of primes
11N32 Primes represented by polynomials; other multiplicative structure
of polynomial values
11T71 Algebraic coding theory; cryptography
11Y05 Factorization
11Y11 Primality
11Y16 Algorithms; complexity
12E20 Finite fields
14G05 Rational points
14G15 Finite ground fields
14G50 Applications to coding theory and cryptography
14H45 Special curves and curves of low genus
14H50 Plane and space curves
14H52 Elliptic curves
62B10 Information-theoretic topics
68P25 Data encryption
94A05 Communication theory
94A15 Information theory, general
94A62 Authentication and secret sharing
14 Introducción
Estructura
La memoria de esta Tesis Doctoral se ha dividido en ocho capítulos, al margen

de la presente introducción. En los siguientes párrafos se resume el contenido de
cada uno de los capítulos.
El Capítulo 1 presenta las características más destacadas de las tarjetas inteli-
gentes, incluyendo su historia y las circunstancias que motivaron su aparición, los
diversos tipos de tarjetas inteligentes, sus propiedades físicas, los principales están-
dares relacionados, los sistemas operativos en los que un desarrollador puede crear
aplicaciones para tarjetas y, por último, las diferentes arquitecturas software de ac-
ceso a las tarjetas así como los mecanismos de comunicación desarrollados para tal
fin.
En el Capítulo 2 se exponen las principales características de la criptografía de
clave pública y de la basada en curvas elípticas, comenzando por la presentación
de conceptos y definiciones de los algoritmos criptográficos de clave pública más
extendidos hasta la fecha. A continuación, se describen las ecuaciones generales
que definen las curvas elípticas, la particularización de la teoría de curvas elípticas
para cuerpos finitos, las aplicaciones más importantes de las curvas elípticas en
criptografía y los estándares relacionados con cada una de estas aplicaciones. Este
capítulo concluye con un resumen de las principales patentes existentes en ECC.
El Capítulo 3 tiene como objetivo presentar las capacidades criptográficas del
lenguaje Java, en concreto las disponibles en las ediciones Java Standard Edition
y Java Card, para lo cual se ofrece una introducción a la programación orientada
a objetos y al lenguaje Java en general, junto con un resumen de las principales
bibliotecas criptográficas desarrolladas con este lenguaje de programación. En el
apartado que hace referencia a Java Card, se ha incluido una descripción detallada
de las características generales de este sistema operativo y de las peculiaridades de
su modelo de programación.
En el Capítulo 4 se describen de forma completa las distintas variantes de ECIES
incluidas en los estándares ANSI X9.63, IEEE 1363a, ISO/IEC 18033-2 y SECG
SEC 1, identificando las principales diferencias existentes entre los cuatro estándares
mencionados. De forma adicional, se incluye un análisis de la seguridad de ECIES
que recoge las indicaciones y recomendaciones sugeridas en los estudios más recientes
sobre este tema.
El Capítulo 5 presenta las decisiones de diseño tomadas con el objetivo de desa-
rrollar la implementación de ECIES en plataformas PC, así como el diagrama de las
clases Java que componen el desarrollo software. El resto del Capítulo 5 se encuentra
dedicado a la descripción funcional completa de esta versión de la aplicación ECIES,
finalizando con un ejemplo de cifrado y descifrado que ilustra las posibilidades de
utilización de la aplicación.
Introducción 15
En el Capítulo 6 se presenta una implementación del esquema de cifrado ECIES

para tarjetas Java Card, indicando las particularidades existentes en función de la
versión Java Card implementada por las tarjetas inteligentes utilizadas en esta Tesis.
De manera adicional, este capítulo incluye la descripción funcional de la aplicación
desarrollada para la comunicación con las tarjetas inteligentes comerciales empleadas
en la Tesis.
El Capítulo 7 recoge las pruebas realizadas con las implementaciones de ECIES
para PC y Java Card, utilizando diferentes combinaciones de parámetros y algorit-
mos en función de las posibilidades criptográficas de cada una de las plataformas
seleccionadas. A fin de analizar los resultados de las pruebas, se ha incluido una
descripción detallada de las características de las tarjetas inteligentes empleadas en
dichas pruebas.
Por último, el Capítulo 8 presenta las conclusiones derivadas del estudio e imple-
mentación del esquema de cifrado ECIES y de los resultados obtenidos mediante las
pruebas con las versiones desarrolladas para PC y Java Card. De manera adicional,
se describen las aportaciones realizadas por esta Tesis, tanto en forma de artículos
y presentaciones en congresos como de soluciones ideadas para evitar las distintas
limitaciones detectadas. Por último, se incluyen las posibles líneas de trabajo que
podrían seguirse como continuación de esta Tesis.
Notas de estilo
La presente Tesis Doctoral ha sido redactada utilizando el sistema de composi-
ción de textos LATEX, empleando para ello la distribución MiKTeX 2.8 y el programa
de edición WinEdt 5.5. Respecto a la configuración y las decisiones de estilo en LATEX,
se han consultado numerosas fuentes, aunque las principales han sido [153] para los
aspectos generales de composición, y [203] para las características tipográficas aso-
ciadas a la notación matemática.
En la elaboración de la bibliografía, se han seguido principalmente los consejos
sugeridos para la redacción de tesis doctorales de la Universidad Politécnica de
Madrid [263], que se basan principalmente en las normas ISO 690 [110] y 690-2
[111] (sustituidas en 2010 por una nueva edición de ISO 690 [112]), así como en
el documento equivalente UNE 50-104-94 de AENOR [12]. Para algunos aspectos
puntuales se han consultado las recomendaciones de Juan Antonio Pérez Ortiz [217]
(que a su vez recoge algunas de las indicaciones de Ramón Sol [251]).
El objetivo ha sido componer una bibliografía adaptada en lo posible al están-
dar ISO y que permitiera una correcta legibilidad. Algunas de las características
principales del estilo utilizado son:
∙ Escritura del nombre de los autores incluyendo en primer lugar el apellido (o

16 Introducción
apellidos) en mayúscula y posteriormente la inicial (o iniciales) del nombre.

En el caso de empresas o instituciones, se ha intentado mantener el mismo
formato mediante la inclusión del nombre completo en mayúsculas.
∙ Separación de los nombres de los autores mediante el carácter punto y coma.
∙ En el caso de existencia de cuatro o más autores, inclusión únicamente del

primer autor junto al término «et al.» que indica la existencia de autores
adicionales.
∙ Utilización de letras mayúsculas en los títulos de las obras únicamente en la

primera letra y en los casos necesarios, como por ejemplo los nombres propios
(p. ej. Diffie-Hellman), los acrónimos (p. ej. RSA) o los nombres de algoritmos
o funciones que normalmente se redacten en mayúscula (p. ej., Triple Data
Encryption o Elliptic Curve Cryptography).
∙ Utilización del nombre de ciudades en su variante castellana en caso de existir

(p. ej., Londres o Nueva York).
∙ Utilización de las abreviaturas habituales en la descripción de las característi-

cas de las publicaciones periódicas (vol., num., pp., etc.).
∙ Inclusión de la versión del documento en el caso de estándares o de documentos

electrónicos, empleando el término ver. como abreviatura.
∙ Utilización del término inédito para los documentos electrónicos elaborados

por su autor que no hayan sido presentados a congresos o incluidos en libros
o revistas especializadas.
∙ Empleo del nombre oficial de las publicaciones periódicas sin abreviar.
∙ En el caso de las páginas web, inclusión del nombre de la compañía, organismo

o individuo responsable del contenido, así como del título de la página.
∙ Inclusión del código asociado al estándar en las normas nacionales e interna-

cionales.
∙ En las patentes, inclusión de los inventores tras el nombre de la empresa (o

individuo) responsable y del título de la patente. Utilización de las fechas de
solicitud y confirmación de la patente, así como del código identificador de la
patente y del país donde ha sido aprobada.
∙ Inclusión del enlace al documento citado en los casos en los que exista una copia
en formato electrónico en internet, utilizando de manera preferente enlaces
compatibles con el sistema DOI (Document Object Identifier). La validez de
los enlaces fue comprobada por última vez el 5 de noviembre de 2010.
Introducción 17
A lo largo del texto, se interpretarán los siguientes términos como se indica a

continuación [80]:
∙ Algoritmo: procedimiento que toma una serie de datos de entrada y genera

como resultado un valor o conjunto de valores asociados a los datos de entrada.
∙ Criptograma: cadena binaria que contiene el mensaje cifrado y que es enviado

al receptor por el usuario emisor. Tomado en sentido amplio, el criptograma
incluye, además del mensaje cifrado, los elementos adicionales que posibiliten
la recuperación del mensaje original (códigos de autenticación, claves públicas,
etc.).
∙ Protocolo: algoritmo en el que de forma general intervienen distintos usuarios

o entidades, y que se encuentra definido mediante una secuencia de pasos que
especifican las acciones que deben ser completadas a fin de lograr el objetivo
final.
∙ Usuario: persona o elemento inanimado (por ejemplo, un ordenador) que envía,

recibe o manipula información.
Tanto la notación como los términos del glosario incluidos en esta Tesis han sido
obtenidos a partir de las obras incluidas en la bibliografía.
Capítulo 1
Tarjetas inteligentes
Resumen del capítulo

Este capítulo presenta las características más destacadas de las tarjetas
inteligentes, incluyendo su historia y las circunstancias que motivaron
su aparición, los diversos tipos de tarjetas inteligentes, sus propiedades
físicas, los principales estándares relacionados, los sistemas operativos
en los que un desarrollador puede crear aplicaciones para tarjetas y, por
último, las diferentes arquitecturas software de acceso a las tarjetas así
como los mecanismos de comunicación desarrollados para tal fin.
1.1. Historia de las tarjetas inteligentes

Las tarjetas de plástico se empezaron a utilizar como método de identificación en
Estados Unidos a partir de los años 50. La primera de estas tarjetas (Figura 1.1) fue
utilizada por Diners Club [62], y permitía al portador de la tarjeta utilizarla para
realizar pagos en un selecto grupo de restaurantes y hoteles que destacaban por
su exclusividad. Poco después, Visa y MasterCard comenzaron a emitir igualmente
tarjetas de plástico, lo que extendió su uso no sólo por Estados Unidos sino también
en Europa y a continuación por el resto del mundo.
Al principio, los mecanismos de seguridad implementados en estas tarjetas de
plástico eran bastante simples (impresiones gráficas, firma del cliente, etc.), por
lo que con el paso del tiempo fue necesario mejorar su nivel de seguridad. Esta
necesidad, junto con la reducción de costes en el proceso de generación de las tarjetas,
introdujo el uso de la banda magnética (Figura 1.2). Esta banda permitía grabar
19
20 1. Tarjetas inteligentes
Figura 1.1: Diners Club, la primera tarjeta de crédito del mundo
datos que pudieran ser leídos por los lectores apropiados, lo que inicialmente estaba
al alcance únicamente de los usuarios legítimos del sistema. Sin embargo, con el paso
del tiempo la capacidad de leer y modificar el contenido de la banda magnética se
hizo accesible a colectivos al margen de la ley, lo que provocó una nueva evolución en
las medidas de seguridad. Esta evolución tuvo lugar en los años 70 con la introducción
de los microprocesadores para tarjetas.
Figura 1.2: Tarjeta con banda magnética
La idea de incorporar un circuito integrado a una tarjeta de plástico fue pro-

puesta de forma independiente por Jürgen Dethloff y Helmut Grötrupp en 1968 en
Alemania [59, 60] y por Kunitaka Arimura en 1970 en Japón (ver [223]), pero no
fue hasta que Roland Moreno registró sus patentes a partir de 1975 [248, 249, 250]
cuando comenzó su verdadero desarrollo. A mediados de los años 80 se empezaron
a utilizar tarjetas inteligentes en cabinas telefónicas, y las pruebas de integración en
telefonía móvil permitieron que, en 1991, se eligiera la tarjeta inteligente como el
elemento fundamental de la seguridad del sistema GSM (Global System for Mobile
Communications). De forma paralela, se comenzaron a utilizar tarjetas bancarias
con chip integrado tanto en Francia como Alemania a partir de mediados de los
años 80. El éxito de esta iniciativa fue tal, que en menos de 10 años todos los bancos
franceses sustituyeron sus tarjetas con banda magnética por tarjetas inteligentes.
Gracias a sus prestaciones y a su alto nivel de seguridad, el uso de las tarjetas
inteligentes ha proliferado con gran éxito en los últimos años. Entre los entornos de
utilización actuales más destacados pueden citarse los siguientes:
1.1. Historia de las tarjetas inteligentes 21
∙ Tarjetas de identificación de ciudadanos (por ejemplo, DNIe de España a partir

de 2006 [176], Figura 1.3).
Figura 1.3: Prototipo de D.N.I. electrónico de España
∙ Sistema de telefonía móvil digital GSM y UMTS (Universal Mobile Telecom-

munication System), donde toma el papel de módulo de identificación del
usuario con las denominaciones SIM (Subscriber Identity Module) y UICC
(Universal Integrated Circuit Card), respectivamente (Figura 1.4).
Figura 1.4: Tarjeta SIM de Telefónica movistar
∙ Aplicaciones bancarias como el monedero electrónico, de manera que la tarjeta

puede llegar a contener valor monetario en sí misma (por ejemplo, Dinamarca
desde 1992 [74], Figura 1.5).
Figura 1.5: Tarjeta monedero Danmont de la serie emitida en 1994

∙ Sanidad, donde funciona como un archivo de los aspectos más relevantes del
historial médico de un paciente, realizando la identificación del mismo ante los
sistemas centrales del sistema de sanidad (por ejemplo, Alemania desde 2006
[246], Figura 1.6).
Figura 1.6: Ejemplo de tarjeta de salud de la República Federal Alemana
∙ Control de acceso a edificios, con sistemas avanzados que pueden llegar a incluir
elementos biométricos. En ellos, la tarjeta inteligente almacena todos los datos
necesarios para autenticar a una determinada persona (por ejemplo, los datos
de la huella digitalizada, como se muestra en la Figura 1.7).
Figura 1.7: Control de acceso con tarjeta inteligente sin contactos
1.2. ¿Qué es una tarjeta inteligente?

Una tarjeta inteligente es una tarjeta de plástico, en general de tamaño 85.60
× 53.98 mm2 , que contiene como elemento diferenciador (tal como se muestra en la
Figura 1.8) un componente electrónico denominado chip que controla el acceso a los
datos almacenados en él.
Tal como puede apreciarse en la Figura 1.9, el chip consta básicamente de una
memoria ROM (Read Only Memory) donde se almacena el sistema operativo de
la tarjeta, una memoria RAM (Random Access Memory) para guardar los datos
1.2. ¿Qué es una tarjeta inteligente? 23
Figura 1.8: Aspecto externo de una tarjeta inteligente
volátiles utilizados durante una determinada sesión de trabajo, una memoria no

volátil normalmente de tipo EEPROM (Electrically Erasable and Programable Read
Only Memory) donde se almacenan los datos relativos a las aplicaciones instaladas
en la tarjeta, un procesador que ejecuta las instrucciones de acuerdo al sistema
operativo, buses internos para la comunicación de todos los elementos mencionados
y buses externos para la comunicación de la tarjeta inteligente con el dispositivo
lector a través de los contactos [65].
Figura 1.9: Diagrama de bloques de una tarjeta inteligente
Los datos almacenados en la memoria EEPROM sólo son accesibles a través

de los comandos implementados por el sistema operativo, el cual controla que el
usuario que intenta acceder tenga los permisos necesarios para hacerlo. Gracias a
este control de la ejecución de cada comando, es posible garantizar niveles elevados
de protección de los datos frente a ataques externos. Otros tipos de memoria no
volátil menos utilizados son Flash EEPROM, EPROM (Erasable Programmable
Read Only Memory) o FRAM (Ferroelectric Random-Access Memory).
Por otra parte, el chip que incluyen las tarjetas inteligentes se encapsula de tal
forma que quede igualmente protegido contra accesos mediante técnicas electromag-
néticas que no precisen contacto físico con la tarjeta. La tecnología de fabricación
de estos chips ha ido evolucionando con el paso del tiempo, pasando por tecnologías
CMOS (Complementary Metal-Oxide Semiconductor) de 0.8 𝜇m, 0.5 𝜇m, 0.35 𝜇m y
0.13 𝜇m actualmente, lo que permite conseguir una mayor densidad de memoria en
el espacio destinado al chip. A este respecto, la cantidad en micras de la tecnología
de fabricación hace referencia a la mínima resolución de la maquinaria responsable
de integrar sus circuitos mediante técnicas de litografía, ya que la correspondencia
entre tecnología de integración y distancia de integración dejó de verificarse a partir
de la tecnología de 0.25 𝜇m [261]. En cuanto a la arquitectura de los microprocesa-
dores, ésta puede variar desde los 8 bits en las tarjetas más básicas hasta los 32 bits
utilizados para las aplicaciones más complejas.
Para la fabricación de las tarjetas inteligentes se parte de una oblea de silicio que
contiene múltiples ejemplares del chip. Una vez identificados y aislados uno a uno los
chips de la oblea, se pegan y se sueldan sobre los contactos. Se añade entonces una
resina protectora que aísla al chip de la humedad, formando el elemento denominado
“micromódulo”.
El plástico, fabricado de forma independiente, es rebajado en la posición donde
se alojará el chip, de forma que dé cabida al mismo bajo los contactos sin dañarse.
Utilizando técnicas de pegado mediante combinación de calor y presión, el micro-
módulo se coloca en el hueco formado en el plástico, quedando por tanto el chip
totalmente encapsulado bajo los contactos, de acuerdo a la Figura 1.10.
Figura 1.10: Encapsulado del chip bajo los contactos

1.3. Tipos de tarjetas inteligentes 25
1.3. Tipos de tarjetas inteligentes
1.3.1. Tarjetas de memoria
Las primeras tarjetas inteligentes producidas en grandes cantidades fueron las

tarjetas de memoria, aunque podría considerarse que estas tarjetas no son plena-
mente “inteligentes”, puesto que no incluyen un microprocesador, sino que suelen
presentarse únicamente con un chip de memoria o bien con un chip de memoria y
una lógica no programable.
Las tarjetas de memoria suelen contener de 1 a 4 KBytes de información. Se
utilizan principalmente en cabinas telefónicas y para la compra de bienes y servicios
de pequeño valor que normalmente se adquieren mediante operaciones prepago.
Puesto que estas tarjetas no incluyen una CPU (Central Processing Unit) para
procesar los datos, este procesamiento se realiza mediante un sencillo circuito capaz
de ejecutar unas pocas instrucciones programadas con anterioridad. Estos circuitos
tienen un uso muy limitado y no pueden volver a ser programados, por lo que una vez
que se ha utilizado una de estas tarjetas de memoria, y por lo tanto se ha consumido
su crédito, ya no se podrá volver a utilizar.
1.3.2. Tarjetas con microprocesador
En comparación con las tarjetas de memoria, las tarjetas con microprocesador

permiten establecer una mayor diferenciación según algunas de sus características.
Por ejemplo, dependiendo de si existe contacto físico entre la tarjeta y el lector, se
puede distinguir entre tarjetas con y sin contactos. Asimismo, si la tarjeta incorpora
un coprocesador matemático para ayudar en el cálculo de operaciones criptográficas,
nos estaremos refiriendo a tarjetas con coprocesador matemático en comparación con
las tarjetas más habituales que no incorporan este coprocesador.
1.3.2.1. Tarjetas con contactos
Las tarjetas con contactos representan el tipo de tarjeta más extendido en la

actualidad, gracias sobre todo a su presencia en los teléfonos móviles GSM y UMTS,
y se encuentran definidas en las normas ISO/IEC 7816 (ver §1.5.1). Para que una
tarjeta con contactos funcione correctamente, debe ser introducida en un lector de
manera que exista contacto físico entre la tarjeta y el lector. Aunque los estándares
definen ocho contactos, dependiendo del entorno en que se vaya a utilizar la tarjeta
inteligente es posible que no se empleen todos. Por ejemplo, las tarjetas SIM/UICC
actuales utilizan únicamente cinco de los ocho contactos disponibles, aunque existen
planes para la utilización de los tres contactos restantes.
En la Figura 1.11 se pueden observar de forma gráfica los diferentes contactos de

una tarjeta inteligente tal como se encuentran estandarizados en la norma ISO/IEC
7816-2 [114].
Figura 1.11: Contactos de una tarjeta inteligente
La función de cada contacto es la siguiente:
∙ Vcc: proporciona alimentación al chip. Los voltajes admisibles son 1.8 V, 3 V

ó 5 V, con una desviación máxima del 10 %.
∙ RST: este contacto se utiliza para resetear el microprocesador, procedimiento

denominado warm reset. En comparación, el procedimiento cold reset consiste
en detener la alimentación del chip para reanudarla posteriormente.
∙ CLK: puesto que las tarjetas inteligentes no poseen un generador interno de

la señal de reloj, necesitan recibir a través de este contacto la señal externa de
reloj.
∙ GND: este contacto se utiliza para el voltaje de referencia (valor de cero vol-
tios).
∙ Vpp: el contacto Vpp es opcional y sólo se utiliza para programar la memoria

EEPROM en tarjetas antiguas.
∙ I/O: este contacto permite la transmisión de datos entre la tarjeta y el lector

en modo half-duplex, de manera que la información sólo puede ser transmitida
en un sentido en cada momento.
Actualmente se encuentra en proceso de estandarización el futuro uso de los

contactos Vpp y RFU para la implementación del protocolo USB (Universal Serial
Bus) de alta velocidad entre el lector y la tarjeta, para lo que se necesitan dos
contactos, así como para la comunicación entre la tarjeta y la antena externa que
permita su uso en entornos contactless.
1.3. Tipos de tarjetas inteligentes 27
1.3.2.2. Tarjetas sin contactos
En comparación con las tarjetas del apartado anterior, las tarjetas sin contactos
no necesitan contacto físico con otro elemento, ya que se comunican con el lector
mediante ondas electromagnéticas de manera similar a la utilizada en la tecnología
RFID (Radio Frequency Identification) [40]. La distancia entre la tarjeta y el lector
depende del tipo de tarjeta, pero en general varía desde unos pocos centímetros
hasta un metro.
La Figura 1.12 muestra el diagrama de una tarjeta sin contactos, así como del
lector necesario para acceder a la información de la tarjeta.
Figura 1.12: Esquema de una tarjeta inteligente sin contactos
El estándar de tarjetas sin contacto más extendido es el ISO/IEC 14443 (ver

§1.5.2), el cual emplea técnicas de acoplamiento magnético con una frecuencia de
13.56 MHz y tiene un alcance de hasta 10 cm. Si a una tarjeta de este tipo se le
añaden los contactos como vía complementaria de comunicación, entonces se trata
de una tarjeta de interfaz dual.
La principal aplicación de las tarjetas contactless son el pago de pequeñas canti-
dades (tarjetas monedero) y el control de acceso (edificios, transporte público, etc.),
donde la rapidez y el carácter local de las transacciones son las características prin-
cipales. De manera más general, sin el requisito de adoptar la forma de una tarjeta
inteligente, la tecnología sin contactos puede encontrarse en multitud de herramien-
tas de logística y seguridad, como por ejemplo los nuevos pasaportes. De hecho,
desde agosto de 2006 todos los pasaportes españoles que se expiden corresponden al
denominado pasaporte electrónico (pasaporte-e), el cual incorpora un chip embebido

en su portada posterior que incluye información sobre su titular [177].
1.3.3. Tarjetas con coprocesador
Las tarjetas inteligentes utilizadas en entornos de seguridad normalmente in-

cluyen un coprocesador de apoyo al procesador principal. Los coprocesadores son
circuitos integrados especializados en los cálculos de aritmética modular y la gestión
de enteros de gran tamaño, lo que permite liberar de este trabajo al procesador
principal. El uso de coprocesadores permite que ciertas operaciones criptográficas,
que en otras tarjetas tardarían varios minutos en realizarse, puedan ser completadas
en pocos segundos.
La inclusión de coprocesadores aumenta el precio final de las tarjetas inteligen-
tes, motivo por el cual en algunos entornos (como el de las telecomunicaciones) su
presencia sea actualmente minoritaria.
1.4. Propiedades físicas y eléctricas

Las principales características físicas de las tarjetas inteligentes son su tamaño
y composición. En la actualidad existen tres formatos estandarizados por ISO/IEC
en la normas 7816-1 [113] y 7816-2 [114], denominados ID-1, ID-00 e ID-000 (este
último identificable como plug-in o mini-SIM en la terminología de ETSI y 3GPP), y
un formato adicional utilizado en telefonía móvil y definido por ETSI en el estándar
TS 102 221 [75], denominado Mini-UICC, micro-SIM o 3FF (3rd Form Factor).
El formato ID-1 fue el primero en surgir, y es fácilmente reconocible debido a
que coincide con el formato de las tarjetas de crédito. En la Figura 1.13 se pueden
apreciar sus dimensiones en cuanto a longitud, altura y grosor.
Por su parte, las tarjetas de tipo ID-00 presentan un tamaño intermedio, tal
como se puede apreciar en la Figura 1.14. Este formato es el menos utilizado de los
cuatro.
El formato ID-000 representa el tipo de tarjeta inteligente utilizado tradicional-
mente en el interior de los teléfonos móviles. La Figura 1.15 incluye sus dimensiones
estandarizadas.
Por último, el formato Micro-UICC (Figura 1.16) es el más pequeño de los cuatro,
y está especialmente diseñado para nuevos dispositivos que deseen liberar espacio
físico para otros componentes, como por ejemplo el iPad Wi-Fi + 3G o el iPhone 4,
ambos de Apple [21].
En cuanto a su composición, existen varias alternativas en función del plástico
1.4. Propiedades físicas y eléctricas 29
Figura 1.13: Formato de tarjeta ID-1
Figura 1.14: Formato de tarjeta ID-00
Figura 1.15: Formato de tarjeta ID-000 (alternativamente plug-in o mini-SIM)

Figura 1.16: Formato de tarjeta Mini-UICC (alternativamente 3FF o micro-SIM)
empleado:
∙ PVC (Policloruro de Vinilo): se presenta como un material blanco que co-

mienza a reblandecerse alrededor de los 80∘ C y se descompone por encima de
140∘ C.
∙ ABS (Acrilonitrilo Butadieno Estireno): sus cualidades principales son una

baja temperatura de ablandamiento, baja resistencia ambiental e igualmente
baja resistencia a los agentes químicos.
∙ PC (Policarbonato): presenta un rango de uso desde -100∘ C a +135∘ C, con un

punto de fusión cercano a 250∘ C.
∙ PET (Polietileno Tereftalato): se trata de un plástico con un alto grado de

cristalinidad muy utilizado en envases de bebidas y textiles como sustituto del
PVC.
En lo relativo a sus características eléctricas, tal como se ha anticipado anterior-

mente, existen tres voltajes de trabajo estandarizados en ISO/IEC 7816-3 [115]:
∙ Clase A: 5 V ± 10 % (4.5-5.5 V).
∙ Clase B: 3 V ± 10 % (2.7-3.3 V).
∙ Clase C: 1.8 V ± 10 % (1.62-1.98 V).
La Figura 1.17 muestra de manera gráfica tanto el voltaje asociado a cada clase
como la frecuencia de la señal externa de reloj aplicable a las tarjetas con contactos,
y que debe situarse entre 1 y 20 MHz en los tres casos (excepto durante el proceso
de inicio, donde hasta que se establezca la frecuencia de trabajo final, ésta debe-
rá situarse obligatoriamente entre 1 y 5 MHz). Como aclaración, la frecuencia de
1.5. Estándares 31
Figura 1.17: Diagrama de voltajes admisibles
trabajo del procesador no siempre coincide con la frecuenta suministrada por el dis-
positivo lector, ya que las tarjetas pueden implementar divisores o multiplicadores
para ajustar la frecuencia interna [226].
Para más información sobre las características físicas y lógicas de las tarjetas
inteligentes, se recomienda consultar el libro de Rankl y Effing [226].
1.5. Estándares
1.5.1. La norma ISO/IEC 7816

ISO/IEC 7816 es un estándar internacional relacionado con las tarjetas de iden-
tificación electrónicas, en especial las tarjetas inteligentes, creado conjuntamente por
la Organización Internacional de Normalización (ISO) y la Comisión Electrotécnica
Internacional (IEC), y que se encuentra gestionado por el Comité Técnico Conjunto
(JTC) 1/Subcomité (SC) 17 [139].
La norma ISO/IEC 7816, que se desglosa a su vez en varias partes, describe los
parámetros para tarjetas de circuito integrado con contactos y el uso de las mismas.
La norma se ha dividido de tal manera que cada parte recoge un aspecto distinto
de las tarjetas inteligentes. Más específicamente, las partes que componen la norma
son:
∙ Parte 1 [113]: especifica las características físicas de las tarjetas, en cuanto al

tamaño del plástico, su grosor, etc.
∙ Parte 2 [114]: engloba todos los elementos que definen las dimensiones y la lo-
calización de los contactos. Igualmente, especifica la función que debe cumplir

cada uno de estos contactos.
∙ Parte 3 [115]: define las señales eléctricas y los protocolos de transmisión half-
duplex de caracteres(denominado T=0) y bloques (T=1) que se utilizan sobre
la interfaz ofrecida a través de los contactos. Así, todos los voltajes, intensida-
des máximas de corrientes, convenciones de paridad, velocidades de transmi-
sión y otros parámetros relacionados con las señales se definen en esta parte
de la norma.
∙ Parte 4 [116]: especifica los comandos para el intercambio de información en-

tre el exterior y el circuito integrado de la tarjeta. Estos comandos deben ser
respetados por los fabricantes de tarjetas para garantizar el correcto funciona-
miento de tarjetas de diferentes fabricantes. De manera adicional, esta parte
del estándar también define la estructura lógica con la que la memoria se divide
en ficheros y los tipos de datos que pueden ser almacenados en las tarjetas.
∙ Parte 5 [117]: define la estructura de los sistemas de numeración utilizados en

el entorno de las tarjetas inteligentes, así como el procedimiento de registro
para identificadores de aplicación.
∙ Parte 6 [118]: especifica los elementos de datos utilizados (nombre, descripción,

formato, codificación y diseño), así como los medios de recuperación de dichos
elementos.
∙ Parte 7 [119]: dado que la tarjeta inteligente puede utilizarse como dispositivo
de almacenamiento de datos, en esta parte de la norma se especifican los
comandos utilizados para la gestión de las estructuras de bases de datos y el
lenguaje SCQL (Structured Card Query Language).
∙ Parte 8 [120]: los comandos relacionados con la seguridad son definidos en esta
parte de la norma (siendo complementarios a los definidos en la parte 7816-4).
Se incluyen protocolos para que la tarjeta preste servicios de seguridad (como
algoritmos de cifrado) y métodos para proporcionar seguridad en la interfaz
entre la tarjeta y el exterior.
∙ Parte 9 [121]: define los comandos para la gestión de ficheros (por ejemplo,
la creación y borrado de ficheros). Estos comandos abarcan todo el ciclo de
vida de los ficheros en la tarjeta. En un anexo de esta norma se muestra cómo
controlar la carga segura de datos en las tarjetas.
∙ Parte 10 [122]: este documento especifica las señales eléctricas y el ATR (Ans-
wer to Reset) de las tarjetas síncronas.
∙ Parte 11 [123]: especifica el uso de los comandos y de los datos relacionados con
la verificación de la identidad de una persona a través de métodos biométricos.
1.5. Estándares 33
Mientras que los comandos utilizados se definen a su vez en la norma ISO/IEC

7816-4, los datos se definen parcialmente en esta norma y están importados de
la norma ISO/IEC 19785-1 [138].
∙ Parte 12 [124]: define las condiciones de funcionamiento de una tarjeta inte-

ligente través de la interfaz USB. A estas tarjetas se las denomina USB-ICC
(Integrated Circuit Card).
∙ Parte 13 [125]: especifica los comandos para la gestión de aplicaciones en en-

tornos multiaplicación. Estos comandos cubren el ciclo de vida completo de
las aplicaciones en una tarjeta inteligente.
∙ Parte 14: este documento no existe, siendo la parte 14 una referencia sin uso
práctico.
∙ Parte 15 [126]: define una aplicación que contiene información sobre la funcio-
nalidad criptográfica. Además, especifica una sintaxis común en ASN.1 (Abs-
tract Syntax Notation One) y tanto el formato de codificación de la información
como los mecanismos para compartir esta información.
1.5.2. La norma ISO/IEC 14443

El conjunto de especificaciones ISO/IEC 14443 define define dos tipos de tarjetas
sin contactos (Tipo A y Tipo B, ambas operando a 13.56 MHz), cuyas principales
diferencias son el tipo de modulación empleado y los detalles del protocolo de ini-
cialización. Las partes que constituyen esta norma son:
∙ Parte 1 [132]: especifica las características físicas de las tarjetas.
∙ Parte 2 [133]: define los campos magnéticos que deben utilizarse tanto para
proporcionar potencia a la tarjeta como para establecer la comunicación entre
lector y tarjeta.
∙ Parte 3 [134]: especifica el protocolo y los comandos para establecer la comu-

nicación entre un lector y varias tarjetas, incluyendo las técnicas para evitar
colisiones en la transmisión.
∙ Parte 4 [135]: incluye los detalles del protocolo half-duplex de bloques (deno-
minado T=CL) por el que se comunican el lector y la tarjeta sin contactos.
1.5.3. Las normas ETSI y 3GPP

La norma TS 11.11, desarrollada inicialmente por ETSI (European Telecommu-
nications Standards Institute) y transferida posteriormente a la organización 3GPP
(3rd Generation Partnership Project) [1, 6], define la interfaz entre la tarjeta SIM
y el teléfono móvil durante la fase de operación en red del sistema GSM, así como
la organización interna de la información en la tarjeta. Mediante esta especificación,
se asegura la correcta interoperabilidad entre la tarjeta y el terminal, independien-
temente de los fabricantes de ambos dispositivos.
Entre otros detalles, la norma TS 11.11 especifica:
∙ Los requisitos físicos a cumplir por la tarjeta SIM en cuanto a señales eléctricas
y protocolos de transmisión.
∙ El modelo lógico a utilizar como base para el diseño de la estructura de ficheros
de la tarjeta SIM.
∙ Las funciones de seguridad, haciendo hincapié en el proceso de autenticación
del usuario frente a la red.
∙ Los comandos y sus respectivas respuestas a transmitir entre el teléfono móvil
y la tarjeta SIM.
∙ Los contenidos en detalle de los ficheros para su utilización en redes GSM.
Dentro de las características físicas se definen dos formatos, conocidos como ID-1
(tamaño tarjeta de crédito) y plug-in o mini-SIM (formato de inferior tamaño para
poder utilizar la tarjeta dentro de los teléfonos móviles, equivalente al formato ID-
000 del estándar ISO/IEC 7816). En ambos casos, las características físicas deben
cumplir los requisitos expresados en la normas ISO 7816-1 y 7816-2, a menos que se
especifique lo contrario.
A nivel eléctrico se mantienen los requisitos de la norma 7816-3, aunque en este
caso el único protocolo obligatorio es T=0, el protocolo semi-dúplex asíncrono y
orientado a byte [97].
Por último, respecto a la estructura de ficheros, éstos se organizan de forma
jerárquica. Existen tres tipos de ficheros elementales: transparentes (secuencia de
bytes sin organización interna), lineales con longitud de registro fija (secuencia de
registros todos con la misma longitud) y cíclicos con longitud de registro fija (simi-
lares a los lineales, con la diferencia de que los registros se sobrescriben por orden
de antigüedad).
Por su parte, la norma TS 11.14, igualmente desarrollada por ETSI y transferida
a 3GPP [2, 7], define la interfaz entre la tarjeta SIM y el terminal móvil para
la comunicación con aplicaciones SIM Application Toolkit (en adelante STK) y
la realización de servicios avanzados. STK proporciona mecanismos que permiten
a las aplicaciones residentes en la tarjeta SIM interactuar y operar con cualquier
teléfono móvil que implemente dichos mecanismos y sus comandos asociados. Entre
los distintos procedimientos incluidos pueden destacarse los siguientes:
1.6. Sistemas operativos de tarjetas inteligentes 35
∙ Profile Download : mecanismo por el cual el terminal informa a la SIM de

sus características como parte del proceso de inicialización de la SIM, y que
permite a las aplicaciones STK conocer exactamente qué servicios del terminal
podrán utilizar.
∙ Proactive SIM : procedimiento por el cual la tarjeta SIM puede iniciar acciones
que deben ser ejecutadas por el terminal. Este sistema se ideó como una forma
de superar la limitación del protocolo T=0, donde la comunicación sólo puede
ser iniciada por el terminal.
∙ Data Download : mecanismo por el que un servidor puede enviar datos a una
aplicación de la tarjeta SIM, utilizando distintos servicios portadores como
los mensajes cortos SMS (Short Message Service) o la difusión CBS (Cell
Broadcast Service).
La norma TS 11.14, de aplicación en las tarjetas SIM de la telefonía GSM,

evolucionó hasta convertirse en la norma TS 31.111 [5] al aplicarse a las tarjetas
UICC de UMTS. De manera equivalente, la norma TS 11.11, que tuvo su origen en
ETSI para entornos GSM, se dividió en las normas TS 31.101 [3] y TS 31.102 [4] en
su definición para entornos UMTS.
1.5.4. Las normas Global Platform

En relación con sus actividades como uno de los principales emisores de tarjetas
del mundo, Visa International creó la especificación Visa Open Platform, la cual
define una interfaz interna para la gestión de múltiples aplicaciones dentro de una
misma tarjeta inteligente. Desde 1999, este trabajo es gestionado por la organiza-
ción GlobalPlatform, por lo que sus documentos pasaron a denominarse simplemente
“especificaciones Global Platform”. Actualmente existen tres comités dentro de Glo-
balPlatform encargados específicamente de las tarjetas inteligentes, los dispositivos
de lectura y los sistemas de gestión de la información relacionada.
El conjunto de requisitos definidos en los documentos Global Platform son in-
dependientes del sistema operativo de la tarjeta, aunque en la práctica se haya
convertido en el estándar por defecto para la carga y gestión de aplicaciones en tar-
jetas Java Card. La Figura 1.18 muestra la arquitectura básica y los componentes
de Global Platform.
1.6. Sistemas operativos de tarjetas inteligentes

En el mundo de las tarjetas inteligentes existen dos tipos de sistemas operativos:
los cerrados o propietarios y los abiertos. La principal diferencia consiste en que
Figura 1.18: Arquitectura Global Platform
las aplicaciones desarrolladas para tarjetas con sistemas operativos propietarios se

almacenan en código nativo (compilado en el lenguaje máquina del procesador de
destino), mientras que las aplicaciones para tarjetas con sistemas operativos abier-
tos se compilan en un código no nativo que debe ser interpretado por el sistema
operativo.
Los sistemas operativos propietarios ofrecen como ventaja un mayor rendimien-
to en la ejecución de las aplicaciones, pero a cambio una aplicación desarrollada
para tales tarjetas no suele ser interoperable entre distintos fabricantes, algo que sí
que ocurre con las aplicaciones para sistemas operativos abiertos. En los siguientes
apartados se realizará una breve introducción a los principales sistemas operativos
abiertos para tarjetas inteligentes.
1.6.1. Tarjetas Java Card
Puesto que el lenguaje de programación Java es objeto de un estudio detalla-

do en el Capítulo 3, de momento únicamente se mencionará el hecho de que Java
Card es actualmente el sistema operativo abierto de mayor difusión en los princi-
pales entornos comerciales de tarjetas inteligentes [210]. La Figura 1.19 muestra la
arquitectura básica del sistema Java Card.
1.6. Sistemas operativos de tarjetas inteligentes 37
Figura 1.19: Arquitectura Java Card
1.6.2. Tarjetas MULTOS
MULTOS es un sistema operativo multiaplicación controlado por el MULTOS

Consortium (también conocido como MAOSCO), que incluye a fabricantes de chips
y tarjetas inteligentes (Gemalto, Oberthur, Infineon, Samsung, etc.), proveedores de
servicios (Datacard, Thales, etc.) y empresas del sector financiero (Mastercard) por
citar unas pocas [163]. El principal mercado de las tarjetas MULTOS son las tarjetas
bancarias y las emitidas para uso gubernamental.
Las tarjetas MULTOS proporcionan un sistema operativo sobre el que se sitúa
una máquina virtual. Esta máquina virtual proporciona los siguientes elementos: un
entorno de ejecución de aplicaciones, un gestor de memoria y otro gestor para la
carga y borrado de aplicaciones. En la Figura 1.20 se pueden apreciar los detalles
de la arquitectura del sistema MULTOS.
1.6.3. Tarjetas Windows for Smart Cards
En 1998 Microsoft anunció su sistema operativo Windows for Smart Cards

(WSC), que pretendía convertirse en una alternativa a Java Card. Sin embargo,
pocos años después Microsoft canceló el proyecto debido a la escasa acogida que
había tenido este sistema operativo, principalmente debido a que sus competidores
Java Card y MULTOS ya contaban para entonces con una base lo suficientemente
sólida de clientes en sus respectivas industrias.
WSC era un sistema operativo multiaplicación que permitía el desarrollo de
aplicaciones en los lenguajes C y Basic utilizando las herramientas de desarrollo
Figura 1.20: Arquitectura MULTOS
propias de Microsoft.
1.7. Arquitecturas de acceso a las tarjetas inteligen-

tes desde PC
1.7.1. Arquitectura OpenCard Framework

El término OpenCard Framework (OCF) hace referencia a un estándar desarro-
llado por un consorcio industrial (entre cuyos miembros figuraban mayoritariamente
fabricantes de tarjetas inteligentes, ver Figura 1.21) que proporciona una arquitectu-
ra interoperable para la comunicación con dispositivos lectores y tarjetas inteligentes
disponible en varias plataformas software y hardware. Se trata, por tanto, de un es-
tándar abierto que incluye un conjunto de API (Application Programming Interface)
para posibilitar el desarrollo de aplicaciones mediante la programación en el lenguaje
Java.
OCF está diseñado para funcionar en cualquier plataforma Java, como por ejem-
plo ordenadores personales, ATMs (Automated Teller Machine), terminales punto
de venta o set-top boxes. El único requisito que deben cumplir los dispositivos que
utilicen OCF consiste en ser compatibles con la versión Java 1.1.
La arquitectura OCF [100] se compone principalmente de tres elementos:
∙ La capa CardTerminal: proporciona acceso a las tarjetas y a los lectores físicos

para los que los fabricantes han creado los controladores apropiados. También
incluye las API para los terminales PS/SC soportados. Este método garantiza
la compatibilidad con lectores existentes y futuros.
1.7. Arquitecturas de acceso a las tarjetas inteligentes desde PC 39
Figura 1.21: Consorcio OpenCard
∙ La capa CardService: OCF representa las funciones asociadas a las tarjetas

inteligentes a través de card services. Cada servicio define una interfaz de alto
nivel que puede emplearse para acceder a determinadas funciones particulares,
siendo el ejemplo más representativo FileAccessCardService para la gestión
de los ficheros.
∙ El componente ApplicationManagement: se encarga de localizar, seleccionar,

instalar, desinstalar, bloquear y desbloquear aplicaciones almacenadas en una
determinada tarjeta, eliminando el problema de la dependencia del proveedor
de tarjetas.
La Figura 1.22 presenta un esquema que muestra la interrelación entre los dis-
tintos elementos de la arquitectura OCF.
Las interacciones con la tarjeta se realizan mediante el intercambio de pares
de elementos de tipo APDU (Application Protocol Data Unit) iniciadas por una
aplicación externa a la tarjeta, para lo que se emplea un lector de tarjetas. La
aplicación envía un comando CommandAPDU a la tarjeta pasándolo al driver del lector,
quien a su vez lo reenvía a la tarjeta. Como respuesta, la tarjeta envía un comando
ResponseAPDU que el driver entrega a la aplicación.
Las funciones de una tarjeta están determinadas por el conjunto de APDU que
es capaz de interpretar. A pesar de los estándares existentes, el rango de comandos
que entiende cada tarjeta depende en cierta medida del fabricante en cuestión. De
igual manera, cada lector de tarjetas tiene distintas funcionalidades, desde el lector
más simple con un único slot o ranura a los más complejos que incluyen accesorios de
identificación biométrica. El problema de nuevo es la inexistencia de un único driver
Figura 1.22: Elementos de la arquitectura OCF
para acceder a los servicios del lector de tarjetas. Sin embargo, gracias a estándares
como OCF este problema queda parcialmente solucionado, al disponer de un canal
por el que es posible enviar cualquier APDU independientemente del dispositivo
lector y de la tarjeta inteligente empleados (siempre que el lector sea compatible con
la arquitectura OCF).
El OpenCard Consortium se disolvió tras la publicación de su versión 1.2, que-
dando su tecnología obsoleta tras la aparición del API Java Smartcard I/O [211],
aunque todavía puede encontrarse información en forma de proyectos evolucionados
a partir de OCF como Open Smart Card Development Platform (OpenSCDP) [39]
o de repositorios de la información original en Sourceforge [252].
1.7.2. Arquitectura PC/SC
El entorno PC/SC constituye un intento equivalente a OCF para desarrollar

un estándar que permita la interoperabilidad de dispositivos lectores y tarjetas in-
1.8. Comunicación con la tarjeta inteligente 41
teligentes en el entorno PC, habiendo participado en su creación empresas como

Microsoft, Hewlett-Packard, IBM, Sun, Toshiba, etc.
La mayor diferencia entre PC/SC y OCF consiste en que la arquitectura PC/SC
está diseñada para funcionar únicamente sobre sistemas operativos de Microsoft
(Windows 95/98/NT/2000/XP/Vista/7), mientras que OCF funciona sobre cual-
quier sistema donde exista una implementación Java y pueda obtenerse acceso a los
puertos de comunicaciones.
La arquitectura PC/SC queda representada por la Figura 1.23, donde pueden
observarse los diferentes niveles de comunicación entre el PC y el dispositivo lector,
así como entre dicho dispositivo y la tarjeta. Muchos de los niveles mostrados no son
físicos, sino que se trata de niveles software, como la aplicación del PC o los drivers
del lector.
Como detalle interesante, el entorno OCF puede utilizar la arquitectura PC/SC
como un canal adicional para la comunicación con el lector. De esta manera, ade-
más de los lectores de tarjetas compatibles con OCF, las aplicaciones desarrolladas
en plataformas Windows pueden beneficiarse de la utilización de cualquier lector
compatible PC/SC instalado en el sistema.
Otra diferencia entre PC/SC y OCF consiste en que, para que un lector funcione
correctamente en el primer entorno, éste debe estar instalado físicamente antes del
encendido del PC, puesto que Windows detecta durante su arranque los lectores
PC/SC instalados. Por su parte, en OCF es posible conectar un nuevo lector en
cualquier momento, incluso durante la ejecución del programa, gracias a que las
clases necesarias son cargadas por la máquina virtual dinámicamente en el momento
de su utilización.
Para más información se recomienda consultar la página web del PC/SC Work-
group [216].
1.8. Comunicación con la tarjeta inteligente

En las tarjetas Java Card es posible utilizar dos modelos de comunicación dife-
rentes. Por una parte se encuentra el modelo basado en APDU; por otra, el esquema
que emplea la tecnología JCRMI (Java Card Remote Method Invocation), que es
un subconjunto del modelo RMI (Remote Method Invocation) presente en Java.
El modelo de comunicación que se muestra en la Figura 1.24 representa el meca-
nismo más extendido para la comunicación con una tarjeta inteligente. Las APDU,
construidas de acuerdo a las especificaciones ISO/IEC 7816-3 y 7816-4, constituyen
los paquetes de datos que son intercambiados entre la aplicación externa y la tar-
jeta. El sistema operativo de la tarjeta se encarga de analizar las APDU recibidas
y de encaminarlas a la aplicación adecuada a la que van destinadas, recogiendo la
Figura 1.23: Elementos de la arquitectura PC/SC

respuesta de la aplicación para su envío al lector de tarjetas (y con ello, a la aplica-

ción que se comunica con el propio lector, ya sea un programa en un ordenador, el
sistema operativo de un teléfono móvil, etc.).
Figura 1.24: Modelo de comunicación con la tarjeta inteligente
La comunicación entre el lector y la tarjeta se basa normalmente en el protocolo

T=0 (orientado a byte) o T=1 (orientado a bloque). Otros protocolos alternativos
como T=USB o T=RF también pueden ser utilizados, aunque su uso se encuentra
mucho menos extendido.
1.8.1. APDU de tipo comando
La estructura de un comando APDU viene definida por el valor de su primer

byte y tiene el aspecto representado en la Figura 1.25.
Figura 1.25: Esquema de una APDU de tipo comando

Un comando APDU consta de una cabecera y opcionalmente de un cuerpo,

siendo sus elementos los siguientes:
∙ CLA (1 byte): este campo obligatorio identifica la clase de comando. La espe-

cificación ISO/IEC 7816-4 incluye los valores CLA válidos para su utilización,
tal como aparecen en el Cuadro 1.1.
CLA Tipo de instrucción

0x0n, 0x1n Instrucciones estándar 7816-4
0x20 - 0x7F Reservado
0x8n, 0x9n Instrucciones 7816-4 específicas para aplicaciones
0xAn Instrucciones específicas de aplicación o fabricante
0xB0 - 0xCF Instrucciones específicas de aplicación o fabricante
0xD0 - FE Instrucciones específicas de aplicación o fabricante
0xFF Reservado para selección de tipo de protocolo
Cuadro 1.1: Valores del byte CLA permitidos
∙ INS (1 byte): este campo obligatorio sirve para indicar una instrucción especí-
fica dentro de la clase representada por el campo CLA. El estándar ISO/IEC
7816-4 especifica las instrucciones básicas para acceder a los datos de una
tarjeta cuya estructura interna esté implementada de acuerdo al estándar. El
Cuadro 1.2 presenta algunas de las instrucciones ISO/IEC 7816 más típicas.
∙ P1 (1 byte, obligatorio): este campo define el primer parámetro asociado a la
instrucción. Se puede utilizar para dar más información sobre la instrucción,
o bien como dato de entrada.
∙ P2 (1 byte, obligatorio): este campo define el segundo parámetro asociado a
la instrucción. Al igual que en el caso anterior, se puede utilizar para dar más
información sobre la instrucción, o como dato de entrada.
∙ Lc (1 byte, opcional): este valor representa el número de bytes del campo de
datos del comando. Puesto que el valor máximo es 0xFF, la longitud máxima
de los datos es de 255 bytes, aunque algunas tarjetas permiten enviar datos de
256 bytes de longitud utilizando el valor 0x00.
∙ Data (tamaño variable, opcional): este campo incluye los datos del comando.
∙ Le (1 byte, opcional): este campo indica el máximo número de bytes a incluir
en el campo de datos de la respuesta esperada.
Si se utiliza el protocolo T=0, dependiendo de la presencia de datos en el co-

mando, y de si es necesaria una respuesta, existen cuatro variantes del comando
INS Nombre de la instrucción

0E Erase Binary
20 Verify
70 Manage Channel
82 External Authenticate
84 Get Challenge
88 Internal Authenticate
A4 Select File
B0 Read Binary
B2 Read Record
C0 Get Response
C2 Envelope
CA Get Data
D0 Write Binary
D2 Write Record
D6 Update Binary
DA Put Data
DC Update Record
E2 Append Record
Cuadro 1.2: Valores del byte CLA permitidos
APDU, tal como puede comprobarse en la Figura 1.26. De forma habitual, las apli-
caciones utilizan varios comandos APDU con distintas estructuras de datos durante
su ejecución.
Figura 1.26: Posibles estructuras de un comando APDU

1.8.2. APDU de tipo respuesta

El formato de una respuesta APDU es mucho más simple, tal como se muestra
en la Figura 1.27.
Figura 1.27: APDU de tipo respuesta
Al igual que los comandos, las APDU de tipo respuesta incluyen campos tanto
obligatorios como opcionales:
∙ Datos (longitud variable, dependiente del campo Le del comando APDU, ca-
rácter opcional): este campo contiene los datos devueltos por la aplicación de
la tarjeta.
∙ SW1 (1 byte, obligatorio): este campo constituye el primer byte de estado,

que proporciona información general sobre el resultado de la ejecución del
comando.
∙ SW2 (1 byte, obligatorio): este campo constituye el segundo byte de estado,

que proporciona información adicional a la ofrecida por el primer byte de
estado.
Los valores posibles para los bytes de estado están definidos en la especificación
ISO 7816-4. La Figura 1.28 muestra de forma gráfica la clasificación de los posibles
bytes de estado.
Figura 1.28: Posibles códigos de respuesta

Capítulo 2
Criptografía de clave pública basada

en curvas elípticas

En este capítulo se exponen las principales características de la cripto-
grafía de clave pública y de la basada en curvas elípticas, comenzando
por la presentación de conceptos y definiciones de los algoritmos cripto-
gráficos de clave pública más extendidos hasta la fecha. A continuación,
se describen las ecuaciones generales que definen las curvas elípticas, la
particularización de la teoría de curvas elípticas para cuerpos finitos, las
aplicaciones más importantes de las curvas elípticas en criptografía y los
estándares relacionados con cada una de estas aplicaciones. Este capítulo
concluye con un resumen de las principales patentes existentes en ECC.
2.1. Introducción
Criptología es el nombre genérico que engloba dos disciplinas opuestas y a la vez
complementarias: criptografía y criptoanálisis. La criptografía se ocupa del diseño
de procedimientos para el cifrado y descifrado de la información, mientras que el
criptoanálisis se encarga del estudio de los métodos para obtener la información ori-
ginal sin tener acceso a los datos secretos requeridos en el funcionamiento normal de
los algoritmos criptográficos. Ambas disciplinas se han desarrollado habitualmente
de forma paralela, puesto que cualquier método de cifrado siempre lleva aparejada
su correspondiente técnica de criptoanálisis [78].
49
50 2. Criptografía de clave pública basada en curvas elípticas
La criptografía como medio para proteger la información es un arte tan antiguo

como la propia escritura. Hasta el siglo pasado, la única técnica utilizada era la
criptografía de clave simétrica, donde la clave de cifrado coincide con la de descifra-
do, dependiendo la seguridad del sistema del ocultamiento de esta clave a terceras
personas. A pesar de las numerosas ventajas que ofrecen las funciones de cifrado
simétrico, principalmente su eficiencia y robustez, la necesidad de disponer de una
clave para cada par de usuarios representa una gran limitación, siendo un elemento
especialmente crítico en los sistemas informáticos distribuidos. Frente a este proble-
ma, la solución consiste en utilizar criptografía de clave pública o asimétrica, donde
por su naturaleza cada usuario dispone de una clave privada y una clave pública,
de manera que precisamente esta clave pública pueda ser distribuida sin que ello
represente un riesgo para la integridad del sistema.
La finalidad de la criptografía de clave pública es múltiple, y puede definirse
mediante las siguientes características:
∙ Confidencialidad o privacidad: únicamente los usuarios autorizados deben ser

capaces de acceder a la información que se desea proteger.
∙ Integridad: capacidad de verificación de que un mensaje no ha sido alterado

en su transmisión desde el emisor hasta el receptor.
∙ Autenticación: el destinatario de un mensaje debe poder identificar sin ninguna

duda al emisor del mensaje.
∙ No repudio: un emisor no debe ser capaz de negar la autoría de un mensaje.
Desde que en 1976 Diffie y Hellman [61] introdujeron el concepto de criptografía

de clave pública, esta rama de la criptografía ha tenido una vertiginosa evolución,
lo que ha generado la aparición tanto de algoritmos criptográficos como de técnicas
de criptoanálisis de una creciente complejidad. Tal como se adelantó en la Introduc-
ción, los problemas matemáticos utilizados actualmente por los criptosistemas más
extendidos son:
∙ Factorización de enteros (IFP)

Dado un número entero positivo 𝑛, el problema de la factorización de enteros,
denominado IFP (Integer Factorization Problem), consiste en determinar su
factorización en números primos [172]. Es decir, expresar el número 𝑛 de la
𝑚𝑘
forma 𝑛 = 𝑝𝑚 1 𝑚2
1 𝑝2 ⋅ ⋅ ⋅ 𝑝𝑘 , donde los valores 𝑝𝑖 representan números primos
distintos, cada uno con orden de multiplicidad 𝑚𝑖 ≥ 1.
∙ Logaritmo discreto (DLP)

Dado el conjunto ℤ𝑝 de los números enteros módulo un número primo 𝑝, un
generador 𝛼 del grupo multiplicativo ℤ∗𝑝 y un elemento 𝛽 ∈ ℤ∗𝑝 , el problema del
2.2. Aplicaciones de la criptografía de clave pública 51
logaritmo discreto, denominado DLP (Discrete Logarithm Problem), consiste

en encontrar el entero 𝑥 que cumpla la condición 𝛼𝑥 ≡ 𝛽 (mod 𝑝) siendo
0 ≤ 𝑥 ≤ 𝑝 − 2 [172].
∙ Logaritmo discreto en curvas elípticas (ECDLP)

Dada una curva elíptica definida sobre el cuerpo finito 𝔽𝑞 (donde 𝑞 es un
número primo o una potencia de 2), un subgrupo de orden 𝑛 de los puntos de
la curva que sea finito y cíclico, un punto de la curva 𝐺 que sea generador del
subgrupo cíclico y un punto 𝑃 perteneciente a dicho subgrupo, el problema del
logaritmo discreto aplicado a una curva elíptica, denominado ECDLP (Elliptic
Curve Discrete Logarithm Problem), consiste en encontrar el número entero 𝑘
tal que 𝑃 = 𝑘 ⋅ 𝐺 [99].
2.2. Aplicaciones de la criptografía de clave pública

En base a las características de confidencialidad, integridad, autenticación y no
repudio, es posible dividir las aplicaciones prácticas de la criptografía de clave pública
en tres grandes grupos: establecimiento de clave, firma digital y cifrado/descifrado.
⎧

 Establecimiento de clave


⎨
Aplicaciones prácticas Firma digital




Cifrado/descifrado
⎩
2.2.1. Establecimiento de clave

Los esquemas de establecimiento de clave tienen como objetivo que dos o más
entidades que se comunican a través de una red abierta (y posiblemente insegura)
lleguen a compartir una clave secreta con la que pueda proporcionarse confidenciali-
dad e integridad a los datos intercambiados posteriormente [78, 172]. Los esquemas
de establecimiento de clave se pueden dividir a su vez en dos grupos: protocolos
de transporte de clave y de acuerdo de clave. Mientras que en los esquemas de
transporte de clave uno de los usuarios es el encargado de generar la clave secreta
y transmitirla al otro usuario, en los procedimientos de acuerdo de clave los dos
usuarios colaboran activamente proporcionando datos que son imprescindibles para
calcular la clave secreta.
⎧
⎨ Transporte de clave
Establecimiento de clave
Acuerdo de clave
⎩
En la práctica, existen más diferencias entre los esquemas de acuerdo de clave

y los esquemas de transporte de clave. Por ejemplo, en los esquemas de acuerdo
de clave se pueden utilizar pares de claves (pública y privada) de uso temporal,
generadas a propósito para dicha comunicación, mientras que en los esquemas de
transporte de clave, el usuario que inicia la comunicación debe conocer la clave
pública permanente del otro usuario (o al menos, lo suficientemente permanente
para que no haya sido sustituida por una clave pública diferente desde su última
comunicación).
Los esquemas de establecimiento de clave más extendidos en la actualidad son
el Diffie-Hellman [61] y algunas de sus variantes como STS (Station-to-Station) [16]
o ECDH (Elliptic Curve Diffie-Hellman) [147, 174]. En §2.6.8.1 se puede encontrar
más información sobre el protocolo ECDH.
2.2.2. Firma digital
La firma digital tiene como objetivo cumplir los objetivos de integridad, auten-
ticación y no repudio, de manera que una firma electrónica sea equivalente a una
firma manuscrita en cualquier transacción [78, 172]. Desde el punto de vista técnico
y de forma simplificada, una firma digital es el resultado de cifrar la salida obte-
nida mediante una función resumen de una determinada información, de manera
que cualquier usuario pueda verificar la identidad de la persona que firmó los datos
y garantizar que la información objeto de la comprobación no ha sido modificada
desde su firma.
Las firmas digitales pueden dividirse en dos grupos: con anexo y con recuperación
del mensaje. En las firmas con anexo, es necesario disponer tanto de la firma digital
como del mensaje original a fin de poder realizar la comprobación de la firma. Por
el contrario, en las firmas digitales con recuperación del mensaje, el propio mensaje
se extrae del contenido de la firma.
⎧
⎨ Con anexo
Firma digital
Con recuperación del mensaje
⎩
Los principales esquemas de firma digital utilizados actualmente son el basado

en el criptosistema RSA [232] y los algoritmos DSA (Digital Signature Algorithm)
[184] y ECDSA (Elliptic Curve Digital Signature Algorithm) [15, 184]. Se ofrece más
información sobre el algoritmo ECDSA en §2.6.8.2.
2.2. Aplicaciones de la criptografía de clave pública 53
2.2.3. Cifrado/descifrado
Los criptosistemas de clave pública tienen como objetivo cifrar el contenido de la
información a transmitir de manera que ésta sólo pueda ser descifrada por un usua-
rio legítimo. Para ello, de forma genérica dichos usuarios deben seguir el siguiente
procedimiento:
1. Preparación del sistema

Como paso inicial, los usuarios deben acordar qué opciones (tipo de claves,
algoritmos, etc.) van a utilizar a fin de garantizar la confidencialidad de la
comunicación posterior.
2. Comprobaciones previas y obtención de claves

Una vez decididas las claves asimétricas a utilizar, el usuario que enviará el
mensaje cifrado debe conseguir la clave pública del usuario receptor del crip-
tograma, comprobando a continuación la validez de dicha clave.
3. Cifrado
Cada vez que el usuario emisor desee enviar un mensaje cifrado, deberá utilizar
el esquema de cifrado previamente acordado, junto con la clave pública del
usuario receptor, a fin de componer el criptograma.
4. Descifrado
Una vez recibido el criptograma, el usuario receptor utilizará el esquema de
cifrado, junto con su clave privada, para descifrar el mensaje y así obtener la
información original.
En principio, los criptosistemas de clave pública permiten cifrar cualquier tipo

de información. Sin embargo, en la práctica se suelen utilizar para cifrar una clave
simétrica, la cual será posteriormente utilizada para garantizar la confidencialidad
en la comunicación entre los usuarios mediante el uso de un algoritmo de cifrado
simétrico, por ejemplo AES (Advanced Encryption Standard) o TDES (Triple Data
Encryption Standard). Debido a este motivo, se suele afirmar que los esquemas de
transporte de claves son un subconjunto de los esquemas de cifrado, además de
constituir un subconjunto de los esquemas de establecimiento de clave [99].
Los criptosistemas de clave pública más conocidos son RSA [229], ElGamal [69]
y ECIES (Elliptic Curve Integrated Encryption Scheme) [16, 8, 109, 136]. Se ofrece
más información sobre el algoritmo ECIES en §2.6.8.3 y en el Capítulo 4.
En §2.4 se describirán de forma detallada las características técnicas de los es-
quemas de cifrado y establecimiento de clave más conocidos en criptografía de clave
pública, y que constituyen los antecedentes naturales del esquema de cifrado ECIES.
2.3. Seguridad en criptosistemas de clave pública

En el estudio de la seguridad de los criptosistemas, existen dos conceptos que
son fundamentales y que representan las características que sería deseable encontrar
en cualquier criptosistema: la seguridad semántica y la no maleabilidad [25, 27, 224].
Seguridad semántica fue un concepto establecido por Goldwasser y Micali [93] en
1982, y consiste en la incapacidad de un atacante para obtener información alguna
sobre el texto sin cifrar 𝔪 a partir del mensaje cifrado 𝔠 y de la clave pública
de cifrado. Goldwasser y Micali demostraron posteriormente [94] la equivalencia
entre seguridad semántica y la propiedad de un mensaje de ser indistinguible (IND).
Esta propiedad consiste en la incapacidad de un atacante para distinguir pares de
mensajes cifrados entre sí a partir de la correspondiente información sin cifrar. Por
lo tanto, la característica de ser indistinguible está relacionada con el concepto de
privacidad.
Por su parte, el concepto de no maleabilidad (NM) fue presentado por Dolev,
Dwork y Naor [64] en 1991, representando la incapacidad de un atacante de, a
partir de un mensaje cifrado 𝔠, obtener un mensaje cifrado diferente 𝔠′ tal que los
respectivos mensajes en claro estén relacionados. Esta propiedad, tal como está
expresada, está relacionada con la capacidad de un mensaje de ser manipulado.
La resistencia de un criptosistema se puede interpretar en base al tipo de ataques
que es capaz de soportar con éxito. A su vez, los posibles ataques se pueden clasificar
según los métodos empleados y el material al que tenga acceso el atacante. En una
primera clasificación, es posible diferenciar entre ataques pasivos y activos [172]:
∙ Ataques pasivos: un atacante pasivo es aquel que, teniendo acceso al canal por
el que se comunican los usuarios legítimos, se limita a obtener información del
canal, por lo que su objetivo principal es comprometer la confidencialidad de
la comunicación.
∙ Ataques activos: un atacante activo es aquel que, además de recuperar los
criptogramas del canal de comunicación, trata de borrar, introducir o alterar
de alguna forma las transmisiones realizadas por los participantes. El objetivo
de este tipo de atacante es múltiple, ya que además de comprometer la confi-
dencialidad de los mensajes puede intentar alterar la integridad de los datos e
incluso la autenticidad de los mensajes.
Dentro de los ataques pasivos, existen diferentes tipos que se diferencian en el tipo
de información a disposición del atacante [172], de manera que en algunos casos se
podrá suponer que el adversario cuenta con acceso a un oráculo, elemento que puede
ser interpretado como una caja negra que se encarga de cifrar o descifrar mensajes
elegidos por el atacante, pero sin revelar ningún tipo de información adicional. Por
supuesto, estas máquinas ideales no existen en la práctica, pero a efectos de modelar
2.3. Seguridad en criptosistemas de clave pública 55
la seguridad de un criptosistema tienen un papel muy importante en la definición

de los tipos de ataques y en la evaluación de la seguridad de los criptosistemas
[172, 224].
Los principales tipos de ataques pasivos, en función de los recursos al alcance
del atacante [172], son:
∙ Ataque con texto en claro conocido (Known Plaintext Attack o KPA): el ata-
cante dispone de un conjunto de textos cifrados junto con los correspondientes
textos en claro. Su objetivo consiste en determinar la clave de descifrado o,
como mínimo, un algoritmo que le permita obtener el texto en claro de poste-
riores mensajes cifrados.
∙ Ataque con texto en claro elegido (Chosen Plaintext Attack o CPA): el atacante
puede obtener los textos cifrados correspondientes a un conjunto arbitrario
de textos en claro de su propia elección. Para ello, es posible suponer que el
atacante hace uso de un oráculo de cifrado que puede utilizar durante un cierto
tiempo, con la restricción de que en ningún caso el atacante podrá obtener
del oráculo la clave de cifrado. El objetivo del ataque consiste de nuevo en
determinar la clave de descifrado o, en su defecto, un algoritmo que le permita
derivar el texto en claro de otros mensajes cifrados que no hayan sido generados
por el atacante.
∙ Ataque adaptativo de texto en claro elegido (Adaptive Chosen Plaintext Attack

o ACPA): la diferencia con los ataques de texto en claro elegido consiste en que,
en este caso, el atacante puede elegir los textos en claro de los que obtendrá el
texto cifrado correspondiente en base a la información obtenida de los procesos
de cifrado anteriores. El objetivo en este tipo de ataque es igual que en los CPA.
∙ Ataque con sólo texto cifrado (Ciphertext-Only Attack o COA): el atacante

sólo tiene acceso a una colección de textos cifrados, y su objetivo consiste en
obtener los mensajes en claro o, mejor aún, la clave de descifrado.
∙ Ataque con texto cifrado elegido (Chosen Ciphertext Attack o CCA): el atacan-
te puede obtener los textos en claro correspondientes a un conjunto arbitrario
de textos cifrados de su propia elección mediante el uso de un oráculo de desci-
frado. De nuevo, se supone imposible obtener del oráculo la clave de descifrado.
El objetivo último del ataque en este caso consiste en obtener dicha clave de
descifrado.
∙ Ataque adaptativo de texto cifrado elegido (Adaptive Chosen Ciphertext Attack

o ACCA): equivalente al ataque de texto cifrado elegido, con la diferencia de
que el atacante puede elegir los textos cifrados subsiguientes en base a la
información obtenida de los procesos de descifrado anteriores. El objetivo en
este tipo de ataque es igual que en los CCA.
Puesto que tanto el esquema de cifrado como la clave pública de un usuario

legítimo se consideran información pública y conocida, en los criptosistemas de clave
pública siempre será posible desarrollar ataques de tipo CPA en los que el atacante
seleccione el mensaje en claro a fin de obtener el correspondiente mensaje cifrado. De
hecho, en estos criptosistemas no hay diferencia práctica entre los ataques de clase
CPA y ACPA, ya que el atacante puede generar mensajes cifrados a su conveniencia
sin ninguna dificultad.
Es posible reducir aún más el número de tipos de ataques a considerar en crip-
tosistemas de clave pública, ya que CPA y ACPA incluyen los ataques de tipo KPA,
y de igual manera CCA y ACCA (denotados como CCA1 y CCA2 por algunos au-
tores, por ejemplo en [27]) tienen un carácter más amplio que los ataques de clase
COA, puesto que cualquier mensaje cifrado considerado en un ataque de tipo COA
formaría parte del conjunto de mensajes cifrados utilizados en CCA y ACCA, pero
no al contrario.
Por lo tanto, se puede concluir que en criptografía de clave pública los tipos
de ataques diferenciados a considerar son CPA, CCA y ACCA. Relacionando esta
clasificación con los conceptos IND y NM expuestos anteriormente, es posible desa-
rrollar las combinaciones IND-CPA, IND-CCA, IND-ACCA, NM-CPA, NM-CCA y
NM-ACCA [27]. La Figura 2.1 muestra las relaciones existentes entre las seis com-
binaciones, donde las flechas representan implicaciones del tipo 𝐴 ⇒ 𝐵, tal como se
demostró en [27].
Figura 2.1: Modelos de seguridad en criptosistemas de clave pública
Como se puede observar en la Figura 2.1, los conceptos IND-ACCA y NM-

ACCA son equivalentes, siendo los ataques de tipo ACCA los que cuentan con
mayor potencial para comprometer cualquier esquema de cifrado de clave pública.
De manera similar, se puede considerar que los conceptos NM-ACCA y NM-CCA
son equivalentes, así como los conceptos NM-CPA e IND-CCA.
2.4. Principales esquemas de cifrado y establecimien-

to de clave
En los siguientes apartados se presenta un resumen de los principales algoritmos
de cifrado y establecimiento de clave utilizados actualmente, donde 𝑢 y 𝑈 represen-
2.4. Principales esquemas de cifrado y establecimiento de clave 57
tan la clave privada y pública respectivamente del usuario U, el mensaje original sin
cifrar se denotará por la letra 𝔪, la información cifrada será identificada como 𝔠, y
el criptograma 𝒞 incluye no solamente el mensaje cifrado sino también los elementos
adicionales que el receptor del criptograma necesita para proceder a su descifra-
do (aunque en algunas ocasiones, ante la falta de dichos elementos adicionales, el
criptograma 𝒞 será completamente equivalente al mensaje cifrado 𝔠).
2.4.1. Establecimiento de clave Diffie-Hellman
2.4.1.1. Descripción
En su ya clásico documento de 1976, Whitfield Diffie y Martin Hellman [61] pre-

sentaron una manera de resolver las necesidades de seguridad del momento mediante
el novedoso concepto de criptografía de clave pública. El sistema propuesto, cono-
cido desde entonces como protocolo de establecimiento o acuerdo de clave de Diffie-
Hellman, representa un mecanismo por el que dos usuarios intercambian pequeñas
cantidades de información a través de un canal que habitualmente es considerado
inseguro de manera que, al final del procedimiento, únicamente ellos conozcan la
clave secreta compartida [61, 172].
Es importante tener en cuenta que el protocolo de acuerdo de clave Diffie-
Hellman, tal como fue planteado por sus autores, no constituye un criptosistema,
puesto que no lleva a cabo el cifrado y descifrado de información, sino que sólo
permite el intercambio de pequeñas cantidades de información a fin de derivar una
clave secreta. En su propuesta, Diffie y Hellman se limitaron a describir de forma
general los conceptos de firma digital, cifrado asimétrico y establecimiento de clave,
aunque sí incluyeron indicaciones para la implementación del esquema de acuerdo
de clave.
El protocolo Diffie-Hellman, recogido en el Algoritmo 2.1, presenta de manera
ordenada los pasos que los usuarios participantes en el intercambio deben dar a fin
de obtener una clave secreta común con la que poder cifrar toda la comunicación
posterior [148].
Después de llevar a cabo los pasos anteriores, U y V conocen y comparten un
elemento común del grupo ℤ∗𝑝 y que es desconocido para cualquier otro usuario.
Dicho elemento es el siguiente:
(𝛼𝑣 )𝑢 = (𝛼𝑢 )𝑣 = 𝛼𝑢𝑣 ∈ ℤ∗𝑝 .
Si en el Algoritmo 2.1 los valores 𝑢 y 𝑣 son fijos, y en lugar de generar los

elementos 𝛼𝑢 y 𝛼𝑣 en cada transmisión dichos valores son obtenidos de un servidor
de claves, nos encontramos ante una versión del protocolo de intercambio Diffie-
Algoritmo 2.1 Establecimiento de clave Diffie-Hellman

1. Si U y V son los dos usuarios que participan en el protocolo, en primer
lugar deben seleccionar y hacer público un número primo 𝑝 y un generador
𝛼 ∈ ℤ∗𝑝 , donde ℤ∗𝑝 = {𝛼𝑖 : 𝑖 = 1, . . . , 𝑝 − 1} y 1 < 𝛼 < 𝑝 − 1.
2. A continuación U debe generar un número entero aleatorio 𝑢, con 1 < 𝑢 <

𝑝 − 1, calcular 𝛼𝑢 ∈ ℤ∗𝑝 y transmitir este elemento a V.
3. De forma análoga, V tiene que generar un número aleatorio 𝑣, con 1 < 𝑣 <
𝑝 − 1, calcular 𝛼𝑣 ∈ ℤ∗𝑝 y transmitir el elemento calculado a U.
4. Tras recibir 𝛼𝑣 , U debe calcular el valor de (𝛼𝑣 )𝑢 ∈ ℤ∗𝑝 .
5. De manera equivalente, una vez recibido el valor 𝛼𝑢 , V debe proceder a

calcular el valor de (𝛼𝑢 )𝑣 ∈ ℤ∗𝑝 .
Hellman denominada protocolo de intercambio Diffie-Hellman con exponentes fijos,

y que en realidad es la descrita en [61].
2.4.1.2. Ejemplo
A continuación se incluye un sencillo ejemplo del protocolo de establecimiento

de clave Diffie-Hellman:
1. Los usuarios U y V eligen públicamente el número primo 𝑝 = 541 y el grupo

ℤ∗541 , cuyo orden es 𝑛 = 𝑝 − 1 = 540. Además, seleccionan un generador de
dicho grupo, 𝛼 = 51 ∈ ℤ∗541 .
2. A continuación, U genera un número aleatorio 𝑢 = 301 y calcula
𝛼𝑢 (mod 𝑝) = 51301 (mod 541) ≡ 94 (mod 541) ,
transmitiendo el valor 94 a V.
3. Análogamente, V genera un número aleatorio 𝑣 = 197, calcula
𝛼𝑣 (mod 𝑝) = 51197 (mod 541) ≡ 378 (mod 541)
y transmite el valor 378 a U.
4. El usuario U recibe 378 y calcula el valor del elemento
378𝑢 (mod 𝑝) = 378301 (mod 541) ≡ 113 (mod 541) .

5. Por otra parte, V recibe 94 y calcula
94𝑣 (mod 𝑝) = 94197 (mod 541) ≡ 113 (mod 541) .
Al finalizar el protocolo, tanto U como V comparten el dato
𝛼𝑢𝑣 (mod 541) = 51301⋅197 (mod 541) ≡ 113 (mod 541) .
2.4.1.3. Seguridad
Este esquema de establecimiento de clave se basa en el DLP y en lo que se conoce

como el problema Diffie-Hellman (Diffie-Hellman Problem o DHP). Una definición
formal de este problema es la siguiente: dado un grupo 𝐺 finito y cíclico, con gene-
rador 𝛼, y unos elementos 𝛽 = 𝛼𝑥 , 𝛾 = 𝛼𝑦 ∈ 𝐺, el problema consiste en determinar
el elemento del grupo dado por 𝛿 = 𝛼𝑥⋅𝑦 [144].
El DHP es, hoy por hoy, un problema muy difícil de resolver desde el punto de
vista computacional. Resulta claro que si un atacante pudiera resolver el problema
DLP, habría resuelto el DHP. En efecto, si dados los elementos 𝐺, 𝑛, 𝛼 y 𝛼𝑢 , el
atacante es capaz de determinar 𝑢 en tiempo polinómico, podría usar este algoritmo
para calcular 𝑢 o 𝑣 en el caso del problema Diffie-Hellman, y puesto que conocería
los valores 𝛼𝑣 y 𝛼𝑢 obtenidos del canal inseguro, bastaría con determinar el valor del
primero elevado a 𝑢 o el del segundo elevado a 𝑣 para resolver el problema planteado.
En resumen, la conjetura generalmente aceptada es que DHP y DLP son equi-
valentes; es decir, que resolver uno de ellos permite resolver el otro en tiempo poli-
nómico. Por esta razón se suele expresar que la seguridad del esquema de acuerdo
de clave Diffie-Hellman está basada en la seguridad del DLP.
Existen numerosas técnicas de ataque del DLP, recopiladas por ejemplo en [172].
Entre las principales se pueden destacar los métodos baby-step giant-step [241], ro
de Pollard (Pollard’s Rho) [222] o el ataque Pohlig-Hellman [219].
2.4.2. Criptosistema RSA

En 1978, Ron Rivest, Adi Shamir y Leonard Adleman [229] propusieron una
implementación práctica de los conceptos presentados anteriormente por Diffie y
Hellman. Aprovechando la dificultad de factorizar números enteros muy grandes,
describieron los pasos necesarios para cifrar y descifrar mensajes que previamente
hubieran sido convertidos en cadenas numéricas. Su propuesta incluía detalles sobre
cómo realizar las operaciones de cifrado y descifrado de forma eficiente, y cómo
calcular los parámetros que componen las claves públicas y privadas. El esquema
de cifrado, tal como está descrito en [229], es independiente del tipo de mensaje,
estando la información cifrada directamente con la clave pública 𝑉 y no por una
clave simétrica temporal. En 1983 les fue concedida la patente que solicitaron en
1977 [164], aunque en el año 2000 los autores dejaron sin efecto dicha patente para
que el algoritmo RSA pudiera ser utilizado libremente.
El protocolo RSA consta de tres partes [66, 232]:
1. Generación de las claves.
2. Cifrado del mensaje.
3. Descifrado del mensaje.
En los siguientes apartados se describen en detalle las fases mencionadas.
Generación de las claves
Cada usuario (lo que representa tanto al usuario U que desea enviar el mensaje
𝔪 como al usuario V que recibe la información cifrada 𝔠, equivalente en este caso al
criptosistema 𝒞) debe elegir su par de claves, pública y privada. Para ello es necesario
completar los pasos del Algoritmo 2.2, descrito utilizando la notación del usuario V.
Algoritmo 2.2 Generación de claves RSA

1. Elegir dos números primos grandes 𝑝 y 𝑞 distintos pero de, aproximadamen-
te, el mismo tamaño.
2. Calcular los valores 𝑛 = 𝑝 ⋅ 𝑞 y 𝜙(𝑛) = (𝑝 − 1) ⋅ (𝑞 − 1), donde la función

𝜙(𝑛) es el indicador de Euler para el número 𝑛.
3. Elegir de forma aleatoria un entero positivo 𝑒, con 2 < 𝑒 < 𝜙(𝑛), tal que
mcd(𝑒, 𝜙(𝑛)) = 1.
4. Calcular, mediante el algoritmo de Euclides extendido, el único entero que

verifica 1 < 𝑑 < 𝜙(𝑛), de modo que 𝑒 ⋅ 𝑑 ≡ 1 (mod 𝜙(𝑛)).
5. Asignar como clave pública del usuario V el par 𝑉 = (𝑛, 𝑒), siendo su
clave privada correspondiente 𝑣 = 𝑑. Además del elemento 𝑑, también deben
permanecer secretos los números 𝑝, 𝑞 y 𝜙(𝑛).
A los valores 𝑒 y 𝑑 así obtenidos se les denomina exponente de cifrado y exponente

de descifrado, respectivamente. Por su parte, el entero 𝑛 se denomina módulo del
criptosistema RSA.
Cifrado del mensaje
Para enviar un mensaje cifrado a V, el usuario U deberá realizar los pasos

descritos en el Algoritmo 2.3.
Algoritmo 2.3 Cifrado RSA

1. Obtener la clave pública de V, 𝑉 = (𝑛𝑉 , 𝑒𝑉 ), de un directorio público de
claves.
2. Convertir el mensaje original 𝔪 en el número entero 𝑚 perteneciente al

conjunto ℤ∗𝑛𝑉 .
3. Calcular el valor numérico 𝑐 asociado al mensaje cifrado 𝔠 mediante la ex-

presión
𝑐 = 𝑚𝑒𝑉 (mod 𝑛𝑉 ),
siendo enviado este valor a V.
Nótese que el factor de expansión del criptosistema RSA, es decir, el cociente

entre la longitud del criptograma y el mensaje original, es exactamente 1, consi-
derando que tanto el valor numérico del mensaje, 𝑚, como del criptograma, 𝑐, se
codifican en formato binario utilizando ⌈log2 𝑛𝑉 ⌉ bits.
Descifrado del mensaje
Una vez que el usuario V recibe el mensaje cifrado 𝔠, para recuperar el mensaje
original 𝔪 debe seguir las instrucciones del Algoritmo 2.4.
Algoritmo 2.4 Descifrado RSA

1. Obtener la clave privada 𝑣 = 𝑑𝑉 .
2. Calcular el valor
𝑐𝑑𝑉 (mod 𝑛𝑉 ) = (𝑚𝑒𝑉 )𝑑𝑉 (mod 𝑛𝑉 ) = 𝑚𝑒𝑉 𝑑𝑉 (mod 𝑛𝑉 ) = 𝑚,
transformándolo a continuación en el mensaje 𝔪.
2.4.2.2. Ejemplo
A continuación se presenta un sencillo ejemplo de cifrado con RSA donde los

parámetros empleados son pequeños para una mayor claridad del proceso.
Para determinar las claves que utilizará el usuario V, se siguen los pasos expues-
tos en §2.4.2.1:
1. El usuario V debe elegir dos números primos de forma secreta, en este caso
𝑝 = 383 y 𝑞 = 521.
2. El siguiente paso consiste en multiplicar los valores 𝑝 y 𝑞 para obtener el

módulo RSA 𝑛, determinando el indicador de Euler 𝜙(𝑛):
𝑛 = 𝑝 ⋅ 𝑞 = 383 ⋅ 521 = 199543,
𝜙(𝑛) = (𝑝 − 1) (𝑞 − 1) = 382 ⋅ 520 = 198640.
3. A continuación, V debe seleccionar un exponente de cifrado dentro del rango

2 < 𝑒 < 198640, tomando por ejemplo 𝑒 = 3, de manera que
mcd(3, 198640) = 1.
4. Posteriormente, V utilizará el algoritmo de Euclides extendido obteniendo

198640 = 66213 ⋅ 3 + 1, con lo que
−66213 ⋅ 3 ≡ 132427 ⋅ 3 (mod 198640) ≡ 1 (mod 198640) .
Este paso permite a V obtener el valor 𝑑𝑉 = 132427.
5. Tras los pasos anteriores, V podrá dar a conocer su clave pública, 𝑉 =

(𝑛𝑉 , 𝑒𝑉 ) = (199543, 3), manteniendo oculta tanto su clave privada, 𝑣 = 𝑑𝑉 =
132427, así como los valores 𝑝 = 383, 𝑞 = 521 y 𝜙(𝑛) = 198640.
Cifrado del mensaje
Cuando el usuario U desee enviar un mensaje a V, por ejemplo el nombre del

criptosistema, ‘RSA’, deberá seguir los pasos mencionados en §2.4.2.1:
1. U debe localizar y obtener la clave pública de V, 𝑉 = (𝑛𝑉 , 𝑒𝑉 ) = (199543, 3).
2. A continuación, U escribirá el mensaje a enviar como un número menor que

𝑛 = 199543 y primo con él. Para ello, por ejemplo, se puede considerar la
siguiente representación de letras mediante números, donde por simplicidad
no se ha considerado la letra Ñ.
𝐴 7→ 0, 𝐵 7→ 1, 𝑐 7→ 2, . . . , 𝑌 7→ 24, 𝑍 7→ 25.
Este sistema emplea la base 26 para representar cualquier palabra. De este

modo, como se verifica la desigualdad
263 = 17576 < 𝑛 = 199543 < 456976 = 264 ,
cada mensaje parcial puede contener, como máximo, tres letras. En el ejemplo
considerado se utilizarán las letras
𝑅 7→ 17, 𝑆 7→ 18, 𝐴 7→ 0,
con lo que el mensaje es
𝔪 = RSA 7→ 𝑚 = 17 ⋅ 262 + 18 ⋅ 26 + 0 = 11492 + 468 + 0 = 11960.
Antes de proceder al cifrado, U debe comprobar que el máximo común divisor

de 199543 y 11960 es 1, lo que efectivamente ocurre en este caso.
3. A continuación, U cifrará el mensaje anterior mediante el siguiente cálculo:
𝑐 = 𝑚𝑒𝑉 (mod 𝑛𝑉 ) = 119603 (mod 199543) ≡
≡ 1710777536000 (mod 199543) ≡ 15446 (mod 199543).
Este valor podría escribirse en base hexadecimal para ser enviado a su desti-
natario, o transformarlo de nuevo a base 26 para convertirlo en letras. En este
último caso:
𝑐 = 15446 = 22 ⋅ 262 + 22 ⋅ 26 + 2 7→ 𝔠 = WWC.
Una vez que el usuario V reciba el mensaje cifrado enviado por U, 𝔠=WWC,
debe realizar los pasos indicados en §2.4.2.1:
1. Recuperar su clave privada; en este caso 𝑣 = 𝑑𝑉 = 132427.

2. A continuación, debe representar el mensaje cifrado en base 26 como un núme-
ro, obteniendo 𝑐 = 15446. Hecho esto, V descifrará el criptograma mediante
las siguientes operaciones:
𝑚 = 𝑐𝑑𝑉 (mod 𝑛𝑉 ) ≡ 15446132427 (mod 199543) = 11960 (mod 199543) ,
𝑚 = 11960 = 17 ⋅ 262 + 18 ⋅ 26 + 0 7→ 𝔪 = RSA.

2.4.2.3. Seguridad
El criptosistema RSA se basa en dos problemas matemáticos relacionados entre

sí: el IFP y el problema RSA. El problema RSA puede definirse de la siguiente
manera [172]: dado un número entero positivo 𝑛 que sea el producto de dos números
primos distintos 𝑝 y 𝑞, un número entero positivo 𝑒 tal que el máximo común divisor
sea mcd(𝑒, (𝑝−1) (𝑞−1)) = 1 y un número entero 𝑐, el problema consiste en encontrar
el número entero 𝑚 tal que 𝑚𝑒 ≡ 𝑐 (mod 𝑛).
La equivalencia entre resolver el IFP y el problema RSA quedó establecida en
2007, cuando Coron y May [54] demostraron la existencia de un algoritmo determi-
nístico de tiempo polinómico capaz de factorizar el elemento 𝑛, supuesto conocidos
los valores 𝑒 y 𝑑, con 𝑒, 𝑑 < 𝜙(𝑛). De manera adicional, existen variantes del crip-
tosistema RSA para las cuales también ha sido probada tal equivalencia, como por
ejemplo los criptosistemas de Rabin [225], Williams [270] y Kurosawa [156].
Existe un gran número de ataques sobre el algoritmo RSA [35, 264], siendo los
más importantes los siguientes:
∙ Ataques de factorización: consisten en intentar factorizar el módulo 𝑛. Den-

tro de este tipo de técnica podemos citar los métodos de Pollard [220, 221],
Williams [271], Lehman [158] y Shanks [241].
∙ Ataques a exponentes de cifrado pequeños: estos métodos están derivados del

intento de conseguir un proceso de cifrado más eficiente [101, 53].
∙ Ataques a exponentes de descifrado pequeños: los ataques iniciales empleando

esta técnica están descritos en [267] y [31]. Para evitarlos, es recomendable
seguir las recomendaciones de Menezes [172] y Schneier [237] respecto a que el
tamaño del exponente de descifrado debe ser prácticamente igual al tamaño
del módulo RSA, o el trabajo al respecto de Luis Hernández, Jaime Muñoz y
Araceli Queiruga [52].
2.4.3. Criptosistema de El Gamal

En 1985, Taher ElGamal [69] propuso un esquema de firma digital y cifrado que
utilizaba la clave pública de V para cifrar una clave simétrica 𝐾, con la que a su vez
se cifraba el mensaje original. La principal novedad de su propuesta consistía en unir
para su envío tanto la clave simétrica temporal como la información original cifrada
con dicha clave, aprovechando la complejidad del cálculo de los logaritmos sobre
cuerpos finitos. En su propuesta, ElGamal aconsejaba no cifrar más de un mensaje
(o más de un bloque del mensaje original, si por su longitud el mensaje debía ser
dividido en varias partes) con la misma clave 𝐾, por lo que en la práctica una
nueva clave 𝐾 siempre acompañará al mensaje cifrado en cada envío de información
confidencial de U a V.
Como en todo criptosistema de clave pública, en el de ElGamal se pueden iden-
tificar tres fases [179]:
1. Generación de claves.
2. Cifrado de mensajes.
3. Descifrado de mensajes.
Generación de claves
Todo usuario V que desee generar claves para el criptosistema de ElGamal debe
seguir el Algoritmo 2.5.
Algoritmo 2.5 Generación de claves para el criptosistema ElGamal

1. Generar un número primo grande 𝑝 (de alrededor de 300-310 dígitos, es
decir, de aproximadamente 1024 bits).
2. Elegir un generador 𝛼 del grupo multiplicativo ℤ∗𝑝 .
3. Generar un número aleatorio 𝑢, con 2 ≤ 𝑣 ≤ 𝑝 − 2, y calcular el valor de

𝛼𝑣 (mod 𝑝).
4. Asignar como clave pública de V el trío 𝑉 = (𝑝, 𝛼, 𝛼𝑣 ), siendo su clave

privada el número 𝑣. En caso de que todos los usuarios utilicen los mismos
valores 𝑝 y 𝛼, la clave pública del usuario V quedaría reducida al elemento
𝑉 = 𝛼𝑣 .
Cifrado de mensajes
Si el usuario U desea enviar un mensaje 𝔪 cifrado al usuario V, U debe seguir

los pasos indicados en el Algoritmo 2.6.
El factor de expansión del algoritmo de ElGamal es igual a 2, debido a que la
longitud del criptograma es el doble de la longitud del mensaje a cifrar, considerando
que tanto el valor numérico del mensaje, 𝑚, como los elementos 𝑓 y 𝑔, se codifican
en formato binario utilizando ⌈log2 𝑝⌉ bits.
Algoritmo 2.6 Cifrado de mensajes en el criptosistema ElGamal

1. Obtener la clave pública de V, 𝑉 = (𝛼𝑣 ), así como los valores 𝑝 y 𝛼.
2. Representar el mensaje 𝔪 como el valor entero 𝑚 ∈ {0, 1, . . . , 𝑝 − 1}.
3. Generar un número aleatorio 𝑘, 2 ≤ 𝑘 ≤ 𝑝 − 2, y utilizarlo para calcular los

valores
𝑓 = 𝛼𝑘 (mod 𝑝) , 𝑔 = 𝑚 ⋅ (𝛼𝑣 )𝑘 (mod 𝑝) .
4. Enviar el criptograma 𝒞 = (𝔣, 𝔤) a V, donde 𝔣 y 𝔤 representan las codifica-

ciones alfanuméricas de los valores 𝑓 y 𝑔.
Descifrado de mensajes
Una vez que el usuario V recibe el criptograma 𝒞 = (𝑓, 𝑔) enviado por el usuario
U, para obtener el mensaje original, 𝔪, V debe realizar el Algoritmo 2.7:
Algoritmo 2.7 Descifrado de mensajes en el criptosistema ElGamal

1. Utilizar su clave privada, 𝑣, para calcular
ℎ = 𝑓 𝑝−1−𝑣 (mod 𝑝) ≡ 𝑓 −𝑣 (mod 𝑝) ≡ 𝛼−𝑘 𝑣 (mod 𝑝) .
2. Calcular el valor numérico asociado al mensaje original multiplicando por 𝑔

el valor anterior mediante la operación
ℎ ⋅ 𝑔 (mod 𝑝) ≡ 𝛼−𝑘 𝑣 ⋅ 𝑚 ⋅ (𝛼𝑣 )𝑘 (mod 𝑝) ≡ 𝑚,
obteniendo a continuación el mensaje 𝔪 original a partir del valor 𝑚.
2.4.3.2. Ejemplo
A continuación se presenta un sencillo ejemplo de cifrado con el algoritmo de

ElGamal.
Para generar sus claves, el usuario V debe seguir los pasos expuestos en §2.4.3.1:
1. V debe comenzar seleccionando el primo 𝑝 = 15485863 que se utilizará para

crear el conjunto ℤ15485863 y su grupo multiplicativo ℤ∗15485863 .
2. A continuación, V elige como generador el elemento 𝛼 = 7 de ℤ∗15485863 .

3. Posteriormente, V genera el número aleatorio 𝑣 = 21702 que será utilizado
como clave privada, calculando además el valor
𝛼𝑣 (mod 𝑝) = 721702 (mod 15485863) ≡ 8890431 (mod 15485863) .
4. Si los dos usuarios deciden utilizar los mismos valores de 𝑝 y 𝛼, entonces la

clave pública de V será 𝑉 = 8890431.
Cifrado del mensaje
Los pasos a realizar por el usuario U para enviar un mensaje cifrado a V son
los descritos en §2.4.3.1.
1. El primer requisito para U consiste en obtener los datos 𝑝 = 15485863, el

generador 𝛼 = 7 y 𝑉 = 8890431.
2. Supongamos que U quiere enviar a V el mensaje 𝔪=LAURA. Antes de cifrar
el mensaje, es necesario codificarlo de manera equivalente al procedimiento
utilizado en el ejemplo RSA, obteniendo el valor 𝑚 asociado a 𝔪:
𝔪 = LAURA 7→ 𝑚 = 11 ⋅ 264 + 0 ⋅ 263 + 20 ⋅ 262 + 17 ⋅ 26 + 0 = 5040698.
3. Tras representar el mensaje como un número entero, el usuario U genera el

número aleatorio 𝑘 = 480 y calcula el valor
𝑓 = 𝛼𝑘 (mod 𝑝) = 7480 (mod 15485863) ≡ 12001315 (mod 15485863) .
A continuación, realiza los siguientes cálculos:
(𝛼𝑣 )𝑘 (mod 𝑝) ≡ 8890431480 (mod 15485863) = 9846598 (mod 15485863) .
𝑔 = 𝑚 ⋅ (𝛼𝑣 )𝑘 (mod 𝑝) ≡ 2829967 (mod 15485863) .
4. Por último, U debe obtener el equivalente alfanumérico del par (𝛼𝑢 , 𝑚⋅(𝛼𝑣 )𝑢 ) =
(12001315, 2829967), que constituye el criptograma.
12001315 = ((((1 ⋅ 26 + 0) ⋅ 26 + 6) ⋅ 26 + 21) ⋅ 26 + 11) ⋅ 26 + 1

= 1 ⋅ 265 + 0 ⋅ 264 + 6 ⋅ 263 + 21 ⋅ 262 + 11 ⋅ 26 + 1 7→ BAGVLB.
2829967 = (((6 ⋅ 26 + 5) ⋅ 26 + 0) ⋅ 26 + 8) ⋅ 26 + 23
= 6 ⋅ 264 + 5 ⋅ 263 + 8 ⋅ 26 + 23 7→ GFIX.
Por lo tanto, el par de valores a enviar a V es: 𝒞 = (BAGVLB, GFIX).
Para proceder al descifrado, V debe calcular los siguientes elementos, tal como
se encuentra descrito en §2.4.3.1:
1. V debe utilizar su clave privada, 𝑣 = 21702, para realizar los siguiente cálculos,
teniendo en cuenta que 𝑓 = 𝛼𝑘 (mod 𝑝):
𝑓 𝑣 (mod 𝑝) ≡ 1200131521702 (mod 15485863) ≡ 9846598 (mod 15485863) ,
ℎ = 𝛼−𝑘𝑣 ≡ 14823281 (mod 15485863) .
2. A continuación, V obtendrá el valor numérico del mensaje original mediante

el cálculo
𝑚 = ℎ ⋅ 𝑔 = 14823281 ⋅ 2829967 (mod 15485863) ≡ 5040698 (mod 15485863) .
Una vez obtenido 𝑚, V podrá recuperar el texto del mensaje original mediante
la siguiente conversión:
𝑚 = 5040698 = 11 ⋅ 264 + 0 ⋅ 263 + 20 ⋅ 262 + 17 ⋅ 26 + 0 7→ 𝔪 = LAURA.
2.4.3.3. Seguridad
La seguridad de este criptosistema se basa en la dificultad computacional que

supone resolver el DLP [36], del que ya se han realizado algunos comentarios en §2.1
y §2.4.1.3. Por esta razón, se dice que la seguridad del criptosistema de ElGamal es
equivalente a la del logaritmo discreto.
2.5. Esquemas de cifrado híbrido DEM -KEM

Los esquemas de cifrado de clave pública integrados representan modelos híbri-
dos en los cuales se utiliza un sistema de clave pública para transportar una clave
de sesión que será posteriormente utilizada por un algoritmo de cifrado simétrico.
Aunque es cierto que durante los años 90 surgieron algunos esquemas de cifrado que
establecieron las bases de lo que se conoce actualmente como cifrado híbrido [9, 155],
no fue hasta el año 2001 cuando Shoup [243] estableció formalmente los conceptos
en los que se basan este tipo de esquemas [25].
2.5. Esquemas de cifrado híbrido DEM -KEM 69
Debido a la contribución de Shoup, las técnicas más modernas relacionadas con

los esquemas de cifrado híbrido de clave pública dividen el esquema en dos eta-
pas claramente diferenciadas, denominadas KEM (Key Encapsulation Mechanism)
y DEM (Data Encapsulation Mechanism). La popularidad que ha alcanzado recien-
temente la técnica DEM -KEM se basa, en parte, a que la seguridad del esquema
resulta más sencilla de analizar considerando los dos bloques por separado [30].
Los siguientes apartados incluyen la definición formal de las etapas KEM y DEM,
utilizando para ello la notación definida en [243].
2.5.1. Mecanismo de encapsulación de clave KEM

Cualquier mecanismo KEM debe incluir los siguientes elementos:
∙ Un algoritmo de generación de clave KEM.KeyGen(), que produce una clave

pública PK y su correspondiente clave privada SK, formando el par (PK,SK ).
∙ Un algoritmo de cifrado KEM.Encrypt(PK,opt), que toma como entrada una

clave pública PK y un conjunto de opciones denominado opt, y produce el par
(K,C 0 ) formado por la clave K y C 0 , que es la clave K cifrada.
∙ Un algoritmo de descifrado KEM.Decrypt(SK,C 0 ), que toma como entrada

una clave secreta privada SK y la clave cifrada C0 , devolviendo como salida
la clave K.
∙ Un entero positivo, denominado KEM.OutputKeyLen, que representa la longi-

tud de la clave K.
2.5.2. Mecanismo de encapsulación de datos DEM

Los mecanismos DEM deben incluir los siguientes elementos:
∙ Un algoritmo de cifrado DEM.Encrypt(K,L,M ) que tome como entrada una

clave K, una etiqueta L y un mensaje M, generando como salida el texto cifrado
C1 .
∙ Un algoritmo de descifrado DEM.Decrypt(K,L,C 1 ), que produzca el mensaje

M a partir de las entradas K, L y C1 , tal que
DEM.Decrypt(K,L,DEM.Encrypt(K,L,M ))=M.
∙ Los elementos K, L, M y C1 representan cadenas de bytes, donde L y M pueden

tener longitudes variables, siendo la longitud de K el valor DEM.KeyLen.
2.5.3. Esquema de cifrado híbrido con etapas KEM -DEM

En base a las definiciones de las etapas DEM y KEM, es posible describir de
forma genérica los pasos necesarios para cifrar un mensaje M utilizando el esquema
de cifrado híbrido genérico H-PKE =H-PKE 𝐾𝐸𝑀,𝐷𝐸𝑀 . La única condición que debe
cumplirse es que, para que las etapas DEM y KEM sean compatibles, las longitudes
KEM.OutputKeyLen y DEM.KeyLen deben coincidir.
Por tanto, dado un par de claves pública y privada (𝑃 𝐾,𝑆𝐾), para cifrar un
mensaje 𝑀 con una etiqueta 𝐿 y opciones de cifrado opt, el esquema de cifrado
H-PKE debe realizar los siguientes pasos:
1. Ejecutar el algoritmo de cifrado de la fase KEM para generar la clave K y su

versión cifrada 𝐶0 .
2. Cifrar M y la etiqueta L con la clave K utilizando el algoritmo de cifrado de

la fase DEM, generando el elemento 𝐶1 .
3. Generar el criptograma 𝒞 = 𝐶0 || 𝐶1 , donde || representa la operación de con-

catenación.
De manera equivalente, para descifrar el criptograma 𝒞 con la etiqueta L y la

clave SK, el algoritmo de descifrado de H-PKE debe realizar las siguientes opera-
ciones:
1. Interpretar el criptograma 𝒞 como 𝐶0 ||𝐶1 .
2. Descifrar el elemento 𝐶0 utilizando el algoritmo de descifrado de la fase KEM

y la clave SK para obtener K.
3. Descifrar el elemento 𝐶1 con la etiqueta L utilizando el algoritmo de descifrado

de la fase KEM y la clave K, obteniendo M.
2.6. Criptografía basada en curvas elípticas

Tal como se ha comentado anteriormente, en 1987 Neal Koblitz [147] propuso
utilizar curvas elípticas sobre cuerpos finitos para implementar algunos criptosis-
temas ya existentes que utilizaban el grupo multiplicativo de un cuerpo finito. En
las secciones dedicadas al equivalente del algoritmo de ElGamal, Koblitz detalló los
cálculos que es necesario realizar sobre los puntos de una curva elíptica, incluyendo
ejemplos sobre cómo elegir dichos puntos. De forma adicional, Koblitz describió có-
mo se podría implementar el proceso de acuerdo de clave Diffie-Hellman utilizando
curvas elípticas, lo que constituye el esquema ECDH (Elliptic Curve Diffie-Hellman).
2.6. Criptografía basada en curvas elípticas 71
Por su parte, Victor Miller [174] realizó su propuesta desde un punto de vista más
teórico en relación al modelo general descrito por Diffie y Hellman, pero sin realizar
comparaciones con otras implementaciones existentes.
En los siguientes apartados se presentan los conceptos fundamentales relaciona-
dos con las curvas elípticas y con su aplicación a la criptografía.
2.6.1. Definición de curva elíptica
Dados el cuerpo 𝔽 y el plano afín A2 (𝔽) = 𝔽2 definido sobre 𝔽, se representa el

plano proyectivo correspondiente como el conjunto
P2 (𝔽) = {(𝑋, 𝑌, 𝑍) ∈ 𝔽3 ∣ (𝑋, 𝑌, 𝑍) ∕= (0, 0, 0)}

junto con la relación de equivalencia ∼, definida de manera que dos puntos del
plano proyectivo (𝑋, 𝑌, 𝑍) y (𝑋 ′ , 𝑌 ′ , 𝑍 ′ ) son equivalentes si y sólo si existe un valor
𝜆 ∕= 0 tal que (𝑋 ′ , 𝑌 ′ , 𝑍 ′ ) = (𝜆𝑋, 𝜆𝑌, 𝜆𝑍) [175]. A la clase de equivalencia del punto
(𝑋, 𝑌, 𝑍) de la representará como [𝑋 : 𝑌 : 𝑍].
Una curva plana definida sobre un cuerpo 𝔽 puede expresarse en el plano afín
2
A (𝔽) mediante la ecuación 𝑓 (𝑥, 𝑦) = 0 en coordenadas no homogéneas, o alter-
nativamente en el plano proyectivo P2 (𝔽) mediante la ecuación 𝐹 (𝑋, 𝑌, 𝑍) = 0
en coordenadas homogéneas [265], donde un polinomio es homogéneo si todos sus
monomios tienen el mismo grado.
Se considera que dicha curva tiene puntos racionales cuando las coordenadas del
punto pertenecen al cuerpo 𝔽 (no necesariamente ℚ) [244]. La existencia de puntos
racionales en una curva depende del género 𝑔 de la propia curva, concepto derivado
del teorema de Riemann [227] y que permite clasificar las curvas planas en función
del grado del polinomio que la define y de sus singularidades mediante la expresión
(𝑛 − 1)(𝑛 − 2) ∑ 𝑚𝑃𝑖 (𝑚𝑃𝑖 − 1)

(2.1) 𝑔= − ,
2 𝑃
2
𝑖
siendo 𝑛 el orden de la curva y 𝑚𝑃𝑖 la multiplicidad de cada punto singular 𝑃𝑖 [96].

Un punto de una curva es singular si y sólo si las derivadas parciales de la
expresión se anulan en dicho punto [149]. Los puntos singulares de una curva cúbica
plana se denominan nodo si el punto tiene dos tangentes distintas y cúspide si
el punto tiene una tangente doble [73]. Se dice que una curva es singular o no
regular cuando tiene al menos un punto singular, mientras que es regular o no
singular cuando no contiene puntos singulares [72]. Las Figuras 2.2 y 2.3 muestran
dos ejemplos de puntos singulares en forma de nodo y cúspide, respectivamente.
Figura 2.2: Curva 𝑦 2 = 𝑥3 con un nodo en el punto (0, 0)
Figura 2.3: Curva 𝑦 2 + 𝑥𝑦 − 𝑥3 = 0 con una cúspide en el punto (0, 0)

En función del género de una curva, es posible establecer unas pautas sobre
la posible existencia o no de puntos racionales (y como caso particular, de puntos
enteros donde las coordenadas necesariamente pertenecen a ℤ), tal como se resume
a continuación [140]:
∙ Una curva de género 𝑔 = 0 no tiene puntos racionales o bien tiene infinitos.

Sin embargo, puede no tener puntos enteros, tener una cantidad finita de ellos
o tener infinitos.
∙ Una curva de género 𝑔 = 1 no tiene puntos racionales, tiene un número finito
de ellos o bien tiene infinitos, pero sólo puede tener una cantidad finita de
puntos enteros.
∙ Una curva de género 𝑔 ≥ 2 sólo puede tener una cantidad finita de puntos
racionales.
A partir de las definiciones anteriores, se puede afirmar que una curva elíptica
𝐸 sobre el cuerpo 𝔽 es una curva proyectiva regular de género 1 que tiene al menos
un punto racional [140, 149, 245]. Toda curva elíptica admite un tipo de ecuación
canónica llamada forma de Weierstrass, cuya expresión en coordenadas homogéneas
es
(2.2) 𝐸 : 𝑌 2 𝑍 + 𝑎1 𝑋𝑌 𝑍 + 𝑎3 𝑌 𝑍 2 = 𝑋 3 + 𝑎2 𝑋 2 𝑍 + 𝑎4 𝑋𝑍 3 + 𝑎6 𝑍 6 ,
donde 𝑎1 , 𝑎2 , 𝑎3 , 𝑎4 , 𝑎6 ∈ 𝔽 y Δ ∕= 0, siendo Δ el discriminante de 𝐸 que se calcula
de la siguiente manera [168]:
⎫
Δ = −𝑑22 𝑑8 − 8𝑑34 − 27𝑑26 + 9𝑑2 𝑑4 𝑑6 

𝑑2 = 𝑎21 + 4𝑎2


⎬
𝑑4 = 2𝑎4 + 𝑎1 𝑎3
𝑑6 = 𝑎23 + 4𝑎6




𝑑8 = 𝑎21 𝑎6 + 4𝑎2 𝑎6 − 𝑎1 𝑎3 𝑎4 + 𝑎2 𝑎23 − 𝑎24
⎭
En la práctica, la ecuación de Weirstrass se suele expresar en su forma no ho-

mogénea, donde la relación entre ambas ecuaciones es 𝑓 (𝑥, 𝑦) = 𝐹 (𝑥, 𝑦, 1), y alter-
nativamente 𝐹 (𝑋, 𝑌, 𝑍) = 𝑓 (𝑋/𝑍, 𝑌 /𝑍) ⋅ 𝑍 3 , resultando la siguiente ecuación afín:
(2.3) 𝐸 : 𝑦 2 + 𝑎1 𝑥𝑦 + 𝑎3 𝑦 = 𝑥3 + 𝑎2 𝑥2 + 𝑎4 𝑥 + 𝑎6 .
Las Figuras 2.4 y 2.5 muestran dos ejemplos de curvas elípticas definidas sobre
el cuerpo de los números reales.
Figura 2.4: Curva elíptica 𝑦 2 = 𝑥3 − 10𝑥 + 15
Figura 2.5: Curva elíptica 𝑦 2 = 𝑥3 − 10𝑥 + 9

La ecuación homogénea de Weierstrass define una curva proyectiva plana con un

único punto en el infinito, 𝒪 = [0 : 1 : 0]. En principio dicha curva no tiene por qué
ser elíptica, ya que podría tener puntos singulares (en realidad, si la curva dada por
la ecuación de Weierstrass no es regular, entonces sólo tiene un punto singular, que
es finito y racional [140]). Por ello, la condición añadida Δ ∕= 0 asegura que la curva
es regular o “suave”, es decir, que no pueden existir puntos de la curva con dos o
más líneas tangentes distintas [72, 99], lo cual es equivalente a afirmar que todas las
raíces de la ecuación deben ser necesariamente simples.
Es interesante comentar que existen otras definiciones equivalentes para curvas
elípticas. Las más importantes expresan que una curva elíptica es:
∙ Una curva plana cúbica no singular con un punto racional.
∙ Una curva no singular de género 1 con un punto racional.
Partiendo de dichas definiciones, y aplicando el teorema de Nagell [51, 182] en el

primer caso, y el teorema de Riemann-Roch en el segundo [51, 227, 230], es posible
llegar a la expresión dada por la ecuación de Weierstrass, por lo que comúnmente
se considera dicha ecuación como el punto de partida al tratar con curvas elípticas.
2.6.2. Estructura de grupo

Sea 𝐸 una curva elíptica sobre un cuerpo 𝔽 definida mediante la ecuación (2.3),
y sean los puntos de la curva 𝑃 = (𝑥𝑃 , 𝑦𝑃 ), 𝑄 = (𝑥𝑄 , 𝑦𝑄 ) y 𝑅 = (𝑥𝑅 , 𝑦𝑅 ), donde
𝒪 = [0 : 1 : 0] representa el punto en el infinito en coordenadas homogéneas. En
estas condiciones, se define la operación + de la siguiente manera [50, 148, 245]:
1. Para todo punto 𝑃 de la curva, 𝑃 + 𝒪 = 𝒪 + 𝑃 = 𝑃 .
2. Dado un punto 𝑃 , entonces −𝑃 = (𝑥𝑃 , −𝑦𝑃 − 𝑎1 𝑥𝑃 − 𝑎3 ), de manera que

𝑃 + (−𝑃 ) = 𝒪. Es importante resaltar que 𝑃 y −𝑃 son los únicos puntos de
la curva cuya primera coordenada es 𝑥𝑃 .
3. Dados dos puntos 𝑃 y 𝑄 tales que 𝑃 ∕= ±𝑄, entonces 𝑅 = 𝑃 + 𝑄, con

⎫
𝑥𝑅 = 𝜆2 + 𝑎1 𝜆 − 𝑎2 − 𝑥𝑃 − 𝑥𝑄 , 





𝑦𝑅 = 𝜆 (𝑥𝑃 − 𝑥𝑅 ) − 𝑦𝑃 − 𝑎1 𝑥𝑅 − 𝑎3 ,
⎬

𝑦𝑄 − 𝑦𝑃



𝜆 = . 

𝑥𝑄 − 𝑥𝑃
⎭
4. Dado un punto 𝑃 , el punto 𝑅 = 𝑃 + 𝑃 = 2𝑃 tiene como coordenadas los

valores
⎫
𝑥𝑅 = 𝜆2 + 𝑎1 𝜆 − 𝑎2 − 𝑥𝑃 − 𝑥𝑄 , 





𝑦𝑅 = 𝜆 (𝑥𝑃 − 𝑥𝑅 ) − 𝑦𝑃 − 𝑎1 𝑥𝑅 − 𝑎3 ,
⎬


3 𝑥2𝑃 + 2 𝑎2 𝑥 𝑃 + 𝑎4 − 𝑎1 𝑦 𝑃


𝜆 = .


⎭
2 𝑦𝑃 + 𝑎1 𝑥𝑃 + 𝑎3
Las siguientes figuras muestran de forma gráfica algunos ejemplos de operaciones

realizadas sobre la curva 𝑦 2 = 𝑥3 − 10𝑥 + 15 definida sobre el cuerpo de los números
reales: suma de dos puntos 𝑃 = (𝑥𝑃 , 𝑦𝑃 ) y 𝑄 = (𝑥𝑄 , 𝑦𝑄 ) tal que 𝑥𝑃 ∕= 𝑥𝑄 e 𝑦𝑃 ∕= 𝑦𝑄
(Figura 2.6); suma de 𝑃 y 𝑄 tal que 𝑥𝑃 = 𝑥𝑄 e 𝑦𝑃 ∕= 𝑦𝑄 (Figura 2.7); suma de 𝑃
con 𝑃 siendo el resultado 2𝑃 (Figura 2.8) y suma de 𝑃 con 2𝑃 siendo el resultado
3𝑃 (Figura 2.9).
Figura 2.6: Suma de puntos de la curva 𝑅 = 𝑃 + 𝑄
Según indica el teorema de Mordell-Weil [180, 266], la operación suma de puntos

definida de esta manera cumple las propiedades descritas a continuación, lo que
permite dotar a los puntos de la curva 𝐸 de la estructura de grupo abeliano:
∙ Asociatividad: (𝑃 + 𝑄) + 𝑅 = 𝑃 + (𝑄 + 𝑅) para todo 𝑃, 𝑄, 𝑅 ∈ 𝐸.

Figura 2.7: Suma de puntos de la curva 𝑅 = 𝑃 + 𝑄 = 𝒪
Figura 2.8: Suma de puntos de la curva 𝑅 = 𝑃 + 𝑃 = 2𝑃

Figura 2.9: Suma de puntos de la curva 𝑅 = 𝑃 + 2𝑃 = 3𝑃
∙ Existencia de elemento neutro: 𝑃 + 𝒪 = 𝑃 para todo punto 𝑃 ∈ 𝐸.
∙ Existencia de elemento opuesto: dado un punto 𝑃 = (𝑥, 𝑦), existe un único

punto 𝑃 ′ tal que 𝑃 + 𝑃 ′ = 𝒪, donde 𝑃 ′ = −𝑃 .
∙ Conmutatividad: 𝑃 + 𝑄 = 𝑄 + 𝑃 para todo 𝑃, 𝑄 ∈ 𝐸.
Esta característica implica que todos los puntos racionales de una curva elíptica
definida sobre ℚ (o sobre una extensión de ℚ) pueden obtenerse a partir de un
número finito de ellos. En el caso de los cuerpos finitos, el número de generadores
es 1 ó 2 [228].
2.6.3. Curvas elípticas sobre cuerpos finitos
2.6.3.1. Orden y característica de un cuerpo finito
El orden de un cuerpo finito 𝔽 es el número de elementos de dicho cuerpo. Es

posible demostrar que la existencia de un cuerpo finito de orden 𝑞 está ligada a la
condición de que el valor 𝑞 sea una potencia prima del tipo 𝑞 = 𝑝𝑚 , donde al valor 𝑝
se le denomina característica del cuerpo y debe ser un número primo, mientras que
el valor 𝑚 puede ser cualquier entero positivo [99].
En general, en los criptosistemas basados en curvas elípticas se utilizan dos tipos

de cuerpos finitos 𝔽𝑞 con 𝑞 = 𝑝𝑚 elementos: 𝔽𝑝 y 𝔽2𝑚 . Si el cuerpo es del tipo 𝔽𝑝
(donde 𝑝 es un primo impar y 𝑚 tiene valor 1), se le denomina cuerpo finito primo;
por el contrario, si el cuerpo finito es del tipo 𝔽2𝑚 (donde evidentemente 𝑝 es igual
a 2 y 𝑚 puede ser cualquier número entero mayor o igual que 1), se le conoce como
cuerpo finito binario [215].
En los cuerpos finitos primos, los elementos del cuerpo 𝔽𝑝 se representan me-
diante los números enteros {0, 1, 2, . . . , 𝑝 − 1}. En este caso, el elemento neutro de
la operación suma es el entero 0, el elemento unitario de la operación producto es
el entero 1, la suma de elementos se realiza mediante la suma de enteros módulo
𝑝 y la multiplicación de elementos del cuerpo se efectúa igualmente mediante la
multiplicación de números enteros módulo 𝑝 [24].
En comparación, en los cuerpos finitos de tipo 𝔽2𝑚 , los elementos del cuerpo se
representan mediante cadenas de bits de longitud 𝑚. Si 𝑓 (𝑥) es un polinomio irredu-
cible de grado 𝑚 con coeficientes en 𝔽2 , entonces el cuerpo 𝔽2𝑚 puede interpretarse
como el conjunto de polinomios con coeficientes en 𝔽2 de grado estrictamente menor
que el grado de 𝑓 (𝑥) [24], o lo que es lo mismo:
𝔽2𝑚 = 𝔽2 [𝑥]/(𝑓 (𝑥)).
Los parámetros que definen el tamaño del cuerpo finito son imprescindibles para
calcular la longitud de las curvas elípticas y de las claves asociadas a dichas cur-
vas. Esta longitud debe ser interpretada como el número de bits necesarios para
representar el entero 𝑝 en curvas sobre cuerpos primos (es decir, el valor ⌈log2 𝑝⌉),
mientras que en el caso de curvas sobre cuerpos binarios la longitud coincide con el
valor del elemento 𝑚.
2.6.3.2. Orden de una curva elíptica
Se define el orden de una curva 𝐸 sobre un cuerpo 𝔽𝑞 de característica 𝑝, de-

notándose mediante la expresión #𝐸(𝔽𝑞 ), como el número de puntos de 𝐸(𝔽𝑞 ). Si
el cuerpo sobre el que está definido la curva es finito, entonces el orden de la curva
siempre será finito, y estará formado por los puntos que satisfacen la ecuación de la
curva más el punto en el infinito.
El teorema de Hasse [143] determina la siguiente expresión para el orden de una
curva:
√
#𝐸(𝔽𝑞 ) = 𝑞 + 1 − 𝑡, ∣𝑡∣ ≤ 2 𝑞,
donde el elemento 𝑡 representa la traza de la curva [99].

2.6.3.3. Versiones simplificadas de la ecuación de Weierstrass
Dependiendo de si el cuerpo 𝔽𝑞 tiene característica 2, 3 o cualquier otro valor [50],

es posible simplificar aún más la ecuación (2.3), tal como se describe a continuación:
1. Si la característica de 𝔽 no es 2 ni 3, el cambio de variables
𝑥 − 3𝑎21 − 12𝑎2 𝑦 − 3𝑎1 𝑥 𝑎31 + 4𝑎1 𝑎2 − 12𝑎3

( )
(𝑥, 𝑦) −→ , −
36 216 24
transforma la ecuación (2.3) en
(2.4) 𝑦 2 = 𝑥3 + 𝑎𝑥 + 𝑏,
cuyo discriminante pasa a ser
Δ = −16 (4𝑎3 + 27𝑏2 ).
2. Si la característica de 𝔽 es 2 aparecen dos casos distintos dependiendo del valor

de 𝑎1 .
a) Si 𝑎1 ∕= 0, entonces el cambio de variables

𝑎21 𝑎4 + 𝑎23
( )
2 𝑎3 3
(𝑥, 𝑦) −→ 𝑎1 𝑥 + , 𝑎1 𝑦 +
𝑎1 𝑎31
transforma la curva dada por la ecuación (2.3) en la curva
(2.5) 𝑦 2 + 𝑥𝑦 = 𝑥3 + 𝑎𝑥2 + 𝑏.
Esta curva se denomina “no supersingular” [99] y su discriminante es

Δ = 𝑏.
b) Si 𝑎1 = 0, entonces el cambio de variables
(𝑥, 𝑦) −→ (𝑥 + 𝑎2 , 𝑦)
transforma la ecuación (2.3) en
(2.6) 𝑦 2 + 𝑐𝑦 = 𝑥3 + 𝑎𝑥 + 𝑏.
A esta curva se la denomina “supersingular” [99] y su discriminante es

Δ = 𝑐4 .
3. Si la característica de 𝔽 es 3, de nuevo nos encontramos con dos casos distintos

en función del valor de 𝑎1 .
a) Si 𝑎21 ∕= −𝑎2 , entonces el cambio de variables

( )
2𝑎4 + 𝑎1 𝑎3 2𝑎4 + 𝑎1 𝑎3
(𝑥, 𝑦) −→ 𝑥 + 2 , 𝑦 + 𝑎1 𝑥 + 𝑎1 2 + 𝑎3
𝑎1 + 4𝑎2 𝑎1 + 4𝑎2
transforma la curva dada por la ecuación (2.3) en la curva
(2.7) 𝑦 2 = 𝑥3 + 𝑎𝑥2 + 𝑏.
Dicha curva se denomina “no supersingular” [99] y su discriminante es

Δ = −𝑎3 𝑏.
b) Si 𝑎21 = −𝑎2 , entonces el cambio de variables
(𝑥, 𝑦) −→ (𝑥, 𝑦 + 𝑎1 𝑥 + 𝑎3 )
transforma la ecuación (2.3) de 𝐸 en la curva
(2.8) 𝑦 2 = 𝑥3 + 𝑎𝑥 + 𝑏.
A esta curva se la denomina “supersingular” [99] y su discriminante es

Δ = −𝑎3 .
Una curva elíptica 𝐸 sobre un cuerpo 𝔽𝑞 de característica 𝑝 definida por la ecua-

ción cúbica en coordenadas homogéneas 𝐹 (𝑋, 𝑌, 𝑍) = 0 se dice que es supersingular
si el coeficiente de (𝑋𝑌 𝑍)𝑝−1 en (𝐹 (𝑋, 𝑌, 𝑍))𝑝−1 es cero. Por el contrario, la curva
es no supersingular si el coeficiente de (𝑋𝑌 𝑍)𝑝−1 en (𝐹 (𝑋, 𝑌, 𝑍))𝑝−1 es distinto de
cero.
De manera equivalente, se puede afirmar que una curva 𝐸 definida sobre un
cuerpo finito con característica 𝑝 es supersingular si 𝑝 divide a 𝑡, siendo 𝑡 la traza de
la curva [99], mientras que si 𝑝 no divide a 𝑡, entonces la curva es no supersingular.
El Cuadro 2.1 presenta un resumen de los distintos tipos de ecuaciones en fun-
ción de la característica de 𝔽 y de las condiciones adicionales que se impongan sobre
cada curva.
Car. de 𝔽 Ecuación Supersingular Condición

∕= 2, 3 𝑦 = 𝑥3 + 𝑎𝑥 + 𝑏
2
No –
2 𝑦 2 + 𝑥𝑦 = 𝑥3 + 𝑎𝑥2 + 𝑏 No 𝑎1 ∕= 0
2 𝑦 2 + 𝑐𝑦 = 𝑥3 + 𝑎𝑥 + 𝑏 Sí 𝑎1 = 0
3 𝑦 2 = 𝑥3 + 𝑎𝑥2 + 𝑏 No 2
𝑎1 ∕= −𝑎2
3 𝑦 2 = 𝑥3 + 𝑎𝑥 + 𝑏 Sí 𝑎21 = −𝑎2
Cuadro 2.1: Versiones simplificadas de la ecuación de Weierstrass
2.6.3.4. Estructura de grupo en curvas sobre cuerpos finitos
La operación suma definida en §2.6.2 sigue manteniendo su validez cuando la

curva 𝐸 está definida sobre el cuerpo finito 𝔽𝑞 . En el caso particular de curvas sobre
cuerpos primos 𝔽𝑝 (con 𝑝 > 3) y dadas por la ecuación (2.4), la operación + queda
particularizada de la siguiente manera [99], donde 𝑃 = (𝑥𝑃 , 𝑦𝑃 ), 𝑄 = (𝑥𝑄 , 𝑦𝑄 ),
𝑅 = (𝑥𝑅 , 𝑦𝑅 ) y los elementos que constituyen las coordenadas pertenecen a 𝔽𝑝 .
2. Dado un punto 𝑃 , entonces 𝑃 + (−𝑃 ) = 𝒪, siendo −𝑃 = (𝑥𝑃 , −𝑦𝑃 ).

⎫
𝑥𝑅 = 𝜆2 − 𝑥𝑃 − 𝑥𝑄 , 





𝑦𝑅 = 𝜆 (𝑥𝑃 − 𝑥𝑅 ) − 𝑦𝑃 ,
⎬

𝑦𝑄 − 𝑦𝑃



𝜆 = . 

𝑥𝑄 − 𝑥𝑃
⎭

valores
⎫
𝑥𝑅 = 𝜆2 − 2 𝑥𝑃 , 





𝑦𝑅 = 𝜆 (𝑥𝑃 − 𝑥𝑅 ) − 𝑦𝑃 ,
⎬


3 𝑥2𝑃 + 𝑎


𝜆 = .


⎭
2 𝑦𝑃
Las fórmulas anteriores implican que la suma de dos puntos 𝑃 y 𝑄 conlleva

la realización de 1 inversión, 2 multiplicaciones y 1 elevación al cuadrado en 𝐹𝑝 ,
mientras que para obtener 2 𝑃 a partir del punto 𝑃 es necesario realizar 1 inversión,
2 multiplicaciones y 2 elevaciones al cuadrado en 𝐹𝑝 . Las operaciones de suma y
diferencia de elementos del cuerpo finito no se suelen contabilizar debido a que, en
comparación con las otras operaciones mencionadas, son las que requieren menor
tiempo de computación.
Las siguientes figuras muestran de forma gráfica las siguientes operaciones reali-
zadas en la curva 𝑦 2 = 𝑥3 + 11𝑥 + 3 definida sobre 𝔽17 : suma de los puntos 𝑃 = (4, 3)
y 𝑄 = (9, 7), con resultado 𝑅 = (6, 9) (Figura 2.10); suma de 𝑃 = (7, 7) con
𝑃 = (7, 7), siendo el resultado 𝑅 = 2𝑃 = (2, 13) (Figura 2.11) y suma de 𝑃 = (7, 7)
con 2𝑃 = (2, 13), siendo el resultado 𝑅 = 3𝑃 = (4, 3) (Figura 2.12).
Figura 2.10: Suma de puntos 𝑅 = 𝑃 + 𝑄 sobre un cuerpo primo
En el caso particular de curvas sobre cuerpos binarios con ecuaciones como la

dada en (2.5), la operación + queda particularizada del siguiente modo [50], donde
𝑃 = (𝑥𝑃 , 𝑦𝑃 ), 𝑄 = (𝑥𝑄 , 𝑦𝑄 ), 𝑅 = (𝑥𝑅 , 𝑦𝑅 ) y los elementos que conforman las
coordenadas pertenecen a 𝔽2𝑚 .
2. Dado un punto 𝑃 , entonces 𝑃 + (−𝑃 ) = 𝒪, siendo −𝑃 = (𝑥𝑃 , 𝑥𝑃 + 𝑦𝑃 ).

Figura 2.11: Suma de puntos 𝑅 = 𝑃 + 𝑃 = 2𝑃 sobre un cuerpo primo
Figura 2.12: Suma de puntos 𝑅 = 𝑃 + 2𝑃 = 3𝑃 sobre un cuerpo primo

⎫
𝑥𝑅 = 𝜆2 + 𝜆 + 𝑥𝑃 + 𝑥𝑄 + 𝑎,  




𝑦𝑅 = 𝜆 (𝑥𝑃 + 𝑥𝑅 ) + 𝑥𝑅 + 𝑦𝑃 ,
⎬


𝑦𝑃 + 𝑦𝑄 

𝜆 = . 

𝑥𝑃 + 𝑥𝑄
⎭

valores
= 𝜆2 + 𝜆 + 𝑎,
⎫
𝑥𝑅 




⎬
𝑦𝑅 = 𝜆 (𝑥𝑃 + 𝑥𝑅 ) + 𝑥𝑅 + 𝑦𝑃 ,


𝑦𝑃 

𝜆 = 𝑥𝑃 + . 
⎭
𝑥𝑃
Con las fórmulas anteriores, tanto la suma de dos puntos 𝑃 y 𝑄 como la obtención
de 2 𝑃 a partir del punto 𝑃 necesitan 1 inversión, 2 multiplicaciones y 1 elevación al
cuadrado en 𝐹2𝑚 . Al igual que en el caso de los cuerpos primos, las operaciones de
suma y diferencia de elementos del cuerpo binario no se han contabilizado debido a
su menor tiempo de ejecución respecto al de las otras operaciones referidas, por lo
que su aportación al tiempo de procesamiento total puede considerarse despreciable.
2.6.3.5. Multiplicación de un punto por un escalar
De manera adicional a la operación suma, existe otra operación ampliamente

utilizada en los cálculos con puntos de una curva. Se trata del producto de un punto
𝑃 de la curva por el entero positivo 𝑛, que se calcula sumando el punto 𝑃 un número
𝑛 de veces consigo mismo:
𝑛 𝑃 = 𝑃 + 𝑃 + . . . + 𝑃.
Aunque en algunos textos la notación recogida para esta operación es [𝑛]𝑃 o

𝑛 ⋅ 𝑃 , se ha decidido utilizar la notación simplificada 𝑛 𝑃 con el fin de conseguir una
mayor sencillez en la exposición.
Cuando la curva elíptica está definida sobre un cuerpo finito, es necesario tener
en cuenta el hecho de que el producto de un punto cualquiera perteneciente a una
curva por el orden de dicha curva es igual al punto en el infinito. Es decir:
#𝐸(𝔽𝑞 ) 𝑃 = 𝒪.
Es importante resaltar que, en curvas definidas sobre cuerpos finitos, el orden

de un punto cualquiera 𝑃 siempre será un divisor del orden de la curva. Al valor del
cociente de dicha división se le denomina cofactor, de manera que si 𝑛 es el orden
de 𝑃 , entonces se cumplirá que el cofactor ℎ será
#𝐸(𝔽𝑞 )
ℎ= .
𝑛
2.6.4. Bases polinómicas y bases normales

Además de su interpretación como el conjunto de polinomios de grado menor
que 𝑚, 𝔽2𝑚 = 𝔽2 [𝑥]/(𝑓 (𝑥)), el cuerpo finito 𝔽2𝑚 también puede entenderse como
un espacio vectorial de dimensión 𝑚 sobre 𝔽2 . En este caso, puede utilizarse una
base de dicho espacio vectorial {𝛼0 , 𝛼1 , . . . , 𝛼𝑚−1 }, de forma que cualquier elemento
𝑎 ∈ 𝔽2𝑚 quede representado como el vector
𝑚−1
∑
𝑎= 𝑎𝑖 𝛼𝑖 = (𝑎0 , 𝑎1 , . . . , 𝑎𝑚−1 ), donde 𝑎𝑖 ∈ {0, 1} ,
𝑖=0
el cual en la práctica se representa como una cadena de bits de longitud 𝑚.
2.6.4.1. Bases polinómicas
Las representaciones de los elementos de 𝔽2𝑚 = 𝔽2 [𝑥]/(𝑓 (𝑥)) mediante bases

polinómicas utilizan una base formada por el conjunto de polinomios
{𝑥𝑚−1 , 𝑥𝑚−2 , . . . , 𝑥, 1}.
De esta manera, un elemento cualquiera 𝑎 ∈ 𝔽2𝑚 puede representarse como la

cadena de bits 𝑎 = (𝑎𝑚−1 𝑎𝑚−2 . . . 𝑎1 𝑎0 ) que se corresponden con los coeficientes del
polinomio
𝑎(𝑥) = 𝑎𝑚−1 𝑥𝑚−1 + 𝑎𝑚−2 𝑥𝑚−2 + . . . + 𝑎1 𝑥 + 𝑎0 .
Utilizando esta técnica, el elemento unitario se representa mediante la cadena

de bits (0 0 . . . 0 0 1), mientras que el elemento neutro queda representado mediante
la cadena (0 0 . . . 0 0 0).
La suma de dos elementos de 𝔽2𝑚 se realiza mediante la operación XOR aplicada
sobre los bits de las cadenas que representan a los elementos que participan en la
suma. Respecto a la multiplicación de elementos de 𝔽2𝑚 , esta operación se realiza
mediante el producto de los polinomios módulo el polinomio irreducible 𝑓 (𝑥) de

grado 𝑚 que define el cuerpo 𝔽2𝑚 , al que se le conoce como polinomio reductor. De
esta forma, el producto de dos elementos del cuerpo es el resto de la división entre
𝑓 (𝑥) del producto de ambos polinomios.
El procedimiento que suele seguirse para elegir el polinomio irreducible de grado
𝑚 es el siguiente:
1. Si existe un trinomio irreducible de la forma 𝑥𝑚 + 𝑥𝑘 + 1, entonces de entre las

distintas posibilidades se elige el de menor término medio 𝑥𝑘 . Es importante
hacer constar que estos trinomios sólo existen para algunos valores de 𝑚.
2. En caso de no existir un polinomio con las características comentadas en el

paso 1, se elige un pentanomio de la forma 𝑥𝑚 + 𝑥𝑘3 + 𝑥𝑘2 + 𝑥𝑘1 + 1. De
entre las distintas opciones iniciales, se elige el polinomio con menor valor
𝑘3 . Después, de entre el conjunto de polinomios con el valor 𝑘3 se elige el de
menor valor 𝑘2 . Por último, del conjunto de polinomios con valores 𝑘3 y 𝑘2 se
elige el de menor valor 𝑘1 . En comparación con los trinomios, los pentanomios
irreducibles existen para todo valor 𝑚 ≥ 4.
Para mayor información, tanto en [16] como en [108] es posible encontrar listas
de trinomios y pentanomios irreducibles sobre 𝔽2 .
2.6.4.2. Bases normales
Una base normal de 𝔽2𝑚 sobre 𝔽2 tiene la forma

{ }
𝑚−1
𝛽, 𝛽 2 , . . . , 𝛽 2 ,
donde 𝛽 ∈ 𝔽2𝑚 . Por tanto, cualquier elemento 𝑎 ∈ 𝔽2𝑚 queda representado como
𝑚−1
𝑖
∑
𝑎= 𝑎𝑖 𝛽 2 , donde 𝑎𝑖 ∈ {0, 1} .
𝑖=0
En el caso de las bases normales, a los elementos 𝑎 ∈ 𝔽2𝑚 se les suele represen-
tar como la cadena de bits (𝑎0 𝑎1 . . . 𝑎𝑚−1 ) de longitud 𝑚 (nótese el cambio en el
orden de los subíndices respecto a las bases polinómicas), donde 𝑎𝑖 ∈ {0, 1}. Em-
pleando esta técnica, el elemento unitario se representa mediante la cadena de bits
(1 1 . . . 1 1 1), mientras que el elemento neutro queda representado mediante la ca-
dena (0 0 . . . 0 0 0). Al igual que en las bases polinómicas, la suma de dos elementos
de 𝔽2𝑚 se realiza mediante la operación XOR aplicada sobre los bits de las cadenas
que los representan.
La ventaja de las bases normales consiste en que la operación de elevar al cuadra-

do un elemento se realiza de forma muy rápida, puesto que si 𝛼 = (𝛼0 𝛼1 . . . 𝛼𝑚−1 ),
entonces su cuadrado resulta ser 𝛼2 = (𝛼𝑚−1 𝛼0 𝛼1 . . . 𝛼𝑚−2 ). Multiplicar dos ele-
mentos distintos es, sin embargo, mucho más complicado, por lo que en la práctica
se utilizan bases normales gaussianas.
Las bases normales gaussianas constituyen un subconjunto de las bases normales,
estando caracterizadas por el hecho de que el valor 𝑚 no debe ser divisible por 8
[15]. Se denomina tipo de la base normal gaussiana (y se representa mediante la
letra 𝑇 ) al número entero positivo que indica la complejidad de la operación de
multiplicación con respecto a la base, de manera que cuando más pequeño sea ese
número, más eficiente será la multiplicación. Para unos valores determinados de 𝑚
y 𝑇 , el cuerpo 𝔽2𝑚 puede tener como mucho una base normal gaussiana de tipo 𝑇 ,
siendo las bases normales gaussianas de tipo 1 y 2 las que poseen las operaciones de
multiplicación más eficientes, por lo que se las denomina bases normales óptimas.
Aunque las bases normales permiten obtener implementaciones más eficientes
de la aritmética de puntos en curvas definidas sobre cuerpos binarios, su utilización
se encuentra controlada por las patentes descritas en §2.6.9, motivo por el cual las
implementaciones de software libre de curvas elípticas utilizan en su lugar las bases
polinómicas.
2.6.5. Representación de los puntos de una curva elíptica

Dada una curva elíptica 𝐸 definida sobre un cuerpo finito 𝔽𝑞 de característica 𝑝,
un punto 𝑃 de la curva puede representarse de forma comprimida o descomprimida
[257], tal como se describe a continuación:
∙ Forma descomprimida
La forma descomprimida de un punto 𝑃 = (𝑥, 𝑦) es la cadena 0x04||𝑋||𝑌 ,
donde 𝑋 e 𝑌 son las representaciones hexadecimales de la primera y segunda
coordenadas del punto, teniendo ambas cadenas hexadecimales una longitud
de ⌈(log2 𝑞)/8⌉ bytes.
∙ Forma comprimida
La forma comprimida de un punto 𝑃 = (𝑥, 𝑦) es la cadena 𝐶 || 𝑋, donde
𝑋 es la representación hexadecimal de la primera coordenada del punto, y
el elemento 𝐶 puede tener como valores 0x02 ó 0x03 dependiendo del punto,
calculándose este valor según el Algoritmo 2.8, tal como se encuentra descrito
en [254].
En cuanto al procedimiento para recuperar las coordenadas 𝑥 e 𝑦 del punto 𝑃

a partir de su forma comprimida, es necesario seguir las indicaciones del Algoritmo
2.9, que se encuentra descrito igualmente en [254].
Algoritmo 2.8 Compresión de un punto 𝑃 = (𝑥, 𝑦) de la curva

1. Obtener la representación binaria hexadecimal 𝑋 de la coordenada 𝑥, que
deberá tener una longitud de ⌈log2 𝑞)/8⌉ bytes.
2. Calcular el valor del elemento 𝑦˜ de la siguiente manera:
a) Si 𝑞 = 𝑝, siendo 𝑝 un número primo, realizar la asignación 𝑦˜ =

𝑦 (mod 2).
b) Si 𝑞 = 2𝑚 y 𝑥 = 0𝔽 , entonces 𝑦˜ = 0. Por el contrario, si 𝑥 ∕= 0𝔽 , entonces

es necesario calcular el elemento 𝑧 = 𝑧𝑚−1 ⋅ 𝑥𝑚−1 + . . . + 𝑧1 ⋅ 𝑥 + 𝑧0 tal
que 𝑧 = 𝑦 ⋅ 𝑥−1 , y tomar como valor de 𝑦˜ el elemento 𝑧0 .
3. Si 𝑦˜ = 0, asignar al byte 𝐶 el valor 0x02. En caso contrario, asignarle el

valor 0x03.
4. Generar como representación comprimida de 𝑃 la cadena 𝐶∣∣𝑋.
Algoritmo 2.9 Descompresión de un punto 𝑃 = (𝑥, 𝑦) de la curva

1. Interpretar la cadena hexadecimal, de longitud ⌈(log2 𝑞)/8⌉ + 1 bytes, como
los elementos concatenados 𝐶∣∣𝑋, donde la longitud de 𝐶 es de un byte.
2. Convertir la cadena 𝑋 en el elemento 𝑥 del cuerpo 𝔽𝑞 .
3. Si el valor del byte 𝐶 es 0x02, realizar la asignación 𝑦˜ = 0. Si por el contrario

𝐶 =0x03, es necesario hacer 𝑦˜ = 1.
4. Derivar el valor de 𝑦 a partir de los elementos 𝑥 e 𝑦˜ de la siguiente manera:
a) Si 𝑞 = 𝑝, siendo 𝑝 un número primo, calcular el elemento del cuerpo 𝔽𝑝

𝛼 ≡ 𝑥3 + 𝑎 𝑥 + 𝑏 (mod 𝑝), y calcular una raíz cuadrada 𝛽 de 𝛼 módulo
𝑝. Si 𝛽 ≡ 𝑦˜ (mod 2), hacer 𝑦 = 𝛽. Si por el contrario no se cumple la
equivalencia indicada, tomar 𝑦 = 𝑝 − 𝛽.
𝑚−1
b) Si 𝑞 = 2𝑚 y 𝑥 = 0, realizar la asignación 𝑦 = 𝑏2 . En cambio,
si 𝑥 ∕= 0, calcular el elemento 𝛽 = 𝑥 + 𝑎 + 𝑏 𝑥−2 del cuerpo 𝔽2𝑚 , y
encontrar a continuación un elemento 𝑧 = 𝑧𝑚−1 ⋅ 𝑥𝑚−1 + . . . + 𝑧1 ⋅ 𝑥 + 𝑧0
de 𝔽2𝑚 tal que 𝑧 2 + 𝑧 = 𝛽. Si 𝑧0 = 𝑦˜, calcular 𝑦 = 𝑥 ⋅ 𝑧, mientras que
si 𝑧0 ∕= 𝑦˜, calcular 𝑦 = 𝑥 ⋅ (𝑧 + 1).
5. Obtener como salida del proceso el punto 𝑃 = (𝑥, 𝑦).

2.6.6. Comprobación de los parámetros de una curva elíptica
En la implementación de funcionalidades de los criptosistemas basados en curvas

elípticas, uno de los puntos más críticos suele ser la generación de los parámetros
asociados a una curva y su posterior comprobación. El presente apartado tiene como
objetivo mostrar algunos de los algoritmos utilizados en estas tareas, comenzando
por el Algoritmo 2.10, utilizado para generar una curva de forma aleatoria en el caso
particular de los cuerpos finitos 𝔽2𝑚 [183, 172].
Algoritmo 2.10 Generación aleatoria de una curva sobre 𝔽2𝑚

1. Elegir una semilla aleatoria 𝑠.
2. Aplicar la función resumen SHA-1 al elemento 𝑠 para obtener una cadena

de bits 𝐵 de longitud 𝑛.
3. Asignar 𝑏 al elemento de 𝔽2𝑚 cuya representación en binario es 𝐵.
4. Incluir 𝑏 en la expresión 𝐸 : 𝑦 2 + 𝑥 ⋅ 𝑦 = 𝑥3 + 𝑥2 + 𝑏.
5. Calcular el orden #𝐸(𝔽2𝑚 ) y asignar su valor a 𝑁 .
6. Si 𝑁 ∕= 2𝑞, siendo 𝑞 un número primo, entonces volver al paso 1. En caso

contrario, continuar.
7. Generar un elemento 𝐺 ∈ 𝐸(𝔽2𝑚 ) de orden 𝑞.
8. Validar la curva con parámetros 𝒫= (𝐸, 𝔽2𝑚 , 𝑞, 2, 𝐺) según el Algoritmo

2.11. Si la validación es negativa, volver al paso 1.
Mediante el valor 𝑠 descrito en el Algoritmo 2.10, cualquier entidad puede com-

probar que la curva elíptica generada está determinada por 𝑠. La operación contraria,
esto es, la comprobación de los parámetros de una curva, se puede realizar median-
te el Algoritmo 2.11, aunque habitualmente tanto la generación de curvas como
la comprobación de la validez de sus parámetros suele ser tarea de las empresas
desarrolladoras de soluciones comerciales de curvas elípticas o de los organismos de
estandarización.
Por último, el Algoritmo 2.12 muestra un sencillo procedimiento que puede ser
utilizado para validar una clave pública cualquiera 𝑄.
La última comprobación mencionada puede resultar computacionalmente costo-
sa, sobre todo si ℎ ∕= 1 en los casos de cuerpos primos, o si ℎ ∕= 2 en el caso de los
cuerpos con característica par. Sin embargo, es una comprobación importante para
evitar problemas con ciertos subgrupos de pequeño tamaño. Precisamente puesto
que esta comprobación puede ser difícil de realizar, existe la opción de utilizar el
cofactor en la función de derivación de clave, tal como se explica en §4.3.3.
Algoritmo 2.11 Comprobación de los parámetros de una curva

1. Asignar el valor 𝑙 = #𝔽 = 𝑝𝑚 al cardinal del cuerpo base 𝔽.
2. Comprobar que #𝐸(𝔽) = ℎ ⋅ 𝑛 (siendo ℎ el cofactor de la curva y 𝑛 el orden

de un punto de la curva) mediante la generación de puntos aleatorios y la
comprobación de que tienen orden ℎ, 𝑛 o ℎ ⋅ 𝑛.
3. Comprobar que 𝑛 es un número primo, para evitar los ataques basados en

el método del descenso de Weil [30].
4. Comprobar que 𝑛 > 2160 para evitar los ataques de tipo BSGS/Rho [29].
5. Comprobar que 𝑛 ∕= 𝑝 para evitar los ataques de tipo anómalo [29].
6. Comprobar que 𝑙𝑡 ∕≡ 1 (mod 𝑛) para todos los valores 𝑡 ≤ 100 a fin de evitar
el ataque de tipo supersingular (también conocidos como MOV/Frey-Rück
[29]).
7. Comprobar que 𝐺 pertenece a la curva y tiene orden 𝑛.
Algoritmo 2.12 Validación de una clave pública 𝑄

1. Si 𝑄 ∈
/ 𝐸(𝔽𝑞 ), entonces la clave pública 𝑄 no es válida.
2. Si 𝑄 = 𝒪, la clave pública 𝑄 no es válida.
3. Si 𝑛 𝑄 ∕= 𝒪, la clave pública 𝑄 no es válida.
2.6.7. Seguridad
De manera equivalente a otros protocolos y algoritmos, la criptografía de curva

elíptica también tiene ataques que tienen en cuenta sus aspectos específicos. En los
siguientes apartados, se describen las características principales de estos ataques
sobre ECC.
2.6.7.1. Curvas supersingulares
Las curvas definidas sobre el cuerpo 𝔽𝑞 con característica 𝑝 se denominan super-

singulares si cumplen la condición #𝐸(𝔽𝑞 ) ≡ 1 (mod 𝑝) [265]. En curvas sobre 𝔽𝑝 ,
por ejemplo, una curva supersingular contendrá exactamente 𝑝 + 1 elementos.
El ataque de Frey y Rück [76], que es una generalización del trabajo de Menezes,
Okamoto y Vanstone [170] (conocido habitualmente como el ataque MOV), reduce
el ECDLP en una curva definida supersingular sobre 𝐸(𝔽𝑞 ) al DLP definido en un
cuerpo finito 𝔽𝐵
𝑞 para algún 𝐵 ≥ 1, el cual es más sencillo de resolver.
Este ataque sólo es práctico si el parámetro 𝐵 es pequeño, y para comprobar si

una curva es vulnerable a este ataque es necesario realizar la siguiente comprobación,
donde 𝑛 es el orden del generador 𝐺:
𝑞 𝐵 ∕≡ 1 (mod 𝑛) , ∀ 𝐵, 1 ≤ 𝐵 ≤ 100.
2.6.7.2. Curvas anómalas
Las curvas anómalas se caracterizan por contener exactamente 𝑞 elementos en 𝔽𝑞

[265]. Semaev [240], Smart [247] y Satoh y Araki [235] demostraron que el ECDLP
planteado para curvas anómalas puede ser resuelto de manera eficiente, por lo que
para excluir de los algoritmos de generación de claves este tipo de curvas es necesario
realizar la comprobación
#𝐸(𝔽𝑞 ) ∕= 𝑞.
2.6.7.3. Descenso de Weil
En 2002, Gaudry, Hess y Smart [91] adaptaron una idea de Frey [77] para resolver
el ECDLP utilizando el descenso de Weil para convertir el ECDLP en un problema de
curvas hiperelípticas. Tanto Jacobson, Menezes y Stein [141] como Maurer, Menezes
y Teske [167] encontraron varias curvas definidas sobre cuerpo 𝔽2𝑚 , siendo 𝑚 un
número compuesto, donde el método era viable.
Por otra parte, Menezes y Qu [173] demostraron que este método no es aplicable
a cuerpos finitos 𝔽2𝑚 cuando 𝑚 es un número primo, por lo que los estándares y
recomendaciones más recientes únicamente incluyen (en los apartados que tratan
sobre cuerpos binarios) curvas elípticas donde 𝑚 es un número primo.
2.6.8. Estándares relacionados

En el ámbito de los algoritmos y protocolos criptográficos, los hallazgos teóricos
no pueden emplearse directamente, sino que es necesario definir las conversiones y
la gestión de datos sobre los que se aplicarán las nuevas técnicas.
La información precisa que permite realizar implementaciones prácticas se de-
talla en los estándares desarrollados por diferentes organizaciones tanto nacionales
como supranacionales, así como por consorcios industriales. A continuación se enu-
meran las principales organizaciones dedicadas a esta labor de estandarización y que
han desarrollado alguna norma relacionada con las curvas elípticas y su aplicación
a la critografía:
∙ ISO
La Organización Internacional para la Estandarización (International Orga-
nization for Standardization o ISO) es el organismo encargado de promover
el desarrollo de las normas internacionales de fabricación, comercio y comu-
nicación para todas las ramas industriales (a excepción de la eléctrica y la
electrónica), especialmente en los temas relacionados con las normas de pro-
ductos y seguridad para las empresas y organizaciones a nivel internacional.
∙ IEC
La Comisión Electrotécnica Internacional (International Electrotechnical Com-
mission o IEC) es un organismo de estandarización en los campos eléctrico,
electrónico y de otras tecnologías relacionadas. Numerosas normas se desarro-
llan conjuntamente con ISO, siendo entonces denominadas normas ISO/IEC.
∙ IEEE
El Instituto de Ingenieros Eléctricos y Electrónicos (Institute of Electrical and
Electronics Engineers o IEEE) es una asociación técnico-profesional mundial
dedicada a la estandarización de tecnologías derivadas de la electricidad: inge-
niería computacional, tecnologías biomédica y aeroespacial, energía eléctrica,
control, telecomunicaciones, electrónica de consumo, etc.
∙ IETF
El Grupo de Trabajo en Ingeniería de Internet (Internet Engineering Task
Force o IETF) es una organización internacional de estandarización que tiene
como objetivo velar para que la arquitectura de la red y los protocolos técni-
cos de Internet funcionen correctamente, actuando en áreas como transporte,
seguridad, etc.
∙ ANSI
El Instituto Nacional Estadounidense de Estándares (American National Stan-
dards Institute o ANSI) es una organización sin ánimo de lucro que supervisa
el desarrollo de estándares para productos, servicios, procesos y sistemas en
los Estados Unidos, siendo miembro de ISO y de IEC. ANSI también se en-
carga de coordinar estándares estadounidenses con estándares internacionales,
de modo que los productos de Estados Unidos puedan utilizarse en todo el
mundo.
∙ NIST
El Instituto Nacional de Estándares y Tecnología (National Institute of Stan-
dards and Technology o NIST) es una agencia de la Administración de Tecno-
logía del Departamento de Comercio de los Estados Unidos. La misión de este
instituto es promover la innovación y la competencia industrial en Estados
Unidos mediante avances en las normas aplicadas y en la propia tecnología.
Las principales áreas de actuación del NIST son biotecnología, nanotecnología,

tecnologías de la información y fabricación avanzada.
∙ SECG
El Grupo de Estándares para la Criptografía Eficiente (Standards for Efficient
Cryptography Group o SECG) es un consorcio internacional fundado en 1998,
siendo su principal objetivo facilitar la adopción de la criptografía de curva
elíptica. Entre sus miembros se encuentran compañías como Certicom, Entrust,
Fujitsu y Visa.
En los próximos apartados se presentan los diferentes estándares relacionados con

la criptografía basada en curvas elípticas, agrupados según el campo de aplicación.
2.6.8.1. Protocolos de establecimiento de clave
Mediante el término ECDH nos referimos al esquema de acuerdo de clave basado

en el mecanismo Diffie-Hellman [61] y las curvas elípticas, definido en [147] y [174].
Este protocolo se encuentra incluido en los estándares ANSI X9.63 [16] e IEEE 1363
[108, 109]. También puede encontrarse en los documentos SP 800-56A del NIST [189]
y SEC 1 del SECG [254]. Además de lo anterior, el algoritmo ECDH forma parte de
la Suite B [194] de la NSA (National Security Agency).
En el campo de los protocolos de acuerdo de clave, existe otro esquema amplia-
mente conocido que utiliza curvas elípticas: el protocolo ECQMV (Elliptic Curve
Menezes-Qu-Vanstone) [171], incluido igualmente en los documentos ANSI X9.63
[16], IEEE 1363 [108] y 1363a [109], NIST SP 800-56A [189] y SECG SEC 1 [254].
2.6.8.2. Protocolos de firma digital
La norma FIPS 186-2 [184] incluye los algoritmos y esquemas de firma digital que
pueden ser empleados por las distintas agencias del gobierno de los EE.UU. Dichos
algoritmos son DSA, RSA y ECDSA (Elliptic Curve Digital Signature Algorithm).
ECDSA es el equivalente al algoritmo DSA empleando curvas elípticas [257].
En los apéndices de FIPS 186-2 [184] y en el estándar ANSI X9.62 [15] se presenta
el esquema ECDSA y se describen distintas curvas que pueden ser utilizadas en los
procedimientos de firma. Aunque el documento [184] sólo tiene ámbito de aplicación
interna en los EE.UU., al ser información de dominio público, en la práctica se utiliza
también fuera de ese ámbito.
El esquema ECDSA también se encuentra recogido en el estándar IEEE 1363
[108] y en el documento SEC 1 [254]. Por último, ECDSA es el algoritmo seleccionado
por la NSA en la Suite B [194].
2.6.8.3. Protocolos de cifrado
Los primeros esquemas de cifrado basados en curvas elípticas que surgieron fue-
ron el equivalente de los sistemas Massey-Omura [205] y ElGamal [69], ambos pre-
sentados por Koblitz en 1985 (y publicados en 1987) [147] y el Menezes-Vanstone
Elliptic Curve Cryptosystem [169], de los que se proporcionan detalles adicionales
en §4.1.
El esquema de cifrado y descifrado más extendido en la actualidad que emplea
curvas elípticas es conocido de forma genérica como ECIES (Elliptic Curve Integra-
ted Encryption Scheme), y se basa en el modelo propuesto por Bellare y Rogaway
en 1997 [26] y refinado posteriormente por Abdalla, Bellare y Rogaway en 1998 [8]
y 2001 [9, 10], constituyendo una variante del esquema ElGamal.
ECIES puede encontrarse en el estándar ANSI X9.63 [16], en el anexo IEEE
1363a [109] al documento IEEE 1363 [108] y en el estándar ISO/IEC 18033-2 [136].
Asimismo, puede encontrarse una amplia descripción de ECIES, así como numerosos
detalles técnicos para su implementación, en el documento SEC 1 [254] realizado por
el consorcio industrial SECG.
2.6.9. Patentes
En la actualidad existe un gran número de patentes reconocidas sobre ECC. La
siguiente lista muestra algunas de las patentes de mayor relevancia para la presente
Tesis.
∙ US 4.567.600 - Method and apparatus for maintaining the privacy of digital

messages conveyed by public transmission [205]: describe una forma de realizar
cálculos eficientes en cuerpos 𝔽2𝑚 con bases normales.
∙ US 4.587.627 - Computational method and apparatus for finite field arithmetic

[206]: incluye descripciones para mejorar la eficiencia de los cálculos en cuerpos
𝔽2𝑚 empleando bases normales.
∙ US 4.745.568 - Computational method and apparatus for finite field multipli-

cation [208]: presenta un diseño para la implementación eficiente en hardware
del producto de dos elementos del cuerpo 𝔽2𝑚 utilizando bases normales.
∙ US 5.146.500 - Public key cryptographic system using elliptic curves over rings
[207]: describe la utilización de curvas elípticas sobre el anillo ℤ𝑚 , donde 𝑚 es
un número compuesto.
∙ US 5.272.755 - Public key cryptosystem with an elliptic curve [166]: presenta

un criptosistema de curvas elípticas sobre cuerpos 𝔽𝑝 donde el orden de la
curva es exactamente 𝑝.
∙ US 5.463.690 - Method and apparatus for public key exchange in a cryptogra-

phic system [197]: describe un criptosistema de curvas elípticas sobre cuerpos
primos, donde los primos tienen el formato 𝑝 = 2𝑞 − 𝐶, siendo 𝐶 un valor
pequeño en comparación con 2𝑞 . Se trata de una extensión de las patentes US
5.159.632 y US 5.271.061 del mismo autor (no incluidas en este listado por
dicho motivo).
∙ US 5.581.616 - Method and apparatus for digital signature authentication [198]:

incluye una optimización en el proceso de verificación de firmas digitales con
curvas elípticas, al deducir la primera coordenada de la suma de dos puntos
únicamente a partir de la primera coordenada de dichos puntos.
∙ US 5.787.028 - Multiple bit multiplier [42]: presenta un diseño hardware y las

funciones necesarias para la multiplicación en cuerpos 𝔽2𝑚 𝑛 .
∙ US 5.854.759 - Methods and apparatus for efficient finite field basis conversion
[231]: describe un método para realizar cambios de base en cuerpos 𝔽2𝑚 de
manera eficiente.
∙ US 5.933.504 - Strengthened public key protocol [44]: recoge procedimientos y

recomendaciones para evitar ataques de subgrupos pequeños.
∙ US 6.078.667 - Generating unique and unpredictable values [43]: presenta mé-

todos específicos de generación de números aleatorios para ser utilizados como
claves privadas.
∙ US 6.212.279 - Method of elliptic curve cryptographic key exchange using redu-

ced base tau expansion in non-adjacent form [192]: incluye indicaciones para
realizar multiplicaciones eficientes en curvas sobre cuerpos 𝔽2𝑚 en las opera-
ciones de acuerdo de clave.
∙ US 6.243.467 - Method of elliptic curve digital signature generation and verifi-

cation using reduced base tau expansion in non-adjacent form [193]: describe el
procedimiento para realizar multiplicaciones eficientes en curvas sobre cuerpos
𝔽2𝑚 en operaciones de firma digital.
∙ US 6.252.960 - Compression and decompression of elliptic curve data points

[104]: incluye las operaciones necesarias para realizar la compresión y descom-
presión de puntos de una curva elíptica.
∙ US 6.618.483 - Elliptic curve encryption systems [45]: presenta un esquema

de cifrado que emplea directamente el producto de la clave privada temporal
del emisor y la clave pública del receptor como clave de cifrado, incluyendo
la compresión de puntos para su transmisión. Se trata de una extensión de la
patente US 6.141.420 (no incluida en este listado por ese motivo).
∙ US 6.704.870 - Digital signatures on a smartcard [46]: describe una implemen-

tación del algoritmo ECDSA con ciertas modificaciones que tiene en conside-
ración las limitaciones de las tarjetas inteligentes.
∙ US 6.782.100 - Accelerated finite field operations on an elliptic curve [47]:

recoge una optimización para la multiplicación en cuerpos 𝔽2𝑚 de un punto de
la curva cuya característica principal consiste en no emplear en ciertos pasos
la segunda coordenada, recuperando el valor de la segunda coordenada del
producto al final de la operación.
∙ EP 1 496 644 A2 - Method for signature and session key generation [41]: des-
cribe el protocolo de acuerdo de clave MQV, representando una continuación
de la patente EP 0 739 105 A1 (no incluida en este listado por ese motivo).
Capítulo 3
Capacidades criptográficas en Java
Este capítulo tiene como objetivo presentar las capacidades criptográfi-

cas del lenguaje Java, en concreto las disponibles en las ediciones Java
Standard Edition y Java Card, para lo cual se ofrece una introducción a
la programación orientada a objetos y al lenguaje Java en general, junto
con un resumen de las principales bibliotecas criptográficas desarrolladas
con este lenguaje de programación. En el apartado que hace referencia a
Java Card, se ha incluido una descripción detallada de las características
generales de este sistema operativo y de las peculiaridades de su modelo
de programación.
3.1. Programación orientada a objetos
Los lenguajes de programación orientados a objetos, entre los que se encuentra

Java, tienen en común ciertas características desarrolladas en torno al propio con-
cepto de “objeto”, que no es más que la instanciación o concreción de una clase.
A su vez, una clase es el molde o prototipo que especifica las variables y métodos
comunes de un determinado tipo de elemento.
Entre las características que Java comparte con otros lenguajes de programación
es imprescindible mencionar los mecanismos de encapsulación, herencia y polimor-
fismo [107], tal como se describen en los siguientes apartados.
99
100 3. Capacidades criptográficas en Java
3.1.1. Encapsulación
La encapsulación consiste en la ocultación de variables y métodos de un objeto,
permitiendo su modificación sólo a través de determinados métodos “públicos”. Este
procedimiento conlleva los siguientes beneficios:
∙ Modularidad: el código de un objeto puede ser creado y mantenido indepen-

dientemente del código de otros objetos. La creación e intercambio de código
es, de esta manera, más sencilla.
∙ Ocultación de la información: los objetos pueden ofrecer una interfaz pública
para la comunicación con otros objetos, manteniendo a la vez ciertos métodos
y variables ocultos, de manera que se puedan modificar sin afectar a los demás
objetos.
3.1.2. Herencia
La herencia es un concepto que relaciona clases de manera jerárquica. Esto per-
mite que los descendientes de una clase hereden todas las variables y métodos de sus
ascendientes, además de crear los suyos propios. A estos descendientes se les llama
subclases. Al padre inmediato de una clase se le denomina superclase. Una subclase
es una versión especializada de su superclase correspondiente que hereda todos sus
métodos y variables de instancia.
3.1.3. Polimorfismo
A los métodos que actúan sobre los objetos se les pasa información en forma
de parámetros en la llamada al método. Estos parámetros representan los valores
de entrada a cada función implementada por la aplicación. Para completar dos
tareas diferentes en la mayoría de los lenguajes de programación es necesario tener
dos funciones independientes con nombres diferentes. El polimorfismo (un objeto y
muchas formas) es un concepto simple que permite que un método tenga múltiples
implementaciones que se seleccionan en base al tipo de objeto que se le pasa en la
llamada al método, lo que se conoce como “sobrecarga del método”.
3.2. El lenguaje Java
3.2.1. Introducción al lenguaje Java

Los orígenes de Java se remontan al año 1990, cuando un equipo de la compa-
ñía Sun Microsystems investigaba, bajo la dirección de James Gosling, el diseño y
3.2. El lenguaje Java 101
elaboración de software para pequeños dispositivos electrónicos en el entorno de un

proyecto denominado Green Project. En un primer momento se pensó en la utili-
zación de lenguajes de programación como C o C++, pero puesto que para poder
compilar un programa en estos lenguajes era preciso adaptarlo a las características
de la plataforma en la que debía funcionar, y que cada pocas semanas aparecían en
el mercado versiones más potentes y baratas de los chips utilizados, el software que
había sido diseñado para un chip determinado debía necesariamente modificarse y
adaptarse para explotar las características de los nuevos chips.
De esta forma, se hizo patente la necesidad de introducir un nuevo lenguaje de
programación que permitiera desarrollar programas independientemente de la pla-
taforma subyacente. Los dispositivos que se pretendían fabricar eran calculadoras,
relojes, equipos de música, cafeteras, etc., todos ellos de pequeña capacidad compu-
tacional, por lo que el nuevo lenguaje debía ser capaz de generar programas pequeños
y rápidos, además de ser fiables y robustos. La primera versión de este nuevo len-
guaje se denominó Oak, pero tuvo que ser descartado debido a que el nombre ya se
encontraba registrado. El nombre elegido como sustituto fue Java.
A pesar del esfuerzo invertido, los proyectos en los que se aplicó el lenguaje Java
no tuvieron éxito, razón por la cual Sun decidió darle una segunda oportunidad apli-
cándolo al por entonces incipiente mercado de la navegación por internet. El equipo
de James Gosling se planteó como objetivo la utilización de Java como lenguaje
de desarrollo para aplicaciones que pudiesen funcionar a través de internet, y como
resultado de su trabajo se presentó en 1995 un navegador escrito completamente
en Java, denominado HotJava. Este navegador permitía la integración de pequeñas
aplicaciones en el interior de las páginas web. El desarrollo de HotJava hizo patente
que las características de Java se adaptaban satisfactoriamente a las características
de internet.
A partir de aquella primera y sencilla versión, Java fue creciendo progresivamente
en tamaño y complejidad, ofreciendo un lenguaje de programación utilizado en gran
cantidad de campos técnico-científicos. Desde su versión J2SE 1.4, la evolución del
lenguaje ha estado regulada por el JCP (Java Community Process), que utiliza
las JSR (Java Specification Request) para proponer y especificar cambios en la
plataforma Java. El lenguaje en sí mismo está especificado en la JLS (Java Language
Specification).
Para evitar confusiones con la nomenclatura, a continuación se presentan las
distintas versiones del lenguaje Java en función de su fecha de aparición:
∙ JDK 1.0 (23 de enero de 1996): constituyó la versión inicial. La denominación

JDK hace referencia al software de desarrollo Java Development Kit.
∙ JDK 1.1 (19 de febrero de 1997): reestructuró el modelo de interfaces gráficas
AWT (Abstract Window Toolkit) y presentó el concepto RMI (Remote Method
Invocation).
∙ J2SE 1.2 (Playground, 8 de diciembre de 1998): representó el cambio a la

denominación Java 2 y el nombre J2SE (Java 2 Platform, Standard Edition)
para distinguir esta plataforma de J2EE (Java 2 Platform, Enterprise Edition).
Su característica más importante es que la API gráfica (Swing) fue integrada
en las clases básicas.
∙ J2SE 1.3 (Kestrel, 8 de mayo de 2000): incluyó la máquina virtual HotSpot

JVM.
∙ J2SE 1.4 (Merlin, 6 de febrero de 2002): fue el primer lanzamiento de la pla-

taforma Java gestionado por el JCP como el subproyecto JSR 59. Su principal
novedad fue la inclusión de un modelo de seguridad integrada que permitía
extensiones criptográficas de terceros.
∙ J2SE 5.0 (Tiger, 30 de septiembre de 2004): significó el cambio de la numera-

ción tipo 1.X a la X.0.
∙ Java SE 6 (Mustang, 11 de diciembre de 2006): en esta versión, Sun cambió el

nombre J2SE por Java SE y eliminó el “.0” del número de versión.
∙ Java SE 7 (Dolphin, prevista para 2011): entre otras novedades, permitirá

operar con clases BigDecimal utilizando operadores ariméticos en lugar de
llamadas a métodos.
Actualmente la cifra de desarrolladores Java supera los 6 millones, existiendo más

de 4.500 millones de dispositivos habilitados con tecnología Java (principalmente
ordenadores personales, teléfonos móviles y tarjetas inteligentes, según [212]). Entre
noviembre de 2006 y mayo de 2007, Sun Microsystems liberó la mayor parte de la
tecnología Java bajo licencia GNU GPL a través del proyecto OpenJDK [213], de
tal forma que con la excepción de algunos elementos sobre los que Sun no tiene los
derechos (principalmente la tecnología de gestión de gráficos Java 2D), prácticamente
todo el lenguaje Java es actualmente software libre. El 27 de enero de 2010, la
compañía Oracle Corporation finalizó la adquisición de Sun Microsystems [214], por
lo que a partir de ese momento la tecnología Java ha pasado a ser gestionada por
Oracle.
En cuanto a las distintas ediciones del lenguaje Java, además de las versiones
Standard y Enterprise mencionadas anteriormente, es posible utilizar las plataformas
Micro Edition y Java Card. A continuación se muestra un breve resumen de sus
características diferenciadoras:
∙ Java Standard Edition (Java SE): proporciona un entorno de ejecución y un

conjunto de API para aplicaciones de ordenadores personales. De manera adi-
cional define el núcleo de funcionalidades presente en las otras ediciones.
∙ Java Enterprise Edition (Java EE): esta edición constituye un conjunto amplia-
do respecto de la versión Standard, estando orientada a entornos empresariales.
∙ Java Micro Edition (Java ME): esta versión define un subconjunto extendido
de la edición Standard, especialmente diseñada para su utilización en teléfonos
móviles y PDAs (Personal Digital Assistant).
∙ Java Card (JC): es la versión específica del lenguaje Java para el mercado de
tarjetas inteligentes.
La Figura 3.1 muestra de manera gráfica las distintas ediciones del lenguaje Java.
Figura 3.1: Ediciones del lenguaje Java
3.2.2. Elementos del entorno Java

El Java Runtime Environment (JRE) es el software necesario para ejecutar cual-
quier aplicación desarrollada para la plataforma Java. El usuario final utiliza el JRE
como parte del entorno Java instalado o como conectores (plugins) en sus navega-
dores web [57].
El JRE está constituido por una Java Virtual Machine (JVM), que es el programa
que interpreta el código Java, y por las librerías de clases estándar que implementan
las diferentes API de Java. Ambos elementos, JVM y API, deben ser consistentes
entre sí, de ahí que sean distribuidas de forma conjunta.
La máquina virtual Java se inicia automáticamente cuando se lanza el proceso
que se desea ejecutar y se detiene cuando éste finaliza. Su objetivo es el de pro-
porcionar un entorno de ejecución independiente de la plataforma hardware y del
sistema operativo, que oculte los detalles de la plataforma subyacente y permita

que un programa se ejecute siempre de la misma forma en cualquier entorno. La
JVM es un programa nativo, es decir, ejecutable en una plataforma específica, ca-
paz de interpretar y ejecutar instrucciones expresadas en un código binario especial
denominado bytecode, el cual es generado por el compilador del lenguaje Java.
La JVM es una de las piezas fundamentales de la plataforma Java. Básicamente
se sitúa en un nivel superior al hardware del sistema sobre el que se pretende ejecutar
la aplicación, y actúa como un puente que entiende tanto el bytecode como las
instrucciones nativas del sistema. Así, cuando se escribe una aplicación Java, se hace
pensando que será ejecutada en una máquina virtual Java, que en última instancia
convierte de bytecode a código nativo del dispositivo. La gran ventaja de la máquina
virtual Java consiste en permitir la portabilidad del mismo bytecode a diferentes
arquitecturas y sistemas operativos.
Además de lo anterior, la JVM provee definiciones para el conjunto de instruc-
ciones y registros, un formato para los archivos de clases, la pila (stack ), un heap
con recolector de basura y la reserva de un área de memoria. Toda implementa-
ción aprobada de la JVM debe ser capaz de ejecutar cualquier clase incluida en las
especificaciones Java.
El código resultante de la compilación es ejecutado por la JVM, la cual realiza
la emulación del conjunto de instrucciones, bien por un proceso de interpretación o
más habitualmente mediante un compilador JIT (Just In Time), como el compila-
dor HotSpot de Sun. Esta última opción convierte el bytecode a código nativo de la
plataforma destino la primera vez que debe interpretar ese bytecode y lo almacena,
de manera que si es necesario ejecutar el mismo código de nuevo ya no es necesaria
una nueva interpretación del bytecode, lo que permite una ejecución considerable-
mente más rápida en los casos es que la misma porción de código se ejecuta en más
de una ocasión. Los principales inconvenientes son el tiempo necesario al principio
del proceso para la compilación a código nativo y los requisitos de memoria para su
almacenamiento temporal.
La JVM verifica todo bytecode antes de ejecutarlo, por lo que cualquier secuencia
de bytecode con un formato desconocido o erróneo no es ejecutada por no ser válida.
En más detalle, la JVM tiene instrucciones para los siguientes grupos de tareas:
∙ Operaciones aritméticas.
∙ Carga y almacenamiento de elementos.
∙ Conversión de tipos.
∙ Creación y manipulación de objetos.
∙ Gestión de pilas (push/pop).

∙ Transferencias de control (branching).
∙ Invocación y retorno de los métodos.
∙ Lanzamiento de excepciones.
3.2.3. Características criptográficas de Java

Dentro de la arquitectura Java, una de las interfaces más importantes es Security
API, que está construida en torno al paquete java.security. La primera versión de
Security API para la versión JDK 1.1 introdujo el esquema JCA (Java Cryptography
Architecture) [106], que permitía la generación de firmas digitales y resúmenes de
mensajes [78, 172].
En las siguientes versiones, J2SE extendió la funcionalidad JCA, incluyendo una
arquitectura tipo “proveedor” que permitiera implementaciones criptográficas múl-
tiples e interoperables de otros algoritmos. El resultado fue el componente adicional
JCE (Java Cryptography Extension) [106], que proporciona implementaciones para
cifrado y descifrado de datos, generación y acuerdo de claves y algoritmos MAC
(Message Authentication Code) [78, 172]. JCE constituía inicialmente un paquete
opcional del software J2SE, pero desde la versión 1.4 se incluyó en el núcleo de la
distribución J2SE, por lo que se suele considerar que los elementos JCA y JCE for-
man parte de un único módulo, siendo referido este esquema de seguridad como el
modelo JCA/JCE.
La independencia de algoritmos se logra mediante la definición de “motores” o
proveedores criptográficos. La Figura 3.2 ilustra la utilización de estos proveedores,
mediante un ejemplo en el que una aplicación desea utilizar el algoritmo AES. El
funcionamiento es el siguiente: en lugar de codificar la lógica del algoritmo por sí
misma, la aplicación del ejemplo solicita a uno de los proveedores criptográficos
(disponibles en ese entorno Java específico) la utilización de su implementación del
algoritmo AES.
Uno de los beneficios de este esquema consiste en que cualquier aplicación que
quiera hacer uso de un algoritmo (en el ejemplo anterior, AES) siempre utilizará
las mismas clases y los mismos nombres identificativos para los algoritmos, inde-
pendientemente de quién haya implementado el proveedor criptográfico que esté
siendo utilizado. Algunos ejemplos de las clases incluidas en dichos motores son
MessageDigest (generación de resúmenes), Signature (creación y verificación de
firmas digitales), KeyFactory (generación de claves para los distintos algoritmos
criptográficos), Cipher (cifrado y descifrado de datos) y Mac (cálculo de códigos
MAC ).
Este esquema de seguridad es útil, pero únicamente si la distribución Java des-
cargada por el usuario incluye algún proveedor por defecto. Afortunadamente, éste
Figura 3.2: Ejemplo de utilización de proveedores criptográficos en Java
es el caso, y por ejemplo la versión Java SE 6 incluye los siguientes proveedores

criptográficos:
∙ SUN
∙ SunRsaSign
∙ SunJCE
∙ SunPKCS11
∙ SunJGSS
∙ SunSASL
∙ XMLDSig
∙ SunPCSC
∙ SunMSCAPI
La razón por la que se incluye un número tan elevado de proveedores se debe

a que, inicialmente, los motores criptográficos se crearon de manera independiente
atendiendo a necesidades muy específicas, por lo que el grado de solapamiento de los

anteriores proveedores en relación a los algoritmos soportados es mínimo. Por ejem-
plo, el paquete SUN incluye algoritmos resumen como MD5, SHA-1, SHA-256, etc.,
el paquete SunRsaSign está especializado en las implementaciones de firma digital
RSA que emplean distintas funciones resumen (como por ejemplo MD5withRSA,
SHA1withRSA, etc.), el paquete SunJCE permite acceder a funciones de generación
de códigos MAC (HmacSHA1, HmacSHA256, etc.) y algoritmos de cifrado simétrico
(DES, AES, etc.), y así sucesivamente.
Sin embargo, al examinar los algoritmos implementados en los distintos provee-
dores JCA/JCE desarrollados por Sun, no es posible encontrar ninguna referencia
a la criptografía de curva elíptica. De hecho, antes de la versión J2SE 5.0, la arqui-
tectura JCA/JCE no incluía clases para algoritmos relacionados con criptografía de
curva elíptica ni tenía estandarizados los nombres de dichos algoritmos para poder
realizar llamadas desde un programa Java, por lo que los usuarios que deseaban
emplear estos algoritmos dependían de software propietario de otras compañías. Es-
ta situación era muy negativa, y afortunadamente la versión J2SE 5.0 solucionó en
parte este problema, ya que a partir de dicha versión se inició la inclusión de clases,
interfaces y nombres estándar para facilitar a los proveedores el soporte ECC.
En concreto, dentro del paquete java.security se incluyeron las interfaces
∙ spec.ECField
∙ interfaces.ECKey
∙ interfaces.ECPublicKey
∙ interfaces.ECPrivateKey
y las clases
∙ spec.ECFieldF2m
∙ spec.ECFieldFp
∙ spec.ECGenParameterSpec
∙ spec.ECParameterSpec
∙ spec.ECPoint
∙ spec.ECPrivateKeySpec
∙ spec.ECPublicKeySpec
∙ spec.EllipticCurve
Además, se definieron los nombres estándar que podían ser utilizados en las
llamadas a las clases, tal como se indica a continuación:
∙ Cipher: ECIES.
∙ KeyPairGenerator: EC.
∙ KeyFactory: EC.
∙ KeyAgreement: ECDH, ECMQV.
∙ Signature: NONEwithECDSA, SHA1withECDSA, SHA256withECDSA, SHA-
384withECDSA y SHA512withECDSA.
Con estos elementos, aunque los motores criptográficos de Sun no incluyan im-
plementaciones de ECC, las aplicaciones que deseen utilizar funcionalidades de crip-
tografía de curva elíptica al menos pueden hacer uso de bibliotecas criptográficas
interoperables y adaptadas a la arquitectura JCA/JCE que hayan sido desarrolla-
das por terceras empresas.
3.3. Bibliotecas criptográficas

Existen multitud de bibliotecas (libraries) y módulos criptográficos en el mercado
enfocados al desarrollo de programas de seguridad, entre ellos cabe destacar:
∙ Botan (botan.randombit.net)
∙ Bouncy Castle (www.bouncycastle.org)
∙ Cryptix (www.cryptix.org)
∙ Cryptlib (www.cryptlib.com)
∙ Crypto++ (sourceforge.net/projects/cryptopp)
∙ IAIK (jce.iaik.tugraz.at)
∙ libecc (libecc.sourceforge.net)
∙ FlexiProvider (www.flexiprovider.de)
Por motivos de eficiencia del código nativo, la mayoría de estas implementaciones

están desarrolladas en lenguajes como C++ o directamente en ensamblador. Sin
embargo, por ser el objetivo de la presente Tesis, en los siguientes apartados se
describirán en mayor detalle los principales productos Java: Cryptix, Bouncy Castle,
IAIK y FlexiProvider. La información recogida en los siguientes apartados representa
un resumen de [81], [82] y [83].
3.3. Bibliotecas criptográficas 109
3.3.1. Cryptix
Cryptix [56] fue la primera biblioteca criptográfica de código libre para el desarro-
llo de aplicaciones Java. Entre los subproyectos gestionados en el ámbito de Cryptix
destacan un proveedor JCE para JDK 1.1.x, 1.2, 1.3 y 1.4 (Cryptix JCE), una im-
plementación Java del estándar OpenPGP (Cryptix OpenPGP) y un paquete para
la utilización de criptografía de curva elíptica (Cryptix Elliptix).
Sin actividad desde 2005, en su propia página web se indica que el proyecto se
encuentra abandonado. Sin embargo, a efectos comparativos con otras distribuciones
resulta interesante conocer el grado de desarrollo del paquete Cryptix Elliptix. Su
objetivo era poder proporcionar una implementación Java de los estándares IEEE
1363 [108], ANSI X9.62 [15] y X9.63 [16]. En la última versión proporcionada, el
paquete incluía soporte para aritmética tanto sobre 𝔽𝑝 (con coordenadas proyectivas)
como sobre 𝔽2𝑚 (con coordenadas afines sobre base polinómica). Sin embargo, no
proporcionaba soporte para la generación de los parámetros de la curva. Asimismo,
las operaciones de alto nivel (por ejemplo, la firma digital y la verificación de dichas
firmas) tampoco estaban disponibles en dicha versión.
3.3.2. Bouncy Castle

Legion of the Bouncy Castle [32] es un grupo de voluntarios que ha desarrollado
implementaciones de código abierto de API criptográficas en los lenguajes Java y
C#. Su última versión (la 1.45, publicada en enero de 2010) está organizada de tal
manera que contiene dos conjuntos de API:
∙ Una API independiente (lo que Bouncy Castle denomina light-weight) de bajo
nivel que puede ser utilizada en cualquier entorno (desde Java ME hasta Java
SE 6) sin necesidad de compatibilidad con la arquitectura JCE.
∙ Un proveedor ajustado al esquema JCA/JCE.
Además de lo anterior, Bouncy Castle proporciona los siguientes recursos:
∙ Una implementación de la arquitectura JCE 1.2.1.
∙ Una biblioteca para la lectura y escritura de objetos ASN.1.
∙ Una API TLS para el modo cliente.
∙ Generadores de certificados X.509 en sus versiones 1, 2 y 3, así como gene-

radores de listas de revocación de certificados (CRL) y archivos PKCS#12
(utilizados para almacenar claves privadas junto con su correspondiente certi-
ficado de clave pública).
∙ Generadores y procesadores para S/MIME y CMS (PKCS7/RFC 3852), OCSP

(RFC 2560), TSP (RFC 3161) y OpenPGP (RFC 2440).
En lo referente a criptografía de curvas elípticas, Bouncy Castle incluye im-

plementaciones de ECDH, ECDSA y ECIES, aunque como elemento mejorable la
implementación de ECIES sólo permite un conjunto de parámetros fijos (algorit-
mo de acuerdo de clave ECDH, función HMAC-SHA1 y algoritmo de derivación de
claves KDF2).
Puesto que son muchas las clases implementadas para dichas funcionalidades,
únicamente las siguientes clases del paquete org.bouncycastle.math.ec serán ci-
tadas como ejemplo:
∙ ECCurve: representa una curva elíptica mediante su ecuación de Weierstrass.
∙ ECFieldElements: representa un elemento del cuerpo finito utilizado.
∙ ECPoint: representa los puntos de una curva elíptica e implementa la aritmé-

tica de los puntos.
Todas las clases abstractas anteriores (ECCurve, ECFieldElements y ECPoint)

son implementadas por dos subclases derivadas, Fp y F2m, representando a las curvas
definidas sobre cuerpos finitos primos y binarios, respectivamente.
A principios de 2008 se publicó un estudio [161] que demostraba la posibilidad
de utilizar un fallo en la implementación de la clase ECPoint para realizar ataques
reales (por ejemplo, contra el esquema de cifrado ECIES). Esta vulnerabilidad fue
posteriormente corregida en la versión 1.33.
Por el grado de soporte (tanto para operaciones de firma como cifrado) y desarro-
llo continuado, Bouncy Castle es posiblemente uno de los mejores paquetes cripto-
gráficos de uso gratuito que se puede encontrar actualmente en internet, tanto para
aplicaciones ECC como para las que utilicen otros algoritmos (RSA, AES, etc.).
3.3.3. IAIK
El Institut für Angewandte Informationsverarbeitung und Kommunikationstech-
nologie (Institute for Applied Information Processing and Communications) de la
Universidad de Graz [260] ha desarrollado un conjunto de herramientas criptográfi-
cas escritas en Java, cuyos principales exponentes son IAIK-JCE (módulo principal
con los algoritmos RSA, DES, AES, Blowfish, etc., y cuya versión más reciente es la
3.18, lanzada en agosto de 2009), IAIK-iSaSiLk (implementación Java de TLS 1.0 y
SSL 3.0, cuya versión 4.4 está disponible desde febrero de 2010) e IAIK-ECC (cuya
versión 2.19 fue lanzada en agosto de 2009).
3.3. Bibliotecas criptográficas 111
El paquete IAIK Elliptic Curve Cryptography Library presenta las siguientes

características:
∙ Es compatible con los estándares IEEE 1363 [108] y ANSI X9.62 [15].
∙ Incluye una implementación ECDSA compatible con la arquitectura de segu-

ridad JCA/JCE con soporte de la familia de funciones resumen SHA-2, de
acuerdo a los documentos ANSI X9.62 [15] y BSI TR 03111 v1.00 [37].
∙ Utiliza aritmética sobre cuerpos primos y binarios. En cuerpos binarios se

emplea únicamente la representación sobre base polinómico por problemas de
patentes.
∙ Permite definir y realizar operaciones con los puntos de la curva en coordenadas

afines y proyectivas.
∙ Ofrece una implementación de ECDH con y sin multiplicación del cofactor.
∙ Calcula la codificación ASN.1 correspondiente a firmas digitales, claves públi-

cas y claves privadas.
Además de lo anterior, la biblioteca IAIK-ECC permite las siguientes opciones

de personalización:
∙ Precálculo de puntos: permite precalcular y almacenar un conjunto de puntos

para mejorar la generación de claves y la realización de firmas posteriores. El
precálculo no tiene ninguna influencia sobre la verificación de firmas, y debe
ser utilizada en caso de generación de muchos puntos y firmas sobre la misma
curva. Por defecto esta opción se encuentra desactivada.
∙ Codificación: es posible especificar el identificador de objeto (OID) o codificar

los parámetros explícitamente. Por defecto la opción utilizada es la codificación
explícita.
∙ Comprobación de puntos: la implementación permite opcionalmente compro-

bar si los puntos decodificados se encuentran sobre una determinada curva.
Por defecto esta opción se encuentra desactivada.
Es necesario destacar como aspecto negativo la ausencia de una implementación

de ECIES. El software IAIK está disponible gratuitamente en forma de versiones
beta y de evaluación, siendo necesario adquirir una licencia para la utilización del
producto completo.
3.3.4. FlexiProvider
Los paquetes criptográficos generados como un proyecto de código libre en torno

al producto FlexiProvider [259] han sido desarrollados por un grupo de estudian-
tes y profesores de la Universidad Politécnica de Darmstadt. Entre ellos destacan
CoreProvider, que incluye algoritmos de cifrado simétrico y asimétrico, así como
funciones resumen y de generación de códigos MAC, y ECProvider, que incluye
implementaciones de los algoritmos ECDH, ECDSA y ECIES compatibles con los
estándares ANSI X9.62 [15], IEEE 1363 [108] y 1363a [109], SEC 1 [254] y SEC 2
[255].
El soporte de curvas incluidas en los estándares citados es muy amplio. A con-
tinuación se presentan los nombres identificativos de las curvas que el paquete EC-
Provider en su última versión (1.6p7) permite utilizar, donde el número asociado
a cada curva hace referencia al tamaño en bits de los elementos del cuerpo finito
empleado.
∙ Curvas sobre 𝔽𝑝 de ANSI X9.62: prime192v1, prime192v2, prime192v3, pri-

me239v1, prime239v2, prime239v3 y prime256v1.
∙ Curvas sobre 𝔽2𝑚 de ANSI X9.62: c2pnb163v1, c2pnb163v2, c2pnb163v3, c2tnb-

191v1, c2tnb191v2, c2tnb191v3, c2pnb208w1, c2tnb239v1, c2tnb239v2, c2tnb-
239v3, c2pnb272w1, c2tnb359v1, c2pnb368w1 y c2tnb431r1.
∙ Curvas sobre 𝔽𝑝 de SEC 2: secp112r1, secp112r2, secp128r1, secp128r2, secp160-

k1, secp160r1, secp160r2, secp192k1, secp224k1, secp224r1, secp256k1, secp384-
r1 y secp521r1.
∙ Curvas sobre 𝔽𝑝 del Grupo Brainpool: brainpoolP160r1, brainpoolP192r1,

brainpoolP224r1, brainpoolP256r1, brainpoolP320r1, brainpoolP384r1 y brain-
poolP512r1.
∙ Curvas sobre 𝔽𝑝 del Grupo CDC: desde la curva primeCurve 1 a la curva

primeCurve 38.
La versión del algoritmo ECIES del paquete ECProvider es notablemente fle-

xible, permitiendo un elevado número de combinaciones de parámetros. Además
del código binario y la documentación, su página web incluye ejemplos y tutoriales
sobre cómo utilizar los paquetes comentados. Por todos estos motivos, los paque-
tes del proyecto FlexiProvider constituyen una alternativa muy interesante para el
desarrollo de aplicaciones que utilicen funcionalidades ECC.
3.4. Java Card 113
3.4. Java Card
3.4.1. Introducción al lenguaje Java Card

La tecnología Java Card combina un subconjunto del lenguaje Java con un en-
torno de ejecución optimizado para las tarjetas inteligentes [48, 100], que se carac-
terizan por ser dispositivos con capacidades limitadas.
Las API Java Card fueron presentadas en noviembre de 1996 por un grupo de
ingenieros de Schlumberger (empresa francesa denominada así debido al apellido de
sus fundadores, Conrad y Marcel Schlumberger) que intentaban aunar la facilidad
de desarrollo del lenguaje Java con las características de seguridad de las tarjetas
inteligentes. Poco después de presentar el primer borrador de las API Java Card, a
Schlumberger se le unieron Gemplus y Bull pasando a crear el Java Card Forum, un
consorcio creado para identificar y resolver los problemas asociados a la tecnología
Java Card.
Tras la presentación de Java Card 1.0, Sun comenzó a colaborar activamente
con los fabricantes de tarjetas y el resultado fue el anuncio en noviembre de 1997
de Java Card 2.0. Esta nueva versión era bastante diferente de la inicial, ya que
proporcionaba un mecanismo de programación orientado a objetos y mejoraba el
nivel de detalle de la especificación del entorno de ejecución de aplicaciones, aunque
por contra no incluía la especificación del formato de los applet (aplicaciones Java
Card) para su descarga.
Debido a la necesidad de adaptar las capacidades del lenguaje Java a las li-
mitaciones físicas de las tarjetas inteligentes, desde su inicio se hizo evidente la
imposibilidad de implementar algunas de sus características, tal como se describe
en detalle en §3.4.5. Ello no ha impedido, sin embargo, su masiva utilización en
industrias como la de la telefonía móvil.
La versión Java Card 2.1 fue lanzada en marzo de 1999 y consistía en tres
especificaciones: Java Card API, Java Card Runtime Environment y Java Card
Virtual Machine.
∙ Java Card API: define los paquetes Java tanto del núcleo como de las exten-
siones disponibles para las tarjetas inteligentes.
∙ Java Card Runtime Environment (Java Card RE): define el comportamiento
en tiempo de ejecución de los applets.
∙ Java Card Virtual Machine (JCVM): define un subconjunto del lenguaje Java
y una máquina virtual para las tarjetas inteligentes.
Aparte de mejorar las API existentes, la versión 2.1 definió explícitamente la

máquina virtual y el formato de applets de forma que su descarga fuera interoperable.
La versión 2.2 fue lanzada en septiembre de 2002, y entre sus novedades se

pueden citar las siguientes:
∙ Implementación de JCRMI (Java Card Remote Method Invocation).
∙ Soporte para cuatro canales lógicos.
∙ Mejoras en la gestión de los recursos de memoria.
∙ Inclusión de nuevas clases para algoritmos criptográficos (AES, claves para

algoritmos de curva elíptica, etc.).
En marzo de 2006 se anunció la disponibilidad de la revisión Java Card 2.2.2,

que incluyó las siguientes mejoras:
∙ Extensión del soporte de canales lógicos, permitiendo la gestión de hasta veinte

canales.
∙ Implementación de los algoritmos resumen (también llamados algoritmos hash

[78, 172]) SHA-256, SHA-384 y SHA-512.
∙ Inclusión de un paquete de extensión con clases relacionadas con la tecnología

de reconocimiento biométrico.
Finalmente, en marzo de 2008 se publicaron las especificaciones Java Card 3.0,

que a fin de adaptarse a las necesidades de los servicios actuales presenta dos edi-
ciones diferenciadas:
∙ Classic Edition: representa una evolución de Java Card 2.2.2, incluyendo no

sólo la corrección de errores detectados desde el lanzamiento de la anterior
versión, sino también nuevas características como la posibilidad de usar claves
RSA de 4096 bits o el soporte para claves y algoritmos descritos en la Suite B
de la NSA [194].
∙ Connected Edition: esta versión presenta un entorno de ejecución mejorado y

una nueva máquina virtual que proporciona características orientadas a red
como el soporte de aplicaciones web mediante servlets.
3.4.2. Java Card API

En este apartado se presenta de forma resumida la lista de API Java Card
disponibles para su utilización en la versión 3.0 Classic Edition:
3.4. Java Card 115
∙ java.lang
Este paquete representa el pilar fundamental del lenguaje Java, con sopor-
te para algunas de sus clases básicas. En Java Card, este paquete constituye
un subconjunto del paquete java.lang de Java Standard Edition, donde sólo
están permitidas algunas clases como Object (la raíz de todas las clases Ja-
va) o Throwable (la clase base para todas las excepciones), y dentro de ellas
únicamente se encuentran disponibles algunos métodos.
∙ java.io
Se trata de un subconjunto del paquete java.io de la edición Standard que
contiene como única clase java.io.IOException, la cual es la superclase de
java.rmi.RemoteException. Su presencia es necesaria para mantener una
jerarquía de excepciones idéntica a la de la versión Standard.
∙ java.rmi
Incluye las clases básicas para la funcionalidad JCRMI.
∙ javacard.framework
Representa el conjunto de clases e interfaces que conforman el núcleo de la
funcionalidad de un applet Java Card. Por ejemplo, incluye la clase Applet
que es básica para la ejecución e interacción de un applet con el JCRE, o
la clase APDU utilizada para la comunicación con la tarjeta inteligente con
independencia del protocolo físico empleado.
∙ javacard.framework.service
Proporciona un entorno de clases e interfaces que permiten a los applet Java
Card ser incluidos en un registro de manera que posteriormente se puedan re-
enviar las APDU entrantes a las aplicaciones registradas. También incluye una
interfaz que incluye métodos para procesar los comandos APDU de múltiples
servicios.
∙ javacard.security
Su diseño se basa en el paquete java.security de Java SE e incluye las clases
e interfaces que dan soporte a algunas de las funcionalidades criptográficas de
las tarjetas Java Card, por ejemplo las relacionadas con generación de números
aleatorios, resúmenes y firmas digitales.
∙ javacardx.apdu
Se trata del primer paquete de extensión del API Java Card. Los paquetes de
extensión son fácilmente identificables por comenzar siempre por el término
javacardx. En concreto, este API permite la comunicación con la tarjeta
mediante APDU según el formato definido en las normas ISO/IEC 7816.
∙ javacardx.biometry
Esta interfaz contiene la funcionalidad necesaria para implementar capacidades
biométricas en Java Card.
∙ javacardx.crypto
Se trata de un paquete de extensión que incluye las funcionalidades crip-
tográficas para el cifrado y descifrado de datos, funcionalidades que pue-
den estar sujetas a controles de exportación. Tanto este paquete como el
javacard.security definen las interfaces que los applet utilizarán, pero no
proporcionan ninguna implementación, que debe ser desarrollada por el pro-
veedor de la JCRE (quien, habitualmente es el propio fabricante de la tarjeta).
Los elementos fundamentales de este paquete son la clase Cipher, que propor-
ciona métodos para cifrar y descifrar mensajes, y la interfaz KeyEncryption
que define los métodos para permitir el acceso a la implementación de una
clave determinada.
∙ javacardx.external
Este paquete permite el acceso a subsistemas de memoria que no son directa-
mente gestionables por el entorno de ejecución de las tarjetas Java Card. Se
compone principalmente de la clase Memory y la interfaz MemoryAccess.
∙ javacardx.framework
Este paquete opcional incluye las clases e interfaces para la implementación
eficiente de applets Java. Si el paquete está presente, también deben estarlo
los subpaquetes math, tlv y util.
∙ javacardx.framework.math
Este paquete contiene funcionalidad común para la utilización de aritmética
BCD (Binary-Coded Decimal) y el cálculo de paridades.
∙ javacardx.framework.tlv
Paquete para la gestión de datos con formato BER TLV basados en las reglas
de codificación ASN.1 BER del estándar ISO/IEC 8825-1 [127], incluyendo la
edición y procesamiento de objetos BER TLV en los buffers de entrada/salida.
∙ javacardx.framework.util
Se trata de una API que contiene utilidades para la gestión de arrays de
componentes de tipo byte, short o int.
∙ javacardx.framework.util.intx
Este paquete incluye la clase JCint, equivalente en su definición a la clase
javacard.framework.Util, pero con el objetivo de utilizar datos de tipo int.
3.4. Java Card 117
3.4.3. Java Card Runtime Environment

La especificación Java Card Runtime Enviroment (JCRE) define el entorno de
ejecución de un dispositivo Java Card. Una implementación del JCRE debe pro-
porcionar una implementación de la máquina virtual (JCVM), de las interfaces de
programación (JC API) y de cualquier otro elemento relacionado con la tecnología
Java Card y recogido en sus especificaciones. Sun Microsystems proporciona una
implementación de referencia de estos elementos, aunque cada fabricante de tarjetas
inteligentes normalmente desarrolla su propia implementación.
JCRE define claramente el ciclo de vida tanto de la Java Card VM como de las
aplicaciones, el modo de selección de los applets y el mecanismo de compartición de
objetos. JCRE proporciona una interfaz independiente del proveedor de la tarjeta
inteligente para los servicios que deben ejecutarse en ella.
La Figura 3.3 muestra de forma esquemática la arquitectura Java Card con los
diferentes niveles lógicos existentes, desde el sistema operativo de la tarjeta hasta
las aplicaciones de usuario o applets.
Figura 3.3: Arquitectura Java Card y de su entorno de ejecución
3.4.3.1. Ciclo de vida de la máquina virtual Java Card
El ciclo de vida de la máquina virtual Java Card coincide con el de la propia

tarjeta: comienza una vez la tarjeta inteligente ha sido creada y probada (aunque
antes de que sea entregada a su propietario final) y termina cuando la tarjeta es
descartada o destruida. La JCVM no se ve afectada cuando se retira la alimentación
a la tarjeta, puesto que su estado se almacena en memoria no volátil (al contrario

de lo que ocurre con los datos almacenados en la RAM, que sí se pierden cuando no
existe alimentación). Una vez la JCVM comienza su ejecución, inicializa el JCRE
y crea todos los objetos del entorno que estarán disponibles a lo largo de la vida
útil de la tarjeta. Tras su inicio, las interacciones con la tarjeta son controladas por
alguno de los applets que residen en ella.
3.4.3.2. Ciclo de vida de un applet Java Card
Cada applet que pueda residir en una tarjeta Java Card queda unívocamente
identificado por su Application ID (AID). Tal como queda definido en la norma
ISO/IEC 7816-5 [117], un AID es una secuencia de entre 5 y 16 bytes que sirve para
la selección directa de aplicaciones.
Para adaptarse a las especificaciones Java Card, todos los applets deben exten-
der la clase abstracta Applet, que define los métodos utilizados por el JCRE para
controlar el ciclo de vida de un applet, tal como puede apreciarse en la Figura 3.4.
Figura 3.4: Métodos para la gestión del ciclo de vida de un applet Java Card
El ciclo de vida de un applet comienza cuando es descargado en una tarjeta y

el JCRE invoca el método estático Applet.install(), tras lo cual se produce el
registro efectivo mediante el método Applet.register(). Una vez el applet está
instalado y registrado, permanece en estado inactivo hasta que es seleccionado a
través del método Applet.select(). A partir de la selección del applet, el JCRE
se encarga de recibir las APDU enviadas por la aplicación externa a través del
lector de tarjetas y entregarlas al applet activo. La Figura 3.5 muestra de forma
global el intercambio de comandos entre la aplicación externa, el JCRE y el applet
seleccionado, para lo cual el JCRE utiliza el método Applet.process(). En cuanto
a las posibles excepciones que puedan generarse durante la ejecución, y que no
sean gestionadas por el propio applet, el JCRE se encarga de atraparlas e informar
debidamente a la aplicación externa.
3.4. Java Card 119
Figura 3.5: Métodos implicados en la gestión de un applet
Al finalizar su ciclo de vida, el JCRE notifica al applet que ha sido deseleccionado

invocando el método Applet.deselect(), que típicamente incluye la lógica para
almacenar los datos que todavía se encontraran en la memoria RAM y devolver el
applet a su estado inactivo.
3.4.3.3. Sesiones Java Card y canales lógicos
Java Card utiliza el concepto de canal lógico para permitir varias sesiones simul-
táneas, con un límite fijo de una sesión por canal lógico. Puesto que el procesamiento
de una APDU no puede ser interrumpido, y cada APDU contiene en su byte CLA
una referencia al canal lógico a utilizar, sucesivas APDU pueden comunicarse con
un número distinto de applets, permitiendo la ilusión de la ejecución simultánea de
distintos applets, cuando en realidad en un momento dado sólo un applet está siendo
ejecutado.
El número de canales lógicos soportados en Java Card ha aumentado con el paso
del tiempo. Mientras que en las versiones Java Card 2.1.x los comandos sólo podían
ser procesados por un único applet, Java Card 2.2 y 2.2.1 permitían utilizar un
máximo de cuatro canales lógicos, número que se ha incrementado hasta veinte en
Java Card 2.2.2 y se ha mantenido en Java Card 3.0.
Algunas tarjetas Java Card permiten que exista un applet que sea seleccionado
de forma automática a través del canal 0 cada vez que la tarjeta recibe alimentación.
Éste es el caso de las tarjetas Java Card utilizadas en telefonía móvil, donde la apli-
cación SIM es seleccionada automáticamente, de manera que los teléfonos móviles
no necesitan realizar la selección de dicha aplicación. La documentación, sin embar-
go, no detalla cómo especificar estos applets por defecto, por lo que los mecanismos
utilizados hasta el momento se basan en procedimientos propietarios dependientes
de cada fabricante.
3.4.3.4. Aislamiento de applets y compartición de objetos
La plataforma Java Card es un entorno multiaplicación seguro, lo que significa

que applets de diferentes vendedores pueden coexistir de forma segura en la misma
tarjeta. Para ello, a cada applet se le asigna un contexto de ejecución que controla
el acceso a los objetos asociados a ese contexto. El límite entre un contexto de
ejecución y otro es lo que se suele denominar cortafuegos (firewall ). El cortafuegos
es la mejora de Java Card al concepto genérico de separación de programas en
ejecución denominado sandbox utilizado por Java SE, y combina las funcionalidades
de carga de clases y su control de acceso. El cortafuegos de Java Card crea una
porción de memoria virtual de manera que, por defecto, un objeto puede acceder
únicamente a métodos y datos públicos de aquellos objetos que residan dentro del
área delimitada por dicho cortafuegos.
Para los casos en que sea necesaria una gestión más avanzada, Java Card permite
la compartición de objetos a través del cortafuegos. Para ello, es necesario definir en
relación a cada objeto a compartir su contexto de ejecución. La Figura 3.6 muestra
estos conceptos, siendo el flujo típico el siguiente:
Figura 3.6: Compartición de objetos en Java Card
1. El applet a solicita acceso a la interfaz compartida del applet c mediante una

llamada al método JCSystem.getAppletShareableInterfaceObject().
2. El entorno de ejecución JCRE solicita entonces al applet c su interfaz compar-
tida invocando el método getShareableInterfaceObject() en nombre del
applet a.
3.4. Java Card 121
3. Si el applet c permite la compartición, el applet a obtendrá una referencia

a los objetos compartidos del applet c, que podrá utilizar a partir de dicho
momento.
En comparación, puesto que los applets a y b están en el mismo contexto de

ejecución, no necesitan realizar la operativa anterior para compartir objetos.
3.4.4. Java Card VM
Tal como se ha comentado anteriormente, la especificación de la JCVM define

un subconjunto del lenguaje de programación Java y una máquina virtual adaptada
a las tarjetas inteligentes, lo que incluye entre otros elementos la representación
de datos binarios, el formato de ficheros y el conjunto de instrucciones que son
interpretadas por la máquina virtual.
Por definición, la máquina virtual Java Card está dividida en dos partes: una
externa a la tarjeta y otra que se ejecuta en la propia tarjeta. La máquina virtual
incluida en la tarjeta interpreta el bytecode y gestiona las clases y los objetos. La
parte externa de la máquina virtual, en comparación, carga, verifica y prepara las
clases Java para su ejecución posterior en la tarjeta. A un mayor nivel de detalle, la
parte externa (también denominada herramienta de conversión) toma como datos
de entrada las clases Java Card y produce un fichero de extensión CAP (Converted
Applet) que contiene todas las clases agrupadas una vez han sido comprobadas, a
fin de verificar que su contenido se adapta a la especificación Java Card.
La Figura 3.7 muestra un esquema básico del proceso de conversión de ficheros
de tipo class a ficheros CAP.
Figura 3.7: Esquema de conversión a ficheros CAP

3.4.5. Limitaciones del lenguaje Java Card

En comparación con las características del lenguaje disponible en la versión
Java SE, Java Card presenta algunas limitaciones debido a los escasos recursos
disponibles en las tarjetas inteligentes. Los siguientes puntos describen algunas de
estas limitaciones.
∙ Términos y tipos no soportados

Los términos native, synchronized, transient, volatile, strictfp, enum
y assert hacen referencia a métodos nativos, ejecución multihilo, datos en for-
mato de coma flotante, gestión de memoria y depuración de fallos (debugging),
los cuales no están soportados.
Por otra parte, Java Card no soporta los tipos de datos básicos char, double,
float y long, ni los objetos de tipo String. Tampoco permite utilizar matrices
de más de una dimensión.
∙ Carga dinámica de clases

Java Card no permite la carga dinámica de clases, por lo que los applets que se
ejecutan en la tarjeta sólo pueden hacer referencia a clases que ya estuvieran
presentes en la tarjeta antes del inicio de la ejecución del applet.
∙ Ejecución multihilo
A diferencia de Java SE, Java Card no permite múltiples hilos de ejecución.
Por dicho motivo, los applets Java Card no pueden utilizar la clase Thread ni
ninguno de los términos relacionados con la ejecución multihilo.
∙ Clonado
Java Card no permite el clonado de objetos, por lo que la clase Object no
implementa el método clone, ni proporciona un interfaz Cloneable que pueda
ser utilizado por las aplicaciones.
∙ Máximas longitudes asociadas a paquetes, clases y métodos

Un paquete en Java Card puede hacer referencia como mucho a otros 128
paquetes, y su nombre puede contener como máximo 255 caracteres que en
formato UTF-8 (Unicode Transformation Format 8-Bit) utilicen un byte por
carácter. Una clase puede implementar hasta 15 interfaces diferentes, incluyen-
do las interfaces implementadas por superclases. A su vez, una interfaz puede
heredar como máximo de 14 superinterfaces. Además, una clase puede imple-
mentar un máximo de 128 métodos de instancia, ya sean públicos o protegidos.
Este límite incluye los métodos heredados. Por último, el número máximo de
variables que pueden ser utilizados en un método es de 255.
3.4. Java Card 123
3.4.6. Características criptográficas en Java Card

De forma equivalente a la situación en Java SE, las API criptográficas de Java
Card definen una serie de servicios criptográficos y las interfaces para acceder a
dichos servicios, lo cual en la práctica permite la separación de interfaces e imple-
mentaciones. Por ofrecer un ejemplo sencillo, para proporcionar la funcionalidad de
resúmenes mediante el algoritmo MD5, un proveedor JCRE puede crear una imple-
mentación de la clase MessageDigestMD5 que extienda la clase MessageDigest. De
esta forma, la clase MessageDigestMD5 impondría sus métodos frente a los de la
clase base en lo que respecta a la implementación del algoritmo MD5.
Entrando en detalle, las API criptográficas de Java Card replican el compor-
tamiento de las API de Java SE, de manera que la funcionalidad se divide en los
paquetes javacard.security y javacardx.crypto, dependiendo de si la funciona-
lidad a ofrecer contuviera en el momento de su diseño limitaciones para su exporta-
ción. En los siguientes apartados se detallan las principales características de ambos
paquetes.
3.4.6.1. javacard.security
El paquete javacard.security contiene varias interfaces para implementar cla-

ves simétricas y asimétricas, la clase generadora de claves (key builder ), las clases
para realizar autenticaciones de resúmenes de mensajes y firmas digitales, así co-
mo la clase utilizada en la generación de datos aleatorios (los cuales son produ-
cidos en la forma de arrays de tipo byte de longitud variable y definible en la
llamada al método). El Cuadro 3.1 detalla todas las clases e interfaces del paquete
javacard.security disponibles en Java Card 3.0 Classic Edition.
Clase o interfaz Descripción

AESKey Representa una clave AES de 128, 192 ó 256 bits
Checksum Clase abstracta base para algoritmos de checksum
CryptoException Excepción de tipo criptográfico
DESKey Representa una clave DES simple de 64 bits, una
clave para TDES de 128 bits con dos claves sim-
ples o una clave TDES de 192 bits con tres claves
simples
DSAKey Interfaz base para implementaciones de claves pú-
blicas y privadas utilizadas por el algoritmo DSA
DSAPrivateKey Utilizada para firmar datos con el algoritmo DSA
DSAPublicKey Utilizada para verificar firmas digitales empleando
el algoritmo DSA

ECKey Interfaz base para implementaciones de claves pú-
blicas y privadas para curvas elípticas definidas so-
bre cuerpos primos y binarios
ECPrivateKey Utilizada para firmar datos con ECDSA y generar
secretos compartidos con ECDH
ECPublicKey Utilizada para verificar firmas digitales mediante
el algoritmo ECDSA y para generar secretos com-
partidos con ECDH
HMACKey Interfaz que define una clave para operaciones
HMAC
InitializedMessageDigest Genera un resumen a partir de un mensaje, pero
permitiendo definir un valor de resumen inicial que
se correspondería con una parte del mensaje de la
que ya se hubiera obtenido previamente su valor
Key Interfaz base para todas las claves
KeyAgreement Clase abstracta base para la implementación de al-
goritmos de acuerdo de clave como Diffie-Hellman
y ECDH
KeyBuilder Clase utilizada para generar un objeto de tipo cla-
ve
KeyPair Contenedor para un par de claves (una pública y
otra privada)
KoreanSEEDKey Clave de 128 bits para operaciones con el algoritmo
Korean Seed
MessageDigest Clase abstracta base para algoritmos resumen
PrivateKey Interfaz base para claves privadas de algoritmos
asimétricos
PublicKey Interfaz base para claves públicas de algoritmos
asimétricos
RandomData Clase abstracta base para la generación de datos
aleatorios
RSAPrivateCrtKey Interfaz de una clave privada RSA con el formato
CRT (Chinese Remainder Theorem)
RSAPrivateKey Interfaz de una clave privada RSA con el formato
módulo/exponente
RSAPublicKey Interfaz de una clave pública RSA
SecretKey Interfaz base para todas las claves de algoritmos
simétricos
Signature Clase abstracta base para algoritmos de firma di-
gital
3.4. Java Card 125

SignatureMessageRecovery Interfaz para operaciones de firma con recupera-
ción de mensaje
Cuadro 3.1: Clases e interfaces del paquete javacard.security
3.4.6.2. javacardx.crypto
El paquete javacardx.crypto es una API de extensión que contiene la clase

cipher, la cual permite el uso de algoritmos de cifrado, y la interfaz KeyEncrypt,
que permite implementar claves de cifrado. El Cuadro 3.2 muestra las clases del
paquete javacardx.crypto.

Cipher Clase abstracta base que proporciona la funcionalidad
para cifrado y descifrado de datos
KeyEncryption Permite implementar claves para acceder a datos cifra-
dos
Cuadro 3.2: Clases e interfaces del paquete javacardx.crypto
3.4.6.3. ECC en Java Card
Java Card 2.2 fue la primera versión en incluir soporte para criptografía de curva
elíptica. En concreto, en dicha versión se definieron los siguientes elementos:
∙ Nuevas clases ECKey, ECPrivateKey y ECPublicKey para la creación y gestión

de claves ECC públicas y privadas sobre cuerpos primos y binarios.
∙ Extensión de la clase KeyPair para permitir la manipulación de pares de claves

sobre cuerpos 𝔽𝑝 y 𝔽2𝑚 .
∙ Extensión de la clase KeyAgreement con las funciones de acuerdo de clave DH

(Diffie-Hellman) y DHC (Diffie-Hellman with Cofactor), con la peculiaridad
de que la salida de esas funciones no es la primera coordenada del elemento
secreto compartido, sino el resultado de pasar este dato a través de la función
SHA-1.
∙ Extensión de la clase KeyBuilder, que define las longitudes de clave permitidas

para ECC y otros criptosistemas. En el caso de curvas elípticas sobre cuerpos
primos, las longitudes válidas en Java Card 2.2 son 112, 128, 160 y 192 bits,
mientras que en el caso de curvas sobre cuerpos binarios, las longitudes posibles
son 113, 131, 163 y 193 bits.
∙ Extensión de la clase Signature con la implementación del esquema de firma

digital ECDSA utilizando la función resumen SHA-1.
Las versiones Java Card 2.2.1 y 2.2.2 no introdujeron ninguna novedad en re-
lación a la criptografía de curvas elípticas. En cambio, la versión Java Card 3.0 sí
presenta algunas novedades en cuanto al soporte ECC, tal como se detalla a conti-
nuación:
∙ Mientras que las longitudes permitidas para los cuerpos binarios continúan
siendo 113, 131, 163 y 193 bits, en los cuerpos primos es posible elegir como
longitud 112, 128, 160, 192, 224, 256 y 384 bits.
∙ La implementación de las funciones de acuerdo de clave DH y DHC se ha

extendido para incluir un modo especial en el que la salida de la función es
directamente el elemento secreto compartido, eliminando la utilización de la
función SHA-1 en la generación de ese dato.
∙ Debido a la disponibilidad en Java Card de la familia de funciones resumen

SHA-2, la implementación del esquema de firma digital ECDSA permite a
partir de la versión Java Card 3.0 utilizar ECDSA en combinación con las
funciones SHA-1, SHA-224, SHA-256, SHA-384 y SHA-512.
3.5. Programación en Java Card

El desarrollo de una aplicación Java Card conlleva los siguientes pasos:
1. Escribir el código Java de la aplicación en ficheros con extensión .java.
2. Compilar el código para obtener ficheros con extensión .class.
3. Convertir los ficheros .class en un fichero CAP.
4. Verificar que el fichero .cap es válido.
5. Instalar el fichero CAP en la tarjeta.
La principal diferencia respecto al desarrollo de aplicaciones Java SE consiste en

la necesidad de convertir los ficheros .class en ficheros .cap. Este paso se realiza fuera
de la tarjeta inteligente y permite optimizar el tamaño de la aplicación. Los ficheros
CAP son en realidad contenedores con formato JAR (que a su vez son una extensión
del formato de compresión ZIP) donde se almacenan los paquetes convertidos. Junto
con el fichero .cap, la herramienta de conversión de Java Card genera un fichero de
3.5. Programación en Java Card 127
Figura 3.8: Fases del desarrollo de un applet Java Card
exportación con extensión .exp que contiene información sobre la interfaz pública
de todas las clases del paquete.
La Figura 3.8 muestra de forma gráfica el proceso completo de desarrollo de un
applet Java Card.
Capítulo 4
Estudio y análisis del esquema de

cifrado ECIES
En este capítulo se describen de forma completa las distintas variantes de

ECIES incluidas en los estándares ANSI X9.63, IEEE 1363a, ISO/IEC
18033-2 y SECG SEC 1, identificando las principales diferencias exis-
tentes entre los cuatro estándares mencionados. De forma adicional, se
incluye un análisis de la seguridad de ECIES que recoge las indicacio-
nes y recomendaciones sugeridas en los estudios más recientes sobre este
tema.
4.1. Criptosistemas de curvas elípticas

Los primeros esquemas de cifrado basados en curvas elípticas que surgieron fue-
ron el equivalente de los sistemas Massey-Omura [205] (que a su vez es una mejora
del three-pass protocol de Shamir, que nunca fue publicado debido a que no era segu-
ro) y ElGamal [69], ambos presentados por Koblitz en 1985 (y publicados en 1987)
[147], y el Menezes-Vanstone Elliptic Curve Cryptosystem [169].
El Algoritmo 4.1 describe el protocolo de Massey-Omura por el que el usuario U
procede al envío de un cierto mensaje 𝔪 al usuario V, donde 𝐸 es una curva elíptica
definida sobre el cuerpo finito de 𝑞 elementos 𝔽𝑞 y existe una relación públicamente
conocida de mensajes en claro 𝔪 y puntos de la curva 𝑃𝔪 .
129
130 4. Estudio y análisis del esquema de cifrado ECIES
Algoritmo 4.1 Criptosistema Massey-Omura con curvas elípticas

1. U debe generar un número entero aleatorio 𝑐, con 0 < 𝑐 < #𝐸, siendo 𝑐 y
el orden de la curva #𝐸 primos relativos, y transmitir el punto de la curva
calculado como 𝑐 𝑃𝔪 a V.
2. A continuación, V debe generar un número entero aleatorio 𝑑 (donde igual-

mente 0 < 𝑑 < #𝐸 y los valores 𝑑 y #𝐸 son primos relativos), y transmitir
el punto de la curva 𝑑 𝑐 𝑃𝔪 a U.
3. Tras su recepción, U transmitirá de vuelta a V el punto de la curva

𝑐′ 𝑑 𝑐 𝑃𝔪 = 𝑑 𝑃𝔪 , puesto que 𝑐′ 𝑐 ≡ 1 (mod #𝐸).
4. Por último, el usuario V obtendrá el punto de la curva curva 𝑃𝔪 asociado

al mensaje 𝔪 calculando 𝑑′ 𝑑 𝑃𝔪 , ya que 𝑑′ 𝑑 ≡ 1 (mod #𝐸).
De forma equivalente, dada una curva 𝐸, un generador 𝐺 y una relación pública-

mente conocida de mensajes en claro y puntos de la curva, el Algoritmo 4.2 muestra
los pasos necesarios para que el usuario U envíe el mensaje 𝔪 cifrado al usuario V
utilizando la versión del esquema de ElGamal con curvas elípticas.
Algoritmo 4.2 Criptosistema ElGamal con curvas elípticas

1. V debe elegir aleatoriamente un valor 𝑣 y hacer pública su clave 𝑉 = 𝑣 𝐺.
2. A partir del mensaje 𝔪 y del punto de la curva 𝑃𝔪 que le corresponda, el

usuario U debe generar aleatoriamente un valor 𝑘 y enviar el par de puntos
(𝑘 𝐺, 𝑃𝔪 + 𝑘 𝑉 ) a V.
3. Tras la recepción del par de puntos, el usuario V recuperará el punto de la

curva que representa el mensaje en claro multiplicando el punto 𝑘 𝐺 por el
valor 𝑣, con lo que obtendrá 𝑣(𝑘 𝐺) = 𝑘(𝑣 𝐺) = 𝑘 𝑉 , y restando a continua-
ción el punto así generado de 𝑃𝔪 + 𝑘 𝑉 .
Una de las principales desventajas de los esquemas anteriores consiste en el

limitado número de mensajes a cifrar, siendo necesario establecer una relación entre
cada mensaje y un punto de la curva elíptica. Si bien es cierto que si se utilizan
curvas elípticas cuyo orden #𝐸 es un valor elevado esta limitación es más teórica
que práctica, la obligatoriedad de construir tablas donde se relacionen cada uno de
los posibles mensajes (y que estos sean previamente conocidos) limita la utilidad
de estos criptosistemas a entornos cerrados donde todos los posibles mensajes estén
estipulados (empresas, pequeños grupos de usuarios, etc.).
El criptosistema Menezes-Vanstone con curvas elíptica fue diseñado precisamen-
te para solventar esa limitación, puesto que en lugar de hacer corresponder cada
mensaje con un punto de la curva 𝐸, representaban los mensajes en claro como
4.1. Criptosistemas de curvas elípticas 131
pares ordenados del producto cartesiano 𝔽∗𝑞 × 𝔽∗𝑞 , donde 𝔽∗𝑞 = 𝔽𝑞 ∖ {0} (los pares
ordenados no tienen que ser necesariamente puntos de la curva). De esta manera, era
posible dividir cualquier mensaje en claro en bloques, donde cada bloque pudiera ser
codificado fácilmente en un par ordenado (por ejemplo, utilizando una codificación
similar a la empleada en los ejemplos de §2.4.2.2 y §2.4.3.2). Como contraparti-
da negativa, en lugar de transformar cada mensaje en un único punto de la curva
(independientemente de cuál fuera el mensaje, como ocurría con las versiones de
Massey-Omura y ElGamal), la longitud del mensaje cifrado depende de la longitud
del mensaje en claro.
El Algoritmo 4.3 muestra de forma resumida los pasos necesarios para completar
los procesos de cifrado y descifrado de un mensaje representado como el elemento
𝑥 = (𝑥1 , 𝑥2 ) ∈ 𝔽∗𝑞 × 𝔽∗𝑞 utilizando el criptosistema Menezes-Vanstone con curvas
elípticas. En la notación empleada, el punto 𝐺 tiene orden 𝑛 y es un generador de
un subgrupo cíclico de 𝐸, mientras que como es habitual 𝑣 y 𝑉 = 𝑣 𝐺 representan
respectivamente la clave privada y pública del usuario V.
Algoritmo 4.3 Criptosistema Menezes-Vanstone con curvas elípticas

1. U debe elegir aleatoriamente un valor 𝑘 ∈ {1, . . . , 𝑛 − 1} y calcular los
valores 𝑌0 = 𝑘 𝐺 ∈ 𝐸, 𝑦1 = 𝑐1 𝑥1 (mod 𝑝) y 𝑦2 = 𝑐2 𝑥2 (mod 𝑝), donde el
elemento (𝑐1 , 𝑐2 ) = 𝑘 𝑉 .
2. A continuación, U enviará el criptograma 𝒞 = (𝑌0 , 𝑦1 , 𝑦2 ) a V.
3. Tras la recepción del criptograma, el usuario V recuperará el par or-

denado 𝑥 = (𝑥1 , 𝑥2 ) mediante las operaciones 𝑥1 = 𝑦1 𝑐−1
1 (mod 𝑞) y
−1
𝑥2 = 𝑦2 𝑐2 (mod 𝑞), donde 𝑣 𝑌0 = (𝑐1 , 𝑐2 ).
En este esquema, el factor de expansión es 2, puesto que a partir del mensaje

en claro 𝑥 = (𝑥1 , 𝑥2 ), compuesto por dos elementos del cuerpo finito 𝔽∗𝑞 , se obtiene
el criptograma (𝑌0 , 𝑦1 , 𝑦2 ), donde 𝑦1 , 𝑦2 ∈ 𝔽∗𝑞 e 𝑌0 ∈ 𝐸 (y por lo tanto tiene dos
coordenadas que pertenecen al cuerpo primo que define la curva), con lo que el
número total de elementos del cuerpo finito a transmitir es 4. Si se utiliza compresión
de puntos (ver §2.6.5), entonces el factor de expansión se reduce prácticamente a
1.5, puesto que además de la primera coordenada del punto es necesario enviar un
byte que incluye la información necesaria para recuperar la segunda coordenada.
En comparación, el factor de expansión de la variante de ElGamal con curvas
elípticas es 2 si se considera que el mensaje en claro es un punto de la curva, mientras
que si se interpreta que el número total de mensajes es #𝐸(𝔽𝑞 ) ≈ 𝑞, entonces el
factor de expansión sería aproximadamente 4 [218]. El hecho de tener un factor de
expansión igual a 2 conlleva que el cifrado de volúmenes de información elevados
genere criptogramas de tamaño mucho mayor que utilizando un algoritmo de clave
simétrica como por ejemplo AES.
Otra desventaja derivada del diseño del criptosistema consiste en la realización

de operaciones con los puntos de las curvas elípticas en cada proceso de cifrado. Al
ser necesario dividir los mensajes en claro de gran tamaño en múltiples segmentos
y realizar un operación de cifrado asimétrico con cada uno de ellos, la diferencia
en tiempo de ejecución del esquema Menezes-Vanstone respecto a un algoritmo de
cifrado simétrico se incrementa conforme aumenta el número de segmentos a cifrar.
De manera adicional a las desventajas de carácter práctico señaladas, Klaus
Kiefer demostró en 1998 que, bajo ciertas condiciones, este criptosistema es inseguro
[146]. Kiefer demostró además que, en contra de lo estipulado en su especificación,
este criptosistema no puede ser considerado un algoritmo de cifrado probabilístico.
Debido a todas las razones comentadas, con el paso de los años la comunidad
académica ha ido abandonando el estudio de los tres criptosistemas citados ante-
riormente en este apartado. Como ejemplo ilustrativo, mientras que en la primera
edición de la obra de Douglas Stinson [257] se incluían la versión con curvas elíp-
ticas del esquema de ElGamal y el criptosistema Menezes-Vanstone, a partir de su
segunda edición esos esquemas fueron reemplazados por ECIES. Incluso en uno de
los últimos libros sobre curvas elípticas en el que ha participado Alfred Menezes [99],
no se incluye el esquema Menezes-Vanstone.
Afortunadamente, el descubrimiento de las limitaciones de esos criptosistemas no
significó el abandono de la búsqueda de un criptosistema de curvas elípticas que fuera
práctico y seguro, sino que únicamente provocó un cambio de dirección, pasando a
ocupar el centro de atención los esquemas de cifrado híbridos (descritos en §2.5).
Los principales esquemas híbridos que emplean curvas elípticas son ECIES, PSEC
(Provably Secure Elliptic Curve encryption scheme) [199, 243] y ACE (Advanced
Cryptographic Engine) [55, 243].
De los tres esquemas, ECIES es el que está presente en un mayor número de
estándares (ANSI X9.63 [16], IEEE 1363a [109], ISO/IEC 18033-2 [136] y SECG
SEC 1 [254]). Por su parte, PSEC se puede encontrar en ISO/IEC 18033-2 [136],
IETF RFC 4051 [68] y en el conjunto de algoritmos seleccionados por el proyecto
NESSIE (New European Schemes for Signatures, Integrity and Encryption) [195,
196], mientras que ACE está presente en ISO/IEC 18033-2 [136] y en la selección
final de NESSIE [195, 196].
Aunque a lo largo de los apartados restantes de este capítulo se describe en de-
talle la funcionalidad de ECIES, a fin de explicar los motivos por los que se decidió
implementar ese esquema en lugar de PSEC y ACE se ha incluido a continuación un
resumen comparativo del proceso de cifrado de los tres esquemas en el Cuadro 4.1,
utilizando una notación equivalente a fin de resaltar las semejanzas entre ellos. Aun-
que en realidad tanto ISO/IEC18033-2 como los documentos de NESSIE describen
el funcionamiento de la fase KEM de los tres esquemas (ECIES-KEM, PSEC-KEM
y ACE-KEM), en el siguiente cuadro se ha añadido la fase DEM (utilizando como
ejemplo la función DEM1 de [136]) a fin de presentar el proceso completo de cifrado
en los tres esquemas.
ECIES PSEC ACE

𝑢 ∈ [1, 𝑛 − 1] 𝑟 ∈ {0, 1}𝑙 𝑢 ∈ [1, 𝑛 − 1]
𝑈 = 𝑢𝐺 𝐾 = KDF (032 ∣∣𝑟) 𝑈 = 𝑢𝐺
𝑃 = 𝑢𝑉 𝐾 = 𝑡∣∣𝑘1 ∣∣𝑘2 𝑃 = 𝑢𝑊
𝑃 = (𝑥𝑃 , 𝑦𝑃 ) 𝑢 = 𝑡 (mod 𝑛) 𝑃′ = 𝑢𝑍
𝐾 =KDF (𝑈 ∣∣𝑥𝑃 ) 𝑈 = 𝑢𝐺 𝑃 = (𝑥𝑃 ′ , 𝑦𝑃 ′ )
𝐾 = 𝑘1 ∣∣𝑘2 ⊕ = 𝑢𝑉
𝑃 𝛼 = 𝐻(𝑈 ∣∣𝑃 )
′
𝔠 =ENC 𝑘1 (𝔪) 𝑠 = 𝑟 KDF (132 ∣∣𝑈 ∣∣𝑃 ) 𝑢 = 𝛼 𝑢 (mod 𝑛)
tag=MAC𝑘2 (𝔠) 𝔠 =ENC 𝑘1 (𝔪) 𝑄 = 𝑢 𝑋 + 𝑢′ 𝑌
𝒞 =(𝑈, 𝔠,tag) tag=MAC𝑘2 (𝔠) 𝐾 =KDF (𝑈 ∣∣𝑥𝑃 ′ )
𝒞 =(𝑈, 𝔠, 𝑠,tag) 𝐾 = 𝑘1 ∣∣𝑘2
𝔠 =ENC 𝑘1 (𝔪)
tag=MAC𝑘2 (𝔠)
𝒞 =(𝑈, 𝑃, 𝑄, 𝔠,tag)
Cuadro 4.1: Comparativa del proceso de cifrado en ECIES, PSEC y ACE
El significado de los elementos incluidos en el Cuadro 4.1 es el siguiente:
∙ 𝐺: generador del subgrupo cíclico del grupo de puntos de la curva elíptica

utilizada en los cálculos.
∙ 𝑛: orden del punto 𝐺.
∙ 𝑢: clave privada temporal del usuario U que envía el criptograma.
∙ 𝑈 : clave pública temporal de U, de manera que 𝑈 = 𝑢 𝐺.
∙ 𝑣: clave privada permanente del usuario V que recibe el criptograma.
∙ 𝑉 : clave pública permanente de V. En ECIES y PSEC, 𝑉 = 𝑣 𝐺, mientras
que en ACE la clave pública está compuesta por cuatro puntos de la curva, de
manera que 𝑉 = (𝑊, 𝑋, 𝑌, 𝑍).
∙ 𝑟: cadena binaria aleatoria cuya longitud 𝑙 está prefijada.
∙ 032 : cadena binaria de 32 bits que representa el número entero 0.
∙ 132 : cadena binaria de 32 bits que representa el número entero 1.
∙ 𝑡: cadena binaria de (𝜆 + 128) bits que debe interpretarse como un número
entero, donde 𝜆 es un parámetro de seguridad que toma el valor de la longitud
en bits asociada al cuerpo finito sobre el que se construye la curva elíptica (es
decir, el valor ⌈log2 𝑝⌉ o 𝑚, según el tipo de cuerpo finito).
Como puede apreciarse en el Cuadro 4.1, las principales diferencias entre los
esquemas ECIES, PSEC y ACE son las siguientes:
∙ Tanto en ECIES como en PSEC, la clave pública del receptor del criptograma
es el punto de la curva 𝑉 = 𝑣 𝐺, mientras que en ACE la clave pública está
formada por cuatro puntos, de manera que 𝑉 = (𝑊, 𝑋, 𝑌, 𝑍).
∙ PSEC utiliza dos veces la función KDF, mientras que ECIES y ACE sólo la
utilizan una vez.
∙ ECIES y ACE utilizan la primera coordenada de un punto de la curva gene-

rado durante los cálculos intermedios (en lugar de las dos coordenadas) como
parámetro de entrada de la función KDF, mientras que en PSEC es obligatorio
utilizar las dos coordenadas.
∙ PSEC es el único esquema que utiliza la función XOR durante el proceso

de generación de claves (independientemente de su posible utilización como
función de cifrado simétrico).
∙ Los criptogramas de ECIES están formados por tres elementos (el punto 𝑈 , el
mensaje cifrado 𝔠 y la etiqueta tag), mientras que los criptogramas de PSEC
añaden además el elemento 𝑠 y los de ACE incluyen dos puntos de la curva
elíptica (𝑃 y 𝑄).
Una vez presentado el esquema general del proceso de cifrado de los tres esque-
mas, y con el fin de seleccionar el más adecuado, es necesario evaluar tres aspectos
fundamentales: eficiencia, seguridad y adaptabilidad a las plataformas hardware de
trabajo.
Respecto al análisis de su eficiencia, los siguientes cuadros muestran datos to-
mados de [196]. En concreto, el Cuadro 4.2 muestra una comparativa del número de
operaciones necesarias para llevar a cabo el proceso de cifrado en los tres esquemas.
En él se puede comprobar que ECIES es el esquema que, de forma global, utiliza
menos operaciones.
ECIES PSEC ACE

Producto escalar 2 2 5
Suma de puntos 0 0 1
Generación de números aleatorios 1 1 1
Llamadas a función KDF 1 2 1
Llamadas a función H 0 1 1
Llamadas a función MAC 1 1 1
Llamadas a función resumen 1 1 1
Cuadro 4.2: Número de operaciones para el cifrado en ECIES, PSEC y ACE
Por su parte, el Cuadro 4.3 presenta el número de ciclos de reloj y el tiempo de

procesado de la operación de cifrado para los tres esquemas utilizando en todos los
casos el mismo PC equipado con un procesador Pentium III con una frecuencia de
reloj de 500 MHz [196].
ECIES PSEC ACE

Ciclos de reloj (miles) 2500 2500 6250
Tiempo (milisegundos) 5 5 12.5
Cuadro 4.3: Rendimiento del cifrado en ECIES, PSEC y ACE
Otro de los aspectos a tener en cuenta para evaluar la eficiencia de los tres es-
quemas de cifrado es su factor de expansión. El Cuadro 4.4 muestra las longitudes
en bytes de las claves públicas y privadas, así como del criptograma generado, con-
siderando que la longitud de los elementos del cuerpo, del mensaje a cifrar y de la
salida de la función resumen son, respectivamente, 20, 16 y 20 bytes, y habiendo
sido utilizada la técnica de compresión de puntos en la representación binaria de los
puntos de la curva.
ECIES PSEC ACE

Clave privada 20 20 80
Clave pública 20 20 80
Criptograma 36 52 76
Cuadro 4.4: Comparativa de longitudes en bytes para ECIES, PSEC y ACE
La seguridad comparada de los tres esquemas candidatos es un tema sobre el que

no existe acuerdo en la comunidad académica. El informe final del proyecto NESSIE
seleccionó los esquemas PSEC y ACE, dejando fuera de la selección a ECIES. Ello
se debió, entre otros factores, a que ECIES no es seguro en el sentido IND-ACCA
(maleabilidad benigna) y que se trata de un esquema KEM no autenticado (es decir,
no comprueba si el elemento 𝑃 = 𝑢 𝑉 utilizado durante los cálculos es correcto en
función de los demás parámetros del criptograma), mientras que en comparación
PSEC y ACE son esquemas KEM autenticados y seguros en el modelo IND-ACCA.
Sin embargo, tal como se describe en §4.9 (donde se realiza un análisis de la
seguridad de ECIES) existen diversas soluciones para evitar la maleabilidad benigna.
Además, la utilidad de los modelos KEM autenticados frente a los no autenticados no
está clara, puesto que en la fase DEM se emplea un algoritmo MAC para autenticar
los datos del mensaje [58]. Por último, algunos autores [79] opinan que el análisis
efectuado por NESSIE es incompleto y que, con los datos conocidos, no se puede
afirmar que PSEC sea más seguro que ECIES. Los documentos de NESSIE fueron
redactados en 2004 y, debido a la finalización del proyecto de la Unión Europea al
que estaban adscritos, no han sido revisados ni se han generado nuevas versiones.
El último aspecto que es necesario tener presente en la evaluación de los candi-

datos consiste en el grupo de funcionalidades disponibles en los dispositivos sobre
los que se implementará el esquema de cifrado. Aunque ciertamente en la versión PC
no existen limitaciones a este respecto, puesto que cualquier función criptográfica
puede ser codificada utilizando las API de Java SE, en cambio en Java Card existen
importantes limitaciones, puesto que por ejemplo en sus API no existen métodos
para realizar directamente operaciones de suma de puntos o productos escalares,
existiendo en cambio la posibilidad de utilizar la función Diffie-Hellman con curvas
elípticas, lo que se puede considerar equivalente al producto escalar pero con la par-
ticularidad de que el API de Java Card define como resultado de dicha función la
primera coordenada del punto de la curva que representa la multiplicación o bien la
salida de una función resumen que tome como entrada dicha coordenada.
Tras evaluar los tres criterios mencionados (rendimiento, seguridad y funcionali-
dad disponible en las plataformas PC y Java Card), en vista de sus características,
y considerando como elemento positivo adicional su mayor difusión, el esquema se-
leccionado para su implementación en esta Tesis Doctoral fue ECIES. Las restantes
secciones de este capítulo describen con todo detalle el esquema ECIES, incluyendo
la comparación de las versiones aparecidas en los distintos estándares existentes y
el análisis de su seguridad.
4.2. Esquema de cifrado DHIES

En 1997, Mihir Bellare y Philip Rogaway [26] presentaron un esquema de ci-
frado denominado DLAES (Discrete Logarithm Augmented Encryption Scheme), el
cual fue mejorado posteriormente por los mismos autores junto con Michel Abda-
lla, renombrándolo primero como DHAES (Diffie-Hellman Augmented Encryption
Scheme) en 1998 [8] y posteriormente como DHIES (Diffie-Hellman Integrated En-
cryption Scheme) en 2001 [9, 10], a fin de evitar confusiones con el algoritmo AES.
De forma simplificada, se puede afirmar que DHIES representa una extensión
mejorada del algoritmo ElGamal. La principal aportación de DHIES respecto a la
versión original de ElGamal [69], o a la implementación que hizo Koblitz de ese
mismo algoritmo [147], consiste en reunir bajo un único esquema operaciones de
clave pública, cifrado simétrico, autenticación mediante códigos MAC y cálculo de
resúmenes. En comparación, tanto ElGamal como Koblitz se limitaban a generar
una clave simétrica con la que se cifraba el mensaje original, sin incluir los demás
elementos propios de un esquema integrado. Debido precisamente a este nivel de
integración, DHIES proporciona seguridad contra ataques de texto cifrado elegi-
do, ante los cuales el algoritmo de ElGamal era vulnerable [10], sin necesidad de
aumentar el número de operaciones o la longitud de las claves.
La Figura 4.1 muestra gráficamente el funcionamiento del esquema de cifrado
4.2. Esquema de cifrado DHIES 137
DHIES tal como aparece en [10], donde 𝑀 representa el mensaje a cifrar, 𝑔 𝑣 la

clave pública del destinatario, 𝑔 𝑢 y 𝑢 respectivamente las claves temporales pública
y privada del remitente, ℰ el algoritmo de cifrado simétrico, 𝒯 el algoritmo de
generación de códigos MAC y H la función resumen. Es necesario tener en cuenta
que esta descripción de DHIES emplea de forma genérica un grupo finito cíclico 𝐺
con notación multiplicativa, de ahí que el término 𝑔 𝑢 represente la multiplicación
del elemento 𝑔 ∈ 𝐺 realizada 𝑢 veces.
Figura 4.1: Esquema de funcionamiento de DHIES
El funcionamiento del esquema DHIES definido en [10] es el siguiente: cuando el

remitente desea cifrar y enviar al destinatario un mensaje 𝑀 , lo primero que debe
hacer es elegir aleatoriamente un valor 𝑢 para construir 𝑔 𝑢 , que actuará como clave
pública temporal. Este dato permite que el diseño se ajuste al modelo de acuerdo
de clave Diffie-Hellman [61], ya que el elemento 𝑔 𝑢𝑣 pasa a convertirse en el valor
secreto compartido que únicamente el remitente y el destinatario pueden calcular.
Una vez obtenido el valor secreto, este dato se hace pasar por la función resumen y
se divide el resultado en dos elementos, una clave MAC denominada macKey y una
clave para el algoritmo de cifrado simétrico denominada encKey. A continuación se
cifra el mensaje 𝑀 con la clave encKey y se pasa el mensaje cifrado denominado
encM por la función MAC utilizando la clave macKey, dando como resultado el
elemento tag. Por último, se envía al destinatario de forma conjunta la clave pública
temporal 𝑔 𝑢 , el resultado tag de la función MAC y el mensaje cifrado encM.

En este esquema, es muy importante que el número de elementos del grupo
escogido sea un número primo. De lo contrario, podría suceder que existieran dos
′
valores distintos 𝑢 y 𝑢′ tales que 𝑔 𝑢𝑣 = 𝑔 𝑢 𝑣 , por lo que existirían dos elementos
que generarían la misma salida de la función resumen, resultando un esquema débil
desde el punto de vista de maleabilidad [243].
4.3. Componentes funcionales de ECIES

A lo largo de los restantes capítulos de esta Tesis Doctoral, se utilizará el término
genérico ECIES para referirse a los distintos esquemas de cifrado incluidos en los
estándares de seguridad más relevantes. A pesar de sus diferencias, las versiones
de ECIES incluidas en los estándares analizados se adaptan a un mismo modelo
general, representado mediante la Figura 4.2 (proceso de cifrado) y la Figura 4.3
(proceso de descifrado).
Figura 4.2: Diagrama funcional del proceso de cifrado en ECIES
En los siguientes apartados se presentan los elementos que ambos usuarios deben
acordar de manera previa, utilizando canales de información donde la privacidad no
es un factor importante, ya que la información a intercambiar no es crítica.
4.3. Componentes funcionales de ECIES 139
Figura 4.3: Diagrama funcional del proceso de descifrado en ECIES
La notación empleada en la descripción de los elementos será utilizada poste-

riormente en los apartados dedicados a las implementaciones de ECIES recogidas
en los estándares analizados.
4.3.1. Parámetros de la curva

En el caso de curvas elípticas definidas sobre el cuerpo 𝔽𝑝 , con 𝑝 > 3 primo, el
conjunto de parámetros a utilizar es
𝒫= (𝑝, 𝑎, 𝑏, 𝐺, 𝑛, ℎ),
cuyos elementos se detallan a continuación:
∙ 𝑝 es el número primo que especifica el cuerpo finito 𝔽𝑝 .
∙ 𝑎 y 𝑏 son los elementos de 𝔽𝑝 que definen la curva 𝐸(𝔽𝑝 ) dada por la expresión
𝑦 2 = 𝑥3 + 𝑎𝑥 + 𝑏.
∙ 𝐺 es el punto que actúa como generador de un subgrupo cíclico de puntos de

la curva, siendo sus coordenadas (𝑥𝐺 , 𝑦𝐺 ).
∙ 𝑛 es el número primo que representa el orden del punto 𝐺.

∙ ℎ es el cofactor de la curva, calculado como #𝐸(𝔽𝑝 )/𝑛.
En cambio, si la curva está definida sobre el cuerpo 𝔽2𝑚 , el conjunto de paráme-

tros es
𝒫= (𝑚, 𝑓 (𝑥), 𝑎, 𝑏, 𝐺, 𝑛, ℎ),
donde el significado de los elementos no mencionados anteriormente es el siguiente:
∙ 𝑚 es el número entero que especifica el cuerpo finito 𝔽2𝑚 .
∙ 𝑓 (𝑥) es un polinomio irreducible de grado 𝑚 que define la base polinómica de

𝔽2𝑚 .
∙ 𝑎 y 𝑏 son los elementos de 𝔽2𝑚 que definen la curva 𝐸(𝔽2𝑚 ) dada por la
expresión 𝑦 2 + 𝑥𝑦 = 𝑥3 + 𝑎𝑥2 + 𝑏.
4.3.2. Funciones resumen

Las funciones resumen, identificadas indistintamente en las descripciones de los
algoritmos de esta Tesis como funciones H o HASH (a excepción de los apartados
donde se indique la utilización de la notación propia de algún estándar), toman
como entrada una cadena de bytes de longitud variable y producen como salida una
cadena de bytes de longitud fija, tras la aplicación de varias operaciones sobre la
cadena inicial [78, 172]. Las funciones resumen con mayor presencia en las distintas
implementaciones de ECIES, agrupadas por familias, son las siguientes:
∙ SHA-1, SHA-224, SHA-256, SHA-384 y SHA-512 [183].
∙ RIPEMD-128 y RIPEMD-160 [63].
∙ WHIRLPOOL [131].
4.3.3. Funciones de generación del secreto compartido

Las funciones de generación del secreto compartido utilizadas en ECIES, deno-
minadas de manera genérica funciones KA (Key Agreement), tienen como objetivo
generar un valor secreto compartido entre dos usuarios, utilizando para ello una
clave privada 𝑢 del usuario U y una clave pública 𝑉 del usuario V. Las principales
funciones KA utilizadas en las implementaciones analizadas son:
∙ Primitiva Diffie-Hellman (DH).

La operativa consiste en calcular un punto de la curva 𝑃 = (𝑥𝑃 , 𝑦𝑃 ) = 𝑢 𝑉 e
identificar 𝑃 o 𝑥𝑃 como el secreto compartido.
∙ Primitiva Diffie-Hellman con cofactor (DHC).
En este caso, la operación consiste en obtener el punto 𝑃 ′ = (𝑥𝑃 ′ , 𝑦𝑃 ′ ) = ℎ 𝑢 𝑉 ,
donde ℎ es el cofactor de la curva elíptica a la que pertenecen todos los puntos
considerados, de manera que el secreto compartido sea 𝑃 ′ o 𝑥𝑃 ′ .
Para que los cálculos con cualquiera de las dos primitivas sean válidos, es nece-
sario comprobar que el punto de la curva generado, ya sea 𝑃 o 𝑃 ′ , es distinto del
punto en el infinito 𝒪.
4.3.4. Funciones de derivación de claves

Las funciones de derivación de claves, denotadas como funciones KDF (Key
Derivation Function) sirven para generar claves a partir de un dato secreto com-
partido. La lista de funciones de derivación de claves permitidas por las principales
implementaciones de ECIES está compuesta por:
∙ ANSI-X9.63-KDF [16].
∙ NIST-800-56-Concatenation-KDF [189].
∙ KDF1 [136].
∙ KDF2 [136].
Las funciones ANSI-X9.63-KDF y NIST-800-56-Concatenation-KDF son muy

similares, diferenciándose básicamente en el orden en que se sitúan los elementos
antes de su paso por la función resumen. Por su parte, las funciones KDF1 y KDF2
se encuentran definidas en el estándar ISO/IEC 18033-2 [136]. A continuación se
presenta la descripción de cada una de las funciones, donde se ha utilizado la notación
propia de los respectivos estándares:
∙ ANSI-X9.63-KDF.
Sea 𝑍 una cadena de bits que representa el secreto compartido, 𝐻 una función
resumen aprobada por ANSI, keydatalen un entero que representa la longitud
en bits de la clave a generar tal que keydatalen < hashlen⋅232 − 1, siendo
hashlen la longitud en bits del resultado de la función resumen empleada, y
SharedInfo una cadena de bits opcional que consiste en un dato compartido
de forma previa por emisor y receptor. Con estos elementos, la clave se genera
mediante el Algoritmo 4.4.
Algoritmo 4.4 Función ANSI-X9.63-KDF

1. Inicializar una variable denominada counter, de 32 bits y formato big-endian,
con el valor 0000000116 .
2. Establecer un bucle de tipo for desde 𝑖 = 1 hasta 𝑖 = ⌈𝑘𝑒𝑦𝑑𝑎𝑡𝑎𝑙𝑒𝑛/ℎ𝑎𝑠ℎ𝑙𝑒𝑛⌉

que consiste en calcular 𝐻𝑖 = 𝐻(Z ||counter ||[SharedInfo]), donde por ser
opcional el elemento SharedInfo se representa entre corchetes, e incrementar
tanto i como counter en cada ejecución del bucle, con lo que el valor de
counter depende directamente del elemento 𝑖.
3. Si el cociente 𝑟 = 𝑘𝑒𝑦𝑑𝑎𝑡𝑎𝑙𝑒𝑛/ℎ𝑎𝑠ℎ𝑙𝑒𝑛 es un número entero, generar la clave

KeyData mediante la concatenación
KeyData=𝐻1 ∣∣𝐻2 ∣∣ ⋅ ⋅ ⋅ ∣∣𝐻𝑟 .
4. Si el cociente 𝑟 = 𝑘𝑒𝑦𝑑𝑎𝑡𝑎𝑙𝑒𝑛/ℎ𝑎𝑠ℎ𝑙𝑒𝑛 no fuera un número entero, realizar

la concatenación y seleccionar los primeros keydatalen bits como valor de la
clave.
∙ NIST-800-56-Concatenation-KDF.
Se considera una cadena de bits 𝑍 que representa el secreto compartido, una
función resumen 𝐻, un entero keydatalen que representa la longitud en bits de
la clave a generar, y que debe ser menor o igual que el valor hashlen⋅232 −1, sien-
do hashlen la longitud en bits del resultado de la función resumen empleada,
y una cadena de bits opcional OtherInfo, que consiste en un dato compartido
de forma previa por emisor y receptor. Con estos elementos, la clave se genera
mediante el Algoritmo 4.5.
En cuanto al elemento OtherInfo de NIST-800-56-Concatenation-KDF, su es-
tructura es
OtherInfo=AlgID||UInfo||VInfo[||SuppPubInfo][||SuppPrivInfo],
donde el significado de cada elemento es el siguiente:
AlgID: cadena de bits que informa sobre cómo obtener la clave y con qué
algoritmos será utilizada.
UInfo: cadena de bits con información pública sobre el emisor del mensaje
cifrado, incluyendo al menos un identificador de ese usuario.
VInfo: cadena de bits con información pública sobre el receptor del men-
saje cifrado, incluyendo al menos un identificador de ese usuario.
SuppPubInfo: cadena de bits opcional con información pública mutua-
mente conocida por el emisor y el receptor del criptograma.
Algoritmo 4.5 Función NIST-800-56-Concatenation-KDF

1. Inicializar una variable denominada counter, de 32 bits y formato big-endian,
con el valor 0000000116 .
2. Calcular el valor de 𝑟𝑒𝑝𝑠 = ⌈𝑘𝑒𝑦𝑑𝑎𝑡𝑎𝑙𝑒𝑛/ℎ𝑎𝑠ℎ𝑙𝑒𝑛⌉. Si 𝑟𝑒𝑝𝑠 > 232 − 1, fina-

lizar la operación devolviendo un error.
3. Establecer un bucle de tipo for desde 𝑖 = 1 hasta 𝑟𝑒𝑝𝑠 que consiste

en calcular 𝐻𝑖 = 𝐻(counter ||Z ||OtherInfo), incrementar la variable coun-
ter (mod 232 ) tratándolo como un entero sin signo de 32 bits, e incrementar
la variable i. De esta manera, el valor de counter depende directamente del
número de iteración marcado por el elemento 𝑖.
4. Si el cociente keydatalen/hashlen es un número entero, generar la clave de-

nominada DerivedKeyingMaterial mediante la concatenación
DerivedKeyingMaterial =H1 ||H2 ||⋅ ⋅ ⋅ ||H𝑟𝑒𝑝𝑠 .
5. Si el cociente keydatalen/hashlen no fuera un número entero, realizar la

concatenación y seleccionar los keydatalen bits más a la izquierda como
valor de la clave.
SuppPrivInfo: cadena de bits opcional con información privada mutua-

mente conocida por el emisor y el receptor del criptograma.
Cada uno de esos cinco elementos debe tener una longitud fija, o en su defecto
adaptarse al formato Datalen||Data, donde Datalen debe tener una longitud
fija y se utilizará para informar de la longitud en bytes del elemento Data.
Por su parte, las funciones de derivación de claves KDF1 y KDF2 no permiten

parámetros opcionales como entrada. Sus características más señaladas son:
∙ KDF1.
La función KDF1 toma como entrada una cadena de bytes 𝑥 y un número
entero positivo 𝑙 que representa una longitud, generando como salida una ca-
dena de bytes distinta de la inicial y de longitud 𝑙 que se obtiene mediante el
Algoritmo 4.6.
∙ KDF2.
La función KDF2 es igual que KDF1, con la única diferencia de que el contador
recorre los números 1 a 𝑘 en lugar de recorrer el rango entre 0 y 𝑘 − 1, tal
como queda recogido en el Algoritmo 4.7.
Algoritmo 4.6 Función KDF1

1. Crear una variable denominada 𝑖 ∈ ℤ, siendo contador (𝑖) la representación
binaria de 𝑖 utilizando 4 bytes y elegir una función resumen H.
2. Calcular el valor 𝑘 = ⌈𝑙/H.len⌉, siendo H.len la longitud de la salida de la

función resumen.
3. Establecer un bucle de tipo for desde 𝑖 = 0 hasta 𝑘 − 1 que consiste en

calcular 𝐻𝑖 = 𝐻(x ||contador (i )) e incrementar a continuación la variable i.
4. Concatenar cada una de las cadenas resumen individuales para obtener como
resultado de la función el dato
KDF1(𝑥, 𝑙) = 𝐻(𝑥∣∣contador (0)) ∣∣ ⋅ ⋅ ⋅ ∣∣ 𝐻(𝑥∣∣contador (𝑘 − 1)).
Algoritmo 4.7 Función KDF2

1. Crear una variable denominada 𝑖 ∈ ℤ, siendo contador (𝑖) la representación
binaria de 𝑖 utilizando 4 bytes y elegir una función resumen H.
2. Calcular el valor 𝑘 = ⌈𝑙/H.len⌉, siendo H.len la longitud de la salida de la

función resumen.
3. Establecer un bucle de tipo for desde 𝑖 = 1 hasta 𝑘 que consiste en calcular

𝐻𝑖 = 𝐻(x ||contador (i )) e incrementar a continuación la variable i.
4. Concatenar cada una de las cadenas resumen individuales para obtener como
resultado de la función el dato
KDF2(𝑥, 𝑙) = 𝐻(𝑥∣∣contador (1)) ∣∣ ⋅ ⋅ ⋅ ∣∣ 𝐻(𝑥∣∣contador (𝑘)).

4.3.5. Función de cifrado simétrico

Mediante el término ENC se representará a lo largo de la presente Tesis el
algoritmo de cifrado simétrico utilizado en ECIES. La lista de algoritmos permitidos
en los principales estándares es la siguiente:
∙ XOR.
∙ TDES, también conocido como TDEA (Triple Data Encryption Algorithm),

en modo CBC (Cipher-Block Chaining), tal como aparece descrito en [190] y
en el ahora descatalogado [14].
∙ AES en modo CBC y CTR [185, 187].
∙ MISTY1 en modo CBC [165, 204].
∙ CAST-128 en modo CBC [11].
∙ Camellia en modo CBC [18].
∙ SEED en modo CBC [157].
4.3.6. Funciones generadoras de códigos de autenticación pa-

ra mensajes
De forma genérica, las funciones MAC toman como entrada una cadena de bytes
y un número entero positivo que representa una longitud, y producen como salida
una cadena de bytes (distinta de la inicial y de la longitud indicada) denominada
comúnmente tag o etiqueta. Por su parte, las funciones HMAC (Hashed Message
Authentication Code) representan un tipo especial de funciones MAC, siendo su
característica principal la utilización de una función resumen.
El Algoritmo 4.8 muestra el funcionamiento de las funciones HMAC que utilizan
una clave 𝑘 para autenticar una cadena binaria 𝑥.
Las funciones MAC cuyo uso está más extendido son:
∙ HMAC-SHA-1-80 y HMAC-SHA-1-160 con claves de 160 bits [154, 186].
∙ HMAC-SHA-224-112 y HMAC-SHA-224-224 con claves de 224 bits [186].

Algoritmo 4.8 Función HMAC

1. Asignar a la variable l la longitud de la salida de la función resumen H a
emplear internamente por la función HMAC.
2. Comprobar la longitud de la clave 𝑘 y realizar la operación adecuada:
∙ Si la longitud de k es superior al valor de 𝑙, la asignación 𝑘 ′ =H (𝑘).
∙ Si la longitud de k es menor que el valor de 𝑙, rellenar con ceros por la

derecha hasta conseguir que la longitud de 𝑘 ′ sea igual a 𝐿, de manera
que 𝑘 ′ = 𝑘∣∣000 . . . 0.
∙ Si no se produce ninguno de los casos anteriores, realizar la asignación

𝑘 ′ = 𝑘.
3. Inicializar la cadena binaria identificada como opad, de longitud 𝑙, con el

valor hexadecimal 0x36.
4. Inicializar de igual manera la cadena binaria de longitud 𝑙 e identificador

ipad utilizando el valor hexadecimal 0x5C.
5. Calcular la salida de la función HMAC utilizando la clave 𝑘 y el dato de

entrada 𝑥 mediante la operación
HMAC (𝑥)=H ((𝑘 ′ opad )||H ((𝑘 ′

⊕ ⊕
ipad )||𝑥)).
∙ HMAC-RIPEMD-128-128 con claves de 128 bits [154].
∙ HMAC-RIPEMD-160-160 con claves de 160 bits [154].
∙ CMAC-AES-128, CMAC-AES-192 y CMAC-AES-256 [188].
La notación anterior, sugerida en [154], representa mediante el término genérico

HMAC-Hash-x la implementación de una función HMAC que utiliza la función
resumen Hash con la salida truncada a x bits. Por ejemplo, HMAC-SHA-1-80 implica
que en dicha función se utiliza la función resumen SHA-1, limitando la salida de la
función HMAC a los 80 bits situados a la izquierda de la salida de la función resumen
SHA-1. Si no se indica el componente x, ello significa que la salida no se encuentra
truncada (por ejemplo, la denominación HMAC-SHA-1 es equivalente a HMAC-
SHA-1-160). En lo que respecta a la notación de las funciones CMAC, en este caso
el término genérico CMAC-AES-x representa la utilización del algoritmo AES-x con
clave de x bits, teniendo la salida de la función MAC en esos casos una longitud fija
de 128 bits.
4.4. Versiones de ECIES 147
4.4. Versiones de ECIES

El esquema DHIES fue empleado, junto con otras propuestas, en la preparación
de los estándares ANSI X9.63 [16] e IEEE 1363a [109]. Como resultado de los estu-
dios realizados durante la elaboración de esos documentos, las versiones de ECIES
incluidas en dichos estándares presentan algunas modificaciones respecto a la pro-
puesta original (y que fue revisada por los propios autores en 1998 y 2001, tal como
se ha comentado en §4.2).
Mientras el desarrollo de los estándares ANSI X9.63 e IEEE 1363a avanzaba,
ISO/IEC decidió reunir un grupo de expertos para trabajar en el estándar de cifrado
asimétrico ISO/IEC 18033-2 [136], de manera que durante su elaboración este grupo
tomó como punto de partida los estándares existentes (ya fuera en fase de borrador o
definitivos), especialmente IEEE 1363a al representar el estándar más reciente sobre
ECIES en aquellos momentos. Tras varios años de trabajo, el grupo de expertos que
trabajaba en el estándar ISO/IEC 18033-2 introdujo cambios en la implementación
de ECIES que afectaban a la compatibilidad con los estándares anteriores, por lo que
actualmente para realizar una implementación de ECIES es imprescindible conocer
las diferencias entre los estándares mencionados a fin de tomar las decisiones de
diseño oportunas.
Los siguientes apartados pretenden resumir las características más importan-
tes de cada una de las distintas versiones de ECIES recogidas en los principales
estándares criptográficos de cifrado asimétrico.
4.4.1. Versión de ANSI X9.63
Aunque los borradores del estándar ANSI X9.63 incluían dos esquemas de ci-
frado (Elliptic Curve Encryption Scheme y Elliptic Curve Augmented Encryption
Scheme), cuya diferencia consistía en que el segundo esquema utilizaba una fun-
ción MAC para generar una etiqueta (mientras que el primero no la utilizaba), en la
versión final del estándar [16] se describe una única versión con el nombre de ECIES.
4.4.1.1. Notación y parámetros utilizados
Los datos que emisor y receptor necesitan acordar antes de comenzar el proceso
de cifrado son, utilizando la notación empleada por ANSI X9.63, los siguientes:
∙ Parámetros de dominio 𝒫, junto con una indicación de la base utilizada y un

polinomio reductor 𝑓 (𝑥) de grado 𝑚 y con coeficientes en 𝔽2 , en caso de elegir
curvas del tipo 𝐸(𝔽2𝑚 ).
∙ Función resumen H aprobada por ANSI, donde hashlen representa la longitud

en bytes de los resúmenes calculados y hashmaxlen indica la longitud máxima
en bytes de los mensajes que pueden ser utilizados como entrada para la función
resumen.
∙ Función MAC aprobada por ANSI, donde la entrada de la función estará

formada por los datos MacData, la clave MacKey tendrá una longitud de
mackeylen bits y la salida de la función se representará como MacTag.
∙ Formato de los elementos opcionales SharedData1 y SharedData2 , en caso de

ser utilizados.
En ANSI X9.63, las funciones KDF, KA y ENC están descritas en el propio do-
cumento, siendo respectivamente las funciones ANSI-X9.63-KDF, DH/DHC y XOR.
Los demás elementos que intervienen en las operaciones son:
∙ EncData: mensaje que el emisor desea enviar al receptor, representado como

una cadena de bits.
∙ MaskedEncData: el resultado de cifrar el mensaje EncData.
∙ 𝑑𝑒 : clave privada temporal del emisor, componente del par (𝑑𝑒 , 𝑄𝑒 ).
∙ 𝑄𝑒 : clave pública temporal del emisor, componente del par (𝑑𝑒 , 𝑄𝑒 ). Su repre-
sentación como cadena de bits es QE.
∙ 𝑄: clave pública del receptor.
∙ SharedData1 : cadena de bits con información compartida por emisor y receptor,

y que será utilizada en la función KDF.
∙ SharedData2 : cadena de bits con información compartida por emisor y receptor,

y que será utilizada en la función MAC.
∙ 𝑧: elemento del cuerpo finito 𝔽𝑞 que representa el secreto compartido que se

utilizará en el proceso de derivación de claves. Su representación como cadena
de bits es 𝑍.
∙ EncKey: clave de cifrado a utilizar por la función ENC.
∙ MacKey: clave a utilizar por la función MAC.
∙ MacTag: cadena de bits obtenida como salida de la función MAC.

Algoritmo 4.9 Cifrado ECIES en ANSI X9.63

1. El emisor debe comenzar creando una pareja de claves temporales (𝑑𝑒 , 𝑄𝑒 ),
para lo cual debe seleccionar de forma aleatoria o pseudoaleatoria un valor 𝑑𝑒
perteneciente al conjunto {1, 2, . . . , 𝑛−1}, de manera que su correspondiente
clave pública sea 𝑄𝑒 = 𝑑𝑒 𝐺. A continuación, representará la clave pública
𝑄𝑒 como la cadena de bits 𝑄𝐸.
2. El emisor utilizará la función KA para generar un dato secreto compartido

𝑧 ∈ 𝔽𝑞 a partir de los valores 𝑑𝑒 , 𝑄 y ℎ. Este valor secreto compartido será
a continuación convertido en la cadena de bits 𝑍.
3. El emisor utilizará la función KDF para generar a partir de 𝑍 (y opcional-

mente también del valor SharedData1 ) un dato KeyData cuya longitud debe
ser igual a la suma enckeylen+mackeylen.
4. A partir del elemento KeyData, el emisor adoptará sus enckeylen bits más a
la izquierda como la clave de cifrado EncKey, y utilizará los mackeylen bits
más a la derecha como la clave MacKey a utilizar con la función MAC.
5. El emisor empleará el algoritmo XOR para cifrar el mensaje EncData con

la clave EncKey, generando el mensaje cifrado MaskedEncData.
6. El emisor utilizará la función MAC para generar el elemento MacTag, que

representa la salida correspondiente a la concatenación del mensaje cifrado
MaskedEncData junto con el dato compartido y opcional SharedData2 al
utilizar la clave MacKey.
7. Finalmente, el emisor enviará al receptor la cadena de bits
QE ||MaskedEncData||MacTag,
compuesta por la clave pública temporal QE, el mensaje cifrado MaskedEnc-

Data y la etiqueta MacTag.
4.4.1.2. Proceso de cifrado
El proceso de cifrado de la versión de ECIES incluida en ANSI X9.63 presenta

los pasos descritos en el Algoritmo 4.9.
4.4.1.3. Opciones disponibles
∙ Función HASH :
Cualquier función resumen aprobada por ANSI. El catálogo de estándares de
ANSI de 2010 [17] indica que dichas funciones son las siguientes:
SHA-1.
SHA-224.
SHA-256.
SHA-384.
SHA-512.
∙ Función KA:
DH.
DHC.
∙ Función KDF :
ANSI-X9.63-KDF.
∙ Función ENC :
XOR (sin límite en la longitud de los mensajes a cifrar).
∙ Función MAC :
Está permitida cualquier función MAC aprobada por ANSI que utilice claves
de al menos 80 bits y que genere salidas cuya longitud mínima sea igualmente
de 80 bits, citando el propio estándar como ejemplo la familia de funciones
HMAC, por lo que junto con la lista de funciones resumen permitidas por
ANSI se obtienen las siguientes opciones:
HMAC-SHA-1.
HMAC-SHA-224.
HMAC-SHA-256.
HMAC-SHA-384.
HMAC-SHA-512.
Como aclaración, aunque el documento X9.63 data del año 2001, en la lista de
funciones permitidas se han incluido algoritmos estandarizados en fecha posterior
(SHA-224, HMAC-SHA-224, etc.) puesto que, en lugar de citar específicamente en
algunos apartados los nombres de los algoritmos permitidos, el documento X9.63 se
limita a indicar que las funciones permitidas son aquellas aprobadas por ANSI, lo
que permite hábilmente la actualización del estándar sin que sea necesario publicar
nuevas versiones.
4.4.2. Versión de IEEE 1363a

La versión de ECIES incluida en en el estándar IEEE 1363a [109] está basada
tanto en el esquema DHIES como en la implementación recogida en ANSI X9.63.
A continuación se presentan, manteniendo la notación utilizada por IEEE 1363a,

los datos que los usuarios emisor y receptor necesitan acordar antes de comenzar el
proceso de cifrado:
∙ Parámetros de dominio (𝑞, 𝑎, 𝑏, 𝐺, 𝑟, 𝑘), donde 𝑟 representa el orden del gene-

rador 𝐺 y 𝑘 es el cofactor de la curva, junto con una indicación del tipo de
representación de los elementos de 𝔽𝑞 .
∙ Función resumen H permitida por IEEE, donde hLen representa la longitud

en bytes de los resúmenes calculados.
∙ Función MAC, donde la salida tendrá una longitud tBits.
∙ Formato de los elementos opcionales P1 y P2 , en caso de ser utilizados.
∙ Indicación respecto a la utilización del modo DHAES y del modo no-DHAES

(denominados de esta manera en el estándar, a pesar de que el algoritmo
conocido como DHAES cambiara su denominación a DHIES en una de sus
revisiones [8, 9, 10]), que consiste en incluir la clave pública del emisor como
entrada en la función KDF. Según [109], la utilización del modo no-DHAES se
incluyó por compatibilidad con ANSI X9.63, aunque los autores recomiendan
utilizar el modo DHAES para mayor seguridad.
∙ Empleo de un algoritmo de cifrado de flujo o de un algoritmo de cifrado por

bloques.
En IEEE 1363a, las funciones KDF y MAC son fijas y están descritas en el propio
documento. Aunque en su notación denominan a la función de derivación de claves
KDF2, en realidad se trata de la función ANSI-X9.63-KDF descrita en §4.3.4, y para
evitar confusiones con la función KDF2 del estándar ISO/IEC 18033-2, se utilizará
en este apartado el término ANSI-X9.63-KDF para referirse a ella. En cuanto a la
función MAC1 del documento, se trata de la construcción HMAC-Hash-x [154].
La notación empleada en [109] incluye los siguientes elementos:
∙ 𝑀 : mensaje que el emisor desea enviar al receptor, representado como una

cadena de l bits.
∙ 𝐶: el resultado de cifrar el mensaje 𝑀 .
∙ 𝑢: clave privada temporal del emisor, componente del par de claves (𝑢, 𝑣).
∙ 𝑣: clave pública temporal del emisor, componente del par de claves (𝑢, 𝑣).
∙ 𝑤′ : clave pública del receptor.
∙ 𝑃1 : cadena de bytes con información compartida por emisor y receptor, y que

será utilizada en la función KDF.
∙ 𝑃2 : cadena de bytes con información compartida por emisor y receptor, y que

será utilizada por la función MAC.

utilizará en el proceso de derivación de claves.
∙ 𝑍: representación como cadena de bytes del secreto compartido 𝑧 ∈ 𝔽𝑞 .
∙ 𝐾1 : clave de cifrado a utilizar por la función de cifrado simétrico ENC.
∙ 𝐾2 : clave a utilizar por la función MAC.
∙ 𝑇 : cadena de bits obtenida como salida de la función MAC.
∙ 𝑡𝐵𝑖𝑡𝑠: longitud en bits de la salida de la función MAC.
∙ 𝑘1 : longitud en bits de la clave de cifrado.
∙ 𝑘2 : longitud en bits de la clave para la función MAC.
En este estándar, tanto la cadena 𝑃1 como 𝑃2 pueden estar vacías, por lo que
realmente su uso es opcional.
Algoritmo 4.10 Cifrado ECIES en IEEE 1363a

1. El emisor debe comenzar creando una pareja de claves temporales (𝑢, 𝑣),
donde 𝑢 ∈ {1, . . . , 𝑟 − 1} y 𝑣 = 𝑟 𝑢.
2. El emisor utilizará la función KA para generar un dato secreto compartido 𝑧

a partir de los valores 𝑢 y 𝑤′ . Opcionalmente también utilizará 𝑘 si la primi-
tiva seleccionada hace uso del cofactor. Este valor secreto compartido, que
representa la primera coordenada del punto producido mediante la primitiva
DH o DHC, será a continuación convertido en la cadena de bytes 𝑍, al igual
que la clave pública 𝑣 del emisor se convertirá en la cadena de bytes 𝑉 .
3. Si los usuarios han decidido utilizar el modo DHAES, entonces el elemento

VZ se construye como VZ =V ||Z. En caso contrario, VZ =Z.
4. Si el método de cifrado elegido consiste en un esquema de cifrado de bloques,

el emisor utilizará la función KDF para generar, a partir de los elementos
VZ y 𝑃1 , un dato 𝐾 de longitud 𝑘1 + 𝑘2 bits. A partir del elemento 𝐾, el
emisor adoptará sus 𝑘1 bits más a la izquierda como la clave de cifrado 𝐾1 ,
y utilizará los 𝑘2 bits más a la derecha como la clave 𝐾2 a utilizar en la
función MAC.
En cambio, si el método de cifrado simétrico es un algoritmo de cifrado en
flujo, existe la opción de invertir el orden con que se interpretan las claves 𝐾2
y 𝐾1 , de manera que en el modo DHAES la clave MAC se obtiene tomando
los 𝑘2 bits más a la izquierda de la salida de la función KDF, mientras que
en el modo no-DHAES se consigue mediante los 𝑘2 bits más a la derecha.
5. El emisor procederá a cifrar el mensaje 𝑀 con la clave 𝐾1 para obtener el

mensaje cifrado 𝐶.
6. En el modo DHAES, el emisor debe convertir la longitud en bits de 𝑃2 en

una cadena de 8 bytes 𝐿2 . Si los usuarios no han decidido utilizar el modo
DHAES, la cadena 𝐿2 estará vacía (aunque 𝑃2 contenga datos).
7. El emisor utilizará la función MAC con la clave 𝐾2 para generar el elemento

T, que representa la etiqueta correspondiente a la concatenación del mensaje
cifrado, denotado como 𝐶, junto con el dato compartido 𝑃2 y la cadena de
bytes (potencialmente vacía) 𝐿2 .
8. Finalmente, el emisor enviará al receptor la tripleta (𝑉, 𝐶, 𝑇 ).

El proceso de cifrado de la versión de ECIES incluida en IEEE 1363a presenta

los pasos indicados en el Algoritmo 4.10.
IEEE 1363a permite que el mismo par de claves (𝑢, 𝑣) sea reutilizado en nuevos
procesos de cifrado con destino el mismo usuario o incluso con distintos destinatarios,
aunque en el caso de volver a utilizar el mismo par de claves recomienda variar el
parámetro 𝑃1 a fin de que el dato 𝐾 sea distinto en cada ocasión.
∙ Función HASH :
SHA-1.
SHA-256.
SHA-384.
SHA-512.
RIPEMD-160.
∙ Función KA:
DH (denominada ECSVDP-DH en la norma).

DHC (denominada ECSVDP-DHC en la norma).
∙ Función KDF :
ANSI-X9.63-KDF (denominada en el estándar KDF2, no confundir con

la función del mismo nombre descrita en §4.3.4).
∙ Función ENC :
XOR (el estándar recomienda cifrar mensajes de reducido tamaño y, si

se utiliza el modo no-DHAES, que su longitud sea constante para una
misma clave pública del receptor a emplear).
TDES en modo CBC y relleno PKCS#5 con bloques de 64 bits y claves
de 128 ó 192 bits.
AES en modo CBC y relleno PKCS#5 con bloques de 128 bits y claves
de 128, 192 ó 256 bits
∙ Función MAC :
El estándar define la función MAC1, equivalente a las funciones de tipo HMAC,
donde las funciones resumen permitidas son las del propio documento [109],
obteniendo por tanto como lista de funciones MAC permitidas las siguientes:
HMAC-SHA-1.
HMAC-SHA-256.
HMAC-SHA-384.
HMAC-SHA-512.
HMAC-RIPEMD-160.
4.4.3. Versión de ISO/IEC 18033-2

Los datos que los usuarios emisor y receptor necesitan acordar antes de comenzar
el proceso de cifrado son los siguientes, donde se ha mantenido la notación utilizada
por ISO/IEC 18033-2 [136]:
∙ Conjunto de parámetros (ℋ, 𝒢, 𝑔, 𝜇, 𝜈), donde ℋ es el cuerpo primo o binario

de trabajo, 𝑔 representa el elemento generador del grupo cíclico 𝒢 ⊂ ℋ, 𝜇 es
el orden del elemento 𝑔 y 𝜈 es el cofactor de la curva.
∙ Función de derivación de claves KDF (pudiendo optar entre las funciones

KDF1 y KDF2).
∙ Función resumen Hash, donde Hash.len representa la longitud en bytes de

los resúmenes calculados y Hash.MaxInputLen indica la longitud máxima, en
bytes, de los mensajes que pueden ser utilizados como entrada para la función
resumen.
∙ Función MAC denominada de forma abreviada MA, donde la longitud en

bytes de la clave se denotará mediante el término MA.KeyLen, mientras que
la longitud en bytes de la etiqueta producida por la función se representará
como MA.MACLen.
∙ Función ENC, donde la longitud en bytes de la clave se denotará mediante el

término SC.KeyLen.
∙ Utilización del modo OldCofactorMode, que implica el uso del cofactor tanto
en la fase de cifrado como de descifrado.
∙ Utilización del modo CofactorMode, que requiere del uso del cofactor única-
mente en el proceso de descifrado.
∙ Utilización del modo CheckMode, que obliga a la comprobación durante el pro-

ceso de descifrado de la pertenencia de la clave pública temporal del emisor a 𝒢.
Únicamente uno de los modos OldCofactorMode, CofactorMode y CheckMode
puede ser utilizado en un mismo proceso de cifrado.
∙ Utilización o no del modo SingleHashMode, que permite elegir que la entrada

a la función KDF sea únicamente la primera coordenada del dato secreto
compartido o de manera adicional la clave pública temporal generada por el
emisor.
∙ Formato de codificación de los puntos (comprimido o sin comprimir).
La notación empleada en ISO/IEC 18033-2 incluye además los siguientes ele-

mentos:
∙ 𝑀 : mensaje que el emisor desea enviar al receptor.
∙ 𝑐: el resultado de cifrar el mensaje 𝑀 .
∙ (𝑥, ℎ): par formado por las claves privada y pública del receptor.
∙ (𝑟, 𝑔˜): par formado por una clave privada y una clave pública temporales ge-
neradas por el emisor.
∙ 𝐿: cadena de bytes con información compartida por emisor y receptor, y que

será utilizada en la función MAC.

∙ 𝑍: representación como cadena de bytes de la clave pública temporal del emi-

sor.
∙ 𝐾: valor obtenido como salida de la función KDF.
∙ 𝑘: clave de cifrado a utilizar por el esquema de cifrado simétrico ENC.
∙ 𝑘 ′ : clave a utilizar por la función MAC.
∙ 𝑇 : valor obtenido como salida de la función MAC.
∙ PEH : primera coordenada del punto que actúa como valor secreto compartido.
El proceso de cifrado de la versión de ECIES incluida en ISO/IEC 18033-2

se divide en dos fases, denominadas ECIES-KEM y ECIES-DEM, correspondien-
tes a la generación de las claves de cifrado y autenticación por una parte, y a la
construcción del criptograma a enviar al destinatario, por otra. El Algoritmo 4.11
presenta los pasos de la fase ECIES-KEM, mientras que en la fase DEM el están-
dar ISO/IEC 18033-2 permite utilizar las variantes DEM1 (Algoritmo 4.12), DEM2
(Algoritmo 4.13) y DEM3 (Algoritmo 4.14).
Algoritmo 4.11 Fase KEM del cifrado ECIES en ISO/IEC 18033-2

1. El emisor debe comenzar generando un número aleatorio 𝑟 perteneciente al
conjunto {1, 2, . . . , 𝜇 − 1}.
2. A continuación, si los usuarios utilizan el modo OldCofactorMode, calculará

𝑟′ = 𝑟 ⋅ 𝜈 (mod 𝜇). En caso contrario, realizará la asignación 𝑟′ = 𝑟.
3. Tras el paso anterior, el emisor calculará los puntos de la curva 𝑔˜ = 𝑟 ⋅ 𝑔 y

ℎ̃ = 𝑟′ ⋅ ℎ.
4. Una vez obtenidos los puntos 𝑔˜ y ℎ̃, el emisor obtendrá la codificación he-
xadecimal 𝐶0 correspondiente a la clave pública temporal 𝑔˜ en función del
formato de codificación elegido (comprimido o sin comprimir).
5. Si los usuarios han decidido utilizar el modo SingleHashMode, entonces el

dato secreto compartido 𝑍 será la cadena nula. En caso contrario, 𝑍 = 𝐶0 .
6. A continuación el emisor codificará en formato hexadecimal la primera coor-

denada del elemento ℎ̃, obteniendo el elemento PEH.
7. Acto seguido, utilizará la función KDF para generar 𝐾, tomando como

entrada la concatenación 𝑍∣∣𝑃 𝐸𝐻, es decir, la clave pública temporal del
emisor (o la cadena nula, en su caso) y la representación binaria de la primera
coordenada del dato secreto compartido.
Es interesante comentar que, mientras DEM1 es la función DEM recomendada

por ISO/IEC 18033-2 (y consecuentemente sólo incluye vectores de test para esa
función), el propio documento informa que la principal razón para incluir las fun-
ciones DEM2 y DEM3 ha sido el mantenimiento de compatibilidad con estándares
anteriores.
Las opciones disponibles en el estándar ISO/IEC 18033-2 son:

Algoritmo 4.12 Función DEM1 de la fase DEM del cifrado ECIES en ISO/IEC
18033-2
1. El emisor debe comenzar dividiendo el elemento 𝐾 en 𝑘∣∣𝑘 ′ , donde 𝑘 actuará
como clave para el algoritmo de cifrado simétrico, con longitud SC.KeyLen,
y 𝑘 ′ será la clave de la función MAC, con longitud MA.KeyLen.
2. A continuación el emisor cifrará el mensaje original 𝑀 con la clave 𝑘, gene-

rando el mensaje cifrado 𝑐.
3. Tras el último paso, obtendrá la etiqueta 𝑇 𝐺 correspondiente a la salida

de la función MAC, tomando como entrada la cadena de bytes concatenada
𝑐∣∣𝐿∣∣𝐿.𝑙𝑒𝑛, donde 𝐿 representa los datos compartidos entre emisor y receptor
y 𝐿.𝑙𝑒𝑛 la longitud codificada en 8 bytes de la longitud en bits de 𝐿.
4. Por último, el emisor concatenará el texto cifrado y la etiqueta, enviando al

receptor el elemento 𝐶1 = 𝑐∣∣TG junto con la clave pública temporal 𝐶0 .
18033-2
1. El emisor debe interpretar el elemento 𝐾 como 𝑘∣∣𝑘 ′ , donde 𝑘 actuará como
clave para el algoritmo de cifrado simétrico, con longitud SC.KeyLen, y 𝑘 ′
será la clave de la función MAC, con longitud MA.KeyLen.
2. El emisor cifrará el mensaje original 𝑀 con la clave 𝑘, generando el mensaje

cifrado 𝑐.

𝑐∣∣𝐿, donde 𝐿 es una cadena binaria de datos compartidos entre emisor y
receptor.

18033-2
1. El emisor debe dividir el elemento 𝐾 en 𝑘∣∣𝑘 ′ , donde 𝑘 actuará como clave
para el algoritmo de cifrado de flujo (y por lo tanto su longitud debe coincidir
con la longitud del mensaje a cifrar), y 𝑘 ′ será la clave de la función MAC,
con longitud MA.KeyLen.
⊕ cifrará el mensaje original 𝑀 con la clave 𝑘 mediante la operación

2. El emisor
𝑐 = 𝑘 𝑀.

𝑐∣∣𝐿, donde 𝐿 es una cadena binaria de datos compartidos entre emisor y
receptor.

∙ Función HASH :
Cualquiera de las las funciones resumen definidas en ISO/IEC 10118-2 [130]
que utilizan internamente una función de cifrado de bloques con la condición
de que el número de bytes ofrecidos como salida de la función sea múltiplo de
8. Los nombres asignado por [130] a las funciones son los siguientes:
Hash-function one.
Hash-function two.
Hash-function three.
Hash-function four.
Cualquiera de las funciones resumen definidas en ISO/IEC 10118-3 [131] con

la condición de que el número de bytes ofrecidos como salida de la función
sea múltiplo de 8. Las funciones específicas que cumplen ese requisito son las
siguientes:
SHA-1.
SHA-256.
SHA-384.
SHA-512.
RIPEMD-128.
RIPEMD-160.
WHIRLPOOL.
∙ Función KA:
DH.
DHC.
∙ Función KDF :
KDF1.
KDF2.
∙ Función ENC :
XOR con una longitud de mensaje en claro definida y constante para

todos los procesos de cifrado.
XOR diseñado para el cifrado de mensajes de longitud variable, donde en
lugar de utilizar directamente la clave de cifrado generada por la función
KDF, ésta se utiliza como semilla para la generación de la clave XOR
definitiva adaptada a la longitud del mensaje en claro mediante una nueva
ejecución de la función KDF.
Cualquier algoritmo incluido en ISO/IEC 18033-3 [137] con la condición de que

la longitud de los mensajes medida en bits sea múltiplo de 8. Los algoritmos
descritos en [137] son los siguientes:
TDES en modo CBC y relleno PKCS#5 con bloques de 64 bits y claves

de 128 ó 192 bits.
AES en modo CBC y relleno PKCS#5 con bloques de 128 bits y claves
de 128, 192 ó 256 bits.
MISTY1 en modo CBC y relleno PKCS#5 con bloques de 64 bits y claves
de 128 bits.
CAST-128 en modo CBC y relleno PKCS#5 con bloques de 64 bits y
claves de 128 bits.
Camellia en modo CBC y relleno PKCS#5 con bloques de 128 bits y
claves de 128, 192 ó 256 bits.
SEED en modo CBC y relleno PKCS#5 con bloques de 128 bits y claves
de 128 bits.
∙ Función MAC :
Cualquiera de las cuatro variantes CBC-MAC incluidas en ISO/IEC 9797-1
[128] que utilizan internamente una función de cifrado de bloques, denominadas
en [128] de la siguiente manera:
MAC Algorithm 1.
MAC Algorithm 2.
MAC Algorithm 3.
MAC Algorithm 4.
Cualquiera de las tres variantes incluidas en ISO/IEC 9797-2 [129] que utilizan
internamente una de las funciones resumen referidas en ISO/IEC 10118-3 [131]:
MAC Algorithm 1 (MDx-MAC).

MAC Algorithm 2 (HMAC).
MAC Algorithm 3 (variante de MDx-MAC).
4.4.4. Versión de SECG SEC 1

El consorcio SECG publicó la primera versión del documento SEC 1 el año
2000. Desde entonces ha publicado distintos borradores que han culminado con la
publicación de la versión 2.0 en mayo de 2009 [254]. Este documento incluye, además
de algunos apartados dedicados a los fundamentos matemáticos y los detalles sobre
cómo generar y elegir los parámetros de dominio adecuados, una amplia descripción
de los esquemas de cifrado, firma digital y acuerdo de clave basados en ECC.
Los datos que los usuarios, identificados como emisor y receptor, necesitan acor-
dar antes de comenzar el proceso de cifrado son los siguientes, donde se ha mantenido
la notación utilizada por SEC 1:
∙ Conjunto de parámetros 𝑇 = (𝑝, 𝑎, 𝑏, 𝐺, 𝑛, ℎ) en caso de utilizar curvas defi-

nidas sobre cuerpos finitos 𝔽𝑝 , o parámetros 𝑇 = (𝑚, 𝑓 (𝑥), 𝑎, 𝑏, 𝐺, 𝑛, ℎ) si se
utilizan curvas del tipo 𝐸(𝔽2𝑚 ), donde en ambos casos 𝑛 representa el orden
del generador 𝐺 y ℎ es el cofactor de la curva.
∙ Función de derivación de clave KDF, que genera una cadena de bytes de lon-
gitud enckeylen+mackeylen.
∙ Función resumen H, donde hashlen representa la longitud en bytes de los re-

súmenes calculados y hashmaxlen indica la longitud máxima en bytes de los
mensajes que pueden ser utilizados como entrada para la función resumen.
∙ Función MAC, donde la longitud en bytes de la clave se denotará mediante el

término mackeylen, mientras que la longitud en bytes de la etiqueta producida
por la función se representará como maclen.
∙ Función ENC, donde la longitud en bytes de la clave se denotará mediante el

término enckeylen.
∙ Formato de los elementos SharedInfo1 y SharedInfo2 .
∙ Utilización o no de la representación de puntos con compresión.
La notación empleada en [254] incluye los siguientes elementos:
∙ 𝑀 : mensaje que el emisor desea enviar al receptor.
∙ EM : mensaje cifrado por el emisor.
∙ 𝐶: el resultado de cifrar el mensaje 𝑀 .
∙ (𝑑𝑉 , 𝑄𝑉 ): par formado por la clave privada y la clave pública de 𝑉 .
∙ (𝑘, 𝑅): par formado por una clave privada y una clave pública temporales
generadas por el emisor.
∙ SharedInfo1 : cadena de bytes con información compartida por los dos usuarios,
y que será utilizada en la función KDF.
∙ SharedInfo2 : cadena de bytes con información compartida por emisor y recep-

tor, y que será utilizada por la función MAC.

∙ 𝑍: representación como cadena de bytes del secreto compartido 𝑧 ∈ 𝔽𝑞 .
∙ EK: clave de cifrado a utilizar por el esquema de cifrado simétrico ENC.
∙ MK: clave a utilizar por la función MAC.
∙ 𝐷: valor obtenido como salida de la función MAC.
El proceso de cifrado de la versión de ECIES incluido en SEC 1 presenta los

pasos indicados en el Algoritmo 4.15.
Algoritmo 4.15 Cifrado ECIES en SEC 1

1. El usuario emisor debe comenzar creando una pareja de claves temporales
(𝑘, 𝑅), con 𝑅 = (𝑥𝑅 , 𝑦𝑅 ). Para ello, debe seleccionar aleatoria o pseudoalea-
toriamente un valor 𝑘 perteneciente al conjunto {1, 2, . . . , 𝑛 − 1}, de manera
que su correspondiente clave pública sea 𝑅 = 𝑘 𝐺.
2. Dependiendo del tipo de compresión que los usuarios hayan decidido utilizar
para representar los puntos de la curva elíptica, es necesario convertir el
punto 𝑅 en la cadena de bytes 𝑅.
3. En función del tipo de primitiva Diffie-Hellman (con o sin cofactor) que el

emisor como el receptor hayan acordado utilizar, el usuario emisor generará
un dato secreto compartido 𝑧 ∈ 𝔽𝑞 a partir de la clave secreta temporal 𝑘 y
de la clave pública 𝑄𝑉 . Este valor secreto compartido será convertido en la
cadena de bytes 𝑍.
4. El emisor utilizará la función KDF acordada con el otro usuario para generar
a partir de 𝑍 (y opcionalmente también del valor SharedInfo1 ) un dato 𝐾
cuya longitud será enckeylen+mackeylen.
5. A partir del elemento 𝐾, el emisor adoptará sus enckeylen bytes más a la

izquierda como la clave de cifrado EK, y utilizará los mackeylen bytes más a
la derecha como la clave MK a utilizar con la función MAC. Únicamente en
el caso de que la función de cifrado sea XOR y no se desee compatibilidad
con estándares anteriores, entonces la interpretación del orden de las claves
de cifrado y autenticación será exactamente la contraria.
6. El emisor empleará el algoritmo de cifrado simétrico ENC, junto con el

mensaje 𝑀 y la clave EK, para generar el mensaje cifrado EM.
7. El usuario emisor utilizará la función MAC acordada al inicio del proceso

para generar el elemento D, que representa la etiqueta correspondiente a
la concatenación del mensaje cifrado 𝐸𝑀 junto con el dato compartido
SharedInfo2 al utilizar la clave MK. El dato SharedInfo2 es opcional, por lo
que puede no estar presente.
8. Finalmente, el emisor enviará al usuario receptor el criptograma 𝐶 =

(𝑅, 𝐸𝑀, 𝐷) compuesto por la representación binaria de la clave pública
temporal 𝑅, el mensaje cifrado EM y la etiqueta 𝐷. Una posible forma de
proceder a su envío consiste en concatenar los elementos de forma que el
criptograma sea
𝐶 = 𝑅∣∣EM ∣∣𝐷.
La siguiente lista muestra las distintas opciones permitidas en SEC 1:
∙ Función HASH :
SHA-1.
SHA-224.
SHA-256.
SHA-384.
SHA-512.
∙ Función KA:
DH.
DHC.
∙ Función KDF :
ANSI-X9.63-KDF [16].
NIST-800-56-Concatenation-KDF [189].
∙ Función ENC :
XOR (sin límite en la longitud de los mensajes a cifrar).

TDES con tres claves en modo CBC [190] (SEC 1 no especifica el método
de relleno).
AES en modo CBC y claves de 128, 192 ó 256 bits [185, 187] (sin especi-
ficar el método de relleno).
AES en modo CTR y claves de 128, 192 ó 256 bits [185, 187] (SEC 1 no
define el método de relleno).
∙ Función MAC :
HMAC-SHA-1-80 (clave de 160 bits y salida truncada a 80 bits).

HMAC-SHA-1-160 (clave de 160 bits y salida de 160 bits).
4.5. Diferencias en las versiones de ECIES 165

CMAC-AES-128 (clave de 128 bits y salida de 128 bits).
4.5. Diferencias en las versiones de ECIES

En los siguientes apartados se presenta una comparación entre pares de están-
dares, donde la elección de los estándares a comparar se ha realizado en base a su
fecha de publicación, de manera que las comparaciones se han efectuado entre cada
par de estándares más cercanos en el tiempo. El motivo de esta decisión es que,
aunque cada nuevo estándar se apoya en los anteriores, suele tomar como referencia
el estándar de más reciente publicación.
En resumen, los documentos considerados y sus fechas de publicación son: DHIES
(1997-2001), ANSI X9.63 (2001), ISO/IEC 18033-2 (2006) y SECG SEC 1 (2009).
4.5.1. Diferencias entre DHIES y ANSI X9.63

De manera abreviada, en los siguientes párrafos la propuesta de Abdalla et al.
[10] será referida como ‘DHIES’, mientras que el estándar ANSI X9.63 [16] aparecerá
denotado simplemente como ‘X9.63’. Las principales diferencias entre las versiones
de ECIES recogidas en ambos documentos son:
∙ DHIES no permite parámetros opcionales en las funciones KDF y MAC, mien-

tras que X9.63 permite parámetros en ambas funciones.
∙ DHIES utiliza una función resumen para producir las claves 𝑘𝑀 𝐴𝐶 y 𝑘𝐸𝑁 𝐶 . En
comparación, X9.63 utiliza una función KDF donde los datos son procesados
mediante un procedimiento iterativo.
∙ DHIES interpreta los bits iniciales de la salida de la función KDF como la clave
MAC, y los bits finales como la clave ENC. En X9.63, el orden es precisamente
el opuesto.
∙ X9.63 sólo permite utilizar la función XOR como algoritmo de cifrado simétri-
co. En comparación, DHIES permite utilizar algoritmos de cifrado en bloque,
dejando abierta la elección del algoritmo específico.
4.5.2. Diferencias entre ANSI X9.63 e IEEE 1363a

La siguiente lista refleja las principales diferencias existentes entre las imple-
mentaciones de ECIES incluidas en ANSI X9.63 [16] e IEEE 1363a [109], que por
simplicidad en los siguientes párrafos serán referidos simplemente como ‘X9.63’ y
‘1363a’.
∙ X9.63 permite utilizar parámetros opcionales como entrada en la función KDF,

aunque no menciona el contenido de dichos parámetros. En comparación, el
modo DHAES de 1363a obliga a utilizar la representación binaria de la clave
temporal pública del emisor como parámetro.
∙ En cualquier caso, aunque X9.63 utilizara la clave pública temporal como
parámetro en la función KDF, este dato se concatenaría en tercera posición en
la cadena binaria que representa el argumento de la función resumen utilizada
internamente dentro de la función KDF (es decir, en las iteraciones de la
función sería necesario calcular 𝐻(𝑥𝑃 ∣∣counter ∣∣𝑈 )), mientras que en IEEE
1363a la clave pública temporal ocuparía el primer lugar en la concatenación
(siendo necesario por tanto calcular el valor 𝐻(𝑈 ∣∣𝑥𝑃 ∣∣counter ))
∙ 1363a interpreta los bits iniciales de la salida de la función KDF como la clave
MAC, y los bits posteriores como la clave ENC, cuando utiliza cifrado en flujo,
mientras que la interpretación es la opuesta cuando 1363a utiliza cifrado en
bloque. En comparación, X9.63 interpreta siempre la salida de la función KDF
como 𝑘𝐸𝑁 𝐶 ∣∣𝑘𝑀 𝐴𝐶 .
4.5.3. Diferencias entre IEEE 1363a e ISO/IEC 18033-2

En este apartado se presentan las principales diferencias entre los estándares
IEEE 1363a [109] e ISO/IEC 18033-2 [136], que por simplicidad en los siguientes
párrafos serán referidos simplemente como ‘1363a’ y ‘18033-2’. Las diferencias más
importantes de las versiones de ECIES incluidas en ambos estándares, obviando las
funciones permitidas en cada uno, son:
∙ 18033-2 no permite parámetros en la función KDF, mientras que 1363a sí los

permite.
∙ 1363a permite utilizar tanto cadenas de bits como de bytes, mientras que
18033-2 sólo permite cadenas de bytes.
∙ 1363a sugiere utilizar siempre los mismos parámetros (funciones resumen y
MAC, algoritmo de cifrado simétrico, etc.) para una clave pública del remitente
determinada, mientras que en 18033-2 es obligatorio no cambiar los parámetros
en relación a la misma clave pública del destinatario.
4.5. Diferencias en las versiones de ECIES 167
∙ 1363a establece como longitud mínima del orden del elemento generador 160
bits, mientras que 18033-2 no hace referencia a longitudes mínimas.
Es interesante comentar que, entre el estándar IEEE 1363a y los primeros borra-
dores de ISO/IEC 18033-2, existían más diferencias, como se puede apreciar en el
documento de Shoup [243], que denotaremos por ‘Shoup01’, y que sirvió como punto
de partida para el estándar ISO/IEC 18033-2. Esas diferencias, que posteriormente
desaparecieron en la versión final del estándar con el fin de asegurar una mayor
compatibilidad con otros estándares, son las siguientes:
∙ Mientras que en Shoup01 se utiliza de manera obligatoria la clave pública

temporal del remitente como entrada de la función resumen (junto con el dato
secreto compartido), 18033-2 permite la posibilidad de no incluir dicha clave
pública temporal. Para completar la comparación entre los tres documentos,
se recuerda que 1363a permite una opción (el modo no-DHAES) en la que no
se utiliza la clave pública del destinatario.
∙ Shoup01 obliga a incluir como entrada de la función MAC un campo que
representa la longitud de la etiqueta que se anexa al mensaje cifrado. Por el
contrario, en la versión final de 18033-2 aparecen dos modos (DEM2 y DEM3)
que permiten no incluir esta información. En comparación, en 1363a añadir la
longitud es opcional y en el modo no-DHAES no se emplea.
∙ 18033-2 permite la utilización de la función XOR como algoritmo de cifrado de
flujo en el modo DEM3, algo que sin embargo estaba explícitamente prohibido
en Shoup01. Por su parte, 1363a permite utilizar tanto un cifrado de flujo
como un algoritmo de cifrado simétrico de bloques.
4.5.4. Diferencias entre ISO/IEC 18033-2 y SEC 1

En este apartado se presentan las principales diferencias entre los estándares
ISO/IEC 18033-2 [136] y el documento SEC 1 [254], que por simplicidad serán
referidos simplemente como ‘18033-2’ y ‘SEC 1’. Las diferencias más importantes
entre las versiones de ECIES incluidas en ambos estándares, a excepción de las
funciones específicas permitidas, son:
∙ 18033-2 no permite parámetros en la función KDF, mientras que SEC 1 sí

permite incluir información adicional en la entrada de esa función, aunque en
los vectores de test de ejemplo incluidos en el documento GEC 2 [253] este
parámetro se encuentre ausente.
∙ SEC 1 no incluye de forma explícita la clave pública temporal del usuario
emisor en el cálculo de las claves de cifrado simétrico y autenticación, aunque
comenta que podría ser uno de los elementos incluidos en el dato SharedInfo1 .
∙ Mientras que 18033-2 no hace referencia a longitudes mínimas, SEC 1 estable-

ce que la elección de los cuerpos finitos debe estar guiada por los siguientes
requisitos:
Cuerpos 𝔽𝑝 : el valor 𝑝 debe ser tal que
⌈log2 𝑝⌉ ∈ {192, 224, 256, 384, 521}.
Cuerpos 𝔽2𝑚 : debe cumplirse la propiedad
𝑚 ∈ {163, 233, 239, 283, 409, 571}.
4.6. Comparación de las funciones permitidas en los

estándares
En este apartado se presenta la comparación de las funciones KA, KDF, HASH,
ENC y MAC incluidas en ANSI X9.63, IEEE 1363a, ISO/IEC 18033-2 y SEC 1.
En concreto, el Cuadro 4.5 muestra las principales funciones resumen empleadas
en ECIES, donde las funciones SHA-1, SHA 224, SHA-256, SHA-384 y SHA-512
se encuentran descritas en [183], RIPEMD-128 y RIPEMD-160 son las funciones
resumen definidas en [63] y WHIRLPOOL es la función especificada en [131]. Las
funciones definidas en [130] y referidas en [136] han sido excluidas del cuadro por
tratarse de un tipo de función resumen no presente en los otros estándares y carecer
de utilidad práctica a efectos comparativos.
ANSI X9.63 IEEE 1363a ISO/IEC 18033-2 SECG SEC 1

SHA-1 SHA-1 SHA-1 SHA-1
SHA-224 SHA-256 SHA-256 SHA-224
SHA-256 SHA-384 SHA-384 SHA-256
SHA-384 SHA-512 SHA-512 SHA-384
SHA-512 RIPEMD-160 RIPEMD-128 SHA-512
RIPEMD-160
WHIRLPOOL
Cuadro 4.5: Función HASH
El Cuadro 4.6 muestra las diferentes funciones KA, donde DH representa la

función Diffie Hellman para curvas elípticas sin cofactor y DHC la misma función
utilizando el cofactor.
Por su parte, el Cuadro 4.7 muestra las funciones KDF incluidas en las versiones
de ECIES, donde X9.63-KDF es la función KDF definida en ANSI X9.63 [16], KDF1
4.6. Comparación de las funciones permitidas en los estándares 169

DH DH DH DH
DHC DHC DHC DHC
Cuadro 4.6: Función KA
y KDF2 son las funciones especificadas en ISO/IEC 18033-2 [136] y el término NIST-
800-56 representa la función definida en el documento NIST SP800-56A [189]. Es
importante indicar que, si la función X9.63-KDF no incluye el elemento SharedInfo,
entonces es equivalente a la función KDF2.

X9.63-KDF X9.63-KDF KDF1 X9.63-KDF
KDF2 NIST-800-56
Cuadro 4.7: Función KDF
De manera equivalente, el Cuadro 4.8 muestra los algoritmos de cifrado simé-

trico utilizados por las distintas versiones de ECIES, donde XOR es la función OR
exclusiva, el término XOR⊥ constituye la variante de ISO/IEC 18033-2 que emplea
la función XOR junto con la función KDF, TDES representa el algoritmo Triple
DES [190], AES es el algoritmo definido en [185] para su utilización con claves de
128, 192 y 256 bits, y los algoritmos MISTY1, CAST-128, Camellia y SEED se en-
cuentran especificados en los documentos [165], [11], [18] y [157], respectivamente.
Los términos CBC y CTR hacen referencia al modo de utilización del algoritmo, la
cadena PKCS5 indica que el método de relleno padding a emplear debe ser PKCS#5
[234], y por último el sufijo * implica que el estándar referido no ha impuesto ningún
método de relleno de forma específica.

XOR XOR XOR XOR
⊥
TDES/CBC/PKCS5 XOR TDES/CBC/*
AES/CBC/PKCS5 TDES/CBC/PKCS5 AES/CBC/*
AES/CBC/PKCS5 AES/CTR/*
MISTY1/CBC/PKCS5
CAST-128/CBC/PKCS5
Camellia/CBC/PKCS5
SEED/CBC/PKCS5
Cuadro 4.8: Función ENC
Por último, el Cuadro 4.9 presenta las funciones MAC permitidas en los dife-
rentes estándares, donde con el objetivo de optimizar el tamaño del cuadro re-
sultante se ha sustituido el prefijo HMAC por H. Las funciones HMAC-SHA-1 y
HMAC-RIPEMD se encuentran especificadas en [154], las variantes HMAC-SHA-

224, HMAC-SHA-256, HMAC-SHA-384 y HMAC-SHA-512 surgen de la combina-
ción de [186] y [191], y finalmente CMAC-AES es el conjunto de funciones HMAC
incluidas en [188] con claves de 128, 192 y 256 bits. Respecto al estándar ISO/IEC
18033-2, se han incluido en el cuadro únicamente las funciones de tipo HMAC, pues-
to que el resto de funciones definidas en [128] y [129] constituyen tipos de funciones
MAC no presentes en los demás estándares analizados y por lo tanto no son com-
parables a efectos prácticos.

H-SHA-1 H-SHA-1 H-SHA-1 H-SHA-1-80/160
H-SHA-512 H-RIPEMD-160 H-RIPEMD-128 H-SHA-512-256/512
H-RIPEMD-160 CMAC-AES-128/192/256
H-WHIRLPOOL
Cuadro 4.9: Función MAC
Como resumen final, el Cuadro 4.10 muestra las funciones permitidas simultá-
neamente por los cuatro estándares revisados.
HASH KA KDF ENC MAC

SHA-1 DH KDF2 XOR HMAC-SHA-1
SHA-256 DHC HMAC-SHA-256
SHA-384 HMAC-SHA-384
SHA-512 HMAC-SHA-512
Cuadro 4.10: Funciones comunes permitidas en los cuatro estándares
4.7. Comparación de las configuraciones permitidas

en los estándares
Tal como se ha mostrado en los anteriores apartados, los diferentes estándares
en los que se encuentra descrito el esquema ECIES contienen múltiples opciones
no siempre compatibles entre sí. El primer paso para realizar una implementación
del esquema de cifrado ECIES consiste, por tanto, en identificar todas las posibles
opciones, a fin de tomar unas decisiones sobre la funcionalidad final a implementar.
Un análisis detallado de las distintas combinaciones de parámetros muestra que
existen 11 configuraciones posibles que puedan ser implementadas al menos por
4.7. Comparación de las configuraciones permitidas en los estándares171
un estándar (las restantes configuraciones, no incluidas, son incompatibles con los

cuatro estándares). Puesto que todos ellos permiten utilizar como función KA las
funciones DH y DHC, el análisis se reduce a comparar los siguientes elementos: el
tipo y número de argumentos de las funciones KDF y MAC, la interpretación del
elemento K a partir del cual se generan las claves de cifrado y autenticación, y por
última la clase de función de cifrado simétrico elegida (en flujo o en bloque).
El Cuadro 4.11 muestra los datos mencionados en el párrafo anterior, donde 𝑥𝑃
es la codificación binaria de la primera coordenada del punto 𝑃 = (𝑥𝑃 , 𝑦𝑃 ), Param 1
representa una cadena binaria con parámetros para la función KDF, 𝑘𝐸𝑁 𝐶 y 𝑘𝑀 𝐴𝐶
son respectivamente las claves de cifrado y autenticación generadas a partir del dato
K (que a su vez es la salida de la función KDF ), 𝔠 es el mensaje cifrado con el
algoritmo de cifrado simétrico (ya sea una función de cifrado en flujo o en bloque),
y por último Param 2 representa una cadena binaria con parámetros para la función
MAC (por ejemplo, la codificación de un texto que conocen emisor y receptor).
Opciones de configuración
Arg. KDF Interp. K Alg. simétrico Arg. MAC
C01 𝑥𝑃 𝑘𝐸𝑁 𝐶 ∣∣𝑘𝑀 𝐴𝐶 Flujo 𝔠
C02 𝑥𝑃 𝑘𝐸𝑁 𝐶 ∣∣𝑘𝑀 𝐴𝐶 Flujo 𝔠, Param 2
Id. de configuración
C03 𝑥𝑃 𝑘𝑀 𝐴𝐶 ∣∣𝑘𝐸𝑁 𝐶 Flujo 𝔠

C04 𝑥𝑃 𝑘𝑀 𝐴𝐶 ∣∣𝑘𝐸𝑁 𝐶 Flujo 𝔠, Param 2
C05 𝑥𝑃 𝑘𝐸𝑁 𝐶 ∣∣𝑘𝑀 𝐴𝐶 Bloque 𝔠
C06 𝑥𝑃 𝑘𝐸𝑁 𝐶 ∣∣𝑘𝑀 𝐴𝐶 Bloque 𝔠, Param 2
C07 𝑥𝑃 , Param 1 𝑘𝐸𝑁 𝐶 ∣∣𝑘𝑀 𝐴𝐶 Bloque 𝔠
C08 𝑥𝑃 , Param 1 𝑘𝐸𝑁 𝐶 ∣∣𝑘𝑀 𝐴𝐶 Bloque 𝔠, Param 2
C09 𝑈 ∣∣𝑥𝑃 𝑘𝐸𝑁 𝐶 ∣∣𝑘𝑀 𝐴𝐶 Bloque 𝔠
C10 𝑈 ∣∣𝑥𝑃 𝑘𝐸𝑁 𝐶 ∣∣𝑘𝑀 𝐴𝐶 Bloque 𝔠, Param 2
C11 𝑈 ∣∣𝑥𝑃 , Param 1 𝑘𝐸𝑁 𝐶 ∣∣𝑘𝑀 𝐴𝐶 Bloque 𝔠, Param 2
Cuadro 4.11: Combinaciones de parámetros admitidas al menos en un estándar
Una vez presentadas las personalizaciones de ECIES que son aceptadas al menos
en un estándar, el Cuadro 4.12 muestra el resumen de los estándares que permiten
cada una de las configuraciones.
Identificador de personalización
C01 C02 C03 C04 C05 C06 C07 C08 C09 C10 C11
X9.63 ✓ ✓
1363a ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓
18033-2 ✓ ✓ ✓ ✓ ✓ ✓
SEC 1 ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓
Cuadro 4.12: Comparativa de las configuraciones permitidas en cada estándar
4.8. Versión de ECIES compatible con todos los es-

tándares
Tras revisar la lista de funciones permitidas por cada estándar en 4.6 y analizar
las configuraciones permitidas por cada uno de ellos en 4.7, se puede concluir que
existen dos configuraciones válidas en las últimas versiones de ANSI X9.63, IEEE
1363a, ISO/IEC 18033-2 y SECG SEC 1, caracterizadas ambas por utiliza la función
XOR como algoritmo de cifrado simétrico.
A la vista de este hecho, y teniendo en cuenta el elevado número de funciones
que los estándares utilizan de forma común, es posible construir distintas versiones
de ECIES compatibles con los cuatro estándares y con las configuraciones C01 y
C02, diferenciándose entre ellas en la función resumen, la función MAC, el uso de
parámetros opcionales en la función MAC, o una combinación de esos elementos.
Por simplicidad, el Algoritmo 4.16 muestra únicamente un ejemplo de los mu-
chos posibles, denominado ECIES-4, que emplea un subconjunto de las opciones
disponibles de manera común en los cuatro estándares.
4.9. Seguridad de ECIES

De manera adicional a los ataques generales sobre curvas elípticas expuestos en
§2.6.7, con el paso del tiempo han surgido ataques específicos para ECIES debi-
do a las peculiaridades de este esquema de cifrado. En los siguientes apartados se
presentan los principales ataques conocidos sobre ECIES.
4.9.1. Resistencia a la maleabilidad

El concepto de maleabilidad puede ser definido como la capacidad de un ata-
cante de generar un criptograma válido asociado al mensaje en claro 𝑦 a partir del
conocimiento del criptograma derivado del mensaje 𝑥, cuando entre los mensajes 𝑥
4.9. Seguridad de ECIES 173
Algoritmo 4.16 Cifrado ECIES compatible con los cuatro estándares (ECIES-4)
1. Elegir un valor aleatorio 𝑢 ∈ {1, 2, . . . , 𝑞 − 1} como clave privada temporal
de U, y generar la clave pública 𝑈 = 𝑢 𝐺.
2. Calcular un punto 𝑃 = (𝑥𝑃 , 𝑦𝑃 ) de la curva mediante la operación 𝑃 = 𝑢 𝑉 ,

donde 𝑉 es la clave pública del usuario receptor.
3. Generar el elemento 𝐾 del que se obtendrán las clave de cifrado y autenti-

cación mediante la operación 𝐾 =KDF (𝑥𝑃 ), siendo la función KDF elegida
ANSI-X9.63-KDF (sin parámetros opcionales) y la función HASH empleada
SHA-1.
4. Interpretar 𝐾 como 𝑘𝐸𝑁 𝐶 ∣∣𝑘𝑀 𝐴𝐶 , donde la longitud en bits de 𝑘𝐸𝑁 𝐶 es igual

a la longitud en bits del mensaje en claro 𝔪, y la longitud de 𝑘𝑀 𝐴𝐶 es 160
bits.
⊕
5. Producir el mensaje cifrado 𝔠 = 𝑘𝐸𝑁 𝐶 𝔪 utilizando la función de cifrado
de flujo XOR.
6. Calcular la etiqueta tag utilizando el método tag = MAC (𝔠), donde la fun-
ción MAC elegida es HMAC-SHA-1 con salida de 160 bits.
7. Enviar la tripleta 𝒞 = (𝑈 , 𝔠,tag) como criptograma concatenando los tres

elementos, de manera que la cadena binaria recibida por el usuario receptor
sea 𝑈 ∣∣𝔠∣∣tag.
e 𝑦 existe alguna relación [67].

En el contexto de ECIES, la maleabilidad se puede dividir en benigna o maligna,
dependiendo de si el ataque es capaz de producir resultados prácticos.
4.9.1.1. Maleabilidad benigna
Shoup [243] demostró que, si se utiliza únicamente la primera coordenada 𝑥𝑃

como entrada de la función KDF, el esquema ECIES es vulnerable frente ataques
de tipo ACCA y, en consecuencia, es maleable. En efecto, dado un criptograma
(𝑈 , 𝔠, 𝑡𝑎𝑔) compuesto por la representación binaria 𝑈 de la clave pública temporal
𝑈 del emisor, el mensaje cifrado 𝔠 y la etiqueta tag, si se sustituye el punto de la
curva 𝑈 por −𝑈 , al aplicar la función KA se obtiene como material para generar la
clave el elemento −𝑢𝑉 en lugar de 𝑢𝑉 . Pero puesto que tanto en 𝑢𝑉 como en −𝑢𝑉
la coordenada 𝑥 tiene el mismo valor, la entrada a la función KDF será la misma
en ambos casos. La conclusión es que, a partir de un criptograma (𝑈 , 𝔠, 𝑡𝑎𝑔) válido,
es posible construir otro criptograma (−𝑈 , 𝔠, 𝑡𝑎𝑔) igualmente válido.
Una posible forma de resolver este problema fue propuesta por el propio Shoup,
y consiste en añadir la clave pública temporal 𝑈 como entrada de la función KDF,
con lo que el criptograma (−𝑈 , 𝔠, 𝑡𝑎𝑔) ya no sería válido, dado que la salida de la
función KDF sería diferente en ambos casos.
Otra posible solución consiste en utilizar el punto 𝑃 generado mediante la función
KA en lugar de únicamente su primera coordenada como entrada de la función
KDF, con lo que de nuevo dejaría de ser válido un criptograma que contuviera −𝑈
en lugar de 𝑈 . Respecto a la solución mencionada anteriormente, algunos autores
como Jacques Stern [256] indican la validez y equivalencia desde el punto de vista
de seguridad de ambas opciones. Sin embargo, a pesar de estar recogida esta opción
en algunas obras [30], en los cuatro estándares estudiados la segunda opción no es
utilizada.
Independientemente de la vulnerabilidad reseñada, Shoup indicó que, en caso de
utilizar la función Diffie-Hellman con cofactor, es igualmente posible crear un ataque
que afecte a la maleabilidad del esquema, puesto que si al punto 𝑈 se le añade un
elemento distinto de 𝒪 cuyo orden divida el cofactor ℎ, entonces de nuevo a partir
de un criptograma válido sería posible generar otro criptograma igualmente válido.
La solución más sencilla para este problema consiste en utilizar la función DH sin
emplear el cofactor.
Shoup caracterizó estos problemas como maleabilidad benigna, dando a entender
que no representan un peligro demasiado importante, ya que hasta la fecha no se
ha demostrado que este ataque sirva para obtener ningún resultado práctico. Sin
embargo, desde el punto de vista formal, si se desea que el esquema ECIES sea no
maleable, es necesario solucionar estos problemas.
4.9.1.2. Maleabilidad en el uso de la función XOR como algoritmo de

cifrado
Shoup demostró en [243] que el esquema ECIES es también maleable, aunque

en este caso de forma no benigna, cuando se utiliza la función XOR como función
de cifrado con mensajes de longitud variable, lo que representa un riesgo en ataques
de tipo ACCA. En efecto, dado el criptograma
(𝑈 , 𝔠,tag),
supongamos que está formado a partir de los siguientes elementos:
1. La representación binaria 𝑈 de la clave pública temporal 𝑈 del emisor.
2. El mensaje en claro 𝔪 formado por la concatenación de las cadenas 𝔪1 y 𝔪2 ,

con longitudes respectivas 𝑙1 y 𝑙2 .
3. La salida de la función KDF, 𝑘∣∣𝑘 ′ , donde la clave de cifrado es la cadena 𝑘,

que tiene longitud 𝑙1 + 𝑙2 , y la clave MAC es la cadena 𝑘 ′ , con longitud 𝑙′ . La
cadena 𝑘 se puede construir como la concatenación 𝑘1 ∣∣𝑘2 , cuyas longitudes
respectivas son 𝑙1 y 𝑙2 .
4. El mensaje cifrado 𝔠 formado por la concatenación de las cadenas 𝔠1 y 𝔠2 ,

donde la cadena 𝔠1 = 𝔪1 ⊕ 𝑘1 tiene longitud 𝑙1 y la cadena 𝔠2 = 𝔪2 ⊕ 𝑘2 tiene
longitud 𝑙2 .
5. La etiqueta tag consistente en la salida de la función MAC tomando como

entrada 𝔠 y utilizando la clave 𝑘 ′ .
Bajo esas premisas, es posible construir de forma artificial otro criptograma
ˆ
(𝑈 , ˆ𝔠, tag)
también válido para los siguientes datos:
1. La representación binaria 𝑈 de la clave pública temporal 𝑈 del emisor.
2. Una cadena Δ con longitud 𝑙1 y contenido indiferente para el resultado final.

⊕
ˆ = 𝔪1 Δ de longitud 𝑙1 .
3. El mensaje en claro 𝔪
4. La salida de la función KDF, 𝑘ˆ = 𝑘ˆ1 ∣∣𝑘ˆ2 = 𝑘1 ∣∣𝑘2 , donde la cadena 𝑘ˆ1 = 𝑘1

tiene longitud 𝑙1 y la cadena 𝑘ˆ2 = 𝑘2 tiene longitud 𝑙2 .
⊕
5. El mensaje cifrado ˆ𝔠 = 𝔠1 Δ de longitud 𝑙1 .
ˆ consistente en la salida de la función MAC tomando como
6. La etiqueta tag
entrada ˆ𝔠 y utilizando la clave 𝑘2 .
Para mayor claridad, la Figura 4.4 muestra las relaciones existentes entre los
diversos datos de ambos criptogramas. Para solucionar este problema es posible
emplear distintas soluciones:
1. Forzar una longitud fija en el caso de utilización de la función XOR [109, 136,
243].
2. Cambiar el orden de interpretación de las claves MAC y de cifrado obtenidas a

partir de la función KA, de manera que la clave MAC se obtenga a partir de los
bits más a la izquierda de la salida de la función KDF [10, 109, 254, 243, 256].
3. Prohibir la utilización de las funciones de cifrado en flujo en ECIES, permi-

tiendo únicamente los algoritmos de cifrado de bloques [224, 243].
Figura 4.4: Maleabilidad debido a la función XOR

4.9.2. Ataques de subgrupos pequeños

Este tipo de ataques [99] se producen cuando un atacante proporciona delibera-
damente una clave pública inválida. Si el usuario que desea enviar el mensaje cifrado
no comprueba la validez de la clave pública del destinatario, éste podría haber pro-
porcionado como clave un elemento de orden pequeño, con el objetivo de limitar el
rango posible para el dato secreto compartido o incluso tratar de obtener alguna
información sobre la clave privada del remitente.
Las opciones disponibles para evitar este tipo de ataques son la siguientes:
∙ Calcular el orden de la clave pública del destinatario, comprobando que es

igual a 𝑛.
∙ Utilizar la primitiva DHC en lugar de la función DH, comprobando que el

elemento ℎ 𝑢 𝑉 ∕= 𝒪.
∙ Reemplazar el dato secreto compartido por su resumen (por ejemplo, mediante

la función SHA-1) antes de utilizar ese dato como entrada de la función KDF.
∙ Utilizar la clave pública temporal del emisor como entrada de la función KDF.
En un escenario típico, la validez de la clave pública del destinatario será reali-

zada por un organismo de certificación, por lo que esta solución no tendría impacto
en una solución comercial.
Por otra parte, la utilización de la función DHC conlleva otras desventajas, tal
como se menciona en §4.9.1.1, siendo una de las razones por las que los vectores de
test de [130, 253] únicamente utilizan la función DH.
Respecto a la utilización del resumen del dato secreto compartido en lugar de su
valor completo, aunque se menciona en [109] y fue implementado en Java Card 2.2,
en la práctica ninguno de los vectores de tests de [130] y [253] lo utilizan, y en la
última versión de Java Card se ha añadido un nuevo modo de operación en el que
no se aplica ninguna función resumen a la salida de la función KA.
Finalmente, la opción más extendida en los estándares analizados consiste en
utilizar la clave pública temporal del emisor como entrada de la función KDF, de
modo que en el diseño de la propia función KDF se incluye una función resumen
de tal manera que a partir de la salida de la función KDF no sea posible obtener
ninguna información útil que pudiera llevar a determinar el valor 𝑢 utilizado.
Como consideración adicional, si el par de claves temporal se genera aleatoria-
mente y se utiliza en un único proceso de cifrado, aunque el atacante consiguiera
obtener alguna información relativa a este par de claves, dicha información no sería
útil para posteriores procesos de cifrado.
4.9.3. Elección dinámica de parámetros y funciones
Aunque algunos autores como Shoup [243] consideran que es fundamental para
la seguridad de ECIES mantener las mismas funciones KDF, ENC y MAC durante
el ciclo de vida de un par de claves determinado, y en algunos estándares como IEEE
1363a esté recomendada esta forma de proceder, en la práctica no existe consenso
[224] sobre el riesgo real que implicaría el cambio de parámetros y funciones durante
el ciclo de vida de unas claves dadas.
Por otra parte, puesto que seguir la recomendación de Shoup no parece tener
ningún efecto negativo, la prudencia sugiere en este caso imponer como requisito
que ni las funciones ni los parámetros puedan ser modificados durante el ciclo de
vida de un par de claves. Esto significa que, en la fase inicial de acuerdo de opciones
de los usuarios legítimos, éstos deben realizar las comprobaciones adecuadas para
asegurar que, para un par de claves específico, solamente se utilizará un conjunto de
parámetros a lo largo del ciclo de vida de esas claves.
4.10. Versión de ECIES segura

Una vez analizada la seguridad de ECIES en §4.9, es necesario revisar las ca-
racterísticas de la versión ECIES-4 definida en §4.8. Puesto que dicha versión (y
sus posibles variantes que empleen otras funciones resumen y MAC ) emplean la
función XOR, que puede ser utilizada por un atacante para generar problemas de
maleabilidad maligna, es necesario reconsiderar las decisiones tomadas respecto a la
versión de ECIES compatible con todos los estándares.
De las tres soluciones al problema de maleabilidad maligna descritas en §4.9.1.2,
la única que es posible de implementar manteniendo la compatibilidad de la versión
ECIES-4 con los cuatro estándares consiste en fijar la longitud de los mensajes a
cifrar, lo que de hecho ya era recomendado en IEEE 1363a, donde además se sugiere
que los únicos mensajes a cifrar mediante la función XOR sean claves de otros
algoritmos de cifrado simétrico.
Puesto que con la única solución compatible con todos los estándares la fun-
cionalidad de ECIES queda seriamente limitada, se hace necesario seleccionar otra
configuración como punto de partida para cualquier implementación de ECIES. Da-
do que exceptuando C01 y C02 no existen más configuraciones compatibles con los
cuatro estándares, los candidatos lógicos son aquellas configuraciones permitidas en
tres estándares, que resultan ser C05 y C06. Al igual que sucedió en §4.8, es posible
definir a partir de las configuraciones C05 y C06 múltiples versiones compatibles con
dichas configuraciones, y que se diferencien en la función HASH, la función MAC o
el uso de argumentos opcionales en la función de autenticación.
Las versión ECIES-3 definida por el Algoritmo 4.17 constituye una de las po-
4.10. Versión de ECIES segura 179
sibles variantes compatibles con las configuraciones C05 y C06 definidas por IEEE
1363a, ISO/IEC 18033-2 y SECG SEC 1. ECIES-3 incluye los elementos necesarios
para resistir cualquiera de los ataques contra ECIES conocidos y descritos en §4.9,
utilizando funciones que aseguren una correcta eficiencia y estén disponibles en las
librerías criptográfica actuales.
Algoritmo 4.17 Cifrado ECIES compatible con los cuatro estándares (ECIES-3)
1. Elegir un valor aleatorio 𝑢 ∈ {1, 2, . . . , 𝑞 − 1} como clave privada temporal
de U, y generar la clave pública 𝑈 = 𝑢 𝐺.
2. Calcular un punto 𝑃 = (𝑥𝑃 , 𝑦𝑃 ) de la curva mediante la operación 𝑃 = 𝑢 𝑉 ,

donde 𝑉 es la clave pública del usuario receptor.
3. Generar el elemento 𝐾 del que se obtendrán las clave de cifrado y autenti-

cación mediante la operación 𝐾 =KDF (𝑥𝑃 ), siendo la función KDF elegida
KDF2 (equivalente a ANSI-X9.63-KDF sin parámetros opcionales) y la fun-
ción HASH empleada SHA-256.
4. Interpretar 𝐾 como 𝑘𝐸𝑁 𝐶 ∣∣𝑘𝑀 𝐴𝐶 , donde las longitudes en bits de 𝑘𝐸𝑁 𝐶 y

𝑘𝑀 𝐴𝐶 son 256 bits.
5. Producir el mensaje cifrado 𝔠 = ENC (𝔪), donde la función de cifrado simé-

trico ENC es el algoritmo AES en modo CBC y relleno PKCS#5 utilizando
claves de 256 bits.
6. Calcular la etiqueta tag utilizando el método tag = MAC (𝔠||Param 2 ), donde

la función MAC elegida es HMAC-SHA-256 con salida de 256 bits y el
elemento Param 2 representa la concatenación de una cadena binaria (que
representa un dato conocido por usuario y emisor) junto con la longitud en
bits de dicho dato empleando para su codificación 8 bytes.
7. Enviar la tripleta 𝒞 = (𝑈 , 𝔠,tag) como criptograma concatenando los tres

elementos, de manera que la cadena binaria recibida por el usuario receptor
sea 𝑈 ∣∣𝔠∣∣tag.
Capítulo 5
Implementación de ECIES en
entorno PC

Este capítulo presenta las decisiones de diseño tomadas con el objetivo de
desarrollar la implementación de ECIES en plataformas PC, así como el
diagrama de las clases Java que componen el desarrollo software. El resto
del capítulo se encuentra dedicado a la descripción funcional completa de
esta versión de la aplicación ECIES, finalizando con un ejemplo de cifrado
y descifrado que ilustra las posibilidades de utilización de la aplicación.
5.1. Diseño del esquema ECIES a implementar

El principal objetivo del desarrollo de la versión de ECIES para PC consiste
en poder realizar pruebas con distintas combinaciones de funciones y parámetros.
Debido a ello, además de los elementos que componen las versiones de ejemplo
ECIES-4 y ECIES-3 definidas en §4.8 y §4.10, se decidió incluir las funciones HASH,
KDF, ENC y MAC más habituales en los estándares analizados, así como algunas
de las opciones que permiten diferenciar las configuraciones descritas en §4.7.
El Capítulo 6 presenta la versión de ECIES para tarjetas Java Card. La inves-
tigación de las capacidades criptográficas de Java Card en relación a ECIES puso
de manifiesto la existencia de una peculiaridad de carácter fundamental en Java
Card que, sin embargo, no aparece descrita en los estándares donde se incluyen las
distintas versiones de ECIES. Dicha peculiaridad consiste en que la salida de las
181
182 5. Implementación de ECIES en entorno PC
funciones KA (tanto DH como DHC) en Java Card es el resultado de utilizar la

función resumen SHA-1 tomando como entrada la primera coordenada del punto de
la curva que actúa como secreto compartido. Puesto que la presente Tesis pretende
comparar el rendimiento de ECIES en plataformas PC y Java Card, y para ello es
fundamental que las versiones comparadas tengan las mismas características, fue
necesario añadir a la definición de ECIES para PC las particulares versiones de las
funciones de acuerdo de clave DH y DHC de Java Card.
Tras estas consideraciones, se incluye en los siguientes apartados la descripción
de la funcionalidad completa de la versión de ECIES para PC, utilizando para ello
el modelo KEM -DEM popularizado en los últimos años y descrito en §2.5.
5.1.1. Cifrado
El Algoritmo 5.1 describe la fase KEM del proceso de cifrado de la versión de

ECIES desarrollada para PC, mientras que el Algoritmo 5.2 muestra la fase DEM
del proceso de cifrado de dicha versión. De manera global, la entrada del proceso de
cifrado KEM -DEM está formada por un mensaje en claro 𝔪, una longitud 𝑙 y una
clave pública 𝑉 , y la salida consiste en el criptograma 𝒞.
Algoritmo 5.1 Cifrado ECIES en la versión PC (fase KEM )

1. Decidir el formato de representación de los puntos (comprimida o sin com-
primir).
2. Elegir un valor 𝑢 ∈ {1, 2, . . . , 𝑞 − 1} como clave privada temporal de U.
3. Generar la clave pública del usuario U, 𝑈 = 𝑢 𝐺, cuya representación hexa-

decimal es 𝑈 .
4. Calcular el punto de la curva 𝑃 = (𝑥𝑃 , 𝑦𝑃 ) = 𝑢 𝑉 mediante la función DH.

La representación hexadecimal de su primera coordenada será 𝑥𝑃 .
5. Obtener el dato 𝐾 mediante una de las siguientes opciones:
a) 𝐾 = KDF (𝑥𝑃 ).
b) 𝐾 = KDF (HASH (𝑥𝑃 )).
c) 𝐾 = KDF (𝑈 ∣∣𝑥𝑃 ).
d ) 𝐾 = KDF (𝑈 ∣∣HASH (𝑥𝑃 )).

5.1. Diseño del esquema ECIES a implementar 183
Algoritmo 5.2 Cifrado ECIES en la versión PC (fase DEM )

1. Interpretar 𝐾 de una de las siguientes maneras, donde 𝑘𝐸𝑁 𝐶 es la clave
de cifrado simétrico, y 𝑘𝑀 𝐴𝐶 es la clave para la función de autenticación
del mensaje, estando las longitudes de ambos elementos determinadas por
el usuario (o por la longitud del propio mensaje, en el caso de utilizar la
función XOR):
a) 𝑘𝐸𝑁 𝐶 ∣∣𝑘𝑀 𝐴𝐶 .
b) 𝑘𝑀 𝐴𝐶 ∣∣𝑘𝐸𝑁 𝐶 .
2. Calcular el mensaje cifrado 𝔠 = 𝐸𝑁 𝐶(𝔪) empleando la clave 𝑘𝐸𝑁 𝐶 y el

algoritmo de cifrado simétrico seleccionado por el usuario.
3. Calcular la etiqueta tag = MAC (𝔠||[dat]||long) utilizando la clave 𝑘𝑀 𝐴𝐶 y

la función MAC seleccionada por el usuario, donde dat es una cadena de
texto opcional acordada por ambos usuarios y el elemento long, que tiene
una longitud fija de 8 bytes, contiene el valor de la longitud en bits del dato
dat. Como aclaración, los elementos dat y long equivalen al dato Param 2
mencionado en el Capítulo 4.
4. Enviar el criptograma 𝒞 =(𝑈 , 𝔠,tag) generado mediante la concatenación de

sus elementos.
5.1.2. Descifrado
El Algoritmo 5.3 describe la fase KEM del proceso de descifrado de la versión

de ECIES desarrollada para PC, en la que se obtiene el material del que se derivan
las claves de cifrado y autenticación. Por su parte, el Algoritmo 5.4 muestra la fase
DEM del proceso de descifrado de dicha versión, donde se utilizan las claves de
cifrado y autenticación para recuperar el mensaje en claro.
De manera global, la entrada del proceso de descifrado está formada por un
criptograma 𝒞 y una clave privada 𝑣, mientras que la salida consiste en el mensaje
en claro 𝔪.
5.1.3. Aritmética de puntos de la curva y de elementos del

cuerpo finito
En todo desarrollo software de ECC es necesario implementar dos tipos de ope-

raciones: las referidas a los puntos de la curva, y las que operan con elementos del
cuerpo finito.
Algoritmo 5.3 Descifrado ECIES en la versión PC (fase KEM )

1. Interpretar 𝒞 como la concatenación 𝑈 ∣∣𝔠∣∣tag, verificando que las longitudes
y el formato de cada elemento de la cadena son correctos.
2. Recuperar la clave 𝑈 a partir de su representación binaria 𝑈 , comprobando

que el punto 𝑈 tiene orden 𝑞.
3. Realizar la multiplicación 𝑄 = (𝑥𝑄 , 𝑦𝑄 ) = 𝑣 𝑈 , y comprobar que 𝑄 ∕= 𝒪.
4. Obtener el dato 𝐾 mediante una de las siguientes opciones:
a) 𝐾 = KDF (𝑥𝑄 ).
b) 𝐾 = KDF (HASH (𝑥𝑄 )).
c) 𝐾 = KDF (𝑈 ∣∣𝑥𝑄 ).
d ) 𝐾 = KDF (𝑈 ∣∣HASH (𝑥𝑄 )).
Algoritmo 5.4 Descifrado ECIES en la versión PC (fase DEM )

1. Interpretar 𝐾 de una de las siguientes maneras, donde 𝑘𝐸𝑁 𝐶 es la clave de
cifrado simétrico, y 𝑘𝑀 𝐴𝐶 es la clave para la función de autenticación del
mensaje, estando las longitudes de ambos elementos determinadas por el
usuario:
a) 𝑘𝐸𝑁 𝐶 ∣∣𝑘𝑀 𝐴𝐶 .
b) 𝑘𝑀 𝐴𝐶 ∣∣𝑘𝐸𝑁 𝐶 .
2. Calcular la etiqueta MAC (𝔠||[dat]||long) utilizando la clave 𝑘𝑀 𝐴𝐶 y la fun-

ción MAC seleccionada por el usuario mediante las opciones de la aplicación,
donde dat y long son los elementos descritos en el Algoritmo 5.2. Si al rea-
lizar la comparación el resultado es tag ∕= 𝑀 𝐴𝐶(𝔠), devolver un error.
3. Descifrar el mensaje original mediante la clave 𝑘𝐸𝑁 𝐶 y el algoritmo de cifrado

simétrico seleccionado por el usuario, con lo que se obtiene 𝔪 = ENC −1 (𝔠).
5.1. Diseño del esquema ECIES a implementar 185
En lo que respecta a la aritmética de puntos de la curva, la complejidad de las

operaciones de suma de dos puntos 𝑃 y 𝑄 y de obtención de 2 𝑃 a partir del punto 𝑃
se puede determinar en función del número de operaciones que es necesario realizar
con los elementos de 𝔽𝑞 . En la estimación de la complejidad no se suelen tener en
cuenta las operaciones de suma y diferencia de elementos del cuerpo finito debido a
que, en comparación con las demás operaciones, son las que requieren menor tiempo
de computación.
Dados los elementos 𝑎, 𝑏 ∈ 𝔽𝑞 , las operaciones que se utilizan en la práctica
para estimar la complejidad de una determinada implementación de la aritmética
de puntos son las siguientes:
∙ Multiplicación: 𝑎 ⋅ 𝑏.
∙ Inversión: 𝑎−1 .
∙ Elevación al cuadrado: 𝑎2 .
Tal como se indicó en §2.6.3.3, la suma de los puntos 𝑃 y 𝑄 realizada con coorde-
nadas afines requiere 1 inversión, 2 multiplicaciones y 1 elevación al cuadrado tanto
en 𝔽𝑝 como en 𝔽2𝑚 , mientras que para obtener el punto 2 𝑃 a partir de 𝑃 igual-
mente con coordenadas afines es necesario realizar 1 inversión, 2 multiplicaciones y
2 elevaciones al cuadrado al utilizar la fórmula para 𝔽𝑝 y una elevación al cuadrado
menos si se emplea la fórmula para 𝔽2𝑚 .
Existen otros sistemas de coordenadas que utilizan coordenadas proyectivas y
ecuaciones homogéneas de las curvas (coordenadas proyectivas estándar, Jacobianas,
López-Dahab, mixtas, etc.) [50, 99]. Estos sistemas implementan la aritmética de
puntos de manera más eficiente, dado que en los cálculos con coordenadas proyectivas
no es necesario realizar operaciones de inversión, que son las más costosas desde un
punto de vista computacional (aunque es cierto que, a cambio, en estos sistemas
crece el número de multiplicaciones y elevaciones al cuadrado). Sin embargo, en
esta Tesis se han utilizado exclusivamente las fórmulas con coordenadas afines en la
implementación de la aritmética de puntos. Los motivos para esta decisión son los
siguientes:
1. La utilización de coordenadas afines produce que el desarrollo y depuración

del código Java sea más sencillo, ya que es posible comparar los resultados con
los de otras implementaciones (Bouncy Castle, FlexiProvider, etc.).
2. Debido a las características de las plataformas hardware utilizadas y a la venta-
ja comparativa del PC (procesador de 32 bits, memoria ilimitada en compara-
ción con las necesidades del programa, etc.), la ejecución de la implementación
para PC es de forma natural más rápida que la ejecución de la implementación
para tarjetas Java Card, por lo que la optimización de la versión de ECIES
para PC no ha sido considerado un objetivo prioritario.
3. Puesto que no ha sido posible obtener datos sobre el sistema de coordenadas

implementado por las tarjetas inteligentes utilizadas en esta Tesis al tratarse
de un dato confidencial, no podrá realizarse ninguna comparación basada en
este elemento.
5.2. Diagrama de clases

La aplicación ECIES que se ha desarrollado para entornos PC como parte de
esta Tesis Doctoral está compuesta por 22 clases (agrupadas por conveniencia dentro
del paquete victor.tesis), tal como puede observarse en la Figura 5.1, donde las
clases pertenecientes a la aplicación aparecen en color azul, mientras que las clases
estándar FileFilter, FileView, JDialog, JFrame, Object y PlainDocument de
Java, de las que heredan algunas de las clases del programa, aparecen en color gris.
A continuación se incluye una breve descripción de cada una de las clases, listadas
por orden alfabético:
∙ Constantes
Interfaz que incluye algunas constantes utilizadas por las demás clases del
programa.
∙ Curva
La clase abstracta Curva define los métodos que serán implementados por las
clases CurvaFp y CurvaF2m, y que contienen la lógica para crear y utilizar
curvas elípticas definidas sobre un cuerpo finito.
∙ CurvaF2m
La clase CurvaF2m incluye la implementación adaptada a los cuerpos finitos
binarios de los métodos definidos por la clase abstracta Curva.
∙ CurvaFp
La clase CurvaFp incluye la implementación adaptada a los cuerpos finitos
primos de los métodos definidos por la clase abstracta Curva.
∙ ECIES
ECIES es la clase principal de la aplicación, y por ello contiene el método main.
Desde ECIES se realizan las invocaciones a las demás clases del paquete, siendo
responsable además de generar la interfaz gráfica y gestionar el procesamiento
provocado por las acciones del usuario.
∙ ElementoCuerpo
5.2. Diagrama de clases 187
Figura 5.1: Diagrama de clases de la aplicación ECIES

La clase abstracta ElementoCuerpo define los métodos con denominación co-

mún que serán implementados por ElementoCuerpoFp y ElementoCuerpoF2m,
y que contienen la lógica para definir y gestionar elementos de un cuerpo finito.
∙ ElementoCuerpoF2m
La clase ElementoCuerpoF2m incluye la implementación adaptada a los cuer-
pos finitos binarios de los métodos definidos por la clase ElementoCuerpo.
∙ ElementoCuerpoFp
La clase ElementoCuerpoFp incluye la implementación adaptada a los cuerpos
finitos primos de los métodos definidos por la clase abstracta ElementoCuerpo.
∙ FicheroPubPri
La clase FicheroPubPri define los iconos azul y rojo utilizados por la aplica-
ción en las ventanas de selección de ficheros para identificar los archivos con
claves públicas y privadas, respectivamente.
∙ FiltroDocumentos
La clase FiltroDocumentos incluye los elementos que permiten limitar el tipo
de datos de entrada (dígitos, caracteres hexadecimales o alfabeto ASCII) de
las cajas de texto utilizadas por la aplicación.
∙ FiltroFicheros
La clase FiltroFicheros permite crear los filtros necesarios con el objetivo de
de mostrar únicamente los ficheros con extensión .pri y .pub en las ventanas
de selección de ficheros de claves públicas y privadas respectivamente.
∙ IntArray
La clase IntArray implementa la lógica de soporte para la realización de ope-
raciones relacionadas con bases polinómicas en cuerpos binarios.
∙ JDialogAcerca
La clase JDialogAcerca es utilizada para mostrar información sobre la versión
de la aplicación ECIES y sobre los autores del desarrollo.
∙ JDialogAyuda
La clase JDialogAyuda incluye los elementos gráficos de la ventana emergente
utilizada por ECIES para presentar al usuario la página HTML con informa-
ción sobre la aplicación.
∙ JDialogClave
La clase JDialogClave es utilizada por la aplicación ECIES durante la inter-
pretación de los contenidos de un fichero que contenga una clave privada, a fin
de permitir al usuario introducir su código de acceso a dicha clave.
5.2. Diagrama de clases 189
∙ JDialogDescompresión
La clase JDialogDescompresión implementa la funcionalidad ofrecida por la
ventana emergente del submenú Descompresión de puntos, descrito en §5.3.7.3.
∙ JDialogFicheros
La clase JDialogFicheros representa la ventana emergente utilizada por el
submenú Crear ficheros con claves, cuya funcionalidad está descrita en §5.3.7.1.
∙ JDialogGenerarClave
La clase JDialogGenerarClave implementa la lógica utilizada por la ventana
emergente del submenú Clave aleatoria, descrito en §5.3.7.2.
∙ Punto
La clase abstracta Punto define los métodos que serán implementados por las
clases PuntoFp y PuntoF2m, y que contienen la lógica para crear puntos de una
curva elíptica definida sobre un cuerpo finito y operar con ellos.
∙ PuntoF2m
La clase PuntoF2m incluye la implementación adaptada a los cuerpos finitos
binarios de los métodos definidos por la clase abstracta Punto.
∙ PuntoFp
La clase PuntoFp incluye la implementación adaptada a los cuerpos finitos
primos de los métodos definidos por la clase abstracta Punto.
∙ Utilidades
La clase Utilidades incluye los métodos para realizar conversiones entre ele-
mentos de tipo array de bytes, BigInteger y las cadenas de texto que repre-
sentan un contenido hexadecimal o decimal. De manera adicional, esta clase
incluye las funciones para generar y convertir texto en los formatos ASCII y
Base64.
La implementación de la aritmética de puntos de la curva y de elementos de los

cuerpos finitos se ha realizado utilizando la clase estándar BigInteger [209] de Java
SE, que permite operar con valores enteros de longitud variable, e incluye funciones
como la suma con otro elemento BigInteger (método add), el cálculo de la longitud
en bits del valor entero (biLength), la obtención del inverso módulo otro elemento
del mismo tipo (modInverse), el resultado de la operación XOR con otra variable
BigInteger (xor) o la exponenciación modular (modPow), entre otras funciones.
5.3. Descripción funcional de la aplicación

En este apartado se describen de manera detallada las funcionalidades de la apli-
cación ECIES para entorno PC, mostrando las diferentes pantallas que la conforman,
así como las opciones que se ofrecen al usuario. De esta manera se proporciona una
visión práctica de lo expuesto en los capítulos anteriores, representando un ejemplo
de las posibilidades de las aplicaciones para entorno PC que implementen capacida-
des de criptografía de curva elíptica.
Esta aplicación para PC se ha desarrollado utilizando el entorno de desarrollo
NetBeans 6.7 y Java SE 6. La Figura 5.2 muestra la ventana principal de NetBeans
con el proyecto del programa de cifrado ECIES seleccionado.
Figura 5.2: Ventana principal del entorno de desarrollo NetBeans
5.3.1. Ventana principal

La aplicación ECIES permite dos modos de funcionamiento: un modo sencillo
donde el usuario no necesita seleccionar parámetros de funcionamiento, pues éstos
ya están prefijados (correspondiéndose con los parámetros definidos en §5.3.3.1), y
un modo avanzado que posibilita realizar pruebas con múltiples combinaciones de
los parámetros disponibles en ECIES. El modo seleccionado por defecto es el modo
sencillo, aunque durante la ejecución del programa el modo activo puede modificarse
a través del menú Modo.
Al iniciar el programa, lo primero que aparece en pantalla es la ventana principal,
5.3. Descripción funcional de la aplicación 191
tal como muestra la Figura 5.3. En ella pueden observarse las tres zonas principales
en que se divide la pantalla, y que se corresponden con las áreas delimitadas mediante
un recuadro rojo, azul y verde respectivamente en la Figura 5.3.
∙ Barra del menú principal: proporciona acceso a todos los menús y opciones
del programa. Los elementos que se encuentran disponibles en el modo sencillo
cuando se inicia la ejecución son Programa, Modo, Curvas, Utilidades y Cuerpo
GF(𝑝), mientras que si se utiliza el modo avanzado entonces también estarán
disponibles los elementos Perfiles y Test.
∙ Barra de pestañas: permite seleccionar la pestaña activa mediante una presen-

tación tabular. En el modo sencillo las pestañas disponibles son Parámetros,
Cifrado y Descifrado, a las que se añade la pestaña Configuración en el modo
avanzado.
∙ Pestaña activa: área de presentación donde se sitúan los elementos pertene-

cientes la pestaña en uso.
5.3.2. Menú Programa

El menú Programa consta de los submenús Aspecto, Ayuda, Acerca de y Salir.
5.3.2.1. Submenú Aspecto
La opción Aspecto (ver Figura 5.4) permite adaptar las características de todos
los elementos de la aplicación (textos, iconos, colores, etc.) a las de los temas grá-
ficos disponibles en Java. Las posibilidades existentes en la versión Java SE 6 para
plataformas PC son:
∙ Metal: apariencia Java multiplataforma presente desde las primeras versiones

del JDK.
∙ Nimbus: nueva apariencia Java multiplataforma disponible desde la revisión

10 de Java SE 6.
∙ Motif: aspecto Unix.
∙ Windows: apariencia nativa de las aplicaciones Windows.
∙ Windows Clásico: tema gráfico muy similar al anterior pero con un aspecto
más clásico.
Figura 5.3: Ventana principal de la aplicación
Figura 5.4: Opciones del menú Programa

Por motivos estéticos, se ha decidido implementar únicamente los dos temas

más modernos, en concreto Nimbus (Figura 5.5) y Windows (Figura 5.6). Si la
distribución Java SE instalada en el PC de trabajo implementa la estética Nimbus,
éste será el tema seleccionado por defecto al iniciar la aplicación. En caso contrario,
el aspecto gráfico utilizado será el propio de Windows.
Figura 5.5: Ejemplo de ventana con aspecto Nimbus
Figura 5.6: Ejemplo de ventana con aspecto Windows
5.3.2.2. Submenú Ayuda
La opción Ayuda (ver Figura 5.4) permite acceder a una ventana en la que se
presenta la ayuda del programa en formato HTML, tal como puede apreciarse en la
Figura 5.7.
Figura 5.7: Ventana de la opción Ayuda
5.3.2.3. Submenú Acerca de
La opción Acerca de (ver Figura 5.4) muestra información general sobre la versión
del programa y los responsables del desarrollo, tal como aparece en la Figura 5.8.
5.3.2.4. Submenú Salir
La opción Salir (ver Figura 5.4), al igual que el icono situado en la esquina su-
perior derecha en todas las aplicaciones Windows, permite abandonar la aplicación.
Sin embargo, en previsión de la activación accidental de esta opción, antes de
abandonar el programa se mostrará al usuario una pantalla de confirmación, tal
como queda reflejado en la Figura 5.9.
5.3.3. Menú Modo
El menú Modo permite seleccionar el modo de uso sencillo o avanzado, tal como
se detalla en los siguientes apartados.
Figura 5.8: Ventana de la opción Acerca de
Figura 5.9: Pantalla de confirmación de la opción Salir

5.3.3.1. Opción Sencillo
El modo sencillo (Figura 5.10) utiliza una parametrización fija del esquema
ECIES, correspondiente a la versión ECIES-3, que consiste en los siguientes ele-
mentos:
∙ Función resumen HASH : SHA-256.
∙ Función KDF : KDF2.
∙ Función MAC : HMAC-SHA-256-256.
∙ Función de cifrado ENC : AES en modo CBC con relleno PKCS#5.
∙ Longitud de la clave MAC : 32 bytes.
∙ Longitud de la clave de cifrado: 32 bytes.
∙ Inclusión de la clave temporal del emisor como parámetro de KDF : activado.
∙ Interpretación de la salida de la función KDF : ENC ||MAC.
∙ Representación binaria: comprimida.
Junto a la utilización de los parámetros anteriores, el modo sencillo oculta los

menús Perfiles y Test de la barra de menús, así como la pestaña Configuración, ya
que estos elementos sólo tienen utilidad en el modo avanzado.
Figura 5.10: Opción Sencillo
5.3.3.2. Opción Avanzado
El modo avanzado (Figura 5.11) permite, en comparación con el modo senci-

llo, especificar todos los parámetros para los que el esquema ECIES puede utilizar
distintas opciones. En concreto, los elementos que es posible parametrizar son los
siguientes:
Figura 5.11: Opción Avanzado
∙ Función resumen HASH.
∙ Función KDF.
∙ Función MAC.
∙ Función de cifrado ENC.
∙ Inclusión de la clave pública temporal del emisor como parámetro de KDF.
∙ Utilización de la primera coordenada del secreto compartido o de su resumen.
∙ Interpretación de la salida de la función KDF.
∙ Representación binaria comprimida o sin comprimir.
Además de lo anterior, el modo avanzado habilita los menús Perfiles y Test de

la barra de menús, así como la pestaña Configuración.
5.3.4. Menú Perfiles (modo avanzado)

El menú Perfiles (Figura 5.12) permite, en el modo avanzado, definir los valores
de los elementos de la pestaña Configuración relacionados con un mismo modo
de operación. Las opciones que el usuario puede elegir están relacionadas con las
configuraciones M1, M2, P1, P2 y P3 descritas en §7.2 y utilizadas en las pruebas
del Capítulo 7.
Figura 5.12: Opciones del menú Perfiles
5.3.4.1. Opción Configuración M1
La opción Configuración M1, diseñada para su utilización por la aplicación de

PC, emplea los siguientes valores:
∙ Cuerpo sobre el que se define la curva elíptica: 𝔽2𝑚 .
∙ Función HASH : SHA-256.
∙ Función KA: DH.
∙ Función ENC : AES en modo CBC con relleno PKCS#5.
∙ Longitud de la clave de cifrado simétrico: 32 bytes.
∙ Inclusión de la clave temporal del emisor como parámetro de KDF : sí.
∙ Utilización de la coordenada del secreto compartido o de su resumen: coorde-

nada.
∙ Representación binaria de los puntos de la curva: comprimida.
5.3.4.2. Opción Configuración M2
La opción Configuración M2, diseñada para su utilización tanto por la aplicación

de PC como por las tarjetas JCOP 41, personaliza los elementos de ECIES con los
siguientes valores:
∙ Cuerpo sobre el que se define la curva elíptica: 𝔽2𝑚 .
∙ Función ENC : TDES en modo CBC sin relleno.
∙ Inclusión de la clave temporal del emisor como parámetro de KDF : no.
∙ Utilización de la coordenada del secreto compartido o de su resumen: resumen.
∙ Representación binaria de los puntos de la curva: sin comprimir.
5.3.4.3. Opción Configuración P1
La opción Configuración P1, diseñada para su utilización por la aplicación de

PC, personaliza los elementos de ECIES con los siguientes valores:
∙ Cuerpo sobre el que se define la curva elíptica: 𝔽𝑝 .
∙ Función ENC : AES en modo CBC con relleno PKCS#5.
∙ Inclusión de la clave temporal del emisor como parámetro de KDF : sí.

nada.
∙ Representación binaria de los puntos de la curva: comprimida.
La opción Configuración P2, diseñada para su utilización tanto por la aplicación

de PC como por las tarjetas JCOP J3A, utiliza los siguientes elementos:
∙ Función ENC : TDES en modo CBC sin relleno.
∙ Utilización de la coordenada del secreto compartido o de su resumen: resumen.
La opción Configuración P3, diseñada para su utilización tanto por la aplicación

de PC como por las tarjetas JCOP J3A, personaliza los elementos de ECIES con
los siguientes valores:

∙ Función ENC : AES en modo CBC sin relleno.

nada.
5.3.5. Menú Test (modo avanzado)

El menú Test es similar al menú Perfiles, puesto que permite configurar los pa-
rámetros de ECIES de la pestaña Configuración en el modo avanzado, pero además
añade los valores necesarios de la pestaña Parámetros de acuerdo a los documentos
de prueba relacionados en cada caso.
5.3.5.1. Submenú ISO/IEC
El submenú ISO/IEC (Figura 5.13) incluye los tests C.2.2 y C.2.3 recogidos en
ISO/IEC 18033-2 [136].
Figura 5.13: Submenú ISO/IEC del menú Test
5.3.5.2. Submenú SECG
El submenú SECG (Figura 5.14) incluye los tests GEC2-3.1 y GEC2-3.2 recogi-
dos en el documento SECG GEC 2 [253].
Figura 5.14: Submenú SECG del menú Test
5.3.6. Menú Curvas

El menú Curvas permite cargar en la pestaña Parámetros información corres-
pondiente a la curva seleccionada en función de su proveedor y del identificador
asignado a la curva.
5.3.6.1. Submenú ANSI
El submenú ANSI (Figura 5.15) incluye las siguientes curvas definidas sobre
cuerpos primos y binarios en el documento ANSI X9.62 [15]:
∙ Curvas sobre 𝔽𝑝 : ansix9p192r1, ansix9p192k1, ansix9p224r1, ansix9p224k1, an-

six9p256r1, ansix9p256k1, ansix9p384r1 y ansix9p521r1.
∙ Curvas sobre 𝔽2𝑚 : ansix9t163r2, ansix9t163k1, ansix9t193r1, ansix9t193r2, an-

six9t233r1, ansix9t233k1, ansix9t239k1, ansix9t283r1, ansix9t283k1, ansix9t409r1,
ansix9t409k1, ansix9t571r1 y ansix9t571k1.
El significado de los elementos utilizados en los identificadores de las curvas

ANSI se explica a continuación:
∙ ansix9 : identifica las curvas definidas por ANSI en [15].
∙ p: indica que se trata de una curva sobre cuerpos primos.
∙ t: identifica las curvas sobre cuerpos binarios.
∙ Primera cadena de dígitos: expresa el tamaño en bits del cuerpo sobre el que
está definida la curva.
∙ r : informa que los coeficientes de la curva se han generado de forma aleatoria

mediante una semilla y una función resumen de acuerdo al procedimiento
descrito en [15].
Figura 5.15: Curvas correspondientes al submenú ANSI
∙ k : identifica las curvas de Koblitz (también conocidas como curvas anóma-

las binarias) que facilitan la realización de operaciones con los puntos de la
curva. En curvas sobre cuerpos binarios, las curvas de Koblitz están definidas
mediante la ecuación 𝑦 2 + 𝑥 𝑦 = 𝑥3 + 𝑎 𝑥2 + 1, con 𝑎 ∈ {0, 1}. ANSI X9.62
también utiliza el término k para referirse a curvas definidas sobre cuerpos
primos, dadas por la ecuación 𝑦 2 = 𝑥3 + 𝑎 𝑥 + 𝑏, donde 𝑎 = 0 y el valor de 𝑏 es
muy pequeño en comparación con 𝑝 (3, 5, 7, etc.).
∙ Dígito final: permite diferenciar curvas donde el resto de los parámetros utili-
zados por esta notación coinciden.
Es importante resaltar que las curvas publicadas en la versión de 2005 del es-
tándar X9.62 no coinciden con las incluidas en la edición de 1998, puesto que tal
como se describe en [15], algunas se eliminaron por no ser consideradas seguras a
la vista de los últimos avanzas en criptoanálisis (c2pnb176w1, c2pnb163v3, etc.).
De manera adicional, la edición de 2005 cambió los identificadores de las restantes
curvas (por ejemplo, la curva ansix9p192r1 de la edición de 2005 es la misma que la
curva prime192v1 de la edición de 1998).
5.3.6.2. Submenú Brainpool
El submenú Brainpool (Figura 5.16) incluye las siguientes curvas definidas sobre
cuerpos primos, tal como aparecen recogidas en la página web del grupo de trabajo
Brainpool [33]:
∙ Curvas sobre 𝔽𝑝 : P160r1, P192r1, P224r1, P256r1, P320r1, P384r1 y P512r1.
Es necesario indicar que Brainpool no dispone de curvas sobre cuerpos binarios

𝔽2𝑚 . El significado de los elementos utilizados en los identificadores de las curvas
Brainpool se muestra a continuación:
∙ P : identifica las curvas sobre cuerpos primos.

∙ r : informa que los coeficientes de la curva se han generado aleatoriamente
según el procedimiento descrito en [34].
∙ Dígito final: permite identificar diferentes curvas donde el resto de los pará-
metros utilizados por esta notación coinciden.
Figura 5.16: Curvas correspondientes al submenú Brainpool
5.3.6.3. Submenú NIST
El submenú NIST (Figura 5.17) incluye las siguientes curvas definidas sobre
cuerpos primos y binarios en el documento FIPS 186-3 [184]:
∙ Curvas sobre 𝔽𝑝 : P-192, P-224, P-256, P-384 y P-521.

∙ Curvas sobre 𝔽2𝑚 : K-163, B-163, K-233, B-233, K-283, B-283, K-409, B-409,
K-571 y B-571.
Figura 5.17: Curvas correspondientes al submenú NIST
El significado de los elementos utilizados como parte de los identificadores de las

curvas NIST es el siguiente:
∙ P : identifica las curvas sobre cuerpos primos.
∙ B : indica que se trata de una curva sobre cuerpos binarios.
∙ K : indica que se trata de una curva de Koblitz (definida sobre cuerpos bina-
rios).
∙ Cadena de dígitos: expresa el tamaño en bits del cuerpo sobre el que está
definida la curva.
5.3.6.4. Submenú SECG
El submenú SECG (Figura 5.18) incluye las siguientes curvas definidas sobre
cuerpos primos y binarios en el documento SEC 2 [255]:
∙ Curvas sobre 𝔽𝑝 : secp112r1, secp112r2, secp128r1, secp128r2, secp160k1, secp-

160r1, secp160r2, secp192k1, secp224k1, secp224r1, secp256k1, secp384r1 y
secp521r1.
Figura 5.18: Curvas correspondientes al submenú SECG
∙ Curvas sobre 𝔽2𝑚 : sect113r1, sect113r2, sect131r1, sect131r2, sect163k1, sect-

163r1, sect163r2, sect193r1, sect193r2, sect233k1, sect233r1, sect239k1, sect-
283k1, sect283r1, sect409k1, sect409r1, sect571k1 y sect571r1.
El significado de los elementos utilizados como parte de los identificadores de las

curvas del consorcio SECG se detalla a continuación:
∙ secp: identifica las curvas sobre cuerpos primos.
∙ sect: indica que se trata de una curva sobre cuerpos binarios.
∙ r : indica que los coeficientes de la curva han sido seleccionados aleatoriamente

de forma verificable.
∙ k : informa que se trata de una curva de Koblitz (definida sobre cuerpos bina-
rios).
∙ Dígito final: permite identificar diferentes curvas donde el resto de los pará-
metros utilizados por esta notación coinciden.
5.3.7. Menú Utilidades

El menú Utilidades ofrece funcionalidades que, sin ser imprescindibles para la
utilización del programa de cifrado ECIES, facilitan considerablemente su uso.
5.3.7.1. Opción Crear ficheros con claves
La opción Crear ficheros con claves (ver Figura 5.19) permite generar un par de
claves utilizando la información de las curvas estándares referidas en §5.3.6, alma-
cenando la información resultante en un fichero con extensión .pri que contiene la
clave privada y un fichero con extensión .pub que alberga la clave pública.
Figura 5.19: Opciones del menú Utilidades
Al seleccionar esta opción, el usuario debe introducir o seleccionar en la nueva

ventana (Figura 5.20) los siguientes datos:
∙ Cuerpo (obligatorio): posibilidad de elegir entre cuerpos primos o binarios.
∙ Proveedor de la curva (obligatorio): organismo responsable de la generación

y publicación de los datos de la curva. Las opciones disponibles son ANSI,
Brainpool, NIST y SECG.
∙ Curva (obligatorio): nombre identificativo empleado por el proveedor para cada

curva.
Figura 5.20: Ventana de creación de los ficheros de claves
∙ Código de seguridad (obligatorio): código de acceso o contraseña para permitir

el almacenamiento seguro de la clave. La implementación de la seguridad de
este almacenamiento se realiza mediante la función resumen SHA-256 y el
algoritmo de cifrado AES, de manera que la clave privada nunca se almacenará
en claro, siendo necesario introducir el código de seguridad para poder utilizar
la clave privada en las operaciones de descifrado. La clave con la que se cifra
la información consiste en los primeros 16 bytes de la salida de la función
SHA-256, donde la entrada se corresponde con el código de seguridad.
∙ Nombre de fichero (obligatorio): los dos ficheros a generar, tanto el que contiene
la clave pública como el utilizado para almacenar la clave privada, comparti-
rán el mismo nombre de fichero, diferenciándose en la extensión (.pub y .pri,
respectivamente).
∙ Semilla de aleatoriedad (opcional): cadena utilizada para construir la semilla

de aleatoriedad que será empleada para generar la clave privada. La cadena
introducida no se utiliza directamente para generar la semilla, siendo la salida
de la función resumen SHA-256 tomando como entrada dicha cadena lo que se
utiliza como dato para generar la semilla de aleatoriedad, por lo que si no se
modifica ni la curva seleccionada ni la semilla introducida en dos generaciones
distintas, el resultado será el mismo. Por el contrario, si esta opción se deja
vacía, el programa generará una semilla distinta de forma pseudoaleatoria en
cada proceso de creación de los ficheros de claves mediante el Algoritmo 5.5,
que ha sido diseñado con el único objetivo de asegurar que en cada ejecución
se generen semillas distintas. A continuación, la semilla generada es utiliza-
da como argumento de la clase Random para obtener el valor pseudoaleatorio
deseado.
∙ Información adicional (opcional): texto que, en caso de ser incluido en los

ficheros de claves, será utilizado por el programa como identificador de la
clave.
Algoritmo 5.5 Generación de una semilla aleatoria

Ejecutar el siguiente bucle seis veces:
1. Obtener el tiempo en milisegundos mediante la función estándar del lenguaje
Java SE System.currentTimeMillis().
2. Multiplicar el valor obtenido por el número de iteración.
3. Identificar los últimos tres dígitos del resultado de la multiplicación.
4. Concatenar esos tres dígitos con los obtenidos en las anteriores iteraciones,
formando una cadena final de dieciocho dígitos.
Los ficheros de claves generados contienen toda la información necesaria para

poder identificar las claves y realizar las operaciones de cifrado y descifrado, uti-
lizando internamente una estructura XML para almacenar los distintos datos. A
continuación se muestra un ejemplo del contenido de un fichero .pub que alberga la
clave pública de un usuario:
<?xml version=’1.0’ encoding=’ISO-8859-1’ standalone=’yes’?>


<parámetros>
<param id=’1’>
<notación>HEXA</notación>
<cuerpo>Fp</cuerpo>
<clave>
<tipo>Pública</tipo>
<proveedor>SEC</proveedor>
<identificador>secp112r1</identificador>
</clave>
<info>Clave de Víctor</info>
DB7C2ABF62E35E668076BEAD208B
<a>DB7C2ABF62E35E668076BEAD2088</a>
659EF8BA043916EEDE8911702B22
<Gx>09487239995A5EE76B55F9C2F098</Gx>
<Gy>A89CE5AF8724C0A23E0E0FF77500</Gy>
<n>DB7C2ABF62E35E7628DFAC6561C5</n>
<Vx>CBB0C998897515D8AF9E474ADEF0</Vx>
<Vy>7B492D22D7872C4CCAB5B58620CC</Vy>
</param>
</parámetros>
Continuando con el mismo ejemplo, el fichero .pri que contiene la clave privada
del usuario anterior tendría el siguiente contenido:

<parámetros>
<param id=’1’>
<cuerpo>Fp</cuerpo>
<clave>
<tipo>Privada</tipo>
<identificador>secp112r1</identificador>
</clave>
<info>Clave de Víctor</info>
DB7C2ABF62E35E668076BEAD208B
<a>DB7C2ABF62E35E668076BEAD2088</a>
659EF8BA043916EEDE8911702B22
<Gx>09487239995A5EE76B55F9C2F098</Gx>
<Gy>A89CE5AF8724C0A23E0E0FF77500</Gy>
<n>DB7C2ABF62E35E7628DFAC6561C5</n>
<uC>7D1C0CF1FC2B741B960A7AE0093B7485</uC>
</param>
</parámetros>
A continuación se muestra otro ejemplo de ficheros .pub y .pri, en esta ocasión

representando un par de claves definidas sobre un cuerpo binario:

<parámetros>
<param id=’1’>
<cuerpo>F2m</cuerpo>
<clave>
<tipo>Pública</tipo>
<identificador>sect113r1</identificador>
</clave>
<info>Clave de Luis</info>
<m>71</m>
<k3></k3>
<k2></k2>
<k1>09</k1>
<a>3088250CA6E7C7FE649CE85820F7</a>
E8BEE4D3E2260744188BE0E9C723
<Gx>9D73616F35F4AB1407D73562C10F</Gx>
<Gy>A52830277958EE84D1315ED31886</Gy>
<n>0100000000000000D9CCEC8A39E56F</n>
<Vx>5AC878E613A8C0EB857D2C007453</Vx>
<Vy>5F9964C68A87793F17F13669DB44</Vy>
</param>
</parámetros>

<parámetros>
<param id=’1’>
<cuerpo>F2m</cuerpo>
<clave>
<tipo>Privada</tipo>
<identificador>sect113r1</identificador>
</clave>
<info>Clave de Luis</info>
<m>71</m>
<k3></k3>
<k2></k2>
<k1>09</k1>
<a>3088250CA6E7C7FE649CE85820F7</a>
E8BEE4D3E2260744188BE0E9C723
<Gx>9D73616F35F4AB1407D73562C10F</Gx>
<Gy>A52830277958EE84D1315ED31886</Gy>
<n>0100000000000000D9CCEC8A39E56F</n>
<uC>9442D1ACEE5F3C384AA8060424A3CCEA</uC>
</param>
</parámetros>
El significado de cada uno de los elementos de ambos ficheros XML es el siguiente:

∙ <param id =’1’>: número de clave (ya sea pública o privada) relativo al fi-
chero, dado que los ficheros .pri y .pub permiten ser utilizados como agendas
de claves y almacenar más de una clave.
∙ <notación>: indicación relativa a la notación empleada para representar los

datos. El único valor utilizado en la generación de los ficheros es HEXA, lo que
implica que los datos se encuentran definidos en formato hexadecimal. Esta
decisión de diseño no afecta al proceso de lectura de los ficheros de claves
como parte de las operativas de cifrado y descifrado, donde además del valor
HEXA también es posible utilizar el valor DECIMAL, indicando que los datos se
encuentran representados como números en esta base.
∙ <cuerpo>: cuerpo de la curva elíptica utilizada en la generación de las claves.

En función del cuerpo seleccionado, los posibles textos para esta opción son
Fp y F2m.
∙ <clave>: cadena informativa que incluye los elementos <tipo> (que puede
tener los valores Privada y Pública), <proveedor> (cuyos valores posibles
son ANSI, Brainpool, NIST y SEC) y por último <identificador>, el nombre
específico que cada proveedor otorga a sus curvas.
∙ <info>: información adicional utilizada por el programa para presentarla por

pantalla, de manera que el usuario pueda seleccionar la clave adecuada durante
los procesos de cifrado y descifrado.
∙ <a>, , <Gx>, <Gy>, <n>: parámetros comunes para curvas definidas tanto
sobre un cuerpo primo como binario.
∙ : parámetro asociado a las curvas definidas sobre un cuerpo primo.
∙ <m>, <k3>, <k2>, <k1>: parámetros de la curvas definidas sobre un cuerpo

binario.
∙ <Vx>, <Vy>: coordenadas del punto que representa la clave pública creada.
∙ <uC>: clave privada del usuario cifrada con el algoritmo AES mediante el código
de acceso.
5.3.7.2. Opción Clave aleatoria
La opción Clave aleatoria (ver Figura 5.19) ofrece la posibilidad de generar una
clave privada pseudoaleatoria a partir de los datos de entrada, que dependiendo del
cuerpo de trabajo son:
∙ Cuerpos 𝔽𝑝 : número primo 𝑝 y semilla de aleatoriedad.

∙ Cuerpos 𝔽2𝑚 : parámetro 𝑚, que representa el número de bits utilizado en la

representación binaria de los elementos de ese cuerpo, y semilla de aleatoriedad.
Dependiendo del cuerpo de trabajo, y que es seleccionable por el usuario desde

el menú Cuerpo GF(𝑝)/Cuerpo GF(2^m) descrito en §5.3.8, la ventana de trabajo
del menú Clave aleatoria es diferente, tal como puede apreciarse en las Figuras 5.21
y 5.22.
Figura 5.21: Ventana de generación de clave en cuerpos 𝔽𝑝
Figura 5.22: Ventana de generación de clave en cuerpos 𝔽2𝑚

5.3.7.3. Opción Descompresión de puntos
La opción Descompresión de puntos (ver Figura 5.19) permite, tras introducir los
datos asociados a una curva elíptica y a un punto de la curva en formato comprimido,
obtener ambas coordenadas de dicho punto.
Dependiendo del cuerpo de trabajo, la ventana del menú Descompresión de pun-
tos es diferente, tal como puede comprobarse en las Figuras 5.23 y 5.24.
Figura 5.23: Ventana de descompresión de puntos en cuerpos 𝔽𝑝
5.3.8. Menú Cuerpo GF(𝑝)/Cuerpo GF(2^m)

El último elemento del menú principal permite intercambiar el tipo de cuerpo
sobre el que se encuentra definida la curva elíptica de trabajo. Si el nombre de la
opción es Cuerpo GF(𝑝), al pulsar sobre ese título el usuario comprobará que el
nombre es sustituido por Cuerpo GF(2^m), siendo seleccionada de manera automá-
tica la pestaña Parámetros donde se encuentran las cajas de texto de los parámetros
asociados al nuevo cuerpo. Las Figuras 5.25 y 5.26 muestran el aspecto de la barra
de menú principal cuando el cuerpo de trabajo es 𝔽𝑝 y 𝔽2𝑚 respectivamente.
Figura 5.24: Ventana de descompresión de puntos en cuerpos 𝔽2𝑚
De forma equivalente, si se encuentra seleccionada la opción Cuerpo GF(2^m) y

el usuario pulsa sobre ese título, el nombre del elemento cambiará por el de Cuerpo
GF(𝑝), siendo seleccionada automáticamente la pestaña Parámetros donde se sitúan
las cajas de texto con los parámetros asociados al nuevo cuerpo.
Figura 5.25: Menú principal con el elemento Cuerpo GF(𝑝) activado
5.3.9. Pestaña Configuración (en modo avanzado)

La pestaña Configuración, que sólo es visible cuando se encuentra seleccionado
el modo avanzado, permite configurar los elementos de ECIES independientemente
Figura 5.26: Menú principal con el elemento Cuerpo GF(2^m) activado
de si el cuerpo de trabajo es 𝔽𝑝 o 𝔽2𝑚 . La Figura 5.27 muestra los elementos de esta

pestaña, y que son presentados a continuación indicando las opciones disponibles.
∙ Función resumen HASH :
SHA-1.
SHA-256.
SHA-384.
SHA-512.
∙ Función de derivación de claves KDF :
KDF1.
KDF2.
∙ Función de generación de códigos MAC :
HMAC-SHA-1-160.
HMAC-SHA-256-256.
HMAC-SHA-384-384.
HMAC-SHA-512-512.
∙ Función de cifrado simétrico ENC :
XOR.
AES en modo CBC con relleno PKCS#5.
AES en modo ECB con relleno PKCS#5.
TDES en modo CBC sin relleno.
TDES en modo CBC con relleno PKCS#5.
∙ Longitud en bytes de la clave a utilizar por la función MAC.

Figura 5.27: Pestaña Configuración
∙ Longitud en bytes de la clave a utilizar por el algoritmo de cifrado simétrico.

∙ Opción de incluir la clave pública temporal 𝑈 del emisor como entrada de la
función KDF.
∙ Utilización de la primera coordenada del dato secreto compartido 𝑢 𝑉 o de la
salida a través de la función resumen seleccionada previamente por el usuario.
∙ Orden en que se debe interpretar la salida de la función de generación de claves
(MAC ||ENC o ENC ||MAC ).
∙ Representación binaria de los puntos de la curva comprimida o sin comprimir.
5.3.10. Pestaña Parámetros

La pestaña Parámetros muestra los elementos de la curva elíptica a los que es
necesario dar valores para poder realizar operaciones de cifrado o descifrado con
ECIES. Esta operación puede realizarse mediante tres procedimientos:
1. Introducción manual de los parámetros por parte del usuario de la aplicación

a través de las cajas de texto de esta pestaña.
2. Selección de una de las curvas disponibles a través del menú Curvas, con lo
que la aplicación rellenará los campos relativos a la curva y el usuario de
la aplicación tendrá que añadir la información relativa a la clave pública del
receptor (para operaciones de cifrado) o de su propia clave privada (en el caso
de tratarse de una operación de descifrado).
3. Selección de la clave pública del destinatario o de la clave privada del propio

usuario de la aplicación mediante las opciones apropiadas de las pestañas Ci-
frado y Descifrado. En estos casos, si los ficheros que incluyen dichas claves
contienen todos los elementos necesarios, el usuario no deberá añadir ningún
dato en la pestaña Parámetros.
En los casos en los que la aplicación aporte algunos de los datos (es decir, el
usuario seleccione una curva o indique al programa el fichero con la clave a recupe-
rar), las cajas de texto de esta pestaña se mantienen habilitadas, lo que implica que
el usuario podría modificar dichos datos. Si dicha modificación conlleva algún error
(por ejemplo, el elemento generador o la clave pública no pertenecen a la curva mo-
dificada), éste será convenientemente detectado durante la ejecución de cualquiera
de las operaciones del programa (cifrado, descifrado, generación de la clave pública
a partir de los datos de la curva y de la clave privada, etc.).
En cuanto al contenido de esta pestaña, dependiendo de si el cuerpo finito de
trabajo, denominado de forma genérica 𝔽𝑞 , es 𝔽𝑝 o 𝔽2𝑚 , la pestaña Parámetros
mostrará distintos elementos, tal como puede apreciarse en las Figuras 5.28 y 5.29.
Independientemente del cuerpo finito seleccionado, los parámetros comunes que
aparecen en esta pestaña en ambos casos son los siguientes:
∙ a: primer parámetro de la curva elíptica 𝐸 cuya ecuación es (2.4) o (2.5), con

𝑎 ∈ 𝔽𝑞 .
∙ b: segundo parámetro de la curva elíptica, con 𝑏 ∈ 𝔽𝑞 .
∙ Gx : primera coordenada del generador 𝐺, donde 𝐺 = (𝐺𝑥 , 𝐺𝑦 ). 𝐺𝑥 es un

elemento del cuerpo base 𝔽𝑞 , mientras que 𝐺 es un punto de la curva elíptica.
∙ Gy: segunda coordenada del generador 𝐺, con 𝐺𝑦 ∈ 𝔽𝑞 .
∙ n: orden del punto 𝐺.

Figura 5.28: Pestaña Parámetros con el menú Cuerpo GF(𝑝) activado
∙ h: cofactor del punto 𝐺, de manera que ℎ = #𝐸(𝔽𝑞 )/𝑛, siendo #𝐸(𝔽𝑞 ) el

número de puntos de la curva elíptica.
∙ u: clave privada temporal del usuario emisor, donde 𝑢 ∈ 𝔽𝑞 .
∙ v : clave privada permanente del usuario receptor, siendo 𝑣 ∈ 𝔽𝑞 .
∙ Ux : primera coordenada de la clave pública temporal del usuario emisor. La

clave pública es 𝑈 , donde 𝑈 = (𝑈𝑥 , 𝑈𝑦 ). 𝑈𝑥 es un elemento de 𝔽𝑞 y 𝑈 es un
punto de la curva elíptica.
∙ Uy: segunda coordenada de la clave pública temporal del usuario emisor, donde
𝑈𝑦 ∈ 𝔽𝑞 .
∙ Vx : primera coordenada de la clave pública permanente del usuario receptor.

La clave pública es 𝑉 , donde 𝑉 = (𝑉𝑥 , 𝑉𝑦 ). 𝑉𝑦 es un elemento de 𝔽𝑞 , mientras
que 𝑉 es un punto de la curva elíptica.
Figura 5.29: Pestaña Parámetros con el menú Cuerpo GF(2^m) activado
∙ Vy: segunda coordenada de la clave pública permanente del usuario receptor,

donde 𝑉 𝑦 ∈ 𝔽𝑞 .
Cuando el menú Cuerpo GF(𝑝) está activado, el único elemento relacionado con
este cuerpo que aparece en la pestaña es:
∙ p: número primo utilizado por el cuerpo finito 𝔽𝑝 .
Por el contrario, cuando el menú Cuerpo GF(2^m) está activado, los nuevos
elementos que aparecen en la pestaña son:
∙ m: exponente utilizado por el cuerpo finito 𝔽2𝑚 .
∙ k3 : exponente del polinomio reductor 𝑓 (𝑥) = 𝑥𝑚 + 𝑥𝑘3 + 𝑥𝑘2 + 𝑥𝑘1 + 1.
∙ k2 : exponente del polinomio reductor 𝑓 (𝑥).

∙ k1 : exponente del polinomio reductor 𝑓 (𝑥).
Independientemente del cuerpo de trabajo, la pestaña Parámetros incluye los

siguientes elementos:
∙ Formato: representación de los datos precedentes en formato hexadecimal o

decimal.
∙ Resultado: información acerca del resultado de la ejecución.
∙ Generar : botón que permite calcular las coordenadas de las claves públicas 𝑈
y 𝑉 a partir de las claves privadas 𝑢 y 𝑣.
∙ Borrar : botón para el borrado de todos los datos de esta pantalla.
Si la operación de cálculo de las coordenadas 𝑈 y 𝑉 es correcta, el contenido del

elemento Resultado será el texto:
Proceso finalizado correctamente.
Por el contrario, los posibles mensajes de error que puede mostrar el elemento
Resultado son:
Falta el parámetro p, operación abortada.

Falta el parámetro m, operación abortada
Falta el parámetro k1, operación abortada.
Falta el parámetro Gx, operación abortada.
Falta el parámetro Gy, operación abortada.
Falta el parámetro n, operación abortada.
Falta el parámetro u, operación abortada.
Falta el parámetro v, operación abortada.
El punto U es el punto en el infinito (U=O).
El punto V es el punto en el infinito (V=O).
5.3.11. Pestaña Cifrado

La pestaña Cifrado muestra todos los elementos necesarios para generar un crip-
tograma a partir de un mensaje en claro utilizando ECIES. La ventana está divida
en tres secciones, delimitadas por recuadros de color verde, azul y rojo que se corres-
ponden, respectivamente, con las zonas de gestión de opciones, las cajas de texto y
los botones de operación, tal como puede apreciarse en la Figura 5.30.
La primera sección está formada por los siguientes elementos:
Figura 5.30: Pestaña Cifrado
∙ Clave pública receptor : clave pública permanente del destinatario del cripto-
grama. Si el usuario pulsa la opción Texto, la pestaña Parámetros pasará a ser
la pestaña en uso, de manera que el usuario pueda introducir manualmente los
datos asociados a la clave pública del receptor. En cambio, si el usuario elige la
opción Fichero, el programa permitirá seleccionar el fichero donde se encuentra
la clave pública, tal como puede apreciarse en la Figura 5.31. Si el procesa-
miento del fichero con la clave pública es correcto, en la pestaña Parámetros
aparecerán los datos obtenidos del fichero con extensión .pub seleccionado.
∙ Mensaje a cifrar : mensaje en claro que el emisor desea enviar al receptor. Si

el usuario pulsa la opción Texto (opción por defecto), deberá introducir el
mensaje manualmente, sin que exista ningún límite en la longitud del mensaje
generado por el usuario. Por el contrario, si el usuario elige la opción Fichero, el
programa permitirá seleccionar el fichero cuyo contenido binario será utilizado
como mensaje en claro, tal como puede observarse en la Figura 5.32. Si el
procesamiento del fichero que representa el mensaje es correcto y su tamaño
es superior a 1 Kbyte, aunque internamente se utilizará el fichero completo en

el proceso de cifrado, únicamente se mostrarán en la caja de texto asociada al
mensaje en claro los primeros 1024 bytes, utilizando una fuente de color azul
para indicar este hecho. En comparación, la fuente de texto de color negro
indica que todo el contenido del fichero se encuentra presente en la caja de
texto.
∙ Criptograma: tripleta de elementos resultado de la operativa de cifrado que el

emisor debe enviar al receptor tras su generación. Si el usuario pulsa la opción
Texto (opción por defecto), el contenido del criptograma será únicamente mos-
trado por pantalla en su caja de texto asociada. Por el contrario, si el usuario
elige la opción Fichero, el programa permitirá al usuario seleccionar un fichero
(Figura 5.33) de manera que, además de mostrarse el criptograma en la caja
de texto, su contenido será almacenado en el fichero indicado. Únicamente en
este último caso, si el tamaño del criptograma supera el límite de 1 Kbyte,
entonces sólo se mostrarán (utilizando de nuevo una fuente de color azul) los
primeros 1024 bytes del criptograma. Comparativamente, la fuente de texto de
color negro indica que el contenido del criptograma se encuentra íntegramente
representado en la caja de texto.
Figura 5.31: Selección del fichero con la clave pública
En caso de elegir la opción Fichero en cualquiera de los tres elementos anteriores,

aparecerá en la ventana principal del programa el nombre del fichero seleccionado
junto al elemento en cuestión, excepto en el caso de la clave pública del receptor,
donde si el fichero con la clave incluye el elemento <info>, y su contenido es válido,
entonces se mostrará la cadena de texto que contenga <info>. Si el fichero con la
clave pública contuviera más de una clave, y alguna de dichas claves no tuviera un
nodo <info> válido, a fin de poder identificar dicha clave, el programa calculará su
posición en el fichero de claves y mostrará el texto Clave sin identificador #i,
Figura 5.32: Selección del fichero con el mensaje en claro
Figura 5.33: Selección del fichero donde se almacenará el criptograma

donde i tendrá como valor la posición de la clave. Por último, si el fichero contuviera
solamente una clave, y el elemento <info> no fuera válido o no estuviera presente, el
programa utilizará como identificador el nombre del fichero. La Figura 5.34 muestra
las diversas variantes existentes en la representación del identificador de la clave
pública.
Figura 5.34: Modalidades de identificación de la clave pública
La segunda sección de la pestaña Cifrado está compuesta por las siguientes cajas
de texto:
∙ Mensaje a cifrar : contenido del mensaje en claro a cifrar (o sus primeros 1024
bytes en caso de que el mensaje se haya obtenido de un fichero y su longitud
sea mayor que ese límite).
∙ Etiqueta: elemento de uso opcional a utilizar por la función MAC.
∙ Criptograma: mensaje cifrado empaquetado (constituyendo una tripleta de

elementos) obtenido mediante el esquema ECIES (o sus primeros 1024 bytes
en caso de que el usuario haya decidido almacenar el criptograma en un fichero
y su longitud sea mayor que ese valor).
∙ Resultado: campo con información acerca del resultado de la ejecución.
Las cajas de texto del mensaje en claro y de la etiqueta permiten mostrar su con-
tenido interpretado como texto o en formato hexadecimal. En caso de que el mensaje
Figura 5.35: Contenido del mensaje en claro no interpretable como texto
a cifrar no sea interpretable como texto ASCII, al seleccionar el formato Texto apa-
recerá en una fuente de color rojo la leyenda El contenido no es interpretable
como texto, tal como muestra la Figura 5.35.
Asimismo, el programa permite visualizar el criptograma en formato hexadecimal
y Base64, permitiendo que pueda ser enviado de forma cómoda por correo electrónico
utilizando esta última codificación.
La tercera sección de la pestaña Cifrado está formada por los siguientes elemen-
tos:
∙ Cifrar : botón que desencadena la generación de un criptograma ECIES a partir

del mensaje en claro, la etiqueta y los parámetros asociados.
∙ Borrar : botón que permite borrar el contenido de las cajas de texto de esta
pantalla y devolver las opciones de configuración de la primera sección a su
estado inicial.
La Figura 5.36 muestra un ejemplo del proceso de cifrado, en el que se ha selec-

cionado la clave pública del receptor de un fichero que contiene un elemento <info>
válido (y que por tanto es el utilizado como identificador de la clave pública), el fiche-
ro Inicio de Don Quijote.txt contiene el mensaje en claro y el fichero Quijote
cifrado.out se empleará para almacenar el resultado de la operación.
Si la operación efectuada es correcta, los posibles mensajes de éxito que puede
mostrar el elemento Resultado son:
Clave pública recuperada correctamente.

Por el contrario, algunos de los posibles mensajes de error que puede mostrar el
elemento Resultado son:
Falta seleccionar la función resumen en Configuración.

Falta seleccionar la función KDF en Configuración.
Falta seleccionar la función MAC en Configuración.
Figura 5.36: Ejemplo de cifrado ECIES
Falta seleccionar la función de cifrado simétrico en Configuración.

Falta especificar la longitud de la clave MAC en Configuración.
Falta seleccionar la clave pública del receptor del mensaje.
El texto en Base64 del criptograma es incorrecto.
El punto generador G=(Gx,Gy) no pertenece a la curva.
La clave pública del receptor V=(Vx,Vy) no pertenece a la curva.
Longitud de la clave AES incorrecta.
Los ficheros security policy de Java necesitan ser sustituidos.
Error durante el cálculo del código MAC.
5.3.12. Pestaña Descifrado
La pestaña Descifrado muestra todos los elementos necesarios en el proceso de

descifrado de un criptograma mediante el esquema ECIES. La ventana está dividida
en tres secciones, delimitadas en la Figura 5.37 mediante recuadros de color verde,
azul y rojo, y que se corresponden con el área de gestión de opciones, las cajas de
texto y los botones de operación.
Figura 5.37: Pestaña Descifrado
La primera sección está formada por las siguientes opciones:
∙ Clave privada receptor : clave privada fija del destinatario del criptograma. Si el
usuario pulsa la opción Texto, la pestaña Parámetros pasará a ser la pestaña
en uso, de manera que el usuario pueda introducir manualmente los datos
asociados a su clave privada. En cambio, si el usuario elige la opción Fichero,
el programa permitirá seleccionar el fichero donde se encuentra la clave privada,
tal como puede comprobarse en la Figura 5.38. Si el procesamiento del fichero
con la clave privada es correcto, en la pestaña Parámetros aparecerán los datos
obtenidos del fichero con extensión .pri seleccionado.
∙ Criptograma: mensaje cifrado empaquetado (tripleta de elementos) que el emi-
sor ha enviado al receptor. Si el usuario pulsa la opción Texto (opción por de-
fecto), deberá introducir el criptograma manualmente, sin que exista ningún
límite en la longitud del criptograma introducido de esta forma por el usuario.

Por el contrario, si el usuario elige la opción Fichero, el programa permiti-
rá seleccionar el fichero cuyo contenido será utilizado como criptograma, tal
como puede observarse en la Figura 5.39. Si el procesamiento del fichero que
representa el mensaje es correcto y su tamaño es superior a 1 Kbyte, aunque
internamente se utilizará el fichero completo en el proceso de cifrado, única-
mente se mostrarán en la caja de texto asociada al criptograma los primeros
1024 bytes, utilizando una fuente de color azul para indicar este hecho. En
comparación, la fuente de texto de color negro indica que todo el contenido
del fichero se encuentra presente en la caja de texto.
∙ Mensaje descifrado: resultado de la operación de descifrado ECIES. Si el usua-

rio pulsa la opción Texto (opción por defecto), el contenido del mensaje des-
cifrado será únicamente mostrado por pantalla en su caja de texto asociada.
Por el contrario, si el usuario elige la opción Fichero, el programa permitirá al
usuario seleccionar un fichero (Figura 5.40) de manera que, además de mos-
trarse el mensaje en claro en la caja de texto, su contenido será almacenado en
el fichero indicado. Únicamente en este último caso, si el tamaño del mensaje
descifrado supera el límite de 1 Kbyte, entonces sólo se mostrarán (utilizando
de nuevo una fuente de color azul) los primeros 1024 bytes del mensaje. Com-
parativamente, la fuente de texto de color negro indica que el contenido del
mensaje en claro se encuentra incluido en la caja de texto.
Figura 5.38: Selección del fichero con la clave privada
En caso de elegir la opción Fichero en cualquiera de los tres elementos anteriores,

aparecerá en la ventana el nombre del fichero seleccionado junto al elemento en
cuestión, excepto en el caso de la clave privada del receptor del criptograma, donde
si el fichero con la clave incluye un elemento <info> válido, entonces se mostrará la
cadena de texto que contenga <info>. Si el fichero con la clave pública contuviera
Figura 5.39: Selección del fichero con el criptograma
Figura 5.40: Selección del fichero donde se almacenará el mensaje en claro

más de una clave privada, y alguna de dichas claves no tuviera un campo <info>
válido, a fin de poder identificar dicha clave el programa calculará su posición en el
fichero de claves y mostrará el texto Clave sin identificador #i, donde i tomará
como valor la posición de la clave. Por último, si el fichero contuviera solamente una
clave, y el elemento <info> no fuera válido, el programa utilizará como identificador
el nombre del fichero. La Figura 5.41 muestra las diversas variantes existentes en la
representación del identificador de la clave privada.
Figura 5.41: Modalidades de identificación de la clave privada
Durante el proceso de interpretación de los datos que contenga el fichero con

la clave privada, puesto que dicha clave se almacena cifrada, el programa reque-
rirá al usuario que introduzca el código de acceso o contraseña (Figura 5.42) que
permitirá utilizar la clave en el proceso de descifrado. Si el código es correcto, el
contenido de la clave privada se insertará en la caja de texto de la pestaña Pará-
metros correspondiente al elemento u, aunque dado su carácter crítico, en lugar de
mostrarse su contenido en claro, éste se mostrará enmascarado, tal como se observa
en la Figura 5.43.
La segunda sección de la pestaña Descifrado está compuesta por las siguientes
cajas de texto:
∙ Criptograma: contenido del mensaje cifrado empaquetado recibido por el des-

tinatario.
∙ Etiqueta: elemento de uso opcional a utilizar por la función MAC.
∙ Mensaje descifrado: mensaje en claro obtenido tras el proceso de descifrado
ECIES.
Figura 5.42: Ventana de solicitud del código de acceso
Figura 5.43: Enmascaramiento de la clave privada
∙ Resultado: campo con información acerca del resultado de la ejecución.
Las cajas de texto de la etiqueta y el mensaje descifrado permiten mostrar su

contenido interpretado como texto o en formato hexadecimal. En caso de que el
mensaje en claro no sea interpretable como texto ASCII, al seleccionar el forma-
to Texto aparecerá en una fuente de color rojo la cadena El contenido no es
interpretable como texto, tal como muestra la Figura 5.44.
Figura 5.44: Contenido del mensaje descifrado no interpretable como texto
Por otra parte, el programa permite introducir el contenido del criptograma en

formato hexadecimal y Base64.
La tercera sección de la pestaña Descifrado está formada por los siguientes ele-
mentos:
∙ Descifrar : botón que desencadena el proceso de descifrado ECIES a partir del

criptograma, la etiqueta y los parámetros asociados.
∙ Borrar : botón que permite borrar el contenido de las cajas de texto de esta
pantalla y devolver las opciones de configuración de la primera sección a su
estado inicial.
La Figura 5.45 muestra un ejemplo de proceso de descifrado, en el que se ha se-

leccionado la clave de un fichero que contiene un elemento <info> válido (y que por
tanto es el representado como identificador de la clave privada), el fichero Quijote
cifrado.out contiene el criptograma y el fichero Quijote descifrado.txt se uti-
lizará para almacenar el mensaje en claro resultante de la operación.
Figura 5.45: Ejemplo de descifrado ECIES
Si la operación efectuada es correcta, los posibles mensajes de éxito que puede

mostrar el elemento Resultado son:
Clave privada recuperada correctamente.

Por el contrario, algunos de los posibles mensajes de error que puede mostrar el
elemento Resultado son:
Problema con el fichero de log.

Problema con el formato del fichero con la clave privada.

Falta introducir el criptograma.
Error durante la creación del punto generador G=(Gx,Gy).
El texto en Base64 del criptograma es incorrecto.
Formato de criptograma incorrecto.
Longitud de la clave 3DES incorrecta.
Error durante el proceso de descifrado con el algoritmo AES.
5.4. Ejemplos de utilización

En los siguientes apartados se muestran dos ejemplos completos de los procesos
de cifrado y descifrado, incluyendo una descripción detallada de los pasos necesarios
para realizar las operaciones descritas.
5.4.1. Ejemplo de cifrado

El presente ejemplo constituye una muestra de las posibilidades de utilización
real del modo sencillo del programa de cifrado ECIES para PC, en el que todos los
datos de interés (clave pública del destinatario, mensaje en claro y criptograma)
se almacenan en fichero. Tras iniciar la aplicación, los pasos que debe completar el
usuario son los siguientes:
1. Seleccionar la pestaña Cifrado en la ventana inicial.
2. Seleccionar la opción Fichero correspondiente al elemento Clave pública recep-

tor.
3. Utilizando las capacidades de navegación de la ventana emergente aparecida,

seleccionar el fichero con la clave pública del usuario receptor del mensaje y
pulsar sobre el botón Abrir. En este ejemplo, el fichero seleccionado es Fp 521
SHA-256.pub (Figura 5.46).
Aparecerá a continuación de nuevo la ventana principal de ECIES con la in-
formación asociada al elemento <info> de la clave pública, que en este caso
particular es el texto Clave pública Bernardo (Figura 5.47).
4. Seleccionar la opción Fichero correspondiente al elemento Mensaje a cifrar.

seleccionar el fichero con el mensaje en claro a cifrar y pulsar sobre el botón
Abrir. En este ejemplo, el mensaje a cifrar será el contenido del fichero Quijote
- Capítulo I.txt (Figura 5.48).
5.4. Ejemplos de utilización 235
Figura 5.46: Selección del fichero con la clave pública del destinatario
Figura 5.47: Identificador de la clave pública del destinatario
Figura 5.48: Selección del fichero con el mensaje en claro

Aparecerá a continuación de nuevo la ventana principal de ECIES con los

primeros 1024 bytes del fichero interpretados como texto y en color azul, in-
dicando que el mensaje no se muestra completo en la caja de texto (Figura
5.49).
Figura 5.49: Identificador del fichero con el mensaje en claro
6. Seleccionar la opción Fichero correspondiente al elemento Criptograma.

seleccionar de entre los existentes el fichero donde se almacenará el criptograma
(o alternativamente introducir un nombre para la creación de un nuevo fichero
para tal fin) y pulsar sobre el botón Guardar. En este ejemplo, el fichero que
albergará el criptograma es Quijote cifrado.out (Figura 5.50).
Aparecerá a continuación de nuevo la ventana principal de ECIES con el nom-
bre del fichero (Figura 5.51).
8. Añadir (opcionalmente) una etiqueta, la cual será utilizada en el cálculo del

código MAC. En el ejemplo, el texto de la etiqueta es Prueba de cifrado
(Figura 5.52).
9. Pulsar el botón Cifrar. Si la operación de cifrado ha concluido satisfactoriamen-

te, aparecerá el texto Proceso finalizado correctamente junto al elemento
Resultado, y la caja de texto del elemento Criptograma mostrará los prime-
ro 1024 bytes del criptograma en formato Base64 y color azul (Figura 5.53),
indicando que el criptograma completo se encuentra almacenado en el fichero
Quijote cifrado.out.
Figura 5.50: Selección del fichero para el criptograma
Figura 5.51: Identificador del fichero para el criptograma
Figura 5.52: Contenido de la caja de texto de la etiqueta

Figura 5.53: Ventana con el resultado del proceso de cifrado
5.4.2. Ejemplo de descifrado

El siguiente ejemplo muestra los pasos necesarios para descifrar un criptograma,
donde todos los datos de interés (clave privada del destinatario, criptograma y men-
saje en claro resultante) se almacenan en forma de fichero. Tras iniciar la aplicación,
los pasos que debe completar el usuario son los siguientes:
1. Seleccionar la pestaña Descifrado en la ventana inicial.
2. Seleccionar la opción Fichero correspondiente al elemento Clave privada re-

ceptor.

seleccionar el fichero con la clave privada del usuario receptor del mensaje y
pulsar sobre el botón Abrir. En este ejemplo, el fichero seleccionado es Fp 521
SHA-256.pri (Figura 5.54).
Figura 5.54: Selección del fichero con la clave privada del destinatario
Aparecerá a continuación la ventana de introducción del código de acceso

(Figura 5.55), el cual permitirá la utilización de la clave privada por parte del
usuario.
Figura 5.55: Introducción de la contraseña para el acceso a la clave privada
Si el código introducido es el correcto, tras pulsar el botón Procesar aparecerá

de nuevo la ventana principal de ECIES con la información asociada al ele-
mento <info> de la clave pública, que en este caso particular es el texto Clave
privada Bernardo (Figura 5.56).
4. Seleccionar la opción Fichero correspondiente al elemento Criptograma.
seleccionar el fichero con el criptograma y pulsar sobre el botón Abrir. En este
ejemplo, el mensaje a cifrar será el contenido del fichero Quijote cifrado.out
(Figura 5.57).
Aparecerá a continuación de nuevo la ventana principal de ECIES con los
primeros 1024 bytes del fichero en formato Base64 y en color azul, indicando
Figura 5.56: Identificador de la clave privada del destinatario
Figura 5.57: Selección del fichero con el criptograma
que el mensaje no se muestra completo en la caja de texto (Figura 5.58).

6. Seleccionar la opción Fichero correspondiente al elemento Mensaje descifrado.
seleccionar de entre los existentes el fichero donde se almacenará el mensaje
descifrado (o alternativamente introducir un nombre para la creación de un
nuevo fichero para tal fin) y pulsar sobre el botón Guardar. En este ejemplo,
el fichero donde que albergará el criptograma es Quijote descifrado.txt
(Figura 5.59).
Aparecerá a continuación de nuevo la ventana principal de ECIES con el nom-
bre del fichero (Figura 5.60).
8. Añadir una etiqueta (en caso de que se utilizara durante el proceso de cifrado),
la cual será utilizada en el cálculo del código MAC. En el ejemplo, el texto de
la etiqueta es Prueba de cifrado (Figura 5.61).
9. Pulsar el botón Descifrar en la ventana principal. Si la operación de descifra-
do ha concluido satisfactoriamente, aparecerá el texto Proceso finalizado
Figura 5.58: Identificador del fichero con criptograma
Figura 5.59: Selección del fichero para el mensaje descifrado
Figura 5.60: Identificador del fichero para el mensaje descifrado

Figura 5.61: Contenido de la caja de texto de la etiqueta
correctamente junto al elemento Resultado, y la caja de texto del elemen-

to Mensaje descifrado mostrará los primero 1024 bytes del mensaje original
en color azul (Figura 5.62), indicando que el mensaje descifrado completo se
encuentra almacenado en el fichero Quijote descifrado.txt.
Figura 5.62: Ventana con el resultado del proceso de descifrado

Capítulo 6
Implementación de ECIES en Java

Card
En este capítulo se presenta una implementación del esquema de cifrado

ECIES para tarjetas Java Card, indicando las particularidades existen-
tes en función de la versión Java Card implementada por las tarjetas
inteligentes utilizadas en esta Tesis. De manera adicional, este capítu-
lo incluye la descripción funcional de la aplicación desarrollada para la
comunicación con las tarjetas inteligentes comerciales empleadas en la
Tesis.
6.1. Elementos criptográficos de ECIES disponibles

en Java Card
Tal como se indicó en el Capítulo 4, debido al carácter híbrido del esquema

de cifrado ECIES, su implementación requiere de elementos de diversa naturaleza
criptográfica. El grado de soporte de dichos elementos es muy variable dependiendo
de la versión Java Card que incluyan las tarjetas, por lo que a fin de identificar qué
funcionalidades y opciones es posible implementar, los siguientes apartados ofrecen
un resumen de los elementos relacionados con ECIES presentes en cada versión de
la plataforma Java Card.
243
244 6. Implementación de ECIES en Java Card
6.1.1. Java Card 2.1

La única característica criptográfica relacionada con ECIES incluida en la versión
Java Card 2.1 es la función resumen SHA-1.
6.1.2. Java Card 2.1.1

En la revisión Java Card 2.1.1 no se introdujo ninguna novedad respecto a las
funciones requeridas por ECIES, por lo que el único algoritmo disponible relacionado
con esquema de cifrado seguía siendo la función resumen SHA-1.

Java Card 2.2 fue la primera versión en incluir soporte para ECC, que junto con
el resto de las novedades conforman la siguiente lista de características criptográficas
relacionadas con ECIES:
∙ Función KA: DH y DHC, aunque con la particularidad de que el resultado

obtenido consiste en la salida de la primera coordenada del elemento secreto
compartido tras pasar por la función SHA-1.
∙ Función ENC : AES con bloques de 128 bits utilizando los modos CBC y ECB,
en ambos casos sin relleno, y longitudes de claves 128, 192 y 256 bits.
∙ Claves ECC: soporte para claves de 113, 131, 163 y 193 bits en cuerpos binarios
y claves de 112, 128, 160 y 192 bits en cuerpos primos.
6.1.4. Java Card 2.2.1

La revisión Java Card 2.2.1 no introdujo ninguna novedad en lo relativo a los
elementos necesarios para implementar ECIES, por lo que la lista de elementos es
idéntica a la mostrada en el apartado anterior.
6.1.5. Java Card 2.2.2

La principal novedad de Java Card 2.2.2 fue la introducción de los algoritmos
HMAC y de la familia de funciones resumen SHA-2. La lista detallada de capacida-
des criptográficas directamente relacionadas con la implementación de ECIES es la
siguiente:
6.1. Elementos criptográficos de ECIES disponibles en Java Card 245
∙ Función HASH : SHA-1, SHA-256, SHA-384, SHA-512.
∙ Función KA: DH y DHC en curvas elípticas, manteniendo la particularidad

reseñada en los apartados anteriores.
∙ Función ENC : AES con bloques de 128 bits utilizando los modos CBC y ECB,
en ambos casos sin relleno, y longitudes de claves 128, 192 y 256 bits.
∙ Función MAC : HMAC-SHA-1, HMAC-SHA-256, HMAC-SHA-384 y HMAC-

SHA-512.
y claves de 112, 128, 160 y 192 bits en cuerpos primos.
Por último, la versión Java Card 3.0.1 ha extendido el número de modos de

funcionamiento del algoritmo AES y de las longitudes de clave disponibles para los
cuerpos primos, añadiendo a la familia de funciones resumen el algoritmo SHA-
224. La lista completa de funcionalidades relacionadas con ECIES presente en esta
versión es la siguiente:
∙ Función HASH : disponibilidad de las funciones SHA-1, SHA-224, SHA-256,

SHA-384 y SHA-512.
∙ Función KA: DH y DHC en curvas elípticas, con la novedad de que a partir

de esta versión es posible decidir si el valor obtenido es la primera coordenada
del elemento secreto compartido o su salida al pasar por la función SHA-1.
∙ Función ENC : AES con bloques de 128, 192 y 256 bits utilizando los modos
CBC y ECB sin relleno. Además se ofrecen los modo CBC y ECB con relleno
compatible con el documento PKCS#5 [234] y el modo ECB compatible con
los métodos 1 y 2 de la norma ISO 9797 [128], en ambos casos con bloques de
128 bits. En todos los casos mencionados, las longitudes de clave admisibles
son 128, 192 y 256 bits.
∙ Función MAC : HMAC-SHA-1, HMAC-SHA-256, HMAC-SHA-384 y HMAC-

SHA-512. La función HMAC-SHA-224, aunque por coherencia debería haber
estado incluida, no forma parte de la especificación Java Card 3.0.
y claves de 112, 128, 160, 192, 224, 256 y 384 bits en cuerpos primos.
6.2. Resumen de funcionalidad ECC en Java Card

El Cuadro 6.1 recoge de forma resumida la información presentada en los anterio-
res apartados, donde DH y DHC son las funciones de acuerdo de clave Diffie-Hellman
con y sin cofactor, mientras que DH∗ y DHC∗ representan las mismas funciones con
la particularidad de que la salida de la función es el resumen de la primera coorde-
nada del elemento secreto compartido proporcionado por las funciones DH y DHC.
JC 2.2 JC 2.2.1 JC 2.2.2 JC 3.0

SHA-1 SHA-1 SHA-1 SHA-1
SHA-256 SHA-224
HASH SHA-384 SHA-256
SHA-512 SHA-384
SHA-512
DH∗ DH∗ DH∗ DH∗
DHC∗ DHC∗ DHC∗ DHC∗
KA
DH
DHC
DES DES DES DES
TDES TDES TDES TDES
ENC
AES-128 AES-128 AES-128 AES-128
AES-192
AES-256
HMAC-SHA-1 HMAC-SHA-1
MAC
112,128,160,192 112,128,160,192 112,128,160,192 112,128,160,192,
𝔽𝑝
224,256,384
𝔽2𝑚 113,131,163,193 113,131,163,193 113,131,163,193 113,131,163,193
Cuadro 6.1: Funcionalidades ECC en Java Card
6.3. Entorno de desarrollo
Durante las diferentes fases de investigación de la presente Tesis Doctoral se han

utilizado tres entornos de desarrollo para tarjetas Java Card, tal como se describe
en los siguientes apartados.
6.3. Entorno de desarrollo 247
6.3.1. NetBeans
Aunque en un primer momento se decidió utilizar la herramienta de desarrollo
NetBeans en su versión 6.7, por ser la primera con soporte de la tecnología Java Card,
esta opción fue descartada tras realizar las primeras pruebas y comprobar la correcta
estructura de la aplicación diseñada, ya que NetBeans sólo permite compilar applets
empleando las bibliotecas Java Card 3.0, lo que impide su descarga en tarjetas reales
por tratarse de una versión muy reciente para la que los fabricantes de tarjetas
inteligentes todavía no tienen productos comerciales.
6.3.2. Herramientas de línea de comandos de Sun

La segunda opción para el desarrollo de applets Java Card fue utilizar directa-
mente los ejecutables mediante línea de comandos proporcionados por Sun. Para
ello, fue necesario configurar el PC de trabajo de la siguiente manera:
1. Instalación de JDK 1.5 en la carpeta «C:\Java\jdk1.5.0_21».
2. Configuración de la variable del sistema JAVA_HOME con la localización del

directorio «C:\Java\jdk1.5.0_21».
3. Instalación del paquete Java Card 2.2.2 en «C:\java_card_kit-2_2_2».
4. Configuración de la variable del sistema JC_HOME con el valor de la carpeta

«C:\java_card_kit-2_2_2».
5. Instalación de la versión 1.6.2 del software Ant en «C:\apache-ant-1.6.2».
6. Configuración de la variable del sistema ANT_HOME con el valor del direc-

torio «C:\apache-ant-1.6.2».
7. Modificación de la variable PATH del sistema para que incluya la cadena

« %JAVA_HOME %\bin; %JC_HOME %\bin; %ANT_HOME %\bin».
La generación del applet se efectúa en dos pasos: en el primero, se realiza la

compilación del fichero con extensión .java, generando un fichero .class; en el segundo
paso, se obtiene el fichero con extensión .cap que será posteriormente descargado en
la tarjeta (para más información sobre el proceso de compilación de los applets en
Java Card, ver §3.5).
Para realizar la compilación del fichero JCECIES.java, es necesario seguir los
siguientes pasos:
1. Guardar el fichero JCECIES.java en «C:\JCECIES\src\victor\tesis\».

2. Acceder al directorio «C:\JCECIES\src\».
3. Ejecutar el comando javac .\victor\tesis\JCECIES.java.
Tras realizar el último paso, el resultado será la clase JCECIES.class, generada

en el directorio «C:\JCECIES\src\victor\tesis».
Con el fin de generar el fichero con extensión .cap asociado al applet, es necesario
seguir las siguientes indicaciones:
1. Acceder al directorio «C:\JCECIES\src».
2. Crear un fichero llamado JCECIES.opt con el siguiente contenido:

-out EXP JCA CAP
-exportpath C:\java_card_kit-2_2_2\api_export_files
-applet 0xa0:0x0:0x0:0x0:0x62:0x3:0x1:0xc:0x1:0x1 \\
victor.tesis.JCECIES
victor.tesis 0xa0:0x0:0x0:0x0:0x62:0x3:0x1:0xc:0x1 1.0
3. Ejecutar el comando converter -config JCECIES.opt.
Tras realizar el último paso, se generará el directorio «\javacard» en la carpe-

ta «C:\JCECIES\src\victor\tesis» junto con los ficheros tesis.cap, tesis.exp y
tesis.jca, que serán utilizados para descargar el applet en tarjetas reales o virtuales
(ver §6.5).
6.3.3. Eclipse
Tras recibir las tarjetas JCOP 41 y JCOP J3A utilizadas en la Tesis (ver §6.6 y
§7.1), el entorno de desarrollo seleccionado para completar el desarrollo de los applets
fue Eclipse 3.2, puesto que primero IBM y más tarde NXP han desarrollado sucesivas
versiones de los complementos (plug-ins) para Eclipse que permiten programar y
descargar applets de manera sencilla en tarjetas de prueba JCOP.
La Figura 6.1 muestra la ventana principal de la aplicación Eclipse 3.2 con los
complementos de NXP instalados.
6.4. Esquema de la aplicación

Antes de iniciar la fase de trabajo con tarjetas reales, en previsión de que no fuera
posible conseguir tarjetas que implementaran curvas definidas tanto sobre cuerpos
primos como binarios, se diseñaron dos versiones de la aplicación Java Card cuya
6.4. Esquema de la aplicación 249
Figura 6.1: Ventana principal del entorno de desarrollo Eclipse
única diferencia fuera precisamente el tipo de curvas empleadas. Estas dos versiones
fueron desarrolladas y depuradas utilizando las herramientas de consola descritas
en §6.3.2, de manera independiente respecto al modelo de tarjetas sobre el que se
descargaran los applets.
El Listado 6.1 muestra el esquema general de la aplicación Java Card diseñada
para curvas elípticas definidas sobre cuerpos binarios. En el caso de curvas elípticas
sobre cuerpos primos la aplicación es equivalente, representando los valores 01, 02,
03 y 04 del parámetro P1 en ese caso las curvas de 112, 128, 160 y 192 bits de
longitud.
1 package v i c t o r . t e s i s ;
2
3 import j a v a c a r d . framework . ∗ ;
4 import j a v a c a r d . s e c u r i t y . ∗ ;
5 import j a v a c a r d x . c r y p t o . ∗ ;
6
7 public c l a s s JCECIESF2m extends Applet
8 {
9 // D e c l a r a c i ó n de v a r i a b l e s
10
11 public s t a t i c void i n s t a l l ( byte [ ] bArray , short b O f f s e t , byte

bLength )
12 {
13 new JCECIESF2m ( ) ;
14 }
15 protected JCECIESF2m ( )
16 {
17 // I n i c i a l i z a c i ó n de v a r i a b l e s y o b j e t o s
18 }
19
20 public boolean s e l e c t ( )
21 {
22 return true ;
23 }
24
25 public void p r o c e s s (APDU apdu )
26 {
27 // Procesamiento de l a s APDU r e c i b i d a s para su g e s t i ó n
28
29 byte [ ] b u f f e r = apdu . g e t B u f f e r ( ) ;
30
31 if ( selectingApplet () )
32 {
33 return ;
34 }
35
36 switch ( b u f f e r [ ISO7816 . OFFSET_INS ] )
37 {
38 case 0 x61 :
39 p r o c e s s I N S 6 1 ( apdu ) ;
40 break ;
41 case 0 x62 :
42 p r o c e s s I N S 6 2 ( apdu ) ;
43 break ;
44 case 0 x63 :
45 p r o c e s s I N S 6 3 ( apdu ) ;
46 break ;
47 case 0 x64 :
48 p r o c e s s I N S 6 4 ( apdu ) ;
49 break ;
50 case 0 x65 :
51 p r o c e s s I N S 6 5 ( apdu ) ;
52 break ;
53 case 0 x66 :
54 p r o c e s s I N S 6 6 ( apdu ) ;
55 break ;
56 case 0 x67 :
57 p r o c e s s I N S 6 7 ( apdu ) ;
58 break ;
59 case 0 x68 :
60 p r o c e s s I N S 6 8 ( apdu ) ;
61 break ;
62 case 0 x69 :
63 p r o c e s s I N S 6 9 ( apdu ) ;
64 break ;
65 }
66 }
67 private void p r o c e s s I N S 6 1 (APDU apdu )
6.4. Esquema de la aplicación 251
68 {
69 // Crea nuevas c l a v e s de l o n g i t u d 113 , 131 , 163 y 193
70 // INS : 61
71 // P1 : t i p o de c l a v e (01=113 , 02=131 , 03=163 , 04=193)
72 // P2 : 00 ( s i n uso en e s t a i n s t r u c c i ó n )
73 // Lc : 00 ( s i n d a t o s de e n t r a d a )
74 // Ejemplo : 0061010000
75
76 }
77
79 {
80 // O b t i e n e l o s par ámetr os de l a s c l a v e s
81 // INS : 62
82 // P1 : t i p o de c l a v e (01=113 , 02=131 , 03=163 , 04=193)
83 // P2 : t i p o de d a t o ( 0 1 : a , 0 2 : b , 0 3 : f ( x ) , 0 4 : G, 0 5 : h , 0 6 :
n , 0 7 : tamaño d e l c u e r p o GF( q ) en b i t s , 0 8 : U, 0 9 : u )
85 // Ejemplo : 0062010900
86
87 }
88
90 {
91 // Almacena v a l o r e s en l o s o b j e t o s de l a s c l a v e s
92 // INS : 63
93 // P1 : t i p o de c l a v e (01=113 , 02=131 , 03=163 , 04=193)
94 // P2 : t i p o de d a t o ( 0 1 : a , 0 2 : b , 0 3 : f ( x ) , 0 4 : G, 0 5 : h , 0 6 :
n , 0 7 : tamaño d e l c u e r p o GF( q ) en b i t s , 0 8 : U, 0 9 : u )
95 // Lc : l o n g i t u d en b y t e s d e l d a t o i n c l u i d o a c o n t i n u a c i ó n
96 // Ejemplo : 006301081F0401A4CD29 . . .
97 }
98
100 {
101 // Almacena e l v a l o r de l a c l a v e p ú b l i c a d e l d e s t i n a t a r i o
102 // INS : 64
103 // P1 : t i p o de c l a v e (01=113 , 02=131 , 03=163 , 04=193)
104 // P2 : t i p o de d a t o ( 0 0 : c r e a c l a v e a l e a t o r i a , 0 1 : a , 0 2 : b ,
0 3 : f ( x ) , 0 4 : G, 0 5 : h , 0 6 : n , 0 7 : tamaño d e l c ue r p o GF( q )
en b i t s , 0 8 : U, 0 9 : u )
105 // Lc : l o n g i t u d en b y t e s d e l d a t o i n c l u i d o a c o n t i n u a c i ó n
106 // Ejemplo : 006401081F0401A4CD29 . . .
107 }
108
110 {
111 // Almacena e l mensaje a c i f r a r
112 // INS : 65
113 // P1 : t i p o de o p e r a c i ó n ( 0 1 : mensaje nuevo , 0 2 : anexar a
mensaje almacenado )
115 // Lc : l o n g i t u d en b y t e s de l a p o r c i ó n de mensaje i n c l u i d o a
continuación
116 // Ejemplo : 00650100080102030405060708
117 }
118
120 {
121 // Almacena l a e t i q u e t a
122 // INS : 66
123 // P1 : s i n uso en e s t a i n s t r u c c i ó n
125 // Lc : l o n g i t u d en b y t e s de l a e t i q u e t a i n c l u i d a a c o n t i n u a c i ó n
126 // Ejemplo : 006600000454657374
127 }
128
130 {
131 // S o l i c i t a l a g e n e r a c i ó n d e l c r i p t o g r a m a
132 // INS : 67
133 // P1 : t i p o de c l a v e (01=113 , 02=131 , 03=163 , 04=193)
136 // Ejemplo : 0067010000
137 }
138
140 {
141 // Almacena e l c r i p t o g r a m a a d e s c i f r a r
142 // INS : 68
143 // P1 : t i p o de o p e r a c i ó n ( 0 1 : c r i p t o g r a m a nuevo , 0 2 : anexar a
c r i p t o g r a m a almacenado )
145 // Lc : l o n g i t u d en b y t e s de l a p o r c i ó n de c r i p t o g r a m a i n c l u i d o
a continuación
146 // Ejemplo : 006801003 B040182D553 . . .
147
148 }
149
151 {
152 // Almacena e l d e s c i f r a d o d e l c r i p t o g r a m a
153 // INS : 69
154 // P1 : t i p o de c l a v e (01=113 , 02=131 , 03=163 , 04=193)
157 // Ejemplo : 0069010000
158 }
159
160 }
Listado 6.1: Esquema de la aplicación Java Card para curvas 𝔽2𝑚

6.5. Pruebas con tarjetas virtuales 253
6.5. Pruebas con tarjetas virtuales

Las herramientas de desarrollo para Java Card de Sun incluyen el fichero eje-
cutable cref.exe, que es una implementación en el lenguaje de programación C
del JCRE. Utilizando este programa junto con apdutool.exe, es posible simular el
comportamiento de una tarjeta Java Card, cargar aplicaciones y enviarles comandos
para realizar pruebas básicas mediante ficheros de instrucciones (scripts).
La implementación que hace el programa cref.exe de la plataforma Java Card
no es completa, y además varía en cada edición de Java Card. Mientras que el
soporte de las capacidades criptográficas en la versión de cref.exe que se incluye
con el paquete de desarrollo para Java Card 2.2.2 es bastante completo, la versión
para Java Card 3.0 proporcionada por Sun hasta el momento no implementa ninguna
funcionalidad criptográfica.
A título informativo, a continuación se detallan las características criptográficas
implementadas en la versión de cref.exe para Java Card 2.2.2:
∙ Función HASH : ejecuta correctamente las funciones ALG_SHA y ALG_SHA_256.

Las otras dos variantes, ALG_SHA_384 y ALG_SHA_512, producen una excepción
de tipo CardRuntime.
∙ Función ENC : el modo ALG_AES_BLOCK_128_CBC_NOPAD se ejecuta correc-

tamente, pero el modo ALG_AES_BLOCK_128_ECB_NOPAD, aunque no produce
errores en la compilación, genera una excepción CardRuntime.
∙ Función MAC : no soporta ninguno de los métodos HMAC definidos en las

API de Java Card (ALG_HMAC_SHA1, ALG_HMAC_SHA_256, ALG_HMAC_SHA_384
y ALG_HMAC_SHA_512).
A continuación se muestran los pasos necesarios para generar un fichero de ins-

trucciones con los datos necesarios para cargar e instalar la aplicación en una tarjeta
virtual, donde como se puede observar es necesario añadir el elemento 0x7F al final
de cada comando.
1. Acceder al directorio «C:\JCECIES\src».
2. Ejecutar el comando
scriptgen -o JCECIES.scr .\victor\tesis\javacard\tesis.cap.
Tras realizar este paso, se generará el el fichero JCECIES.scr en el directorio
«C:\JCECIES\src».
3. Editar el fichero JCECIES.scr, añadiéndole las siguientes líneas al principio

del fichero:
powerup;
// Selección del applet instalador con AID A00000006203010801

// CLA: 0x00, INS: 0xA4, P1: 0x04, P2: 0x00, Lc: 0x09
// Datos: 0xA0 0x00 0x00 0x00 0x62 0x03 0x01 0x08 0x01
0x00 0xA4 0x04 0x00 0x09 0xA0 0x00 0x00 0x00 0x62 0x03 0x01 \\
0x08 0x01 0x7F;
4. Continuar la edición del fichero, añadiéndole las siguientes líneas al final:

// Creación del applet JCECIES con AID A00000006203010C0101
// CLA: 0x80, INS: 0xB8, P1: 0x00, P2: 0x00, Lc: 0x0B
// Datos: 0x0A 0xA0 0x00 0x00 0x00 0x62 0x03 0x01 0x0C 0x01 0x01
0x80 0xB8 0x00 0x00 0x0B 0x0A 0xA0 0x00 0x00 0x00 0x62 0x03 \\
0x01 0x0C 0x01 0x01 0x7F;
powerdown;
Si en el mismo fichero de instrucciones se desean incluir los comandos APDU

necesarios para probar la aplicación, éstos deberán ser incluidos inmediatamente
antes de la orden powerdown. Las siguientes líneas muestran un ejemplo de APDU
de prueba:
// Selección del applet JCECIES con AID A00000006203010C0101

// CLA: 0x00, INS: 0xA4, P1: 0x04, P2: 0x00, Lc: 0x0A
// Datos: 0xA0 0x00 0x00 0x62 0x03 0x01 0x0C 0x01 0x01
0x00 0xA4 0x04 0x00 0x0A 0xA0 0x00 0x00 0x00 0x62 0x03 0x01 \\
0x0C 0x01 0x01 0x7F;
// Comando INS 10
// CLA: 0x80, INS: 0x10, P1: 0x00, P2: 0x00, Lc: 0x01
// Datos: 0x11
0x80 0x10 0x00 0x00 0x01 0x11 0x7F;
// Comando INS 20
// Datos: 0x22
0x80 0x20 0x00 0x00 0x01 0x22 0x7F;

6.6. Pruebas con tarjetas reales 255
// Comando INS 30
// Datos: 0x33
0x80 0x30 0x00 0x00 0x01 0x33 0x7F;
Por último, para ejecutar un fichero de instrucciones es necesario realizar las

siguientes acciones:
1. Abrir una consola de MS-DOS y ejecutar el comando cref.exe.
2. Abrir en paralelo otra consola de MS-DOS, acceder al directorio donde se

encuentre el fichero de instrucciones JCECIES.scr y ejecutar el comando
apdutool.exe -o APDU.txt JCECIES.scr
Mediante el último comando, el resultado de la ejecución de las instrucciones se

almacenará en el fichero APDU.txt.
6.6. Pruebas con tarjetas reales

En el momento de iniciar la elaboración de esta Tesis, los fabricantes Gemalto,
Oberthur y G&D no disponían de productos comerciales con soporte para cripto-
grafía de curva elíptica. Afortunadamente, sí estaban disponibles para su compra en
internet [262] tarjetas JCOP (Java Card Open Platform), fabricadas inicialmente
por IBM y posteriormente por NXP [268].
Existe en el mercado una amplia gama de tarjetas JCOP (JCOP 20, 30, 40, 31,
41, etc.) con diferentes características. De entre todas ellas, el modelo seleccionado
finalmente fue JCOP 41, ya que estaban disponibles para su compra en diversas
tiendas online y además implementaban funciones de ECC.
Tras la recepción de las tarjetas JCOP 41, y la confirmación de que estas tarjetas
únicamente implementaban curvas sobre cuerpos binarios, el autor de esta Tesis
se puso en contacto con la empresa NXP a fin de solicitar el último modelo de
tarjetas JCOP disponibles. Gracias a las gestiones realizadas por Juan Moreno y la
generosidad de NXP, fue posible hacer pruebas con tarjetas del modelo JCOP J3A,
que además de implementar curvas elípticas sobre cuerpos primos incluyen algunas
de las funciones criptográficas añadidas recientemente al estándar Java Card (AES,
SHA-256, etc.).
Debido a las peculiaridades de las tarjetas JCOP, con el objetivo de realizar un
mayor número de pruebas y comparaciones se decidió desarrollar tres versiones del
applet en lugar de las dos previstas inicialmente. Dichas versiones son las corres-
pondientes a las configuraciones de prueba M2, P2 y P3 descritas en §7.2, y para
diferenciar en lo sucesivo los tres applets Java Card, las tres versiones del applet se
han denominado JCOP-M2, JCOP-P2 y JCOP-P3.
La instalación de los applets en las tarjetas JCOP se realizó mediante el entorno
de desarrollo Eclipse 3.2 junto con los complementos JCOP Tools 3.2.8 y SmartMX
Target-Pack for JCOP Tools 1.2.9 proporcionados por NXP, que permiten realizar
la descarga de la aplicación desde el entorno Eclipse utilizando las claves que por
defecto incluyen todas las tarjetas JCOP de desarrollo.
En cuanto al tamaño de los applets, tal como puede apreciarse en la Figura 6.2
(compuesta por imágenes obtenidas del entorno de desarrollo Eclipse), la versión
JCOP-M2 (AID A00000000501) ocupa 5031 bytes, el tamaño de la versión JCOP-
P2 (AID A00000000601) es 4328 bytes, y por último la versión JCOP-P3 (AID
A00000000701) ocupa 4404 bytes. Dichas cantidades no incluyen ni las variables
que se alojarán en RAM (de tipo transient en Java Card) ni las que residirán en
memoria EEPROM (de tipo persistent), aunque sí incluye las matrices formadas
por elementos constantes (es decir, las matrices de tipo final static).
La versión JCOP-M2 tiene un tamaño superior a las otras dos puesto que las
tarjetas JCOP 41 implementan 4 tipos de curvas, mientras que las tarjetas JCOP
J3A permiten utilizar únicamente 3 curvas, por lo que la gestión de las curvas es
más compleja en la versión JCOP-M2.
Por otra parte, el tamaño de la versión JCOP-P3 es ligeramente superior al de
la versión JCOP-P2 debido a que las funciones MAC y HMAC (SHA-256 y HMAC-
SHA-256) utilizadas en dicha versión generan unos datos de salida de mayor longitud
que las funciones correspondientes de la versión JCOP-P2 (SHA-1 y HMAC-SHA-1),
siendo necesario aumentar el tamaño de los arrays con los que se trabaja de forma
interna.
Una vez realizada la descarga de la aplicación en las tarjetas JCOP mediante
el entorno Eclipse y los complementos de NXP, las pruebas de comunicación con el
applet Java se han realizado utilizando dos aplicaciones diferentes: el propio entorno
Eclipse, utilizado principalmente para depurar los diferentes applets mediante la
realización de pruebas individuales, y una aplicación Java SE con interfaz gráfica,
desarrollada por el autor de esta Tesis y presentada en detalle en §6.7.
6.7. Aplicación JCOPECIES

Tras comprobar la correcta implementación y depuración de los applets Java
Card en las tarjetas JCOP 41 y J3A efectuada mediante el entorno Eclipse, con el
objetivo de realizar las pruebas descritas en el Capítulo 7 y facilitar a los posibles
6.7. Aplicación JCOPECIES 257
Figura 6.2: Tamaño de los aplets JCOP-M2, JCOP-P2 y JCOP-P3
usuarios la utilización del esquema de cifrado en tarjetas inteligentes, se decidió

desarrollar una aplicación Java SE para PC que realizase las operaciones de cifrado
y descifrado.
Esta aplicación, denominada de forma abreviada JCOPECIES, presenta cuatro
pantallas a las que se puede acceder mediante la pestaña apropiada, tal y como se
describe a continuación:
∙ Pestaña Configuración (Figura 6.3): incluye los elementos que permiten selec-
cionar el lector (Figura 6.4), el tipo de tarjeta (JCOP 41 o J3A) y la curva
(que depende de la tarjeta elegida, ver Figura 6.5). De forma adicional, esta
pestaña permite generar nuevos pares de claves para una tarjeta y curva da-
da, así como recuperar el valor de la clave pública seleccionada, mostrando la
Figura 6.6 el resultado final de ambos procesos. Por último, esta pantalla in-
cluye una caja de texto donde se pueden visualizar las APDU intercambiadas
con la tarjeta inteligente en cualquiera de las operativas implementadas por
la aplicación (cifrado, descifrado, generación de pares de claves y recuperación
de la clave pública).
Figura 6.3: Pestaña Configuración
∙ Pestaña Cifrado (Figura 6.7): permite añadir la curva pública del destinatario
del criptograma, el mensaje en claro a cifrar y la etiqueta a utilizar de manera
opcional por la función MAC. El resultado del proceso de cifrado se muestra
en la caja de texto asociada al criptograma.
∙ Pestaña Descifrado (Figura 6.8): permite incluir el criptograma a descifrar y

la etiqueta opcional para la función MAC, mostrando el mensaje original en
su caja de texto.
6.7. Aplicación JCOPECIES 259
Figura 6.4: Lectores de tarjetas disponibles
Figura 6.5: Curvas implementadas en JCOP 41 y JCOP J3A
∙ Pestaña Acerca (Figura 6.9): muestra información sobre la versión del progra-
ma JCOPECIES y sus autores.
Como parte de las distintas funciones implementadas, la aplicación muestra de

forma gráfica los errores debidos a las siguientes causas (Figura 6.10):
∙ Falta de selección de un lector de tarjetas.

∙ Selección de un lector donde no se ha introducido ninguna tarjeta.
∙ Falta de selección de la curva de trabajo.
∙ Utilización de una tarjeta que no tiene instalado el applet adecuado para los
modelos JCOP 41 y JCOP J3A.
Respecto a la longitud del mensaje a cifrar, se ha implementado una variante del

esquema de padding o relleno PKCS#5 [234] que tiene las siguientes características:
Figura 6.6: Generación y recuperación de una clave pública de 192 bits

Figura 6.7: Pestaña Cifrado
∙ Al mensaje original se le añaden tantos bytes como sea necesario hasta que la
longitud en bytes del mensaje así modificado sea múltiplo de 8 (en las tarjetas
JCOP 41, ya que implementa el algoritmo TDES) o múltiplo de 16 (en las
tarjetas JCOP J3A, puesto que el applet para esas tarjetas utiliza AES).
∙ El contenido de cada uno de los bytes adicionales es la codificación en formato

hexadecimal del número de bytes que es necesario añadir.
∙ A diferencia del esquema de relleno PKCS#5 habitual, si la longitud en bytes

del mensaje original en bytes ya es múltiplo de 8 (JCOP 41) o de 16 (JCOP
J3A), no se añade ningún byte adicional.
El motivo de incluir esa modificación al esquema PKCS#5 se debe a las limi-

taciones en la longitud del mensaje original que impone la implementación en Java
Card, y que por diseño del applet utiliza una única APDU tanto para transmitir
el mensaje original a la tarjeta como para recuperar el criptograma. Proporcional-
mente, en el ámbito de la centena de bytes, la pérdida de 8 ó 16 bytes (según la
tarjeta) para relleno es elevada, por lo que en esta implementación se ha suprimido
la necesidad de añadir un nuevo bloque en tales casos.
Figura 6.8: Pestaña Descifrado
Debido a ello, existiría un caso en el que podría producirse pérdida de informa-

ción al descifrar un mensaje, en concreto cuando la longitud del mensaje original
es múltiplo de 8 (JCOP 41) o 16 (JCOP J3A), y el valor de los últimos 𝑛 bytes
es precisamente la codificación hexadecimal del número 𝑛 (es decir, los últimos by-
tes del mensaje se ajustan a los esquemas . . . 01, . . . 0202, . . . 030303, etc.). Para
evitar este problema, el propio programa comprueba que el mensaje a cifrar no
da lugar a esta situación, y en caso de que sea así muestra por pantalla el men-
saje Proceso cancelado: el contenido del mensaje provocaría pérdida de
información.
6.8. Ejemplos de utilización
En los siguientes apartados se muestran dos ejemplos completos de los procesos

de cifrado y descifrado, incluyendo una descripción detallada de los pasos necesarios
para realizar las operaciones descritas. Las imágenes que componen las figuras están
tomadas de los complementos para tarjetas JCOP proporcionado por NXP para el
entorno de desarrollo Eclipse y de la aplicación JCOPECIES.
Figura 6.9: Pestaña Acerca
Figura 6.10: Errores asociados al lector, la curva o la tarjeta

Tal como se puede apreciar en todas las figuras incluidas en el resto del presente
capítulo, el primer comando en todos los casos es el de selección del applet. Esta
selección no es necesaria para el correcto funcionamiento de la aplicación, pero se
ha incluido a fin de demostrar que no es necesario completar la secuencia de todos
los comandos en una única sesión.
6.8.1. Cifrado y descifrado en tarjetas JCOP 41 y el comple-

mento de NXP para Eclipse
El ejemplo incluido en este apartado muestra el proceso cifrado de un men-
saje realizado por el usuario U y el posterior descifrado por parte del usuario V
empleando tarjetas JCOP 41 y los complementos de NXP para Eclipse.
Antes de realizar las operaciones del cifrado y descifrado, es necesario que los
usuarios U y V obtengan un par de tarjetas que contengan la aplicación Java Card
de cifrado y descifrado. Aunque en la instalación del applet se genera un par de
claves para cada longitud permitida por el fabricante, como medida de precaución
los usuarios pueden solicitar a la tarjeta la generación de nuevos pares de claves en
cualquier momento, por ejemplo cuando reciban sus tarjetas. En el caso del producto
JCOP 41, las longitudes disponibles para curvas definidas sobre cuerpos 𝔽2𝑚 son 113,
131, 163 y 193 bits.
La Figura 6.11 muestra los comandos que tanto el usuario U como V necesitarían
enviar para la generación de dichas claves, y que son:
∙ Selección del applet: A00000000501.
∙ Generación de un par de claves de 113 bits: 0061010000.
La Figura 6.12 muestra todos los parámetros asociados a las claves del usuario U.
El último comando enviado permite obtener la clave privada de U, por lo que dicho
comando sólo está disponible en la versión de pruebas del applet, siendo eliminada
de la versión definitiva de la aplicación que sería utilizada por usuarios reales. Por
su parte, la Figura 6.13 muestra de manera equivalente los parámetros asociados a
las claves del usuario V.
Tal y como se puede apreciar en las Figuras 6.12 y 6.13, todos los parámetros
coinciden a excepción de las claves privadas y públicas, ya que las tarjetas JCOP
Figura 6.11: Generación de nuevas claves en JCOP 41
41 utilizan una única curva para cada una de las longitudes posibles, cambiando en
cada generación aleatoria de claves únicamente los valores 𝑢 y 𝑈 para un usuario U.
Dada la curva 𝑦 2 + 𝑥𝑦 = 𝑥3 + 𝑎𝑥2 + 𝑏 caracterizada por el conjunto de pará-
metros 𝒫=(𝑚, 𝑓 (𝑥), 𝑎, 𝑏, 𝐺, 𝑛, ℎ), los comandos empleados en la Figura 6.12 para la
obtención de los parámetros de las claves asociadas al usuario U son los presentados
a continuación:
∙ Parámetro 𝑎: 0062040100.
∙ Parámetro 𝑏: 0062040200.
∙ Polinomio reductor 𝑓 (𝑥): 0062040300.
∙ Punto de la curva que actúa como el generador 𝐺: 0062040400.
∙ Cofactor ℎ: 0062040500.
∙ Orden del punto 𝐺: 0062040600.

Figura 6.12: Parámetros de las claves de 193 bits de U en JCOP 41

Figura 6.13: Parámetros de las claves de 193 bits de V en JCOP 41

∙ Tamaño de la clave (longitud en bits del cuerpo binario): 0062040700.

∙ Clave pública 𝑈 : 0062040800.
∙ Clave privada 𝑢: 0062040900.
Tal como puede apreciarse en las Figuras 6.12 y 6.13, la respuesta de la tarjeta
al comando 0062040500 consiste en un código de error definido por el propio applet
(FF62), lo que indica que, a pesar de estar especificado el método para obtener
el cofactor en Java Card, esta funcionalidad no está implementada en las tarjetas
JCOP 41.
Una vez obtenidos los parámetros de las propias claves por parte de los usuarios
U y V (con el objetivo, por ejemplo, de distribuir su clave pública junto con los
parámetros de la curva a otros usuarios), para poder generar un criptograma es
necesario enviar a la tarjeta el mensaje a cifrar, la etiqueta a utilizar como parámetro
de entrada opcional en el cálculo del código MAC, y la clave pública del receptor
del mensaje cifrado. Una vez estos elementos estén almacenados en la memoria de
la tarjeta, el usuario U podrá solicitar al applet la generación del criptograma que
posteriormente deberá enviar al usuario V. La Figura 6.14 muestra los comandos
necesarios, y que se detallan a continuación:

∙ Envío de la clave pública 𝑉 del usuario V:
0064040833040147EF73CAC299773F20AF95E64B01B8EFED22A0AD8
DC53DD300AE2A3607E5D51CF66A82F623A69FD6D876C265128FFF
D9FD.
∙ Envío del mensaje en claro a cifrar:
00650100201112131415161718212223242526272831323334353637384142
434445464748.
∙ Envío de la etiqueta para el cálculo del código MAC : 006600000454657374.

∙ Solicitud de generación del criptograma: 0067040000.
El resultado de la operación de cifrado es el criptograma
0401BC9A5BE00DB6F5FDDEA249434FED1665A0749236160C622301736
8B704A497646EBD7D87249647B4F6C900E3978BB887887A40F0FFE036B
8E9364F525E107ED6B3BD6E00D651E689F3F70F813B30AC66FD7BECC
931E850D19FE644F1886656C43E91FAE913,
Figura 6.14: Comandos para cifrar un mensaje ejecutados por U en JCOP 41
que U deberá enviar a V. Una vez recibido este criptograma, la secuencia de co-
mandos que V necesita enviar a la tarjeta a fin de obtener el mensaje descifrado
están incluidos en la Figura 6.15 y listados a continuación:

∙ Envío de la etiqueta para el cálculo del código MAC : 006600000454657374.
∙ Envío del criptograma:
00680100670401BC9A5BE00DB6F5FDDEA249434FED1665A07492361
60C6223017368B704A497646EBD7D87249647B4F6C900E3978BB88788
7A40F0FFE036B8E9364F525E107ED6B3BD6E00D651E689F3F70F813
B30AC66FD7BECC931E850D19FE644F1886656C43E91FAE913.
∙ Solicitud de descifrado del criptograma: 0069040000.
A la solicitud de descifrado, la tarjeta responde con la cadena hexadecimal
1112131415161718212223242526272831323334353637384142434445464748,
la cual coincide con el contenido del mensaje original que U deseaba enviar a V.
Figura 6.15: Comandos de descifrado ejecutados por V en JCOP 41
6.8.2. Cifrado y descifrado en tarjetas JCOP J3A y la apli-

cación JCOPECIES
A continuación se muestra un ejemplo de cifrado y descifrado empleando la
aplicación JCOPECIES y una tarjeta JCOP J3A con la configuración P3 y la curva
sect193r1. La Figura 6.7 recoge los datos utilizados en el proceso de cifrado, y que
son los siguientes:
∙ Clave pública del destinatario:
042A38ACD50BDBBE2FE80DB46492E10CE988310A9E7679FAAE739
5DCEAC208B64D0AFE521A0B61DF4C2A2700D48E164D05.
∙ Mensaje a cifrar: Texto Prueba cifrado 1, cuyo valor hexadecimal está re-
presentado por la cadena
507275656261206369667261646F2031.
∙ Etiqueta: Cadena Test, cuyo valor hexadecimal es 54657374.
El resultado de este proceso de cifrado es el criptograma

04F465E627E750EDC11C0EF383AE077F964A9D12755CA94439A92A6C
DC89E259E41FCFBB3C1EADDDB4831EBBCA1D03F0BF89AD884D829
E76A98E100172F64E1054FDD117E97B04C9CFDBBE610BF3AACC75B4
10448EA679FC44C3C427C3466D275D
cuya codificación Base64 es
BPRl5ifnUO3BHA7zg64Hf5ZKnRJ1XKlEOakqbNyJ4lnkH8+7PB6t3bSD
HrvKHQPwv4mtiE2CnnapjhABcvZOEFT90RfpewTJz9u+YQvzqsx1tBB
EjqZ5/ETDxCfDRm0nXQ==.
A continuación es necesario utilizar la tarjeta JCOP J3A que incluye el par de

claves cuya clave pública fue empleada en el cifrado del mensaje. En este caso, los
datos a incluir en la pestaña Descifrado son únicamente el criptograma y la etiqueta,
mientras que en la pestaña Configuración es necesario especificar el lector, el tipo de
tarjeta y la curva elíptica. La Figura 6.8 muestra el resultado del proceso de cifrado
tal como aparece en la pestaña Descifrado.
De manera complementaria, si el usuario desea comprobar qué APDU han sido
transmitidas durante el proceso de descifrado, puede acceder a estos datos mediante
la pestaña Configuración, tal como puede apreciarse en la Figura 6.16.
Figura 6.16: Ventana APDU con datos de descifrado

Capítulo 7
Resultados empíricos

Este capítulo recoge las pruebas realizadas con las implementaciones de
ECIES para PC y Java Card, utilizando diferentes combinaciones de pa-
rámetros y algoritmos en función de las posibilidades criptográficas de
cada una de las plataformas seleccionadas. A fin de analizar los resulta-
dos de las pruebas, el capítulo incluye una descripción detallada de las
características de las tarjetas inteligentes empleadas en dichas pruebas.
7.1. Material utilizado

Las pruebas ejecutadas con las distintas configuraciones detalladas en §7.2 se
han realizado sobre tres plataformas hardware diferentes: un PC y dos modelos de
tarjetas inteligentes de la empresa NXP. A continuación se detallan las principales
características de cada una de las plataformas mencionadas:
∙ Plataforma PC:
Procesador: Intel Pentium D a 3 GHz.

Memoria RAM: 2 Gbytes.
Sistema operativo: Windows XP con Service Pack 3.
Versiones Java: Java SE 5.0 y Java SE 6.
∙ Tarjetas JCOP 41 [200, 202]:
271
272 7. Resultados empíricos
Módulo hardware: P5CT072.

CPU: Secure_MX51 (Memory eXtended/enhanced 80C51) de 8 bits.
Sistema operativo: JCOP 2.2.1.
Versión Java Card: 2.2.1 (implementación parcial).
Versión GlobalPlatform: 2.1.1.
Tecnología CMOS: 0,18 𝜇m con 5 capas de metal.
Frecuencia externa de reloj: hasta 10 MHz.
Máxima frecuencia interna de reloj: 30 MHz.
Memoria ROM: 160 Kbytes.
Memoria EEPROM: 72 Kbytes.
Memoria RAM: 4608 bytes.
Protocolos de comunicación: ISO/IEC 7816 (con contactos) e ISO/IEC
14443 Tipo A (sin contactos).
Coprocesadores criptográficos: TDES, AES y PKI (RSA, ECC, etc).
Cuerpo finito: 𝔽2𝑚 .
Longitudes de curvas: 113, 131, 163 y 193 bits.
Función HASH : SHA-1.
Función KA: DH, donde la salida de la función es el resumen SHA-1 de
la primera coordenada del dato secreto compartido.
Función ENC : DES y TDES en modo CBC sin relleno.
∙ Tarjetas JCOP J3A [201, 202]:
Módulo hardware: P5CD080.

CPU: Secure_MX51 (Memory eXtended/enhanced 80C51) de 8 bits.
Sistema operativo: JCOP 2.4.1.
Versión Java Card: 2.2.2 (implementación parcial).
Versión GlobalPlatform: 2.1.1.
Tecnología CMOS: 0,14 𝜇m.
Frecuencia externa de reloj: hasta 10 MHz.
Máxima frecuencia interna de reloj: 30 MHz.
Memoria ROM: 200 Kbytes.
Memoria EEPROM: 80 Kbytes.
Memoria RAM: 6144 bytes.
Protocolos de comunicación: ISO/IEC 14443 Tipo A (sin contactos).
7.1. Material utilizado 273
Coprocesadores criptográficos: TDES, AES y PKI (RSA, ECC, etc).

Cuerpo finito: 𝔽𝑝 .
Longitudes de curvas: 128, 160 y 192 bits.
Función HASH : SHA-1 y SHA-256.
Función KA: DH con dos variantes, una en la que la salida de la función
es el resumen SHA-1 de la primera coordenada del secreto compartido, y
otra en la que la salida es directamente el valor de la primera coordenada.
Función ENC : DES, TDES y AES en modo CBC sin relleno.
La Figura 7.1 presenta el diagrama de los componentes comunes de los módulos

P5CT072 y P5CD080, donde se pueden apreciar claramente los tres coprocesadores
criptográficos que incorporan los productos JCOP 41 y J3A. Para evitar confusiones
es necesario comentar que, aunque las tarjetas JCOP 41 incluyen el coprocesador
para AES, no permiten utilizar este algoritmo debido a que se encuentra inhabilitado
en esas tarjetas por un error de configuración durante el proceso de fabricación.
Figura 7.1: Diagrama de los módulos P5CT072 y P5CD080
Otro dato interesante es el hecho de que el chip tiene más entradas (nueve en
el caso de la Figura 7.1) que el número de contactos de las tarjetas (típicamente
ocho, ver §1.3.2.1). Ello se debe a que los chips se diseñan de manera genérica para
poder adaptarse a diferentes configuraciones según las necesidades de los clientes:

en las tarjetas JCOP utilizadas, por ejemplo, únicamente se utiliza uno de los tres
contactos de entrada/salida para la comunicación serie entre el lector y el chip.
Por otra parte, la Figura 7.2 muestra una imagen real de las tarjetas JCOP 41
y JCOP J3A utilizadas, así como del lector PC/SC Omnikey 5321 [105] empleado
en las pruebas.
Figura 7.2: Tarjetas JCOP y lector PC/SC empleados en las pruebas
Puesto que las tarjetas JCOP 41 permiten utilizar tanto la interfaz con contactos
como la interfaz sin contactos, las pruebas de cifrado y descifrado realizadas con las
tarjeas JCOP 41 han sido duplicadas a fin de obtener resultados mediante ambas
interfaces. Tal como se puede apreciar en la Figura 7.3, que muestra la informa-
ción proporcionada por una herramienta de Omnikey relativa a la tarjeta JCOP 41
utilizando el protocolo T=0 (con contactos) y T=CL (sin contactos), la frecuencia
utilizada en la interfaz con contactos es de 4.80 MHz, mientras si se utiliza la interfaz
sin contactos la frecuencia es 13.56 MHz.
Es importante señalar que, a pesar de conocer la frecuencia de la señal externa
de reloj proporcionada a la tarjeta, no es posible sin embargo conocer la frecuencia
interna a la que las tarjetas realmente están trabajando. La única información que
ha sido posible obtener es la asociada a las características técnicas de los dos modelos
de tarjetas, la cual indica que la frecuencia interna de trabajo tiene un valor máximo
de 30 MHz para ambos modelos.
7.2. Configuraciones de prueba 275
Figura 7.3: Frecuencias de trabajo en la interfaz con contactos y sin contactos
Independientemente de lo anterior, es necesario aclarar que los tiempos de cifrado

y descifrado calculados en las pruebas descritas en este capítulo incluyen el tiempo
de transmisión de las APDU apropiadas (de petición de una operación y de envío del
resultado desde la tarjeta al lector) junto con el tiempo de procesamiento efectivo
(es decir, el tiempo que tarda la tarjeta en realizar la operación pertinente desde
que dispone de todos los datos y ha recibido la orden de ejecución hasta los datos
producidos están listos para ser transmitidos). El tiempo de transmisión, por su
naturaleza, depende de dos parámetros: la longitud de los datos a transmitir, y la
velocidad a la que los datos son transmitidos por el canal de comunicación.
7.2. Configuraciones de prueba

Con el objetivo de intentar comparar de forma homogénea las implementaciones
del esquema de cifrado ECIES en PC y Java Card, y debido a las limitaciones en
las funcionalidades criptográficas disponible en las tarjetas JCOP 41 y JCOP J3A,
se han realizado pruebas con las configuraciones detalladas a continuación.
∙ Configuración M1:
Cuerpo sobre el que se define la curva elíptica: 𝔽2𝑚 .

Función KA: DH.
Función KDF : KDF2.
Función ENC : AES en modo CBC con relleno PKCS#5.
Función MAC : HMAC-SHA-256-256.
Longitud de la clave de cifrado simétrico: 32 bytes.
Longitud de la clave MAC : 32 bytes.

Utilización como parámetro de entrada en la función KDF de la primera
coordenada del punto de la curva que representa el secreto compartido.
Utilización de la clave pública temporal del emisor como entrada para la
función KDF.
Interpretación de la salida de la función KDF como 𝑘𝐸𝑁 𝐶 ∣∣𝑘𝑀 𝐴𝐶 .
Utilización del formato comprimido en la representación de los puntos de
la curva elíptica.
∙ Configuración M2:
Cuerpo sobre el que se define la curva elíptica: 𝔽2𝑚 .
Función KA: DH.
Función ENC : TDES en modo CBC sin relleno.
Utilización como parámetro de entrada en la función KDF del resumen
SHA-1 de la primera coordenada del punto de la curva que representa el
secreto compartido.
Utilización del formato sin comprimir en la representación de los puntos
∙ Configuración P1:
Cuerpo sobre el que se define la curva elíptica: 𝔽𝑝 .
Función KA: DH.
Función ENC : AES en modo CBC con relleno PKCS#5.
7.2. Configuraciones de prueba 277
Utilización de la clave pública temporal del emisor como entrada para la

función KDF.
Utilización del formato comprimido en la representación de los puntos de
la curva elíptica.
Función KA: DH.
Función ENC : TDES en modo CBC sin relleno.
Utilización como parámetro de entrada en la función KDF del resumen
SHA-1 de la primera coordenada del punto de la curva que representa el
secreto compartido.
Función KA: DH.
Función ENC : AES en modo CBC sin relleno.
Las configuraciones cuyo nombre comienza por la letra P indican la utilización

de curvas sobre cuerpos primos, mientras que las configuraciones cuyo identifica-
dor empieza con la letra M implican el uso de curvas sobre cuerpos binarios. Las
versiones P1 y M1 representan la implementación de ECIES para PC que incorpo-
ra las recomendaciones de seguridad reseñadas en el Capítulo 4. Aunque estas dos
configuraciones no se pueden implementar en las tarjetas Java Card, se han inclui-
do para poder realizar comparaciones con las otras configuraciones. Por su parte,
la configuración M2 es la versión implementada en las tarjetas JCOP 41, siendo
la configuración P2 equivalente a la versión M2 con la única diferencia del cuerpo
finito empleado. Por último, la configuración P3 es la versión para tarjetas JCOP
J3A que emplea las características avanzadas de estas tarjetas (funciones SHA-256,
AES, etc.).
Respecto a las curvas elípticas utilizadas en las pruebas, el Cuadro 7.1 presenta
las curvas empleadas en cada una de las configuraciones.
M1 M2 P1 P2 P3
sect113r1 sect113r1 secp112r1 secp128r1 secp128r1
sect131r1 sect131r1 secp128r1 secp160r1 secp160r1
sect163r1 c2pnb163v1 secp160r1 P-192 P-192
sect193r1 sect193r1 secp192k1
sect233r1 secp224r1
sect239k1 secp256k1
sect283r1 secp384r1
sect409r1 secp521r1
sect571r1
Cuadro 7.1: Curvas elípticas empleadas en las configuraciones
En las configuraciones M1 y P1 se han utilizado curvas elípticas publicadas por

SECG, puesto que este consorcio proporciona curvas con un amplio rango respecto
a su longitud. En concreto, se ha tomado una curva de cada una de las longitudes
disponibles en [255], eligiendo como primera opción las curvas cuyos coeficientes han
sido seleccionados aleatoriamente de forma reproducible siguiendo las indicaciones
de [255] (curvas con sufijo r1), y como segunda opción las curvas Koblitz (curvas
con sufijo k1). Por su parte, las curvas de las configuraciones P2, P3 y M2 son las
implementadas en las tarjetas JCOP 41 y JCOP J3A, donde todas las curvas están
definidas en [255], con la excepción de las curvas P-192 [15] y c2pnb163v1 [272].
7.3. Factor de expansión 279
7.3. Factor de expansión

Este apartado presenta las pruebas en las que se ha calculado el factor de expan-
sión, interpretado en esta Tesis como la relación entre la longitud del criptograma
𝒞 (tripleta formado por la clave pública temporal, el mensaje cifrado y el código
MAC ) y la longitud del mensaje original, obteniendo de esta manera una medida
de la eficiencia en cuanto a ancho de banda de ECIES.
Debido a la naturaleza de ECIES, existen diversos elementos que contribuyen al
tamaño final de los criptogramas. La siguiente lista describe dichos elementos:
1. El cuerpo finito 𝔽𝑞 , que determina la longitud en bytes de la representación

binaria asociada a los elementos del cuerpo (y que conforman las coordenadas
de los puntos de la curva elíptica).
2. La representación binaria de la clave pública temporal del emisor (ya sea com-
primida o sin comprimir).
3. La función de cifrado simétrico (TDES, AES, etc.), su modo de utilización

(ECB, CBC, etc.) y el método de relleno (PKCS#5, sin relleno, etc.).
4. La longitud del código MAC generado.
En el caso particular de las implementaciones Java Card, puesto que la longi-

tud máxima de un comando APDU es 255 bytes, el conjunto de longitudes de los
mensajes a cifrar utilizados en estas pruebas se ha seleccionado de manera que la res-
puesta a una petición de cifrado o descifrado esté contenida en una única APDU de
respuesta. La utilización de peticiones con mensajes y criptogramas cuya respuesta
excediera 255 bytes tendría las siguientes consecuencias:
1. El tiempo de la operación aumentaría al ser necesaria la transmisión de APDU

adicionales por el canal de transmisión.
2. Dado que tanto los mensajes a cifrar como los criptogramas a descifrar deben
ser almacenados temporalmente en la memoria de las tarjetas inteligentes para
su procesado, y puesto que la cantidad de RAM en las tarjetas es muy limitada,
la utilización de mensajes de excesivo tamaño provocaría que los elementos
de tipo array que albergan los datos a cifrar o descifrar tuvieran que ser
almacenados en memoria EEPROM en lugar de en memoria RAM, con el
consiguiente deterioro del rendimiento general.
En todas las pruebas referidas a continuación, el factor de expansión puede ser

calculado como
∣𝒞∣ ∣𝔪∣ + 𝛿
(7.1) FE = = ,
∣𝔪∣ ∣𝔪∣
donde ∣𝒞∣ es la longitud en bytes del criptograma, ∣𝔪∣ es la longitud en bytes del
mensaje en claro y 𝛿 representa la diferencia entre las longitudes del criptograma y
del mensaje en claro (ambas medidas en bytes). Mientras que los cuadros y figuras
de los siguientes apartados recogen el factor de expansión calculado para distintas
combinaciones de claves y mensajes en claro, por sencillez en la exposición se incluirá
únicamente la fórmula del valor 𝛿 en cada caso.
7.3.1. Factor de expansión con la configuración M1
Las pruebas llevadas a cabo con la configuración M1 tienen las siguientes pro-
piedades:
∙ La longitud de los mensajes en claro es en todos los casos múltiplo de 16 (lo

que genera un bloque de 16 bytes adicional al utilizar el algoritmo AES en
modo CBC con relleno PKCS#5).
∙ Los puntos de la curva elíptica se representan de forma comprimida.
∙ El código MAC tiene una longitud de 32 bytes.
Con ello, la diferencia 𝛿𝑀 1 entre la longitud del criptograma y la longitud del

mensaje original cuando se utilizan curvas definidas sobre 𝔽2𝑚 viene dada por la
fórmula
⌈𝑚⌉ ⌈𝑚⌉
𝛿𝑀 1 = 1 + + 16 + 32 = + 49,
8 8
donde el byte inicial es el prefijo que indica la compresión del punto que representa
la clave pública temporal 𝑈 , ⌈𝑚/8⌉ representa el número de bytes necesarios para
representar un elemento del cuerpo 𝔽2𝑚 , el relleno PKCS#5 añade 16 bytes durante
el proceso de cifrado simétrico y, por último, el código MAC ocupa 32 bytes.
El Cuadro 7.2 y la Figura 7.4 muestran el factor de expansión calculado a partir
de la ecuación (7.1) al cifrar mensajes de distinta longitud (16, 32, 64, 128, 256,
512 y 1024 bytes) utilizando las diferentes longitudes de clave consideradas en la
configuración M1.
Longitud del mensaje (bytes)

16 32 64 128 256 512 1024
sect113r1 5 3 2 1.5 1.25 1.13 1.06
sect131r1 5.13 3.06 2.03 1.52 1.26 1.13 1.06
Curva elíptica
sect163r1 5.38 3.19 2.09 1.55 1.27 1.14 1.07

sect193r1 5.63 3.31 2.16 1.58 1.29 1.14 1.07
sect233r1 5.94 3.47 2.23 1.62 1.31 1.15 1.08
sect239k1 5.94 3.47 2.23 1.62 1.31 1.15 1.08
sect283r1 6.31 3.66 2.33 1.66 1.33 1.17 1.08
sect409r1 7.31 4.16 2.58 1.79 1.39 1.2 1.1
sect571r1 8.56 4.78 2.89 1.95 1.47 1.24 1.12
Cuadro 7.2: Factor de expansión en curvas sobre 𝔽2𝑚 con la configuración M1
Figura 7.4: Factor de expansión en curvas sobre 𝔽2𝑚 con la configuración M1

7.3.2. Factor de expansión con la configuración M2

Las características específicas de las pruebas realizadas con la configuración M2
son:
∙ La longitud de los mensajes en claro es en todos los casos múltiplo de 16

(siendo la longitud del mensaje cifrado igual a la longitud del mensaje original
al utilizar el algoritmo TDES en modo CBC sin relleno).
∙ Los puntos de la curva elíptica se representan sin comprimir.
Con estos elementos, la diferencia 𝛿𝑀 2 entre la longitud del criptograma y la

longitud del mensaje original cuando se utilizan curvas definidas sobre 𝔽2𝑚 viene
dada por la fórmula
⌈𝑚⌉ ⌈𝑚⌉
𝛿𝑀 2 = 1 + 2 ⋅ + 20 = 2 ⋅
+ 21,
8 8
donde el byte inicial es el prefijo añadido para indicar que el punto de la curva que
representa la clave pública temporal no está comprimido, el valor ⌈𝑚/8⌉ aparece
duplicado puesto que al no utilizarse compresión de puntos es necesario incluir las
dos coordenadas del punto, y finalmente el código MAC ocupa 20 bytes.
El Cuadro 7.3 y la Figura 7.5 muestran el factor de expansión calculado mediante
la ecuación (7.1) al cifrar mensajes de distinta longitud (16, 32, 48, 64, 80, 96, 112,
128, 144 y 160 bytes) utilizando la configuración M2 con diferentes longitudes de
claves.

16 32 48 64 80 96 112 128 144 160
sect113r1 4.19 2.59 2.06 1.8 1.64 1.53 1.46 1.4 1.35 1.32
Curva
sect131r1 4.44 2.72 2.15 1.86 1.69 1.57 1.49 1.43 1.38 1.34
c2pnb163v1 4.94 2.97 2.31 1.98 1.79 1.66 1.56 1.49 1.44 1.39
sect193r1 5.44 3.22 2.48 2.11 1.89 1.74 1.63 1.55 1.49 1.44
Cuadro 7.3: Factor de expansión en curvas sobre 𝔽2𝑚 con la configuración M2
7.3.3. Factor de expansión con la configuración P1

Las pruebas realizadas en este apartado tienen las siguientes características es-
pecíficas:
Figura 7.5: Factor de expansión en curvas sobre 𝔽2𝑚 con la configuración M2
∙ La longitud de los mensajes en claro es, en todos los casos, múltiplo de 16 (lo
que genera un bloque de 16 bytes adicional al utilizar el algoritmo AES en
modo CBC con relleno PKCS#5).
∙ Los puntos de la curva elíptica se representan de forma comprimida.
Con ello, la diferencia 𝛿𝑃 1 entre la longitud del criptograma y la longitud del

mensaje original cuando se utilizan curvas definidas sobre 𝔽𝑝 para cifrar mensajes
cuya longitud en bytes es múltiplo de 16 viene dada por la fórmula
⌈ log 𝑝 ⌉ ⌈ log 𝑝 ⌉
2 2
𝛿𝑃 1 = 1 + + 16 + 32 = + 49,
8 8
donde el byte inicial es el prefijo añadido por el algoritmo de compresión de puntos
(y cuyos posibles valores son 0x02 ó 0x03), ⌈(log2 𝑝)/8⌉ representa el número de
bytes necesarios para representar un elemento del cuerpo 𝔽𝑝 , el relleno PKCS#5
añade 16 bytes durante el proceso de cifrado simétrico y, por último, el código MAC
ocupa 32 bytes.
la ecuación (7.1) al cifrar mensajes de distinta longitud (16, 32, 64, 128, 256, 512 y
1024 bytes) utilizando la configuración P1 y haciendo uso de curvas con diferentes

longitudes de clave.
16 32 64 128 256 512 1024
secp112r1 4.94 2.97 1.98 1.49 1.25 1.12 1.06
secp128r1 5.06 3.03 2.02 1.51 1.25 1.13 1.06
Curva elíptica
secp160r1 5.31 3.16 2.08 1.54 1.27 1.13 1.07

secp192k1 5.56 3.28 2.14 1.57 1.29 1.14 1.07
secp224r1 5.81 3.41 2.2 1.6 1.3 1.15 1.08
secp256k1 6.06 3.53 2.27 1.63 1.32 1.16 1.08
secp384r1 7.06 4.03 2.52 1.76 1.38 1.19 1.09
secp521r1 8.19 4.59 2.8 1.9 1.45 1.22 1.11
Cuadro 7.4: Factor de expansión en curvas sobre 𝔽𝑝 con la configuración P1
Figura 7.6: Factor de expansión en curvas sobre 𝔽𝑝 con la configuración P1

Las pruebas realizadas en este apartado tienen las siguientes características es-
pecíficas:

al utilizar el algoritmo TDES en modo CBC sin relleno).
Con estos elementos, la diferencia 𝛿𝑃 2 entre la longitud del criptograma y la

longitud del mensaje original cuando se utilizan curvas definidas sobre 𝔽𝑝 viene
2 2
𝛿𝑃 2 = 1 + 2 ⋅ + 20 = 2 ⋅ + 21,
8 8
donde el byte inicial es el prefijo añadido para indicar que el punto de la curva que
representa la clave pública temporal 𝑈 no está comprimido (y que por lo tanto toma
valor 0x04), el valor ⌈(log2 𝑝)/8⌉ aparece duplicado ya que al no utilizarse compresión
de puntos es necesario incluir las dos coordenadas del punto, y finalmente el código
MAC ocupa 32 bytes.
El Cuadro 7.5 y la Figura 7.7 muestran el factor de expansión calculado a partir
de la ecuación (7.1) al cifrar mensajes de distinta longitud (16, 32, 48, 64, 80, 96,
112, 128, 144 y 160 bytes) utilizando la configuración P2 con diferentes longitudes
de claves, según las curvas consideradas.

16 32 48 64 80 96 112 128 144 160
secp128r1 4.31 2.66 2.1 1.83 1.66 1.55 1.47 1.41 1.37 1.33
Curva
secp160r1 4.81 2.91 2.27 1.95 1.76 1.64 1.54 1.48 1.42 1.38
P-192 5.31 3.16 2.44 2.08 1.86 1.72 1.62 1.54 1.48 1.43

Las características específicas de las pruebas realizadas en este apartado son:

al utilizar el algoritmo AES en modo CBC sin relleno).

Debido a estas características, la diferencia 𝛿𝑃 3 entre la longitud del criptograma

y la longitud del mensaje original cuando se utilizan curvas definidas sobre 𝔽𝑝 viene
2 2
𝛿𝑃 3 =1+2⋅ + 32 = 2 ⋅ + 33,
8 8
donde el byte inicial es el prefijo añadido para indicar que el punto de la curva
que representa la clave pública temporal no está comprimido, el valor ⌈(log2 𝑝)/8⌉
aparece duplicado puesto que representa la longitud en bytes de dos elementos del
cuerpo finito 𝔽𝑝 , y por último el código MAC ocupa 32 bytes.
la ecuación (7.1) al cifrar mensajes de distinta longitud (16, 32, 48, 64, 80, 96, 112,
128, 144 y 160 bytes) utilizando la configuración P3 con diferentes claves.

16 32 48 64 80 96 112 128 144 160
secp128r1 5.06 3.03 2.35 2.02 1.81 1.68 1.58 1.51 1.45 1.41
Curva
secp160r1 5.56 3.28 2.52 2.14 1.91 1.76 1.65 1.57 1.51 1.46
P-192 6.06 3.53 2.69 2.27 2.01 1.84 1.72 1.63 1.56 1.51

7.4. Tiempo de cifrado

El procedimiento seguido para obtener las mediciones del tiempo de cifrado en
todas las implementaciones tiene las siguientes características:
1. Para cada longitud de curva disponible se han utilizado mensajes de longitud

16, 32, 48, 64, 80, 96, 112, 128, 144 y 160 bytes de forma común a todas
las pruebas, y mensajes de 176 bytes de longitud en los casos en los que la
respuesta se podía incluir en una única APDU. Todos los bytes del mensaje
han sido inicializados con el valor 0xFF.
2. El tiempo de cifrado referido a cada curva representa la media de 20 procesos

de cifrado consecutivos.
3. La función de la API de Java SE utilizada para obtener la medición de tiempos

es System.nanoTime(), que proporciona el valor actual en nanosegundos del
reloj del sistema.
En el caso particular de las mediciones utilizando la implementación de ECIES

para PC, el tiempo de inicio de la medición es exactamente antes del cálculo del
producto 𝑢 𝑉 , después de que todos los parámetros y variables estén cargados en
la memoria RAM del PC. Por su parte, el tiempo final de cada medición ha sido
obtenido justo después de que el criptograma esté construido en la memoria RAM
como una cadena hexadecimal, antes de que se muestren los datos por pantalla para
evitar la influencia de los retrasos asociados a dicha presentación.
En cuanto a las implementaciones Java Card, tal como se comentó en §6.6,
se ha diseñado una aplicación Java SE de línea de comandos que se encarga del
envío y recepción de los comandos APDU, así como de la medición de tiempos. La
comunicación con la tarjeta inteligente se ha realizado mediante el API Smart Card
I/O de Java y el lector PC/SC Omnikey 5321. El tiempo de inicio de la medición en
estas pruebas constituye el instante anterior al envío de la APDU con la petición de
cifrado (estando en ese momento todos los datos necesarios cargados en la memoria
RAM de la tarjeta inteligente), mientras que el tiempo final ha sido obtenido en el
instante posterior a la recepción de la APDU de respuesta, por lo que los tiempos
así medidos incluyen tanto el tiempo de transmisión de los datos como el tiempo de
procesamiento en la tarjeta inteligente.
Para mayor claridad en la lectura, el tiempo de cifrado se encuentra expresado
en todas las figuras y cuadros incluidos en los siguientes apartados en milisegundos,
aunque no se indique expresamente.
7.4. Tiempo de cifrado 289
7.4.1. Tiempo de cifrado en PC con la configuración M1
Al igual que con la configuración P1, únicamente la versión de Java para PC

dispone de las funcionalidades criptográficas requeridas por la configuración M1. El
Cuadro 7.7 y la Figura 7.9 muestran el tiempo de cifrado de la versión para PC de
ECIES.
Longitud del cuerpo finito 𝔽2𝑚 (bits)

113 131 163 193 233 239 283 409 571
16 28.82 35.61 54.94 76.57 102.84 106.52 131.56 220.78 370.40
32 27.91 36.02 54.4 80.26 103.81 106.24 133.21 220.52 370.97

48 27.52 36.34 55.01 81.45 103.43 106.12 132.31 219.85 369.78
64 27.80 36.71 54.35 81.92 102.33 105.46 132.04 220.66 368.64
80 27.64 36.62 57.60 82.05 102.93 105.44 132.62 221.53 368.81
96 27.71 36.50 57.23 82.57 103.72 105.32 131.77 220.30 370.62
112 27.62 36.42 58.03 81.53 102.92 105.52 132.34 220.43 370.36
128 27.53 36.40 59.61 82.46 103.24 105.42 131.73 222.71 368.68
144 27.55 36.63 58.61 81.34 103.21 105.30 130.62 225.65 369.73
160 28.14 36.21 58.00 81.51 102.51 105.33 129.72 224.45 368.42
176 28.34 36.26 59.67 82.53 102.31 105.54 129.96 225.53 368.50
Cuadro 7.7: Tiempo de cifrado con curvas sobre 𝔽2𝑚 en PC (configuración M1)
7.4.2. Tiempo de cifrado en PC y Java Card con la configu-

ración M2
La configuración M2 ha sido probada tanto en la versión PC de ECIES como en la

implementación Java Card desarrollada para la tarjeta JCOP 41. El Cuadro 7.8 y la
Figura 7.10 muestran los resultados de la versión PC, el Cuadro 7.9 y la Figura 7.11
presentan el tiempo de cifrado utilizando tarjetas JCOP 41 y la interfaz sin contactos,
y finalmente el Cuadro 7.10 y la Figura 7.12 muestran el tiempo de cifrado utilizando
el mismo modelo de tarjetas y la interfaz con contactos.
7.4.3. Tiempo de cifrado en PC con la configuración P1
Puesto que la configuración P1 utiliza unas funciones criptográficas que no están

disponibles en la tarjeta Java Card, esta configuración ha sido utilizada únicamente
en la implementación PC de ECIES. El Cuadro 7.11 y la Figura 7.13 muestran los
resultados de la versión PC.
Figura 7.9: Tiempo de cifrado con curvas sobre 𝔽2𝑚 en PC (configuración M1)

113 131 163 193
16 25.91 34.9 53.56 77.99
32 26.04 35.15 55.49 78.13

48 25.68 35.24 55.49 78.28
64 25.99 35.13 54.27 78.17
80 25.61 35.04 54.31 77.97
96 25.92 35.02 53.94 77.66
112 26.01 34.82 53.36 77.12
128 26.22 34.79 53.18 77.93
144 26.51 34.67 53.59 79.32
160 26.55 35.14 53.69 79.24
176 26.78 35.07 53.71 79.50
Cuadro 7.8: Tiempo de cifrado con curvas sobre 𝔽2𝑚 en PC (configuración M2)
Figura 7.10: Tiempo de cifrado con curvas sobre 𝔽2𝑚 en PC (configuración M2)

113 131 163 193
16 296.74 314.65 332.71 367.64
32 297.35 314.76 333.82 368.88

48 306.58 324.33 342.34 384.44
64 307.49 331.62 349.65 384.58
80 314.23 332.18 349.94 384.98
96 314.59 332.55 351.54 386.45
112 323.76 341.66 360.50 401.76
128 331.39 348.78 367.11 401.81
144 331.53 349.39 367.57 403.46
160 331.82 350.70 368.74 403.70
176 341.52 358.64 384.40 418.98
Cuadro 7.9: Tiempo de cifrado con curvas sobre 𝔽2𝑚 en JCOP 41 e interfaz sin con-
tactos (configuración M2)
Figura 7.11: Tiempo de cifrado con curvas sobre 𝔽2𝑚 en JCOP 41 e interfaz sin con-

113 131 163 193
16 363.51 384.52 407.35 446.56
32 379.26 399.71 423.00 461.89

48 398.18 418.68 441.77 481.21
64 413.51 433.60 457.30 496.31
80 428.94 448.95 472.47 511.39
96 444.44 464.41 487.81 526.91
112 463.38 483.65 506.62 545.77
128 478.95 498.73 522.03 561.14
144 494.01 514.38 537.20 576.33
160 509.34 529.41 552.31 591.55
176 528.36 548.35 571.23 610.54
Cuadro 7.10: Tiempo de cifrado con curvas sobre 𝔽2𝑚 en JCOP 41 e interfaz con
contactos (configuración M2)
Figura 7.12: Tiempo de cifrado con curvas sobre 𝔽2𝑚 en JCOP 41 e interfaz con con-
Longitud del cuerpo finito 𝔽𝑝 (bits)

112 128 160 192 224 256 384 521
16 23.53 23.94 39.01 54.47 68.61 79.06 142.33 226.02
32 23.48 23.94 39.28 54.89 68.95 79.63 141.05 225.91

48 23.72 23.88 40.03 54.82 69 78.89 141.12 225.44
64 24.43 24.64 40.12 54.63 68.91 79.31 141.02 226.55
80 23.31 24.51 40.05 54.27 69.03 78.61 141.28 226.63
96 23.28 24.39 39.99 54.91 69.71 80.92 141.39 225.67
112 24.08 24.57 40.20 54.49 69.15 81.33 142.29 226.64
128 23.86 24.51 41.49 54.78 68.81 82.56 141.84 227.53
144 23.9 24.65 40.64 54.25 69.09 80.18 142.10 228.13
160 24.33 24.83 40.45 54.23 69.3 79.81 142.22 229.36
176 23.55 24.12 39.77 53.96 69.88 79.33 143.07 228.08
Cuadro 7.11: Tiempo de cifrado con curvas sobre 𝔽𝑝 en PC (configuración P1)
Figura 7.13: Tiempo de cifrado con curvas sobre 𝔽𝑝 en PC (configuración P1)

ración P2
La configuración P2 ha sido probada tanto en la versión PC de ECIES como en

la implementación Java Card desarrollada para las tarjetas JCOP J3A de NXP. El
Cuadro 7.12 y la Figura 7.14 muestran los resultados de la versión PC, mientras que
el Cuadro 7.13 y la Figura 7.15 presentan el tiempo de cifrado utilizando tarjetas
JCOP J3A.

ración P3
La configuración P3 ha sido igualmente probada en las versiones para PC y

tarjetas JCOP J3A. El Cuadro 7.14 y la Figura 7.16 muestran los resultados de la
versión PC, mientras que el Cuadro 7.15 y la Figura 7.17 presentan el tiempo de
cifrado de mensajes de distinta longitud utilizando tarjetas JCOP J3A.

128 160 192
16 25.87 40.95 57.59
Longitud mensaje (bytes) 32 25.79 41.45 57.37
48 25.84 41.02 57.29
64 25.98 40.57 57.23
80 26.21 40.58 56.77
96 25.78 40.04 56.70
112 25.75 40.67 56.61
128 26.15 41.73 56.67
144 26.34 40.94 56.99
160 26.98 41.63 57.04


128 160 192
16 481.55 518.24 587.76
32 482.26 520.29 589.71
48 489.63 526.76 597.61
64 491.59 534.67 603.90
80 499.66 535.46 605.29
96 501.82 536.85 606.50
112 512.23 544.14 620.53
128 519.80 551.29 621.59
144 521.07 552.35 623.32
160 522.50 554.08 623.73
176 529.22 561.74 636.95
Cuadro 7.13: Tiempo de cifrado con curvas sobre 𝔽𝑝 en JCOP J3A e interfaz sin
contactos (configuración P2)
Figura 7.15: Tiempo de cifrado con curvas sobre 𝔽𝑝 en JCOP J3A e interfaz sin con-
tactos (configuración P2)

128 160 192
16 23.37 40.49 57.96
48 24.97 40.50 58.12
64 25.39 39.54 58.21
80 25.53 39.45 57.91
96 25.45 39.55 58.13
112 24.57 39.23 58.06
128 24.62 39.44 58.03
144 24.67 39.37 58.11
160 24.73 39.44 58.31


128 160 192
16 512.54 543.31 613.50
48 527.88 564.82 634.21
64 535.06 565.95 635.42
80 536.18 567.78 637.21
96 537.58 568.58 639.29
112 551.27 588.09 657.83
128 558.10 588.98 658.56
144 558.89 590.59 660.66
160 560.78 591.69 668.73
Cuadro 7.15: Tiempo de cifrado con curvas sobre 𝔽𝑝 en JCOP J3A e interfaz sin
Figura 7.17: Tiempo de cifrado con curvas sobre 𝔽𝑝 en JCOP J3A e interfaz sin con-
tactos (configuración P3)
7.5. Tiempo de descifrado 299
7.5. Tiempo de descifrado

El procedimiento seguido para obtener las mediciones del tiempo de descifrado
tiene las mismas características generales que el empleado para el proceso de cifrado.
El punto de medición de los tiempos inicial y final en la versión PC son equivalentes a
los del proceso de cifrado, y de forma análoga, la medición en la implementación Java
Card se ha realizado mediante la misma aplicación Java SE de línea de comandos,
la cual se encarga de enviar y recibir las APDU apropiadas.
Continuando con el objetivo de facilitar la lectura, el tiempo de cifrado se en-
cuentra expresado en todas las figuras y cuadros incluidos en los siguientes apartados
en milisegundos, aunque no se indique expresamente.
7.5.1. Tiempo de descifrado en PC con la configuración M1

Al igual que con la configuración P1, únicamente la versión de Java para PC
dispone de las funcionalidades criptográficas requeridas por la configuración M1. El
Cuadro 7.16 y la Figura 7.18 muestran el tiempo de descifrado de esta versión.

113 131 163 193 233 239 283 409 571
16 28.9 38.5 62.6 91.8 103.4 112.1 132.8 226.1 356.7
32 29.0 38.3 61.9 90.8 103.6 111.7 132.9 226.4 361.2

48 28.7 38.1 66.4 90.2 103.7 112.1 132.9 228.9 361.5
64 28.9 38.1 66.3 90.0 103.2 113.4 132.8 227.9 359.5
80 29.3 37.9 66.3 89.0 103.8 110.8 132.8 227.2 358.0
96 29.3 38.5 66.1 87.9 103.0 110.7 132.7 228.2 358.7
112 29.4 37.9 65.6 87.7 103.7 110.5 132.6 228.7 358.7
128 29.3 38.3 65.8 88.0 103.8 110.3 132.6 227.8 366.4
144 29.5 38.3 66.2 88.9 104.4 111.0 132.6 227.7 363.8
160 29.4 38.4 66.4 89.4 104.1 111.8 132.7 228.2 364.5
176 29.7 38.9 66.5 89.8 104.5 111.6 132.8 228.2 364.6
Cuadro 7.16: Tiempo de descifrado con curvas sobre 𝔽2𝑚 en PC (configuración M1)
7.5.2. Tiempo de descifrado en PC y Java Card con la confi-

guración M2
La configuración M2 ha sido probada tanto en la versión PC de ECIES como en la
implementación Java Card desarrollada para la tarjeta JCOP 41. El Cuadro 7.17 y la
Figura 7.19 muestran los resultados de la versión PC, el Cuadro 7.18 y la Figura 7.20
Figura 7.18: Tiempo de descifrado con curvas sobre 𝔽2𝑚 en PC (configuración M1)
presentan el tiempo de descifrado utilizando tarjetas JCOP 41 y la interfaz sin

contactos, y finalmente el Cuadro 7.19 y la Figura 7.21 muestran el tiempo de
descifrado utilizando el mismo modelo de tarjetas y la interfaz con contactos.
7.5.3. Tiempo de descifrado en PC con la configuración P1
Puesto que la configuración P1 utiliza unas funciones criptográficas que no están

disponibles en la tarjeta Java Card, esta configuración ha sido utilizada únicamente
en la implementación PC de ECIES. El Cuadro 7.20 y la Figura 7.22 muestran los
resultados de la medición del proceso de descifrado en la versión de ECIES para PC.

guración P2
La configuración P2 ha sido probada tanto en la versión PC de ECIES como en la

implementación Java Card desarrollada para la tarjeta JCOP J3A. El Cuadro 7.21 y
la Figura 7.23 muestran los resultados de la versión PC, mientras que el Cuadro 7.22
y la Figura 7.24 presentan el tiempo de descifrado utilizando tarjetas JCOP J3A.

113 131 163 193
16 25.68 34.18 52.64 76.79
32 25.19 33.91 52.85 76.98

48 25.14 34.25 52.95 77.74
64 25.16 33.98 52.71 77.65
80 25.47 35.01 52.97 77.56
96 25.22 34.80 52.81 77.82
112 25.84 34.92 53.04 77.36
128 25.68 35.25 52.97 77.16
144 25.75 35.35 53.03 76.71
160 25.38 35.36 53.35 76.84
176 25.45 35.99 53.93 76.76
Cuadro 7.17: Tiempo de descifrado con curvas sobre 𝔽2𝑚 en PC (configuración M2)
Figura 7.19: Tiempo de descifrado con curvas sobre 𝔽2𝑚 en PC (configuración M2)

113 131 163 193
16 197.74 203.12 212.04 222.08
32 198.83 204.34 213.33 223.20

48 208.54 213.66 222.49 232.61
64 215.00 220.45 229.37 239.37
80 215.61 220.65 229.50 239.59
96 216.64 221.94 230.89 241.15
112 225.60 230.63 239.70 249.49
128 232.63 237.81 246.80 256.74
144 233.31 238.58 247.46 257.38
160 234.46 239.58 248.60 258.62
176 244.41 249.53 258.53 268.34
Cuadro 7.18: Tiempo de descifrado con curvas sobre 𝔽2𝑚 en JCOP 41 e interfaz sin
Figura 7.20: Tiempo de descifrado con curvas sobre 𝔽2𝑚 en JCOP 41 e interfaz sin

113 131 163 193
16 223.78 228.21 236.18 245.19
32 239.00 243.50 251.47 260.57
48 257.95 262.37 270.15 279.39
64 273.21 277.62 285.54 294.63
80 288.56 292.12 300.84 310.06
96 304.13 308.53 316.22 325.14
112 323.23 327.38 335.59 344.07
128 338.22 342.64 350.69 359.56
144 353.64 358.06 366.12 374.88
160 368.92 373.29 381.45 390.04
176 387.98 392.21 400.50 408.76
Cuadro 7.19: Tiempo de descifrado con curvas sobre 𝔽2𝑚 en JCOP 41 e interfaz con
Figura 7.21: Tiempo de descifrado con curvas sobre 𝔽2𝑚 en JCOP 41 e interfaz con

112 128 160 192 224 256 384 521
16 24.99 25.57 42.37 56.10 76.80 82.63 144.21 230.38
32 25.79 25.93 41.95 57.06 76.97 82.83 144.59 231.94

48 25.73 26.14 41.37 56.43 76.84 82.67 144.26 229.00
64 25.80 26.08 40.97 55.51 76.67 82.60 144.10 228.36
80 25.82 26.28 40.67 55.49 74.30 82.90 145.54 227.93
96 25.66 26.26 38.96 55.36 74.54 82.99 148.35 228.80
112 25.69 26.26 69.43 55.34 74.72 82.31 148.89 227.63
128 25.97 26.12 39.59 56.15 74.13 84.72 148.56 227.62
144 25.66 26.21 39.83 56.05 74.19 84.95 148.72 228.39
160 25.95 26.40 40.34 55.96 74.34 84.25 148.32 230.85
176 25.93 26.66 40.11 56.07 74.42 85.41 149.38 228.95
Cuadro 7.20: Tiempo de descifrado con curvas sobre 𝔽𝑝 en PC (configuración P1)
Figura 7.22: Tiempo de descifrado con curvas sobre 𝔽𝑝 en PC (configuración P1)


128 160 192
16 26.78 39.02 56.08
Longitud del mensaje (bytes) 32 26.15 39.11 56.36
48 26.07 38.93 56.16
64 26.11 39.07 56.34
80 25.86 40.28 56.49
96 26.06 40.06 55.56
112 27.09 40.12 56.19
128 25.97 40.35 57.34
144 26.22 40.63 56.87
160 26.52 39.67 56.91
176 25.90 40.12 57.22


128 160 192
Longitud del mensaje (bytes) 16 213.84 219.32 233.71
32 215.38 220.76 234.92
48 222.53 227.80 242.35
64 229.85 234.73 249.42
80 230.25 235.90 250.15
96 232.01 237.65 251.97
112 238.41 243.87 258.24
128 246.35 251.39 266.07
144 247.43 252.50 266.63
160 249.00 254.06 268.55
176 256.57 261.46 275.85
Cuadro 7.22: Tiempo de descifrado con curvas sobre 𝔽𝑝 en JCOP J3A e interfaz sin
Figura 7.24: Tiempo de descifrado con curvas sobre 𝔽𝑝 en JCOP J3A e interfaz sin

guración P3
La configuración P3 ha sido igualmente probada en las versiones para PC y

tarjetas JCOP J3A. El Cuadro 7.23 y la Figura 7.25 muestran los resultados de la
versión PC, mientras que el Cuadro 7.24 y la Figura 7.26 presentan el tiempo de
descifrado de mensajes de distinta longitud utilizando tarjetas JCOP J3A.

128 160 192
16 27.25 41.29 56.05
Longitud mensaje (bytes)
32 26.5 41.35 56.83

48 28.44 41.01 57.18
64 26.21 40.37 56.97
80 27.03 40.33 57.04
96 26.55 40.26 57.16
112 26.9 40.25 57.4
128 26.18 40.2 58.21
144 26.34 39.85 58.85
160 27.09 40.78 58.73

128 160 192
16 237.17 243.94 258.30
Longitud mensaje (bytes)
32 239.39 246.01 260.24

48 253.16 259.39 273.56
64 260.92 267.00 280.97
80 261.53 267.43 282.28
96 264.34 269.79 284.02
112 276.72 282.42 296.59
128 284.84 290.01 304.60
144 285.52 291.41 305.52
160 287.92 293.33 307.45
Cuadro 7.24: Tiempo de descifrado con curvas sobre 𝔽𝑝 en JCOP J3A e interfaz sin
Figura 7.26: Tiempo de descifrado con curvas sobre 𝔽𝑝 en JCOP J3A e interfaz sin
7.6. Rendimiento comparado 309
7.6. Rendimiento comparado

El objetivo de este apartado es presentar algunas comparaciones de especial inte-
rés, tomando como partida los datos obtenidos en las pruebas de cifrado y descifrado
expuestas en los apartados anteriores.
A fin de analizar el rendimiento general de las curvas sobre cuerpos primos y
binarios en una misma implementación, la Figura 7.27 muestra el tiempo medio de
cifrado y descifrado de un mismo mensaje de 160 bytes de longitud para cada una
de las curvas incluidas en las configuraciones M1 y P1, aplicables exclusivamente a
la versión de ECIES para PC.
Figura 7.27: Comparación del tiempo de ejecución en PC (configuraciones M1 y P1)
A continuación se presenta una comparativa del tiempo medio de cifrado y des-

cifrado (en las versiones PC y Java Card) de un mismo mensaje de 160 bytes de
longitud para cada una de las curvas incluidas en las configuraciones M2 (Figu-
ra 7.28), P2 (Figura 7.29) y P3 (Figura 7.30). Es importante tener en cuenta que,
dada la escala utilizada en las figuras, para poder mostrar en el mismo gráfico los
resultados de las implementaciones en PC y Java Card, los tiempos de cifrado y
descifrado en PC se encuentran superpuestos en gran parte de su trazado.
La Figura 7.31 muestra la comparación del tiempo de cifrado y descifrado em-
pleado por las tarjetas JCOP 41 (con la configuración M2) y JCOP J3A (con la
configuración P2) al gestionar un mensaje en claro de 64 bytes. De manera similar,
la Figura 7.32 muestra la misma comparación utilizando un mensaje de 160 bytes.
Figura 7.28: Comparación del tiempo de ejecución entre las versiones PC y Java Card
(configuración M2)
(configuración P2)
7.6. Rendimiento comparado 311
(configuración P3)
Es necesario tener en cuenta que, al tratarse de modelos con distintas versiones

del sistema operativo JCOP (sobre las que se han cargado applets diferentes, aunque
similares), y dado que no ha sido posible acceder a toda la información técnica de
estas tarjetas por tratarse de datos confidenciales (descripción del sistema operativo
JCOP, detalles de la implementación de las operaciones aritméticas sobre cuerpos
primos y binarios, tipos de contramedidas implementadas para evitar ataques de
canal lateral, etc.), no es posible determinar el motivo preciso de la diferencia de
resultados. Sin embargo, aun con las limitaciones mencionadas, este estudio es in-
teresante con el fin de obtener una aproximación del rendimiento comparado de
ambas tarjetas.
Figura 7.31: Comparación del tiempo de ejecución en las tarjetas JCOP 41 (configura-
ción M2) y JCOP J3A (configuración P2) al cifrar un mensaje de 64 bytes
Figura 7.32: Comparación del tiempo de ejecución en JCOP 41 (configuración M2) y

JCOP J3A (configuración P2) al cifrar un mensaje de 160 bytes
Capítulo 8
Conclusiones, aportaciones y trabajo

futuro

Este capítulo presenta las conclusiones derivadas del estudio e imple-
mentación del esquema de cifrado ECIES y de los resultados obtenidos
mediante las pruebas con las versiones desarrolladas para PC y Java
Card. De manera adicional, se describen las aportaciones realizadas por
esta Tesis, tanto en forma de artículos y presentaciones en congresos
como de soluciones ideadas para evitar las distintas limitaciones detec-
tadas. Por último, se incluyen las posibles líneas de trabajo que podrían
seguirse como continuación de esta Tesis.
8.1. Conclusiones
Tal como se ha comentado en diversos apartados, ECIES es un esquema de ci-
frado que dispone de múltiples opciones de implementación. En la presente Tesis
Doctoral se ha estudiado en profundidad el protocolo de cifrado ECIES y se han
desarrollado varias aplicaciones (para PC y tarjetas JCOP 41 y JCOP J3A) con el
objetivo de realizar pruebas en estas tres plataformas hardware con cinco configu-
raciones diferentes (M1, M2, P1, P2 y P3).
Como resultado del estudio previo realizado y de las pruebas efectuadas es posible
presentar las conclusiones detalladas en los siguientes apartados, las cuales están
agrupadas en función de los objetivos descritos en la Introducción.
313
314 8. Conclusiones, aportaciones y trabajo futuro
8.1.1. El esquema ECIES como estándar

A continuación se detallan las conclusiones a las que ha sido posible llegar res-
pecto a la consideración del esquema ECIES como estándar:
1. El esquema de cifrado y descifrado ECIES se encuentra especificado en los

estándares ANSI X9.63 [16], IEEE 1363a [109], ISO/IEC 18033-2 [136] y SECG
SEC 1 [254]. Las características concretas de cada una de dichas versiones están
descritas en §4.4 y §4.5.
Aunque las implementaciones de los cuatro estándares mencionados se basan,
en última instancia, en el esquema de cifrado DHIES [9, 10], existe una gran
variedad en lo relativo a las funciones HASH, KA, KDF, ENC y MAC per-
mitidas en cada estándar, así como en las características particulares (p. ej.,
el uso de parámetros opcionales, la interpretación de algunos elementos, etc.)
incluidas en esas versiones de ECIES.
2. A partir de las características particulares de cada estándar, hemos construido

11 configuraciones genéricas (es decir, independientes de las funciones HASH,
KA, KDF, ENC y MAC específicas utilizadas), de manera que cada una de
ellas sea válida al menos en un estándar. Dichas configuraciones se encuentran
descritas en §4.7.
3. De la revisión de las 11 configuraciones y de su aplicabilidad a cada estándar, se

puede afirmar que existen dos configuraciones (C01 y C02) compatibles con las
últimas versiones de los cuatro estándares mencionados. Dichas configuraciones
tienen como elemento característico la utilización de la función XOR como
algoritmo de cifrado simétrico.
Como consecuencia de la existencia de esas configuraciones y de al menos una
función específica permitida de forma común para cada una de las funciones
HASH, KA, KDF, ENC y MAC, se puede concluir que ECIES es un esquema
de cifrado que, a pesar de sus muchas opciones, permite ser implementado de
manera compatible con los cuatro estándares analizados.
8.1.2. Conjunto de parámetros compatibles con todos los es-

tándares
En relación al conjunto de parámetros compatibles con todos los estándares se
pueden realizar las siguientes conclusiones:
1. Existen dos configuraciones genéricas de ECIES compatibles con los cuatro

estándares analizados, denominadas C01 y C02, y descritas en §4.7.
8.1. Conclusiones 315
2. Dichas versiones compatibles tienen como elemento característico la utilización

de la función XOR como algoritmo de cifrado simétrico. Las diferencias entre
ambas configuraciones residen en la función HASH empleada, la función MAC,
el uso de parámetros opcionales en la función MAC, o una combinación de los
tres elementos citados.
3. A modo de ejemplo, se ha desarrollado una versión concreta compatible con

los cuatro estándares utilizando una selección específica de funciones HASH,
KA, KDF, ENC y MAC de entre las mostradas en el Cuadro 4.10. La versión
así construida, denominada ECIES-4, constituye el Algoritmo 4.16.
Sin embargo, es importante resaltar que la utilización de la función XOR como
algoritmo de cifrado simétrico provoca determinados problemas de seguridad
que, si se implementan las medidas necesarias para evitarlos y que permiten
mantener la compatibilidad con los cuatro estándares, limitan la utilización del
esquema ECIES, tal como se detalló en §4.9. Puesto que no existen más con-
figuraciones compatibles con los cuatro estándares, la mejor solución consiste
en utilizar una de las dos configuraciones compatibles con los tres estándares
más recientes (C05 y C06), y que permiten desarrollar implementaciones de
ECIES más seguras y flexibles en cuanto a su funcionalidad.
8.1.3. Desarrollo de la implementación de ECIES para PC

Las conclusiones que se derivan del desarrollo de la implementación de ECIES
para plataformas PC son las siguientes:
1. El lenguaje de programación Java, uno de los más extendidos actualmente,

permite la implementación de todas las funciones de la criptografía de cur-
vas elípticas sin necesidad de utilizar bibliotecas (libraries) adicionales. Como
ejemplo de ello, existen diversas bibliotecas criptográficas, analizadas en §3.3,
que incluyen funcionalidades de la ECC desarrolladas por empresas o grupos
de programadores, siendo los ejemplos más conocidos Bouncy Castle, IAIK y
FlexiProvider.
2. Las bibliotecas mencionadas, sin embargo, o no implementan ECIES o, en caso

de hacerlo, no permiten utilizar todas las funciones y parámetros presentes en
los estándares analizados. Debido a ello el autor de esta Tesis decidió desarro-
llar la versión de ECIES para PC implementando todas las clases necesarias
para utilizar los algoritmos relacionados con la ECC y las operaciones aritmé-
ticas, tanto para los puntos de las curvas elípticas como para los elementos de
los cuerpos finitos.
Esta opción ha permitido un grado de flexibilidad superior, al ser posible in-
corporar cualquier algoritmo durante el propio desarrollo, aunque ha requerido
un tiempo de desarrollo superior al de otras alternativas. El diagrama de clases

de la aplicación puede consultarse en 5.2, mientras que la descripción funcional
de la aplicación completa se encuentra en §5.3. Para mejorar la comprensión
del proceso de cifrado y descifrado, se ha incluido en §6.8 un ejemplo de cada
tipo de operación utilizando la aplicación desarrollada.
3. En cuanto a los algoritmos y características de ECIES incluidas en el desarrollo

para PC, puesto que el objetivo principal de esa versión de ECIES consiste en
poder realizar pruebas con distintas combinaciones de funciones y parámetros,
además de las combinaciones M1, M2, P1, P2 y P3 (definidas en §7.2), se
decidió incluir las funciones HASH, KA, KDF, ENC y MAC más habituales
en los estándares analizados, así como las opciones que permiten diferenciar
las configuraciones descritas en §4.7.
8.1.4. Estudio de la eficiencia de la implementación PC

A continuación se presentan las conclusiones que se han podido obtener mediante
las pruebas realizadas en PC con las configuraciones M1, M2, P1, P2 y P3.
1. La sobrecarga 𝛿 añadida durante el proceso de cifrado, definida en esta Tesis

como la diferencia entre la longitud del criptograma 𝒞 y la longitud del mensaje
en claro 𝔪, es irrelevante en las configuraciones M1 y P1 para mensajes cuya
longitud supere 500 bytes.
Por el contrario, para mensajes cuyo tamaño sea menor de 500 bytes, y espe-
cialmente cuando la longitud es menor de 64 bytes, el factor de expansión (es
decir, el cociente entre las longitudes de 𝒞 y 𝔪) tiene un valor elevado. Esto
implica que, a efectos de ancho de banda, ECIES es especialmente útil para
cifrar mensajes de mediano y gran tamaño.
2. Dada una determinada curva, el tiempo de cifrado y descifrado es práctica-

mente constante para todas las longitudes del mensaje a cifrar empleadas en
las pruebas con las configuraciones M1 y P1. Ello se debe a que el tiempo de
procesamiento de las funciones HASH, ENC, y MAC apenas varía para las
longitudes de mensajes utilizadas, siendo las operaciones con los puntos de la
curva y los elementos del cuerpo finito las que tienen una mayor incidencia en
el tiempo de procesamiento.
3. El tiempo de cifrado y descifrado al utilizar curvas distintas es claramente

diferente, lo que junto al anterior comentario permite concluir que, para las
longitudes de mensaje empleadas, el tipo de curva tiene un impacto en el
tiempo de procesamiento mucho mayor que la longitud del mensaje a cifrar,
debido tal como se ha comentado a la mayor complejidad de las operaciones
realizadas con puntos de la curva y elementos de los cuerpos finitos respecto

a las operaciones de cifrado simétrico.
4. El tiempo de cifrado y descifrado en la versión de ECIES para PC aumenta de

manera más rápida que la longitud de las claves, tal como puede apreciarse en
los Cuadros 8.1 y 8.2, donde la interpretación de las columnas es la siguiente:
Long. 𝔽2𝑚 y Long. 𝔽𝑝 representan la longitud en bits de las curvas de traba-
jo definidas sobre cuerpos finitos binarios y primos, respectivamente; Ratio 1
indica la relación entre la longitud de la curva de trabajo y la longitud de la
curva sect113r1 (Cuadro 8.1) o secp112r1 (Cuadro 8.2), medidas ambas longi-
tudes en bits; la columna Cifrado contiene el tiempo de cifrado de un mensaje
de 176 bytes de longitud para cada curva medido en milisegundos; Ratio 2
expresa el cociente entre el tiempo de cifrado utilizando la curva de trabajo y
el tiempo de cifrado con la curva de referencia sect113r1 o secp112r1 (en fun-
ción del cuadro); la columna Descifrado contiene el tiempo de descifrado de
un mensaje de 176 bytes de longitud para cada curva medido en milisegundos;
finalmente Ratio 3 muestra la relación entre el tiempo de descifrado utilizando
la curva de trabajo y el tiempo de cifrado con la curva sect113r1 o secp112r1
(dependiendo del cuadro).
Curva Long. 𝔽2𝑚 Ratio 1 Cifrado Ratio 2 Descifrado Ratio 3

sect113r1 113 1.00 28.34 1.00 29.7 1.00
sect131r1 131 1.16 36.26 1.28 38.9 1.31
sect163r1 163 1.44 59.67 2.11 66.5 2.24
sect193r1 193 1.71 82.53 2.91 89.8 3.02
sect233r1 233 2.06 102.31 3.61 104.5 3.52
sect239k1 239 2.11 105.54 3.72 111.6 3.75
sect283r1 383 3.39 129.96 4.59 132.8 4.47
sect409r1 409 3.62 225.53 7.96 228.2 7.68
sect571r1 571 5.05 368.50 13.00 364.6 12.28
Cuadro 8.1: Crecimiento del tiempo de cifrado y descifrado en PC (configuración M1)
5. La implementación de la aritmética de curvas definidas sobre cuerpos 𝔽𝑝 en

PC es más eficiente que la implementación sobre cuerpos 𝔽2𝑚 . Esto se debe a
la utilización de bases polinómicas en lugar de bases normales en la implemen-
tación de las operaciones con cuerpos binarios. Las bases normales son más
eficientes y permitirían obtener mejores resultados, pero su uso está restringido
por las patentes expuestas en §2.6.9.
Curva Long. 𝔽𝑝 Ratio 1 Cifrado Ratio 2 Descifrado Ratio 3

secp112r1 112 1.00 23.55 1.00 25.93 1.00
secp128r1 128 1.14 24.12 1.02 26.66 1.03
secp160r1 160 1.43 39.77 1.69 40.11 1.55
secp192k1 192 1.71 53.96 2.29 56.07 2.16
secp224r1 224 2.00 69.88 2.97 74.42 2.87
secp256k1 256 2.29 79.33 3.37 85.41 3.29
secp384r1 384 3.43 143.07 6.07 149.38 5.76
secp521r1 521 4.65 228.08 9.68 228.95 8.83
Cuadro 8.2: Crecimiento del tiempo de cifrado y descifrado en PC (configuración P1)
8.1.5. Desarrollo de la implementación de ECIES en tarjetas

Java Card
Las conclusiones que se pueden extraer del proceso de desarrollo de los applets
Java Card que implementan ECIES, denominados JCOP-M2, JCOP-P2 y JCOP-P3,
son las siguientes:
1. El soporte actual a la criptografía de curva elíptica por parte de los grandes

fabricantes de tarjetas inteligentes (Gemalto, Oberthur, G&D, etc.) es todavía
escaso.
2. En el mercado existe una amplia gama de tarjetas JCOP (desarrolladas ini-

cialmente por IBM, y en la actualidad por NXP) compatibles con distintas
versiones de Java Card. De entre las tarjetas JCOP que implementan funcio-
nalidades de la ECC, fueron seleccionados para su uso en esta Tesis los modelos
JCOP 41 y JCOP J3A, debido principalmente a su disponibilidad. Para di-
chas tarjetas se han desarrollado tres versiones del applet ECIES, denominadas
JCOP-M2, JCOP-P2 y JCOP-P3, tal como se menciona en §6.6.
3. Para poder realizar comparaciones más fiables, sería deseable que los fabri-
cantes de tarjetas inteligentes desarrollaran modelos que permitieran utilizar
indistintamente curvas sobre cuerpos finitos tanto primos como binarios. En
el caso de los modelos utilizados en la Tesis, las tarjetas JCOP 41 únicamente
implementan curvas definidas sobre cuerpos binarios, mientras que las tarjetas
JCOP J3A sólo incluyen curvas construidas sobre cuerpos binarios.
4. Los fabricantes deben esforzarse en el futuro en implementar todas las curvas

sobre cuerpos finitos incluidas en Java Card 3.0, especialmente aquellas de
longitud 224, 256 y 384 bits definidas sobre cuerpos binarios. Estas longitu-
des serán paulatinamente más importantes según aumenten los requisitos de
seguridad de las aplicaciones con el paso del tiempo.
5. A pesar de estar definida en las API de Java Card, la función HMAC no está
incluida en las tarjetas JCOP probadas. Aunque el desarrollo de la función
HMAC apropiada no ha sido complejo, el rendimiento global mejoraría si
dicha función fuera ejecutada a través de la llamada estándar al API Java
Card.
6. Igualmente sería deseable que el API Java Card añadiera en el futuro la función
KDF2, puesto que de hecho actualmente dicha API no incluye ninguna función
KDF.
7. De manera equivalente sería recomendable que las tarjetas comerciales incor-
poraran en el futuro próximo las modalidades con relleno del algoritmo AES
definidas en Java Card 3.0, lo que evitaría la codificación de sistemas alterna-
tivos de relleno por parte de las aplicaciones que se comunican con la tarjeta
inteligente.
8.1.6. Estudio de la eficiencia de la implementación Java Card

La siguiente lista recoge las conclusiones obtenidas gracias a las pruebas reali-
zadas en tarjetas JCOP 41 con la configuración M2 y en tarjetas JCOP J3A con las
configuraciones P2 y P3.
1. Los tiempos de cifrado y descifrado incluyen tanto el tiempo de transmisión

(del lector a la tarjeta con la APDU de tipo comando, y de la tarjeta al lector
con la APDU de tipo respuesta) como el tiempo de procesamiento realizado
por la tarjeta, por lo que es necesario tener en cuenta este hecho al realizar
comparaciones.
2. Las tarjetas JCOP 41, que permiten el envío de comandos mediante dos in-
terfaces (con contactos y sin contactos) presentan un rendimiento diferente
en función de la interfaz empleada. Aunque la falta de detalles técnicos sobre
las tarjetas sólo permiten realizar suposiciones sobre este hecho, el motivo más
probable podría ser la diferente frecuencia de la señal externa de reloj utilizada
en ambas interfaces (4.8 MHz frente a 13.56 MHz), lo que genera que la uti-
lización de la interfaz sin contactos ofrezca mejores resultados en las pruebas
de cifrado y descifrado.
3. Además de las diferencias respecto al tiempo de cifrado y descifrado, la utiliza-
ción de distintas interfaces produce comportamientos marcadamente distintos
en la misma tarjeta. Si se observan los tiempos de cifrado para las tarjetas
JCOP 41 en ambos casos (Figuras 7.11 y 7.12), se puede comprobar que en
la interfaz con contactos el comportamiento es prácticamente lineal, mientras
que en la interfaz sin contactos el aumento del tiempo de cifrado se produce
por escalones.
De nuevo, con los datos disponibles sobre el modelo JCOP 41, únicamente se
puede conjeturar que, a igualdad del resto de los factores, el comportamiento
del coprocesador 3DES depende de la frecuencia de la señal externa de re-
loj. Los tiempos de descifrado muestran el mismo comportamiento en estas
circunstancias (Figuras 7.20 y 7.21).
4. La sobrecarga 𝛿 añadida durante el proceso de cifrado en las configuraciones

M2, P2 y P3 implementadas en Java Card es muy elevada para mensajes en
claro cuya longitud sea menor de 80 bytes, tal como se puede apreciar en las
Figuras 7.5, 7.7 y 7.8, lo que implica que la transmisión de esos mensajes es
poco eficiente desde el punto de vista del ancho de banda.
5. El aumento del tiempo de cifrado y descifrado en las tarjetas JCOP al incre-

mentar la longitud de las claves y mantener el mensaje a cifrar es menor que
el aumento relativo de la longitud de las claves, tal como puede observarse
en los Cuadros 8.3, 8.4, 8.5 y 8.6, donde el significado de las columnas es el
siguiente: Long. 𝔽𝑝 y Long. 𝔽2𝑚 representan la longitud en bits de las curvas
definidas sobre cuerpos primos y binarios, respectivamente; Ratio 1 indica la
relación entre la longitud de la curva de trabajo y la longitud de la curva
sect113r1 (Cuadros 8.3 y 8.4) o secp128r1 (Cuadros 8.5 y 8.6), medidas ambas
longitudes en bits; la columna Cifrado contiene el tiempo de cifrado para cada
curva medido en milisegundos; Ratio 2 expresa el cociente entre el tiempo de
cifrado de un mensaje de 176 bytes utilizando la curva de trabajo y el tiempo
de cifrado con la curva sect113r1 o secp128r1 (en función del cuadro); la co-
lumna Descifrado contiene el tiempo de descifrado para cada curva medido en
milisegundos; finalmente Ratio 3 muestra la relación entre el tiempo de desci-
frado de un mensaje de 176 bytes utilizando la curva de trabajo y el tiempo
de cifrado con la curva sect113r1 o secp112r1 (dependiendo del cuadro).

sect113r1 113 1.00 341.52 1.00 244.41 1.00
sect131r1 131 1.16 358.64 1.05 249.53 1.02
c2pnb163v1 163 1.44 384.40 1.13 258.53 1.06
sect193r1 193 1.70 418.98 1.23 267.34 1.09
Cuadro 8.3: Crecimiento del tiempo de cifrado y descifrado en JCOP 41 e interfaz sin
Este comportamiento es el contrario que el observado en la versión para PC,

donde el tiempo de cifrado y descifrado aumenta más rápidamente que la lon-
gitud de las curvas empleadas. Una posible explicación de este resultado lo
constituye la utilización del criptoprocesador de clave pública en las tarjetas
JCOP, lo que permite que la diferencia en rendimiento entre operaciones rea-
lizadas con una u otra curva sea en proporción más pequeña que la medida al

sect113r1 113 1.00 528.36 1.00 387.98 1.00
sect131r1 131 1.16 548.35 1.04 392.21 1.01
c2pnb163v1 163 1.44 571.23 1.08 400.50 1.03
sect193r1 193 1.70 640.54 1.21 408.76 1.05
Cuadro 8.4: Crecimiento del tiempo de cifrado y descifrado en JCOP 41 e interfaz con

secp128r1 128 1.00 529.22 1.00 256.57 1.00
secp160r1 160 1.25 561.74 1.06 261.46 1.02
P-192 192 1.5 636.95 1.20 275.85 1.08
Cuadro 8.5: Crecimiento del tiempo de cifrado y descifrado en JCOP J3A e interfaz
sin contactos (configuración P2)
utilizar directamente la CPU del PC (aunque el rendimiento global del crip-

toprocesador de la tarjeta inteligente sea peor que el de la CPU). Es decir, el
criptoprocesador de las tarjetas JCOP, a pesar de las limitaciones tecnológi-
cas propias de arquitecturas de 8 bits, comparativamente está más optimizado
para la aritmética de puntos de la curva y de elementos del cuerpo finito que
la CPU del PC.
6. El tiempo de descifrado en las tarjetas Java Card es sensiblemente inferior al

tiempo de cifrado. Esto podría deberse, a falta de más datos sobre el funciona-
miento de las tarjetas y sus coprocesadores, a que en la operación de cifrado se
ejecuta un paso adicional relacionado con la aritmética de puntos de la curva
y elementos del cuerpo finito (la generación pseudoaleatoria del par de claves
temporal) que no es necesario durante el descifrado.
7. Mientras que el tiempo de descifrado para longitudes de clave equivalentes

es similar en las tarjetas JCOP 41 y JCOP J3A cuando ambas utilizan la
interfaz sin contactos, en cambio el tiempo de cifrado es claramente superior
en las tarjetas JCOP J3A en condiciones similares. Puesto que los tiempos de

secp128r1 128 1.00 560.78 1.00 287.92 1.00
secp160r1 160 1.25 591.69 1.06 293.33 1.02
P-192 192 1.5 668.73 1.19 307.45 1.07
Cuadro 8.6: Crecimiento del tiempo de cifrado y descifrado en JCOP J3A e interfaz
sin contactos (configuración P3)
descifrado en ambos casos son similares, no es posible atribuir la diferencia al

producto escalar realizado durante el procedimiento Diffie-Hellman (ya que se
realiza tanto en el proceso de cifrado como de descifrado), lo que deja como
posible razón para este hecho la menor optimización del proceso de generación
del par de claves aleatorias en 𝔽𝑝 respecto a 𝔽2𝑚 .
8. Debido a la naturaleza de la comunicación mediante comandos APDU entre

una aplicación externa y una tarjeta inteligente, y a las características crip-
tográficas implementadas en las tarjetas JCOP analizadas, si se desea que la
respuesta a una petición de cifrado o descifrado esté contenida en una única
APDU de respuesta, es necesario limitar la longitud máxima de los mensajes
en claro a 176 bytes en el caso de las configuraciones M2 y P2, y 160 bytes para
la configuración P3. La diferencia se debe a que la configuración P3 genera un
código MAC de 32 bytes, mientras que el código generado en las implementa-
ciones P2 y M2 es de 20 bytes. Esta longitud podría extenderse en el caso de
que las tarjetas JCOP permitieran representar los puntos de una curva elíptica
de forma comprimida.
9. La utilización de mensajes en claro de longitudes mayores a las expuestas en el

punto anterior provocaría un deterioro del rendimiento de la implementación.
Por una parte, sería necesario intercambiar varias APDU para poder recuperar
la totalidad del criptograma (o del mensaje en claro en la operación de desci-
frado). Por otra parte, dado que todas las variables deben estar almacenadas
temporalmente en la memoria de las tarjetas inteligentes para su procesado, y
puesto que la cantidad de RAM en las tarjetas es muy limitada, la utilización
de mensajes de excesivo tamaño provocaría que las variables tuvieran que ser
almacenadas en memoria EEPROM en lugar de en memoria RAM, siendo la
memoria EEPROM notablemente más lenta que la memoria RAM.
Como ejemplo de esta afirmación, la primera implementación de la versión
JCOP-M2, que guardaba todas las variables en memoria EEPROM en lugar
de en memoria RAM, ofrecía un tiempo medio (teniendo en cuenta las cuatro
curvas implementadas) de cifrado de aproximadamente 2 segundos utilizando
la interfaz con contactos, en lugar del tiempo medio de aproximadamente 500
milisegundos necesario en la versión final de la configuración M2 que almace-
na todas las variables en memoria RAM. En esta última versión, la cantidad
de memoria RAM libre tras la asignación de todas las variables es de 16 by-
tes, habiendo sido necesario reutilizar variables a fin de que todas estuvieran
situadas en memoria RAM.
10. Si se analizan los datos desde una perspectiva diferente, manteniendo fija la
longitud de la clave y aumentando la longitud del mensaje en claro, se pue-
de afirmar que en la mayoría de los casos de cifrado, el incremente relativo
al pasar de un mensaje de 16 bytes a otro de 160 bytes es de aproximada-
mente el 10 %, tal como puede observarse en los Cuadros 8.7 y 8.8 (relativos
a las tarjetas JCOP 41 utilizando la interfaz sin contactos y con contactos,

respectivamente), y los Cuadros 8.9 y 8.10 (referidos a las tarjetas JCOP J3A
utilizando las configuraciones P2 y P3, respectivamente). La única excepción
a esta afirmación la consitutuyen las pruebas realizadas con tarjetas JCOP 41
empleando la interfaz con contactos, donde el incremento es mucho mayor.
Cif. 16 Cif. 160 Ratio 1 Descif. 16 Descif. 160 Ratio 2

sect113r1 296.74 331.82 1.12 197.74 234.46 1.20
Curva
sect131r1 314.65 350.70 1.11 203.12 239.58 1.18

c2pnb163v1 332.71 368.74 1.11 212.04 248.60 1.17
sect193r1 367.64 403.70 1.10 222.08 258.62 1.16
Cuadro 8.7: Incremento relativo del tiempo de ejecución en JCOP 41 e interfaz sin

sect113r1 363.51 509.34 1.40 223.78 368.92 1.65
Curva
sect131r1 384.52 529.41 1.38 228.21 373.29 1.64

c2pnb163v1 407.35 552.31 1.35 236.18 381.45 1.62
sect193r1 446.56 591.55 1.32 245.19 390.04 1.59
Cuadro 8.8: Incremento relativo del tiempo de ejecución en JCOP 41 e interfaz con
Cif. 16 Cif. 160 Ratio 1 Des. 16 Des. 160 Ratio 2

secp128r1 481.55 522.50 1.08 213.84 249.00 1.16
Curva
secp160r1 518.24 554.08 1.07 219.32 254.06 1.16

P-192 587.76 623.73 1.06 233.71 268.55 1.15
Cuadro 8.9: Incremento relativo del tiempo de ejecución en JCOP J3A e interfaz sin
Respecto al proceso de descifrado es posible hacer una afirmación equivalente,

ya que el incremento en la mayoría de los casos es aproximadamente del 20 %,
con la excepción de nuevo de las tarjetas JCOP 41 y la interfaz con contactos,
donde el incremento es ciertamente superior.
11. Debido a la falta de las clases relacionadas con la criptografía de curvas elíp-
ticas en tarjetas sin coprocesador PKI, no ha sido posible determinar el ren-
dimiento de las aplicaciones sin utilizar dicho criptoprocesador. Sin embargo,
debido a la naturaleza de las operaciones a realizar (multiplicación escalar de

secp128r1 512.54 560.78 1.09 237.17 287.92 1.21
Curva
secp160r1 543.31 591.69 1.09 243.94 293.33 1.20

P-192 613.50 668.73 1.09 253.16 307.46 1.21
Cuadro 8.10: Incremento relativo del tiempo de ejecución en JCOP J3A e interfaz sin
un punto de la curva, generación pseudoaleatoria de un punto de la curva,

etc.), es razonable suponer que el rendimiento sin coprocesador se degradaría
de manera muy marcada. La falta de tarjetas inteligentes con soporte ECC
pero sin criptoprocesador PKI podría ser un argumento más a favor de esta
suposición.
8.1.7. Comparativa entre las versiones PC y Java Card

A continuación se resumen las conclusiones derivadas de la comparación entre
las implementaciones de ECIES para PC y Java Card:
1. Como era de esperar, el rendimiento de la implementación en tarjetas Java

Card con un procesador de 8 bits, coprocesador criptográfico y memoria RAM
limitada es sensiblemente inferior al de la versión para PC, que ha sido eje-
cutada en un equipo con procesador de 32 bits y una cantidad de memoria
ampliamente superior a la requerida por la aplicación.
2. Dada la decisión de realizar pruebas con mensajes con una longitud máxima
de 176 bytes (160 bytes en las pruebas con las tarjetas JCOP J3A y la confi-
guración P3), al no existir dicha limitación para la version PC, el número de
pruebas en las que es posible establecer una comparación entre las versiones
PC y Java Card es pequeño comparado con el número de pruebas realizadas
en la versión PC.
3. Mientras que el tiempo de cifrado y descifrado es prácticamente el mismo en
la versión PC para una misma curva y longitudes del mensaje inferiores a 176
bytes, tanto en las tarjetas JCOP 41 como en JCOP J3A el tiempo de cifrado
es superior al de descifrado.
8.1.8. Configuración de ECIES resistente a ataques

Una vez analizada la seguridad de ECIES en §4.9, las conclusiones que se pueden
obtener sobre la resistencia a ataques de las distintas versiones de ECIES son las
siguientes:
8.2. Aportaciones 325
1. Las configuraciones C01 y C02 compatibles con los cuatro estándares son sus-
ceptibles de sufrir ataques debido a la utilización de la función XOR como
algoritmo de cifrado simétrico.
2. De las tres soluciones al problema de la maleabilidad descritas en §4.9.1.2,

la única que es posible implementar manteniendo la compatibilidad con los
cuatro estándares consiste en fijar la longitud de los mensajes a cifrar, tal
como se ha comentado en §8.1.1.
3. Puesto que con la única solución compatible con todos los estándares la fun-
cionalidad de ECIES queda seriamente limitada, se hace necesario seleccionar
otra configuración como punto de partida para cualquier implementación segu-
ra de ECIES. Dado que exceptuando C01 y C02 no existen más configuraciones
compatibles con los cuatro estándares, las candidatas lógicas son aquellas con-
figuraciones recogidas en los tres estándares más recientes, que resultan ser
C05 y C06. Al igual que sucedió en §4.8, es posible definir a partir de las
configuraciones C05 y C06 múltiples versiones compatibles con dichas confi-
guraciones, y que se diferencien en la función HASH, la función MAC, el uso
de argumentos opcionales en la función de autenticación o una combinación
de esos tres elementos.
4. El Algoritmo 4.17 define una versión del esquema de cifrado, denominada

ECIES-3, que constituye una de las posibles variantes compatibles con las con-
figuraciones C05 y C06 definidas por IEEE 1363a, ISO/IEC 18033-2 y SECG
SEC 1. ECIES-3 incluye los elementos necesarios para resistir cualquiera de los
ataques contra ECIES conocidos y descritos en §4.9, utilizando el algoritmo
de cifrado AES en modo CBC con relleno PKCS#5 y claves de 256 bytes,
la función resumen SHA-256, la función de derivación de claves KDF2 y la
función de autenticación HMAC-SHA-256.
8.2. Aportaciones
La presente Tesis doctoral incluye la especificación y desarrollo de una imple-
mentación software de ECIES, para lo cual se ha creado una versión utilizando Java
SE para entornos PC, y otra versión (con tres variantes) para tarjetas Java Card.
Hasta donde el autor de esta Tesis conoce, se trata de la primera implementación
del protocolo ECIES en ambas plataformas, permitiendo además en la versión para
PC la selección de manera dinámica de la configuración específica a utilizar por el
usuario.
Como era predecible, durante el desarrollo el autor ha encontrado diversas di-
ficultades y obstáculos. En primer lugar, los estándares que incluyen ECIES como
algoritmo de cifrado presentan un número de opciones muy elevado, estando en
algunos casos dichas opciones desaconsejadas en estándares posteriores debido al

descubrimiento de alguna vulnerabilidad. Ello ha provocado que la tarea de compa-
ración y selección de las opciones a implementar haya sido especialmente laboriosa
en comparación con la implementación de otros estándares criptográficos.
El segundo obstáculo digno de mención ha sido la enorme dificultad para conse-
guir tarjetas Java Card que implementen criptografía de curva elíptica. Ninguno de
los principales fabricantes de tarjetas (Gemalto, Oberthur, G&D, etc.) disponían de
productos comerciales que incluyeran primitivas para trabajar con ECC en el mo-
mento de inicio de los desarrollos. Afortunadamente, la existencia de tarjetas JCOP
(desarrolladas originalmente por IBM) permitió descargar y probar los applets en
tarjetas reales, aunque la obtención de dichas tarjetas no fue sencilla.
Debido a la compra de la línea de productos JCOP por parte de NXP en 2008,
a pesar de que NXP ha creado nuevas versiones de las tarjetas JCOP en los últimos
años, debido a limitaciones comerciales las tiendas de electrónica de internet sólo
pueden comercializar las tarjetas JCOP originales de IBM, como por ejemplo el
modelo JCOP 41 utilizado en esta Tesis y que tiene implementada la versión 2.2.1
del sistema operativo JCOP. Aunque esta tarjeta implementa funciones ECC sobre
cuerpos binarios, al tratarse de tarjetas con casi 7 años de antigüedad no disponían
de otros algoritmos como AES o SHA-256.
Gracias a la colaboración con NXP, fue posible acceder a las nuevas tarjetas
J3A con sistema operativo JCOP v2.4.1. Estas tarjetas, además de los algoritmos
mencionados, implementan las funciones ECC sobre cuerpos finitos primos, por lo
que gracias a este producto ha sido posible realizar una comparación más amplia de
ECIES con sendas versiones Java Card para cuerpos primos y binarios.
El trabajo realizado en las sucesivas etapas de esta Tesis Doctoral ha permi-
tido dar a conocer parte de la investigación mediante presentaciones en congresos
y artículos en revistas especializadas, contribuciones todas ellas aceptadas tras las
procedentes revisiones ciegas por pares. En este sentido, las aportaciones realizadas
han sido las siguientes:
∙ Elliptic Curve Criptography: Java implementation issues [81]: presentación

en la 39th IEEE International Carnahan Conference on Security Technology
(ICCST) celebrado en Las Palmas de Gran Canaria en octubre de 2005, siendo
publicado en las actas del congreso.
∙ Estado del arte de las implementaciones Java de criptografía de curva elíptica

[82]: presentación en el I Simposio sobre Seguridad Informática dentro del I
Congreso Español de Informática (CEDI) celebrado en Granada en septiembre
de 2005, junto con la publicación en las actas del congreso.
∙ Sobre la clasificación de curvas hiperelípticas de género 2 definidas en cuerpos

finitos [102]: publicación en las actas del I Simposio sobre Seguridad Infor-
8.3. Trabajo futuro 327
mática dentro del I Congreso Español de Informática (CEDI) celebrado en

Granada en septiembre de 2005.
∙ Elliptic Curve Cryptography. Java platform implementations [83]: presentación

en la 23rd International Conference for Automation of Engineering and Re-
search (SAER-2009) - International Conference on Information Technologies
(InfoTech-2009) celebrado en Varna (Bulgaria) en septiembre de 2009, junto
con la publicación en las actas del congreso. Este mismo artículo fue publica-
do posteriormente en el número 4 del International Journal on Information
Techonologies & Security [84].
∙ A Java implementation of the Elliptic Curve Integrated Encryption Scheme

[85]: presentación en el 2010 International Conference on Security & Manage-
ment (SAM) celebrado en Las Vegas en julio de 2010, siendo publicado en las
actas del congreso de manera adicional.
∙ A comparison of the standardized versions of ECIES [86]: publicación en las

actas del 6th International Conference on Information Assurance and Security
(IAS), celebrado en Atlanta en agosto de 2010.
∙ A survey of the elliptic curve integrated encryption scheme [90]: publicado

en el volumen 2 (número 2) de la revista Journal of Computer Science and
Engineering en agosto de 2010.
∙ Security and practical considerations when implementing the Elliptic Curve

Integrated Encryption Scheme [87]: enviado para su publicación en la revista
Journal of Systems and Software (actualmente en estado de revisión).
∙ Performance evaluation of the Elliptic Curve Integrated Encryption Scheme

implemented in PC and Java Card [88]: enviado para su publicación en la
revista Computers & Mathematics with Applications (actualmente en estado
de revisión).
∙ Java Card implementation of the Elliptic Curve Integrated Encryption Scheme

using prime and binary finite fields [89]: enviado para su publicación en la
revista International Journal of Information Security (actualmente en estado
de revisión).
8.3. Trabajo futuro

El trabajo efectuado en esta Tesis sugiere la posibilidad de continuar algunas
de las líneas de investigación desarrolladas e incluso iniciar otras nuevas asociadas
a aspectos que, aunque estén situados fuera de los objetivos de la presente Tesis, se
encuentran relacionados con los temas tratados.
∙ Respecto a la implementación en PC de ECIES, las operaciones aritméticas

de los cuerpos 𝔽𝑝 y 𝔽2𝑚 podrían optimizarse a fin de aumentar la velocidad de
las operaciones de cifrado y descifrado. En concreto, una posible mejora con-
sistiría en utilizar coordenadas homogéneas y mixtas en lugar de únicamente
coordenadas afines en las operaciones relacionadas con los puntos de una curva
elíptica, puesto que dependiendo de la operación (suma de puntos, multiplica-
ción de un punto por un escalar, etc.) cada tipo de coordenadas requiere un
esfuerzo computacional diferente, siendo necesario analizar qué combinación
de tipos de coordenadas sería más eficiente para las operaciones de cifrado y
descifrado.
∙ Una funcionalidad que se podría añadir a la implementación en PC (no así a

la implementación en tarjetas inteligentes, por los requisitos de procesamiento
necesarios) consiste en la implementación de los algoritmos incluidos en los
estándares para la generación aleatoria de curvas elípticas, así como la función
necesaria para contar los puntos de una curva elíptica, incluyendo las opciones
pertinentes en la interfaz del programa para que un usuario pudiera generar
aleatoriamente una curva en función de los parámetros introducidos por dicho
usuario (tamaño del cuerpo finito, tipo de curva, etc.) y posteriormente obtener
el cardinal de dicha curva. Sería necesario para ello comparar los algoritmos
existentes, principalmente los desarrollados por Schoof [238, 239], Atkins [22],
Elkies [70] y Satoh [236].
∙ En cuanto las implementaciones en tarjetas inteligentes, los applets desarrolla-

dos están optimizados para el cifrado y descifrado de mensajes cuya longitud
esté limitada a una única APDU. Puesto que una aplicación comercial de
ECIES podría requerir el cifrado y descifrado de datos de mayor longitud, se-
ría necesario rediseñar los applets con el objetivo de que pudieran gestionar
volúmenes de datos mayores sin que su rendimiento se viera penalizado, para
lo que es imprescindible incrementar la reutilización de las variables de mane-
ra que todas ellas puedan residir en la memoria RAM o bien utilizar tarjetas
inteligentes con una mayor cantidad de memoria RAM disponible.
∙ Puesto que el protocolo de firma digital basado en curvas elípticas, ECDSA, se

encuentra más extendido que el protocolo de cifrado, ECIES, su implementa-
ción resulta menos interesante, ya que incluso en Java Card existen primitivas
para utilizar ECDSA. Sin embargo, lo que no se encuentra implementado son
las firmas no estándares, es decir, las firmas delegadas [162, 273], múltiples
[160, 242] o en nombre de un grupo [19, 20]. Una nueva línea de investigación
consistiría en comprobar la viabilidad, y en su caso realizar la implementación,
de dichos esquemas no estándares de firma en tarjetas inteligentes.
∙ Igualmente interesante sería realizar un estudio sobre la resistencia a ataques

de canal lateral de las implementaciones realizadas sobre las tarjetas JCOP
8.3. Trabajo futuro 329
41 y JCOP J3A, utilizando para ello el material adecuado (equipos láser, de

implantación iónica, etc.).
∙ Por último, en función de la disponibilidad en el mercado de otras tarjetas Java

Card que implementen funciones ECC, sería recomendable comparar el rendi-
miento de los applets en las tarjetas JCOP 41 y JCOP J3A con el rendimiento
en otros modelos JCOP o en tarjetas inteligentes de otros fabricantes.
Notación
0x Prefijo que identifica las cadenas binarias hexadecimales

A2 (𝔽) Plano afín sobre el cuerpo 𝔽
𝑎 Elemento del cuerpo 𝔽 que define la curva 𝐸
𝑏 Elementos del cuerpo 𝔽 que define la curva 𝐸
𝔠 Mensaje cifrado
𝒞 Criptograma
Δ Discriminante de una curva elíptica
𝛿𝐶 Diferencia entre la longitud del criptograma y el mensaje en claro usan-
do la configuración C
𝐸 Curva elíptica
𝐸(𝔽) Curva elíptica definida sobre el cuerpo 𝔽
EK Clave de cifrado
𝔽 Cuerpo finito, equivalente a 𝔽𝑞
𝔽𝑝 Cuerpo finito primo
𝔽2𝑚 Cuerpo finito binario
𝑓 (𝑥) Polinomio irreducible de grado 𝑚 que define la base polinómica de 𝔽2𝑚
𝐺 Punto de la curva que actúa como generador
𝑔 Género de una curva algebraica
ℎ Cofactor de la curva
𝑘1 Primer exponente del polinomio reductor 𝑓 (𝑥)
331
332 Notación
𝑘2 Segundo exponente del polinomio reductor 𝑓 (𝑥)

𝑘3 Tercer exponente del polinomio reductor 𝑓 (𝑥)
𝑚 Número entero que especifica el cuerpo finito 𝔽2𝑚
𝔪 Mensaje en claro sin cifrar
MK Clave MAC
𝑛 Número primo que representa el orden del punto 𝐺
𝒪 Punto en el infinito
P2 (𝔽) Plano proyectivo sobre el cuerpo 𝔽
𝑃 Representación binaria del punto 𝑃
𝑃 Punto de la curva 𝐸 con coordenadas expresadas indistintamente como
(𝑃𝑥 , 𝑃𝑦 ) o (𝑥𝑃 , 𝑦𝑃 )
𝑝 Número primo que especifica el cuerpo finito 𝔽𝑝
𝑞 Número de elementos del cuerpo 𝔽𝑞
𝑃𝑥 Primera coordenada del punto 𝑃 , equivalente a 𝑥𝑃
𝑃𝑦 Segunda coordenada del punto 𝑃 , equivalente a 𝑦𝑃
𝒫 Conjunto de parámetros que caracterizan la curva 𝐸
u Clave privada del usuario U
U Clave pública del usuario U
U Usuario que envía el criptograma
v Clave privada del usuario V
V Clave pública del usuario V
V Usuario que recibe el criptograma
⌈⌉ Función techo
Glosario
3FF 3rd Form Factor

3GPP 3rd Generation Partnership Project
ABS Acrilonitrilo Butadieno Estireno
ACCA Adaptive Chosen Ciphertext Attack
ACE Advanced Cryptographic Engine
ACPA Adaptive Chosen Plaintext Attack
AES Advanced Encryption Standard
AMS American Mathematical Society
ANSI American National Standards Institute
APDU Application Protocol Data Unit
API Application Programming Interface
ASCII American Standard Code for Information Interchange
ASN.1 Abstract Syntax Notation One
ATM Automated Teller Machine
ATR Answer to Reset
AWT Abstract Window Toolkit
BCD Binary-Coded Decimal
BER Basic Encoding Rules
BSI Bundesamt für Sicherheit in der Informationstechnik (Federal Of-
fice for Security)
333
334 Glosario
CAP Converted Applet

CBC Cipher-Block Chaining
CCA Chosen Ciphertext Attack
CER Canonical Encoding Rules
CLA Class
CLK Clock
CMOS Complementary Metal-Oxide Semiconductor
CMS Cryptographic Message Syntax
COA Ciphertext-Only Attack
CPA Chosen Plaintext Attack
CPU Central Processing Unit
CRL Certificate Revocation List
CRT Chinese Remainder Theorem
CTR Counter
DEM Data Encapsulation Mechanism
DER Distinguished Encoding Rules
DES Data Encryption Standard
DHAES Diffie-Hellman Augmented Encryption Scheme
DH Diffie-Hellman
DHC Diffie-Hellman with Cofactor
DHIES Diffie-Hellman Integrated Encryption Scheme
DHP Diffie-Hellman Problem
DLAES Discrete Logarithm Augmented Encryption Scheme
DLP Discrete Logarithm Problem
DOI Document Object Identifier
DSA Digital Signature Algorithm
ECC Elliptic Curve Cryptography
ECDH Elliptic Curve Diffie-Hellman
ECDLP Elliptic Curve Discrete Logarithm Problem
Glosario 335
ECDSA Elliptic Curve Digital Signature Algorithm

ECIES Elliptic Curve Integrated Encryption Scheme
ECMQV Elliptic Curve Menezes-Qu-Vanstone
EEPROM Electrically Erasable and Programmable Read Only Memory
EPROM Erasable Programmable Read Only Memory
ETSI European Telecommunications Standards Institute
FRAM Ferroelectric Random-Access Memory
GDLP Generalized Discrete Logarithm Problem
GND Ground
GNU Gnu’s Not Unix
GPL General Public Licence
GSM Global System for Mobile Communications
HMAC Hashed Message Authentication Code
IAIK Institut für Angewandte Informationsverarbeitung und Kommu-
nikationstechnologie (Institute for Applied Information Proces-
sing and Communications)
ICC Integrated Circuit Card
ID Identifier
IEC International Electrotechnical Commission
IEEE Institute of Electrical and Electronics Engineers
IETF Internet Engineering Task Force
IFP Integer Factorization Problem
INS Instruction
I/O Input/Output
KA Key Agreement
KEM Key Encapsulation Mechanism
J2SE Java 2 Platform Standard Edition
J2EE Java 2 Platform Enterprise Edition
JAAS Java Authentication and Authorization Service
336 Glosario
JCA Java Cryptography Architecture

JCE Java Cryptography Extension
JCP Java Community Process
JCRE Java Card Runtime Environment
JCRMI Java Card Remote Method Invocation
JCVM Java Card Virtual Machine
JDK Java Development Kit
JIT Just in Time
JLS Java Language Specification
JRE Java Runtime Environment
JSE Java Standard Edition
JSSE Java Secure Socket Extension
JSR Java Specification Request
JTC Joint Technical Committee
JVM Java Virtual Machine
KDF Key Derivation Function
KEM Key Encapsulation Mechanism
KPA Known Plaintext Attack
LNCS Lecture Notes in Computer Science
MAC Message Authentication Code
ME Mobile Equipment
MIME Multipurpose Internet Mail Extensions
MSC Mathematics Subject Classification
NESSIE New European Schemes for Signature, Integrity, and Encryption
NFC Near Field Communication
NGICC Next Generation Integrated Circuit Card
NIST National Institute of Standards and Technology
NSA National Security Agency
OCF OpenCard Framework
Glosario 337
OCSP Online Certificate Status Protocol

OID Object Identifier
P1 Parameter 1
P2 Parameter 2
P3 Parameter 3
PC Personal Computer
PC Policarbonato
PC/SC Personal Computer / Smart Card
PDA Personal Digital Assistant
PET Polyethylene Terephthalate
PGP Pretty Good Privacy
PKCS Public-Key Cryptography Standards
PSEC Provably Secure Elliptic Curve encryption scheme
PVC Polyvinyl Chloride
RAM Random Access Memory
RFC Request for Comments
RFID Radio Frequency Identification
RFU Reserved for Future Use
RMI Remote Method Invocation
RNG Random Number Generator
ROM Read Only Memory
RSA Algoritmo Rivest-Shamir-Adleman
RST Reset
SAT SIM Application Toolkit
SCQL Structured Card Query Language
SECG Standards for Efficient Cryptography Group
SHA Secure Hash Algorithm
SIM Subscriber Identity Module
STK SIM Application Toolkit
338 Glosario
STS Station-To-Station
SW1 Status Word 1
SW2 Status Word 2
TDE Triple Data Encryption
TDES Triple DES
TDEA Triple Data Encryption Algorithm
TLS Transport Layer Security
TLV Tag-Length-Value
TSP Time-Stamp Protocol
UICC Universal Integrated Circuit Card
UMTS Universal Mobile Telecommunication System
USAT USIM Application Toolkit
USB Universal Serial Bus
USIM Universal Subscriber Identity Module
UTF-8 Unicode Transformation Format 8-Bit
WAP Wireless Application Protocol
WIM WAP Identity Module
WSC Windows for Smart Cards
Referencias
[1] 3RD GENERATION PARTNERSHIP PROJECT (3GPP). Specification of

the Subscriber Identity Module - Mobile Equipment (SIM-ME) interface. Ver.
8.14.0 (Release 99). TS 11.11. 2007.
http://www.3gpp.org/ftp/specs/html-info/1111.htm

the SIM Application Toolkit (SAT) for the Subscriber Identity Module - Mobile
Equipment (SIM-ME) interface. Ver. 8.18.0 (Release 99). TS 11.14. 2007.
[3] 3RD GENERATION PARTNERSHIP PROJECT (3GPP). UICC-terminal

interface; physical and logical characteristics. Ver. 6.5.1 (Release 6). TS 31.101.
2006.
[4] 3RD GENERATION PARTNERSHIP PROJECT (3GPP). Characteristics of

the Universal Subscriber Identity Module (USIM) application. Ver. 6.21.0 (Re-
lease 6). TS 31.102. 2008.
[5] 3RD GENERATION PARTNERSHIP PROJECT (3GPP). Universal Subscri-

ber Identity Module (USIM) Application Toolkit (USAT). Ver. 6.13.0 (Release
6). TS 31.111. 2009.

the Subscriber Identity Module - Mobile Equipment (SIM-ME) interface. Ver.
4.15.0 (Release 4). TS 51.011. 2005.

the SIM Application Toolkit (SAT) for the Subscriber Identity Module - Mobile
Equipment (SIM-ME) interface. Ver. 4.15.0 (Release 4). TS 51.014. 2003-2005.
339
340 Referencias
[8] ABDALLA, M.; BELLARE, M. y ROGAWAY, P. DHAES: An encryption

scheme based on the Diffie-Hellman problem. Contribución a IEEE P1363a,
1998.
http://grouper.ieee.org/groups/1363/P1363a/contributions/dhaes.
pdf
[9] ABDALLA, M.; BELLARE, M y ROGAWAY, P. “The oracle Diffie-Hellman

assumptions and an analysis of DHIES”. Lecture Notes in Computer Science.
2001, vol. 2020, pp. 143–158. ISBN 3-540-41898-9.
http://dx.doi.org/10.1007/3-540-45353-9_12
[10] ABDALLA, M.; BELLARE, M. y ROGAWAY, P. DHIES: An encryption sche-

me based on the Diffie-Hellman problem. Inédito, 2001.
http://www.cs.ucdavis.edu/~rogaway/papers/dhies.pdf
[11] ADAMS, C. The CAST-128 encryption algorithm. Request for Comments

(RFC) 2144. Internet Engineering Task Force (IETF), 1997.
http://www.ietf.org/rfc/rfc2144.txt
[12] AENOR. Referencias bibliográficas. Contenido, forma y estructura. UNE 50-

104-94. Enero 1994.
http://www.aenor.es/aenor/normas/normas/fichanorma.asp?tipo=
N&codigo=N0005073&PDF=Si
[13] AMERICAN MATHEMATICAL SOCIETY. MSC 2010 database. Página web.

http://www.ams.org/mathscinet/msc/msc.html
[14] AMERICAN NATIONAL STANDARDS INSTITUTE (ANSI). Triple Data

Encryption: Modes of operation. X9.52. 1998.
[15] AMERICAN NATIONAL STANDARDS INSTITUTE (ANSI). Public key

cryptography for the financial services industry: The Elliptic Curve Digital
Signature Algorithm (ECDSA). X9.62. 2005.
http://webstore.ansi.org/RecordDetail.aspx?sku=ANSI+X9.62%3A2005
[16] AMERICAN NATIONAL STANDARDS INSTITUTE (ANSI). Public key

cryptography for the financial services industry: Key agreement and key trans-
port using Elliptic Curve Cryptography. X9.63. 2001.
http://webstore.ansi.org/RecordDetail.aspx?sku=ANSI+X9.63%3a2001
Referencias 341
[17] AMERICAN NATIONAL STANDARDS INSTITUTE (ANSI). Catalog of fi-

nantial industry american national standards, draft standards for trial use,
technical reports and technical guides. Marzo 2010.
http://www.x9.org/standards/catalog/X9_Standards_Catalog.pdf
[18] AOKI K. et al. “Camellia: A 128-bit block cipher suitable for multiple plat-
forms - Design and analysis”. Lecture Notes in Computer Science, 2001, vol.
2012, pp. 39-56. ISBN 3-540-42069-X.
http://dx.doi.org/10.1007/3-540-44983-3_4
[19] ATENIESE, G. et al. “A practical and provably secure coalition-resistant group

signature scheme ”. Lecture Notes in Computer Science. 2000, vol. 1880, pp.
255–270. ISBN 978-3-540-67907-3.
http://dx.doi.org/10.1007/3-540-44598-6_16
[20] ATENIESE, G. y DE MEDEIROS, B. “Efficient group signatures without

trapdoors”. Lecture Notes in Computer Science. 2003, vol. 2894, pp. 246–268.
ISBN 978-3-540-20592-0.
http://dx.doi.org/10.1007/978-3-540-40061-5_15
[21] APPLE INC. How to identify a micro-SIM. Página web.

http://support.apple.com/kb/HT4192
[22] ATKIN, A. O. L. “The number of points on an elliptic curve modulo a prime”.

Correos enviados al Number Theory Mailing List, 1988-1992.
[23] ATKIN, A. O. L. y MORAIN, F. “Elliptic curves and primality proving”.

Mathematics of Computation. Julio 1993, vol. 61, num. 203, pp. 29–68. ISSN
0025-5718.
http://dx.doi.org/10.1090/S0025-5718-1993-1199989-X
[24] BACH, E. y SHALLIT, J. Algorithmic number theory. Cambridge (Massachu-

setts): MIT Press, 1996. ISBN 0-262-02405-5.
[25] BARRÓN VIDALES, J. “Diseño e implementación de un esquema de cifrado

híbrido basado en DHIES”. Director: Debrup Chakraborty. Centro de Inves-
tigación y de Estudios Avanzados del Instituto Politécnico Nacional, Méjico,
2008.
http://www.cs.cinvestav.mx/Estudiantes/TesisGraduados/2008/
tesisJesusBarron.pdf
[26] BELLARE, M. y ROGAWAY, P. “Minimizing the use of random oracles in

authenticated encryption schemes”. Lecture Notes in Computer Science. 1997,
vol. 1334, pp. 1–16. ISBN 978-3-540-63696-0.
342 Referencias
http://dx.doi.org/10.1007/BFb0028457
[27] BELLARE, M. et al. “Relations among notions of security for public-key en-
cryption schemes”. Lecture Notes in Computer Science. 1998, vol. 1462, pp.
549–570. ISSN 3-540-64892-5.
[28] BERTA, I. Z. y MANN, Z. Á. “Implementing Elliptic Curve Cryptography on

PC and smart card”. Periodica Polytechnica Electrical Enginnering. 2002, vol.
46, num. 1-2, pp. 47–73. ISSN 0324-6000.
http://www.pp.bme.hu/ee/2002_1/pdf/ee2002_1_04.pdf
[29] BLAKE, I.; SEROUSSI, G. y SMART, N. Elliptic curves in cryptography.

Cambridge: Cambridge University Press, 1999. ISBN 0-521-65374-6.
[30] BLAKE, I.; SEROUSSI, G. y SMART, N. Advances in Elliptic Curve Crypto-

graphy. Cambridge: Cambridge University Press, 2005. ISBN 0-521-60415-X.
[31] BONEH, D. “Twenty years of attacks on the RSA cryptosystem”. Notices of the
American Mathematical Society. Febrero 1999, vol. 46, num. 2, pp. 203–213.
ISSN 0002-9920.
http://www.ams.org/notices/199902/boneh.pdf
[32] BOUNCE CASTLE. The legion of the Bouncy Castle. Página web.
http://www.bouncycastle.org
[33] BRAINPOOL. ECC Brainpool. Página web.

http://www.ecc-brainpool.org
[34] BRAINPOOL. ECC Brainpool standard curves and curve generation. Ver. 1.0.
2005.
www.ecc-brainpool.org/download/Domain-parameters.pdf
[35] BRESSOUD, D. M. Factorization and primality testing. Nueva York: Springer-

Verlag, 1989. ISBN 0-387-97040-1.
[36] BUCHMANN, J. A. Introduction to cryptography. 2a ed. Nueva York: Springer,

2004. ISBN 0-387-21156-X.
[37] BUNDESAMT FÜR SICHERHEIT IN DER INFORMATIONSTECHNIK

(BSI). Elliptic Curve Cryptography. Ver. 1.11. TR-03111. 2009.
https://www.bsi.bund.de/cae/servlet/contentblob/471398/
publicationFile/30615/BSI-TR-03111_pdf.pdf
Referencias 343
[38] CARBONELL JIMÉNEZ, C.; DÍAZ MUÑOZ, R. y MEJÍAS OSORIO, P.

Algunas aplicaciones de las curvas elípticas a la criptografía. Director: Eric
Donders Orellana. Facultad de Ciencias Físicas y Matemáticas. Universidad
Central de Chile, 2007.
http://www.criptored.upm.es/descarga/EficienciaCCE_RSA.zip
[39] CARD CONTACT SOFTWARE. Open Smart Card Development Platform

(OpenSCDP). Página web.
http://www.openscdp.org
[40] CENTRO CRIPTOLÓGICO NACIONAL (CCN). Tecnología de identifica-

ción por radiofrecuencia (RFID). CCN-STIC-443. 2009.
https://www.ccn-cert.cni.es/index.php?option=com_wrapper&view=
wrapper&Itemid=188&lang=es
[41] CERTICOM CORP. Method for signature and session key generation. Inven-
tores: S. A. Vanstone, A. J. Menezes, M. Qu. Fecha de solicitud: 1996-04-15.
Patente internacional, WO 96/33565. 1996-10-24.
http://v3.espacenet.com/publicationDetails/originalDocument?CC=
WO&NR=9633565A1&KC=A1&FT=D&date=19961024&DB=EPODOC&locale=es_lp
[42] CERTICOM CORP. Multiple bit multiplier. Inventor: R. C. Mullin. Fecha de

solicitud: 1996-03-29. Estados Unidos, patente de invención, 5.787.028. 1998-
07-28.
http://www.google.com/patents/about?id=wnETAAAAEBAJ&dq=5787028
[43] CERTICOM CORP. Generating unique and unpredictable values. Inventor:

D. B. Johnson. Fecha de solicitud: 1996-10-10. Estados Unidos, patente de
invención, 6.078.667. 2000-06-20.
http://www.google.com/patents/about?id=rUUEAAAAEBAJ&dq=6078667
[44] CERTICOM CORP. Strengthened public key protocol. Inventores: S. A. Vans-

tone, A. J. Menezes, M. Qu. Fecha de solicitud: 1999-04-01. Estados Unidos,
patente de invención, 5.933.504. 2003-05-13.
http://www.google.com/patents/about?id=rNoOAAAAEBAJ&dq=5933504
[45] CERTICOM CORP. Elliptic curve encryption systems. Inventores: S. A. Vans-

tone, R. C. Mullin, G. B. Agnew. Fecha de solicitud: 2000-09-06. Estados
Unidos, patente de invención, 6.618.483 B1. 2003-09-09.
http://www.google.com/patents/about?id=AeEOAAAAEBAJ&dq=6618483
344 Referencias
[46] CERTICOM CORP. Digital signatures on a smartcard. Inventores: S. A. Vans-

tone, A. J. Menezes. Fecha de solicitud: 2001-08-29. Estados Unidos, patente
de invención, 6.704.870 B2. 2004-03-09.
http://www.google.com/patents/about?id=rZ0SAAAAEBAJ&dq=6704870
[47] CERTICOM CORP. Accelerated finite field operations on an elliptic curve. In-
ventores: S. A. Vanstone, R. Mullin, A. Antipa, R. Gallant. Fecha de solicitud:
2000-10-02. Estados Unidos, patente de invención, 6.782.100. 2004-08-24.
http://www.google.com/patents/about?id=XGESAAAAEBAJ&dq=6782100
[48] CHEN, Z. Java Card technology for smart cards: Architecture and program-
mer’s guide. Boston: Addison-Wesley, 2000. ISBN 0-201-70329-7.
[49] COHEN, H. A course in computational algebraic number theory. Berlín:

Springer-Verlag, 1993. ISBN 3-540-55640-0.
[50] COHEN, H. et al. Handbook of elliptic and hyperelliptic curve cryptography.

Florida: Chapman & Hall/CRC, 2006. ISBN 1-58488-518-1.
[51] CONNELL, I. Elliptic Curve Handbook. Inédito, 1999.

http://www.math.mcgill.ca/connell/
[52] CONSEJO SUPERIOR DE INVESTIGACIONES CIENTÍFICAS. Procedi-

miento y dispositivo de encriptación mediante un criptosistema tipo RSA. In-
ventores: L. Hernández, J. Muñoz, A. Queiruga. Fecha de solicitud: 2003-02-14.
España, patente de invención, 2.217.959. 2006-02-01.
http://dx.doi.org/10261/4968
[53] COPPERSMITH, D. et al. “Low-exponent RSA with related messages”. Lec-

ture Notes in Computer Science. 1996, vol. 1070, pp. 1–9. ISBN 978-3-540-
61186-8.
http://dx.doi.org/10.1007/3-540-68339-9_1
[54] CORON, J. S. y MAY, A. “Deterministic polynomial-time equivalence of com-

puting the RSA secret key and factoring”. Journal of Cryptology. Enero 2007,
vol. 20, num. 1, pp. 39–50. ISSN 0933-2790.
http://dx.doi.org/10.1007/s00145-006-0433-6
[55] CRAMER, R. y SHOUP, V. “Design and analysis of practical public-key en-

cryption schemes secure against adaptive chosen ciphertext attack”. SIAM
Journal on Computing. Diciembre 2003, vol. 33, num. 1, pp. 167–226. ISSN
0097-5397.
http://dx.doi.org/10.1137/S0097539702403773
Referencias 345
[56] CRYPTIX. The Cryptix project. Página web.

http://www.cryptix.org
[57] DEITEL, P. y DEITEL, H. M. Java: How to program. 8a ed. Upper Saddle

River (Nueva Jersey): Pearson Prentice Hall, 2009. ISBN 0-13605-306-8.
[58] DENT, A. W. ACE-KEM and the general KEM-DEM structure. NES/DO-

C/RHU/WP5/023/3. NESSIE Project, 2002.
https://www.cosic.esat.kuleuven.be/nessie/reports/phase2/
Evaluation.zip
[59] DETHLOFF, J. y GRÖTRUPP, H. Identification switch. Inventores: J. Deth-

loff, H. Grötrupp. Fecha de solicitud: 1969-09-15. Estados Unidos, patente de
invención, 3.678.250. 1972-07-18.
http://www.google.com/patents/about?id=zjUvAAAAEBAJ&dq=3678250
[60] DETHLOFF, J. y GRÖTRUPP, H. Identification system. Inventores: J. Deth-

loff, H. Grötrupp. Fecha de solicitud: 1970-08-17. Estados Unidos, patente de
invención, 3.641.316. 1972-02-08.
http://www.google.com/patents/about?id=fFY6AAAAEBAJ&dq=3641316
[61] DIFFIE, W. y HELLMAN, M. E. “New directions in cryptography”. IEEE

Transactions on Information Theory. Noviembre 1976, vol. 22, num. 6, pp.
644–654. ISSN 0018-9448.
http://dx.doi.org/10.1109/TIT.1976.1055638
[62] DINERS CLUB. Company history of Diners Club. Página web.

https://www.dinersclubus.com/dce_content/aboutdinersclub/
companyhistory
[63] DOBBERTIN, H.; BOSSELAERS, A. y PRENEEL, B. “RIPEMD-160: A

strengthed version of RIPEMD”. Lecture Notes in Computer Science. 1996,
vol. 1039, pp. 71–82. ISBN 3-540-60865-6.
http://dx.doi.org/10.1007/3-540-60865-6_44
[64] DOLEV, D.; DWORK, C. y NAOR, M. “Non-malleable cryptograpy”. En: Pro-

ceedings of the 23rd Annual Symposium on the Theory of Computing. Nueva
Orleans, 1991. pp 542–552. ISBN 0-89791-397-3.
http://dx.doi.org/10.1145/103418.103474
[65] DREIFUS, H. y MONK, J. T. Smart cards: A guide to building and managing

smart card applications. Nueva York: Wiley, 1998. ISBN 0-471-15748-1.
346 Referencias
[66] DURÁN DÍAZ, R.; HERNÁNDEZ ENCINAS, L. y MUÑOZ MASQUÉ, J. El

criptosistema RSA. Madrid: RA-MA, 2005. ISBN 84-7897-651-5.
[67] DWORK, C. y NAOR, M. Non-malleability: Introduction and survey of recent

develpments. Inédito, 2003.
http://www.wisdom.weizmann.ac.il/~naor/PAPERS/ref_nmc.pdf
[68] EASTLAKE, D. E. Additional XML Security Uniform Resource Identifiers

(URIs). Request for Comments (RFC) 4051. Internet Engineering Task Force
(IETF), 2005.
[69] ELGAMAL, T. “A public key cryptosystem and a signature scheme based on

discrete logarithms”. IEEE Transactions on Information Theory. Julio 1985,
vol. 31, num. 4, pp. 469–472. ISSN 0018-9448.
[70] ELKIES, N. “Elliptic and modular curves over finite fields and related compu-
tational issues”. En: Proceedings of Computational Perspectives on Number
Theory. Chicago, 1998. pp 21–76. ISBN 0-8218-0880-X.
http://www.ams.org/mathscinet-getitem?mr=1486831
[71] ELO, T. Lessons learned on implementing ECDSA on a Java smart card.

Inédito, 2000.
http://www.tml.hut.fi/Research/TeSSA/Papers/Elo/Elo_Nordsec2000.
pdf
[72] ENGE, A. Elliptic curves and their applications to cryptography: An introduc-

tion. Boston: Kluwer Academic Publishers, 1999. ISBN 0-7923-8589-6.
[73] ERICKSON, M. y VAZZANA, A. Introduction to number theory. Boca Ratón

(Florida): Chapman & Hall/CRC, 2008. ISBN 1-58488-937-3.
[74] EUROPEAN COMMITTEE FOR BANKING STANDARDS. Overview of

electronic purse products. Ver. 4.0. Informe técnico TR102. European Com-
mittee for Banking Standards, 2003.
http://www.ecbs.org
[75] EUROPEAN TELECOMMUNICATION STANDARDS INSTITUTE (ET-

SI). Smart cards - UICC-terminal interface - Physical and logical characte-
ristics . Ver. 8.2.0 (Release 8). TS 102 221. 2009.
http://www.etsi.eu/deliver/etsi_ts/102200_102299/102221/08.02.
00_60/ts_102221v080200p.pdf
Referencias 347
[76] FREY, G. y RUCK, H. “A remark concerning 𝑚-divisibility and the discrete

logarithm in the divisor class group of curves”. Mathematics of Computation.
Abril 1994, vol. 62, num. 206, pp. 865–874. ISSN 0025-5718.
http://dx.doi.org/10.1090/S0025-5718-1994-1218343-6
[77] FREY, G. “Applications of arithmetical geometry to cryptographic construc-

tions”. En: Proceedings of the Fifth International Conference on Finite Fields
and Applications, pp 128–161. Augsburg (Alemania), 2001. ISBN 3-540-41109-
7.
http://www.iem.uni-due.de/zahlentheorie/preprints/nna1.ps
[78] FÚSTER SABATER, A.; et al. Técnicas criptográficas de protección de datos.

3a ed. Madrid: RA-MA, 2004. ISBN 84-7897-594-2.
[79] GALINDO, D.; MARTÍN, S. y VILLAR, J. L. “The security of PSEC-KEM

versus ECIES-KEM”. En: Proceedings of the 26th Symposium on Information
Theory in the BeNeLux, pp 17–27. Bruselas, 2005. ISBN 90-71048-21-7.
http://www.dgalindo.es/kemsFullBenelux.pdf
[80] GATTIKER, U. E. The information security dictionary: Defining the terms

that define security for E-business, Internet, information, and wireless tech-
nology. Boston: Kluwer Academic Publishers, 2004. ISBN 1-4020-7889-7.
[81] GAYOSO MARTÍNEZ, V. et al. “Elliptic Curve Criptography: Java imple-

mentation issues”. En: Proceedings of the 39th IEEE International Carnahan
Conference on Security Technology (ICCST 2005), pp 238–241. Las Palmas
de Gran Canaria, 2005. ISBN 0-7803-9245-0.
http://dx.doi.org/10.1109/CCST.2005.1594866
[82] GAYOSO MARTÍNEZ, V. et al. “Estado del arte de las implementaciones

Java de criptografía de curva elíptica”. En: Actas del I Simposio sobre Segu-
ridad Informática, I Congreso Español de Informática (CEDI), pp. 127–134.
Granada, 2005. ISBN: 84-9732-447-1.
[83] GAYOSO MARTÍNEZ, V.; HERNÁNDEZ ENCINAS, L. y SÁNCHEZ ÁVI-

LA, C. “Elliptic Curve Cryptography. Java platform implementations”. En:
Proceedigs of the 23rd International Conference on Information Technologies
(InfoTech-2009), pp. 20–27. Varna (Bulgaria), 2009. ISBN: 978-954-438-771-6.

LA, C. “Elliptic Curve Cryptography. Java platform implementations”. Inter-
national Journal on Information Techonologies & Security. Diciembre 2009,
num. 4, pp. 65–72. ISSN: 1313-8251.
348 Referencias

LA, C. “A Java implementation of the Elliptic Curve Integrated Encryption
Scheme”. En: Proceedings of the 2010 International Conference on Security
& Management - SAM’10, vol.n II, pp. 495–501. Las Vegas, 2010. ISBN: 1-
60132-162-7.

LA, C. “A comparison of the standardized versions of ECIES”. En: Proceedings
of the 6th International Conference on Information Assurance and Security
(IAS 2010)m pp. 1–4. Atlanta, 2010. ISBN: 978-1-4244-7408-0.
http://dx.doi.org/10.1109/ISIAS.2010.5604194

LA, C. “Security and practical considerations when implementing the Elliptic
Curve Integrated Encryption Scheme”. Enviado a: Journal of Systems and
Software. 2010. ISSN 0164-1212.

LA, C. “Performance evaluation of the Elliptic Curve Integrated Encryption
Scheme implemented in PC and Java Card”. Enviado a: Computers & Mathe-
matics with Applications. 2010. ISSN 0898-1221.

LA, C. “Java Card implementation of the Elliptic Curve Integrated Encryption
Scheme using prime and binary finite fields”. Enviado a: International Journal
of Information Security. 2010. ISSN 1615-5262.

LA, C. “A survey of the elliptic curve integrated encryption scheme”. Journal
of Computer Science and Engineering. Agosto 2010, vol. 2, num. 2, pp. 7–13.
ISSN 2043-9091.
http://sites.google.com/site/jcseuk/volumes/V2-I2-P7-13.pdf
[91] GAUDRY, P.; HESS, F. y SMART, N. “Constructive and destructive facets

of Weil descent on elliptic curves”. Journal of Cryptology. Marzo 2002, vol. 15,
num. 1, pp. 19–46. ISSN 0933-2790.
http://dx.doi.org/10.1007/s00145-001-0011-x
[92] GEISELMANN, W. y STEINWANDT, R. “Power attacks on a side-channel

resistant elliptic curve implementation”. Information Processing Letters. Julio
2004, vol. 91, num. 1, pp. 29–32. ISSN 0020-0190.
http://dx.doi.org/10.1016/j.ipl.2003.12.009
Referencias 349
[93] GOLDWASSER, S. y MICALI, S. “Probabilistic encryption & how to play

mental poker keeping secret all partial information”. En: Proceedings of the
ACM symposium on theory of computing - STOC 82, pp. 365–377. San Fran-
cisco, 1982. ISBN 0-89791-070-2.
http://dx.doi.org/10.1145/800070.802212
[94] GOLDWASSER, S. y MICALI, S. “Probabilistic encryption”. Journal of Com-

puter and System Sciences. Abril 1984, vol. 28, num. 2, pp. 270–299. ISSN
0022-0000.
http://dx.doi.org/10.1016/0022-0000(84)90070-9
[95] GOLDWASSER, S. y KILIAN, J. “Almost all primes can be quickly certified”.

En: Proceedings of the 18th Annual ACM Symposium on Theory of Computing,
pp. 316–329. Berkeley (California), 1986. ISBN 0-89791-193-8.
http://dx.doi.org/10.1145/12130.12162
[96] GRIFFITHS, P. A. Introduction to algebraic curves. Providence (Rhode Is-

land): American Mathematical Society, 1989. ISBN 0-8218-4530-6.
[97] GUTHERY, S. B. y JURGENSEN, T. M. Smart card: Developer’s kit. India-

nápolis (Indiana): Macmillan Technical Publishing, 1998. ISBN 1-57870-027-2.
[98] HANN, J. et al. “Implementation of ECC/ECDSA Cryptography Algorithms

Based on Java Card”. En: Proceedings of the 22nd International Conference
on Distributed Computing Systems - ICDCSW’02, pp. 272–278. Viena, 2002.
ISBN 0-7695-1588-6.
http://dx.doi.org/10.1109/ICDCSW.2002.1030781
[99] HANKERSON, D.; MENEZES, A. y VANSTONE, S. Guide to Elliptic Curve

Cryptography. Nueva York: Springer-Verlag, 2004. ISBN 0-387-95273-X.
[100] HANSMANN, U.; et al. Smart card application development using Java. Ber-
lín: Springer, 2000. ISBN 3-540-65829-7.
[101] HASTAD, J. “Solving simultaneous modular equations of low degree”. SIAM

Journal of Computing. Abril 1988, vol. 17, num. 2, pp. 336–341. ISSN 0097-
5397.
http://dx.doi.org/10.1137/0217019
[102] HERNÁNDEZ ENCINAS, L. et al. “Sobre la clasificación de curvas hiperelíp-

ticas de género 2 definidas en cuerpos finitos”. En: Actas del I Simposio sobre
Seguridad Informática, I Congreso Español de Informática (CEDI), pp. 31–36.
Granada, 2005. ISBN 84-9732-447-1.
350 Referencias
[103] HESS, E. et al. “Information leakage attacks against smart card implemen-
tations of cryptographic algorithms and countermeasures - A survey”. En:
Proceedings of the EUROSMART Security Conference, pp. 55–64. Marsella,
2000.
http://www.torsten-schuetze.de/reports/leakage.pdf
[104] HEWLETT-PACKARD COMPANY. Compression and decompression of

elliptic curve data points. Inventor: G. Seroussi. Fecha de solicitud: 1998-08-04.
Estados Unidos, patente de invención, 6.252.960. 2001-06-26.
http://www.google.com/patents/about?id=mcIIAAAAEBAJ&dq=6252960
[105] HID GLOBAL. HID Products OMNIKEY 5321 CL USB Reader. Página web.
http://www.hidglobal.com/prod_detail.php?prod_id=331
[106] HOOK, D. Beginning cryptography with Java. Indianapolis: Wiley Publishing,

2005. ISBN 0-7645-9633-0.
[107] HORTON, I. Beginning Java 2. Birmingham (Reino Unido): Wrox Press, 1999.
ISBN 1-86100-223-8.
[108] INSTITUTE OF ELECTRICAL AND ELECTRONICS ENGINEERS

(IEEE). Standard specifications for public key cryptography. IEEE Std 1363.
2000.
http://grouper.ieee.org/groups/1363/P1363/index.html
[109] INSTITUTE OF ELECTRICAL AND ELECTRONICS ENGINEERS

(IEEE). Standard specifications for public key cryptography - Amendment 1:
Additional techniques. IEEE Std 1363a. 2004.
http://grouper.ieee.org/groups/1363/P1363a/index.html
[110] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION (ISO).

Documentation – Bibliographic references – Content, form and structure. 2a
ed. ISO 690. 1987.
http://www.iso.org/iso/iso_catalogue/catalogue_ics/catalogue_
detail_ics.htm?csnumber=4888

Information and documentation – Bibliographic references – Part 2: Electronic
documents or parts thereof. ISO 690-2. 1997.
Referencias 351

Information and documentation – Guidelines for bibliographic references and
citations to information resources. 3a ed. ISO 690. 2010.
http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_
detail.htm?csnumber=43320

Identification cards – Integrated circuit(s) cards with contacts – Part 1: Phy-
sical characteristics. ISO/IEC 7816-1. 1998.
http://www.iso.org/iso/catalogue_detail?csnumber=29257

Identification cards – Integrated circuit cards – Part 2: Cards with contacts
– Dimensions and location of the contacts. 2a ed. ISO/IEC 7816-2. 2007.
http://www.iso.org/iso/catalogue_detail.htm?csnumber=45989

Information technology – Identification cards – Integrated circuit(s) cards
with contacts – Part 3: Electronic signals and transmission protocols. 3a ed.
ISO/IEC 7816-3. 2006.

Information technology – Identification cards – Integrated circuit(s) cards with
contacts – Part 4: Interindustry commands for interchange. 2a ed. ISO/IEC
7816-4. 2005.

Identification cards – Integrated circuit cards – Part 5: Registration of ap-
plication providers. 2a ed. ISO/IEC 7816-5. 2004.

Identification cards – Integrated circuit cards – Part 6: Interindustry data ele-
ments for interchange. 2a ed. ISO/IEC 7816-6. 2004.

Identification cards – Integrated circuit(s) cards with contacts – Part 7: Inte-
rindustry commands for Structured Card Query Language (SCQL). ISO/IEC
7816-7. 1999.
352 Referencias

Identification cards – Integrated circuit cards – Part 8: Commands for security
operations. 2a ed. ISO/IEC 7816-8. 2004.

Identification cards – Integrated circuit cards – Part 9: Commands for card
management. 2a ed. ISO/IEC 7816-9. 2004.

Identification cards – Integrated circuit(s) cards with contacts – Part 10: Elec-
tronic signals and answer to reset for synchronous cards. ISO/IEC 7816-10.
1999.

Identification cards – Integrated circuit cards – Part 11: Personal verification
through biometric methods. ISO/IEC 7816-11. 2004.

Identification cards - Integrated circuit cards – Part 12: Cards with contacts –
USB electrical interface and operating procedures. ISO/IEC 7816-12. 2005.

Identification cards – Integrated circuit cards – Part 13: Commands for ap-
plication management in a multi-application environment. ISO/IEC 7816-13.
2007.

Identification cards – Integrated circuit cards – Part 15: Cryptographic in-
formation application. ISO/IEC 7816-15. 2004.

Information technology – ASN.1 encoding rules: Specification of Basic En-
coding Rules (BER), Canonical Encoding Rules (CER) and Distinguished En-
coding Rules (DER). ISO/IEC 8825-1. 2008.
Referencias 353

Information technology – Security techniques – Message authentication codes
– Part 1: Mechanisms using a block cipher. ISO/IEC 9797-1. 1999.

Information technology – Security techniques – Message authentication co-
des (MACs) – Part 2: Mechanisms using a dedicated hash-function. ISO/IEC
9797-2. 2002.

Information technology – Security techniques – Hash-functions – Part 2: Hash-
functions using an n-bit block cipher. 3a ed. ISO/IEC 10118-2. 2010.

Information technology – Security techniques – Hash-functions – Part 3: De-
dicated hash-functions. ISO/IEC 10118-3. 2004.

Identification cards – Contactless integrated circuit(s) cards – Proximity cards
– Part 1: Physical characteristics. 2a ed. ISO/IEC 14443-1. 2008.

Identification cards – Contactless integrated circuit cards – Proximity cards
– Part 2: Radio frequency power and signal interface. 2a ed. ISO/IEC 14443-
2. 2010.

– Part 3: Initialization and anticollision. ISO/IEC 14443-3. 2001.
354 Referencias

– Part 4: Initialization and anticollision. 2a ed. ISO/IEC 14443-4. 2008.

Information technology – Security techniques – Encryption algorithms – Part
2: Asymmetric ciphers. ISO/IEC 18033-2. 2006.

Information technology – Security techniques – Encryption algorithms – Part
3: Block ciphers. ISO/IEC 18033-3. 2005.

Information technology – Biometric Exchange Formats Framework – Part 1:
Data element specification. ISO/IEC 19785-1. 2006.

Joint Technical Comittee (JTC) 1/Sub-comittee (SC) 17. Página web.
http://www.iso.org/iso/standards_development/technical_
committees/list_of_iso_technical_committees/iso_technical_
committee.htm?commid=45144
[140] IVORRA CASTILLO, C. Curvas elípticas. Inédito, 2010.

www.uv.es/ivorra/Libros/Elipticas.pdf
[141] JACOBSON, M.; MENEZES, A. y STEIN, A. “Solving Elliptic Curve Discrete

Logarithm Problems using Weil descent”. Journal of the Ramanujan Mathe-
matical Society. 2000, vol. 16, pp. 231–260.
http://eprint.iacr.org/2001/041.pdf
[142] JOYE, M. “Smart-card implementation of elliptic curve cryptography and

DPA-type attacks”. En: Proceedings of the 6th International Conference on
Smart Card Research and Advanced Applications (CARDIS), pp. 115–125.
Toulouse, 2004. ISBN 1-4020-8146-4.
http://joye.site88.net/papers/Joy04cardis.pdf
Referencias 355
[143] KATZ, N. M. y MAZUR, B. Arithmetic moduli of elliptic curves. Princeton

(Nueva Jersey): Princeton University Press, 1985. ISBN 0-691-08352-5.
[144] KATZ, J. y LINDELL, Y. Introduction to modern cryptography. Boca Ratón

[145] KAYA KOÇ, Ç. (editor). Cryptographic engineering. Nueva York: Springer,

2009. ISBN 978-0-387-71816-3.
[146] KIEFER, K. “A weakness of the Menezes-Vanstone cryptosystem”. Lecture

Notes in Computer Science. 1998, vol. 1361, pp. 201–206. ISBN 978-3-540-
64040-0.
[147] KOBLITZ, N. “Elliptic curve cryptosystems”. Mathematics of Computation.

Enero 1987, vol. 48, num. 177, pp. 203–209. ISSN 0025-5718.
http://dx.doi.org/10.1090/S0025-5718-1987-0866109-5
[148] KOBLITZ, N. A course in number theory and cryptography. 2a ed. Berlín:

[149] KOBLITZ, N. Algebraic aspects of cryptography. Berlín: Springer-Verlag, 1998.

ISBN 3-540-63446-0.
[150] KOCHER, P. “Timing attacks on implementations of Diffie-Hellman, RSA,

DSS, and other systems”. Lecture Notes in Computer Science. 1996, vol. 1109,
pp. 104–113. ISBN 978-3-540-61512-5.
http://dx.doi.org/10.1007/3-540-68697-5_9
[151] KOCHER, P.; JAFFE, J. y JUN, B. Introduction to Differential Power Analy-

sis and related attacks. Informe técnico. Cryptographic Research, 1998.
http://www.cryptography.com/public/pdf/DPATechInfo.pdf
[152] KOCHER, P.; JAFFE, J. y JUN, B. “Differential Power Analysis”. Lecture

Notes in Computer Science. 1999, vol. 1666, pp. 388–397. ISBN 978-3-540-
66347-8.
http://dx.doi.org/10.1007/3-540-48405-1_25
[153] KRANTZ, S. G. Handbook of typography for the mathematical sciences. Boca

Ratón (Florida): Chapman & Hall/CRC, 2001. ISBN 1-58488-149-6.
[154] KRAWCZYK, H.; BELLARE, M. y CANETTI, R. HMAC: Keyed hashing for

message authentication. Request for Comments (RFC) 2104. Internet Engi-
neering Task Force (IETF), 1997.
356 Referencias
[155] KUROSAWA, K. y DESMEDT, Y. “A new paradigm of hybrid encryption

scheme”. Lecture Notes in Computer Science. 2004, vol. 3152, pp. 426–442.
ISBN 3-540-22668-0.
http://dx.doi.org/10.1007/978-3-540-28628-8_26
[156] KUROSAWA, K.; ITO, T. y TAKEUCHI, M. “Public key cryptosystem using
a reciprocal number with the same intractability as factoring a large number”.
Cryptologia. Octubre 1983, vol. 7, num. 4, pp. 225–233. ISSN 0161-1194.
http://dx.doi.org/10.1080/0161-118891862972
[157] LEE, H.J. et al. The SEED encryption algorithm. Request for Comments
(RFC) 4269. Internet Engineering Task Force (IETF), 2005.
[158] LEHMAN, S. “Factoring large integers”. Mathematics of Computation. Abril
1974, vol. 28, num. 126, pp. 637–646. ISSN 0025-5718.
http://dx.doi.org/10.1090/S0025-5718-1974-0340163-2
[159] LENSTRA, H. W. “Factoring integers with elliptic curves”. Annals of Mathe-
matics. Noviembre 1987, vol. 126, num. 3, pp. 649–673. ISSN 0003-486X.
http://www.jstor.org/stable/1971363
[160] LEUNG, K. y HUI, L. “Multiple signature handling in workflow systems”.
En: Proceedings of the 33rd International Conference on System Sciences, pp.
6033. Hawaii, 2000. ISBN 0-7695-0493-0.
http://dx.doi.org/10.1109/HICSS.2000.926854
[161] MALL, D. y ZHONG, Q. Open source is not enough. Attacking the EC-package
of Bouncycastle version 1.x_132. Inédito, 2008.
http://eprint.iacr.org/2008/113
[162] MAMBO, M.; USUDA, K. y OKAMOTO, E. “Proxy signatures for delegating
signing operation”. En: Proceedings of the 3rd ACM Conference on Computer
and Communications Security - CCS’96, pp. 48–57. Nueva Delhi (India), 1996.
http://dx.doi.org/10.1145/238168.238185
[163] MAOSCO LTD. MULTOS smart card technology. Página web.
http://www.multos.com
[164] MASSACHUSETTS INSTITUTE OF TECHNOLOGY. Cryptographic com-
munications system and method. Inventores: R. L. Rivest, A. Shamir y L. Ad-
leman. Fecha de solicitud: 1977-12-14. Estados Unidos, patente de invención,
4.405.829. 1983-09-20.
http://www.google.com/patents?vid=4405829
Referencias 357
[165] MATSUI, M. Specification of MISTY1 - A 64-bit block cipher. Inédito, 2000.

https://www.cosic.esat.kuleuven.be/nessie/workshop/submissions/
misty1.zip
[166] MATSUSHITA ELECTRIC INDUSTRIAL CO., LTD. Public key cryptosys-

tem with an elliptic curve. Inventores: A. Miyaji, M. Tatebayashi. Fecha de
solicitud: 1992-05-26. Estados Unidos, patente de invención, 5.272.755. 1993-
12-21.
http://www.google.com/patents/about?id=nB4bAAAAEBAJ&dq=5272755
[167] MAURER, M.; MENZES, A. y TESKE, E. “Analysis of the GHS Weil descent
attack on the ECDLP over characteristic two finite fields of composite degree
(extended abstract)”. Lecture Notes in Computer Science. 2001, vol. 2247, pp.
195–213. ISBN 978-3-540-43010-0.
http://dx.doi.org/10.1007/3-540-45311-3_19
[168] MENEZES, A. J. Elliptic curve public key cryptosystems. Boston: Kluwer Aca-
demic Publishers, 1993. ISBN 0-79239-368-6.
[169] MENEZES, A. J. y VANSTONE, S. A. Vanstone. “Elliptic curve cryptosys-

tems and their implementation”. Journal of Cryptology. Septiembre 1993, vol.
6, num. 4, pp. 209–224. ISSN 0933-2790.
http://dx.doi.org/10.1007/BF00203817
[170] MENEZES, A. J.; OKAMOTO, T. y VANSTONE, S. A. Vanstone. “Reducing

elliptic curve logarithms to logarithms in a finite field”. IEEE Transactions on
Information Theory. Septiembre 1993, vol. 39, num. 5, pp. 1639–1646. ISSN
0018-9448.
http://dx.doi.org/10.1109/18.259647
[171] MENEZES, A.; QU, M. y VANSTONE, S. “Some new key agreement proto-
cols providing implicit authentication”. En: Proceedings of the Workshop on
Selected Areas in Cryptography - SAC ’95, pp. 22–32. Ottawa (Canadá), 1995.
http://leonardo.ee.queensu.ca/sac/sac95/papers/SAC_95_003.pdf
[172] MENEZES, A.; VAN OORSCHOT, P. y VANSTONE, S. Handbook of applied

cryptography. Florida: CRC Press, 1996. ISBN: 0-8493-8523-7.
http://www.cacr.math.uwaterloo.ca/hac/
[173] MENEZES, A. y QU, M. “Analysis of the Weil descent attack of Gaudry, Hess
and Smart”. Lecture Notes in Computer Science. 2001, vol. 2020, pp. 308–318.
ISBN 978-3-540-41898-6.
http://dx.doi.org/10.1007/3-540-45353-9_23
358 Referencias
[174] MILLER, V. S. “Use of elliptic curves in cryptography”. Lecture Notes in Com-

puter Science. 1986, vol. 218, pp. 417–426. ISBN 3-540-16463-4.
http://dx.doi.org/10.1007/3-540-39799-X_31
[175] MILNE, J. S. Elliptic curves. Charleston (Carolina del Sur): BookSurge, 2006.
ISBN 1-4196-5257-5.
[176] MINISTERIO DEL INTERIOR. DNI electrónico. Página web.

http://www.dnielectronico.es/oficina_prensa/noticias/noticia12.
html
[177] MINISTERIO DEL INTERIOR. Pasaporte electrónico (pasaporte-e). Página

web.
http://www.mir.es/SGACAVT/pasaport/concepto.html
[178] MOHAMMED, E.; EMARAH, A. E. y EL-SHENNAWY, K. “Elliptic curve

cryptosystems on smart cards”. En: Proceedings of the 35th IEEE Internatio-
nal Carnahan Conference on Security Technology (ICCST 2001), pp 213–222.
Londres, 2001. ISBN 0-7803-6636-0 .
http://dx.doi.org/10.1109/.2001.962835
[179] MOLLIN, R. A. An introduction to cryptography. 2a ed. Boca Ratón (Florida):

Chapman & Hall/CRC, 2007. ISBN 1-58488-618-8.
[180] Mordell, L. J. “On the rational solutions of the indeterminate equations of the
third and fourth degrees”. Proceedings of the Cambridge Philosophical Society.
1922, vol. 21, pp. 179–192. ISSN 0305-0041.
[181] MULDER, E. et al. “Differential power and electromagnetic attacks on a FP-

GA implementation of elliptic curve cryptosystems”. Computers and Electrical
Engineering. Septiembre 2007, vol. 33, num. 5–6, pp. 367–382. ISSN 0045-7906.
http://dx.doi.org/10.1016/j.compeleceng.2007.05.009
[182] NAGELL, T. “Sur les propriétés arithmétiques des cubiques planes du premier
genre”. Acta Mathematica. 1929, vol. 52, pp. 93–126. ISSN 0001-5962.
http://dx.doi.org/10.1007/BF02592681
[183] NATIONAL INSTITUTE OF STANDARDS AND TECHNOLOGY (NIST).

Secure hash standard. FIPS 180-3. 2008.
http://csrc.nist.gov/publications/fips/fips180-3/fips180-3_
final.pdf
Referencias 359

Digital Signature Standard (DSS). FIPS 186-3. 2009.
http://csrc.nist.gov/publications/fips/fips186-3/fips_186-3.pdf
Advanced Encryption Standard. FIPS 197. 2001.
http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf
The Keyed-Hash Message Authentication Code (HMAC). FIPS 198-1. 2008.
http://csrc.nist.gov/publications/fips/fips198-1/FIPS-198-1_
final.pdf
Recommendation for block cipher modes of operation. Methods and techniques.
SP 800-38A. 2001.
http://csrc.nist.gov/publications/nistpubs/800-38a/sp800-38a.pdf
Recommendation for block cipher modes of operation: The CMAC mode for
authentication. SP 800-38B. 2005.
http://csrc.nist.gov/publications/nistpubs/800-38B/SP_800-38B.
pdf
Recommendation for pair-wise key establishment schemes using discrete loga-
rithm cryptography. SP 800-56A. 2007.
http://csrc.nist.gov/publications/nistpubs/800-56A/SP800-56A_
Revision1_Mar08-2007.pdf
Recommendation for the Triple Data Encryption Algorithm (TDEA) block cip-
her. Ver. 1.1. SP 800-67. 2008.
http://csrc.nist.gov/publications/nistpubs/800-67/SP800-67.pdf
Secure hashing - Approved algorithms. Página web.
http://csrc.nist.gov/groups/ST/toolkit/secure_hashing.html
[192] NATIONAL SECURITY AGENCY. Method of elliptic curve cryptographic key
exchange using reduced base tau expansion in non-adjacent form. Inventores:
R. W. Reiter, J. A. Solinas. Fecha de solicitud: 1998-07-23. Estados Unidos,
http://www.google.com/patents/about?id=4pgGAAAAEBAJ&dq=6212279
360 Referencias
[193] NATIONAL SECURITY AGENCY. Method of elliptic curve digital signature

generation and verification using reduced base tau expansion in non-adjacent
form. Inventores: R. W. Reiter, J. A. Solinas. Fecha de solicitud: 1998-07-23.
http://www.google.com/patents/about?id=fcsIAAAAEBAJ&dq=6243467
[194] NATIONAL SECURITY AGENCY (NSA). Suite B cryptography. Página web.

http://www.nsa.gov/ia/programs/suiteb_cryptography/index.shtml
[195] NESSIE CONSORTIUM. Portfolio of recommended cryptographic primitives.

Ver. 1.0. 2003.
https://www.cosic.esat.kuleuven.be/nessie/deliverables/
decision-final.pdf
[196] NESSIE CONSORTIUM. Final report of European project number IST-1999-

12324 named New European Schemes for Signatures, Integrity, and Encry-
ption. Ver. 0.15. 2004.
https://www.cosic.esat.kuleuven.be/nessie/Bookv015.pdf
[197] NEXT COMPUTER, INC. Method and apparatus for public key exchange in a
cryptographic system. Inventor: R. E. Crandall. Fecha de solicitud: 1993-12-14.
http://www.google.com/patents/about?id=9TYTAAAAEBAJ&dq=5463690
[198] NEXT COMPUTER, INC. Method and apparatus for digital signature aut-
hentication. Inventor: R. E. Crandall. Fecha de solicitud: 2000-04-06. Estados
Unidos, patente de invención, 5.581.616. 2001-09-04.
http://www.google.com/patents/about?id=92kIAAAAEBAJ&dq=5581616
[199] NTT CORPORATION. PSEC-KEM specification. Ver. 2.2. 2008.

http://www.cryptrec.go.jp/cryptrec_03_spec_cypherlist_files/PDF/
02_03e_jspec.pdf
[200] NXP SEMICONDUCTORS. P5CT072 - Secure dual interface PKI smart card
controller. Ver. 1.3. 2004.
http://www.nxp.com/acrobat_download2/other/identification/
sfs085513.pdf
[201] NXP SEMICONDUCTORS. P5Cx012/02x/40/73/80/144 family - Secure

dual interface PKI smart card controller. Ver. 1.03. 2008.
http://www.nxp.com/documents/data_sheet/P5CX012_02X_40_73_80_
144_FAM_SDS.pdf
Referencias 361
[202] NXP SEMICONDUCTORS. Smart solutions for smart services. Ver. 1.0.
2009.
http://www.nxp.com/acrobat_download2/literature/9397/75016728.
pdf
[203] OETIKER, T. et al. The not so short introduction to LATEX 2𝜀 . Ver. 4.31. 2010.
http://ftp.udc.es/CTAN/info/lshort/english/lshort.pdf
[204] OHTA, H. y MATSUI, M. A description of the MISTY1 encryption algorithm.

Request for Comments (RFC) 2994. Internet Engineering Task Force (IETF),
2000.
[205] OMNET ASSOCIATES. Method and apparatus for maintaining the privacy
of digital messages conveyed by public transmission. Inventores: J. L. Mas-
sey, J. K. Omura. Fecha de solicitud: 1982-09-14. Estados Unidos, patente de
invención, 4.567.600. 1986-01-28.
http://www.google.com/patents/about?id=i-M5AAAAEBAJ&dq=4567600
[206] OMNET ASSOCIATES. Computational method and apparatus for finite field
arithmetic. Inventores: J. K. Omura, J. L. Massey. Fecha de solicitud: 1982-
09-14. Estados Unidos, patente de invención, 4.587.627. 1986-05-06.
http://www.google.com/patents/about?id=lNsyAAAAEBAJ&dq=4587627
[207] OMNISEC A.G. Public key cryptographic system using elliptic curves over
rings. Inventor: U. Maurer. Fecha de solicitud: 1991-03-22. Estados Unidos,
http://www.google.com/patents/about?id=iuMbAAAAEBAJ&dq=5146500
[208] ONYSZCHUK, I. M.; MULLIN, R. C. y VANSTONE, S. A. Computational

method and apparatus for finite field multiplication. Inventores: I. M. Onysz-
chuk, R. C. Mullin, S. A. Vanstone. Fecha de solicitud: 1985-05-30. Estados
Unidos, patente de invención, 4.745.568. 1988-05-17.
http://www.google.com/patents/about?id=OJc2AAAAEBAJ&dq=4745568
[209] ORACLE CORP. BigInteger (Java Platform SE 6). Página web.

http://download.oracle.com/javase/6/docs/api/java/math/
BigInteger.html
[210] ORACLE CORP. Java Card Technology. Página web.

http://www.oracle.com/technetwork/java/javacard/overview/index.
html
362 Referencias
[211] ORACLE CORP. Java smart card I/O API. Página web.
http://jcp.org/en/jsr/detail?id=268
[212] ORACLE CORP. Java technology. Página web.

http://java.com/en/about
[213] ORACLE CORP. OpenJDK. Página web.

http://openjdk.java.net
[214] ORACLE CORP. Oracle completes acquisition of Sun. Página web.

http://www.oracle.com/us/corporate/press/044428
[215] ORTEGA JUANCAS, S. Algunas aplicaciones de las curvas elípticas a la crip-

tografía. Director: Juan Gabriel Tena Ayuso. Secretariado de Publicaciones e
Intercambio Científico de la Universidad de Valladolid, 1997.
http://dialnet.unirioja.es/servlet/tesis?codigo=11638
[216] PC/SC WORKGROUP. The PC/SC workgroup. Página web.

http://www.pcscworkgroup.com
[217] PÉREZ ORTIZ, J. A. Diccionario urgente de estilo científico del español. Iné-
dito, 1999.
http://www.dlsi.ua.es/~japerez/pub/pdf/duece1999.pdf
[218] PIETILÄINEN, H. “Elliptic curve cryptography on smart cards”. Director: El-

jas Soisalon-Soininen. Faculty of Information Technology, Helsinki University
of Technology, Finlandia, 2000.
http://henna.laurikari.net/Dippa/di.pdf
[219] POHLIG, S. C. y HELLMAN, M. E. “An improved algorithm for computing

logarithms over 𝐺𝐹 (𝑝) and its cryptographic significance”. IEEE Transactions
on Information Theory. Enero 1978, vol. 24, num. 1, pp. 644–654. ISSN 0018-
9448.
[220] POLLARD, J. M. “Theorems on factorization and primality testing”. Mathe-

matical Proceedings of the Cambridge Philosophical Society. Noviembre 1974,
vol. 76, num. 3, pp. 521–528. ISSN 0305-0041.
http://dx.doi.org/10.1017/S0305004100049252
[221] POLLARD, J. M. “A Monte Carlo method for factorization”. BIT Numerical

Mathematics. Septiembre 1975, vol. 15, num. 3, pp. 331–334. ISSN 0006-3835.
http://dx.doi.org/10.1007/BF01933667
Referencias 363
[222] POLLARD, J. M. “Monte Carlo methods for index computation (mod 𝑝)”.
Mathematics of Computation. Julio 1978, vol. 32, num. 143, pp. 918–924.
http://dx.doi.org/10.1090/S0025-5718-1978-0491431-9
[223] QUISQUATER, J. “The adolescence of smart cards”. Future Generation Com-

puter Systems. Julio 1997, vol. 13, num. 1, pp. 3–7. ISSN 0167-739X.
http://dx.doi.org/10.1016/S0167-739X(97)89108-X
[224] QUISQUATER, J. y KOEUNE, F. ECIES - Security evaluation of the encry-

ption scheme and primitives. Informe técnico 1015. Cryptrec, 2002.
http://www.ipa.go.jp/security/enc/CRYPTREC/fy15/doc/1015_ECIES_
report.pdf
[225] RABIN, M. O. Digitalized signatures and public key functions as intractable

as factorization. Informe técnico 212. Massachussetts Institute of Technology
(MIT), 1979.
http://publications.csail.mit.edu/lcs/pubs/pdf/MIT-LCS-TR-212.
pdf
[226] RANKL, W. y EFFING, W. Smart card handbook. 3a ed. West Sussex (Ingla-
terra): John Wiley & Sons, 2003. ISBN 0-470-85668-8.
[227] RIEMANN, B. “Theorie der Abel’schen functionen”. Journal für die reine und
angewandte Mathematik. Enero 1857, num. 54, pp. 115–155. ISSN 0075-4102.
http://dx.doi.org/10.1515/crll.1857.54.115
[228] RIESEL, H. Prime numbers and computer methods for factorization. 2a ed.
Boston: Birkhäuser, 1994. ISBN 0-8176-3743-5.
[229] RIVEST, R. L.; SHAMIR, A. y ADLEMAN, L.. “A method for obtaining di-
gital signatures and public-key cryptosystems”. Communications of the ACM.
Enero 1983, vol. 26, num. 1, pp. 96–99.
http://dx.doi.org/10.1145/359340.359342
[230] ROCH, G. “Ueber die anzahl der willkurlichen constanten in algebraischen

functionen”. Journal für die reine und angewandte Mathematik. Enero 1865,
num. 64, pp. 372–376. ISSN 0075-4102.
http://dx.doi.org/10.1515/crll.1865.64.372
[231] RSA DATA SECURITY INC. Methods and apparatus for efficient finite field
basis conversion. Inventores: B. S. Kaliski, Jr., Y. L. Yin. Fecha de solicitud:
http://www.google.com/patents/about?id=HHIYAAAAEBAJ&dq=5854759
364 Referencias
[232] RSA LABORATORIES. RSA cryptography standard. Ver. 2.1. PKCS #1.
2002.
ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-1/pkcs-1v2-1.pdf
[233] RSA LABORATORIES. Overview of Elliptic Curve Cryptosystems. RSA La-

boratories Technical Note. 1997.
http://www.rsa.com/rsalabs/node.asp?id=2013
[234] RSA LABORATORIES. Password-based cryptography standard. Ver. 2.1.

PKCS#5. 2006.
ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-5v2/pkcs5v2_1.pdf
[235] SATOH, T. y ARAKI, K. “Fermat quotients and the polynomial time dis-
crete log algorithm for anomalous elliptic curves”. Commentarii Mathematici
Universitatis Sancti Pauli. Enero 1998, vol. 47, num. 1, pp. 81–92.
http://mathpc-satoh.math.titech.ac.jp/en/A1998.html
[236] SATOH, T. “The canonical lift of an ordinary elliptic curve over a finite field
and its point counting”. Journal of the Ramanujan Mathematical Society. 2000,
vol. 15, num. 4, pp. 247–270.
http://mathpc-satoh.math.titech.ac.jp/en/A2000.html
[237] SCHNEIER, B. Applied cryptography. 2a ed. Nueva York: John Willey & Sons,
1996. ISBN 0-471-11709-9.
[238] SCHOOF, R. “Elliptic curves over finite fields and the computation of square
roots mod 𝑝”. Mathematics of Computation. Abril 1985, vol. 44, num. 170, pp.
483–494.
http://dx.doi.org/10.1090/S0025-5718-1985-0777280-6
[239] SCHOOF, R. “Counting points on elliptic curves over finite fields”. Journal de
Théorie de Nombres de Bordeaux. 1995, vol. 7, pp. 219–254.
http://www.mat.uniroma2.it/~schoof/ctg.pdf
[240] SEMAEV, I. A. “Evaluation of discrete logarithms in a group of 𝑝-torsion

points of an elliptic curve in characteristic 𝑝”. Mathematics of Computation.
Enero 1998, vol. 67, num. 221, pp. 353–356.
http://dx.doi.org/10.1090/S0025-5718-98-00887-4
[241] SHANKS, D. “Class number, a theory of factorization, and genera”. En: Pro-
ceedings of 1969 Number Theory Institute. Stony Brook (Nueva York), 1969.
pp 415–440. ISBN 0-82181-420-6.
http://www.ams.org/mathscinet-getitem?mr=47:4932
Referencias 365
[242] SHIEH, S. et al. “Digital multisignature schemes for authenticating delegates

in mobile code systems”. IEEE Transactions on Vehicular Technology. Julio
2000, vol. 49, num. 4, pp. 1464–1473. ISSN 0018-9545.
http://dx.doi.org/10.1109/25.875284
[243] SHOUP, V. A proposal for an ISO standard for public key encryption. Ver.
2.1. Inédito, 2001.
http://eprint.iacr.org/2001/112.pdf
[244] SILVERMAN, J. H. y TATE, J. Rational points on elliptic curves. Nueva York:

[245] SILVERMAN, J. H. The arithmetic of elliptic curves. 2a ed. Nueva York:

Springer-Verlag, 2009. ISBN 978-0-387-09493-9.
[246] SMART CARD ALLIANCE. German electronic health card. 2006.

http://www.smartcardalliance.org/resources/pdf/German_Health_
Card.pdf
[247] SMART, N. “The discrete logarithm problem on elliptic curves of trace one”.
Journal of Cryptology. Noviembre 1999, vol. 12, num. 3, pp. 193–196. ISSN
0933-2790.
http://dx.doi.org/10.1007/s001459900052
[248] SOCIÉTÉ INTERNATIONALE POUR L’INNOVATION. Methods of data

storage and data storage systems. Inventor: R. Moreno. Fecha de solicitud:
http://www.google.com/patents/about?id=5js9AAAAEBAJ&dq=3971916
[249] SOCIÉTÉ INTERNATIONALE POUR L’INNOVATION. Data-transfer sys-

tem. Inventor: R. Moreno. Fecha de solicitud: 1975-03-21. Estados Unidos,
http://www.google.com/patents/about?id=-6c1AAAAEBAJ&dq=4007355
[250] SOCIÉTÉ INTERNATIONALE POUR L’INNOVATION. Systems for storing

and transferring data. Inventor: R. Moreno. Fecha de solicitud: 1976-05-13.
http://www.google.com/patents/about?id=l0IxAAAAEBAJ&dq=4092524
[251] SOL, R. Manual práctico de estilo. Barcelona: Urano, 1992. ISBN 84-7953-
020-0.
[252] SOURCEFORGE. OpenCard Framework. Página web.

http://sourceforge.net/projects/opencard/
366 Referencias
[253] STANDARDS FOR EFFICIENT CRYPTOGRAPHY GROUP (SECG). Test

vectors for SEC 1. Ver. 0.3. GEC 2. 1999.
http://www.secg.org/download/aid-390/gec2.pdf
[254] STANDARDS FOR EFFICIENT CRYPTOGRAPHY GROUP (SECG).

Elliptic Curve Cryptography. Ver. 2.0. SEC 1. 2009.
http://www.secg.org/download/aid-780/sec1-v2.pdf
[255] STANDARDS FOR EFFICIENT CRYPTOGRAPHY GROUP (SECG). Re-

commended elliptic curve domain parameters. Ver. 2.0. SEC 2. 2010.
http://www.secg.org/download/aid-784/sec2-v2.pdf
[256] STERN, J. Evaluation report on the ECIES cryptosystem. Informe técnico

1016. Cryptrec, 2002.
http://www.ipa.go.jp/security/enc/CRYPTREC/fy15/doc/1016_Stern.
ECIES.pdf
[257] STINSON, D. R. Cryptography: Theory and practice. 3a ed. Boca Ratón (Flo-
rida): Chapman & Hall/CRC, 2006. ISBN 1-58488-508-4.
[258] SVENDA, P. Cryptographic algorithms re-implementation for JavaCard. Pá-

gina web.
http://www.fi.muni.cz/~xsvenda/jcalgs.html
[259] TECHNISCHE UNIVERSITÄT DARMSTADT. FlexiProvider. Página web.

http://www.cdc.informatik.tu-darmstadt.de/flexiprovider/
[260] TECHNISCHE UNIVERSITÄT GRAZ. IAIK crypto toolkit. Página web.

http://jce.iaik.tugraz.at
[261] UJALDÓN MARTÍNEZ, M. Arquitectura del PC. Volumen I. Microprocesa-

dores. Madrid: Ciencia 3 Distribución, 2003. ISBN 978-84-95391-86-5.
[262] UNIVERSAL SMART CARDS. JCOP range (Java Card OS). Página web.
http://www.usmartcards.com/prod-jcop-range-java-card-os-10.php
[263] UNIVERSIDAD POLITÉCNICA DE MADRID. Cómo citar una bibliografía.

Página web.
http://www.upm.es/upm/biblioteca/citabibliografia.html
[264] WAGSTAFF, S. S. Jr. Cryptanalysis of number theoretic ciphers. Boca Ratón

Referencias 367
[265] WASHINGTON, L. C. Elliptic curves. Number theory and cryptography. 2a ed.

Boca Ratón (Florida): Chapman & Hall/CRC, 2008. ISBN 978-1-4200-7146-7.
[266] WEIL, A. “L’arithmétique sur les courbes algébriques”. Acta Mathematica.

1929, vol. 52, pp. 281–315. ISSN 0001-5962.
http://dx.doi.org/10.1007/BF02592688
[267] WIENER, M. J. “Cryptoanalysis of short RSA secret exponents”. IEEE Tran-

sactions on Information Theory. Mayo 1990, vol. 36, num. 3, pp. 553–558.
ISSN 0018-9448.
http://dx.doi.org/10.1109/18.54902
[268] WIKIPEDIA. Java Card Open Platform. Página web.

http://en.wikipedia.org/wiki/Java_Card_OpenPlatform
[269] WILES, A. “Modular elliptic curves and Fermat’s Last Theorem”. Annals of
Mathematics. Mayo 1995, vol. 141, num. 3, pp. 443–551. ISSN 0003-486X.
http://www.jstor.org/stable/2118559
[270] WILLIAMS, H. C. “A modification of the RSA public key encryption proce-

dure”. IEEE Transactions on Information Theory. Noviembre 1980, vol. 26,
num. 6, pp. 726–729. ISSN 0018-9448.
[271] WILLIAMS, H. C. “A 𝑝+1 method of factoring”. Mathematics of Computation.

Julio 1982, vol. 39, num. 159, pp. 225–234. ISSN 0025-5718.
http://dx.doi.org/10.1090/S0025-5718-1982-0658227-7
[272] WIRELESS APPLICATION PROTOCOL FORUM (WAP FORUM). Wire-

less Transport Layer Security (WTLS). Ver. 06. WAP-261-WTLS. 2001.
http://www.openmobilealliance.org/tech/affiliates/wap/
wap-261-wtls-20010406-a.pdf
[273] ZHANG, K. “Threshold proxy signature schemes”. Lecture Notes in Computer

Science. 1998, vol. 1396, pp. 282–290. ISBN 978-3-540-64382-1.
368 Referencias

Victor Gayoso Martinez

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Victor Gayoso Martinez

Cargado por

Copyright:

Formatos disponibles

Universidad Politécnica de Madrid

Escuela Técnica Superior de Ingenieros de Telecomunicación

Consejo Superior de Investigaciones Científicas

Víctor Gayoso Martínez

Carmen Sánchez Ávila

Luis Hernández Encinas

Tribunal nombrado por el Magfco. y Excmo. Sr. Rector de la Universidad Poli-

Realizado el acto de lectura y defensa de la Tesis el día de

EL PRESIDENTE LOS VOCALES

I do not have a name. You can call me V.

Reputation is what other people know about you.

En primer lugar me gustaría mostrar mi agradecimiento a mis tutores Luis Her-

En especial, me gustaría agradecer a Luis la magnífica oportunidad de haber

El resto de agradecimientos son para:

Mi mujer y mi hija, a las que tanto debo.

Mis padres, por apoyarme y ayudarme siempre que lo he necesitado.

Mi hermana, con la que a pesar de la distancia sigo compartiendo tantas cosas.

La empresa NXP, y muy especialmente Juan Moreno, por proporcionarme las

El departamento de Tratamiento de la Información y Codificación del Instituto

1.6.1. Tarjetas Java Card . . . . . . . . . . . . . . . . . . . . . . . . 36

2. Criptografía de clave pública basada en curvas elípticas 49

2.6.6. Comprobación de los parámetros de una curva elíptica . . . . 90

3. Capacidades criptográficas en Java 99

4. Estudio y análisis del esquema de cifrado ECIES 129

4.3. Componentes funcionales de ECIES . . . . . . . . . . . . . . . . . . . 138

5. Implementación de ECIES en entorno PC 181

5.1.3. Aritmética de puntos de la curva y de elementos del cuerpo

6. Implementación de ECIES en Java Card 243

6.3.2. Herramientas de línea de comandos de Sun . . . . . . . . . . . 247

7. Resultados empíricos 271

7.5.4. Tiempo de descifrado en PC y Java Card con la configuración

8. Conclusiones, aportaciones y trabajo futuro 313

1. Longitudes de clave en RSA y ECC . . . . . . . . . . . . . . . . . . . 2

1.1. Diners Club, la primera tarjeta de crédito del mundo . . . . . . . . . 20

1.23. Elementos de la arquitectura PC/SC . . . . . . . . . . . . . . . . . . 42

2.1. Modelos de seguridad en criptosistemas de clave pública . . . . . . . 56

3.1. Ediciones del lenguaje Java . . . . . . . . . . . . . . . . . . . . . . . 103

4.1. Esquema de funcionamiento de DHIES . . . . . . . . . . . . . . . . . 137

4.4. Maleabilidad debido a la función XOR . . . . . . . . . . . . . . . . . 176

5.1. Diagrama de clases de la aplicación ECIES . . . . . . . . . . . . . . . 187

5.30. Pestaña Cifrado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222

5.60. Identificador del fichero para el mensaje descifrado . . . . . . . . . . . 241

6.1. Ventana principal del entorno de desarrollo Eclipse . . . . . . . . . . 249

7.1. Diagrama de los módulos P5CT072 y P5CD080 . . . . . . . . . . . . 273

7.32. Comparación del tiempo de ejecución en JCOP 41 (configuración M2)

1. Comparación de las longitudes de clave entre RSA y ECC . . . . . . 2

1.1. Valores del byte CLA permitidos . . . . . . . . . . . . . . . . . . . . 44

2.1. Versiones simplificadas de la ecuación de Weierstrass . . . . . . . . . 82

3.1. Clases e interfaces del paquete javacard.security . . . . . . . . . . 125

4.1. Comparativa del proceso de cifrado en ECIES, PSEC y ACE . . . . . 133

6.1. Funcionalidades ECC en Java Card . . . . . . . . . . . . . . . . . . . 246

7.1. Curvas elípticas empleadas en las configuraciones . . . . . . . . . . . 278

7.24. Tiempo de descifrado con curvas sobre 𝔽𝑝 en JCOP J3A e interfaz

8.1. Crecimiento del tiempo de cifrado y descifrado en PC (configuración

2.1. Establecimiento de clave Diffie-Hellman . . . . . . . . . . . . . . . . 58

4.12. Función DEM1 de la fase DEM del cifrado ECIES en ISO/IEC

∙ Factorización en enteros (Integer Factorization Problem o IFP), fundamento

∙ Logaritmo discreto (Discrete Logarithm Problem o DLP), base matemática

∙ Logaritmo discreto en curvas elípticas (Elliptic Curve Discrete Logarithm Pro-

Nivel de seguridad Longitud de la Longitud de la

Cuadro 1: Comparación de las longitudes de clave entre RSA y ECC

Debido a su reciente aparición, al menos en comparación con otros algoritmos de

Figura 1: Longitudes de clave en RSA y ECC

Optimización Tiempo (ms) Puertas lógicas