2O Implementacio N de Tarjetas Inteligentes Java Card

Universidad Politcnica de Madrid
Escuela Tcnica Superior de Ingenieros de Telecomunicacin
Consejo Superior de Investigaciones Cientficas

Instituto de Fsica Aplicada
Implementacin en tarjetas
inteligentes Java Card de
protocolos de cifrado y descifrado
basados en curvas elpticas
Tesis Doctoral
Vctor Gayoso Martnez
Ingeniero de Telecomunicacin
2010
Departamento de Matemtica Aplicada a las

Tecnologas de la Informacin
Departamento de Tratamiento de la
Informacin y Codificacin
Directores
Carmen Snchez vila
Doctora en Ciencias Matemticas
Luis Hernndez Encinas

Doctor en Ciencias Matemticas
Madrid
2010
TRIBUNAL CALIFICADOR
Tribunal nombrado por el Magfco. y Excmo. Sr. Rector de la Universidad Polide
de
.
tcnica de Madrid el da
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 da

de
en Madrid.
de
Calificacin:
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 gustara mostrar mi agradecimiento a mis tutores Luis Hernndez y Carmen Snchez por su esfuerzo continuo y su paciencia infinita revisando
cada borrador de esta Tesis, dndome siempre buenos y acertados consejos.
En especial, me gustara agradecer a Luis la magnfica oportunidad de haber
podido trabajar con l estos dos ltimos aos en el Consejo Superior de Investigaciones Cientficas, 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, Mnica, Mara Jos, Carlos Daniel, Jos Ignacio, 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 habra podido desarrollar una parte importante de la investigacin.
El departamento de Tratamiento de la Informacin y Codificacin del Instituto
de Fsica Aplicada del CSIC, por la profesionalidad y compaerismo demostrados
en estos dos ltimos aos.
ndice general
Introduccin
Antecedentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Justificacin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Metodologa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Clasificacin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 fsicas y elctricas . . . . . . . . . . . . . . . . . . . . . . 28
1.5. Estndares . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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
ndice general
xii
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. Comunicacin con la tarjeta inteligente . . . . . . . . . . . . . . . . . 41
1.8.1. APDU de tipo comando . . . . . . . . . . . . . . . . . . . . . 43
1.8.2. APDU de tipo respuesta . . . . . . . . . . . . . . . . . . . . . 46
2. Criptografa de clave pblica basada en curvas elpticas
49
2.1. Introduccin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
2.2. Aplicaciones de la criptografa de clave pblica . . . . . . . . . . . . . 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 pblica . . . . . . . . . . . . . . 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 hbrido DEM -KEM . . . . . . . . . . . . . . . . 68
2.5.1. Mecanismo de encapsulacin de clave KEM
. . . . . . . . . . 69
2.5.2. Mecanismo de encapsulacin de datos DEM . . . . . . . . . . 69

2.5.3. Esquema de cifrado hbrido con etapas KEM -DEM . . . . . . 70
2.6. Criptografa basada en curvas elpticas . . . . . . . . . . . . . . . . . 70
2.6.1. Definicin de curva elptica . . . . . . . . . . . . . . . . . . . . 71
2.6.2. Estructura de grupo . . . . . . . . . . . . . . . . . . . . . . . 75
2.6.3. Curvas elpticas sobre cuerpos finitos . . . . . . . . . . . . . . 78
2.6.4. Bases polinmicas y bases normales . . . . . . . . . . . . . . . 86
2.6.5. Representacin de los puntos de una curva elptica . . . . . . . 88
ndice general
xiii
2.6.6. Comprobacin de los parmetros de una curva elptica . . . . 90

2.6.7. Seguridad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
2.6.8. Estndares relacionados . . . . . . . . . . . . . . . . . . . . . 92
2.6.9. Patentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
3. Capacidades criptogrficas en Java
99
3.1. Programacin orientada a objetos . . . . . . . . . . . . . . . . . . . . 99

3.1.1. Encapsulacin . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
3.1.2. Herencia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
3.1.3. Polimorfismo . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
3.2. El lenguaje Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
3.2.1. Introduccin al lenguaje Java . . . . . . . . . . . . . . . . . . 100
3.2.2. Elementos del entorno Java . . . . . . . . . . . . . . . . . . . 103
3.2.3. Caractersticas criptogrficas de Java . . . . . . . . . . . . . . 105
3.3. Bibliotecas criptogrficas . . . . . . . . . . . . . . . . . . . . . . . . . 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. Introduccin 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. Caractersticas criptogrficas en Java Card . . . . . . . . . . . 123
3.5. Programacin en Java Card . . . . . . . . . . . . . . . . . . . . . . . 126
4. Estudio y anlisis del esquema de cifrado ECIES
129
4.1. Criptosistemas de curvas elpticas . . . . . . . . . . . . . . . . . . . . 129

4.2. Esquema de cifrado DHIES . . . . . . . . . . . . . . . . . . . . . . . 136
ndice general
xiv
4.3. Componentes funcionales de ECIES . . . . . . . . . . . . . . . . . . . 138

4.3.1. Parmetros de la curva . . . . . . . . . . . . . . . . . . . . . . 139
4.3.2. Funciones resumen . . . . . . . . . . . . . . . . . . . . . . . . 140
4.3.3. Funciones de generacin del secreto compartido . . . . . . . . 140
4.3.4. Funciones de derivacin de claves . . . . . . . . . . . . . . . . 141
4.3.5. Funcin de cifrado simtrico . . . . . . . . . . . . . . . . . . . 145
4.3.6. Funciones generadoras de cdigos de autenticacin para mensajes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
4.4. Versiones de ECIES . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
4.4.1. Versin de ANSI X9.63 . . . . . . . . . . . . . . . . . . . . . . 147
4.4.2. Versin de IEEE 1363a . . . . . . . . . . . . . . . . . . . . . . 151
4.4.3. Versin de ISO/IEC 18033-2 . . . . . . . . . . . . . . . . . . . 155
4.4.4. Versin 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. Comparacin de las funciones permitidas en los estndares . . . . . . 168
4.7. Comparacin de las configuraciones permitidas en los estndares . . . 170
4.8. Versin de ECIES compatible con todos los estndares . . . . . . . . 172
4.9. Seguridad de ECIES . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
4.9.1. Resistencia a la maleabilidad . . . . . . . . . . . . . . . . . . . 172
4.9.2. Ataques de subgrupos pequeos . . . . . . . . . . . . . . . . . 177
4.9.3. Eleccin dinmica de parmetros y funciones . . . . . . . . . . 178
4.10. Versin de ECIES segura . . . . . . . . . . . . . . . . . . . . . . . . . 178
5. Implementacin de ECIES en entorno PC
181
5.1. Diseo del esquema ECIES a implementar . . . . . . . . . . . . . . . 181

5.1.1. Cifrado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
5.1.2. Descifrado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
ndice general
xv
5.1.3. Aritmtica de puntos de la curva y de elementos del cuerpo

finito . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
5.2. Diagrama de clases . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186
5.3. Descripcin funcional de la aplicacin . . . . . . . . . . . . . . . . . . 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. Pestaa Configuracin (en modo avanzado) . . . . . . . . . . 215
5.3.10. Pestaa Parmetros
. . . . . . . . . . . . . . . . . . . . . . . 218
5.3.11. Pestaa Cifrado . . . . . . . . . . . . . . . . . . . . . . . . . . 222

5.3.12. Pestaa Descifrado . . . . . . . . . . . . . . . . . . . . . . . . 227
5.4. Ejemplos de utilizacin . . . . . . . . . . . . . . . . . . . . . . . . . . 234
5.4.1. Ejemplo de cifrado . . . . . . . . . . . . . . . . . . . . . . . . 234
5.4.2. Ejemplo de descifrado . . . . . . . . . . . . . . . . . . . . . . 237
6. Implementacin de ECIES en Java Card
243
6.1. Elementos criptogrficos 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
ndice general
xvi
6.3.2. Herramientas de lnea de comandos de Sun . . . . . . . . . . . 247

6.3.3. Eclipse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248
6.4. Esquema de la aplicacin . . . . . . . . . . . . . . . . . . . . . . . . . 248
6.5. Pruebas con tarjetas virtuales . . . . . . . . . . . . . . . . . . . . . . 253
6.6. Pruebas con tarjetas reales . . . . . . . . . . . . . . . . . . . . . . . . 255
6.7. Aplicacin JCOPECIES . . . . . . . . . . . . . . . . . . . . . . . . . 256
6.8. Ejemplos de utilizacin . . . . . . . . . . . . . . . . . . . . . . . . . . 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 aplicacin
JCOPECIES . . . . . . . . . . . . . . . . . . . . . . . . . . . 269
7. Resultados empricos
271
7.1. Material utilizado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271

7.2. Configuraciones de prueba . . . . . . . . . . . . . . . . . . . . . . . . 275
7.3. Factor de expansin . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279
7.3.1. Factor de expansin con la configuracin M1 . . . . . . . . . . 280
7.3.2. Factor de expansin con la configuracin M2 . . . . . . . . . . 282
7.3.3. Factor de expansin con la configuracin P1 . . . . . . . . . . 282
7.4. Tiempo de cifrado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288
7.4.1. Tiempo de cifrado en PC con la configuracin M1 . . . . . . . 289
7.4.2. Tiempo de cifrado en PC y Java Card con la configuracin M2 289
7.4.3. Tiempo de cifrado en PC con la configuracin P1 . . . . . . . 289
7.4.4. Tiempo de cifrado en PC y Java Card con la configuracin P2 294
7.4.5. Tiempo de cifrado en PC y Java Card con la configuracin P3 294
7.5. Tiempo de descifrado . . . . . . . . . . . . . . . . . . . . . . . . . . . 299
7.5.1. Tiempo de descifrado en PC con la configuracin M1 . . . . . 299
7.5.2. Tiempo de descifrado en PC y Java Card con la configuracin
M2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299
7.5.3. Tiempo de descifrado en PC con la configuracin 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 estndar . . . . . . . . . . . . . . . . 314
8.1.2. Conjunto de parmetros compatibles con todos los estndares 314
8.1.3. Desarrollo de la implementacin de ECIES para PC . . . . . . 315
8.1.4. Estudio de la eficiencia de la implementacin PC . . . . . . . 316
8.1.5. Desarrollo de la implementacin de ECIES en tarjetas Java
Card . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 318
8.1.6. Estudio de la eficiencia de la implementacin Java Card . . . . 319
8.1.7. Comparativa entre las versiones PC y Java Card . . . . . . . . 324
8.1.8. Configuracin de ECIES resistente a ataques . . . . . . . . . . 324
8.2. Aportaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325
8.3. Trabajo futuro
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 327
Notacin
331
Glosario
333
Referencias
339
ndice de figuras
1.
Longitudes de clave en RSA y ECC . . . . . . . . . . . . . . . . . . .
1.1. Diners Club, la primera tarjeta de crdito del mundo . . . . . . . . . 20

1.2. Tarjeta con banda magntica
. . . . . . . . . . . . . . . . . . . . . . 20
1.3. Prototipo de D.N.I. electrnico de Espaa . . . . . . . . . . . . . . . 21

1.4. Tarjeta SIM de Telefnica movistar . . . . . . . . . . . . . . . . . . . 21
1.5. Tarjeta monedero Danmont de la serie emitida en 1994 . . . . . . . . 21
1.6. Ejemplo de tarjeta de salud de la Repblica 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
ndice de figuras
xx
1.23. Elementos de la arquitectura PC/SC . . . . . . . . . . . . . . . . . . 42

1.24. Modelo de comunicacin 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 cdigos de respuesta
. . . . . . . . . . . . . . . . . . . . . . 47
2.1. Modelos de seguridad en criptosistemas de clave pblica . . . . . . . 56

2.2. Curva 2 = 3 con un nodo en el punto (0, 0) . . . . . . . . . . . . . . 72
2.3. Curva 2 + 3 = 0 con una cspide en el punto (0, 0) . . . . . . 72
2.4. Curva elptica 2 = 3 10 + 15 . . . . . . . . . . . . . . . . . . . . 74
2.5. Curva elptica 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 utilizacin de proveedores criptogrficos en Java . . . . . 106
3.3. Arquitectura Java Card y de su entorno de ejecucin . . . . . . . . . 117
3.4. Mtodos para la gestin del ciclo de vida de un applet Java Card
. . 118
3.5. Mtodos implicados en la gestin de un applet . . . . . . . . . . . . . 119

3.6. Comparticin de objetos en Java Card . . . . . . . . . . . . . . . . . 120
3.7. Esquema de conversin 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 funcin XOR . . . . . . . . . . . . . . . . . 176

5.1. Diagrama de clases de la aplicacin ECIES . . . . . . . . . . . . . . . 187
5.2. Ventana principal del entorno de desarrollo NetBeans . . . . . . . . . 190
5.3. Ventana principal de la aplicacin . . . . . . . . . . . . . . . . . . . . 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 opcin Ayuda . . . . . . . . . . . . . . . . . . . . . . . 194
5.8. Ventana de la opcin Acerca de . . . . . . . . . . . . . . . . . . . . . 195
5.9. Pantalla de confirmacin de la opcin Salir . . . . . . . . . . . . . . . 195
5.10. Opcin Sencillo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196
5.11. Opcin 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 creacin de los ficheros de claves . . . . . . . . . . . . . . 208
5.21. Ventana de generacin de clave en cuerpos . . . . . . . . . . . . . 213
5.22. Ventana de generacin de clave en cuerpos 2 . . . . . . . . . . . . . 213
5.23. Ventana de descompresin de puntos en cuerpos . . . . . . . . . . 214
5.24. Ventana de descompresin 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. Pestaa Configuracin . . . . . . . . . . . . . . . . . . . . . . . . . . 216
5.28. Pestaa Parmetros con el men Cuerpo GF() activado . . . . . . . 219
5.29. Pestaa Parmetros con el men Cuerpo GF(2^m) activado . . . . . 220
xxii
ndice de figuras
5.30. Pestaa Cifrado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222

5.31. Seleccin del fichero con la clave pblica . . . . . . . . . . . . . . . . 224
5.32. Seleccin del fichero con el mensaje en claro . . . . . . . . . . . . . . 224
5.33. Seleccin del fichero donde se almacenar el criptograma . . . . . . . 224
5.34. Modalidades de identificacin de la clave pblica . . . . . . . . . . . . 225
5.35. Contenido del mensaje en claro no interpretable como texto . . . . . 226
5.36. Ejemplo de cifrado ECIES . . . . . . . . . . . . . . . . . . . . . . . . 227
5.37. Pestaa Descifrado . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228
5.38. Seleccin del fichero con la clave privada . . . . . . . . . . . . . . . . 229
5.39. Seleccin del fichero con el criptograma . . . . . . . . . . . . . . . . . 229
5.40. Seleccin del fichero donde se almacenar el mensaje en claro . . . . . 230
5.41. Modalidades de identificacin de la clave privada . . . . . . . . . . . . 231
5.42. Ventana de solicitud del cdigo 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. Seleccin del fichero con la clave pblica del destinatario . . . . . . . 234
5.47. Identificador de la clave pblica del destinatario . . . . . . . . . . . . 235
5.48. Seleccin del fichero con el mensaje en claro . . . . . . . . . . . . . . 235
5.49. Identificador del fichero con el mensaje en claro . . . . . . . . . . . . 236
5.50. Seleccin 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. Seleccin del fichero con la clave privada del destinatario . . . . . . . 238
5.55. Introduccin de la contrasea para el acceso a la clave privada . . . . 239
5.56. Identificador de la clave privada del destinatario . . . . . . . . . . . . 239
5.57. Seleccin del fichero con el criptograma . . . . . . . . . . . . . . . . . 240
5.58. Identificador del fichero con criptograma . . . . . . . . . . . . . . . . 240
5.59. Seleccin 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. Tamao de los aplets JCOP-M2, JCOP-P2 y JCOP-P3 . . . . . . . . 257
6.3. Pestaa Configuracin . . . . . . . . . . . . . . . . . . . . . . . . . . 258
6.4. Lectores de tarjetas disponibles . . . . . . . . . . . . . . . . . . . . . 259
6.5. Curvas implementadas en JCOP 41 y JCOP J3A . . . . . . . . . . . 259
6.6. Generacin y recuperacin de una clave pblica de 192 bits . . . . . . 259
6.7. Pestaa Cifrado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260
6.8. Pestaa Descifrado . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261
6.9. Pestaa Acerca . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262
6.10. Errores asociados al lector, la curva o la tarjeta . . . . . . . . . . . . 262
6.11. Generacin de nuevas claves en JCOP 41 . . . . . . . . . . . . . . . . 264
6.12. Parmetros de las claves de 193 bits de U en JCOP 41 . . . . . . . . 265
6.13. Parmetros 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 mdulos 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 expansin en curvas sobre 2 con la configuracin M1 . . 281
7.6. Factor de expansin en curvas sobre con la configuracin P1
. . . 284
. . . 286
. . . 287
7.9. Tiempo de cifrado con curvas sobre 2 en PC (configuracin M1) . . 290

xxiv
ndice de figuras
7.11. Tiempo de cifrado con curvas sobre 2 en JCOP 41 e interfaz sin

contactos (configuracin 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 (configuracin P1) . . . 294
7.15. Tiempo de cifrado con curvas sobre en JCOP J3A e interfaz sin
contactos (configuracin P2) . . . . . . . . . . . . . . . . . . . . . . . 296
7.18. Tiempo de descifrado con curvas sobre 2 en PC (configuracin 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 (configuracin M2) . . . . . . . . . . . . . . . . . . . . 303
7.22. Tiempo de descifrado con curvas sobre en PC (configuracin P1) . 304
7.24. Tiempo de descifrado con curvas sobre en JCOP J3A e interfaz
sin contactos (configuracin P2) . . . . . . . . . . . . . . . . . . . . . 306
7.27. Comparacin del tiempo de ejecucin en PC (configuraciones M1 y P1)309
7.28. Comparacin del tiempo de ejecucin entre las versiones PC y Java
Card (configuracin M2) . . . . . . . . . . . . . . . . . . . . . . . . . 310
Card (configuracin P2) . . . . . . . . . . . . . . . . . . . . . . . . . 310
Card (configuracin P3) . . . . . . . . . . . . . . . . . . . . . . . . . 311
7.31. Comparacin del tiempo de ejecucin en las tarjetas JCOP 41 (configuracin M2) y JCOP J3A (configuracin P2) al cifrar un mensaje
de 64 bytes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312
ndice de figuras
xxv
7.32. Comparacin del tiempo de ejecucin en JCOP 41 (configuracin M2)

y JCOP J3A (configuracin P2) al cifrar un mensaje de 160 bytes . . 312
ndice de cuadros
1.
Comparacin de las longitudes de clave entre RSA y ECC . . . . . .
2.
Comparacin del rendimiento de ECC, RSA y los esquemas DLP

medido en unidades de tiempo necesarias para cada operacin . . . .
Comparacin de las implementaciones hardware de RSA y ECC . . .
3.
1.1. Valores del byte CLA permitidos . . . . . . . . . . . . . . . . . . . . 44

1.2. Valores del byte CLA permitidos . . . . . . . . . . . . . . . . . . . . 45
2.1. Versiones simplificadas de la ecuacin 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. Nmero 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. Funcin HASH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
4.6. Funcin KA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
4.7. Funcin KDF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
4.8. Funcin ENC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
4.9. Funcin MAC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
4.10. Funciones comunes permitidas en los cuatro estndares . . . . . . . . 170
4.11. Combinaciones de parmetros admitidas al menos en un estndar . . 171
4.12. Comparativa de las configuraciones permitidas en cada estndar . . . 172
xxvii
xxviii
ndice de cuadros
6.1. Funcionalidades ECC en Java Card . . . . . . . . . . . . . . . . . . . 246

7.1. Curvas elpticas empleadas en las configuraciones . . . . . . . . . . . 278
. . . 284
. . . 285
. . . 287

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 (configuracin
M1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317
8.2. Crecimiento del tiempo de cifrado y descifrado en PC (configuracin
P1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 318
8.3. Crecimiento del tiempo de cifrado y descifrado en JCOP 41 e interfaz
sin contactos (configuracin 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 interfaz sin contactos (configuracin P2) . . . . . . . . . . . . . . . . . . . 321
8.6. Crecimiento del tiempo de cifrado y descifrado en JCOP J3A e interfaz sin contactos (configuracin P3) . . . . . . . . . . . . . . . . . . . 321
8.7. Incremento relativo del tiempo de ejecucin en JCOP 41 e interfaz
sin contactos (configuracin M2) . . . . . . . . . . . . . . . . . . . . . 323
8.8. Incremento relativo del tiempo de ejecucin en JCOP 41 e interfaz
8.9. Incremento relativo del tiempo de ejecucin en JCOP J3A e interfaz
8.10. Incremento relativo del tiempo de ejecucin en JCOP J3A e interfaz
ndice de algoritmos
2.1.
Establecimiento de clave Diffie-Hellman . . . . . . . . . . . . . . . . 58
2.2.
Generacin de claves RSA . . . . . . . . . . . . . . . . . . . . . . . . 60
2.3.
Cifrado RSA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
2.4.
Descifrado RSA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
2.5.
Generacin 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.
Compresin de un punto = (, ) de la curva . . . . . . . . . . . . 89
2.9.
Descompresin de un punto = (, ) de la curva . . . . . . . . . . 89
2.10. Generacin aleatoria de una curva sobre 2 . . . . . . . . . . . . . 90

2.11. Comprobacin de los parmetros de una curva . . . . . . . . . . . . 91
2.12. Validacin de una clave pblica . . . . . . . . . . . . . . . . . . . 91
4.1.
Criptosistema Massey-Omura con curvas elpticas . . . . . . . . . . 130
4.2.
Criptosistema ElGamal con curvas elpticas . . . . . . . . . . . . . . 130
4.3.
Criptosistema Menezes-Vanstone con curvas elpticas . . . . . . . . . 131
4.4.
Funcin ANSI-X9.63-KDF . . . . . . . . . . . . . . . . . . . . . . . 142
4.5.
Funcin NIST-800-56-Concatenation-KDF . . . . . . . . . . . . . . . 143
4.6.
Funcin KDF1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
4.7.
Funcin KDF2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
4.8.
Funcin 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. Funcin 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 estndares (ECIES-4) . . . 173
4.17. Cifrado ECIES compatible con los cuatro estndares (ECIES-3) . . . 179
5.1.
Cifrado ECIES en la versin PC (fase KEM ) . . . . . . . . . . . . . 182
5.2.
Cifrado ECIES en la versin PC (fase DEM ) . . . . . . . . . . . . . 183
5.3.
Descifrado ECIES en la versin PC (fase KEM ) . . . . . . . . . . . 184
5.4.
Descifrado ECIES en la versin PC (fase DEM ) . . . . . . . . . . . 184
5.5.
Generacin de una semilla aleatoria . . . . . . . . . . . . . . . . . . 209
Introduccin
Antecedentes
En 1976, Whitfield Diffie y Martin Hellman [61] desarrollaron los conceptos que
permitieron el nacimiento de la criptografa de clave pblica. Desde entonces, numerosos criptosistemas han sido propuestos, aunque slo unos pocos han soportado
con xito el escrutinio de la comunidad cientfica. Entre los elementos analizados
por los expertos destacan principalmente las caractersticas de eficiencia, complejidad y seguridad de los algoritmos, las cuales dependen en gran medida del problema
matemtico en que estn basados. Algunos de los problemas relacionados con los
criptosistemas actuales son:
Factorizacin en enteros (Integer Factorization Problem o IFP), fundamento
del criptosistema RSA [66, 232, 229].
Logaritmo discreto (Discrete Logarithm Problem o DLP), base matemtica
para el algoritmo ElGamal [69].
Logaritmo discreto en curvas elpticas (Elliptic Curve Discrete Logarithm Problem o ECDLP), ncleo de la criptografa basada en curvas elpticas.
En 1985, Neal Koblitz [147] y Victor Miller [174] propusieron de forma independiente el uso de curvas elpticas en criptografa (Elliptic Curve Cryptography o
ECC), cuya seguridad depende del ECDLP. Desde entonces, la ECC se ha aplicado
a campos tan diversos como la creacin de criptosistemas para el cifrado y descifrado
de datos [16, 109, 136, 254], la generacin y verificacin de firmas digitales [15, 184],
la factorizacin de enteros [49, 159], las tcnicas de primalidad [23, 49, 95], e incluso
ocup un lugar destacado en la demostracin del ltimo teorema de Fermat por
parte de Andrew Wiles [269].
1
Introduccin
Al igual que en el caso del IFP y del DLP, no se conoce ningn algoritmo que
resuelva de forma eficiente el ECDLP. De hecho, se estima que el ECDLP es el ms
difcil de resolver de los tres problemas mencionados [37, 147, 168], lo que convertira
la criptografa con curvas elpticas en el criptosistema ms resistente.
Gracias a esta mayor resistencia, la longitud de las claves en ECC es sensiblemente inferior que la necesaria en otros algoritmos para conseguir el mismo nivel
de seguridad (medido como la fortaleza proporcionada por un algoritmo de cifrado
simtrico 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 telfonos mviles y las
tarjetas inteligentes.
Nivel de seguridad Longitud de la
(bits)
clave RSA (bits)
80
1024
112
2048
128
3072
192
7680
256
15360
Longitud de la
clave ECC (bits)
160-223
224-255
256-283
384-511
512-571
Cuadro 1: Comparacin de las longitudes de clave entre RSA y ECC
Debido a su reciente aparicin, al menos en comparacin con otros algoritmos de

clave pblica como el propio criptosistema RSA, las propiedades y posibilidades de
utilizacin de la criptografa de curva elptica han sido estudiadas en menor profundidad que otras opciones criptogrficas, lo que ha motivado su menor implantacin
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/verificacin,
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 nmero de unidades temporales necesarias para realizar las operaciones
citadas, tomando como unidad de referencia el tiempo necesario para realizar una
multiplicacin modular de 1024 bits.
Por su parte, los autores de [38] presentaron una comparacin entre ECC y RSA
utilizando dos implementaciones hardware distintas, diseadas para conseguir la mejor optimizacin en el espacio ocupado y la velocidad de ejecucin del proceso de
cifrado, respectivamente. Los resultados de dicho anlisis se presentan en el Cuadro 3, donde se puede comprobar que el tiempo de procesamiento global (cifrado ms
descifrado) de ECC mejora respecto al de RSA al pasar de utilizar implementaciones
software a emplear diseos hardware optimizados para las operaciones criptogrficas
Introduccin
Figura 1: Longitudes de clave en RSA y ECC
Cifrado
Descifrado
Firma
Verificacin
ECC 160 bits RSA 1024 bits (con CRT) DLP 1024 bits
120
17
480
60
384
240
60
384
240
120
17
480
Cuadro 2: Comparacin del rendimiento de ECC, RSA y los esquemas DLP medido en
unidades de tiempo necesarias para cada operacin
Introduccin
necesarias.
RSA 1024
ECC 163
RSA 1024
ECC 163
RSA 3072
ECC 283
RSA 3072
ECC 283
Optimizacin Tiempo (ms) Puertas lgicas

4.90
34000
Espacio
0.66
3260
2.60
150000
Velocidad
0.35
48400
184
50000
Espacio
29
6660
110
189200
Velocidad
1.3
80100
Cuadro 3: Comparacin 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 elpticas aumenten su importancia y utilidad an ms en el futuro segn
se incrementen en paralelo los requisitos de seguridad.
Justificacin
A la vista de la situacin planteada en el apartado anterior, y dada la escasez de
implementaciones software de ECC en general (y en tarjetas inteligentes en particular), se estim la importancia de desarrollar diversas aplicaciones que implementaran
un protocolo de cifrado y descifrado sobre curvas elpticas en entornos PC y tarjetas
inteligentes, siendo Java el lenguaje de programacin elegido debido a su popularidad y presencia en entornos comerciales (ver 3.2 y 3.4). A ttulo informativo, la
cifra de desarrolladores Java supera en la actualidad los 6 millones, existiendo ms
de 4.500 millones de dispositivos habilitados con tecnologa Java (principalmente
ordenadores personales, telfonos mviles y tarjetas inteligentes) [212].
El siguiente paso consisti en analizar los diferentes esquemas de cifrado existentes y seleccionar uno de los candidatos para su implementacin. Los primeros
esquemas basados en curvas elpticas que surgieron fueron el equivalente de los sistemas 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 elptica. Si bien es cierto que en las
curvas utilizadas habitualmente el nmero de puntos es un valor tan elevado que esta
limitacin es ms terica que prctica, la obligatoriedad de construir tablas donde
se relacionen cada uno de los posibles mensajes (y que stas sean previamente conocidas por todos los usuarios) limita la utilidad de estos criptosistemas a entornos
Introduccin
cerrados donde todos los posibles mensajes estn estipulados (empresas, pequeos
grupos, etc.).
El criptosistema Menezes-Vanstone [169] fue diseado para solventar esa limitacin, 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 elptica.
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 numrico). Como contrapartida negativa, 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 ElGamal para curvas elpticas, donde el criptograma siempre tiene la misma longitud
independientemente del mensaje en claro).
En el esquema Menezes-Vanstone el factor de expansin (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 comparacin, la variante de ElGamal con curvas elpticas tiene el mismo
factor de expansin si se considera que el mensaje en claro es un punto de la curva,
mientras que si se interpreta que el nmero total de mensajes posibles es igual
al nmero de puntos de la curva (que es del orden del nmero de elementos del
cuerpo finito), entonces el factor de expansin sera aproximadamente 4 (ver 4.1).
El hecho de tener un factor de expansin igual a 2 4 conlleva que el cifrado de
volmenes de informacin elevados generen criptogramas de tamao mucho mayor
que si se utilizara un algoritmo de clave simtrica como por ejemplo AES (Advanced
Encryption Standard).
Otra desventaja derivada del diseo del criptosistema Menezes-Vanstone consiste en la realizacin de operaciones con los puntos de las curvas elpticas en cada
proceso de cifrado. Al ser necesario dividir los mensajes en claro de gran tamao en
mltiples segmentos, y realizar un operacin de cifrado asimtrico con cada uno de
ellos, la diferencia en tiempo de ejecucin del esquema Menezes-Vanstone respecto
a un algoritmo de cifrado simtrico se incrementa conforme aumenta el nmero de
segmentos a cifrar, puesto que las operaciones con puntos son ms lentas que los
clculos realizados por los algoritmos de clave simtrica.
De manera adicional a las desventajas de carcter prctico sealadas, Klaus Kiefer demostr en 1998 que, bajo ciertas ciertas condiciones, el criptosistema MenezesVanstone es inseguro [146]. Kiefer demostr adems que, en contra de lo estipulado
en su especificacin, este criptosistema no puede ser considerado un algoritmo de
cifrado probabilstico.
Debido a todas las razones comentadas, con el paso de los aos la comunidad
acadmica ha ido abandonando el estudio de las versiones con curvas elpticas de
Introduccin
los criptosistemas Massey-Omura, ElGamal y Menezes-Vanstone. Sin embargo, el

descubrimiento de las limitaciones de esos criptosistemas no signific que se abandonara la bsqueda de un criptosistema de curvas elpticas que fuera prctico y seguro,
sino que provoc un cambio de direccin, pasando a ocupar el centro de atencin
los esquemas de cifrado hbridos (descritos en 2.5). Los principales esquemas hbridos que emplean curvas elpticas 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 nmero de
estndares (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 seleccin
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 pblica del receptor del criptograma
es un punto de la curva, mientras que en ACE la clave pblica est formada
por cuatro puntos.
PSEC utiliza dos veces una funcin de derivacin de claves, mientras que
ECIES y ACE slo la utilizan una vez.
ECIES y ACE utilizan la primera coordenada de un punto de la curva generado durante los clculos intermedios (en lugar de las dos coordenadas) como
parmetro de entrada de la funcin de derivacin de claves, mientras que en
PSEC es obligatorio utilizar las dos coordenadas.
Los criptogramas de ECIES estn formados por tres elementos (un punto de
la curva, el mensaje cifrado con una clave simtrica y un dato utilizado para la
autenticacin del mensaje), mientras que los criptogramas de PSEC incluyen
adems un elemento derivado de los clculos intermedios (y representado como
una cadena binaria) y los criptogramas del esquema ACE aaden dos puntos
de la curva elptica.
En la comparacin 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 nmero de operaciones necesarias como de ciclos
de reloj, el tiempo de proceso y el factor de expansin resultante muestran una clara
ventaja de ECIES frente a PSEC y ACE.
Introduccin
La seguridad comparada de los tres esquemas candidatos es un tema sobre el que

no existe acuerdo en la comunidad acadmica. El informe final del proyecto NESSIE
seleccion a PSEC y ACE como esquemas de cifrado asimtrico, dejando fuera de la
seleccin 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
clculos son correctos en funcin de los dems parmetros del criptograma, mientras
que en comparacin 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. Adems, la utilidad en la prctica de la autenticacin de los
datos intermedios del proceso de cifrado no est clara, puesto que los tres esquemas
emplean de forma adicional un algoritmo de autenticacin de los datos a cifrar, por
lo que la primera autenticacin podra considerarse redundante [58].
El ltimo aspecto presente en la evaluacin 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 versin PC no existen limitaciones
a este respecto, puesto que cualquier funcin criptogrfica puede ser codificada mediante el lenguaje Java, en cambio en Java Card existen importantes limitaciones,
puesto que por ejemplo en sus API (Application Programming Interface) no existen
mtodos 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 funcin Diffie-Hellman sobre curvas elpticas, que se puede considerar equivalente
al producto escalar pero con la particularidad de que el API de Java Card define
como salida de dicha funcin la primera coordenada del punto de la curva que representa la multiplicacin o bien el resultado de pasar dicha coordenada a travs de
una funcin resumen (hash, en ingls).
Tras evaluar los tres criterios mencionados (rendimiento, seguridad y funcionalidad disponible en las plataformas PC y Java Card), en vista de sus caractersticas, y
considerando como elemento positivo adicional su mayor difusin en los estndares,
el esquema seleccionado para su implementacin tanto en PC como en tarjetas Java
Card fue ECIES.
Una vez seleccionado el esquema de cifrado y el lenguaje de programacin, la
siguiente decisin 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. Utilizacin de bibliotecas criptogrficas de terceros adaptadas a la arquitectura
de seguridad Java.
2. Uso de bibliotecas criptogrficas de terceros con clases y sintaxis propietarias,
no adaptadas a la arquitectura Java.
Introduccin
3. Desarrollo propio de los algoritmos relacionados con la ECC y de las operaciones aritmticas con los puntos de las curvas elpticas y con los elementos de
los cuerpos finitos.
La primera opcin referida permite un desarrollo rpido, al utilizar paquetes criptogrficos (en la medida de lo posible de cdigo abierto) ya probados y de notable
calidad. Sin embargo, esta opcin limita la utilizacin de parmetros a los contemplados por dichas bibliotecas, que tal como se describir en 3.3 no ofrecen todas
las combinaciones posibles de algoritmos y parmetros que se deseaban analizar en
esta Tesis.
La segunda opcin es, probablemente, la menos recomendable, al crear una dependencia respecto a unas clases no interoperables de otros proveedores, con la
dificultad inherente de una migracin futura que tenga previsto utilizar software de
otro proveedor, manteniendo al mismo tiempo la limitacin sobre las combinaciones
de algoritmos y parmetros incluidas en la distribucin.
La ltima opcin, 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 parmetros que requiera el proyecto.
El aspecto negativo de esta opcin lo constituye el coste en tiempo y esfuerzo del
desarrollo en comparacin con las soluciones ya existentes, aunque una vez completado el desarrollo de la biblioteca criptogrfica, sta se podra reutilizar en cualquier
desarrollo posterior.
En la presente Tesis Doctoral, se ha optado por el desarrollo propio para implementar una aplicacin de PC que permita realizar las operaciones de cifrado y descifrado empleando una elevada combinacin de parmetros. Adems de las ventajas
enunciadas anteriormente, este mecanismo aporta la flexibilidad adicional necesaria para poder llevar a cabo las comparaciones con la implementacin de ECIES a
realizar en tarjetas Java Card.
En cuanto a la implementacin en tarjetas inteligentes, dadas las limitaciones
tanto en las API estndar de Java Card (ver 6.2) como en las funcionalidades disponibles en tarjetas reales (ver 7.1), nicamente ha sido posible desarrollar algunas
de las posibles combinaciones de parmetros y funciones de ECIES (ver 7.2).
El ltimo paso antes de comenzar la implementacin de ECIES consisti en comprobar que los objetivos de la Tesis no hubieran sido logrados por otros autores. Tras
realizar las bsquedas correspondientes y analizar el contenido de otras tesis, proyectos fin de carrera, artculos de investigacin y ponencias de congresos, fue posible
identificar una serie de trabajos relacionados con implementaciones Java de curvas
elpticas en tarjetas inteligentes o plataformas PC. A continuacin se detallan dichos
trabajos, adjuntando las razones por los que sus objetivos y desarrollos difieren de
los de la presente Tesis.
Introduccin
Elliptic curve cryptography on smart cards [218]: se trata de un Proyecto Fin

de Carrera presentado el ao 2000 en el que, con el objetivo de comparar ECC
y RSA en tarjetas inteligentes, se muestra una implementacin de los algoritmos Nyberg-Rueppel de firma digital y Menezes-Vanstone de cifrado. La
implementacin desarrollada emplea nicamente curvas definidas sobre cuerpos 2 , utilizando para la realizacin de las pruebas el emulador software
incluido en Java Card 2.1, sin presentar ningn resultado con tarjetas reales.
Smart-card implementation of Elliptic Curve Cryptography and DPA-based attacks [142]: este artculo analiza los ataques de canal lateral (tambin conocidos
como side channel attacks) diseados especficamente para tarjetas inteligentes que implementen criptografa de curva elptica. El artculo se centra en
el anlisis de seguridad, proponiendo algunas medidas para evitar ataques de
anlisis de potencia (Differential Power Analysis o DPA) al utilizar curvas
sobre cuerpos 2 , pero sin tratar especficamente el esquema ECIES.
Lessons learned on implementing ECDSA on a Java smart card [71]: artculo
que describe las dificultades de implementar clases propietarias para la ejecucin del algoritmo de firma digital ECDSA [15, 184], y que concluye que
dicha implementacin en tarjetas Java Card no es prctica, siendo preferible
que existan clases estndar incluidas en la tarjeta, y que stas utilicen un coprocesador. 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 implementacin de ECDSA en una placa de simulacin
NGICC (Next Generation Integrated Circuit Card) de 32 bits con coprocesador criptogrfico y soporte nativo para funciones de ECC mediante API de
Java Card. Tras la implementacin, los autores comparan el rendimiento de
ECDSA con RSA para concluir que la ejecucin de ECDSA es ms eficiente.
Elliptic curve cryptosystems on smart cards [178]: artculo que describe de
forma terica la implementacin de un protocolo de acuerdo de clave para
tarjetas inteligentes basado en las operaciones del algoritmo de firma digital
ECDSA. Este trabajo presenta una comparacin 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]: artculo
en que los autores implementaron las clases necesarias para realizar aritmtica
modular y de puntos en tarjetas Java Card 2.0 y 2.1. Como ejemplo del bajo
rendimiento de la implementacin, la suma de dos puntos de una curva de 109
bits definida sobre 2 tardaba 10 minutos, debido a que la tarjeta empleada
no dispona de API especificas para ECC ni de coprocesador matemtico. Este
trabajo reitera la imposibilidad de desarrollar implementaciones eficientes con
10
Introduccin
curvas elpticas en tarjetas inteligentes sin utilizar las clases y los mtodos
definidos en las API estndar de Java Card.
La lectura del material referido ofrece datos concluyentes respecto a las limitaciones de las implementaciones que no utilicen las clases y API estndar de Java Card.
Aunque tcnicamente es posible crear clases y mtodos que realicen operaciones
comnmente conocidas como de bajo nivel (por ejemplo, Petr Svenda ha creado
implementaciones del algoritmo AES y de la funcin resumen SHA-512 utilizando
cdigo 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 operacin no debera superar la cantidad de un segundo (comprese este dato, por
ejemplo, con los 10 minutos utilizados en la suma de dos puntos segn [28], o con
el tiempo medio de 4 segundos al cifrar con AES un nico bloque de datos con la
implementacin 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 combinaciones de parmetros.
Comparar el rendimiento de las implementaciones en PC y Java Card, tanto
por separado como de forma conjunta.
Recomendar combinaciones especficas para su utilizacin en distintos tipos de
dispositivos, en funcin de las caractersticas de los dispositivos y del nivel de
seguridad deseado.
Para conseguir este objetivo general, se pretenden alcanzar los siguientes objetivos 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
estndar coherente y homogneo.
2. Proponer un conjunto (o conjuntos) de parmetros que sean compatibles con
todos los estndares analizados.
Introduccin
11
3. Desarrollar una implementacin de ECIES utilizando el lenguaje de programacin Java sobre una plataforma PC que permita trabajar con los conjuntos
de parmetros propuestos y curvas definidas sobre cuerpos finitos primos y
binarios.
4. Estudiar la eficiencia en trminos de tiempo de computacin y de factor de
expansin de la implementacin para PC.
5. Implementar el protocolo ECIES en tarjetas inteligentes de tipo Java Card,
segn la oferta y disponibilidad de tarjetas existentes en el mercado, con curvas
definidas tanto sobre cuerpos finitos primos como binarios.
6. Caracterizar en trminos de eficiencia la implementacin realizada en las tarjetas Java Card utilizando curvas definidas sobre los dos cuerpos finitos anteriormente mencionados.
7. Comparar la implementacin 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 caractersticas de programacin
de cada una de las plataformas.
8. Recomendar una configuracin de ECIES que asegure su resistencia a los diferentes tipos de ataques conocidos, comprobando si dicha configuracin 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
acadmica tanto en sus aspectos ms generales [103, 145, 150, 151, 152], como de
manera especfica para implementaciones de curvas elpticas [30, 92, 142, 181]. Sin
embargo, puesto que la implementacin Java Card desarrollada en esta Tesis utiliza
tarjetas inteligentes comerciales de las que no se ha podido obtener informacin
sobre las soluciones implementadas para evitar este tipo de ataques, y dado que
el equipamiento necesario (equipos lser y de implantacin inica, laboratorio de
tratamientos qumicos, etc.) para realizar este tipo de ataques es extremadamente
costoso, los anlisis de ataques de canal lateral para las tarjetas empleadas quedan
reservados para organismos o instituciones dedicadas de forma preeminente a este
tipo de actividades.
Metodologa
Teniendo en cuenta los objetivos sealados anteriormente, la metodologa empleada a lo largo de este trabajo de investigacin ha consistido en estudiar el sistema
12
Introduccin
de cifrado ECIES haciendo uso de la bibliografa general sobre criptografa y de los

estndares donde tal sistema es propuesto y presentado. Posteriormente se ha llevado
a cabo el diseo e implementacin de este esquema de cifrado.
Para llevar a cabo estas tareas se han consultado las bibliotecas de diferentes
universidades y del Instituto de Fsica Aplicada del Consejo Superior de Investigaciones Cientficas, as como las principales bases de datos en Internet. Tambin se
ha consultado y pedido opinin a investigadores y expertos nacionales y extranjeros,
entre los que cabe destacar al profesor Alfred Menezes.
En la parte del anlisis del estndar ECIES, se ha llevado a cabo un estudio pormenorizado de sus caractersticas, segn la propuesta de cada uno de los organismos
que lo incluyen, y se han comparado tales propuestas, obtenindose las conclusiones
apropiadas.
Con relacin a la parte del diseo e implementacin del software para ECIES en
Java, se ha recurrido al uso de las dos tcnicas metodolgicas tpicas para este tipo
de trabajos de investigacin y desarrollo: dividir el problema a resolver en problemas
menores y realizar pruebas de ensayo y error. As, al margen del diseo del trabajo
a desarrollar, que ha sido estructurado de modo jerrquico, la implementacin se ha
dividido en bloques de trabajo pequeos de modo que la estructura de la programacin 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 unin 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 bibliogrficas y para la adquisicin de artculos y libros han sido sufragados por diferentes proyectos y contratos de investigacin del Departamento de Tratamiento de la Informacin y Codificacin del Instituto
de Fsica 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 investigacin,
donde se han publicado resultados parciales de esta memoria. Se ha hecho uso de
las instalaciones, de los equipos informticos y de los programas de computacin
de que dispone el Instituto de Fsica Aplicada. En particular, la mayor parte del
trabajo se ha desarrollado bajo el sistema operativo Windows XP, con programas
de edicin de textos basados en LATEX y con entornos de programacin para trabajar
en el lenguaje Java.
Introduccin
13
Clasificacin
El tema principal de la presente Tesis Doctoral, segn la MSC (Mathematics
Subject Classification) 2010 de la AMS (American Mathematical Society) [13] es:
94A60
Cryptography
De acuerdo a la misma clasificacin, a continuacin se enumeran los identificadores de los restantes temas asociados a esta Tesis, junto con la descripcin proporcionada por la AMS.
03D15
11A05
11A07
11A25
11A41
11A51
11G05
11G20
11N05
11N32
11T71
11Y05
11Y11
11Y16
12E20
14G05
14G15
14G50
14H45
14H50
14H52
62B10
68P25
94A05
94A15
94A62
Complexity of computation
Multiplicative structure; Euclidean algorithm; greatest common
divisors
Congruences; primitive roots; residue systems
Arithmetic functions; related numbers; inversion formulas
Primes
Factorization; primality
Elliptic curves over global fields
Curves over finite and local fields
Distribution of primes
Primes represented by polynomials; other multiplicative structure
of polynomial values
Algebraic coding theory; cryptography
Factorization
Primality
Algorithms; complexity
Finite fields
Rational points
Finite ground fields
Applications to coding theory and cryptography
Special curves and curves of low genus
Plane and space curves
Elliptic curves
Information-theoretic topics
Data encryption
Communication theory
Information theory, general
Authentication and secret sharing
14
Introduccin
Estructura
La memoria de esta Tesis Doctoral se ha dividido en ocho captulos, al margen
de la presente introduccin. En los siguientes prrafos se resume el contenido de
cada uno de los captulos.
El Captulo 1 presenta las caractersticas ms destacadas de las tarjetas inteligentes, incluyendo su historia y las circunstancias que motivaron su aparicin, los
diversos tipos de tarjetas inteligentes, sus propiedades fsicas, los principales estndares 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 comunicacin desarrollados para tal
fin.
En el Captulo 2 se exponen las principales caractersticas de la criptografa de
clave pblica y de la basada en curvas elpticas, comenzando por la presentacin
de conceptos y definiciones de los algoritmos criptogrficos de clave pblica ms
extendidos hasta la fecha. A continuacin, se describen las ecuaciones generales
que definen las curvas elpticas, la particularizacin de la teora de curvas elpticas
para cuerpos finitos, las aplicaciones ms importantes de las curvas elpticas en
criptografa y los estndares relacionados con cada una de estas aplicaciones. Este
captulo concluye con un resumen de las principales patentes existentes en ECC.
El Captulo 3 tiene como objetivo presentar las capacidades criptogrficas del
lenguaje Java, en concreto las disponibles en las ediciones Java Standard Edition
y Java Card, para lo cual se ofrece una introduccin a la programacin orientada
a objetos y al lenguaje Java en general, junto con un resumen de las principales
bibliotecas criptogrficas desarrolladas con este lenguaje de programacin. En el
apartado que hace referencia a Java Card, se ha incluido una descripcin detallada
de las caractersticas generales de este sistema operativo y de las peculiaridades de
su modelo de programacin.
En el Captulo 4 se describen de forma completa las distintas variantes de ECIES
incluidas en los estndares ANSI X9.63, IEEE 1363a, ISO/IEC 18033-2 y SECG
SEC 1, identificando las principales diferencias existentes entre los cuatro estndares
mencionados. De forma adicional, se incluye un anlisis de la seguridad de ECIES
que recoge las indicaciones y recomendaciones sugeridas en los estudios ms recientes
sobre este tema.
El Captulo 5 presenta las decisiones de diseo tomadas con el objetivo de desarrollar la implementacin de ECIES en plataformas PC, as como el diagrama de las
clases Java que componen el desarrollo software. El resto del Captulo 5 se encuentra
dedicado a la descripcin funcional completa de esta versin de la aplicacin ECIES,
finalizando con un ejemplo de cifrado y descifrado que ilustra las posibilidades de
utilizacin de la aplicacin.
Introduccin
15
En el Captulo 6 se presenta una implementacin del esquema de cifrado ECIES

para tarjetas Java Card, indicando las particularidades existentes en funcin de la
versin Java Card implementada por las tarjetas inteligentes utilizadas en esta Tesis.
De manera adicional, este captulo incluye la descripcin funcional de la aplicacin
desarrollada para la comunicacin con las tarjetas inteligentes comerciales empleadas
en la Tesis.
El Captulo 7 recoge las pruebas realizadas con las implementaciones de ECIES
para PC y Java Card, utilizando diferentes combinaciones de parmetros y algoritmos en funcin de las posibilidades criptogrficas de cada una de las plataformas
seleccionadas. A fin de analizar los resultados de las pruebas, se ha incluido una
descripcin detallada de las caractersticas de las tarjetas inteligentes empleadas en
dichas pruebas.
Por ltimo, el Captulo 8 presenta las conclusiones derivadas del estudio e implementacin 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 artculos
y presentaciones en congresos como de soluciones ideadas para evitar las distintas
limitaciones detectadas. Por ltimo, se incluyen las posibles lneas de trabajo que
podran seguirse como continuacin de esta Tesis.
Notas de estilo
La presente Tesis Doctoral ha sido redactada utilizando el sistema de composicin de textos LATEX, empleando para ello la distribucin MiKTeX 2.8 y el programa
de edicin WinEdt 5.5. Respecto a la configuracin y las decisiones de estilo en LATEX,
se han consultado numerosas fuentes, aunque las principales han sido [153] para los
aspectos generales de composicin, y [203] para las caractersticas tipogrficas asociadas a la notacin matemtica.
En la elaboracin de la bibliografa, se han seguido principalmente los consejos
sugeridos para la redaccin de tesis doctorales de la Universidad Politcnica de
Madrid [263], que se basan principalmente en las normas ISO 690 [110] y 690-2
[111] (sustituidas en 2010 por una nueva edicin 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 Prez Ortiz [217]
(que a su vez recoge algunas de las indicaciones de Ramn Sol [251]).
El objetivo ha sido componer una bibliografa adaptada en lo posible al estndar ISO y que permitiera una correcta legibilidad. Algunas de las caractersticas
principales del estilo utilizado son:
Escritura del nombre de los autores incluyendo en primer lugar el apellido (o
16
Introduccin
apellidos) en mayscula y posteriormente la inicial (o iniciales) del nombre.
En el caso de empresas o instituciones, se ha intentado mantener el mismo
formato mediante la inclusin del nombre completo en maysculas.
Separacin de los nombres de los autores mediante el carcter punto y coma.
En el caso de existencia de cuatro o ms autores, inclusin nicamente del
primer autor junto al trmino et al. que indica la existencia de autores
adicionales.
Utilizacin de letras maysculas en los ttulos de las obras nicamente en la
primera letra y en los casos necesarios, como por ejemplo los nombres propios
(p. ej. Diffie-Hellman), los acrnimos (p. ej. RSA) o los nombres de algoritmos
o funciones que normalmente se redacten en mayscula (p. ej., Triple Data
Encryption o Elliptic Curve Cryptography).
Utilizacin del nombre de ciudades en su variante castellana en caso de existir
(p. ej., Londres o Nueva York).
Utilizacin de las abreviaturas habituales en la descripcin de las caractersticas de las publicaciones peridicas (vol., num., pp., etc.).
Inclusin de la versin del documento en el caso de estndares o de documentos
electrnicos, empleando el trmino ver. como abreviatura.
Utilizacin del trmino indito para los documentos electrnicos 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 peridicas sin abreviar.
En el caso de las pginas web, inclusin del nombre de la compaa, organismo
o individuo responsable del contenido, as como del ttulo de la pgina.
Inclusin del cdigo asociado al estndar en las normas nacionales e internacionales.
En las patentes, inclusin de los inventores tras el nombre de la empresa (o
individuo) responsable y del ttulo de la patente. Utilizacin de las fechas de
solicitud y confirmacin de la patente, as como del cdigo identificador de la
patente y del pas donde ha sido aprobada.
Inclusin del enlace al documento citado en los casos en los que exista una copia
en formato electrnico 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.
Introduccin
17
A lo largo del texto, se interpretarn los siguientes trminos como se indica a

continuacin [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, adems del mensaje cifrado, los elementos adicionales que posibiliten
la recuperacin del mensaje original (cdigos de autenticacin, claves pblicas,
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 enva,
recibe o manipula informacin.
Tanto la notacin como los trminos del glosario incluidos en esta Tesis han sido
obtenidos a partir de las obras incluidas en la bibliografa.
Captulo 1
Tarjetas inteligentes
Resumen del captulo

Este captulo presenta las caractersticas ms destacadas de las tarjetas
inteligentes, incluyendo su historia y las circunstancias que motivaron
su aparicin, los diversos tipos de tarjetas inteligentes, sus propiedades
fsicas, los principales estndares 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 comunicacin desarrollados para tal fin.
1.1.
Historia de las tarjetas inteligentes
Las tarjetas de plstico se empezaron a utilizar como mtodo de identificacin en

Estados Unidos a partir de los aos 50. La primera de estas tarjetas (Figura 1.1) fue
utilizada por Diners Club [62], y permita al portador de la tarjeta utilizarla para
realizar pagos en un selecto grupo de restaurantes y hoteles que destacaban por
su exclusividad. Poco despus, Visa y MasterCard comenzaron a emitir igualmente
tarjetas de plstico, lo que extendi su uso no slo por Estados Unidos sino tambin
en Europa y a continuacin por el resto del mundo.
Al principio, los mecanismos de seguridad implementados en estas tarjetas de
plstico eran bastante simples (impresiones grficas, firma del cliente, etc.), por
lo que con el paso del tiempo fue necesario mejorar su nivel de seguridad. Esta
necesidad, junto con la reduccin de costes en el proceso de generacin de las tarjetas,
introdujo el uso de la banda magntica (Figura 1.2). Esta banda permita grabar
19
20
Figura 1.1: Diners Club, la primera tarjeta de crdito del mundo
datos que pudieran ser ledos por los lectores apropiados, lo que inicialmente estaba
al alcance nicamente de los usuarios legtimos del sistema. Sin embargo, con el paso
del tiempo la capacidad de leer y modificar el contenido de la banda magntica se
hizo accesible a colectivos al margen de la ley, lo que provoc una nueva evolucin en
las medidas de seguridad. Esta evolucin tuvo lugar en los aos 70 con la introduccin
de los microprocesadores para tarjetas.
Figura 1.2: Tarjeta con banda magntica
La idea de incorporar un circuito integrado a una tarjeta de plstico fue propuesta de forma independiente por Jrgen Dethloff y Helmut Grtrupp en 1968 en
Alemania [59, 60] y por Kunitaka Arimura en 1970 en Japn (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 aos 80 se empezaron
a utilizar tarjetas inteligentes en cabinas telefnicas, y las pruebas de integracin en
telefona mvil 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
aos 80. El xito de esta iniciativa fue tal, que en menos de 10 aos todos los bancos
franceses sustituyeron sus tarjetas con banda magntica 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 aos. Entre los entornos de
utilizacin actuales ms destacados pueden citarse los siguientes:
1.1. Historia de las tarjetas inteligentes
21
Tarjetas de identificacin de ciudadanos (por ejemplo, DNIe de Espaa a partir

de 2006 [176], Figura 1.3).
Figura 1.3: Prototipo de D.N.I. electrnico de Espaa
Sistema de telefona mvil digital GSM y UMTS (Universal Mobile Telecommunication System), donde toma el papel de mdulo de identificacin 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 Telefnica movistar
Aplicaciones bancarias como el monedero electrnico, 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
22
Sanidad, donde funciona como un archivo de los aspectos ms relevantes del
historial mdico de un paciente, realizando la identificacin 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 Repblica Federal Alemana
Control de acceso a edificios, con sistemas avanzados que pueden llegar a incluir
elementos biomtricos. 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 plstico, en general de tamao 85.60

53.98 mm2 , que contiene como elemento diferenciador (tal como se muestra en la
Figura 1.8) un componente electrnico denominado chip que controla el acceso a los
datos almacenados en l.
Tal como puede apreciarse en la Figura 1.9, el chip consta bsicamente 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
voltiles utilizados durante una determinada sesin de trabajo, una memoria no

voltil 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 comunicacin de todos los elementos mencionados
y buses externos para la comunicacin de la tarjeta inteligente con el dispositivo
lector a travs de los contactos [65].
Figura 1.9: Diagrama de bloques de una tarjeta inteligente
Los datos almacenados en la memoria EEPROM slo son accesibles a travs

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 ejecucin de cada comando, es posible garantizar niveles elevados
de proteccin de los datos frente a ataques externos. Otros tipos de memoria no
voltil menos utilizados son Flash EEPROM, EPROM (Erasable Programmable
Read Only Memory) o FRAM (Ferroelectric Random-Access Memory).
24
Por otra parte, el chip que incluyen las tarjetas inteligentes se encapsula de tal
forma que quede igualmente protegido contra accesos mediante tcnicas electromagnticas que no precisen contacto fsico con la tarjeta. La tecnologa de fabricacin
de estos chips ha ido evolucionando con el paso del tiempo, pasando por tecnologas
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 tecnologa
de fabricacin hace referencia a la mnima resolucin de la maquinaria responsable
de integrar sus circuitos mediante tcnicas de litografa, ya que la correspondencia
entre tecnologa de integracin y distancia de integracin dej de verificarse a partir
de la tecnologa de 0.25 m [261]. En cuanto a la arquitectura de los microprocesadores, sta puede variar desde los 8 bits en las tarjetas ms bsicas hasta los 32 bits
utilizados para las aplicaciones ms complejas.
Para la fabricacin de las tarjetas inteligentes se parte de una oblea de silicio que
contiene mltiples 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 aade entonces una
resina protectora que asla al chip de la humedad, formando el elemento denominado
micromdulo.
El plstico, fabricado de forma independiente, es rebajado en la posicin donde
se alojar el chip, de forma que d cabida al mismo bajo los contactos sin daarse.
Utilizando tcnicas de pegado mediante combinacin de calor y presin, el micromdulo se coloca en el hueco formado en el plstico, 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
1.3.
1.3.1.
25
Tipos de tarjetas inteligentes

Tarjetas de memoria
Las primeras tarjetas inteligentes producidas en grandes cantidades fueron las

tarjetas de memoria, aunque podra considerarse que estas tarjetas no son plenamente 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 lgica no programable.
Las tarjetas de memoria suelen contener de 1 a 4 KBytes de informacin. Se
utilizan principalmente en cabinas telefnicas y para la compra de bienes y servicios
de pequeo 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 crdito, ya no se podr volver a utilizar.
1.3.2.
Tarjetas con microprocesador
En comparacin con las tarjetas de memoria, las tarjetas con microprocesador

permiten establecer una mayor diferenciacin segn algunas de sus caractersticas.
Por ejemplo, dependiendo de si existe contacto fsico entre la tarjeta y el lector, se
puede distinguir entre tarjetas con y sin contactos. Asimismo, si la tarjeta incorpora
un coprocesador matemtico para ayudar en el clculo de operaciones criptogrficas,
nos estaremos refiriendo a tarjetas con coprocesador matemtico en comparacin con
las tarjetas ms habituales que no incorporan este coprocesador.
1.3.2.1.
Tarjetas con contactos
Las tarjetas con contactos representan el tipo de tarjeta ms extendido en la

actualidad, gracias sobre todo a su presencia en los telfonos mviles 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 fsico entre la tarjeta y el lector. Aunque los estndares
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 utilizacin de los tres contactos restantes.
26
En la Figura 1.11 se pueden observar de forma grfica 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 funcin de cada contacto es la siguiente:

Vcc: proporciona alimentacin al chip. Los voltajes admisibles son 1.8 V, 3 V
5 V, con una desviacin mxima del 10 %.
RST: este contacto se utiliza para resetear el microprocesador, procedimiento
denominado warm reset. En comparacin, el procedimiento cold reset consiste
en detener la alimentacin del chip para reanudarla posteriormente.
CLK: puesto que las tarjetas inteligentes no poseen un generador interno de
la seal de reloj, necesitan recibir a travs de este contacto la seal externa de
reloj.
GND: este contacto se utiliza para el voltaje de referencia (valor de cero voltios).
Vpp: el contacto Vpp es opcional y slo se utiliza para programar la memoria
EEPROM en tarjetas antiguas.
I/O: este contacto permite la transmisin de datos entre la tarjeta y el lector
en modo half-duplex, de manera que la informacin slo puede ser transmitida
en un sentido en cada momento.
Actualmente se encuentra en proceso de estandarizacin el futuro uso de los
contactos Vpp y RFU para la implementacin 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 comunicacin entre la tarjeta y la antena externa que
permita su uso en entornos contactless.
1.3. Tipos de tarjetas inteligentes

1.3.2.2.
27
Tarjetas sin contactos
En comparacin con las tarjetas del apartado anterior, las tarjetas sin contactos
no necesitan contacto fsico con otro elemento, ya que se comunican con el lector
mediante ondas electromagnticas de manera similar a la utilizada en la tecnologa
RFID (Radio Frequency Identification) [40]. La distancia entre la tarjeta y el lector
depende del tipo de tarjeta, pero en general vara desde unos pocos centmetros
hasta un metro.
La Figura 1.12 muestra el diagrama de una tarjeta sin contactos, as como del
lector necesario para acceder a la informacin de la tarjeta.
Figura 1.12: Esquema de una tarjeta inteligente sin contactos
El estndar de tarjetas sin contacto ms extendido es el ISO/IEC 14443 (ver

1.5.2), el cual emplea tcnicas de acoplamiento magntico con una frecuencia de
13.56 MHz y tiene un alcance de hasta 10 cm. Si a una tarjeta de este tipo se le
aaden los contactos como va complementaria de comunicacin, entonces se trata
de una tarjeta de interfaz dual.
La principal aplicacin de las tarjetas contactless son el pago de pequeas cantidades (tarjetas monedero) y el control de acceso (edificios, transporte pblico, etc.),
donde la rapidez y el carcter local de las transacciones son las caractersticas principales. De manera ms general, sin el requisito de adoptar la forma de una tarjeta
inteligente, la tecnologa sin contactos puede encontrarse en multitud de herramientas de logstica y seguridad, como por ejemplo los nuevos pasaportes. De hecho,
desde agosto de 2006 todos los pasaportes espaoles que se expiden corresponden al
28
denominado pasaporte electrnico (pasaporte-e), el cual incorpora un chip embebido

en su portada posterior que incluye informacin sobre su titular [177].
1.3.3.
Tarjetas con coprocesador
Las tarjetas inteligentes utilizadas en entornos de seguridad normalmente incluyen un coprocesador de apoyo al procesador principal. Los coprocesadores son
circuitos integrados especializados en los clculos de aritmtica modular y la gestin
de enteros de gran tamao, lo que permite liberar de este trabajo al procesador
principal. El uso de coprocesadores permite que ciertas operaciones criptogrficas,
que en otras tarjetas tardaran varios minutos en realizarse, puedan ser completadas
en pocos segundos.
La inclusin de coprocesadores aumenta el precio final de las tarjetas inteligentes, motivo por el cual en algunos entornos (como el de las telecomunicaciones) su
presencia sea actualmente minoritaria.
1.4.
Propiedades fsicas y elctricas
Las principales caractersticas fsicas de las tarjetas inteligentes son su tamao

y composicin. 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 terminologa de ETSI y 3GPP), y
un formato adicional utilizado en telefona mvil y definido por ETSI en el estndar
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 fcilmente reconocible debido a
que coincide con el formato de las tarjetas de crdito. 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 tamao 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 tradicionalmente en el interior de los telfonos mviles. La Figura 1.15 incluye sus dimensiones
estandarizadas.
Por ltimo, el formato Micro-UICC (Figura 1.16) es el ms pequeo de los cuatro,
y est especialmente diseado para nuevos dispositivos que deseen liberar espacio
fsico para otros componentes, como por ejemplo el iPad Wi-Fi + 3G o el iPhone 4,
ambos de Apple [21].
En cuanto a su composicin, existen varias alternativas en funcin del plstico
1.4. Propiedades fsicas y elctricas
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)
29
30
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 comienza 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 qumicos.
PC (Policarbonato): presenta un rango de uso desde -100 C a +135 C, con un
punto de fusin cercano a 250 C.
PET (Polietileno Tereftalato): se trata de un plstico con un alto grado de
cristalinidad muy utilizado en envases de bebidas y textiles como sustituto del
PVC.
En lo relativo a sus caractersticas elctricas, tal como se ha anticipado anteriormente, 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 grfica tanto el voltaje asociado a cada clase
como la frecuencia de la seal 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 deber situarse obligatoriamente entre 1 y 5 MHz). Como aclaracin, la frecuencia de
1.5. Estndares
31
Figura 1.17: Diagrama de voltajes admisibles
trabajo del procesador no siempre coincide con la frecuenta suministrada por el dispositivo lector, ya que las tarjetas pueden implementar divisores o multiplicadores
para ajustar la frecuencia interna [226].
Para ms informacin sobre las caractersticas fsicas y lgicas de las tarjetas
inteligentes, se recomienda consultar el libro de Rankl y Effing [226].
1.5.
1.5.1.
Estndares
La norma ISO/IEC 7816
ISO/IEC 7816 es un estndar internacional relacionado con las tarjetas de identificacin electrnicas, en especial las tarjetas inteligentes, creado conjuntamente por
la Organizacin Internacional de Normalizacin (ISO) y la Comisin Electrotcnica
Internacional (IEC), y que se encuentra gestionado por el Comit Tcnico Conjunto
(JTC) 1/Subcomit (SC) 17 [139].
La norma ISO/IEC 7816, que se desglosa a su vez en varias partes, describe los
parmetros 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. Ms especficamente, las partes que componen la norma
son:
Parte 1 [113]: especifica las caractersticas fsicas de las tarjetas, en cuanto al
tamao del plstico, su grosor, etc.
Parte 2 [114]: engloba todos los elementos que definen las dimensiones y la lo-
32
calizacin de los contactos. Igualmente, especifica la funcin que debe cumplir
cada uno de estos contactos.
Parte 3 [115]: define las seales elctricas y los protocolos de transmisin halfduplex de caracteres(denominado T=0) y bloques (T=1) que se utilizan sobre
la interfaz ofrecida a travs de los contactos. As, todos los voltajes, intensidades mximas de corrientes, convenciones de paridad, velocidades de transmisin y otros parmetros relacionados con las seales se definen en esta parte
de la norma.
Parte 4 [116]: especifica los comandos para el intercambio de informacin entre el exterior y el circuito integrado de la tarjeta. Estos comandos deben ser
respetados por los fabricantes de tarjetas para garantizar el correcto funcionamiento de tarjetas de diferentes fabricantes. De manera adicional, esta parte
del estndar tambin define la estructura lgica 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 numeracin utilizados en
el entorno de las tarjetas inteligentes, as como el procedimiento de registro
para identificadores de aplicacin.
Parte 6 [118]: especifica los elementos de datos utilizados (nombre, descripcin,
formato, codificacin y diseo), as como los medios de recuperacin 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 gestin 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 mtodos para proporcionar seguridad en la interfaz
entre la tarjeta y el exterior.
Parte 9 [121]: define los comandos para la gestin de ficheros (por ejemplo,
la creacin 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 cmo
controlar la carga segura de datos en las tarjetas.
Parte 10 [122]: este documento especifica las seales elctricas y el ATR (Answer to Reset) de las tarjetas sncronas.
Parte 11 [123]: especifica el uso de los comandos y de los datos relacionados con
la verificacin de la identidad de una persona a travs de mtodos biomtricos.
1.5. Estndares
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 estn importados de
la norma ISO/IEC 19785-1 [138].
Parte 12 [124]: define las condiciones de funcionamiento de una tarjeta inteligente travs de la interfaz USB. A estas tarjetas se las denomina USB-ICC
(Integrated Circuit Card).
Parte 13 [125]: especifica los comandos para la gestin de aplicaciones en entornos multiaplicacin. 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
prctico.
Parte 15 [126]: define una aplicacin que contiene informacin sobre la funcionalidad criptogrfica. Adems, especifica una sintaxis comn en ASN.1 (Abstract Syntax Notation One) y tanto el formato de codificacin de la informacin
como los mecanismos para compartir esta informacin.
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 modulacin empleado y los detalles del protocolo de inicializacin. Las partes que constituyen esta norma son:
Parte 1 [132]: especifica las caractersticas fsicas de las tarjetas.
Parte 2 [133]: define los campos magnticos que deben utilizarse tanto para
proporcionar potencia a la tarjeta como para establecer la comunicacin entre
lector y tarjeta.
Parte 3 [134]: especifica el protocolo y los comandos para establecer la comunicacin entre un lector y varias tarjetas, incluyendo las tcnicas para evitar
colisiones en la transmisin.
Parte 4 [135]: incluye los detalles del protocolo half-duplex de bloques (denominado 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 Telecommunications Standards Institute) y transferida posteriormente a la organizacin 3GPP
34
(3rd Generation Partnership Project) [1, 6], define la interfaz entre la tarjeta SIM
y el telfono mvil durante la fase de operacin en red del sistema GSM, as como
la organizacin interna de la informacin en la tarjeta. Mediante esta especificacin,
se asegura la correcta interoperabilidad entre la tarjeta y el terminal, independientemente de los fabricantes de ambos dispositivos.
Entre otros detalles, la norma TS 11.11 especifica:
Los requisitos fsicos a cumplir por la tarjeta SIM en cuanto a seales elctricas
y protocolos de transmisin.
El modelo lgico a utilizar como base para el diseo de la estructura de ficheros
de la tarjeta SIM.
Las funciones de seguridad, haciendo hincapi en el proceso de autenticacin
del usuario frente a la red.
Los comandos y sus respectivas respuestas a transmitir entre el telfono mvil
y la tarjeta SIM.
Los contenidos en detalle de los ficheros para su utilizacin en redes GSM.
Dentro de las caractersticas fsicas se definen dos formatos, conocidos como ID-1
(tamao tarjeta de crdito) y plug-in o mini-SIM (formato de inferior tamao para
poder utilizar la tarjeta dentro de los telfonos mviles, equivalente al formato ID000 del estndar ISO/IEC 7816). En ambos casos, las caractersticas fsicas deben
cumplir los requisitos expresados en la normas ISO 7816-1 y 7816-2, a menos que se
especifique lo contrario.
A nivel elctrico se mantienen los requisitos de la norma 7816-3, aunque en este
caso el nico protocolo obligatorio es T=0, el protocolo semi-dplex asncrono y
orientado a byte [97].
Por ltimo, respecto a la estructura de ficheros, stos se organizan de forma
jerrquica. Existen tres tipos de ficheros elementales: transparentes (secuencia de
bytes sin organizacin interna), lineales con longitud de registro fija (secuencia de
registros todos con la misma longitud) y cclicos con longitud de registro fija (similares a los lineales, con la diferencia de que los registros se sobrescriben por orden
de antigedad).
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 mvil para
la comunicacin con aplicaciones SIM Application Toolkit (en adelante STK) y
la realizacin de servicios avanzados. STK proporciona mecanismos que permiten
a las aplicaciones residentes en la tarjeta SIM interactuar y operar con cualquier
telfono mvil 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 caractersticas como parte del proceso de inicializacin de la SIM, y que
permite a las aplicaciones STK conocer exactamente qu servicios del terminal
podrn 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 limitacin del protocolo T=0, donde la comunicacin slo puede
ser iniciada por el terminal.
Data Download : mecanismo por el que un servidor puede enviar datos a una
aplicacin de la tarjeta SIM, utilizando distintos servicios portadores como
los mensajes cortos SMS (Short Message Service) o la difusin CBS (Cell
Broadcast Service).
La norma TS 11.14, de aplicacin en las tarjetas SIM de la telefona 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 definicin para entornos UMTS.
1.5.4.
Las normas Global Platform
En relacin con sus actividades como uno de los principales emisores de tarjetas
del mundo, Visa International cre la especificacin Visa Open Platform, la cual
define una interfaz interna para la gestin de mltiples aplicaciones dentro de una
misma tarjeta inteligente. Desde 1999, este trabajo es gestionado por la organizacin GlobalPlatform, por lo que sus documentos pasaron a denominarse simplemente
especificaciones Global Platform. Actualmente existen tres comits dentro de GlobalPlatform encargados especficamente de las tarjetas inteligentes, los dispositivos
de lectura y los sistemas de gestin de la informacin relacionada.
El conjunto de requisitos definidos en los documentos Global Platform son independientes del sistema operativo de la tarjeta, aunque en la prctica se haya
convertido en el estndar por defecto para la carga y gestin de aplicaciones en tarjetas Java Card. La Figura 1.18 muestra la arquitectura bsica 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
36
Figura 1.18: Arquitectura Global Platform
las aplicaciones desarrolladas para tarjetas con sistemas operativos propietarios se

almacenan en cdigo nativo (compilado en el lenguaje mquina del procesador de
destino), mientras que las aplicaciones para tarjetas con sistemas operativos abiertos se compilan en un cdigo no nativo que debe ser interpretado por el sistema
operativo.
Los sistemas operativos propietarios ofrecen como ventaja un mayor rendimiento en la ejecucin de las aplicaciones, pero a cambio una aplicacin 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 introduccin a los principales sistemas operativos
abiertos para tarjetas inteligentes.
1.6.1.
Tarjetas Java Card
Puesto que el lenguaje de programacin Java es objeto de un estudio detallado en el Captulo 3, de momento nicamente se mencionar el hecho de que Java
Card es actualmente el sistema operativo abierto de mayor difusin en los principales entornos comerciales de tarjetas inteligentes [210]. La Figura 1.19 muestra la
arquitectura bsica 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 multiaplicacin controlado por el MULTOS

Consortium (tambin 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 sita
una mquina virtual. Esta mquina virtual proporciona los siguientes elementos: un
entorno de ejecucin 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 pretenda convertirse en una alternativa a Java Card. Sin embargo,
pocos aos despus Microsoft cancel el proyecto debido a la escasa acogida que
haba tenido este sistema operativo, principalmente debido a que sus competidores
Java Card y MULTOS ya contaban para entonces con una base lo suficientemente
slida de clientes en sus respectivas industrias.
WSC era un sistema operativo multiaplicacin que permita el desarrollo de
aplicaciones en los lenguajes C y Basic utilizando las herramientas de desarrollo
38
Figura 1.20: Arquitectura MULTOS
propias de Microsoft.
1.7.
1.7.1.
Arquitecturas de acceso a las tarjetas inteligentes desde PC

Arquitectura OpenCard Framework
El trmino OpenCard Framework (OCF) hace referencia a un estndar desarrollado por un consorcio industrial (entre cuyos miembros figuraban mayoritariamente
fabricantes de tarjetas inteligentes, ver Figura 1.21) que proporciona una arquitectura interoperable para la comunicacin con dispositivos lectores y tarjetas inteligentes
disponible en varias plataformas software y hardware. Se trata, por tanto, de un estndar abierto que incluye un conjunto de API (Application Programming Interface)
para posibilitar el desarrollo de aplicaciones mediante la programacin en el lenguaje
Java.
OCF est diseado para funcionar en cualquier plataforma Java, como por ejemplo 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 versin 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 fsicos
para los que los fabricantes han creado los controladores apropiados. Tambin
incluye las API para los terminales PS/SC soportados. Este mtodo 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 travs de card services. Cada servicio define una interfaz de alto
nivel que puede emplearse para acceder a determinadas funciones particulares,
siendo el ejemplo ms representativo FileAccessCardService para la gestin
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 interrelacin entre los distintos 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
aplicacin externa a la tarjeta, para lo que se emplea un lector de tarjetas. La
aplicacin enva un comando CommandAPDU a la tarjeta pasndolo al driver del lector,
quien a su vez lo reenva a la tarjeta. Como respuesta, la tarjeta enva un comando
ResponseAPDU que el driver entrega a la aplicacin.
Las funciones de una tarjeta estn determinadas por el conjunto de APDU que
es capaz de interpretar. A pesar de los estndares existentes, el rango de comandos
que entiende cada tarjeta depende en cierta medida del fabricante en cuestin. De
igual manera, cada lector de tarjetas tiene distintas funcionalidades, desde el lector
ms simple con un nico slot o ranura a los ms complejos que incluyen accesorios de
identificacin biomtrica. El problema de nuevo es la inexistencia de un nico driver
40
Figura 1.22: Elementos de la arquitectura OCF
para acceder a los servicios del lector de tarjetas. Sin embargo, gracias a estndares
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 publicacin de su versin 1.2, quedando su tecnologa obsoleta tras la aparicin del API Java Smartcard I/O [211],
aunque todava puede encontrarse informacin en forma de proyectos evolucionados
a partir de OCF como Open Smart Card Development Platform (OpenSCDP) [39]
o de repositorios de la informacin original en Sourceforge [252].
1.7.2.
Arquitectura PC/SC
El entorno PC/SC constituye un intento equivalente a OCF para desarrollar

un estndar que permita la interoperabilidad de dispositivos lectores y tarjetas in-
1.8. Comunicacin con la tarjeta inteligente
41
teligentes en el entorno PC, habiendo participado en su creacin 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 diseada para funcionar nicamente sobre sistemas operativos de Microsoft
(Windows 95/98/NT/2000/XP/Vista/7), mientras que OCF funciona sobre cualquier sistema donde exista una implementacin 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 comunicacin entre el PC y el dispositivo lector,
as como entre dicho dispositivo y la tarjeta. Muchos de los niveles mostrados no son
fsicos, sino que se trata de niveles software, como la aplicacin 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 comunicacin con el lector. De esta manera, adems de los lectores de tarjetas compatibles con OCF, las aplicaciones desarrolladas
en plataformas Windows pueden beneficiarse de la utilizacin 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 fsicamente 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 ejecucin del programa, gracias a que las
clases necesarias son cargadas por la mquina virtual dinmicamente en el momento
de su utilizacin.
Para ms informacin se recomienda consultar la pgina web del PC/SC Workgroup [216].
1.8.
Comunicacin con la tarjeta inteligente
En las tarjetas Java Card es posible utilizar dos modelos de comunicacin diferentes. Por una parte se encuentra el modelo basado en APDU; por otra, el esquema
que emplea la tecnologa JCRMI (Java Card Remote Method Invocation), que es
un subconjunto del modelo RMI (Remote Method Invocation) presente en Java.
El modelo de comunicacin que se muestra en la Figura 1.24 representa el mecanismo ms extendido para la comunicacin 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 aplicacin externa y la tarjeta. El sistema operativo de la tarjeta se encarga de analizar las APDU recibidas
y de encaminarlas a la aplicacin adecuada a la que van destinadas, recogiendo la
42
Figura 1.23: Elementos de la arquitectura PC/SC
43
respuesta de la aplicacin para su envo al lector de tarjetas (y con ello, a la aplicacin que se comunica con el propio lector, ya sea un programa en un ordenador, el
sistema operativo de un telfono mvil, etc.).
Figura 1.24: Modelo de comunicacin con la tarjeta inteligente
La comunicacin 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 tambin 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
44
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 especificacin ISO/IEC 7816-4 incluye los valores CLA vlidos para su utilizacin,
tal como aparecen en el Cuadro 1.1.
CLA
0x0n, 0x1n
0x20 - 0x7F
0x8n, 0x9n
0xAn
0xB0 - 0xCF
0xD0 - FE
0xFF
Tipo de instruccin
Instrucciones estndar 7816-4
Reservado
Instrucciones 7816-4 especficas para aplicaciones
Instrucciones especficas de aplicacin o fabricante
Reservado para seleccin de tipo de protocolo
Cuadro 1.1: Valores del byte CLA permitidos
INS (1 byte): este campo obligatorio sirve para indicar una instruccin especfica dentro de la clase representada por el campo CLA. El estndar ISO/IEC
7816-4 especifica las instrucciones bsicas para acceder a los datos de una
tarjeta cuya estructura interna est implementada de acuerdo al estndar. El
Cuadro 1.2 presenta algunas de las instrucciones ISO/IEC 7816 ms tpicas.
P1 (1 byte, obligatorio): este campo define el primer parmetro asociado a la
instruccin. Se puede utilizar para dar ms informacin sobre la instruccin,
o bien como dato de entrada.
P2 (1 byte, obligatorio): este campo define el segundo parmetro asociado a
la instruccin. Al igual que en el caso anterior, se puede utilizar para dar ms
informacin sobre la instruccin, o como dato de entrada.
Lc (1 byte, opcional): este valor representa el nmero de bytes del campo de
datos del comando. Puesto que el valor mximo es 0xFF, la longitud mxima
de los datos es de 255 bytes, aunque algunas tarjetas permiten enviar datos de
256 bytes de longitud utilizando el valor 0x00.
Data (tamao variable, opcional): este campo incluye los datos del comando.
Le (1 byte, opcional): este campo indica el mximo nmero 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 comando, y de si es necesaria una respuesta, existen cuatro variantes del comando

INS
0E
20
70
82
84
88
A4
B0
B2
C0
C2
CA
D0
D2
D6
DA
DC
E2
45
Nombre de la instruccin
Erase Binary
Verify
Manage Channel
External Authenticate
Get Challenge
Internal Authenticate
Select File
Read Binary
Read Record
Get Response
Envelope
Get Data
Write Binary
Write Record
Update Binary
Put Data
Update Record
Append Record
Cuadro 1.2: Valores del byte CLA permitidos
APDU, tal como puede comprobarse en la Figura 1.26. De forma habitual, las aplicaciones utilizan varios comandos APDU con distintas estructuras de datos durante
su ejecucin.
Figura 1.26: Posibles estructuras de un comando APDU
46
1.8.2.
APDU de tipo respuesta
El formato de una respuesta APDU es mucho ms 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, carcter opcional): este campo contiene los datos devueltos por la aplicacin de
la tarjeta.
SW1 (1 byte, obligatorio): este campo constituye el primer byte de estado,
que proporciona informacin general sobre el resultado de la ejecucin del
comando.
SW2 (1 byte, obligatorio): este campo constituye el segundo byte de estado,
que proporciona informacin adicional a la ofrecida por el primer byte de
estado.
Los valores posibles para los bytes de estado estn definidos en la especificacin
ISO 7816-4. La Figura 1.28 muestra de forma grfica la clasificacin de los posibles
bytes de estado.
Figura 1.28: Posibles cdigos de respuesta
47
Captulo 2
Criptografa de clave pblica basada
en curvas elpticas
Resumen del captulo

En este captulo se exponen las principales caractersticas de la criptografa de clave pblica y de la basada en curvas elpticas, comenzando
por la presentacin de conceptos y definiciones de los algoritmos criptogrficos de clave pblica ms extendidos hasta la fecha. A continuacin,
se describen las ecuaciones generales que definen las curvas elpticas, la
particularizacin de la teora de curvas elpticas para cuerpos finitos, las
aplicaciones ms importantes de las curvas elpticas en criptografa y los
estndares relacionados con cada una de estas aplicaciones. Este captulo
concluye con un resumen de las principales patentes existentes en ECC.
2.1.
Introduccin
Criptologa es el nombre genrico que engloba dos disciplinas opuestas y a la vez

complementarias: criptografa y criptoanlisis. La criptografa se ocupa del diseo
de procedimientos para el cifrado y descifrado de la informacin, mientras que el
criptoanlisis se encarga del estudio de los mtodos para obtener la informacin original sin tener acceso a los datos secretos requeridos en el funcionamiento normal de
los algoritmos criptogrficos. Ambas disciplinas se han desarrollado habitualmente
de forma paralela, puesto que cualquier mtodo de cifrado siempre lleva aparejada
su correspondiente tcnica de criptoanlisis [78].
49
50
La criptografa como medio para proteger la informacin es un arte tan antiguo

como la propia escritura. Hasta el siglo pasado, la nica tcnica utilizada era la
criptografa de clave simtrica, donde la clave de cifrado coincide con la de descifrado, 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
simtrico, principalmente su eficiencia y robustez, la necesidad de disponer de una
clave para cada par de usuarios representa una gran limitacin, siendo un elemento
especialmente crtico en los sistemas informticos distribuidos. Frente a este problema, la solucin consiste en utilizar criptografa de clave pblica o asimtrica, donde
por su naturaleza cada usuario dispone de una clave privada y una clave pblica,
de manera que precisamente esta clave pblica pueda ser distribuida sin que ello
represente un riesgo para la integridad del sistema.
La finalidad de la criptografa de clave pblica es mltiple, y puede definirse
mediante las siguientes caractersticas:
Confidencialidad o privacidad: nicamente los usuarios autorizados deben ser
capaces de acceder a la informacin que se desea proteger.
Integridad: capacidad de verificacin de que un mensaje no ha sido alterado
en su transmisin desde el emisor hasta el receptor.
Autenticacin: 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 autora de un mensaje.
Desde que en 1976 Diffie y Hellman [61] introdujeron el concepto de criptografa
de clave pblica, esta rama de la criptografa ha tenido una vertiginosa evolucin,
lo que ha generado la aparicin tanto de algoritmos criptogrficos como de tcnicas
de criptoanlisis de una creciente complejidad. Tal como se adelant en la Introduccin, los problemas matemticos utilizados actualmente por los criptosistemas ms
extendidos son:
Factorizacin de enteros (IFP)
Dado un nmero entero positivo , el problema de la factorizacin de enteros,
denominado IFP (Integer Factorization Problem), consiste en determinar su
factorizacin en nmeros primos [172]. Es decir, expresar el nmero de la
1 2
forma =
1 2 , donde los valores representan nmeros primos
distintos, cada uno con orden de multiplicidad 1.
Logaritmo discreto (DLP)
Dado el conjunto de los nmeros enteros mdulo un nmero primo , un
generador del grupo multiplicativo y un elemento , el problema del
2.2. Aplicaciones de la criptografa de clave pblica
51
logaritmo discreto, denominado DLP (Discrete Logarithm Problem), consiste

en encontrar el entero que cumpla la condicin (mod ) siendo
0 2 [172].
Logaritmo discreto en curvas elpticas (ECDLP)
Dada una curva elptica definida sobre el cuerpo finito (donde es un
nmero primo o una potencia de 2), un subgrupo de orden de los puntos de
la curva que sea finito y cclico, un punto de la curva que sea generador del
subgrupo cclico y un punto perteneciente a dicho subgrupo, el problema del
logaritmo discreto aplicado a una curva elptica, denominado ECDLP (Elliptic
Curve Discrete Logarithm Problem), consiste en encontrar el nmero entero
tal que = [99].
2.2.
Aplicaciones de la criptografa de clave pblica
En base a las caractersticas de confidencialidad, integridad, autenticacin y no

repudio, es posible dividir las aplicaciones prcticas de la criptografa de clave pblica
en tres grandes grupos: establecimiento de clave, firma digital y cifrado/descifrado.
Establecimiento de clave
Firma digital
Aplicaciones prcticas
Cifrado/descifrado
2.2.1.
Los esquemas de establecimiento de clave tienen como objetivo que dos o ms

entidades que se comunican a travs de una red abierta (y posiblemente insegura)
lleguen a compartir una clave secreta con la que pueda proporcionarse confidencialidad 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
Acuerdo de clave
52
En la prctica, existen ms 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 (pblica y privada) de uso temporal,
generadas a propsito para dicha comunicacin, mientras que en los esquemas de
transporte de clave, el usuario que inicia la comunicacin debe conocer la clave
pblica permanente del otro usuario (o al menos, lo suficientemente permanente
para que no haya sido sustituida por una clave pblica diferente desde su ltima
comunicacin).
Los esquemas de establecimiento de clave ms 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
ms informacin sobre el protocolo ECDH.
2.2.2.
Firma digital
La firma digital tiene como objetivo cumplir los objetivos de integridad, autenticacin y no repudio, de manera que una firma electrnica sea equivalente a una
firma manuscrita en cualquier transaccin [78, 172]. Desde el punto de vista tcnico
y de forma simplificada, una firma digital es el resultado de cifrar la salida obtenida mediante una funcin resumen de una determinada informacin, de manera
que cualquier usuario pueda verificar la identidad de la persona que firm los datos
y garantizar que la informacin objeto de la comprobacin no ha sido modificada
desde su firma.
Las firmas digitales pueden dividirse en dos grupos: con anexo y con recuperacin
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 comprobacin de la firma. Por
el contrario, en las firmas digitales con recuperacin del mensaje, el propio mensaje
se extrae del contenido de la firma.
Firma digital
Con anexo
Con recuperacin 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 ms
informacin sobre el algoritmo ECDSA en 2.6.8.2.
2.2. Aplicaciones de la criptografa de clave pblica
2.2.3.
53
Cifrado/descifrado
Los criptosistemas de clave pblica tienen como objetivo cifrar el contenido de la

informacin a transmitir de manera que sta slo pueda ser descifrada por un usuario legtimo. Para ello, de forma genrica dichos usuarios deben seguir el siguiente
procedimiento:
1. Preparacin 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
comunicacin posterior.
2. Comprobaciones previas y obtencin de claves
Una vez decididas las claves asimtricas a utilizar, el usuario que enviar el
mensaje cifrado debe conseguir la clave pblica del usuario receptor del criptograma, comprobando a continuacin 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 pblica 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
informacin original.
En principio, los criptosistemas de clave pblica permiten cifrar cualquier tipo
de informacin. Sin embargo, en la prctica se suelen utilizar para cifrar una clave
simtrica, la cual ser posteriormente utilizada para garantizar la confidencialidad
en la comunicacin entre los usuarios mediante el uso de un algoritmo de cifrado
simtrico, 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, adems de
constituir un subconjunto de los esquemas de establecimiento de clave [99].
Los criptosistemas de clave pblica ms conocidos son RSA [229], ElGamal [69]
y ECIES (Elliptic Curve Integrated Encryption Scheme) [16, 8, 109, 136]. Se ofrece
ms informacin sobre el algoritmo ECIES en 2.6.8.3 y en el Captulo 4.
En 2.4 se describirn de forma detallada las caractersticas tcnicas de los esquemas de cifrado y establecimiento de clave ms conocidos en criptografa de clave
pblica, y que constituyen los antecedentes naturales del esquema de cifrado ECIES.
54
2.3.
Seguridad en criptosistemas de clave pblica
En el estudio de la seguridad de los criptosistemas, existen dos conceptos que

son fundamentales y que representan las caractersticas que sera deseable encontrar
en cualquier criptosistema: la seguridad semntica y la no maleabilidad [25, 27, 224].
Seguridad semntica fue un concepto establecido por Goldwasser y Micali [93] en
1982, y consiste en la incapacidad de un atacante para obtener informacin alguna
sobre el texto sin cifrar a partir del mensaje cifrado y de la clave pblica
de cifrado. Goldwasser y Micali demostraron posteriormente [94] la equivalencia
entre seguridad semntica 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 informacin sin cifrar. Por
lo tanto, la caracterstica 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 estn 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
segn los mtodos empleados y el material al que tenga acceso el atacante. En una
primera clasificacin, 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 legtimos, se limita a obtener informacin del
canal, por lo que su objetivo principal es comprometer la confidencialidad de
la comunicacin.
Ataques activos: un atacante activo es aquel que, adems de recuperar los
criptogramas del canal de comunicacin, trata de borrar, introducir o alterar
de alguna forma las transmisiones realizadas por los participantes. El objetivo
de este tipo de atacante es mltiple, ya que adems de comprometer la confidencialidad 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 informacin a disposicin del atacante [172], de manera que en algunos casos se
podr suponer que el adversario cuenta con acceso a un orculo, elemento que puede
ser interpretado como una caja negra que se encarga de cifrar o descifrar mensajes
elegidos por el atacante, pero sin revelar ningn tipo de informacin adicional. Por
supuesto, estas mquinas ideales no existen en la prctica, pero a efectos de modelar
2.3. Seguridad en criptosistemas de clave pblica
55
la seguridad de un criptosistema tienen un papel muy importante en la definicin

de los tipos de ataques y en la evaluacin de la seguridad de los criptosistemas
[172, 224].
Los principales tipos de ataques pasivos, en funcin de los recursos al alcance
del atacante [172], son:
Ataque con texto en claro conocido (Known Plaintext Attack o KPA): el atacante 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 mnimo, un algoritmo que le permita obtener el texto en claro de posteriores 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 eleccin. Para ello, es posible suponer que el
atacante hace uso de un orculo de cifrado que puede utilizar durante un cierto
tiempo, con la restriccin de que en ningn caso el atacante podr obtener
del orculo 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 informacin obtenida de los procesos
de cifrado anteriores. El objetivo en este tipo de ataque es igual que en los CPA.
Ataque con slo texto cifrado (Ciphertext-Only Attack o COA): el atacante
slo tiene acceso a una coleccin de textos cifrados, y su objetivo consiste en
obtener los mensajes en claro o, mejor an, la clave de descifrado.
Ataque con texto cifrado elegido (Chosen Ciphertext Attack o CCA): el atacante puede obtener los textos en claro correspondientes a un conjunto arbitrario
de textos cifrados de su propia eleccin mediante el uso de un orculo de descifrado. De nuevo, se supone imposible obtener del orculo 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
informacin obtenida de los procesos de descifrado anteriores. El objetivo en
este tipo de ataque es igual que en los CCA.
56
Puesto que tanto el esquema de cifrado como la clave pblica de un usuario

legtimo se consideran informacin pblica y conocida, en los criptosistemas de clave
pblica 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 prctica 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 an ms el nmero de tipos de ataques a considerar en criptosistemas de clave pblica, 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 autores, por ejemplo en [27]) tienen un carcter ms amplio que los ataques de clase
COA, puesto que cualquier mensaje cifrado considerado en un ataque de tipo COA
formara parte del conjunto de mensajes cifrados utilizados en CCA y ACCA, pero
no al contrario.
Por lo tanto, se puede concluir que en criptografa de clave pblica los tipos
de ataques diferenciados a considerar son CPA, CCA y ACCA. Relacionando esta
clasificacin con los conceptos IND y NM expuestos anteriormente, es posible desarrollar 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 combinaciones, donde las flechas representan implicaciones del tipo , tal como se
demostr en [27].
Figura 2.1: Modelos de seguridad en criptosistemas de clave pblica
Como se puede observar en la Figura 2.1, los conceptos IND-ACCA y NMACCA son equivalentes, siendo los ataques de tipo ACCA los que cuentan con
mayor potencial para comprometer cualquier esquema de cifrado de clave pblica.
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 establecimiento 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 pblica respectivamente del usuario U, el mensaje original sin
cifrar se denotar por la letra , la informacin cifrada ser identificada como , y
el criptograma incluye no solamente el mensaje cifrado sino tambin los elementos
adicionales que el receptor del criptograma necesita para proceder a su descifrado (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.
Descripcin
En su ya clsico documento de 1976, Whitfield Diffie y Martin Hellman [61] presentaron una manera de resolver las necesidades de seguridad del momento mediante
el novedoso concepto de criptografa de clave pblica. El sistema propuesto, conocido desde entonces como protocolo de establecimiento o acuerdo de clave de DiffieHellman, representa un mecanismo por el que dos usuarios intercambian pequeas
cantidades de informacin a travs 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 DiffieHellman, tal como fue planteado por sus autores, no constituye un criptosistema,
puesto que no lleva a cabo el cifrado y descifrado de informacin, sino que slo
permite el intercambio de pequeas cantidades de informacin 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 asimtrico y establecimiento de clave,
aunque s incluyeron indicaciones para la implementacin 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 comn con la que poder cifrar toda la comunicacin
posterior [148].
Despus de llevar a cabo los pasos anteriores, U y V conocen y comparten un
elemento comn 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 transmisin dichos valores son obtenidos de un servidor
de claves, nos encontramos ante una versin del protocolo de intercambio Diffie-
58
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 pblico un nmero primo y un generador
, donde = { : = 1, . . . , 1} y 1 < < 1.
2. A continuacin U debe generar un nmero entero aleatorio , con 1 < <
1, calcular y transmitir este elemento a V.
3. De forma anloga, V tiene que generar un nmero 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 continuacin se incluye un sencillo ejemplo del protocolo de establecimiento

de clave Diffie-Hellman:
1. Los usuarios U y V eligen pblicamente el nmero primo = 541 y el grupo
541 , cuyo orden es = 1 = 540. Adems, seleccionan un generador de
dicho grupo, = 51 541 .
2. A continuacin, U genera un nmero aleatorio = 301 y calcula
(mod ) = 51301 (mod 541) 94 (mod 541) ,
transmitiendo el valor 94 a V.
3. Anlogamente, V genera un nmero 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) .
59
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) = 51301197 (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 definicin
formal de este problema es la siguiente: dado un grupo finito y cclico, con generador , y unos elementos = , = , el problema consiste en determinar
el elemento del grupo dado por = [144].
El DHP es, hoy por hoy, un problema muy difcil de resolver desde el punto de
vista computacional. Resulta claro que si un atacante pudiera resolver el problema
DLP, habra resuelto el DHP. En efecto, si dados los elementos , , y , el
atacante es capaz de determinar en tiempo polinmico, podra usar este algoritmo
para calcular o en el caso del problema Diffie-Hellman, y puesto que conocera
los valores y obtenidos del canal inseguro, bastara 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 equivalentes; es decir, que resolver uno de ellos permite resolver el otro en tiempo polinmico. Por esta razn se suele expresar que la seguridad del esquema de acuerdo
de clave Diffie-Hellman est basada en la seguridad del DLP.
Existen numerosas tcnicas de ataque del DLP, recopiladas por ejemplo en [172].
Entre las principales se pueden destacar los mtodos baby-step giant-step [241], ro
de Pollard (Pollards Rho) [222] o el ataque Pohlig-Hellman [219].
2.4.2.
Criptosistema RSA
2.4.2.1.
Descripcin
En 1978, Ron Rivest, Adi Shamir y Leonard Adleman [229] propusieron una
implementacin prctica de los conceptos presentados anteriormente por Diffie y
Hellman. Aprovechando la dificultad de factorizar nmeros enteros muy grandes,
describieron los pasos necesarios para cifrar y descifrar mensajes que previamente
hubieran sido convertidos en cadenas numricas. Su propuesta inclua detalles sobre
cmo realizar las operaciones de cifrado y descifrado de forma eficiente, y cmo
60
calcular los parmetros que componen las claves pblicas y privadas. El esquema
de cifrado, tal como est descrito en [229], es independiente del tipo de mensaje,
estando la informacin cifrada directamente con la clave pblica y no por una
clave simtrica temporal. En 1983 les fue concedida la patente que solicitaron en
1977 [164], aunque en el ao 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. Generacin de las claves.
2. Cifrado del mensaje.
3. Descifrado del mensaje.
En los siguientes apartados se describen en detalle las fases mencionadas.
Generacin de las claves
Cada usuario (lo que representa tanto al usuario U que desea enviar el mensaje
como al usuario V que recibe la informacin cifrada , equivalente en este caso al
criptosistema ) debe elegir su par de claves, pblica y privada. Para ello es necesario
completar los pasos del Algoritmo 2.2, descrito utilizando la notacin del usuario V.
Algoritmo 2.2 Generacin de claves RSA
1. Elegir dos nmeros primos grandes y distintos pero de, aproximadamente, el mismo tamao.
2. Calcular los valores = y () = ( 1) ( 1), donde la funcin
() es el indicador de Euler para el nmero .
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 pblica del usuario V el par = (, ), siendo su
clave privada correspondiente = . Adems del elemento , tambin deben
permanecer secretos los nmeros , 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 mdulo del
criptosistema RSA.
61
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 pblica de V, = ( , ), de un directorio pblico de
claves.
2. Convertir el mensaje original en el nmero entero perteneciente al
conjunto .
3. Calcular el valor numrico asociado al mensaje cifrado mediante la expresin
=
(mod ),
siendo enviado este valor a V.

Ntese que el factor de expansin del criptosistema RSA, es decir, el cociente
entre la longitud del criptograma y el mensaje original, es exactamente 1, considerando que tanto el valor numrico 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 ) = ,
transformndolo a continuacin en el mensaje .
2.4.2.2.
Ejemplo
A continuacin se presenta un sencillo ejemplo de cifrado con RSA donde los

parmetros empleados son pequeos para una mayor claridad del proceso.
62

Para determinar las claves que utilizar el usuario V, se siguen los pasos expuestos en 2.4.2.1:
1. El usuario V debe elegir dos nmeros primos de forma secreta, en este caso
= 383 y = 521.
2. El siguiente paso consiste en multiplicar los valores y para obtener el
mdulo RSA , determinando el indicador de Euler ():
= = 383 521 = 199543,
() = ( 1) ( 1) = 382 520 = 198640.
3. A continuacin, 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 pblica, =
( , ) = (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 pblica de V, = ( , ) = (199543, 3).
2. A continuacin, U escribir el mensaje a enviar como un nmero menor que
= 199543 y primo con l. Para ello, por ejemplo, se puede considerar la
siguiente representacin de letras mediante nmeros, donde por simplicidad
no se ha considerado la letra .
63
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 mximo, tres letras. En el ejemplo
considerado se utilizarn 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 mximo comn divisor
de 199543 y 11960 es 1, lo que efectivamente ocurre en este caso.
3. A continuacin, U cifrar el mensaje anterior mediante el siguiente clculo:
(mod ) = 119603 (mod 199543)
1710777536000 (mod 199543) 15446 (mod 199543).
Este valor podra escribirse en base hexadecimal para ser enviado a su destinatario, 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 continuacin, debe representar el mensaje cifrado en base 26 como un nmero, 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.
64
2.4.2.3.
Seguridad
El criptosistema RSA se basa en dos problemas matemticos relacionados entre

s: el IFP y el problema RSA. El problema RSA puede definirse de la siguiente
manera [172]: dado un nmero entero positivo que sea el producto de dos nmeros
primos distintos y , un nmero entero positivo tal que el mximo comn divisor
sea mcd(, (1) (1)) = 1 y un nmero entero , el problema consiste en encontrar
el nmero 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 determinstico de tiempo polinmico capaz de factorizar el elemento , supuesto conocidos
los valores y , con , < (). De manera adicional, existen variantes del criptosistema RSA para las cuales tambin ha sido probada tal equivalencia, como por
ejemplo los criptosistemas de Rabin [225], Williams [270] y Kurosawa [156].
Existe un gran nmero de ataques sobre el algoritmo RSA [35, 264], siendo los
ms importantes los siguientes:
Ataques de factorizacin: consisten en intentar factorizar el mdulo . Dentro de este tipo de tcnica podemos citar los mtodos de Pollard [220, 221],
Williams [271], Lehman [158] y Shanks [241].
Ataques a exponentes de cifrado pequeos: estos mtodos estn derivados del
intento de conseguir un proceso de cifrado ms eficiente [101, 53].
Ataques a exponentes de descifrado pequeos: los ataques iniciales empleando
esta tcnica estn descritos en [267] y [31]. Para evitarlos, es recomendable
seguir las recomendaciones de Menezes [172] y Schneier [237] respecto a que el
tamao del exponente de descifrado debe ser prcticamente igual al tamao
del mdulo RSA, o el trabajo al respecto de Luis Hernndez, Jaime Muoz y
Araceli Queiruga [52].
2.4.3.
Criptosistema de El Gamal
2.4.3.1.
Descripcin
En 1985, Taher ElGamal [69] propuso un esquema de firma digital y cifrado que
utilizaba la clave pblica de V para cifrar una clave simtrica , con la que a su vez
se cifraba el mensaje original. La principal novedad de su propuesta consista en unir
para su envo tanto la clave simtrica temporal como la informacin original cifrada
con dicha clave, aprovechando la complejidad del clculo de los logaritmos sobre
cuerpos finitos. En su propuesta, ElGamal aconsejaba no cifrar ms de un mensaje
(o ms de un bloque del mensaje original, si por su longitud el mensaje deba ser
65
dividido en varias partes) con la misma clave , por lo que en la prctica una
nueva clave siempre acompaar al mensaje cifrado en cada envo de informacin
confidencial de U a V.
Como en todo criptosistema de clave pblica, en el de ElGamal se pueden identificar tres fases [179]:
1. Generacin de claves.
2. Cifrado de mensajes.
3. Descifrado de mensajes.
Generacin de claves
Todo usuario V que desee generar claves para el criptosistema de ElGamal debe
seguir el Algoritmo 2.5.
Algoritmo 2.5 Generacin de claves para el criptosistema ElGamal
1. Generar un nmero primo grande (de alrededor de 300-310 dgitos, es
decir, de aproximadamente 1024 bits).
2. Elegir un generador del grupo multiplicativo .
3. Generar un nmero aleatorio , con 2 2, y calcular el valor de
(mod ).
4. Asignar como clave pblica de V el tro = (, , ), siendo su clave
privada el nmero . En caso de que todos los usuarios utilicen los mismos
valores y , la clave pblica del usuario V quedara 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 expansin 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 numrico del mensaje, , como los elementos y , se codifican
en formato binario utilizando log2 bits.
66
Algoritmo 2.6 Cifrado de mensajes en el criptosistema ElGamal

1. Obtener la clave pblica de V, = ( ), as como los valores y .
2. Representar el mensaje como el valor entero {0, 1, . . . , 1}.
3. Generar un nmero aleatorio , 2 2, y utilizarlo para calcular los
valores
= (mod ) ,
= ( ) (mod ) .
4. Enviar el criptograma = (, ) a V, donde y representan las codificaciones alfanumricas 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 numrico asociado al mensaje original multiplicando por
el valor anterior mediante la operacin
(mod ) ( ) (mod ) ,
obteniendo a continuacin el mensaje original a partir del valor .
2.4.3.2.
Ejemplo
A continuacin 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 .
67
2. A continuacin, V elige como generador el elemento = 7 de 15485863 .

3. Posteriormente, V genera el nmero aleatorio = 21702 que ser utilizado
como clave privada, calculando adems el valor
(mod ) = 721702 (mod 15485863) 8890431 (mod 15485863) .
4. Si los dos usuarios deciden utilizar los mismos valores de y , entonces la
clave pblica 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 nmero entero, el usuario U genera el
nmero aleatorio = 480 y calcula el valor
= (mod ) = 7480 (mod 15485863) 12001315 (mod 15485863) .
A continuacin, realiza los siguientes clculos:
( ) (mod ) 8890431480 (mod 15485863) = 9846598 (mod 15485863) .
= ( ) (mod ) 2829967 (mod 15485863) .
4. Por ltimo, U debe obtener el equivalente alfanumrico 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).
68

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 clculos,
teniendo en cuenta que = (mod ):
(mod ) 1200131521702 (mod 15485863) 9846598 (mod 15485863) ,
= 14823281 (mod 15485863) .
2. A continuacin, V obtendr el valor numrico del mensaje original mediante
el clculo
= = 14823281 2829967 (mod 15485863) 5040698 (mod 15485863) .
Una vez obtenido , V podr recuperar el texto del mensaje original mediante
la siguiente conversin:
= 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 razn, se dice que la seguridad del criptosistema de ElGamal es
equivalente a la del logaritmo discreto.
2.5.
Esquemas de cifrado hbrido DEM -KEM
Los esquemas de cifrado de clave pblica integrados representan modelos hbridos en los cuales se utiliza un sistema de clave pblica para transportar una clave
de sesin que ser posteriormente utilizada por un algoritmo de cifrado simtrico.
Aunque es cierto que durante los aos 90 surgieron algunos esquemas de cifrado que
establecieron las bases de lo que se conoce actualmente como cifrado hbrido [9, 155],
no fue hasta el ao 2001 cuando Shoup [243] estableci formalmente los conceptos
en los que se basan este tipo de esquemas [25].
2.5. Esquemas de cifrado hbrido DEM -KEM
69
Debido a la contribucin de Shoup, las tcnicas ms modernas relacionadas con

los esquemas de cifrado hbrido de clave pblica dividen el esquema en dos etapas claramente diferenciadas, denominadas KEM (Key Encapsulation Mechanism)
y DEM (Data Encapsulation Mechanism). La popularidad que ha alcanzado recientemente la tcnica DEM -KEM se basa, en parte, a que la seguridad del esquema
resulta ms sencilla de analizar considerando los dos bloques por separado [30].
Los siguientes apartados incluyen la definicin formal de las etapas KEM y DEM,
utilizando para ello la notacin definida en [243].
2.5.1.
Mecanismo de encapsulacin de clave KEM
Cualquier mecanismo KEM debe incluir los siguientes elementos:

Un algoritmo de generacin de clave KEM.KeyGen(), que produce una clave
pblica 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 pblica 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 longitud de la clave K.
2.5.2.
Mecanismo de encapsulacin 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.
70
2.5.3.
Esquema de cifrado hbrido con etapas KEM -DEM
En base a las definiciones de las etapas DEM y KEM, es posible describir de

forma genrica los pasos necesarios para cifrar un mensaje M utilizando el esquema
de cifrado hbrido genrico H-PKE =H-PKE , . La nica condicin 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 pblica 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
versin 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 operacin de concatenacin.
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 operaciones:
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.
Criptografa basada en curvas elpticas
Tal como se ha comentado anteriormente, en 1987 Neal Koblitz [147] propuso

utilizar curvas elpticas sobre cuerpos finitos para implementar algunos criptosistemas ya existentes que utilizaban el grupo multiplicativo de un cuerpo finito. En
las secciones dedicadas al equivalente del algoritmo de ElGamal, Koblitz detall los
clculos que es necesario realizar sobre los puntos de una curva elptica, incluyendo
ejemplos sobre cmo elegir dichos puntos. De forma adicional, Koblitz describi cmo se podra implementar el proceso de acuerdo de clave Diffie-Hellman utilizando
curvas elpticas, lo que constituye el esquema ECDH (Elliptic Curve Diffie-Hellman).
2.6. Criptografa basada en curvas elpticas
71
Por su parte, Victor Miller [174] realiz su propuesta desde un punto de vista ms
terico en relacin 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 relacionados con las curvas elpticas y con su aplicacin a la criptografa.
2.6.1.
Definicin de curva elptica
Dados el cuerpo y el plano afn A2 () = 2 definido sobre , se representa el

plano proyectivo correspondiente como el conjunto
P2 () = {(, , ) 3 (, , ) = (0, 0, 0)}
junto con la relacin de equivalencia , definida de manera que dos puntos del
plano proyectivo (, , ) y ( , , ) son equivalentes si y slo 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 afn
A () mediante la ecuacin (, ) = 0 en coordenadas no homogneas, o alternativamente en el plano proyectivo P2 () mediante la ecuacin (, , ) = 0
en coordenadas homogneas [265], donde un polinomio es homogneo si todos sus
monomios tienen el mismo grado.
2
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 gnero de la propia curva, concepto derivado
del teorema de Riemann [227] y que permite clasificar las curvas planas en funcin
del grado del polinomio que la define y de sus singularidades mediante la expresin
(2.1)
( 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 slo si las derivadas parciales de la
expresin se anulan en dicho punto [149]. Los puntos singulares de una curva cbica
plana se denominan nodo si el punto tiene dos tangentes distintas y cspide 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 cspide, respectivamente.
72
Figura 2.2: Curva 2 = 3 con un nodo en el punto (0, 0)
Figura 2.3: Curva 2 + 3 = 0 con una cspide en el punto (0, 0)
73
En funcin del gnero 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 continuacin [140]:
Una curva de gnero = 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 gnero = 1 no tiene puntos racionales, tiene un nmero finito
de ellos o bien tiene infinitos, pero slo puede tener una cantidad finita de
puntos enteros.
Una curva de gnero 2 slo puede tener una cantidad finita de puntos
racionales.
A partir de las definiciones anteriores, se puede afirmar que una curva elptica
sobre el cuerpo es una curva proyectiva regular de gnero 1 que tiene al menos
un punto racional [140, 149, 245]. Toda curva elptica admite un tipo de ecuacin
cannica llamada forma de Weierstrass, cuya expresin en coordenadas homogneas
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 834 2726 + 92 4 6
2 = 21 + 42
4 = 24 + 1 3
6 = 23 + 46
8 = 21 6 + 42 6 1 3 4 + 2 23 24
En la prctica, la ecuacin de Weirstrass se suele expresar en su forma no homognea, donde la relacin entre ambas ecuaciones es (, ) = (, , 1), y alternativamente (, , ) = (/, /) 3 , resultando la siguiente ecuacin afn:
(2.3)
: 2 + 1 + 3 = 3 + 2 2 + 4 + 6 .
Las Figuras 2.4 y 2.5 muestran dos ejemplos de curvas elpticas definidas sobre
el cuerpo de los nmeros reales.
74
Figura 2.4: Curva elptica 2 = 3 10 + 15
Figura 2.5: Curva elptica 2 = 3 10 + 9
75
La ecuacin homognea 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 elptica, ya que podra tener puntos singulares (en realidad, si la curva dada por
la ecuacin de Weierstrass no es regular, entonces slo tiene un punto singular, que
es finito y racional [140]). Por ello, la condicin aadida = 0 asegura que la curva
es regular o suave, es decir, que no pueden existir puntos de la curva con dos o
ms lneas tangentes distintas [72, 99], lo cual es equivalente a afirmar que todas las
races de la ecuacin deben ser necesariamente simples.
Es interesante comentar que existen otras definiciones equivalentes para curvas
elpticas. Las ms importantes expresan que una curva elptica es:
Una curva plana cbica no singular con un punto racional.
Una curva no singular de gnero 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 expresin dada por la ecuacin de Weierstrass, por lo que comnmente
se considera dicha ecuacin como el punto de partida al tratar con curvas elpticas.
2.6.2.
Estructura de grupo
Sea una curva elptica sobre un cuerpo definida mediante la ecuacin (2.3),
y sean los puntos de la curva = ( , ), = ( , ) y = ( , ), donde
= [0 : 1 : 0] representa el punto en el infinito en coordenadas homogneas. En
estas condiciones, se define la operacin + 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 ,
76

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 grfica algunos ejemplos de operaciones

realizadas sobre la curva 2 = 3 10 + 15 definida sobre el cuerpo de los nmeros
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 = +
Segn indica el teorema de Mordell-Weil [180, 266], la operacin suma de puntos

definida de esta manera cumple las propiedades descritas a continuacin, 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
77
78
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 caracterstica implica que todos los puntos racionales de una curva elptica
definida sobre (o sobre una extensin de ) pueden obtenerse a partir de un
nmero finito de ellos. En el caso de los cuerpos finitos, el nmero de generadores
es 1 2 [228].
2.6.3.
Curvas elpticas sobre cuerpos finitos
2.6.3.1.
Orden y caracterstica de un cuerpo finito
El orden de un cuerpo finito es el nmero de elementos de dicho cuerpo. Es

posible demostrar que la existencia de un cuerpo finito de orden est ligada a la
condicin de que el valor sea una potencia prima del tipo = , donde al valor
se le denomina caracterstica del cuerpo y debe ser un nmero primo, mientras que
el valor puede ser cualquier entero positivo [99].
79
En general, en los criptosistemas basados en curvas elpticas 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 nmero 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 mediante los nmeros enteros {0, 1, 2, . . . , 1}. En este caso, el elemento neutro de
la operacin suma es el entero 0, el elemento unitario de la operacin producto es
el entero 1, la suma de elementos se realiza mediante la suma de enteros mdulo
y la multiplicacin de elementos del cuerpo se efecta igualmente mediante la
multiplicacin de nmeros enteros mdulo [24].
En comparacin, en los cuerpos finitos de tipo 2 , los elementos del cuerpo se
representan mediante cadenas de bits de longitud . Si () es un polinomio irreducible 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 parmetros que definen el tamao del cuerpo finito son imprescindibles para
calcular la longitud de las curvas elpticas y de las claves asociadas a dichas curvas. Esta longitud debe ser interpretada como el nmero 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 elptica
Se define el orden de una curva sobre un cuerpo de caracterstica , denotndose mediante la expresin #( ), como el nmero 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 ecuacin de la
curva ms el punto en el infinito.
El teorema de Hasse [143] determina la siguiente expresin para el orden de una
curva:
#( ) = + 1 ,
2 ,
donde el elemento representa la traza de la curva [99].
80
2.6.3.3.
Versiones simplificadas de la ecuacin de Weierstrass
Dependiendo de si el cuerpo tiene caracterstica 2, 3 o cualquier otro valor [50],

es posible simplificar an ms la ecuacin (2.3), tal como se describe a continuacin:
1. Si la caracterstica de no es 2 ni 3, el cambio de variables
(
(, )
321 122 31 31 + 41 2 123

,
36
216
24
transforma la ecuacin (2.3) en
2 = 3 + + ,
(2.4)
cuyo discriminante pasa a ser
= 16 (43 + 272 ).
2. Si la caracterstica de es 2 aparecen dos casos distintos dependiendo del valor
de 1 .
a) Si 1 = 0, entonces el cambio de variables
(
)
3 3
21 4 + 23
2
(, ) 1 + , 1 +
1
31
transforma la curva dada por la ecuacin (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 ecuacin (2.3) en
(2.6)
2 + = 3 + + .
A esta curva se la denomina supersingular [99] y su discriminante es
81
= 4 .
3. Si la caracterstica de es 3, de nuevo nos encontramos con dos casos distintos
en funcin del valor de 1 .
a) Si 21 = 2 , entonces el cambio de variables
)
(
24 + 1 3
24 + 1 3
, + 1 + 1 2
+ 3
(, ) + 2
1 + 42
1 + 42
transforma la curva dada por la ecuacin (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 ecuacin (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 elptica sobre un cuerpo de caracterstica definida por la ecuacin cbica en coordenadas homogneas (, , ) = 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 caracterstica 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 funcin de la caracterstica de y de las condiciones adicionales que se impongan sobre
cada curva.
82
Car. de
Ecuacin
2
= 2, 3
= 3 + +
2
2 + = 3 + 2 +
2
2 + = 3 + +
3
2 = 3 + 2 +
3
2 = 3 + +
Supersingular
No
No
S
No
S
Condicin
1 = 0
1 = 0
2
1 = 2
21 = 2
Cuadro 2.1: Versiones simplificadas de la ecuacin de Weierstrass
2.6.3.4.
Estructura de grupo en curvas sobre cuerpos finitos
La operacin 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 ecuacin (2.4), la operacin + 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 frmulas anteriores implican que la suma de dos puntos y conlleva

la realizacin de 1 inversin, 2 multiplicaciones y 1 elevacin al cuadrado en ,
83
mientras que para obtener 2 a partir del punto es necesario realizar 1 inversin,
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
comparacin con las otras operaciones mencionadas, son las que requieren menor
tiempo de computacin.
Las siguientes figuras muestran de forma grfica las siguientes operaciones realizadas 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 operacin + queda particularizada del siguiente modo [50], donde
= ( , ), = ( , ), = ( , ) y los elementos que conforman las
coordenadas pertenecen a 2 .
2. Dado un punto , entonces + ( ) = , siendo = ( , + ).
84
Figura 2.11: Suma de puntos = + = 2 sobre un cuerpo primo
Figura 2.12: Suma de puntos = + 2 = 3 sobre un cuerpo primo
85
= 2 + + + + ,
= ( + ) + + ,
.
=

valores
= 2 + + ,
= ( + ) + + ,
= +
.
Con las frmulas anteriores, tanto la suma de dos puntos y como la obtencin
de 2 a partir del punto necesitan 1 inversin, 2 multiplicaciones y 1 elevacin 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 ejecucin respecto al de las otras operaciones referidas, por lo
que su aportacin al tiempo de procesamiento total puede considerarse despreciable.
2.6.3.5.
Multiplicacin de un punto por un escalar
De manera adicional a la operacin suma, existe otra operacin ampliamente

utilizada en los clculos 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 nmero
de veces consigo mismo:
= + + . . . + .
Aunque en algunos textos la notacin recogida para esta operacin es [] o
, se ha decidido utilizar la notacin simplificada con el fin de conseguir una
mayor sencillez en la exposicin.
Cuando la curva elptica 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:
#( ) = .
86
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 divisin se le denomina cofactor, de manera que si es el orden
de , entonces se cumplir que el cofactor ser
=
2.6.4.
#( )
.
Bases polinmicas y bases normales
Adems de su interpretacin como el conjunto de polinomios de grado menor

que , 2 = 2 []/( ()), el cuerpo finito 2 tambin puede entenderse como
un espacio vectorial de dimensin 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
= (0 , 1 , . . . , 1 ),
donde {0, 1} ,
=0
el cual en la prctica se representa como una cadena de bits de longitud .

2.6.4.1.
Bases polinmicas
Las representaciones de los elementos de 2 = 2 []/( ()) mediante bases

polinmicas 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 tcnica, 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 operacin XOR aplicada
sobre los bits de las cadenas que representan a los elementos que participan en la
suma. Respecto a la multiplicacin de elementos de 2 , esta operacin se realiza
87
mediante el producto de los polinomios mdulo 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 divisin 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 trmino medio . Es importante
hacer constar que estos trinomios slo existen para algunos valores de .
2. En caso de no existir un polinomio con las caractersticas 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 . Despus, 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 comparacin con los trinomios, los pentanomios
irreducibles existen para todo valor 4.
Para mayor informacin, 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
=
2 ,
donde {0, 1} .
=0
En el caso de las bases normales, a los elementos 2 se les suele representar como la cadena de bits (0 1 . . . 1 ) de longitud (ntese el cambio en el
orden de los subndices respecto a las bases polinmicas), donde {0, 1}. Empleando esta tcnica, el elemento unitario se representa mediante la cadena de bits
(1 1 . . . 1 1 1), mientras que el elemento neutro queda representado mediante la cadena (0 0 . . . 0 0 0). Al igual que en las bases polinmicas, la suma de dos elementos
de 2 se realiza mediante la operacin XOR aplicada sobre los bits de las cadenas
que los representan.
88
La ventaja de las bases normales consiste en que la operacin de elevar al cuadrado un elemento se realiza de forma muy rpida, puesto que si = (0 1 . . . 1 ),
entonces su cuadrado resulta ser 2 = (1 0 1 . . . 2 ). Multiplicar dos elementos distintos es, sin embargo, mucho ms complicado, por lo que en la prctica
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 nmero entero positivo que indica la complejidad de la operacin de
multiplicacin con respecto a la base, de manera que cuando ms pequeo sea ese
nmero, ms eficiente ser la multiplicacin. 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
multiplicacin ms eficientes, por lo que se las denomina bases normales ptimas.
Aunque las bases normales permiten obtener implementaciones ms eficientes
de la aritmtica de puntos en curvas definidas sobre cuerpos binarios, su utilizacin
se encuentra controlada por las patentes descritas en 2.6.9, motivo por el cual las
implementaciones de software libre de curvas elpticas utilizan en su lugar las bases
polinmicas.
2.6.5.
Representacin de los puntos de una curva elptica
Dada una curva elptica definida sobre un cuerpo finito de caracterstica ,

un punto de la curva puede representarse de forma comprimida o descomprimida
[257], tal como se describe a continuacin:
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 representacin hexadecimal de la primera coordenada del punto, y
el elemento puede tener como valores 0x02 0x03 dependiendo del punto,
calculndose este valor segn 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].
89
Algoritmo 2.8 Compresin de un punto = (, ) de la curva

1. Obtener la representacin 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 nmero primo, realizar la asignacin =
(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 representacin comprimida de la cadena .
Algoritmo 2.9 Descompresin 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 asignacin = 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 nmero primo, calcular el elemento del cuerpo
3 + + (mod ), y calcular una raz cuadrada de mdulo
. Si (mod 2), hacer = . Si por el contrario no se cumple la
equivalencia indicada, tomar = .
1
b) Si = 2 y = 0, realizar la asignacin = 2 . En cambio,

si = 0, calcular el elemento = + + 2 del cuerpo 2 , y
encontrar a continuacin 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 = (, ).
90
2.6.6.
Comprobacin de los parmetros de una curva elptica
En la implementacin de funcionalidades de los criptosistemas basados en curvas

elpticas, uno de los puntos ms crticos suele ser la generacin de los parmetros
asociados a una curva y su posterior comprobacin. 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 Generacin aleatoria de una curva sobre 2
1. Elegir una semilla aleatoria .
2. Aplicar la funcin resumen SHA-1 al elemento para obtener una cadena
de bits de longitud .
3. Asignar al elemento de 2 cuya representacin en binario es .
4. Incluir en la expresin : 2 + = 3 + 2 + .
5. Calcular el orden #(2 ) y asignar su valor a .
6. Si = 2, siendo un nmero primo, entonces volver al paso 1. En caso
contrario, continuar.
7. Generar un elemento (2 ) de orden .
8. Validar la curva con parmetros = (, 2 , , 2, ) segn el Algoritmo
2.11. Si la validacin es negativa, volver al paso 1.
Mediante el valor descrito en el Algoritmo 2.10, cualquier entidad puede comprobar que la curva elptica generada est determinada por . La operacin contraria,
esto es, la comprobacin de los parmetros de una curva, se puede realizar mediante el Algoritmo 2.11, aunque habitualmente tanto la generacin de curvas como
la comprobacin de la validez de sus parmetros suele ser tarea de las empresas
desarrolladoras de soluciones comerciales de curvas elpticas o de los organismos de
estandarizacin.
Por ltimo, el Algoritmo 2.12 muestra un sencillo procedimiento que puede ser
utilizado para validar una clave pblica cualquiera .
La ltima comprobacin mencionada puede resultar computacionalmente costosa, sobre todo si = 1 en los casos de cuerpos primos, o si = 2 en el caso de los
cuerpos con caracterstica par. Sin embargo, es una comprobacin importante para
evitar problemas con ciertos subgrupos de pequeo tamao. Precisamente puesto
que esta comprobacin puede ser difcil de realizar, existe la opcin de utilizar el
cofactor en la funcin de derivacin de clave, tal como se explica en 4.3.3.
91
Algoritmo 2.11 Comprobacin de los parmetros 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 generacin de puntos aleatorios y la
comprobacin de que tienen orden , o .
3. Comprobar que es un nmero primo, para evitar los ataques basados en
el mtodo 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 anmalo [29].
6. Comprobar que 1 (mod ) para todos los valores 100 a fin de evitar
el ataque de tipo supersingular (tambin conocidos como MOV/Frey-Rck
[29]).
7. Comprobar que pertenece a la curva y tiene orden .
Algoritmo 2.12 Validacin de una clave pblica
1. Si
/ ( ), entonces la clave pblica no es vlida.
2. Si = , la clave pblica no es vlida.
3. Si = , la clave pblica no es vlida.
2.6.7.
Seguridad
De manera equivalente a otros protocolos y algoritmos, la criptografa de curva

elptica tambin tiene ataques que tienen en cuenta sus aspectos especficos. En los
siguientes apartados, se describen las caractersticas principales de estos ataques
sobre ECC.
2.6.7.1.
Curvas supersingulares
Las curvas definidas sobre el cuerpo con caracterstica se denominan supersingulares si cumplen la condicin #( ) 1 (mod ) [265]. En curvas sobre ,
por ejemplo, una curva supersingular contendr exactamente + 1 elementos.
El ataque de Frey y Rck [76], que es una generalizacin 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 algn 1, el cual es ms sencillo de resolver.
92
Este ataque slo es prctico si el parmetro es pequeo, y para comprobar si

una curva es vulnerable a este ataque es necesario realizar la siguiente comprobacin,
donde es el orden del generador :
1 (mod ) , , 1 100.
2.6.7.2.
Curvas anmalas
Las curvas anmalas se caracterizan por contener exactamente elementos en

[265]. Semaev [240], Smart [247] y Satoh y Araki [235] demostraron que el ECDLP
planteado para curvas anmalas puede ser resuelto de manera eficiente, por lo que
para excluir de los algoritmos de generacin de claves este tipo de curvas es necesario
realizar la comprobacin
#( ) = .
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 hiperelpticas. Tanto Jacobson, Menezes y Stein [141] como Maurer, Menezes
y Teske [167] encontraron varias curvas definidas sobre cuerpo 2 , siendo un
nmero compuesto, donde el mtodo era viable.
Por otra parte, Menezes y Qu [173] demostraron que este mtodo no es aplicable
a cuerpos finitos 2 cuando es un nmero primo, por lo que los estndares y
recomendaciones ms recientes nicamente incluyen (en los apartados que tratan
sobre cuerpos binarios) curvas elpticas donde es un nmero primo.
2.6.8.
Estndares relacionados
En el mbito de los algoritmos y protocolos criptogrficos, los hallazgos tericos

no pueden emplearse directamente, sino que es necesario definir las conversiones y
la gestin de datos sobre los que se aplicarn las nuevas tcnicas.
La informacin precisa que permite realizar implementaciones prcticas se detalla en los estndares desarrollados por diferentes organizaciones tanto nacionales
como supranacionales, as como por consorcios industriales. A continuacin se enumeran las principales organizaciones dedicadas a esta labor de estandarizacin y que
han desarrollado alguna norma relacionada con las curvas elpticas y su aplicacin
a la critografa:
93
ISO
La Organizacin Internacional para la Estandarizacin (International Organization for Standardization o ISO) es el organismo encargado de promover
el desarrollo de las normas internacionales de fabricacin, comercio y comunicacin para todas las ramas industriales (a excepcin de la elctrica y la
electrnica), especialmente en los temas relacionados con las normas de productos y seguridad para las empresas y organizaciones a nivel internacional.
IEC
La Comisin Electrotcnica Internacional (International Electrotechnical Commission o IEC) es un organismo de estandarizacin en los campos elctrico,
electrnico y de otras tecnologas relacionadas. Numerosas normas se desarrollan conjuntamente con ISO, siendo entonces denominadas normas ISO/IEC.
IEEE
El Instituto de Ingenieros Elctricos y Electrnicos (Institute of Electrical and
Electronics Engineers o IEEE) es una asociacin tcnico-profesional mundial
dedicada a la estandarizacin de tecnologas derivadas de la electricidad: ingeniera computacional, tecnologas biomdica y aeroespacial, energa elctrica,
control, telecomunicaciones, electrnica de consumo, etc.
IETF
El Grupo de Trabajo en Ingeniera de Internet (Internet Engineering Task
Force o IETF) es una organizacin internacional de estandarizacin que tiene
como objetivo velar para que la arquitectura de la red y los protocolos tcnicos de Internet funcionen correctamente, actuando en reas como transporte,
seguridad, etc.
ANSI
El Instituto Nacional Estadounidense de Estndares (American National Standards Institute o ANSI) es una organizacin sin nimo de lucro que supervisa
el desarrollo de estndares para productos, servicios, procesos y sistemas en
los Estados Unidos, siendo miembro de ISO y de IEC. ANSI tambin se encarga de coordinar estndares estadounidenses con estndares internacionales,
de modo que los productos de Estados Unidos puedan utilizarse en todo el
mundo.
NIST
El Instituto Nacional de Estndares y Tecnologa (National Institute of Standards and Technology o NIST) es una agencia de la Administracin de Tecnologa del Departamento de Comercio de los Estados Unidos. La misin de este
instituto es promover la innovacin y la competencia industrial en Estados
Unidos mediante avances en las normas aplicadas y en la propia tecnologa.
94

Las principales reas de actuacin del NIST son biotecnologa, nanotecnologa,
tecnologas de la informacin y fabricacin avanzada.
SECG
El Grupo de Estndares para la Criptografa Eficiente (Standards for Efficient
Cryptography Group o SECG) es un consorcio internacional fundado en 1998,
siendo su principal objetivo facilitar la adopcin de la criptografa de curva
elptica. Entre sus miembros se encuentran compaas como Certicom, Entrust,
Fujitsu y Visa.
En los prximos apartados se presentan los diferentes estndares relacionados con

la criptografa basada en curvas elpticas, agrupados segn el campo de aplicacin.
2.6.8.1.
Protocolos de establecimiento de clave
Mediante el trmino ECDH nos referimos al esquema de acuerdo de clave basado

en el mecanismo Diffie-Hellman [61] y las curvas elpticas, definido en [147] y [174].
Este protocolo se encuentra incluido en los estndares ANSI X9.63 [16] e IEEE 1363
[108, 109]. Tambin puede encontrarse en los documentos SP 800-56A del NIST [189]
y SEC 1 del SECG [254]. Adems 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 ampliamente conocido que utiliza curvas elpticas: 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 elpticas [257].
En los apndices de FIPS 186-2 [184] y en el estndar 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] slo tiene mbito de aplicacin
interna en los EE.UU., al ser informacin de dominio pblico, en la prctica se utiliza
tambin fuera de ese mbito.
El esquema ECDSA tambin se encuentra recogido en el estndar 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.
95
Protocolos de cifrado
Los primeros esquemas de cifrado basados en curvas elpticas que surgieron fueron el equivalente de los sistemas Massey-Omura [205] y ElGamal [69], ambos presentados 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 ms extendido en la actualidad que emplea
curvas elpticas es conocido de forma genrica como ECIES (Elliptic Curve Integrated 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 estndar ANSI X9.63 [16], en el anexo IEEE
1363a [109] al documento IEEE 1363 [108] y en el estndar ISO/IEC 18033-2 [136].
Asimismo, puede encontrarse una amplia descripcin de ECIES, as como numerosos
detalles tcnicos para su implementacin, en el documento SEC 1 [254] realizado por
el consorcio industrial SECG.
2.6.9.
Patentes
En la actualidad existe un gran nmero 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
clculos 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 clculos en cuerpos
2 empleando bases normales.
US 4.745.568 - Computational method and apparatus for finite field multiplication [208]: presenta un diseo para la implementacin 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 utilizacin de curvas elpticas sobre el anillo , donde es
un nmero compuesto.
US 5.272.755 - Public key cryptosystem with an elliptic curve [166]: presenta
un criptosistema de curvas elpticas sobre cuerpos donde el orden de la
curva es exactamente .
96

US 5.463.690 - Method and apparatus for public key exchange in a cryptographic system [197]: describe un criptosistema de curvas elpticas sobre cuerpos
primos, donde los primos tienen el formato = 2 , siendo un valor
pequeo en comparacin con 2 . Se trata de una extensin 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 optimizacin en el proceso de verificacin de firmas digitales con
curvas elpticas, 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 diseo hardware y las
funciones necesarias para la multiplicacin en cuerpos 2 .
US 5.854.759 - Methods and apparatus for efficient finite field basis conversion
[231]: describe un mtodo 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 pequeos.
US 6.078.667 - Generating unique and unpredictable values [43]: presenta mtodos especficos de generacin de nmeros aleatorios para ser utilizados como
claves privadas.
US 6.212.279 - Method of elliptic curve cryptographic key exchange using reduced base tau expansion in non-adjacent form [192]: incluye indicaciones para
realizar multiplicaciones eficientes en curvas sobre cuerpos 2 en las operaciones de acuerdo de clave.
US 6.243.467 - Method of elliptic curve digital signature generation and verification 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 compresin y descompresin de puntos de una curva elptica.
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 pblica del receptor como clave de cifrado, incluyendo
la compresin de puntos para su transmisin. Se trata de una extensin de la
patente US 6.141.420 (no incluida en este listado por ese motivo).
97
US 6.704.870 - Digital signatures on a smartcard [46]: describe una implementacin del algoritmo ECDSA con ciertas modificaciones que tiene en consideracin las limitaciones de las tarjetas inteligentes.
US 6.782.100 - Accelerated finite field operations on an elliptic curve [47]:
recoge una optimizacin para la multiplicacin en cuerpos 2 de un punto de
la curva cuya caracterstica principal consiste en no emplear en ciertos pasos
la segunda coordenada, recuperando el valor de la segunda coordenada del
producto al final de la operacin.
EP 1 496 644 A2 - Method for signature and session key generation [41]: describe el protocolo de acuerdo de clave MQV, representando una continuacin
de la patente EP 0 739 105 A1 (no incluida en este listado por ese motivo).
Captulo 3
Capacidades criptogrficas en Java
Resumen del captulo

Este captulo tiene como objetivo presentar las capacidades criptogrficas del lenguaje Java, en concreto las disponibles en las ediciones Java
Standard Edition y Java Card, para lo cual se ofrece una introduccin a
la programacin orientada a objetos y al lenguaje Java en general, junto
con un resumen de las principales bibliotecas criptogrficas desarrolladas
con este lenguaje de programacin. En el apartado que hace referencia a
Java Card, se ha incluido una descripcin detallada de las caractersticas
generales de este sistema operativo y de las peculiaridades de su modelo
de programacin.
3.1.
Programacin orientada a objetos
Los lenguajes de programacin orientados a objetos, entre los que se encuentra

Java, tienen en comn ciertas caractersticas desarrolladas en torno al propio concepto de objeto, que no es ms que la instanciacin o concrecin de una clase.
A su vez, una clase es el molde o prototipo que especifica las variables y mtodos
comunes de un determinado tipo de elemento.
Entre las caractersticas que Java comparte con otros lenguajes de programacin
es imprescindible mencionar los mecanismos de encapsulacin, herencia y polimorfismo [107], tal como se describen en los siguientes apartados.
99
100
3.1.1.
Encapsulacin
La encapsulacin consiste en la ocultacin de variables y mtodos de un objeto,

permitiendo su modificacin slo a travs de determinados mtodos pblicos. Este
procedimiento conlleva los siguientes beneficios:
Modularidad: el cdigo de un objeto puede ser creado y mantenido independientemente del cdigo de otros objetos. La creacin e intercambio de cdigo
es, de esta manera, ms sencilla.
Ocultacin de la informacin: los objetos pueden ofrecer una interfaz pblica
para la comunicacin con otros objetos, manteniendo a la vez ciertos mtodos
y variables ocultos, de manera que se puedan modificar sin afectar a los dems
objetos.
3.1.2.
Herencia
La herencia es un concepto que relaciona clases de manera jerrquica. Esto permite que los descendientes de una clase hereden todas las variables y mtodos de sus
ascendientes, adems 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 versin especializada de su superclase correspondiente que hereda todos sus
mtodos y variables de instancia.
3.1.3.
Polimorfismo
A los mtodos que actan sobre los objetos se les pasa informacin en forma
de parmetros en la llamada al mtodo. Estos parmetros representan los valores
de entrada a cada funcin implementada por la aplicacin. Para completar dos
tareas diferentes en la mayora de los lenguajes de programacin es necesario tener
dos funciones independientes con nombres diferentes. El polimorfismo (un objeto y
muchas formas) es un concepto simple que permite que un mtodo tenga mltiples
implementaciones que se seleccionan en base al tipo de objeto que se le pasa en la
llamada al mtodo, lo que se conoce como sobrecarga del mtodo.
3.2.
3.2.1.
El lenguaje Java
Introduccin al lenguaje Java
Los orgenes de Java se remontan al ao 1990, cuando un equipo de la compaa Sun Microsystems investigaba, bajo la direccin de James Gosling, el diseo y
3.2. El lenguaje Java
101
elaboracin de software para pequeos dispositivos electrnicos en el entorno de un

proyecto denominado Green Project. En un primer momento se pens en la utilizacin de lenguajes de programacin como C o C++, pero puesto que para poder
compilar un programa en estos lenguajes era preciso adaptarlo a las caractersticas
de la plataforma en la que deba funcionar, y que cada pocas semanas aparecan en
el mercado versiones ms potentes y baratas de los chips utilizados, el software que
haba sido diseado para un chip determinado deba necesariamente modificarse y
adaptarse para explotar las caractersticas de los nuevos chips.
De esta forma, se hizo patente la necesidad de introducir un nuevo lenguaje de
programacin que permitiera desarrollar programas independientemente de la plataforma subyacente. Los dispositivos que se pretendan fabricar eran calculadoras,
relojes, equipos de msica, cafeteras, etc., todos ellos de pequea capacidad computacional, por lo que el nuevo lenguaje deba ser capaz de generar programas pequeos
y rpidos, adems de ser fiables y robustos. La primera versin de este nuevo lenguaje 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, razn por la cual Sun decidi darle una segunda oportunidad aplicndolo al por entonces incipiente mercado de la navegacin por internet. El equipo
de James Gosling se plante como objetivo la utilizacin de Java como lenguaje
de desarrollo para aplicaciones que pudiesen funcionar a travs de internet, y como
resultado de su trabajo se present en 1995 un navegador escrito completamente
en Java, denominado HotJava. Este navegador permita la integracin de pequeas
aplicaciones en el interior de las pginas web. El desarrollo de HotJava hizo patente
que las caractersticas de Java se adaptaban satisfactoriamente a las caractersticas
de internet.
A partir de aquella primera y sencilla versin, Java fue creciendo progresivamente
en tamao y complejidad, ofreciendo un lenguaje de programacin utilizado en gran
cantidad de campos tcnico-cientficos. Desde su versin J2SE 1.4, la evolucin 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 continuacin se presentan las
distintas versiones del lenguaje Java en funcin de su fecha de aparicin:
JDK 1.0 (23 de enero de 1996): constituy la versin inicial. La denominacin
JDK hace referencia al software de desarrollo Java Development Kit.
JDK 1.1 (19 de febrero de 1997): reestructur el modelo de interfaces grficas
AWT (Abstract Window Toolkit) y present el concepto RMI (Remote Method
Invocation).
102
J2SE 1.2 (Playground, 8 de diciembre de 1998): represent el cambio a la

denominacin Java 2 y el nombre J2SE (Java 2 Platform, Standard Edition)
para distinguir esta plataforma de J2EE (Java 2 Platform, Enterprise Edition).
Su caracterstica ms importante es que la API grfica (Swing) fue integrada
en las clases bsicas.
J2SE 1.3 (Kestrel, 8 de mayo de 2000): incluy la mquina virtual HotSpot
JVM.
J2SE 1.4 (Merlin, 6 de febrero de 2002): fue el primer lanzamiento de la plataforma Java gestionado por el JCP como el subproyecto JSR 59. Su principal
novedad fue la inclusin de un modelo de seguridad integrada que permita
extensiones criptogrficas de terceros.
J2SE 5.0 (Tiger, 30 de septiembre de 2004): signific el cambio de la numeracin tipo 1.X a la X.0.
Java SE 6 (Mustang, 11 de diciembre de 2006): en esta versin, Sun cambi el
nombre J2SE por Java SE y elimin el .0 del nmero de versin.
Java SE 7 (Dolphin, prevista para 2011): entre otras novedades, permitir
operar con clases BigDecimal utilizando operadores arimticos en lugar de
llamadas a mtodos.
Actualmente la cifra de desarrolladores Java supera los 6 millones, existiendo ms
de 4.500 millones de dispositivos habilitados con tecnologa Java (principalmente
ordenadores personales, telfonos mviles y tarjetas inteligentes, segn [212]). Entre
noviembre de 2006 y mayo de 2007, Sun Microsystems liber la mayor parte de la
tecnologa Java bajo licencia GNU GPL a travs del proyecto OpenJDK [213], de
tal forma que con la excepcin de algunos elementos sobre los que Sun no tiene los
derechos (principalmente la tecnologa de gestin de grficos Java 2D), prcticamente
todo el lenguaje Java es actualmente software libre. El 27 de enero de 2010, la
compaa Oracle Corporation finaliz la adquisicin de Sun Microsystems [214], por
lo que a partir de ese momento la tecnologa Java ha pasado a ser gestionada por
Oracle.
En cuanto a las distintas ediciones del lenguaje Java, adems de las versiones
Standard y Enterprise mencionadas anteriormente, es posible utilizar las plataformas
Micro Edition y Java Card. A continuacin se muestra un breve resumen de sus
caractersticas diferenciadoras:
Java Standard Edition (Java SE): proporciona un entorno de ejecucin y un
conjunto de API para aplicaciones de ordenadores personales. De manera adicional define el ncleo de funcionalidades presente en las otras ediciones.
103
Java Enterprise Edition (Java EE): esta edicin constituye un conjunto ampliado respecto de la versin Standard, estando orientada a entornos empresariales.
Java Micro Edition (Java ME): esta versin define un subconjunto extendido
de la edicin Standard, especialmente diseada para su utilizacin en telfonos
mviles y PDAs (Personal Digital Assistant).
Java Card (JC): es la versin especfica del lenguaje Java para el mercado de
tarjetas inteligentes.
La Figura 3.1 muestra de manera grfica 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 cualquier aplicacin desarrollada para la plataforma Java. El usuario final utiliza el JRE
como parte del entorno Java instalado o como conectores (plugins) en sus navegadores web [57].
El JRE est constituido por una Java Virtual Machine (JVM), que es el programa
que interpreta el cdigo Java, y por las libreras de clases estndar 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 mquina virtual Java se inicia automticamente cuando se lanza el proceso
que se desea ejecutar y se detiene cuando ste finaliza. Su objetivo es el de proporcionar un entorno de ejecucin independiente de la plataforma hardware y del
104
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 especfica, capaz de interpretar y ejecutar instrucciones expresadas en un cdigo 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. Bsicamente
se sita en un nivel superior al hardware del sistema sobre el que se pretende ejecutar
la aplicacin, y acta como un puente que entiende tanto el bytecode como las
instrucciones nativas del sistema. As, cuando se escribe una aplicacin Java, se hace
pensando que ser ejecutada en una mquina virtual Java, que en ltima instancia
convierte de bytecode a cdigo nativo del dispositivo. La gran ventaja de la mquina
virtual Java consiste en permitir la portabilidad del mismo bytecode a diferentes
arquitecturas y sistemas operativos.
Adems de lo anterior, la JVM provee definiciones para el conjunto de instrucciones 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 implementacin aprobada de la JVM debe ser capaz de ejecutar cualquier clase incluida en las
especificaciones Java.
El cdigo resultante de la compilacin es ejecutado por la JVM, la cual realiza
la emulacin del conjunto de instrucciones, bien por un proceso de interpretacin o
ms habitualmente mediante un compilador JIT (Just In Time), como el compilador HotSpot de Sun. Esta ltima opcin convierte el bytecode a cdigo 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 cdigo de nuevo ya no es necesaria
una nueva interpretacin del bytecode, lo que permite una ejecucin considerablemente ms rpida en los casos es que la misma porcin de cdigo se ejecuta en ms
de una ocasin. Los principales inconvenientes son el tiempo necesario al principio
del proceso para la compilacin a cdigo 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 errneo no es ejecutada por no ser vlida.
En ms detalle, la JVM tiene instrucciones para los siguientes grupos de tareas:
Operaciones aritmticas.
Carga y almacenamiento de elementos.
Conversin de tipos.
Creacin y manipulacin de objetos.
Gestin de pilas (push/pop).
105
Transferencias de control (branching).

Invocacin y retorno de los mtodos.
Lanzamiento de excepciones.
3.2.3.
Caractersticas criptogrficas de Java
Dentro de la arquitectura Java, una de las interfaces ms importantes es Security

API, que est construida en torno al paquete java.security. La primera versin de
Security API para la versin JDK 1.1 introdujo el esquema JCA (Java Cryptography
Architecture) [106], que permita la generacin de firmas digitales y resmenes de
mensajes [78, 172].
En las siguientes versiones, J2SE extendi la funcionalidad JCA, incluyendo una
arquitectura tipo proveedor que permitiera implementaciones criptogrficas mltiples 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, generacin y acuerdo de claves y algoritmos MAC
(Message Authentication Code) [78, 172]. JCE constitua inicialmente un paquete
opcional del software J2SE, pero desde la versin 1.4 se incluy en el ncleo de la
distribucin J2SE, por lo que se suele considerar que los elementos JCA y JCE forman parte de un nico mdulo, siendo referido este esquema de seguridad como el
modelo JCA/JCE.
La independencia de algoritmos se logra mediante la definicin de motores o
proveedores criptogrficos. La Figura 3.2 ilustra la utilizacin de estos proveedores,
mediante un ejemplo en el que una aplicacin desea utilizar el algoritmo AES. El
funcionamiento es el siguiente: en lugar de codificar la lgica del algoritmo por s
misma, la aplicacin del ejemplo solicita a uno de los proveedores criptogrficos
(disponibles en ese entorno Java especfico) la utilizacin de su implementacin del
algoritmo AES.
Uno de los beneficios de este esquema consiste en que cualquier aplicacin 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, independientemente de quin haya implementado el proveedor criptogrfico que est
siendo utilizado. Algunos ejemplos de las clases incluidas en dichos motores son
MessageDigest (generacin de resmenes), Signature (creacin y verificacin de
firmas digitales), KeyFactory (generacin de claves para los distintos algoritmos
criptogrficos), Cipher (cifrado y descifrado de datos) y Mac (clculo de cdigos
MAC ).
Este esquema de seguridad es til, pero nicamente si la distribucin Java descargada por el usuario incluye algn proveedor por defecto. Afortunadamente, ste
106
Figura 3.2: Ejemplo de utilizacin de proveedores criptogrficos en Java
es el caso, y por ejemplo la versin Java SE 6 incluye los siguientes proveedores

criptogrficos:
SUN
SunRsaSign
SunJCE
SunPKCS11
SunJGSS
SunSASL
XMLDSig
SunPCSC
SunMSCAPI
La razn por la que se incluye un nmero tan elevado de proveedores se debe
a que, inicialmente, los motores criptogrficos se crearon de manera independiente
107
atendiendo a necesidades muy especficas, por lo que el grado de solapamiento de los

anteriores proveedores en relacin a los algoritmos soportados es mnimo. Por ejemplo, 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 generacin
de cdigos MAC (HmacSHA1, HmacSHA256, etc.) y algoritmos de cifrado simtrico
(DES, AES, etc.), y as sucesivamente.
Sin embargo, al examinar los algoritmos implementados en los distintos proveedores JCA/JCE desarrollados por Sun, no es posible encontrar ninguna referencia
a la criptografa de curva elptica. De hecho, antes de la versin J2SE 5.0, la arquitectura JCA/JCE no inclua clases para algoritmos relacionados con criptografa de
curva elptica ni tena estandarizados los nombres de dichos algoritmos para poder
realizar llamadas desde un programa Java, por lo que los usuarios que deseaban
emplear estos algoritmos dependan de software propietario de otras compaas. Esta situacin era muy negativa, y afortunadamente la versin J2SE 5.0 solucion en
parte este problema, ya que a partir de dicha versin se inici la inclusin de clases,
interfaces y nombres estndar 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
108
Adems, se definieron los nombres estndar que podan ser utilizados en las
llamadas a las clases, tal como se indica a continuacin:
Cipher: ECIES.
KeyPairGenerator: EC.
KeyFactory: EC.
KeyAgreement: ECDH, ECMQV.
Signature: NONEwithECDSA, SHA1withECDSA, SHA256withECDSA, SHA384withECDSA y SHA512withECDSA.
Con estos elementos, aunque los motores criptogrficos de Sun no incluyan implementaciones de ECC, las aplicaciones que deseen utilizar funcionalidades de criptografa de curva elptica al menos pueden hacer uso de bibliotecas criptogrficas
interoperables y adaptadas a la arquitectura JCA/JCE que hayan sido desarrolladas por terceras empresas.
3.3.
Bibliotecas criptogrficas
Existen multitud de bibliotecas (libraries) y mdulos criptogrficos 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 cdigo nativo, la mayora de estas implementaciones
estn desarrolladas en lenguajes como C++ o directamente en ensamblador. Sin
embargo, por ser el objetivo de la presente Tesis, en los siguientes apartados se
describirn en mayor detalle los principales productos Java: Cryptix, Bouncy Castle,
IAIK y FlexiProvider. La informacin recogida en los siguientes apartados representa
un resumen de [81], [82] y [83].
3.3. Bibliotecas criptogrficas
3.3.1.
109
Cryptix
Cryptix [56] fue la primera biblioteca criptogrfica de cdigo libre para el desarrollo 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 implementacin Java del estndar OpenPGP (Cryptix OpenPGP) y un paquete para
la utilizacin de criptografa de curva elptica (Cryptix Elliptix).
Sin actividad desde 2005, en su propia pgina 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 implementacin Java de los estndares IEEE
1363 [108], ANSI X9.62 [15] y X9.63 [16]. En la ltima versin proporcionada, el
paquete inclua soporte para aritmtica tanto sobre (con coordenadas proyectivas)
como sobre 2 (con coordenadas afines sobre base polinmica). Sin embargo, no
proporcionaba soporte para la generacin de los parmetros de la curva. Asimismo,
las operaciones de alto nivel (por ejemplo, la firma digital y la verificacin de dichas
firmas) tampoco estaban disponibles en dicha versin.
3.3.2.
Bouncy Castle
Legion of the Bouncy Castle [32] es un grupo de voluntarios que ha desarrollado

implementaciones de cdigo abierto de API criptogrficas en los lenguajes Java y
C#. Su ltima versin (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.
Adems de lo anterior, Bouncy Castle proporciona los siguientes recursos:
Una implementacin 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 generadores de listas de revocacin de certificados (CRL) y archivos PKCS#12
(utilizados para almacenar claves privadas junto con su correspondiente certificado de clave pblica).
110
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 criptografa de curvas elpticas, Bouncy Castle incluye implementaciones de ECDH, ECDSA y ECIES, aunque como elemento mejorable la
implementacin de ECIES slo permite un conjunto de parmetros fijos (algoritmo de acuerdo de clave ECDH, funcin HMAC-SHA1 y algoritmo de derivacin de
claves KDF2).
Puesto que son muchas las clases implementadas para dichas funcionalidades,
nicamente las siguientes clases del paquete org.bouncycastle.math.ec sern citadas como ejemplo:
ECCurve: representa una curva elptica mediante su ecuacin de Weierstrass.
ECFieldElements: representa un elemento del cuerpo finito utilizado.
ECPoint: representa los puntos de una curva elptica e implementa la aritmtica 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 implementacin de la clase ECPoint para realizar ataques
reales (por ejemplo, contra el esquema de cifrado ECIES). Esta vulnerabilidad fue
posteriormente corregida en la versin 1.33.
Por el grado de soporte (tanto para operaciones de firma como cifrado) y desarrollo continuado, Bouncy Castle es posiblemente uno de los mejores paquetes criptogrficos 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 fr Angewandte Informationsverarbeitung und Kommunikationstechnologie (Institute for Applied Information Processing and Communications) de la
Universidad de Graz [260] ha desarrollado un conjunto de herramientas criptogrficas escritas en Java, cuyos principales exponentes son IAIK-JCE (mdulo principal
con los algoritmos RSA, DES, AES, Blowfish, etc., y cuya versin ms reciente es la
3.18, lanzada en agosto de 2009), IAIK-iSaSiLk (implementacin Java de TLS 1.0 y
SSL 3.0, cuya versin 4.4 est disponible desde febrero de 2010) e IAIK-ECC (cuya
versin 2.19 fue lanzada en agosto de 2009).
3.3. Bibliotecas criptogrficas
111
El paquete IAIK Elliptic Curve Cryptography Library presenta las siguientes

caractersticas:
Es compatible con los estndares IEEE 1363 [108] y ANSI X9.62 [15].
Incluye una implementacin ECDSA compatible con la arquitectura de seguridad 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 aritmtica sobre cuerpos primos y binarios. En cuerpos binarios se
emplea nicamente la representacin sobre base polinmico por problemas de
patentes.
Permite definir y realizar operaciones con los puntos de la curva en coordenadas
afines y proyectivas.
Ofrece una implementacin de ECDH con y sin multiplicacin del cofactor.
Calcula la codificacin ASN.1 correspondiente a firmas digitales, claves pblicas y claves privadas.
Adems de lo anterior, la biblioteca IAIK-ECC permite las siguientes opciones
de personalizacin:
Preclculo de puntos: permite precalcular y almacenar un conjunto de puntos
para mejorar la generacin de claves y la realizacin de firmas posteriores. El
preclculo no tiene ninguna influencia sobre la verificacin de firmas, y debe
ser utilizada en caso de generacin de muchos puntos y firmas sobre la misma
curva. Por defecto esta opcin se encuentra desactivada.
Codificacin: es posible especificar el identificador de objeto (OID) o codificar
los parmetros explcitamente. Por defecto la opcin utilizada es la codificacin
explcita.
Comprobacin de puntos: la implementacin permite opcionalmente comprobar si los puntos decodificados se encuentran sobre una determinada curva.
Por defecto esta opcin se encuentra desactivada.
Es necesario destacar como aspecto negativo la ausencia de una implementacin
de ECIES. El software IAIK est disponible gratuitamente en forma de versiones
beta y de evaluacin, siendo necesario adquirir una licencia para la utilizacin del
producto completo.
112
3.3.4.
FlexiProvider
Los paquetes criptogrficos generados como un proyecto de cdigo libre en torno

al producto FlexiProvider [259] han sido desarrollados por un grupo de estudiantes y profesores de la Universidad Politcnica de Darmstadt. Entre ellos destacan
CoreProvider, que incluye algoritmos de cifrado simtrico y asimtrico, as como
funciones resumen y de generacin de cdigos MAC, y ECProvider, que incluye
implementaciones de los algoritmos ECDH, ECDSA y ECIES compatibles con los
estndares ANSI X9.62 [15], IEEE 1363 [108] y 1363a [109], SEC 1 [254] y SEC 2
[255].
El soporte de curvas incluidas en los estndares citados es muy amplio. A continuacin se presentan los nombres identificativos de las curvas que el paquete ECProvider en su ltima versin (1.6p7) permite utilizar, donde el nmero asociado
a cada curva hace referencia al tamao en bits de los elementos del cuerpo finito
empleado.
Curvas sobre de ANSI X9.62: prime192v1, prime192v2, prime192v3, prime239v1, prime239v2, prime239v3 y prime256v1.
Curvas sobre 2 de ANSI X9.62: c2pnb163v1, c2pnb163v2, c2pnb163v3, c2tnb191v1, c2tnb191v2, c2tnb191v3, c2pnb208w1, c2tnb239v1, c2tnb239v2, c2tnb239v3, c2pnb272w1, c2tnb359v1, c2pnb368w1 y c2tnb431r1.
Curvas sobre de SEC 2: secp112r1, secp112r2, secp128r1, secp128r2, secp160k1, secp160r1, secp160r2, secp192k1, secp224k1, secp224r1, secp256k1, secp384r1 y secp521r1.
Curvas sobre del Grupo Brainpool: brainpoolP160r1, brainpoolP192r1,
brainpoolP224r1, brainpoolP256r1, brainpoolP320r1, brainpoolP384r1 y brainpoolP512r1.
Curvas sobre del Grupo CDC: desde la curva primeCurve 1 a la curva
primeCurve 38.
La versin del algoritmo ECIES del paquete ECProvider es notablemente flexible, permitiendo un elevado nmero de combinaciones de parmetros. Adems
del cdigo binario y la documentacin, su pgina web incluye ejemplos y tutoriales
sobre cmo utilizar los paquetes comentados. Por todos estos motivos, los paquetes del proyecto FlexiProvider constituyen una alternativa muy interesante para el
desarrollo de aplicaciones que utilicen funcionalidades ECC.
3.4. Java Card
3.4.
3.4.1.
113
Java Card
Introduccin al lenguaje Java Card
La tecnologa Java Card combina un subconjunto del lenguaje Java con un entorno de ejecucin optimizado para las tarjetas inteligentes [48, 100], que se caracterizan 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 caractersticas de seguridad de las tarjetas
inteligentes. Poco despus 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 tecnologa
Java Card.
Tras la presentacin 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 versin era bastante diferente de la inicial, ya que
proporcionaba un mecanismo de programacin orientado a objetos y mejoraba el
nivel de detalle de la especificacin del entorno de ejecucin de aplicaciones, aunque
por contra no inclua la especificacin del formato de los applet (aplicaciones Java
Card) para su descarga.
Debido a la necesidad de adaptar las capacidades del lenguaje Java a las limitaciones fsicas de las tarjetas inteligentes, desde su inicio se hizo evidente la
imposibilidad de implementar algunas de sus caractersticas, tal como se describe
en detalle en 3.4.5. Ello no ha impedido, sin embargo, su masiva utilizacin en
industrias como la de la telefona mvil.
La versin Java Card 2.1 fue lanzada en marzo de 1999 y consista en tres
especificaciones: Java Card API, Java Card Runtime Environment y Java Card
Virtual Machine.
Java Card API: define los paquetes Java tanto del ncleo como de las extensiones disponibles para las tarjetas inteligentes.
Java Card Runtime Environment (Java Card RE): define el comportamiento
en tiempo de ejecucin de los applets.
Java Card Virtual Machine (JCVM): define un subconjunto del lenguaje Java
y una mquina virtual para las tarjetas inteligentes.
Aparte de mejorar las API existentes, la versin 2.1 defini explcitamente la
mquina virtual y el formato de applets de forma que su descarga fuera interoperable.
114
La versin 2.2 fue lanzada en septiembre de 2002, y entre sus novedades se

pueden citar las siguientes:
Implementacin de JCRMI (Java Card Remote Method Invocation).
Soporte para cuatro canales lgicos.
Mejoras en la gestin de los recursos de memoria.
Inclusin de nuevas clases para algoritmos criptogrficos (AES, claves para
algoritmos de curva elptica, etc.).
En marzo de 2006 se anunci la disponibilidad de la revisin Java Card 2.2.2,
que incluy las siguientes mejoras:
Extensin del soporte de canales lgicos, permitiendo la gestin de hasta veinte
canales.
Implementacin de los algoritmos resumen (tambin llamados algoritmos hash
[78, 172]) SHA-256, SHA-384 y SHA-512.
Inclusin de un paquete de extensin con clases relacionadas con la tecnologa
de reconocimiento biomtrico.
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 ediciones diferenciadas:
Classic Edition: representa una evolucin de Java Card 2.2.2, incluyendo no
slo la correccin de errores detectados desde el lanzamiento de la anterior
versin, sino tambin nuevas caractersticas 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 versin presenta un entorno de ejecucin mejorado y
una nueva mquina virtual que proporciona caractersticas 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 utilizacin en la versin 3.0 Classic Edition:
3.4. Java Card
115
java.lang
Este paquete representa el pilar fundamental del lenguaje Java, con soporte para algunas de sus clases bsicas. En Java Card, este paquete constituye
un subconjunto del paquete java.lang de Java Standard Edition, donde slo
estn permitidas algunas clases como Object (la raz de todas las clases Java) o Throwable (la clase base para todas las excepciones), y dentro de ellas
nicamente se encuentran disponibles algunos mtodos.
java.io
Se trata de un subconjunto del paquete java.io de la edicin 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
jerarqua de excepciones idntica a la de la versin Standard.
java.rmi
Incluye las clases bsicas para la funcionalidad JCRMI.
javacard.framework
Representa el conjunto de clases e interfaces que conforman el ncleo de la
funcionalidad de un applet Java Card. Por ejemplo, incluye la clase Applet
que es bsica para la ejecucin e interaccin de un applet con el JCRE, o
la clase APDU utilizada para la comunicacin con la tarjeta inteligente con
independencia del protocolo fsico 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 reenviar las APDU entrantes a las aplicaciones registradas. Tambin incluye una
interfaz que incluye mtodos para procesar los comandos APDU de mltiples
servicios.
javacard.security
Su diseo se basa en el paquete java.security de Java SE e incluye las clases
e interfaces que dan soporte a algunas de las funcionalidades criptogrficas de
las tarjetas Java Card, por ejemplo las relacionadas con generacin de nmeros
aleatorios, resmenes y firmas digitales.
javacardx.apdu
Se trata del primer paquete de extensin del API Java Card. Los paquetes de
extensin son fcilmente identificables por comenzar siempre por el trmino
javacardx. En concreto, este API permite la comunicacin con la tarjeta
mediante APDU segn el formato definido en las normas ISO/IEC 7816.
116
javacardx.biometry
Esta interfaz contiene la funcionalidad necesaria para implementar capacidades
biomtricas en Java Card.
javacardx.crypto
Se trata de un paquete de extensin que incluye las funcionalidades criptogrficas para el cifrado y descifrado de datos, funcionalidades que pueden estar sujetas a controles de exportacin. Tanto este paquete como el
javacard.security definen las interfaces que los applet utilizarn, pero no
proporcionan ninguna implementacin, que debe ser desarrollada por el proveedor de la JCRE (quien, habitualmente es el propio fabricante de la tarjeta).
Los elementos fundamentales de este paquete son la clase Cipher, que proporciona mtodos para cifrar y descifrar mensajes, y la interfaz KeyEncryption
que define los mtodos para permitir el acceso a la implementacin de una
clave determinada.
javacardx.external
Este paquete permite el acceso a subsistemas de memoria que no son directamente gestionables por el entorno de ejecucin 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 implementacin
eficiente de applets Java. Si el paquete est presente, tambin deben estarlo
los subpaquetes math, tlv y util.
javacardx.framework.math
Este paquete contiene funcionalidad comn para la utilizacin de aritmtica
BCD (Binary-Coded Decimal) y el clculo de paridades.
javacardx.framework.tlv
Paquete para la gestin de datos con formato BER TLV basados en las reglas
de codificacin ASN.1 BER del estndar ISO/IEC 8825-1 [127], incluyendo la
edicin 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 gestin de arrays de
componentes de tipo byte, short o int.
javacardx.framework.util.intx
Este paquete incluye la clase JCint, equivalente en su definicin a la clase
javacard.framework.Util, pero con el objetivo de utilizar datos de tipo int.
3.4. Java Card
3.4.3.
117
Java Card Runtime Environment
La especificacin Java Card Runtime Enviroment (JCRE) define el entorno de

ejecucin de un dispositivo Java Card. Una implementacin del JCRE debe proporcionar una implementacin de la mquina virtual (JCVM), de las interfaces de
programacin (JC API) y de cualquier otro elemento relacionado con la tecnologa
Java Card y recogido en sus especificaciones. Sun Microsystems proporciona una
implementacin de referencia de estos elementos, aunque cada fabricante de tarjetas
inteligentes normalmente desarrolla su propia implementacin.
JCRE define claramente el ciclo de vida tanto de la Java Card VM como de las
aplicaciones, el modo de seleccin de los applets y el mecanismo de comparticin 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 esquemtica la arquitectura Java Card con los
diferentes niveles lgicos 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 ejecucin
3.4.3.1.
Ciclo de vida de la mquina virtual Java Card
El ciclo de vida de la mquina 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 alimentacin
118
a la tarjeta, puesto que su estado se almacena en memoria no voltil (al contrario

de lo que ocurre con los datos almacenados en la RAM, que s se pierden cuando no
existe alimentacin). Una vez la JCVM comienza su ejecucin, inicializa el JCRE
y crea todos los objetos del entorno que estarn 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 unvocamente
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 seleccin directa de aplicaciones.
Para adaptarse a las especificaciones Java Card, todos los applets deben extender la clase abstracta Applet, que define los mtodos 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: Mtodos para la gestin 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 mtodo esttico Applet.install(), tras lo cual se produce el
registro efectivo mediante el mtodo Applet.register(). Una vez el applet est
instalado y registrado, permanece en estado inactivo hasta que es seleccionado a
travs del mtodo Applet.select(). A partir de la seleccin del applet, el JCRE
se encarga de recibir las APDU enviadas por la aplicacin externa a travs del
lector de tarjetas y entregarlas al applet activo. La Figura 3.5 muestra de forma
global el intercambio de comandos entre la aplicacin externa, el JCRE y el applet
seleccionado, para lo cual el JCRE utiliza el mtodo Applet.process(). En cuanto
a las posibles excepciones que puedan generarse durante la ejecucin, y que no
sean gestionadas por el propio applet, el JCRE se encarga de atraparlas e informar
debidamente a la aplicacin externa.
3.4. Java Card
119
Figura 3.5: Mtodos implicados en la gestin de un applet
Al finalizar su ciclo de vida, el JCRE notifica al applet que ha sido deseleccionado

invocando el mtodo Applet.deselect(), que tpicamente incluye la lgica para
almacenar los datos que todava se encontraran en la memoria RAM y devolver el
applet a su estado inactivo.
3.4.3.3.
Sesiones Java Card y canales lgicos
Java Card utiliza el concepto de canal lgico para permitir varias sesiones simultneas, con un lmite fijo de una sesin por canal lgico. Puesto que el procesamiento
de una APDU no puede ser interrumpido, y cada APDU contiene en su byte CLA
una referencia al canal lgico a utilizar, sucesivas APDU pueden comunicarse con
un nmero distinto de applets, permitiendo la ilusin de la ejecucin simultnea de
distintos applets, cuando en realidad en un momento dado slo un applet est siendo
ejecutado.
El nmero de canales lgicos soportados en Java Card ha aumentado con el paso
del tiempo. Mientras que en las versiones Java Card 2.1.x los comandos slo podan
ser procesados por un nico applet, Java Card 2.2 y 2.2.1 permitan utilizar un
mximo de cuatro canales lgicos, nmero 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 automtica a travs del canal 0 cada vez que la tarjeta recibe alimentacin.
ste es el caso de las tarjetas Java Card utilizadas en telefona mvil, donde la aplicacin SIM es seleccionada automticamente, de manera que los telfonos mviles
no necesitan realizar la seleccin de dicha aplicacin. La documentacin, sin embargo, no detalla cmo especificar estos applets por defecto, por lo que los mecanismos
utilizados hasta el momento se basan en procedimientos propietarios dependientes
de cada fabricante.
120
3.4.3.4.

Aislamiento de applets y comparticin de objetos
La plataforma Java Card es un entorno multiaplicacin 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 ejecucin que controla
el acceso a los objetos asociados a ese contexto. El lmite entre un contexto de
ejecucin y otro es lo que se suele denominar cortafuegos (firewall ). El cortafuegos
es la mejora de Java Card al concepto genrico de separacin de programas en
ejecucin 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
porcin de memoria virtual de manera que, por defecto, un objeto puede acceder
nicamente a mtodos y datos pblicos de aquellos objetos que residan dentro del
rea delimitada por dicho cortafuegos.
Para los casos en que sea necesaria una gestin ms avanzada, Java Card permite
la comparticin de objetos a travs del cortafuegos. Para ello, es necesario definir en
relacin a cada objeto a compartir su contexto de ejecucin. La Figura 3.6 muestra
estos conceptos, siendo el flujo tpico el siguiente:
Figura 3.6: Comparticin de objetos en Java Card
1. El applet a solicita acceso a la interfaz compartida del applet c mediante una

llamada al mtodo JCSystem.getAppletShareableInterfaceObject().
2. El entorno de ejecucin JCRE solicita entonces al applet c su interfaz compartida invocando el mtodo getShareableInterfaceObject() en nombre del
applet a.
3.4. Java Card
121
3. Si el applet c permite la comparticin, el applet a obtendr una referencia

a los objetos compartidos del applet c, que podr utilizar a partir de dicho
momento.
En comparacin, puesto que los applets a y b estn en el mismo contexto de
ejecucin, no necesitan realizar la operativa anterior para compartir objetos.
3.4.4.
Java Card VM
Tal como se ha comentado anteriormente, la especificacin de la JCVM define

un subconjunto del lenguaje de programacin Java y una mquina virtual adaptada
a las tarjetas inteligentes, lo que incluye entre otros elementos la representacin
de datos binarios, el formato de ficheros y el conjunto de instrucciones que son
interpretadas por la mquina virtual.
Por definicin, la mquina virtual Java Card est dividida en dos partes: una
externa a la tarjeta y otra que se ejecuta en la propia tarjeta. La mquina virtual
incluida en la tarjeta interpreta el bytecode y gestiona las clases y los objetos. La
parte externa de la mquina virtual, en comparacin, carga, verifica y prepara las
clases Java para su ejecucin posterior en la tarjeta. A un mayor nivel de detalle, la
parte externa (tambin denominada herramienta de conversin) toma como datos
de entrada las clases Java Card y produce un fichero de extensin 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 especificacin Java Card.
La Figura 3.7 muestra un esquema bsico del proceso de conversin de ficheros
de tipo class a ficheros CAP.
Figura 3.7: Esquema de conversin a ficheros CAP
122
3.4.5.
Limitaciones del lenguaje Java Card
En comparacin con las caractersticas del lenguaje disponible en la versin

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.
Trminos y tipos no soportados
Los trminos native, synchronized, transient, volatile, strictfp, enum
y assert hacen referencia a mtodos nativos, ejecucin multihilo, datos en formato de coma flotante, gestin de memoria y depuracin de fallos (debugging),
los cuales no estn soportados.
Por otra parte, Java Card no soporta los tipos de datos bsicos char, double,
float y long, ni los objetos de tipo String. Tampoco permite utilizar matrices
de ms de una dimensin.
Carga dinmica de clases
Java Card no permite la carga dinmica de clases, por lo que los applets que se
ejecutan en la tarjeta slo pueden hacer referencia a clases que ya estuvieran
presentes en la tarjeta antes del inicio de la ejecucin del applet.
Ejecucin multihilo
A diferencia de Java SE, Java Card no permite mltiples hilos de ejecucin.
Por dicho motivo, los applets Java Card no pueden utilizar la clase Thread ni
ninguno de los trminos relacionados con la ejecucin multihilo.
Clonado
Java Card no permite el clonado de objetos, por lo que la clase Object no
implementa el mtodo clone, ni proporciona un interfaz Cloneable que pueda
ser utilizado por las aplicaciones.
Mximas longitudes asociadas a paquetes, clases y mtodos
Un paquete en Java Card puede hacer referencia como mucho a otros 128
paquetes, y su nombre puede contener como mximo 255 caracteres que en
formato UTF-8 (Unicode Transformation Format 8-Bit) utilicen un byte por
carcter. Una clase puede implementar hasta 15 interfaces diferentes, incluyendo las interfaces implementadas por superclases. A su vez, una interfaz puede
heredar como mximo de 14 superinterfaces. Adems, una clase puede implementar un mximo de 128 mtodos de instancia, ya sean pblicos o protegidos.
Este lmite incluye los mtodos heredados. Por ltimo, el nmero mximo de
variables que pueden ser utilizados en un mtodo es de 255.
3.4. Java Card
3.4.6.
123
Caractersticas criptogrficas en Java Card
De forma equivalente a la situacin en Java SE, las API criptogrficas de Java

Card definen una serie de servicios criptogrficos y las interfaces para acceder a
dichos servicios, lo cual en la prctica permite la separacin de interfaces e implementaciones. Por ofrecer un ejemplo sencillo, para proporcionar la funcionalidad de
resmenes mediante el algoritmo MD5, un proveedor JCRE puede crear una implementacin de la clase MessageDigestMD5 que extienda la clase MessageDigest. De
esta forma, la clase MessageDigestMD5 impondra sus mtodos frente a los de la
clase base en lo que respecta a la implementacin del algoritmo MD5.
Entrando en detalle, las API criptogrficas de Java Card replican el comportamiento 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 funcionalidad a ofrecer contuviera en el momento de su diseo limitaciones para su exportacin. En los siguientes apartados se detallan las principales caractersticas de ambos
paquetes.
3.4.6.1.
javacard.security
El paquete javacard.security contiene varias interfaces para implementar claves simtricas y asimtricas, la clase generadora de claves (key builder ), las clases
para realizar autenticaciones de resmenes de mensajes y firmas digitales, as como la clase utilizada en la generacin de datos aleatorios (los cuales son producidos en la forma de arrays de tipo byte de longitud variable y definible en la
llamada al mtodo). 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
AESKey
Checksum
CryptoException
DESKey
DSAKey
DSAPrivateKey
DSAPublicKey
Descripcin
Representa una clave AES de 128, 192 256 bits
Clase abstracta base para algoritmos de checksum
Excepcin de tipo criptogrfico
Representa una clave DES simple de 64 bits, una
clave para TDES de 128 bits con dos claves simples o una clave TDES de 192 bits con tres claves
simples
Interfaz base para implementaciones de claves pblicas y privadas utilizadas por el algoritmo DSA
Utilizada para firmar datos con el algoritmo DSA
Utilizada para verificar firmas digitales empleando
el algoritmo DSA
124

Clase o interfaz
Descripcin
ECKey
Interfaz base para implementaciones de claves pblicas y privadas para curvas elpticas definidas sobre 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 compartidos 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 correspondera 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 implementacin de algoritmos de acuerdo de clave como Diffie-Hellman
y ECDH
KeyBuilder
Clase utilizada para generar un objeto de tipo clave
KeyPair
Contenedor para un par de claves (una pblica 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
asimtricos
PublicKey
Interfaz base para claves pblicas de algoritmos
asimtricos
RandomData
Clase abstracta base para la generacin 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
mdulo/exponente
RSAPublicKey
Interfaz de una clave pblica RSA
SecretKey
Interfaz base para todas las claves de algoritmos
simtricos
Signature
Clase abstracta base para algoritmos de firma digital
3.4. Java Card
125
Clase o interfaz
Descripcin
SignatureMessageRecovery Interfaz para operaciones de firma con recuperacin 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 extensin 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.
Clase o interfaz
Cipher
KeyEncryption
Descripcin
Clase abstracta base que proporciona la funcionalidad
para cifrado y descifrado de datos
Permite implementar claves para acceder a datos cifrados
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 versin en incluir soporte para criptografa de curva
elptica. En concreto, en dicha versin se definieron los siguientes elementos:
Nuevas clases ECKey, ECPrivateKey y ECPublicKey para la creacin y gestin
de claves ECC pblicas y privadas sobre cuerpos primos y binarios.
Extensin de la clase KeyPair para permitir la manipulacin de pares de claves
sobre cuerpos y 2 .
Extensin 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 travs de la funcin
SHA-1.
Extensin de la clase KeyBuilder, que define las longitudes de clave permitidas
para ECC y otros criptosistemas. En el caso de curvas elpticas sobre cuerpos
primos, las longitudes vlidas 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.
126
Extensin de la clase Signature con la implementacin del esquema de firma

digital ECDSA utilizando la funcin resumen SHA-1.
Las versiones Java Card 2.2.1 y 2.2.2 no introdujeron ninguna novedad en relacin a la criptografa de curvas elpticas. En cambio, la versin Java Card 3.0 s
presenta algunas novedades en cuanto al soporte ECC, tal como se detalla a continuacin:
Mientras que las longitudes permitidas para los cuerpos binarios continan
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 implementacin 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 funcin es
directamente el elemento secreto compartido, eliminando la utilizacin de la
funcin SHA-1 en la generacin de ese dato.
Debido a la disponibilidad en Java Card de la familia de funciones resumen
SHA-2, la implementacin del esquema de firma digital ECDSA permite a
partir de la versin Java Card 3.0 utilizar ECDSA en combinacin con las
funciones SHA-1, SHA-224, SHA-256, SHA-384 y SHA-512.
3.5.
Programacin en Java Card
El desarrollo de una aplicacin Java Card conlleva los siguientes pasos:

1. Escribir el cdigo Java de la aplicacin en ficheros con extensin .java.
2. Compilar el cdigo para obtener ficheros con extensin .class.
3. Convertir los ficheros .class en un fichero CAP.
4. Verificar que el fichero .cap es vlido.
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 tamao de la aplicacin. Los ficheros
CAP son en realidad contenedores con formato JAR (que a su vez son una extensin
del formato de compresin ZIP) donde se almacenan los paquetes convertidos. Junto
con el fichero .cap, la herramienta de conversin de Java Card genera un fichero de
3.5. Programacin en Java Card
127
Figura 3.8: Fases del desarrollo de un applet Java Card
exportacin con extensin .exp que contiene informacin sobre la interfaz pblica
de todas las clases del paquete.
La Figura 3.8 muestra de forma grfica el proceso completo de desarrollo de un
applet Java Card.
Captulo 4
Estudio y anlisis del esquema de
cifrado ECIES
Resumen del captulo

En este captulo se describen de forma completa las distintas variantes de
ECIES incluidas en los estndares ANSI X9.63, IEEE 1363a, ISO/IEC
18033-2 y SECG SEC 1, identificando las principales diferencias existentes entre los cuatro estndares mencionados. De forma adicional, se
incluye un anlisis de la seguridad de ECIES que recoge las indicaciones y recomendaciones sugeridas en los estudios ms recientes sobre este
tema.
4.1.
Criptosistemas de curvas elpticas
Los primeros esquemas de cifrado basados en curvas elpticas que surgieron fueron 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 seguro) 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 envo de un cierto mensaje al usuario V, donde es una curva elptica
definida sobre el cuerpo finito de elementos y existe una relacin pblicamente
conocida de mensajes en claro y puntos de la curva .
129
130
Algoritmo 4.1 Criptosistema Massey-Omura con curvas elpticas

1. U debe generar un nmero 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 continuacin, V debe generar un nmero entero aleatorio (donde igualmente 0 < < # y los valores y # son primos relativos), y transmitir
el punto de la curva a U.
3. Tras su recepcin, 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 relacin pblicamente conocida de mensajes en claro y puntos de la curva, el Algoritmo 4.2 muestra
los pasos necesarios para que el usuario U enve el mensaje cifrado al usuario V
utilizando la versin del esquema de ElGamal con curvas elpticas.
Algoritmo 4.2 Criptosistema ElGamal con curvas elpticas
1. V debe elegir aleatoriamente un valor y hacer pblica 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 recepcin 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 continuacin el punto as generado de + .
Una de las principales desventajas de los esquemas anteriores consiste en el
limitado nmero de mensajes a cifrar, siendo necesario establecer una relacin entre
cada mensaje y un punto de la curva elptica. Si bien es cierto que si se utilizan
curvas elpticas cuyo orden # es un valor elevado esta limitacin es ms terica
que prctica, 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 estn
estipulados (empresas, pequeos grupos de usuarios, etc.).
El criptosistema Menezes-Vanstone con curvas elptica fue diseado precisamente para solventar esa limitacin, 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 elpticas
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 fcilmente en un par ordenado (por ejemplo, utilizando una codificacin
similar a la empleada en los ejemplos de 2.4.2.2 y 2.4.3.2). Como contrapartida negativa, en lugar de transformar cada mensaje en un nico punto de la curva
(independientemente de cul fuera el mensaje, como ocurra 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
elpticas. En la notacin empleada, el punto tiene orden y es un generador de
un subgrupo cclico de , mientras que como es habitual y = representan
respectivamente la clave privada y pblica del usuario V.
Algoritmo 4.3 Criptosistema Menezes-Vanstone con curvas elpticas
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 continuacin, U enviar el criptograma = (0 , 1 , 2 ) a V.
3. Tras la recepcin del criptograma, el usuario V recuperar el par ordenado = (1 , 2 ) mediante las operaciones 1 = 1 1
(mod ) y
1
1
2 = 2 2 (mod ), donde 0 = (1 , 2 ).
En este esquema, el factor de expansin 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
nmero total de elementos del cuerpo finito a transmitir es 4. Si se utiliza compresin
de puntos (ver 2.6.5), entonces el factor de expansin se reduce prcticamente a
1.5, puesto que adems de la primera coordenada del punto es necesario enviar un
byte que incluye la informacin necesaria para recuperar la segunda coordenada.
En comparacin, el factor de expansin de la variante de ElGamal con curvas
elpticas es 2 si se considera que el mensaje en claro es un punto de la curva, mientras
que si se interpreta que el nmero total de mensajes es #( ) , entonces el
factor de expansin sera aproximadamente 4 [218]. El hecho de tener un factor de
expansin igual a 2 conlleva que el cifrado de volmenes de informacin elevados
genere criptogramas de tamao mucho mayor que utilizando un algoritmo de clave
simtrica como por ejemplo AES.
132
Otra desventaja derivada del diseo del criptosistema consiste en la realizacin

de operaciones con los puntos de las curvas elpticas en cada proceso de cifrado. Al
ser necesario dividir los mensajes en claro de gran tamao en mltiples segmentos
y realizar un operacin de cifrado asimtrico con cada uno de ellos, la diferencia
en tiempo de ejecucin del esquema Menezes-Vanstone respecto a un algoritmo de
cifrado simtrico se incrementa conforme aumenta el nmero de segmentos a cifrar.
De manera adicional a las desventajas de carcter prctico sealadas, Klaus
Kiefer demostr en 1998 que, bajo ciertas condiciones, este criptosistema es inseguro
[146]. Kiefer demostr adems que, en contra de lo estipulado en su especificacin,
este criptosistema no puede ser considerado un algoritmo de cifrado probabilstico.
Debido a todas las razones comentadas, con el paso de los aos la comunidad
acadmica ha ido abandonando el estudio de los tres criptosistemas citados anteriormente en este apartado. Como ejemplo ilustrativo, mientras que en la primera
edicin de la obra de Douglas Stinson [257] se incluan la versin con curvas elpticas del esquema de ElGamal y el criptosistema Menezes-Vanstone, a partir de su
segunda edicin esos esquemas fueron reemplazados por ECIES. Incluso en uno de
los ltimos libros sobre curvas elpticas 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 bsqueda de un criptosistema de curvas elpticas que fuera
prctico y seguro, sino que nicamente provoc un cambio de direccin, pasando a
ocupar el centro de atencin los esquemas de cifrado hbridos (descritos en 2.5).
Los principales esquemas hbridos que emplean curvas elpticas 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 nmero de
estndares (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 seleccin
final de NESSIE [195, 196].
Aunque a lo largo de los apartados restantes de este captulo se describe en detalle 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 continuacin un
resumen comparativo del proceso de cifrado de los tres esquemas en el Cuadro 4.1,
utilizando una notacin equivalente a fin de resaltar las semejanzas entre ellos. Aunque 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 aadido la fase DEM (utilizando como
ejemplo la funcin DEM1 de [136]) a fin de presentar el proceso completo de cifrado
133
en los tres esquemas.

ECIES
PSEC
[1, 1]
{0, 1}
=
= KDF (032 )
=
= 1 2
= ( , )
= (mod )
=KDF ( )
=
= 1 2
=
=ENC 1 ()
= KDF (132 )
tag=MAC2 ()
=ENC 1 ()
=(, ,tag)
tag=MAC2 ()
=(, , ,tag)
ACE
[1, 1]
=
=
=
= ( , )
= ( )
= (mod )
= +
=KDF ( )
= 1 2
=ENC 1 ()
tag=MAC2 ()
=(, , , ,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 cclico del grupo de puntos de la curva elptica
utilizada en los clculos.
: orden del punto .
: clave privada temporal del usuario U que enva el criptograma.
: clave pblica temporal de U, de manera que = .
: clave privada permanente del usuario V que recibe el criptograma.
: clave pblica permanente de V. En ECIES y PSEC, = , mientras
que en ACE la clave pblica 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 nmero entero 0.
132 : cadena binaria de 32 bits que representa el nmero entero 1.
: cadena binaria de ( + 128) bits que debe interpretarse como un nmero
entero, donde es un parmetro de seguridad que toma el valor de la longitud
en bits asociada al cuerpo finito sobre el que se construye la curva elptica (es
decir, el valor log2 o , segn el tipo de cuerpo finito).
134
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 pblica del receptor del criptograma
es el punto de la curva = , mientras que en ACE la clave pblica est
formada por cuatro puntos, de manera que = (, , , ).
PSEC utiliza dos veces la funcin KDF, mientras que ECIES y ACE slo la
utilizan una vez.
ECIES y ACE utilizan la primera coordenada de un punto de la curva generado durante los clculos intermedios (en lugar de las dos coordenadas) como
parmetro de entrada de la funcin KDF, mientras que en PSEC es obligatorio
utilizar las dos coordenadas.
PSEC es el nico esquema que utiliza la funcin XOR durante el proceso
de generacin de claves (independientemente de su posible utilizacin como
funcin de cifrado simtrico).
Los criptogramas de ECIES estn formados por tres elementos (el punto , el
mensaje cifrado y la etiqueta tag), mientras que los criptogramas de PSEC
aaden adems el elemento y los de ACE incluyen dos puntos de la curva
elptica ( y ).
Una vez presentado el esquema general del proceso de cifrado de los tres esquemas, y con el fin de seleccionar el ms adecuado, es necesario evaluar tres aspectos
fundamentales: eficiencia, seguridad y adaptabilidad a las plataformas hardware de
trabajo.
Respecto al anlisis de su eficiencia, los siguientes cuadros muestran datos tomados de [196]. En concreto, el Cuadro 4.2 muestra una comparativa del nmero 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.
Producto escalar
Suma de puntos
Generacin de nmeros aleatorios
Llamadas a funcin KDF
Llamadas a funcin H
Llamadas a funcin MAC
Llamadas a funcin resumen
ECIES
2
0
1
1
0
1
1
PSEC
2
0
1
2
1
1
1
ACE
5
1
1
1
1
1
1
Cuadro 4.2: Nmero de operaciones para el cifrado en ECIES, PSEC y ACE
135
Por su parte, el Cuadro 4.3 presenta el nmero de ciclos de reloj y el tiempo de

procesado de la operacin 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].
Ciclos de reloj (miles)

Tiempo (milisegundos)
ECIES
2500
5
PSEC
2500
5
ACE
6250
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 esquemas de cifrado es su factor de expansin. El Cuadro 4.4 muestra las longitudes
en bytes de las claves pblicas y privadas, as como del criptograma generado, considerando que la longitud de los elementos del cuerpo, del mensaje a cifrar y de la
salida de la funcin resumen son, respectivamente, 20, 16 y 20 bytes, y habiendo
sido utilizada la tcnica de compresin de puntos en la representacin binaria de los
puntos de la curva.
Clave privada
Clave pblica
Criptograma
ECIES
20
20
36
PSEC
20
20
52
ACE
80
80
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 acadmica. El informe final del proyecto NESSIE
seleccion los esquemas PSEC y ACE, dejando fuera de la seleccin 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 clculos es correcto en
funcin de los dems parmetros del criptograma), mientras que en comparacin
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 anlisis de la
seguridad de ECIES) existen diversas soluciones para evitar la maleabilidad benigna.
Adems, 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 anlisis
efectuado por NESSIE es incompleto y que, con los datos conocidos, no se puede
afirmar que PSEC sea ms seguro que ECIES. Los documentos de NESSIE fueron
redactados en 2004 y, debido a la finalizacin del proyecto de la Unin Europea al
que estaban adscritos, no han sido revisados ni se han generado nuevas versiones.
136
El ltimo aspecto que es necesario tener presente en la evaluacin 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 versin PC
no existen limitaciones a este respecto, puesto que cualquier funcin criptogrfica
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 mtodos
para realizar directamente operaciones de suma de puntos o productos escalares,
existiendo en cambio la posibilidad de utilizar la funcin Diffie-Hellman con curvas
elpticas, lo que se puede considerar equivalente al producto escalar pero con la particularidad de que el API de Java Card define como resultado de dicha funcin la
primera coordenada del punto de la curva que representa la multiplicacin o bien la
salida de una funcin resumen que tome como entrada dicha coordenada.
Tras evaluar los tres criterios mencionados (rendimiento, seguridad y funcionalidad disponible en las plataformas PC y Java Card), en vista de sus caractersticas,
y considerando como elemento positivo adicional su mayor difusin, el esquema seleccionado para su implementacin en esta Tesis Doctoral fue ECIES. Las restantes
secciones de este captulo describen con todo detalle el esquema ECIES, incluyendo
la comparacin de las versiones aparecidas en los distintos estndares existentes y
el anlisis de su seguridad.
4.2.
Esquema de cifrado DHIES
En 1997, Mihir Bellare y Philip Rogaway [26] presentaron un esquema de cifrado denominado DLAES (Discrete Logarithm Augmented Encryption Scheme), el
cual fue mejorado posteriormente por los mismos autores junto con Michel Abdalla, renombrndolo primero como DHAES (Diffie-Hellman Augmented Encryption
Scheme) en 1998 [8] y posteriormente como DHIES (Diffie-Hellman Integrated Encryption Scheme) en 2001 [9, 10], a fin de evitar confusiones con el algoritmo AES.
De forma simplificada, se puede afirmar que DHIES representa una extensin
mejorada del algoritmo ElGamal. La principal aportacin de DHIES respecto a la
versin original de ElGamal [69], o a la implementacin que hizo Koblitz de ese
mismo algoritmo [147], consiste en reunir bajo un nico esquema operaciones de
clave pblica, cifrado simtrico, autenticacin mediante cdigos MAC y clculo de
resmenes. En comparacin, tanto ElGamal como Koblitz se limitaban a generar
una clave simtrica con la que se cifraba el mensaje original, sin incluir los dems
elementos propios de un esquema integrado. Debido precisamente a este nivel de
integracin, DHIES proporciona seguridad contra ataques de texto cifrado elegido, ante los cuales el algoritmo de ElGamal era vulnerable [10], sin necesidad de
aumentar el nmero de operaciones o la longitud de las claves.
La Figura 4.1 muestra grficamente 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 pblica del destinatario, y respectivamente las claves temporales pblica
y privada del remitente, el algoritmo de cifrado simtrico, el algoritmo de
generacin de cdigos MAC y H la funcin resumen. Es necesario tener en cuenta
que esta descripcin de DHIES emplea de forma genrica un grupo finito cclico
con notacin multiplicativa, de ah que el trmino represente la multiplicacin
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
pblica temporal. Este dato permite que el diseo 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 funcin resumen y
se divide el resultado en dos elementos, una clave MAC denominada macKey y una
clave para el algoritmo de cifrado simtrico denominada encKey. A continuacin se
cifra el mensaje con la clave encKey y se pasa el mensaje cifrado denominado
encM por la funcin MAC utilizando la clave macKey, dando como resultado el
elemento tag. Por ltimo, se enva al destinatario de forma conjunta la clave pblica
138
temporal , el resultado tag de la funcin MAC y el mensaje cifrado encM.

En este esquema, es muy importante que el nmero de elementos del grupo
escogido sea un nmero primo. De lo contrario, podra suceder que existieran dos
valores distintos y tales que = , por lo que existiran dos elementos

que generaran la misma salida de la funcin resumen, resultando un esquema dbil
desde el punto de vista de maleabilidad [243].
4.3.
Componentes funcionales de ECIES
A lo largo de los restantes captulos de esta Tesis Doctoral, se utilizar el trmino

genrico ECIES para referirse a los distintos esquemas de cifrado incluidos en los
estndares de seguridad ms relevantes. A pesar de sus diferencias, las versiones
de ECIES incluidas en los estndares 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 informacin donde la privacidad no
es un factor importante, ya que la informacin a intercambiar no es crtica.
4.3. Componentes funcionales de ECIES
139
Figura 4.3: Diagrama funcional del proceso de descifrado en ECIES
La notacin empleada en la descripcin de los elementos ser utilizada posteriormente en los apartados dedicados a las implementaciones de ECIES recogidas
en los estndares analizados.
4.3.1.
Parmetros de la curva
En el caso de curvas elpticas definidas sobre el cuerpo , con > 3 primo, el

conjunto de parmetros a utilizar es
= (, , , , , ),
cuyos elementos se detallan a continuacin:
es el nmero primo que especifica el cuerpo finito .
y son los elementos de que definen la curva ( ) dada por la expresin
2 = 3 + + .
es el punto que acta como generador de un subgrupo cclico de puntos de
la curva, siendo sus coordenadas ( , ).
es el nmero primo que representa el orden del punto .
140
es el cofactor de la curva, calculado como #( )/.

En cambio, si la curva est definida sobre el cuerpo 2 , el conjunto de parmetros es
= (, (), , , , , ),
donde el significado de los elementos no mencionados anteriormente es el siguiente:
es el nmero entero que especifica el cuerpo finito 2 .
() es un polinomio irreducible de grado que define la base polinmica de
2 .
y son los elementos de 2 que definen la curva (2 ) dada por la
expresin 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 excepcin de los apartados
donde se indique la utilizacin de la notacin propia de algn estndar), toman
como entrada una cadena de bytes de longitud variable y producen como salida una
cadena de bytes de longitud fija, tras la aplicacin 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 generacin del secreto compartido
Las funciones de generacin del secreto compartido utilizadas en ECIES, denominadas de manera genrica 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 pblica del usuario V. Las principales
funciones KA utilizadas en las implementaciones analizadas son:
141
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 operacin consiste en obtener el punto = ( , ) = ,
donde es el cofactor de la curva elptica a la que pertenecen todos los puntos
considerados, de manera que el secreto compartido sea o .
Para que los clculos con cualquiera de las dos primitivas sean vlidos, es necesario comprobar que el punto de la curva generado, ya sea o , es distinto del
punto en el infinito .
4.3.4.
Funciones de derivacin de claves
Las funciones de derivacin de claves, denotadas como funciones KDF (Key

Derivation Function) sirven para generar claves a partir de un dato secreto compartido. La lista de funciones de derivacin 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, diferencindose bsicamente en el orden en que se sitan los elementos
antes de su paso por la funcin resumen. Por su parte, las funciones KDF1 y KDF2
se encuentran definidas en el estndar ISO/IEC 18033-2 [136]. A continuacin se
presenta la descripcin de cada una de las funciones, donde se ha utilizado la notacin
propia de los respectivos estndares:
ANSI-X9.63-KDF.
Sea una cadena de bits que representa el secreto compartido, una funcin
resumen aprobada por ANSI, keydatalen un entero que representa la longitud
en bits de la clave a generar tal que keydatalen < hashlen232 1, siendo
hashlen la longitud en bits del resultado de la funcin 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.
142
Algoritmo 4.4 Funcin 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 ejecucin del bucle, con lo que el valor de
counter depende directamente del elemento .
3. Si el cociente = / es un nmero entero, generar la clave
KeyData mediante la concatenacin
KeyData=1 2 .
4. Si el cociente = / no fuera un nmero entero, realizar
la concatenacin 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
funcin 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 hashlen232 1, siendo hashlen la longitud en bits del resultado de la funcin 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 estructura es
OtherInfo=AlgID||UInfo||VInfo[||SuppPubInfo][||SuppPrivInfo],
donde el significado de cada elemento es el siguiente:
AlgID: cadena de bits que informa sobre cmo obtener la clave y con qu
algoritmos ser utilizada.
UInfo: cadena de bits con informacin pblica sobre el emisor del mensaje
cifrado, incluyendo al menos un identificador de ese usuario.
VInfo: cadena de bits con informacin pblica sobre el receptor del mensaje cifrado, incluyendo al menos un identificador de ese usuario.
SuppPubInfo: cadena de bits opcional con informacin pblica mutuamente conocida por el emisor y el receptor del criptograma.
143
Algoritmo 4.5 Funcin 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, finalizar la operacin devolviendo un error.
3. Establecer un bucle de tipo for desde = 1 hasta que consiste
en calcular = (counter ||Z ||OtherInfo), incrementar la variable counter (mod 232 ) tratndolo como un entero sin signo de 32 bits, e incrementar
la variable i. De esta manera, el valor de counter depende directamente del
nmero de iteracin marcado por el elemento .
4. Si el cociente keydatalen/hashlen es un nmero entero, generar la clave denominada DerivedKeyingMaterial mediante la concatenacin
DerivedKeyingMaterial =H1 ||H2 || ||H .
5. Si el cociente keydatalen/hashlen no fuera un nmero entero, realizar la
concatenacin y seleccionar los keydatalen bits ms a la izquierda como
valor de la clave.
SuppPrivInfo: cadena de bits opcional con informacin privada mutuamente 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 derivacin de claves KDF1 y KDF2 no permiten
parmetros opcionales como entrada. Sus caractersticas ms sealadas son:
KDF1.
La funcin KDF1 toma como entrada una cadena de bytes y un nmero
entero positivo que representa una longitud, generando como salida una cadena de bytes distinta de la inicial y de longitud que se obtiene mediante el
Algoritmo 4.6.
KDF2.
La funcin KDF2 es igual que KDF1, con la nica diferencia de que el contador
recorre los nmeros 1 a en lugar de recorrer el rango entre 0 y 1, tal
como queda recogido en el Algoritmo 4.7.
144
Algoritmo 4.6 Funcin KDF1

1. Crear una variable denominada , siendo contador () la representacin
binaria de utilizando 4 bytes y elegir una funcin resumen H.
2. Calcular el valor = /H.len, siendo H.len la longitud de la salida de la
funcin resumen.
3. Establecer un bucle de tipo for desde = 0 hasta 1 que consiste en
calcular = (x ||contador (i )) e incrementar a continuacin la variable i.
4. Concatenar cada una de las cadenas resumen individuales para obtener como
resultado de la funcin el dato
KDF1(, ) = (contador (0)) (contador ( 1)).
Algoritmo 4.7 Funcin KDF2

1. Crear una variable denominada , siendo contador () la representacin
binaria de utilizando 4 bytes y elegir una funcin resumen H.
2. Calcular el valor = /H.len, siendo H.len la longitud de la salida de la
funcin resumen.
3. Establecer un bucle de tipo for desde = 1 hasta que consiste en calcular
= (x ||contador (i )) e incrementar a continuacin la variable i.
4. Concatenar cada una de las cadenas resumen individuales para obtener como
resultado de la funcin el dato
KDF2(, ) = (contador (1)) (contador ()).
4.3.5.
145
Funcin de cifrado simtrico
Mediante el trmino ENC se representar a lo largo de la presente Tesis el

algoritmo de cifrado simtrico utilizado en ECIES. La lista de algoritmos permitidos
en los principales estndares es la siguiente:
XOR.
TDES, tambin 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 cdigos de autenticacin para mensajes
De forma genrica, las funciones MAC toman como entrada una cadena de bytes
y un nmero entero positivo que representa una longitud, y producen como salida
una cadena de bytes (distinta de la inicial y de la longitud indicada) denominada
comnmente tag o etiqueta. Por su parte, las funciones HMAC (Hashed Message
Authentication Code) representan un tipo especial de funciones MAC, siendo su
caracterstica principal la utilizacin de una funcin 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 ms 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].
146
Algoritmo 4.8 Funcin HMAC

1. Asignar a la variable l la longitud de la salida de la funcin resumen H a
emplear internamente por la funcin HMAC.
2. Comprobar la longitud de la clave y realizar la operacin adecuada:
Si la longitud de k es superior al valor de , la asignacin =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 asignacin
= .
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 funcin HMAC utilizando la clave y el dato de
entrada mediante la operacin
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 notacin anterior, sugerida en [154], representa mediante el trmino genrico
HMAC-Hash-x la implementacin de una funcin HMAC que utiliza la funcin
resumen Hash con la salida truncada a x bits. Por ejemplo, HMAC-SHA-1-80 implica
que en dicha funcin se utiliza la funcin resumen SHA-1, limitando la salida de la
funcin HMAC a los 80 bits situados a la izquierda de la salida de la funcin resumen
SHA-1. Si no se indica el componente x, ello significa que la salida no se encuentra
truncada (por ejemplo, la denominacin HMAC-SHA-1 es equivalente a HMACSHA-1-160). En lo que respecta a la notacin de las funciones CMAC, en este caso
el trmino genrico CMAC-AES-x representa la utilizacin del algoritmo AES-x con
clave de x bits, teniendo la salida de la funcin MAC en esos casos una longitud fija
de 128 bits.
4.4. Versiones de ECIES
4.4.
147
Versiones de ECIES
El esquema DHIES fue empleado, junto con otras propuestas, en la preparacin

de los estndares ANSI X9.63 [16] e IEEE 1363a [109]. Como resultado de los estudios realizados durante la elaboracin de esos documentos, las versiones de ECIES
incluidas en dichos estndares presentan algunas modificaciones respecto a la propuesta 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 estndares ANSI X9.63 e IEEE 1363a avanzaba,
ISO/IEC decidi reunir un grupo de expertos para trabajar en el estndar de cifrado
asimtrico ISO/IEC 18033-2 [136], de manera que durante su elaboracin este grupo
tom como punto de partida los estndares existentes (ya fuera en fase de borrador o
definitivos), especialmente IEEE 1363a al representar el estndar ms reciente sobre
ECIES en aquellos momentos. Tras varios aos de trabajo, el grupo de expertos que
trabajaba en el estndar ISO/IEC 18033-2 introdujo cambios en la implementacin
de ECIES que afectaban a la compatibilidad con los estndares anteriores, por lo que
actualmente para realizar una implementacin de ECIES es imprescindible conocer
las diferencias entre los estndares mencionados a fin de tomar las decisiones de
diseo oportunas.
Los siguientes apartados pretenden resumir las caractersticas ms importantes de cada una de las distintas versiones de ECIES recogidas en los principales
estndares criptogrficos de cifrado asimtrico.
4.4.1.
Versin de ANSI X9.63
Aunque los borradores del estndar ANSI X9.63 incluan dos esquemas de cifrado (Elliptic Curve Encryption Scheme y Elliptic Curve Augmented Encryption
Scheme), cuya diferencia consista en que el segundo esquema utilizaba una funcin MAC para generar una etiqueta (mientras que el primero no la utilizaba), en la
versin final del estndar [16] se describe una nica versin con el nombre de ECIES.
4.4.1.1.
Notacin y parmetros utilizados
Los datos que emisor y receptor necesitan acordar antes de comenzar el proceso
de cifrado son, utilizando la notacin empleada por ANSI X9.63, los siguientes:
Parmetros de dominio , junto con una indicacin de la base utilizada y un
polinomio reductor () de grado y con coeficientes en 2 , en caso de elegir
curvas del tipo (2 ).
148
Funcin resumen H aprobada por ANSI, donde hashlen representa la longitud

en bytes de los resmenes calculados y hashmaxlen indica la longitud mxima
en bytes de los mensajes que pueden ser utilizados como entrada para la funcin
resumen.
Funcin MAC aprobada por ANSI, donde la entrada de la funcin estar
formada por los datos MacData, la clave MacKey tendr una longitud de
mackeylen bits y la salida de la funcin 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 estn descritas en el propio documento, siendo respectivamente las funciones ANSI-X9.63-KDF, DH/DHC y XOR.
Los dems 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 pblica temporal del emisor, componente del par ( , ). Su representacin como cadena de bits es QE.
: clave pblica del receptor.
SharedData1 : cadena de bits con informacin compartida por emisor y receptor,
y que ser utilizada en la funcin KDF.
SharedData2 : cadena de bits con informacin compartida por emisor y receptor,
y que ser utilizada en la funcin MAC.
: elemento del cuerpo finito que representa el secreto compartido que se
utilizar en el proceso de derivacin de claves. Su representacin como cadena
de bits es .
EncKey: clave de cifrado a utilizar por la funcin ENC.
MacKey: clave a utilizar por la funcin MAC.
MacTag: cadena de bits obtenida como salida de la funcin MAC.
149
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 pblica sea = . A continuacin, representar la clave pblica
como la cadena de bits .
2. El emisor utilizar la funcin KA para generar un dato secreto compartido
a partir de los valores , y . Este valor secreto compartido ser
a continuacin convertido en la cadena de bits .
3. El emisor utilizar la funcin KDF para generar a partir de (y opcionalmente tambin 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 ms a
la izquierda como la clave de cifrado EncKey, y utilizar los mackeylen bits
ms a la derecha como la clave MacKey a utilizar con la funcin 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 funcin MAC para generar el elemento MacTag, que
representa la salida correspondiente a la concatenacin 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 pblica temporal QE, el mensaje cifrado MaskedEncData y la etiqueta MacTag.
150
4.4.1.2.
Proceso de cifrado
El proceso de cifrado de la versin de ECIES incluida en ANSI X9.63 presenta

los pasos descritos en el Algoritmo 4.9.
4.4.1.3.
Opciones disponibles
Funcin HASH :
Cualquier funcin resumen aprobada por ANSI. El catlogo de estndares de
ANSI de 2010 [17] indica que dichas funciones son las siguientes:
SHA-1.
SHA-224.
SHA-256.
SHA-384.
SHA-512.
Funcin KA:
DH.
DHC.
Funcin KDF :
ANSI-X9.63-KDF.
Funcin ENC :
XOR (sin lmite en la longitud de los mensajes a cifrar).
Funcin MAC :
Est permitida cualquier funcin MAC aprobada por ANSI que utilice claves
de al menos 80 bits y que genere salidas cuya longitud mnima sea igualmente
de 80 bits, citando el propio estndar 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.
151
HMAC-SHA-512.
Como aclaracin, aunque el documento X9.63 data del ao 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 especficamente 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 hbilmente la actualizacin del estndar sin que sea necesario publicar
nuevas versiones.
4.4.2.
Versin de IEEE 1363a
La versin de ECIES incluida en en el estndar IEEE 1363a [109] est basada

tanto en el esquema DHIES como en la implementacin recogida en ANSI X9.63.
4.4.2.1.
A continuacin se presentan, manteniendo la notacin utilizada por IEEE 1363a,

los datos que los usuarios emisor y receptor necesitan acordar antes de comenzar el
proceso de cifrado:
Parmetros de dominio (, , , , , ), donde representa el orden del generador y es el cofactor de la curva, junto con una indicacin del tipo de
representacin de los elementos de .
Funcin resumen H permitida por IEEE, donde hLen representa la longitud
en bytes de los resmenes calculados.
Funcin MAC, donde la salida tendr una longitud tBits.
Formato de los elementos opcionales P1 y P2 , en caso de ser utilizados.
Indicacin respecto a la utilizacin del modo DHAES y del modo no-DHAES
(denominados de esta manera en el estndar, a pesar de que el algoritmo
conocido como DHAES cambiara su denominacin a DHIES en una de sus
revisiones [8, 9, 10]), que consiste en incluir la clave pblica del emisor como
entrada en la funcin KDF. Segn [109], la utilizacin 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.
152
En IEEE 1363a, las funciones KDF y MAC son fijas y estn descritas en el propio
documento. Aunque en su notacin denominan a la funcin de derivacin de claves
KDF2, en realidad se trata de la funcin ANSI-X9.63-KDF descrita en 4.3.4, y para
evitar confusiones con la funcin KDF2 del estndar ISO/IEC 18033-2, se utilizar
en este apartado el trmino ANSI-X9.63-KDF para referirse a ella. En cuanto a la
funcin MAC1 del documento, se trata de la construccin HMAC-Hash-x [154].
La notacin 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 pblica temporal del emisor, componente del par de claves (, ).
: clave pblica del receptor.
1 : cadena de bytes con informacin compartida por emisor y receptor, y que
ser utilizada en la funcin KDF.
2 : cadena de bytes con informacin compartida por emisor y receptor, y que
ser utilizada por la funcin MAC.
utilizar en el proceso de derivacin de claves.
: representacin como cadena de bytes del secreto compartido .
1 : clave de cifrado a utilizar por la funcin de cifrado simtrico ENC.
2 : clave a utilizar por la funcin MAC.
: cadena de bits obtenida como salida de la funcin MAC.
: longitud en bits de la salida de la funcin MAC.
1 : longitud en bits de la clave de cifrado.
2 : longitud en bits de la clave para la funcin MAC.
En este estndar, tanto la cadena 1 como 2 pueden estar vacas, por lo que
realmente su uso es opcional.
153
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 funcin KA para generar un dato secreto compartido
a partir de los valores y . Opcionalmente tambin utilizar si la primitiva 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 continuacin convertido en la cadena de bytes , al igual
que la clave pblica 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 mtodo de cifrado elegido consiste en un esquema de cifrado de bloques,
el emisor utilizar la funcin 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 ms a la izquierda como la clave de cifrado 1 ,
y utilizar los 2 bits ms a la derecha como la clave 2 a utilizar en la
funcin MAC.
En cambio, si el mtodo de cifrado simtrico es un algoritmo de cifrado en
flujo, existe la opcin 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 ms a la izquierda de la salida de la funcin KDF, mientras que
en el modo no-DHAES se consigue mediante los 2 bits ms 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 vaca (aunque 2 contenga datos).
7. El emisor utilizar la funcin MAC con la clave 2 para generar el elemento
T, que representa la etiqueta correspondiente a la concatenacin del mensaje
cifrado, denotado como , junto con el dato compartido 2 y la cadena de
bytes (potencialmente vaca) 2 .
8. Finalmente, el emisor enviar al receptor la tripleta (, , ).
154
4.4.2.2.
Proceso de cifrado
El proceso de cifrado de la versin 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
parmetro 1 a fin de que el dato sea distinto en cada ocasin.
4.4.2.3.
Funcin HASH :
SHA-1.
SHA-256.
SHA-384.
SHA-512.
RIPEMD-160.
Funcin KA:
DH (denominada ECSVDP-DH en la norma).
DHC (denominada ECSVDP-DHC en la norma).
Funcin KDF :
ANSI-X9.63-KDF (denominada en el estndar KDF2, no confundir con
la funcin del mismo nombre descrita en 4.3.4).
Funcin ENC :
XOR (el estndar recomienda cifrar mensajes de reducido tamao y, si
se utiliza el modo no-DHAES, que su longitud sea constante para una
misma clave pblica 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
155
Funcin MAC :
El estndar define la funcin 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.
Versin de ISO/IEC 18033-2
4.4.3.1.
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 notacin utilizada
por ISO/IEC 18033-2 [136]:
Conjunto de parmetros (, , , , ), donde es el cuerpo primo o binario
de trabajo, representa el elemento generador del grupo cclico , es
el orden del elemento y es el cofactor de la curva.
Funcin de derivacin de claves KDF (pudiendo optar entre las funciones
KDF1 y KDF2).
Funcin resumen Hash, donde Hash.len representa la longitud en bytes de
los resmenes calculados y Hash.MaxInputLen indica la longitud mxima, en
bytes, de los mensajes que pueden ser utilizados como entrada para la funcin
resumen.
Funcin MAC denominada de forma abreviada MA, donde la longitud en
bytes de la clave se denotar mediante el trmino MA.KeyLen, mientras que
la longitud en bytes de la etiqueta producida por la funcin se representar
como MA.MACLen.
Funcin ENC, donde la longitud en bytes de la clave se denotar mediante el
trmino SC.KeyLen.
Utilizacin del modo OldCofactorMode, que implica el uso del cofactor tanto
en la fase de cifrado como de descifrado.
156
Utilizacin del modo CofactorMode, que requiere del uso del cofactor nicamente en el proceso de descifrado.
Utilizacin del modo CheckMode, que obliga a la comprobacin durante el proceso de descifrado de la pertenencia de la clave pblica temporal del emisor a .
nicamente uno de los modos OldCofactorMode, CofactorMode y CheckMode
puede ser utilizado en un mismo proceso de cifrado.
Utilizacin o no del modo SingleHashMode, que permite elegir que la entrada
a la funcin KDF sea nicamente la primera coordenada del dato secreto
compartido o de manera adicional la clave pblica temporal generada por el
emisor.
Formato de codificacin de los puntos (comprimido o sin comprimir).
La notacin empleada en ISO/IEC 18033-2 incluye adems los siguientes elementos:
: mensaje que el emisor desea enviar al receptor.
(, ): par formado por las claves privada y pblica del receptor.
(, ): par formado por una clave privada y una clave pblica temporales generadas por el emisor.
: cadena de bytes con informacin compartida por emisor y receptor, y que
ser utilizada en la funcin MAC.
: representacin como cadena de bytes de la clave pblica temporal del emisor.
: valor obtenido como salida de la funcin KDF.
: clave de cifrado a utilizar por el esquema de cifrado simtrico ENC.
: clave a utilizar por la funcin MAC.
: valor obtenido como salida de la funcin MAC.
PEH : primera coordenada del punto que acta como valor secreto compartido.

4.4.3.2.
157
Proceso de cifrado
El proceso de cifrado de la versin de ECIES incluida en ISO/IEC 18033-2

se divide en dos fases, denominadas ECIES-KEM y ECIES-DEM, correspondientes a la generacin de las claves de cifrado y autenticacin por una parte, y a la
construccin 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 estndar 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 nmero aleatorio perteneciente al
conjunto {1, 2, . . . , 1}.
2. A continuacin, si los usuarios utilizan el modo OldCofactorMode, calcular
= (mod ). En caso contrario, realizar la asignacin = .
3. Tras el paso anterior, el emisor calcular los puntos de la curva = y
= .
el emisor obtendr la codificacin he4. Una vez obtenidos los puntos y ,

xadecimal 0 correspondiente a la clave pblica temporal en funcin del
formato de codificacin 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 continuacin el emisor codificar en formato hexadecimal la primera coor obteniendo el elemento PEH.
denada del elemento ,
7. Acto seguido, utilizar la funcin KDF para generar , tomando como
entrada la concatenacin , es decir, la clave pblica temporal del
emisor (o la cadena nula, en su caso) y la representacin binaria de la primera
coordenada del dato secreto compartido.
Es interesante comentar que, mientras DEM1 es la funcin DEM recomendada
por ISO/IEC 18033-2 (y consecuentemente slo incluye vectores de test para esa
funcin), el propio documento informa que la principal razn para incluir las funciones DEM2 y DEM3 ha sido el mantenimiento de compatibilidad con estndares
anteriores.
4.4.3.3.
Las opciones disponibles en el estndar ISO/IEC 18033-2 son:
158
Algoritmo 4.12 Funcin 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 simtrico, con longitud SC.KeyLen,
y ser la clave de la funcin MAC, con longitud MA.KeyLen.
2. A continuacin el emisor cifrar el mensaje original con la clave , generando el mensaje cifrado .
3. Tras el ltimo paso, obtendr la etiqueta correspondiente a la salida
de la funcin 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 pblica temporal 0 .
18033-2
1. El emisor debe interpretar el elemento como , donde actuar como
clave para el algoritmo de cifrado simtrico, con longitud SC.KeyLen, y
ser la clave de la funcin 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.
159
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 funcin MAC,
con longitud MA.KeyLen.
2. El emisor
cifrar el mensaje original con la clave mediante la operacin
= .
, donde es una cadena binaria de datos compartidos entre emisor y
receptor.
Funcin HASH :
Cualquiera de las las funciones resumen definidas en ISO/IEC 10118-2 [130]
que utilizan internamente una funcin de cifrado de bloques con la condicin
de que el nmero de bytes ofrecidos como salida de la funcin sea mltiplo 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 condicin de que el nmero de bytes ofrecidos como salida de la funcin
sea mltiplo de 8. Las funciones especficas que cumplen ese requisito son las
siguientes:
SHA-1.
SHA-256.
SHA-384.
SHA-512.
RIPEMD-128.
RIPEMD-160.
WHIRLPOOL.
160
Funcin KA:
DH.
DHC.
Funcin KDF :
KDF1.
KDF2.
Funcin ENC :
XOR con una longitud de mensaje en claro definida y constante para
todos los procesos de cifrado.
XOR diseado para el cifrado de mensajes de longitud variable, donde en
lugar de utilizar directamente la clave de cifrado generada por la funcin
KDF, sta se utiliza como semilla para la generacin de la clave XOR
definitiva adaptada a la longitud del mensaje en claro mediante una nueva
ejecucin de la funcin KDF.
Cualquier algoritmo incluido en ISO/IEC 18033-3 [137] con la condicin de que
la longitud de los mensajes medida en bits sea mltiplo 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.
Funcin MAC :
Cualquiera de las cuatro variantes CBC-MAC incluidas en ISO/IEC 9797-1
[128] que utilizan internamente una funcin de cifrado de bloques, denominadas
en [128] de la siguiente manera:
161
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.
Versin de SECG SEC 1
El consorcio SECG public la primera versin del documento SEC 1 el ao

2000. Desde entonces ha publicado distintos borradores que han culminado con la
publicacin de la versin 2.0 en mayo de 2009 [254]. Este documento incluye, adems
de algunos apartados dedicados a los fundamentos matemticos y los detalles sobre
cmo generar y elegir los parmetros de dominio adecuados, una amplia descripcin
de los esquemas de cifrado, firma digital y acuerdo de clave basados en ECC.
4.4.4.1.
Los datos que los usuarios, identificados como emisor y receptor, necesitan acordar antes de comenzar el proceso de cifrado son los siguientes, donde se ha mantenido
la notacin utilizada por SEC 1:
Conjunto de parmetros = (, , , , , ) en caso de utilizar curvas definidas sobre cuerpos finitos , o parmetros = (, (), , , , , ) si se
utilizan curvas del tipo (2 ), donde en ambos casos representa el orden
del generador y es el cofactor de la curva.
Funcin de derivacin de clave KDF, que genera una cadena de bytes de longitud enckeylen+mackeylen.
Funcin resumen H, donde hashlen representa la longitud en bytes de los resmenes calculados y hashmaxlen indica la longitud mxima en bytes de los
mensajes que pueden ser utilizados como entrada para la funcin resumen.
Funcin MAC, donde la longitud en bytes de la clave se denotar mediante el
trmino mackeylen, mientras que la longitud en bytes de la etiqueta producida
por la funcin se representar como maclen.
162
Funcin ENC, donde la longitud en bytes de la clave se denotar mediante el

trmino enckeylen.
Formato de los elementos SharedInfo1 y SharedInfo2 .
Utilizacin o no de la representacin de puntos con compresin.
La notacin empleada en [254] incluye los siguientes elementos:
: mensaje que el emisor desea enviar al receptor.
EM : mensaje cifrado por el emisor.
( , ): par formado por la clave privada y la clave pblica de .
(, ): par formado por una clave privada y una clave pblica temporales
generadas por el emisor.
SharedInfo1 : cadena de bytes con informacin compartida por los dos usuarios,
y que ser utilizada en la funcin KDF.
SharedInfo2 : cadena de bytes con informacin compartida por emisor y receptor, y que ser utilizada por la funcin MAC.
: representacin como cadena de bytes del secreto compartido .
EK: clave de cifrado a utilizar por el esquema de cifrado simtrico ENC.
MK: clave a utilizar por la funcin MAC.
: valor obtenido como salida de la funcin MAC.
4.4.4.2.
Proceso de cifrado
El proceso de cifrado de la versin de ECIES incluido en SEC 1 presenta los

pasos indicados en el Algoritmo 4.15.
163
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 pseudoaleatoriamente un valor perteneciente al conjunto {1, 2, . . . , 1}, de manera
que su correspondiente clave pblica sea = .
2. Dependiendo del tipo de compresin que los usuarios hayan decidido utilizar
para representar los puntos de la curva elptica, es necesario convertir el
punto en la cadena de bytes .
3. En funcin 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 pblica . Este valor secreto compartido ser convertido en la
cadena de bytes .
4. El emisor utilizar la funcin KDF acordada con el otro usuario para generar
a partir de (y opcionalmente tambin del valor SharedInfo1 ) un dato
cuya longitud ser enckeylen+mackeylen.
5. A partir del elemento , el emisor adoptar sus enckeylen bytes ms a la
izquierda como la clave de cifrado EK, y utilizar los mackeylen bytes ms a
la derecha como la clave MK a utilizar con la funcin MAC. nicamente en
el caso de que la funcin de cifrado sea XOR y no se desee compatibilidad
con estndares anteriores, entonces la interpretacin del orden de las claves
de cifrado y autenticacin ser exactamente la contraria.
6. El emisor emplear el algoritmo de cifrado simtrico ENC, junto con el
mensaje y la clave EK, para generar el mensaje cifrado EM.
7. El usuario emisor utilizar la funcin MAC acordada al inicio del proceso
para generar el elemento D, que representa la etiqueta correspondiente a
la concatenacin 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 representacin binaria de la clave pblica
temporal , el mensaje cifrado EM y la etiqueta . Una posible forma de
proceder a su envo consiste en concatenar los elementos de forma que el
criptograma sea
= EM .
164
4.4.4.3.
La siguiente lista muestra las distintas opciones permitidas en SEC 1:

Funcin HASH :
SHA-1.
SHA-224.
SHA-256.
SHA-384.
SHA-512.
Funcin KA:
DH.
DHC.
Funcin KDF :
ANSI-X9.63-KDF [16].
NIST-800-56-Concatenation-KDF [189].
Funcin ENC :
XOR (sin lmite en la longitud de los mensajes a cifrar).
TDES con tres claves en modo CBC [190] (SEC 1 no especifica el mtodo
de relleno).
AES en modo CBC y claves de 128, 192 256 bits [185, 187] (sin especificar el mtodo de relleno).
AES en modo CTR y claves de 128, 192 256 bits [185, 187] (SEC 1 no
define el mtodo de relleno).
Funcin 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 comparacin entre pares de estndares, donde la eleccin de los estndares a comparar se ha realizado en base a su
fecha de publicacin, de manera que las comparaciones se han efectuado entre cada
par de estndares ms cercanos en el tiempo. El motivo de esta decisin es que,
aunque cada nuevo estndar se apoya en los anteriores, suele tomar como referencia
el estndar de ms reciente publicacin.
En resumen, los documentos considerados y sus fechas de publicacin 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 prrafos la propuesta de Abdalla et al.

[10] ser referida como DHIES, mientras que el estndar 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 parmetros opcionales en las funciones KDF y MAC, mientras que X9.63 permite parmetros en ambas funciones.
DHIES utiliza una funcin resumen para producir las claves y . En
comparacin, X9.63 utiliza una funcin KDF donde los datos son procesados
mediante un procedimiento iterativo.
DHIES interpreta los bits iniciales de la salida de la funcin KDF como la clave
MAC, y los bits finales como la clave ENC. En X9.63, el orden es precisamente
el opuesto.
X9.63 slo permite utilizar la funcin XOR como algoritmo de cifrado simtrico. En comparacin, DHIES permite utilizar algoritmos de cifrado en bloque,
dejando abierta la eleccin del algoritmo especfico.
166
4.5.2.
Diferencias entre ANSI X9.63 e IEEE 1363a
La siguiente lista refleja las principales diferencias existentes entre las implementaciones de ECIES incluidas en ANSI X9.63 [16] e IEEE 1363a [109], que por
simplicidad en los siguientes prrafos sern referidos simplemente como X9.63 y
1363a.
X9.63 permite utilizar parmetros opcionales como entrada en la funcin KDF,
aunque no menciona el contenido de dichos parmetros. En comparacin, el
modo DHAES de 1363a obliga a utilizar la representacin binaria de la clave
temporal pblica del emisor como parmetro.
En cualquier caso, aunque X9.63 utilizara la clave pblica temporal como
parmetro en la funcin KDF, este dato se concatenara en tercera posicin en
la cadena binaria que representa el argumento de la funcin resumen utilizada
internamente dentro de la funcin KDF (es decir, en las iteraciones de la
funcin sera necesario calcular ( counter )), mientras que en IEEE
1363a la clave pblica temporal ocupara el primer lugar en la concatenacin
(siendo necesario por tanto calcular el valor ( counter ))
1363a interpreta los bits iniciales de la salida de la funcin KDF como la clave
MAC, y los bits posteriores como la clave ENC, cuando utiliza cifrado en flujo,
mientras que la interpretacin es la opuesta cuando 1363a utiliza cifrado en
bloque. En comparacin, X9.63 interpreta siempre la salida de la funcin KDF
como .
4.5.3.
Diferencias entre IEEE 1363a e ISO/IEC 18033-2
En este apartado se presentan las principales diferencias entre los estndares

IEEE 1363a [109] e ISO/IEC 18033-2 [136], que por simplicidad en los siguientes
prrafos sern referidos simplemente como 1363a y 18033-2. Las diferencias ms
importantes de las versiones de ECIES incluidas en ambos estndares, obviando las
funciones permitidas en cada uno, son:
18033-2 no permite parmetros en la funcin KDF, mientras que 1363a s los
permite.
1363a permite utilizar tanto cadenas de bits como de bytes, mientras que
18033-2 slo permite cadenas de bytes.
1363a sugiere utilizar siempre los mismos parmetros (funciones resumen y
MAC, algoritmo de cifrado simtrico, etc.) para una clave pblica del remitente
determinada, mientras que en 18033-2 es obligatorio no cambiar los parmetros
en relacin a la misma clave pblica del destinatario.
4.5. Diferencias en las versiones de ECIES
167
1363a establece como longitud mnima del orden del elemento generador 160
bits, mientras que 18033-2 no hace referencia a longitudes mnimas.
Es interesante comentar que, entre el estndar IEEE 1363a y los primeros borradores de ISO/IEC 18033-2, existan ms diferencias, como se puede apreciar en el
documento de Shoup [243], que denotaremos por Shoup01, y que sirvi como punto
de partida para el estndar ISO/IEC 18033-2. Esas diferencias, que posteriormente
desaparecieron en la versin final del estndar con el fin de asegurar una mayor
compatibilidad con otros estndares, son las siguientes:
Mientras que en Shoup01 se utiliza de manera obligatoria la clave pblica
temporal del remitente como entrada de la funcin resumen (junto con el dato
secreto compartido), 18033-2 permite la posibilidad de no incluir dicha clave
pblica temporal. Para completar la comparacin entre los tres documentos,
se recuerda que 1363a permite una opcin (el modo no-DHAES) en la que no
se utiliza la clave pblica del destinatario.
Shoup01 obliga a incluir como entrada de la funcin MAC un campo que
representa la longitud de la etiqueta que se anexa al mensaje cifrado. Por el
contrario, en la versin final de 18033-2 aparecen dos modos (DEM2 y DEM3)
que permiten no incluir esta informacin. En comparacin, en 1363a aadir la
longitud es opcional y en el modo no-DHAES no se emplea.
18033-2 permite la utilizacin de la funcin XOR como algoritmo de cifrado de
flujo en el modo DEM3, algo que sin embargo estaba explcitamente prohibido
en Shoup01. Por su parte, 1363a permite utilizar tanto un cifrado de flujo
como un algoritmo de cifrado simtrico de bloques.
4.5.4.
Diferencias entre ISO/IEC 18033-2 y SEC 1
En este apartado se presentan las principales diferencias entre los estndares

ISO/IEC 18033-2 [136] y el documento SEC 1 [254], que por simplicidad sern
referidos simplemente como 18033-2 y SEC 1. Las diferencias ms importantes
entre las versiones de ECIES incluidas en ambos estndares, a excepcin de las
funciones especficas permitidas, son:
18033-2 no permite parmetros en la funcin KDF, mientras que SEC 1 s
permite incluir informacin adicional en la entrada de esa funcin, aunque en
los vectores de test de ejemplo incluidos en el documento GEC 2 [253] este
parmetro se encuentre ausente.
SEC 1 no incluye de forma explcita la clave pblica temporal del usuario
emisor en el clculo de las claves de cifrado simtrico y autenticacin, aunque
comenta que podra ser uno de los elementos incluidos en el dato SharedInfo1 .
168
Mientras que 18033-2 no hace referencia a longitudes mnimas, SEC 1 establece que la eleccin 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.
Comparacin de las funciones permitidas en los

estndares
En este apartado se presenta la comparacin 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 funcin especificada en [131]. Las
funciones definidas en [130] y referidas en [136] han sido excluidas del cuadro por
tratarse de un tipo de funcin resumen no presente en los otros estndares y carecer
de utilidad prctica a efectos comparativos.
ANSI X9.63
SHA-1
SHA-224
SHA-256
SHA-384
SHA-512
IEEE 1363a ISO/IEC 18033-2

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

funcin Diffie Hellman para curvas elpticas sin cofactor y DHC la misma funcin
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 funcin KDF definida en ANSI X9.63 [16], KDF1
4.6. Comparacin de las funciones permitidas en los estndares

ANSI X9.63
DH
DHC
IEEE 1363a
DH
DHC
ISO/IEC 18033-2
DH
DHC
169
SECG SEC 1
DH
DHC
Cuadro 4.6: Funcin KA
y KDF2 son las funciones especificadas en ISO/IEC 18033-2 [136] y el trmino NIST800-56 representa la funcin definida en el documento NIST SP800-56A [189]. Es
importante indicar que, si la funcin X9.63-KDF no incluye el elemento SharedInfo,
entonces es equivalente a la funcin KDF2.
ANSI X9.63
X9.63-KDF
IEEE 1363a
X9.63-KDF
ISO/IEC 18033-2
KDF1
KDF2
SECG SEC 1
X9.63-KDF
NIST-800-56
Cuadro 4.7: Funcin KDF
De manera equivalente, el Cuadro 4.8 muestra los algoritmos de cifrado simtrico utilizados por las distintas versiones de ECIES, donde XOR es la funcin OR
exclusiva, el trmino XOR constituye la variante de ISO/IEC 18033-2 que emplea
la funcin XOR junto con la funcin KDF, TDES representa el algoritmo Triple
DES [190], AES es el algoritmo definido en [185] para su utilizacin con claves de
128, 192 y 256 bits, y los algoritmos MISTY1, CAST-128, Camellia y SEED se encuentran especificados en los documentos [165], [11], [18] y [157], respectivamente.
Los trminos CBC y CTR hacen referencia al modo de utilizacin del algoritmo, la
cadena PKCS5 indica que el mtodo de relleno padding a emplear debe ser PKCS#5
[234], y por ltimo el sufijo * implica que el estndar referido no ha impuesto ningn
mtodo de relleno de forma especfica.
ANSI X9.63
XOR
IEEE 1363a
XOR
TDES/CBC/PKCS5
AES/CBC/PKCS5
ISO/IEC 18033-2
SECG SEC 1
XOR
XOR
XOR
TDES/CBC/*
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: Funcin ENC
Por ltimo, el Cuadro 4.9 presenta las funciones MAC permitidas en los diferentes estndares, donde con el objetivo de optimizar el tamao del cuadro resultante se ha sustituido el prefijo HMAC por H. Las funciones HMAC-SHA-1 y
170
HMAC-RIPEMD se encuentran especificadas en [154], las variantes HMAC-SHA224, HMAC-SHA-256, HMAC-SHA-384 y HMAC-SHA-512 surgen de la combinacin 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 estndar ISO/IEC
18033-2, se han incluido en el cuadro nicamente las funciones de tipo HMAC, puesto que el resto de funciones definidas en [128] y [129] constituyen tipos de funciones
MAC no presentes en los dems estndares analizados y por lo tanto no son comparables a efectos prcticos.
ANSI X9.63
H-SHA-1
H-SHA-224
H-SHA-256
H-SHA-384
H-SHA-512
IEEE 1363a
ISO/IEC 18033-2
H-SHA-1
H-SHA-1
H-SHA-256
H-SHA-256
H-SHA-384
H-SHA-384
H-SHA-512
H-SHA-512
H-RIPEMD-160 H-RIPEMD-128
H-RIPEMD-160
H-WHIRLPOOL
SECG SEC 1
H-SHA-1-80/160
H-SHA-224-112/224
H-SHA-256-128/256
H-SHA-384-192/384
H-SHA-512-256/512
CMAC-AES-128/192/256
Cuadro 4.9: Funcin MAC
Como resumen final, el Cuadro 4.10 muestra las funciones permitidas simultneamente por los cuatro estndares revisados.
HASH
SHA-1
SHA-256
SHA-384
SHA-512
KA
DH
DHC
KDF
KDF2
ENC
XOR
MAC
HMAC-SHA-1
HMAC-SHA-256
HMAC-SHA-384
HMAC-SHA-512
Cuadro 4.10: Funciones comunes permitidas en los cuatro estndares
4.7.
Comparacin de las configuraciones permitidas

en los estndares
Tal como se ha mostrado en los anteriores apartados, los diferentes estndares

en los que se encuentra descrito el esquema ECIES contienen mltiples opciones
no siempre compatibles entre s. El primer paso para realizar una implementacin
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 anlisis detallado de las distintas combinaciones de parmetros muestra que
existen 11 configuraciones posibles que puedan ser implementadas al menos por
4.7. Comparacin de las configuraciones permitidas en los estndares171

un estndar (las restantes configuraciones, no incluidas, son incompatibles con los
cuatro estndares). Puesto que todos ellos permiten utilizar como funcin KA las
funciones DH y DHC, el anlisis se reduce a comparar los siguientes elementos: el
tipo y nmero de argumentos de las funciones KDF y MAC, la interpretacin del
elemento K a partir del cual se generan las claves de cifrado y autenticacin, y por
ltima la clase de funcin de cifrado simtrico elegida (en flujo o en bloque).
Id. de configuracin
El Cuadro 4.11 muestra los datos mencionados en el prrafo anterior, donde

es la codificacin binaria de la primera coordenada del punto = ( , ), Param 1
representa una cadena binaria con parmetros para la funcin KDF, y
son respectivamente las claves de cifrado y autenticacin generadas a partir del dato
K (que a su vez es la salida de la funcin KDF ), es el mensaje cifrado con el
algoritmo de cifrado simtrico (ya sea una funcin de cifrado en flujo o en bloque),
y por ltimo Param 2 representa una cadena binaria con parmetros para la funcin
MAC (por ejemplo, la codificacin de un texto que conocen emisor y receptor).
C01
C02
C03
C04
C05
C06
C07
C08
C09
C10
C11
Arg. KDF
, Param 1
, Param 1

, Param 1
Opciones de configuracin
Interp. K
Alg. simtrico

Flujo

Flujo

Flujo

Flujo

Bloque

Bloque

Bloque

Bloque

Bloque

Bloque

Bloque
Arg. MAC
, Param 2
, Param 2
, Param 2
, Param 2
, Param 2
, Param 2
Cuadro 4.11: Combinaciones de parmetros admitidas al menos en un estndar
Una vez presentadas las personalizaciones de ECIES que son aceptadas al menos
en un estndar, el Cuadro 4.12 muestra el resumen de los estndares que permiten
cada una de las configuraciones.
172
X9.63
1363a
18033-2
SEC 1
Identificador de personalizacin
C01 C02 C03 C04 C05 C06 C07 C08 C09 C10 C11
Cuadro 4.12: Comparativa de las configuraciones permitidas en cada estndar
4.8.
Versin de ECIES compatible con todos los estndares
Tras revisar la lista de funciones permitidas por cada estndar en 4.6 y analizar
las configuraciones permitidas por cada uno de ellos en 4.7, se puede concluir que
existen dos configuraciones vlidas en las ltimas versiones de ANSI X9.63, IEEE
1363a, ISO/IEC 18033-2 y SECG SEC 1, caracterizadas ambas por utiliza la funcin
XOR como algoritmo de cifrado simtrico.
A la vista de este hecho, y teniendo en cuenta el elevado nmero de funciones
que los estndares utilizan de forma comn, es posible construir distintas versiones
de ECIES compatibles con los cuatro estndares y con las configuraciones C01 y
C02, diferencindose entre ellas en la funcin resumen, la funcin MAC, el uso de
parmetros opcionales en la funcin MAC, o una combinacin de esos elementos.
Por simplicidad, el Algoritmo 4.16 muestra nicamente un ejemplo de los muchos posibles, denominado ECIES-4, que emplea un subconjunto de las opciones
disponibles de manera comn en los cuatro estndares.
4.9.
Seguridad de ECIES
De manera adicional a los ataques generales sobre curvas elpticas expuestos en

2.6.7, con el paso del tiempo han surgido ataques especficos para ECIES debido 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 atacante de generar un criptograma vlido 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 estndares (ECIES-4)
1. Elegir un valor aleatorio {1, 2, . . . , 1} como clave privada temporal
de U, y generar la clave pblica = .
2. Calcular un punto = ( , ) de la curva mediante la operacin = ,
donde es la clave pblica del usuario receptor.
3. Generar el elemento del que se obtendrn las clave de cifrado y autenticacin mediante la operacin =KDF ( ), siendo la funcin KDF elegida
ANSI-X9.63-KDF (sin parmetros opcionales) y la funcin 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 funcin de cifrado
de flujo XOR.
6. Calcular la etiqueta tag utilizando el mtodo tag = MAC (), donde la funcin 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 relacin [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 prcticos.
4.9.1.1.
Maleabilidad benigna
Shoup [243] demostr que, si se utiliza nicamente la primera coordenada

como entrada de la funcin KDF, el esquema ECIES es vulnerable frente ataques
de tipo ACCA y, en consecuencia, es maleable. En efecto, dado un criptograma
( , , ) compuesto por la representacin binaria de la clave pblica temporal
del emisor, el mensaje cifrado y la etiqueta tag, si se sustituye el punto de la
curva por , al aplicar la funcin 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 funcin KDF ser la misma
en ambos casos. La conclusin es que, a partir de un criptograma ( , , ) vlido,
es posible construir otro criptograma ( , , ) igualmente vlido.
174
Una posible forma de resolver este problema fue propuesta por el propio Shoup,
y consiste en aadir la clave pblica temporal como entrada de la funcin KDF,
con lo que el criptograma ( , , ) ya no sera vlido, dado que la salida de la
funcin KDF sera diferente en ambos casos.
Otra posible solucin consiste en utilizar el punto generado mediante la funcin
KA en lugar de nicamente su primera coordenada como entrada de la funcin
KDF, con lo que de nuevo dejara de ser vlido un criptograma que contuviera
en lugar de . Respecto a la solucin 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 opcin
en algunas obras [30], en los cuatro estndares estudiados la segunda opcin no es
utilizada.
Independientemente de la vulnerabilidad reseada, Shoup indic que, en caso de
utilizar la funcin Diffie-Hellman con cofactor, es igualmente posible crear un ataque
que afecte a la maleabilidad del esquema, puesto que si al punto se le aade un
elemento distinto de cuyo orden divida el cofactor , entonces de nuevo a partir
de un criptograma vlido sera posible generar otro criptograma igualmente vlido.
La solucin ms sencilla para este problema consiste en utilizar la funcin 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 ningn resultado prctico. 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 funcin XOR como algoritmo de

cifrado
Shoup demostr en [243] que el esquema ECIES es tambin maleable, aunque

en este caso de forma no benigna, cuando se utiliza la funcin XOR como funcin
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 representacin binaria de la clave pblica temporal del emisor.
2. El mensaje en claro formado por la concatenacin de las cadenas 1 y 2 ,
con longitudes respectivas 1 y 2 .
175
3. La salida de la funcin 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 concatenacin 1 2 , cuyas longitudes
respectivas son 1 y 2 .
4. El mensaje cifrado formado por la concatenacin 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 funcin MAC tomando como
entrada y utilizando la clave .
Bajo esas premisas, es posible construir de forma artificial otro criptograma
( , , tag)
tambin vlido para los siguientes datos:
1. La representacin binaria de la clave pblica 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 funcin 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 funcin 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 utilizacin de la funcin XOR [109, 136,
243].
2. Cambiar el orden de interpretacin de las claves MAC y de cifrado obtenidas a
partir de la funcin KA, de manera que la clave MAC se obtenga a partir de los
bits ms a la izquierda de la salida de la funcin KDF [10, 109, 254, 243, 256].
3. Prohibir la utilizacin de las funciones de cifrado en flujo en ECIES, permitiendo nicamente los algoritmos de cifrado de bloques [224, 243].
176
Figura 4.4: Maleabilidad debido a la funcin XOR
4.9.2.
177
Ataques de subgrupos pequeos
Este tipo de ataques [99] se producen cuando un atacante proporciona deliberadamente una clave pblica invlida. Si el usuario que desea enviar el mensaje cifrado
no comprueba la validez de la clave pblica del destinatario, ste podra haber proporcionado como clave un elemento de orden pequeo, con el objetivo de limitar el
rango posible para el dato secreto compartido o incluso tratar de obtener alguna
informacin sobre la clave privada del remitente.
Las opciones disponibles para evitar este tipo de ataques son la siguientes:
Calcular el orden de la clave pblica del destinatario, comprobando que es
igual a .
Utilizar la primitiva DHC en lugar de la funcin DH, comprobando que el
elemento = .
Reemplazar el dato secreto compartido por su resumen (por ejemplo, mediante
la funcin SHA-1) antes de utilizar ese dato como entrada de la funcin KDF.
Utilizar la clave pblica temporal del emisor como entrada de la funcin KDF.
En un escenario tpico, la validez de la clave pblica del destinatario ser realizada por un organismo de certificacin, por lo que esta solucin no tendra impacto
en una solucin comercial.
Por otra parte, la utilizacin de la funcin 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 funcin DH.
Respecto a la utilizacin 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 prctica ninguno de los vectores de tests de [130] y [253] lo utilizan, y en la
ltima versin de Java Card se ha aadido un nuevo modo de operacin en el que
no se aplica ninguna funcin resumen a la salida de la funcin KA.
Finalmente, la opcin ms extendida en los estndares analizados consiste en
utilizar la clave pblica temporal del emisor como entrada de la funcin KDF, de
modo que en el diseo de la propia funcin KDF se incluye una funcin resumen
de tal manera que a partir de la salida de la funcin KDF no sea posible obtener
ninguna informacin til que pudiera llevar a determinar el valor utilizado.
Como consideracin adicional, si el par de claves temporal se genera aleatoriamente y se utiliza en un nico proceso de cifrado, aunque el atacante consiguiera
obtener alguna informacin relativa a este par de claves, dicha informacin no sera
til para posteriores procesos de cifrado.
178
4.9.3.
Eleccin dinmica de parmetros 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 estndares como IEEE
1363a est recomendada esta forma de proceder, en la prctica no existe consenso
[224] sobre el riesgo real que implicara el cambio de parmetros y funciones durante
el ciclo de vida de unas claves dadas.
Por otra parte, puesto que seguir la recomendacin de Shoup no parece tener
ningn efecto negativo, la prudencia sugiere en este caso imponer como requisito
que ni las funciones ni los parmetros 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 legtimos, stos deben realizar las comprobaciones adecuadas para
asegurar que, para un par de claves especfico, solamente se utilizar un conjunto de
parmetros a lo largo del ciclo de vida de esas claves.
4.10.
Versin de ECIES segura
Una vez analizada la seguridad de ECIES en 4.9, es necesario revisar las caractersticas de la versin ECIES-4 definida en 4.8. Puesto que dicha versin (y
sus posibles variantes que empleen otras funciones resumen y MAC ) emplean la
funcin XOR, que puede ser utilizada por un atacante para generar problemas de
maleabilidad maligna, es necesario reconsiderar las decisiones tomadas respecto a la
versin de ECIES compatible con todos los estndares.
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 versin
ECIES-4 con los cuatro estndares consiste en fijar la longitud de los mensajes a
cifrar, lo que de hecho ya era recomendado en IEEE 1363a, donde adems se sugiere
que los nicos mensajes a cifrar mediante la funcin XOR sean claves de otros
algoritmos de cifrado simtrico.
Puesto que con la nica solucin compatible con todos los estndares la funcionalidad de ECIES queda seriamente limitada, se hace necesario seleccionar otra
configuracin como punto de partida para cualquier implementacin de ECIES. Dado que exceptuando C01 y C02 no existen ms configuraciones compatibles con los
cuatro estndares, los candidatos lgicos son aquellas configuraciones permitidas en
tres estndares, que resultan ser C05 y C06. Al igual que sucedi en 4.8, es posible
definir a partir de las configuraciones C05 y C06 mltiples versiones compatibles con
dichas configuraciones, y que se diferencien en la funcin HASH, la funcin MAC o
el uso de argumentos opcionales en la funcin de autenticacin.
Las versin ECIES-3 definida por el Algoritmo 4.17 constituye una de las po-
4.10. Versin 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 estn disponibles en las
libreras criptogrfica actuales.
Algoritmo 4.17 Cifrado ECIES compatible con los cuatro estndares (ECIES-3)
1. Elegir un valor aleatorio {1, 2, . . . , 1} como clave privada temporal
de U, y generar la clave pblica = .
2. Calcular un punto = ( , ) de la curva mediante la operacin = ,
donde es la clave pblica del usuario receptor.
3. Generar el elemento del que se obtendrn las clave de cifrado y autenticacin mediante la operacin =KDF ( ), siendo la funcin KDF elegida
KDF2 (equivalente a ANSI-X9.63-KDF sin parmetros opcionales) y la funcin 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 funcin de cifrado simtrico ENC es el algoritmo AES en modo CBC y relleno PKCS#5 utilizando
claves de 256 bits.
6. Calcular la etiqueta tag utilizando el mtodo tag = MAC (||Param 2 ), donde
la funcin MAC elegida es HMAC-SHA-256 con salida de 256 bits y el
elemento Param 2 representa la concatenacin 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 codificacin 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.
Captulo 5
Implementacin de ECIES en
entorno PC
Resumen del captulo

Este captulo presenta las decisiones de diseo tomadas con el objetivo de
desarrollar la implementacin de ECIES en plataformas PC, as como el
diagrama de las clases Java que componen el desarrollo software. El resto
del captulo se encuentra dedicado a la descripcin funcional completa de
esta versin de la aplicacin ECIES, finalizando con un ejemplo de cifrado
y descifrado que ilustra las posibilidades de utilizacin de la aplicacin.
5.1.
Diseo del esquema ECIES a implementar
El principal objetivo del desarrollo de la versin de ECIES para PC consiste

en poder realizar pruebas con distintas combinaciones de funciones y parmetros.
Debido a ello, adems 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 ms habituales en los estndares analizados, as como algunas
de las opciones que permiten diferenciar las configuraciones descritas en 4.7.
El Captulo 6 presenta la versin de ECIES para tarjetas Java Card. La investigacin de las capacidades criptogrficas de Java Card en relacin a ECIES puso
de manifiesto la existencia de una peculiaridad de carcter fundamental en Java
Card que, sin embargo, no aparece descrita en los estndares donde se incluyen las
distintas versiones de ECIES. Dicha peculiaridad consiste en que la salida de las
181
182
funciones KA (tanto DH como DHC) en Java Card es el resultado de utilizar la

funcin resumen SHA-1 tomando como entrada la primera coordenada del punto de
la curva que acta 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 caractersticas, fue
necesario aadir a la definicin 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 descripcin
de la funcionalidad completa de la versin de ECIES para PC, utilizando para ello
el modelo KEM -DEM popularizado en los ltimos aos y descrito en 2.5.
5.1.1.
Cifrado
El Algoritmo 5.1 describe la fase KEM del proceso de cifrado de la versin de

ECIES desarrollada para PC, mientras que el Algoritmo 5.2 muestra la fase DEM
del proceso de cifrado de dicha versin. De manera global, la entrada del proceso de
cifrado KEM -DEM est formada por un mensaje en claro , una longitud y una
clave pblica , y la salida consiste en el criptograma .
Algoritmo 5.1 Cifrado ECIES en la versin PC (fase KEM )
1. Decidir el formato de representacin de los puntos (comprimida o sin comprimir).
2. Elegir un valor {1, 2, . . . , 1} como clave privada temporal de U.
3. Generar la clave pblica del usuario U, = , cuya representacin hexadecimal es .
4. Calcular el punto de la curva = ( , ) = mediante la funcin DH.
La representacin 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. Diseo del esquema ECIES a implementar
183
Algoritmo 5.2 Cifrado ECIES en la versin PC (fase DEM )

1. Interpretar de una de las siguientes maneras, donde es la clave
de cifrado simtrico, y es la clave para la funcin de autenticacin
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
funcin XOR):
a) .
b) .
2. Calcular el mensaje cifrado = () empleando la clave y el
algoritmo de cifrado simtrico seleccionado por el usuario.
3. Calcular la etiqueta tag = MAC (||[dat]||long) utilizando la clave y
la funcin 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 aclaracin, los elementos dat y long equivalen al dato Param 2
mencionado en el Captulo 4.
4. Enviar el criptograma =( , ,tag) generado mediante la concatenacin de
sus elementos.
5.1.2.
Descifrado
El Algoritmo 5.3 describe la fase KEM del proceso de descifrado de la versin

de ECIES desarrollada para PC, en la que se obtiene el material del que se derivan
las claves de cifrado y autenticacin. Por su parte, el Algoritmo 5.4 muestra la fase
DEM del proceso de descifrado de dicha versin, donde se utilizan las claves de
cifrado y autenticacin 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.
Aritmtica de puntos de la curva y de elementos del

cuerpo finito
En todo desarrollo software de ECC es necesario implementar dos tipos de operaciones: las referidas a los puntos de la curva, y las que operan con elementos del
cuerpo finito.
184
Algoritmo 5.3 Descifrado ECIES en la versin PC (fase KEM )

1. Interpretar como la concatenacin tag, verificando que las longitudes
y el formato de cada elemento de la cadena son correctos.
2. Recuperar la clave a partir de su representacin binaria , comprobando
que el punto tiene orden .
3. Realizar la multiplicacin = ( , ) = , 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 versin PC (fase DEM )

1. Interpretar de una de las siguientes maneras, donde es la clave de
cifrado simtrico, y es la clave para la funcin de autenticacin 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 funcin MAC seleccionada por el usuario mediante las opciones de la aplicacin,
donde dat y long son los elementos descritos en el Algoritmo 5.2. Si al realizar la comparacin el resultado es tag = (), devolver un error.
3. Descifrar el mensaje original mediante la clave y el algoritmo de cifrado
simtrico seleccionado por el usuario, con lo que se obtiene = ENC 1 ().
5.1. Diseo del esquema ECIES a implementar
185
En lo que respecta a la aritmtica de puntos de la curva, la complejidad de las

operaciones de suma de dos puntos y y de obtencin de 2 a partir del punto
se puede determinar en funcin del nmero de operaciones que es necesario realizar
con los elementos de . En la estimacin de la complejidad no se suelen tener en
cuenta las operaciones de suma y diferencia de elementos del cuerpo finito debido a
que, en comparacin con las dems operaciones, son las que requieren menor tiempo
de computacin.
Dados los elementos , , las operaciones que se utilizan en la prctica
para estimar la complejidad de una determinada implementacin de la aritmtica
de puntos son las siguientes:
Multiplicacin: .
Inversin: 1 .
Elevacin al cuadrado: 2 .
Tal como se indic en 2.6.3.3, la suma de los puntos y realizada con coordenadas afines requiere 1 inversin, 2 multiplicaciones y 1 elevacin al cuadrado tanto
en como en 2 , mientras que para obtener el punto 2 a partir de igualmente con coordenadas afines es necesario realizar 1 inversin, 2 multiplicaciones y
2 elevaciones al cuadrado al utilizar la frmula para y una elevacin al cuadrado
menos si se emplea la frmula para 2 .
Existen otros sistemas de coordenadas que utilizan coordenadas proyectivas y
ecuaciones homogneas de las curvas (coordenadas proyectivas estndar, Jacobianas,
Lpez-Dahab, mixtas, etc.) [50, 99]. Estos sistemas implementan la aritmtica de
puntos de manera ms eficiente, dado que en los clculos con coordenadas proyectivas
no es necesario realizar operaciones de inversin, que son las ms costosas desde un
punto de vista computacional (aunque es cierto que, a cambio, en estos sistemas
crece el nmero de multiplicaciones y elevaciones al cuadrado). Sin embargo, en
esta Tesis se han utilizado exclusivamente las frmulas con coordenadas afines en la
implementacin de la aritmtica de puntos. Los motivos para esta decisin son los
siguientes:
1. La utilizacin de coordenadas afines produce que el desarrollo y depuracin
del cdigo Java sea ms sencillo, ya que es posible comparar los resultados con
los de otras implementaciones (Bouncy Castle, FlexiProvider, etc.).
2. Debido a las caractersticas de las plataformas hardware utilizadas y a la ventaja comparativa del PC (procesador de 32 bits, memoria ilimitada en comparacin con las necesidades del programa, etc.), la ejecucin de la implementacin
para PC es de forma natural ms rpida que la ejecucin de la implementacin
para tarjetas Java Card, por lo que la optimizacin de la versin de ECIES
para PC no ha sido considerado un objetivo prioritario.
186
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 comparacin basada en
este elemento.
5.2.
Diagrama de clases
La aplicacin 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 aplicacin aparecen en color azul, mientras que las clases
estndar FileFilter, FileView, JDialog, JFrame, Object y PlainDocument de
Java, de las que heredan algunas de las clases del programa, aparecen en color gris.
A continuacin se incluye una breve descripcin de cada una de las clases, listadas
por orden alfabtico:
Constantes
Interfaz que incluye algunas constantes utilizadas por las dems clases del
programa.
Curva
La clase abstracta Curva define los mtodos que sern implementados por las
clases CurvaFp y CurvaF2m, y que contienen la lgica para crear y utilizar
curvas elpticas definidas sobre un cuerpo finito.
CurvaF2m
La clase CurvaF2m incluye la implementacin adaptada a los cuerpos finitos
binarios de los mtodos definidos por la clase abstracta Curva.
CurvaFp
La clase CurvaFp incluye la implementacin adaptada a los cuerpos finitos
primos de los mtodos definidos por la clase abstracta Curva.
ECIES
ECIES es la clase principal de la aplicacin, y por ello contiene el mtodo main.
Desde ECIES se realizan las invocaciones a las dems clases del paquete, siendo
responsable adems de generar la interfaz grfica y gestionar el procesamiento
provocado por las acciones del usuario.
ElementoCuerpo
5.2. Diagrama de clases
Figura 5.1: Diagrama de clases de la aplicacin ECIES
187
188

La clase abstracta ElementoCuerpo define los mtodos con denominacin comn que sern implementados por ElementoCuerpoFp y ElementoCuerpoF2m,
y que contienen la lgica para definir y gestionar elementos de un cuerpo finito.
ElementoCuerpoF2m
La clase ElementoCuerpoF2m incluye la implementacin adaptada a los cuerpos finitos binarios de los mtodos definidos por la clase ElementoCuerpo.
ElementoCuerpoFp
La clase ElementoCuerpoFp incluye la implementacin adaptada a los cuerpos
finitos primos de los mtodos definidos por la clase abstracta ElementoCuerpo.
FicheroPubPri
La clase FicheroPubPri define los iconos azul y rojo utilizados por la aplicacin en las ventanas de seleccin de ficheros para identificar los archivos con
claves pblicas y privadas, respectivamente.
FiltroDocumentos
La clase FiltroDocumentos incluye los elementos que permiten limitar el tipo
de datos de entrada (dgitos, caracteres hexadecimales o alfabeto ASCII) de
las cajas de texto utilizadas por la aplicacin.
FiltroFicheros
La clase FiltroFicheros permite crear los filtros necesarios con el objetivo de
de mostrar nicamente los ficheros con extensin .pri y .pub en las ventanas
de seleccin de ficheros de claves pblicas y privadas respectivamente.
IntArray
La clase IntArray implementa la lgica de soporte para la realizacin de operaciones relacionadas con bases polinmicas en cuerpos binarios.
JDialogAcerca
La clase JDialogAcerca es utilizada para mostrar informacin sobre la versin
de la aplicacin ECIES y sobre los autores del desarrollo.
JDialogAyuda
La clase JDialogAyuda incluye los elementos grficos de la ventana emergente
utilizada por ECIES para presentar al usuario la pgina HTML con informacin sobre la aplicacin.
JDialogClave
La clase JDialogClave es utilizada por la aplicacin ECIES durante la interpretacin de los contenidos de un fichero que contenga una clave privada, a fin
de permitir al usuario introducir su cdigo de acceso a dicha clave.
5.2. Diagrama de clases
189
JDialogDescompresin
La clase JDialogDescompresin implementa la funcionalidad ofrecida por la
ventana emergente del submen Descompresin 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 lgica utilizada por la ventana
emergente del submen Clave aleatoria, descrito en 5.3.7.2.
Punto
La clase abstracta Punto define los mtodos que sern implementados por las
clases PuntoFp y PuntoF2m, y que contienen la lgica para crear puntos de una
curva elptica definida sobre un cuerpo finito y operar con ellos.
PuntoF2m
La clase PuntoF2m incluye la implementacin adaptada a los cuerpos finitos
binarios de los mtodos definidos por la clase abstracta Punto.
PuntoFp
La clase PuntoFp incluye la implementacin adaptada a los cuerpos finitos
primos de los mtodos definidos por la clase abstracta Punto.
Utilidades
La clase Utilidades incluye los mtodos para realizar conversiones entre elementos de tipo array de bytes, BigInteger y las cadenas de texto que representan 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 implementacin de la aritmtica de puntos de la curva y de elementos de los
cuerpos finitos se ha realizado utilizando la clase estndar BigInteger [209] de Java
SE, que permite operar con valores enteros de longitud variable, e incluye funciones
como la suma con otro elemento BigInteger (mtodo add), el clculo de la longitud
en bits del valor entero (biLength), la obtencin del inverso mdulo otro elemento
del mismo tipo (modInverse), el resultado de la operacin XOR con otra variable
BigInteger (xor) o la exponenciacin modular (modPow), entre otras funciones.
190
5.3.
Descripcin funcional de la aplicacin
En este apartado se describen de manera detallada las funcionalidades de la aplicacin 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
visin prctica de lo expuesto en los captulos anteriores, representando un ejemplo
de las posibilidades de las aplicaciones para entorno PC que implementen capacidades de criptografa de curva elptica.
Esta aplicacin 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 aplicacin ECIES permite dos modos de funcionamiento: un modo sencillo

donde el usuario no necesita seleccionar parmetros de funcionamiento, pues stos
ya estn prefijados (correspondindose con los parmetros definidos en 5.3.3.1), y
un modo avanzado que posibilita realizar pruebas con mltiples combinaciones de
los parmetros disponibles en ECIES. El modo seleccionado por defecto es el modo
sencillo, aunque durante la ejecucin del programa el modo activo puede modificarse
a travs del men Modo.
Al iniciar el programa, lo primero que aparece en pantalla es la ventana principal,
5.3. Descripcin funcional de la aplicacin
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 mens y opciones
del programa. Los elementos que se encuentran disponibles en el modo sencillo
cuando se inicia la ejecucin son Programa, Modo, Curvas, Utilidades y Cuerpo
GF(), mientras que si se utiliza el modo avanzado entonces tambin estarn
disponibles los elementos Perfiles y Test.
Barra de pestaas: permite seleccionar la pestaa activa mediante una presentacin tabular. En el modo sencillo las pestaas disponibles son Parmetros,
Cifrado y Descifrado, a las que se aade la pestaa Configuracin en el modo
avanzado.
Pestaa activa: rea de presentacin donde se sitan los elementos pertenecientes la pestaa en uso.
5.3.2.
Men Programa
El men Programa consta de los submens Aspecto, Ayuda, Acerca de y Salir.

5.3.2.1.
Submen Aspecto
La opcin Aspecto (ver Figura 5.4) permite adaptar las caractersticas de todos
los elementos de la aplicacin (textos, iconos, colores, etc.) a las de los temas grficos disponibles en Java. Las posibilidades existentes en la versin 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 revisin
10 de Java SE 6.
Motif: aspecto Unix.
Windows: apariencia nativa de las aplicaciones Windows.
Windows Clsico: tema grfico muy similar al anterior pero con un aspecto
ms clsico.
192
Figura 5.3: Ventana principal de la aplicacin
Figura 5.4: Opciones del men Programa
193
Por motivos estticos, se ha decidido implementar nicamente los dos temas

ms modernos, en concreto Nimbus (Figura 5.5) y Windows (Figura 5.6). Si la
distribucin Java SE instalada en el PC de trabajo implementa la esttica Nimbus,
ste ser el tema seleccionado por defecto al iniciar la aplicacin. En caso contrario,
el aspecto grfico 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 opcin 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.
194
Figura 5.7: Ventana de la opcin Ayuda
5.3.2.3.
Submen Acerca de
La opcin Acerca de (ver Figura 5.4) muestra informacin general sobre la versin
del programa y los responsables del desarrollo, tal como aparece en la Figura 5.8.
5.3.2.4.
Submen Salir
La opcin Salir (ver Figura 5.4), al igual que el icono situado en la esquina superior derecha en todas las aplicaciones Windows, permite abandonar la aplicacin.
Sin embargo, en previsin de la activacin accidental de esta opcin, antes de
abandonar el programa se mostrar al usuario una pantalla de confirmacin, 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 opcin Acerca de
Figura 5.9: Pantalla de confirmacin de la opcin Salir
195
196
5.3.3.1.

Opcin Sencillo
El modo sencillo (Figura 5.10) utiliza una parametrizacin fija del esquema
ECIES, correspondiente a la versin ECIES-3, que consiste en los siguientes elementos:
Funcin resumen HASH : SHA-256.
Funcin KDF : KDF2.
Funcin MAC : HMAC-SHA-256-256.
Funcin 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.
Inclusin de la clave temporal del emisor como parmetro de KDF : activado.
Interpretacin de la salida de la funcin KDF : ENC ||MAC.
Representacin binaria: comprimida.
Junto a la utilizacin de los parmetros anteriores, el modo sencillo oculta los
mens Perfiles y Test de la barra de mens, as como la pestaa Configuracin, ya
que estos elementos slo tienen utilidad en el modo avanzado.
Figura 5.10: Opcin Sencillo
5.3.3.2.
Opcin Avanzado
El modo avanzado (Figura 5.11) permite, en comparacin con el modo sencillo, especificar todos los parmetros para los que el esquema ECIES puede utilizar
distintas opciones. En concreto, los elementos que es posible parametrizar son los
siguientes:
197
Figura 5.11: Opcin Avanzado
Funcin resumen HASH.

Funcin KDF.
Funcin MAC.
Funcin de cifrado ENC.
Inclusin de la clave pblica temporal del emisor como parmetro de KDF.
Utilizacin de la primera coordenada del secreto compartido o de su resumen.
Interpretacin de la salida de la funcin KDF.
Representacin binaria comprimida o sin comprimir.
Adems de lo anterior, el modo avanzado habilita los mens Perfiles y Test de
la barra de mens, as como la pestaa Configuracin.
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 pestaa Configuracin relacionados con un mismo modo
de operacin. Las opciones que el usuario puede elegir estn relacionadas con las
configuraciones M1, M2, P1, P2 y P3 descritas en 7.2 y utilizadas en las pruebas
del Captulo 7.
198
Figura 5.12: Opciones del men Perfiles
5.3.4.1.
Opcin Configuracin M1
La opcin Configuracin M1, diseada para su utilizacin por la aplicacin de

PC, emplea los siguientes valores:
Cuerpo sobre el que se define la curva elptica: 2 .
Funcin HASH : SHA-256.
Funcin KA: DH.
Funcin KDF : KDF2.
Funcin ENC : AES en modo CBC con relleno PKCS#5.
Longitud de la clave de cifrado simtrico: 32 bytes.
Inclusin de la clave temporal del emisor como parmetro de KDF : s.
Utilizacin de la coordenada del secreto compartido o de su resumen: coordenada.
Representacin binaria de los puntos de la curva: comprimida.
5.3.4.2.
Opcin Configuracin M2
La opcin Configuracin M2, diseada para su utilizacin tanto por la aplicacin

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

Funcin KA: DH.
Funcin KDF : KDF2.
Funcin ENC : TDES en modo CBC sin relleno.
Inclusin de la clave temporal del emisor como parmetro de KDF : no.
Utilizacin de la coordenada del secreto compartido o de su resumen: resumen.
Representacin binaria de los puntos de la curva: sin comprimir.
5.3.4.3.
Opcin Configuracin P1
La opcin Configuracin P1, diseada para su utilizacin por la aplicacin de

PC, personaliza los elementos de ECIES con los siguientes valores:
Cuerpo sobre el que se define la curva elptica: .
Funcin KA: DH.
Funcin KDF : KDF2.
Inclusin de la clave temporal del emisor como parmetro de KDF : s.
200

Representacin binaria de los puntos de la curva: comprimida.
5.3.4.4.
La opcin Configuracin P2, diseada para su utilizacin tanto por la aplicacin

de PC como por las tarjetas JCOP J3A, utiliza los siguientes elementos:
Funcin KA: DH.
Funcin KDF : KDF2.
Utilizacin de la coordenada del secreto compartido o de su resumen: resumen.
5.3.4.5.
La opcin Configuracin P3, diseada para su utilizacin tanto por la aplicacin

de PC como por las tarjetas JCOP J3A, personaliza los elementos de ECIES con
los siguientes valores:
Funcin KA: DH.
Funcin KDF : KDF2.
201
Funcin ENC : AES en modo CBC sin relleno.

5.3.5.
Men Test (modo avanzado)
El men Test es similar al men Perfiles, puesto que permite configurar los parmetros de ECIES de la pestaa Configuracin en el modo avanzado, pero adems
aade los valores necesarios de la pestaa Parmetros 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 recogidos en el documento SECG GEC 2 [253].
202
Figura 5.14: Submen SECG del men Test
5.3.6.
Men Curvas
El men Curvas permite cargar en la pestaa Parmetros informacin correspondiente a la curva seleccionada en funcin 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, ansix9p256r1, ansix9p256k1, ansix9p384r1 y ansix9p521r1.
Curvas sobre 2 : ansix9t163r2, ansix9t163k1, ansix9t193r1, ansix9t193r2, ansix9t233r1, 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 continuacin:
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 dgitos: expresa el tamao 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 funcin resumen de acuerdo al procedimiento
descrito en [15].
203
Figura 5.15: Curvas correspondientes al submen ANSI
k : identifica las curvas de Koblitz (tambin conocidas como curvas anmalas binarias) que facilitan la realizacin de operaciones con los puntos de la
curva. En curvas sobre cuerpos binarios, las curvas de Koblitz estn definidas
mediante la ecuacin 2 + = 3 + 2 + 1, con {0, 1}. ANSI X9.62
tambin utiliza el trmino k para referirse a curvas definidas sobre cuerpos
primos, dadas por la ecuacin 2 = 3 + + , donde = 0 y el valor de es
muy pequeo en comparacin con (3, 5, 7, etc.).
Dgito final: permite diferenciar curvas donde el resto de los parmetros utilizados por esta notacin coinciden.
Es importante resaltar que las curvas publicadas en la versin de 2005 del estndar X9.62 no coinciden con las incluidas en la edicin 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 criptoanlisis (c2pnb176w1, c2pnb163v3, etc.).
De manera adicional, la edicin de 2005 cambi los identificadores de las restantes
curvas (por ejemplo, la curva ansix9p192r1 de la edicin de 2005 es la misma que la
curva prime192v1 de la edicin de 1998).
204
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 pgina 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 continuacin:
P : identifica las curvas sobre cuerpos primos.
r : informa que los coeficientes de la curva se han generado aleatoriamente
segn el procedimiento descrito en [34].
Dgito final: permite identificar diferentes curvas donde el resto de los parmetros utilizados por esta notacin 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.
205
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 binarios).
Cadena de dgitos: expresa el tamao 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, secp160r1, secp160r2, secp192k1, secp224k1, secp224r1, secp256k1, secp384r1 y
secp521r1.
206
Figura 5.18: Curvas correspondientes al submen SECG
Curvas sobre 2 : sect113r1, sect113r2, sect131r1, sect131r2, sect163k1, sect163r1, sect163r2, sect193r1, sect193r2, sect233k1, sect233r1, sect239k1, sect283k1, 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 continuacin:
secp: identifica las curvas sobre cuerpos primos.
sect: indica que se trata de una curva sobre cuerpos binarios.
207
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 binarios).
Dgito final: permite identificar diferentes curvas donde el resto de los parmetros utilizados por esta notacin coinciden.
5.3.7.
Men Utilidades
El men Utilidades ofrece funcionalidades que, sin ser imprescindibles para la

utilizacin del programa de cifrado ECIES, facilitan considerablemente su uso.
5.3.7.1.
Opcin Crear ficheros con claves
La opcin Crear ficheros con claves (ver Figura 5.19) permite generar un par de
claves utilizando la informacin de las curvas estndares referidas en 5.3.6, almacenando la informacin resultante en un fichero con extensin .pri que contiene la
clave privada y un fichero con extensin .pub que alberga la clave pblica.
Figura 5.19: Opciones del men Utilidades
Al seleccionar esta opcin, 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 generacin
y publicacin 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.
208
Figura 5.20: Ventana de creacin de los ficheros de claves
Cdigo de seguridad (obligatorio): cdigo de acceso o contrasea para permitir

el almacenamiento seguro de la clave. La implementacin de la seguridad de
este almacenamiento se realiza mediante la funcin resumen SHA-256 y el
algoritmo de cifrado AES, de manera que la clave privada nunca se almacenar
en claro, siendo necesario introducir el cdigo de seguridad para poder utilizar
la clave privada en las operaciones de descifrado. La clave con la que se cifra
la informacin consiste en los primeros 16 bytes de la salida de la funcin
SHA-256, donde la entrada se corresponde con el cdigo de seguridad.
Nombre de fichero (obligatorio): los dos ficheros a generar, tanto el que contiene
la clave pblica como el utilizado para almacenar la clave privada, compartirn el mismo nombre de fichero, diferencindose en la extensin (.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 funcin 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 opcin se deja
vaca, el programa generar una semilla distinta de forma pseudoaleatoria en
cada proceso de creacin de los ficheros de claves mediante el Algoritmo 5.5,
que ha sido diseado con el nico objetivo de asegurar que en cada ejecucin
se generen semillas distintas. A continuacin, la semilla generada es utilizada como argumento de la clase Random para obtener el valor pseudoaleatorio
209
deseado.
Informacin 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 Generacin de una semilla aleatoria
Ejecutar el siguiente bucle seis veces:
1. Obtener el tiempo en milisegundos mediante la funcin estndar del lenguaje
Java SE System.currentTimeMillis().
2. Multiplicar el valor obtenido por el nmero de iteracin.
3. Identificar los ltimos tres dgitos del resultado de la multiplicacin.
4. Concatenar esos tres dgitos con los obtenidos en las anteriores iteraciones,
formando una cadena final de dieciocho dgitos.
Los ficheros de claves generados contienen toda la informacin necesaria para
poder identificar las claves y realizar las operaciones de cifrado y descifrado, utilizando internamente una estructura XML para almacenar los distintos datos. A
continuacin se muestra un ejemplo del contenido de un fichero .pub que alberga la
clave pblica de un usuario:
<?xml version=1.0 encoding=ISO-8859-1 standalone=yes?>

<parmetros>
<param id=1>
<notacin>HEXA</notacin>
<cuerpo>Fp</cuerpo>
<clave>
<tipo>Pblica</tipo>
<proveedor>SEC</proveedor>
<identificador>secp112r1</identificador>
</clave>
<info>Clave de Vctor</info>
DB7C2ABF62E35E668076BEAD208B
<a>DB7C2ABF62E35E668076BEAD2088</a>
659EF8BA043916EEDE8911702B22
<Gx>09487239995A5EE76B55F9C2F098</Gx>
<Gy>A89CE5AF8724C0A23E0E0FF77500</Gy>
<n>DB7C2ABF62E35E7628DFAC6561C5</n>
<Vx>CBB0C998897515D8AF9E474ADEF0</Vx>
210
<Vy>7B492D22D7872C4CCAB5B58620CC</Vy>
</param>
</parmetros>
Continuando con el mismo ejemplo, el fichero .pri que contiene la clave privada
del usuario anterior tendra el siguiente contenido:
<parmetros>
<param id=1>
<cuerpo>Fp</cuerpo>
<clave>
<tipo>Privada</tipo>
<identificador>secp112r1</identificador>
</clave>
<info>Clave de Vctor</info>
DB7C2ABF62E35E668076BEAD208B
<a>DB7C2ABF62E35E668076BEAD2088</a>
659EF8BA043916EEDE8911702B22
<Gx>09487239995A5EE76B55F9C2F098</Gx>
<Gy>A89CE5AF8724C0A23E0E0FF77500</Gy>
<n>DB7C2ABF62E35E7628DFAC6561C5</n>
<uC>7D1C0CF1FC2B741B960A7AE0093B7485</uC>
</param>
</parmetros>
A continuacin se muestra otro ejemplo de ficheros .pub y .pri, en esta ocasin
representando un par de claves definidas sobre un cuerpo binario:
<parmetros>
<param id=1>
<cuerpo>F2m</cuerpo>
<clave>
<tipo>Pblica</tipo>
<identificador>sect113r1</identificador>
211
</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>
</parmetros>
<parmetros>
<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>
</parmetros>
El significado de cada uno de los elementos de ambos ficheros XML es el siguiente:
212
<param id =1>: nmero de clave (ya sea pblica o privada) relativo al fichero, dado que los ficheros .pri y .pub permiten ser utilizados como agendas
de claves y almacenar ms de una clave.
<notacin>: indicacin relativa a la notacin empleada para representar los
datos. El nico valor utilizado en la generacin de los ficheros es HEXA, lo que
implica que los datos se encuentran definidos en formato hexadecimal. Esta
decisin de diseo no afecta al proceso de lectura de los ficheros de claves
como parte de las operativas de cifrado y descifrado, donde adems del valor
HEXA tambin es posible utilizar el valor DECIMAL, indicando que los datos se
encuentran representados como nmeros en esta base.
<cuerpo>: cuerpo de la curva elptica utilizada en la generacin de las claves.
En funcin del cuerpo seleccionado, los posibles textos para esta opcin son
Fp y F2m.
<clave>: cadena informativa que incluye los elementos <tipo> (que puede
tener los valores Privada y Pblica), <proveedor> (cuyos valores posibles
son ANSI, Brainpool, NIST y SEC) y por ltimo <identificador>, el nombre
especfico que cada proveedor otorga a sus curvas.
<info>: informacin 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>: parmetros comunes para curvas definidas tanto
sobre un cuerpo primo como binario.
: parmetro asociado a las curvas definidas sobre un cuerpo primo.
<m>, <k3>, <k2>, <k1>: parmetros de la curvas definidas sobre un cuerpo
binario.
<Vx>, <Vy>: coordenadas del punto que representa la clave pblica creada.
<uC>: clave privada del usuario cifrada con el algoritmo AES mediante el cdigo
de acceso.
5.3.7.2.
Opcin Clave aleatoria
La opcin 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 : nmero primo y semilla de aleatoriedad.
213
Cuerpos 2 : parmetro , que representa el nmero de bits utilizado en la

representacin 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 generacin de clave en cuerpos
Figura 5.22: Ventana de generacin de clave en cuerpos 2
214
5.3.7.3.

Opcin Descompresin de puntos
La opcin Descompresin de puntos (ver Figura 5.19) permite, tras introducir los
datos asociados a una curva elptica 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 Descompresin de puntos es diferente, tal como puede comprobarse en las Figuras 5.23 y 5.24.
Figura 5.23: Ventana de descompresin 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 elptica de trabajo. Si el nombre de la
opcin es Cuerpo GF(), al pulsar sobre ese ttulo el usuario comprobar que el
nombre es sustituido por Cuerpo GF(2^m), siendo seleccionada de manera automtica la pestaa Parmetros donde se encuentran las cajas de texto de los parmetros
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.
215
Figura 5.24: Ventana de descompresin de puntos en cuerpos 2
De forma equivalente, si se encuentra seleccionada la opcin Cuerpo GF(2^m) y

el usuario pulsa sobre ese ttulo, el nombre del elemento cambiar por el de Cuerpo
GF(), siendo seleccionada automticamente la pestaa Parmetros donde se sitan
las cajas de texto con los parmetros asociados al nuevo cuerpo.
Figura 5.25: Men principal con el elemento Cuerpo GF() activado
5.3.9.
Pestaa Configuracin (en modo avanzado)
La pestaa Configuracin, que slo es visible cuando se encuentra seleccionado

el modo avanzado, permite configurar los elementos de ECIES independientemente
216
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

pestaa, y que son presentados a continuacin indicando las opciones disponibles.
Funcin resumen HASH :
SHA-1.
SHA-256.
SHA-384.
SHA-512.
Funcin de derivacin de claves KDF :

KDF1.
KDF2.
Funcin de generacin de cdigos MAC :

HMAC-SHA-1-160.
HMAC-SHA-256-256.
HMAC-SHA-384-384.
HMAC-SHA-512-512.
Funcin de cifrado simtrico 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 funcin MAC.
217
Figura 5.27: Pestaa Configuracin
Longitud en bytes de la clave a utilizar por el algoritmo de cifrado simtrico.

Opcin de incluir la clave pblica temporal del emisor como entrada de la
funcin KDF.
Utilizacin de la primera coordenada del dato secreto compartido o de la
salida a travs de la funcin resumen seleccionada previamente por el usuario.
Orden en que se debe interpretar la salida de la funcin de generacin de claves
(MAC ||ENC o ENC ||MAC ).
Representacin binaria de los puntos de la curva comprimida o sin comprimir.
5.3.10.
Pestaa Parmetros
La pestaa Parmetros muestra los elementos de la curva elptica a los que es

necesario dar valores para poder realizar operaciones de cifrado o descifrado con
218
ECIES. Esta operacin puede realizarse mediante tres procedimientos:

1. Introduccin manual de los parmetros por parte del usuario de la aplicacin
a travs de las cajas de texto de esta pestaa.
2. Seleccin de una de las curvas disponibles a travs del men Curvas, con lo
que la aplicacin rellenar los campos relativos a la curva y el usuario de
la aplicacin tendr que aadir la informacin relativa a la clave pblica del
receptor (para operaciones de cifrado) o de su propia clave privada (en el caso
de tratarse de una operacin de descifrado).
3. Seleccin de la clave pblica del destinatario o de la clave privada del propio
usuario de la aplicacin mediante las opciones apropiadas de las pestaas Cifrado y Descifrado. En estos casos, si los ficheros que incluyen dichas claves
contienen todos los elementos necesarios, el usuario no deber aadir ningn
dato en la pestaa Parmetros.
En los casos en los que la aplicacin aporte algunos de los datos (es decir, el
usuario seleccione una curva o indique al programa el fichero con la clave a recuperar), las cajas de texto de esta pestaa se mantienen habilitadas, lo que implica que
el usuario podra modificar dichos datos. Si dicha modificacin conlleva algn error
(por ejemplo, el elemento generador o la clave pblica no pertenecen a la curva modificada), ste ser convenientemente detectado durante la ejecucin de cualquiera
de las operaciones del programa (cifrado, descifrado, generacin de la clave pblica
a partir de los datos de la curva y de la clave privada, etc.).
En cuanto al contenido de esta pestaa, dependiendo de si el cuerpo finito de
trabajo, denominado de forma genrica , es o 2 , la pestaa Parmetros
mostrar distintos elementos, tal como puede apreciarse en las Figuras 5.28 y 5.29.
Independientemente del cuerpo finito seleccionado, los parmetros comunes que
aparecen en esta pestaa en ambos casos son los siguientes:
a: primer parmetro de la curva elptica cuya ecuacin es (2.4) o (2.5), con
.
b: segundo parmetro de la curva elptica, con .
Gx : primera coordenada del generador , donde = ( , ). es un
elemento del cuerpo base , mientras que es un punto de la curva elptica.
Gy: segunda coordenada del generador , con .
n: orden del punto .
219
Figura 5.28: Pestaa Parmetros con el men Cuerpo GF() activado
h: cofactor del punto , de manera que = #( )/, siendo #( ) el

nmero de puntos de la curva elptica.
u: clave privada temporal del usuario emisor, donde .
v : clave privada permanente del usuario receptor, siendo .
Ux : primera coordenada de la clave pblica temporal del usuario emisor. La
clave pblica es , donde = ( , ). es un elemento de y es un
punto de la curva elptica.
Uy: segunda coordenada de la clave pblica temporal del usuario emisor, donde
.
Vx : primera coordenada de la clave pblica permanente del usuario receptor.
La clave pblica es , donde = ( , ). es un elemento de , mientras
que es un punto de la curva elptica.
220
Figura 5.29: Pestaa Parmetros con el men Cuerpo GF(2^m) activado
Vy: segunda coordenada de la clave pblica permanente del usuario receptor,

donde .
Cuando el men Cuerpo GF() est activado, el nico elemento relacionado con
este cuerpo que aparece en la pestaa es:
p: nmero 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 pestaa son:
m: exponente utilizado por el cuerpo finito 2 .
k3 : exponente del polinomio reductor () = + 3 + 2 + 1 + 1.
k2 : exponente del polinomio reductor ().
221
k1 : exponente del polinomio reductor ().

Independientemente del cuerpo de trabajo, la pestaa Parmetros incluye los
siguientes elementos:
Formato: representacin de los datos precedentes en formato hexadecimal o
decimal.
Resultado: informacin acerca del resultado de la ejecucin.
Generar : botn que permite calcular las coordenadas de las claves pblicas
y a partir de las claves privadas y .
Borrar : botn para el borrado de todos los datos de esta pantalla.
Si la operacin de clculo 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
Falta el
Falta el
Falta el
Falta el
Falta el
Falta el
Falta el
El punto
El punto
5.3.11.
parmetro p, operacin abortada.

parmetro m, operacin abortada
parmetro k1, operacin abortada.
parmetro Gx, operacin abortada.
parmetro Gy, operacin abortada.
parmetro n, operacin abortada.
parmetro u, operacin abortada.
parmetro v, operacin abortada.
U es el punto en el infinito (U=O).
V es el punto en el infinito (V=O).
Pestaa Cifrado
La pestaa Cifrado muestra todos los elementos necesarios para generar un criptograma 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 corresponden, respectivamente, con las zonas de gestin de opciones, las cajas de texto y
los botones de operacin, tal como puede apreciarse en la Figura 5.30.
La primera seccin est formada por los siguientes elementos:
222
Figura 5.30: Pestaa Cifrado
Clave pblica receptor : clave pblica permanente del destinatario del criptograma. Si el usuario pulsa la opcin Texto, la pestaa Parmetros pasar a ser
la pestaa en uso, de manera que el usuario pueda introducir manualmente los
datos asociados a la clave pblica del receptor. En cambio, si el usuario elige la
opcin Fichero, el programa permitir seleccionar el fichero donde se encuentra
la clave pblica, tal como puede apreciarse en la Figura 5.31. Si el procesamiento del fichero con la clave pblica es correcto, en la pestaa Parmetros
aparecern los datos obtenidos del fichero con extensin .pub seleccionado.
Mensaje a cifrar : mensaje en claro que el emisor desea enviar al receptor. Si
el usuario pulsa la opcin Texto (opcin por defecto), deber introducir el
mensaje manualmente, sin que exista ningn lmite en la longitud del mensaje
generado por el usuario. Por el contrario, si el usuario elige la opcin 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 tamao
223
es superior a 1 Kbyte, aunque internamente se utilizar el fichero completo en

el proceso de cifrado, nicamente se mostrarn 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 comparacin, 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 generacin. Si el usuario pulsa la opcin
Texto (opcin por defecto), el contenido del criptograma ser nicamente mostrado por pantalla en su caja de texto asociada. Por el contrario, si el usuario
elige la opcin Fichero, el programa permitir al usuario seleccionar un fichero
(Figura 5.33) de manera que, adems de mostrarse el criptograma en la caja
de texto, su contenido ser almacenado en el fichero indicado. nicamente en
este ltimo caso, si el tamao del criptograma supera el lmite de 1 Kbyte,
entonces slo se mostrarn (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: Seleccin del fichero con la clave pblica
En caso de elegir la opcin Fichero en cualquiera de los tres elementos anteriores,

aparecer en la ventana principal del programa el nombre del fichero seleccionado
junto al elemento en cuestin, excepto en el caso de la clave pblica del receptor,
donde si el fichero con la clave incluye el elemento <info>, y su contenido es vlido,
entonces se mostrar la cadena de texto que contenga <info>. Si el fichero con la
clave pblica contuviera ms de una clave, y alguna de dichas claves no tuviera un
nodo <info> vlido, a fin de poder identificar dicha clave, el programa calcular su
posicin en el fichero de claves y mostrar el texto Clave sin identificador #i,
224
Figura 5.32: Seleccin del fichero con el mensaje en claro
Figura 5.33: Seleccin del fichero donde se almacenar el criptograma
225
donde i tendr como valor la posicin de la clave. Por ltimo, si el fichero contuviera
solamente una clave, y el elemento <info> no fuera vlido o no estuviera presente, el
programa utilizar como identificador el nombre del fichero. La Figura 5.34 muestra
las diversas variantes existentes en la representacin del identificador de la clave
pblica.
Figura 5.34: Modalidades de identificacin de la clave pblica
La segunda seccin de la pestaa 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 lmite).
Etiqueta: elemento de uso opcional a utilizar por la funcin 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 informacin acerca del resultado de la ejecucin.
Las cajas de texto del mensaje en claro y de la etiqueta permiten mostrar su contenido interpretado como texto o en formato hexadecimal. En caso de que el mensaje
226
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 aparecer 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 cmoda por correo electrnico
utilizando esta ltima codificacin.
La tercera seccin de la pestaa Cifrado est formada por los siguientes elementos:
Cifrar : botn que desencadena la generacin de un criptograma ECIES a partir
del mensaje en claro, la etiqueta y los parmetros asociados.
Borrar : botn que permite borrar el contenido de las cajas de texto de esta
pantalla y devolver las opciones de configuracin de la primera seccin a su
estado inicial.
La Figura 5.36 muestra un ejemplo del proceso de cifrado, en el que se ha seleccionado la clave pblica del receptor de un fichero que contiene un elemento <info>
vlido (y que por tanto es el utilizado como identificador de la clave pblica), el fichero Inicio de Don Quijote.txt contiene el mensaje en claro y el fichero Quijote
cifrado.out se emplear para almacenar el resultado de la operacin.
Si la operacin efectuada es correcta, los posibles mensajes de xito que puede
mostrar el elemento Resultado son:
Clave pblica recuperada correctamente.
Por el contrario, algunos de los posibles mensajes de error que puede mostrar el
elemento Resultado son:
Falta seleccionar la funcin resumen en Configuracin.
Falta seleccionar la funcin KDF en Configuracin.
Falta seleccionar la funcin MAC en Configuracin.
227
Figura 5.36: Ejemplo de cifrado ECIES
Falta seleccionar la funcin de cifrado simtrico en Configuracin.

Falta especificar la longitud de la clave MAC en Configuracin.
Falta seleccionar la clave pblica 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 pblica 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 clculo del cdigo MAC.
5.3.12.
Pestaa Descifrado
La pestaa 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,
228
azul y rojo, y que se corresponden con el rea de gestin de opciones, las cajas de
texto y los botones de operacin.
Figura 5.37: Pestaa Descifrado
La primera seccin est formada por las siguientes opciones:

Clave privada receptor : clave privada fija del destinatario del criptograma. Si el
usuario pulsa la opcin Texto, la pestaa Parmetros pasar a ser la pestaa
en uso, de manera que el usuario pueda introducir manualmente los datos
asociados a su clave privada. En cambio, si el usuario elige la opcin 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 pestaa Parmetros aparecern los datos
obtenidos del fichero con extensin .pri seleccionado.
Criptograma: mensaje cifrado empaquetado (tripleta de elementos) que el emisor ha enviado al receptor. Si el usuario pulsa la opcin Texto (opcin por defecto), deber introducir el criptograma manualmente, sin que exista ningn
229
lmite en la longitud del criptograma introducido de esta forma por el usuario.

Por el contrario, si el usuario elige la opcin Fichero, el programa permitir 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 tamao es superior a 1 Kbyte, aunque
internamente se utilizar el fichero completo en el proceso de cifrado, nicamente se mostrarn en la caja de texto asociada al criptograma los primeros
1024 bytes, utilizando una fuente de color azul para indicar este hecho. En
comparacin, 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 operacin de descifrado ECIES. Si el usuario pulsa la opcin Texto (opcin por defecto), el contenido del mensaje descifrado ser nicamente mostrado por pantalla en su caja de texto asociada.
Por el contrario, si el usuario elige la opcin Fichero, el programa permitir al
usuario seleccionar un fichero (Figura 5.40) de manera que, adems de mostrarse el mensaje en claro en la caja de texto, su contenido ser almacenado en
el fichero indicado. nicamente en este ltimo caso, si el tamao del mensaje
descifrado supera el lmite de 1 Kbyte, entonces slo se mostrarn (utilizando
de nuevo una fuente de color azul) los primeros 1024 bytes del mensaje. Comparativamente, 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: Seleccin del fichero con la clave privada
En caso de elegir la opcin Fichero en cualquiera de los tres elementos anteriores,

aparecer en la ventana el nombre del fichero seleccionado junto al elemento en
cuestin, excepto en el caso de la clave privada del receptor del criptograma, donde
si el fichero con la clave incluye un elemento <info> vlido, entonces se mostrar la
cadena de texto que contenga <info>. Si el fichero con la clave pblica contuviera
230
Figura 5.39: Seleccin del fichero con el criptograma
Figura 5.40: Seleccin del fichero donde se almacenar el mensaje en claro
231
ms de una clave privada, y alguna de dichas claves no tuviera un campo <info>

vlido, a fin de poder identificar dicha clave el programa calcular su posicin en el
fichero de claves y mostrar el texto Clave sin identificador #i, donde i tomar
como valor la posicin de la clave. Por ltimo, si el fichero contuviera solamente una
clave, y el elemento <info> no fuera vlido, el programa utilizar como identificador
el nombre del fichero. La Figura 5.41 muestra las diversas variantes existentes en la
representacin del identificador de la clave privada.
Figura 5.41: Modalidades de identificacin de la clave privada
Durante el proceso de interpretacin de los datos que contenga el fichero con

la clave privada, puesto que dicha clave se almacena cifrada, el programa requerir al usuario que introduzca el cdigo de acceso o contrasea (Figura 5.42) que
permitir utilizar la clave en el proceso de descifrado. Si el cdigo es correcto, el
contenido de la clave privada se insertar en la caja de texto de la pestaa Parmetros correspondiente al elemento u, aunque dado su carcter crtico, en lugar de
mostrarse su contenido en claro, ste se mostrar enmascarado, tal como se observa
en la Figura 5.43.
La segunda seccin de la pestaa Descifrado est compuesta por las siguientes
cajas de texto:
Criptograma: contenido del mensaje cifrado empaquetado recibido por el destinatario.
Etiqueta: elemento de uso opcional a utilizar por la funcin MAC.
Mensaje descifrado: mensaje en claro obtenido tras el proceso de descifrado
ECIES.
232
Figura 5.42: Ventana de solicitud del cdigo de acceso
Figura 5.43: Enmascaramiento de la clave privada
Resultado: campo con informacin acerca del resultado de la ejecucin.

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 formato 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 seccin de la pestaa Descifrado est formada por los siguientes elementos:
Descifrar : botn que desencadena el proceso de descifrado ECIES a partir del
criptograma, la etiqueta y los parmetros asociados.
Borrar : botn que permite borrar el contenido de las cajas de texto de esta
pantalla y devolver las opciones de configuracin de la primera seccin a su
estado inicial.
233
La Figura 5.45 muestra un ejemplo de proceso de descifrado, en el que se ha seleccionado la clave de un fichero que contiene un elemento <info> vlido (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 utilizar para almacenar el mensaje en claro resultante de la operacin.
Figura 5.45: Ejemplo de descifrado ECIES
Si la operacin 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.
234
Problema con el formato del fichero con la clave privada.

Falta introducir el criptograma.
Error durante la creacin 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 utilizacin
En los siguientes apartados se muestran dos ejemplos completos de los procesos

de cifrado y descifrado, incluyendo una descripcin 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 utilizacin

real del modo sencillo del programa de cifrado ECIES para PC, en el que todos los
datos de inters (clave pblica del destinatario, mensaje en claro y criptograma)
se almacenan en fichero. Tras iniciar la aplicacin, los pasos que debe completar el
usuario son los siguientes:
1. Seleccionar la pestaa Cifrado en la ventana inicial.
2. Seleccionar la opcin Fichero correspondiente al elemento Clave pblica receptor.
3. Utilizando las capacidades de navegacin de la ventana emergente aparecida,
seleccionar el fichero con la clave pblica del usuario receptor del mensaje y
pulsar sobre el botn Abrir. En este ejemplo, el fichero seleccionado es Fp 521
SHA-256.pub (Figura 5.46).
Aparecer a continuacin de nuevo la ventana principal de ECIES con la informacin asociada al elemento <info> de la clave pblica, que en este caso
particular es el texto Clave pblica Bernardo (Figura 5.47).
4. Seleccionar la opcin Fichero correspondiente al elemento Mensaje a cifrar.
seleccionar el fichero con el mensaje en claro a cifrar y pulsar sobre el botn
Abrir. En este ejemplo, el mensaje a cifrar ser el contenido del fichero Quijote
- Captulo I.txt (Figura 5.48).
5.4. Ejemplos de utilizacin
Figura 5.46: Seleccin del fichero con la clave pblica del destinatario
Figura 5.47: Identificador de la clave pblica del destinatario
Figura 5.48: Seleccin del fichero con el mensaje en claro
235
236

Aparecer a continuacin de nuevo la ventana principal de ECIES con los
primeros 1024 bytes del fichero interpretados como texto y en color azul, indicando 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 opcin Fichero correspondiente al elemento Criptograma.

seleccionar de entre los existentes el fichero donde se almacenar el criptograma
(o alternativamente introducir un nombre para la creacin de un nuevo fichero
para tal fin) y pulsar sobre el botn Guardar. En este ejemplo, el fichero que
albergar el criptograma es Quijote cifrado.out (Figura 5.50).
Aparecer a continuacin de nuevo la ventana principal de ECIES con el nombre del fichero (Figura 5.51).
8. Aadir (opcionalmente) una etiqueta, la cual ser utilizada en el clculo del
cdigo MAC. En el ejemplo, el texto de la etiqueta es Prueba de cifrado
(Figura 5.52).
9. Pulsar el botn Cifrar. Si la operacin de cifrado ha concluido satisfactoriamente, aparecer el texto Proceso finalizado correctamente junto al elemento
Resultado, y la caja de texto del elemento Criptograma mostrar los primero 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: Seleccin 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
237
238
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 inters (clave privada del destinatario, criptograma y mensaje en claro resultante) se almacenan en forma de fichero. Tras iniciar la aplicacin,
los pasos que debe completar el usuario son los siguientes:
1. Seleccionar la pestaa Descifrado en la ventana inicial.
2. Seleccionar la opcin Fichero correspondiente al elemento Clave privada receptor.
seleccionar el fichero con la clave privada del usuario receptor del mensaje y
pulsar sobre el botn Abrir. En este ejemplo, el fichero seleccionado es Fp 521
SHA-256.pri (Figura 5.54).
239
Figura 5.54: Seleccin del fichero con la clave privada del destinatario
Aparecer a continuacin la ventana de introduccin del cdigo de acceso

(Figura 5.55), el cual permitir la utilizacin de la clave privada por parte del
usuario.
Figura 5.55: Introduccin de la contrasea para el acceso a la clave privada
Si el cdigo introducido es el correcto, tras pulsar el botn Procesar aparecer

de nuevo la ventana principal de ECIES con la informacin asociada al elemento <info> de la clave pblica, que en este caso particular es el texto Clave
privada Bernardo (Figura 5.56).
4. Seleccionar la opcin Fichero correspondiente al elemento Criptograma.
seleccionar el fichero con el criptograma y pulsar sobre el botn Abrir. En este
ejemplo, el mensaje a cifrar ser el contenido del fichero Quijote cifrado.out
(Figura 5.57).
Aparecer a continuacin de nuevo la ventana principal de ECIES con los
primeros 1024 bytes del fichero en formato Base64 y en color azul, indicando
240
Figura 5.56: Identificador de la clave privada del destinatario
Figura 5.57: Seleccin del fichero con el criptograma
que el mensaje no se muestra completo en la caja de texto (Figura 5.58).

6. Seleccionar la opcin 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 creacin de un
nuevo fichero para tal fin) y pulsar sobre el botn Guardar. En este ejemplo,
el fichero donde que albergar el criptograma es Quijote descifrado.txt
(Figura 5.59).
Aparecer a continuacin de nuevo la ventana principal de ECIES con el nombre del fichero (Figura 5.60).
8. Aadir una etiqueta (en caso de que se utilizara durante el proceso de cifrado),
la cual ser utilizada en el clculo del cdigo MAC. En el ejemplo, el texto de
la etiqueta es Prueba de cifrado (Figura 5.61).
9. Pulsar el botn Descifrar en la ventana principal. Si la operacin de descifrado ha concluido satisfactoriamente, aparecer el texto Proceso finalizado
Figura 5.58: Identificador del fichero con criptograma
Figura 5.59: Seleccin del fichero para el mensaje descifrado
Figura 5.60: Identificador del fichero para el mensaje descifrado
241
242
Figura 5.61: Contenido de la caja de texto de la etiqueta
correctamente junto al elemento Resultado, y la caja de texto del elemento 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
Captulo 6
Implementacin de ECIES en Java
Card
Resumen del captulo

En este captulo se presenta una implementacin del esquema de cifrado
ECIES para tarjetas Java Card, indicando las particularidades existentes en funcin de la versin Java Card implementada por las tarjetas
inteligentes utilizadas en esta Tesis. De manera adicional, este captulo incluye la descripcin funcional de la aplicacin desarrollada para la
comunicacin con las tarjetas inteligentes comerciales empleadas en la
Tesis.
6.1.
Elementos criptogrficos de ECIES disponibles

en Java Card
Tal como se indic en el Captulo 4, debido al carcter hbrido del esquema

de cifrado ECIES, su implementacin requiere de elementos de diversa naturaleza
criptogrfica. El grado de soporte de dichos elementos es muy variable dependiendo
de la versin 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 versin de
la plataforma Java Card.
243
244
6.1.1.
Java Card 2.1
La nica caracterstica criptogrfica relacionada con ECIES incluida en la versin

Java Card 2.1 es la funcin resumen SHA-1.
6.1.2.
Java Card 2.1.1
En la revisin 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 segua siendo la funcin resumen SHA-1.
6.1.3.
Java Card 2.2
Java Card 2.2 fue la primera versin en incluir soporte para ECC, que junto con
el resto de las novedades conforman la siguiente lista de caractersticas criptogrficas
relacionadas con ECIES:
Funcin 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 funcin SHA-1.
Funcin 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 revisin 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
idntica 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 introduccin de los algoritmos

HMAC y de la familia de funciones resumen SHA-2. La lista detallada de capacidades criptogrficas directamente relacionadas con la implementacin de ECIES es la
siguiente:
6.1. Elementos criptogrficos de ECIES disponibles en Java Card
245
Funcin HASH : SHA-1, SHA-256, SHA-384, SHA-512.

Funcin KA: DH y DHC en curvas elpticas, manteniendo la particularidad
reseada en los apartados anteriores.
Funcin 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.
Funcin MAC : HMAC-SHA-1, HMAC-SHA-256, HMAC-SHA-384 y HMACSHA-512.
y claves de 112, 128, 160 y 192 bits en cuerpos primos.
6.1.6.
Java Card 3.0
Por ltimo, la versin Java Card 3.0.1 ha extendido el nmero de modos de

funcionamiento del algoritmo AES y de las longitudes de clave disponibles para los
cuerpos primos, aadiendo a la familia de funciones resumen el algoritmo SHA224. La lista completa de funcionalidades relacionadas con ECIES presente en esta
versin es la siguiente:
Funcin HASH : disponibilidad de las funciones SHA-1, SHA-224, SHA-256,
SHA-384 y SHA-512.
Funcin KA: DH y DHC en curvas elpticas, con la novedad de que a partir
de esta versin es posible decidir si el valor obtenido es la primera coordenada
del elemento secreto compartido o su salida al pasar por la funcin SHA-1.
Funcin ENC : AES con bloques de 128, 192 y 256 bits utilizando los modos
CBC y ECB sin relleno. Adems se ofrecen los modo CBC y ECB con relleno
compatible con el documento PKCS#5 [234] y el modo ECB compatible con
los mtodos 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.
Funcin MAC : HMAC-SHA-1, HMAC-SHA-256, HMAC-SHA-384 y HMACSHA-512. La funcin HMAC-SHA-224, aunque por coherencia debera haber
estado incluida, no forma parte de la especificacin Java Card 3.0.
y claves de 112, 128, 160, 192, 224, 256 y 384 bits en cuerpos primos.
246
6.2.
Resumen de funcionalidad ECC en Java Card
El Cuadro 6.1 recoge de forma resumida la informacin presentada en los anteriores 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 funcin es el resumen de la primera coordenada del elemento secreto compartido proporcionado por las funciones DH y DHC.
JC 2.2
SHA-1
HASH
KA
ENC
MAC
JC 2.2.1
SHA-1
JC 2.2.2
SHA-1
SHA-256
SHA-384
SHA-512
JC 3.0
SHA-1
SHA-224
SHA-256
SHA-384
SHA-512
DH
DH
DH
DH
DHC
DHC
DHC
DHC
DH
DHC
DES
DES
DES
DES
TDES
TDES
TDES
TDES
AES-128
AES-128
AES-128
AES-128
AES-192
AES-256
HMAC-SHA-1
HMAC-SHA-1
HMAC-SHA-256 HMAC-SHA-256
112,128,160,192 112,128,160,192 112,128,160,192 112,128,160,192,
224,256,384
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 investigacin 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
6.3.1.
247
NetBeans
Aunque en un primer momento se decidi utilizar la herramienta de desarrollo

NetBeans en su versin 6.7, por ser la primera con soporte de la tecnologa Java Card,
esta opcin fue descartada tras realizar las primeras pruebas y comprobar la correcta
estructura de la aplicacin diseada, ya que NetBeans slo permite compilar applets
empleando las bibliotecas Java Card 3.0, lo que impide su descarga en tarjetas reales
por tratarse de una versin muy reciente para la que los fabricantes de tarjetas
inteligentes todava no tienen productos comerciales.
6.3.2.
Herramientas de lnea de comandos de Sun
La segunda opcin para el desarrollo de applets Java Card fue utilizar directamente los ejecutables mediante lnea de comandos proporcionados por Sun. Para
ello, fue necesario configurar el PC de trabajo de la siguiente manera:
1. Instalacin de JDK 1.5 en la carpeta C:\Java\jdk1.5.0_21.
2. Configuracin de la variable del sistema JAVA_HOME con la localizacin del
directorio C:\Java\jdk1.5.0_21.
3. Instalacin del paquete Java Card 2.2.2 en C:\java_card_kit-2_2_2.
4. Configuracin de la variable del sistema JC_HOME con el valor de la carpeta
C:\java_card_kit-2_2_2.
5. Instalacin de la versin 1.6.2 del software Ant en C:\apache-ant-1.6.2.
6. Configuracin de la variable del sistema ANT_HOME con el valor del directorio C:\apache-ant-1.6.2.
7. Modificacin de la variable PATH del sistema para que incluya la cadena
%JAVA_HOME %\bin; %JC_HOME %\bin; %ANT_HOME %\bin.
La generacin del applet se efecta en dos pasos: en el primero, se realiza la
compilacin del fichero con extensin .java, generando un fichero .class; en el segundo
paso, se obtiene el fichero con extensin .cap que ser posteriormente descargado en
la tarjeta (para ms informacin sobre el proceso de compilacin de los applets en
Java Card, ver 3.5).
Para realizar la compilacin del fichero JCECIES.java, es necesario seguir los
siguientes pasos:
1. Guardar el fichero JCECIES.java en C:\JCECIES\src\victor\tesis\.
248
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 extensin .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 carpeta C:\JCECIES\src\victor\tesis junto con los ficheros tesis.cap, tesis.exp y
tesis.jca, que sern 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 ms 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 aplicacin Eclipse 3.2 con los
complementos de NXP instalados.
6.4.
Esquema de la aplicacin
Antes de iniciar la fase de trabajo con tarjetas reales, en previsin de que no fuera
posible conseguir tarjetas que implementaran curvas definidas tanto sobre cuerpos
primos como binarios, se disearon dos versiones de la aplicacin Java Card cuya
6.4. Esquema de la aplicacin
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 aplicacin Java Card diseada
para curvas elpticas definidas sobre cuerpos binarios. En el caso de curvas elpticas
sobre cuerpos primos la aplicacin es equivalente, representando los valores 01, 02,
03 y 04 del parmetro 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
4
5
import j a v a c a r d . framework . ;
import j a v a c a r d . s e c u r i t y . ;
import j a v a c a r d x . c r y p t o . ;
6
7
8
9
public c l a s s JCECIESF2m extends Applet

{
// D e c l a r a c i n de v a r i a b l e s
10
11
12
13
14
15
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 )
{
new JCECIESF2m ( ) ;
}
protected JCECIESF2m ( )
250
16

{
// 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
17
18
19
20
21
22
23
public boolean s e l e c t ( )
{
return true ;
}
24
25
26
27
public void p r o c e s s (APDU apdu )

{
// 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
32
33
34
if ( selectingApplet () )
{
return ;
}
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
switch ( b u f f e r [ ISO7816 . OFFSET_INS ] )

{
case 0 x61 :
p r o c e s s I N S 6 1 ( apdu ) ;
break ;
case 0 x62 :
break ;
case 0 x63 :
break ;
case 0 x64 :
break ;
case 0 x65 :
break ;
case 0 x66 :
break ;
case 0 x67 :
break ;
case 0 x68 :
break ;
case 0 x69 :
break ;
}
}
private void p r o c e s s I N S 6 1 (APDU apdu )
6.4. Esquema de la aplicacin

68
251
{
//
//
//
//
//
//
69
70
71
72
73
74
Crea nuevas c l a v e s de l o n g i t u d 113 , 131 , 163 y 193

INS : 61
P1 : t i p o de c l a v e (01=113 , 02=131 , 03=163 , 04=193)
P2 : 00 ( s i n uso en e s t a i n s t r u c c i n )
Lc : 00 ( s i n d a t o s de e n t r a d a )
Ejemplo : 0061010000
75
76
77
78
79
80
81
82
83
84
85

{
// O b t i e n e l o s par metr os de l a s c l a v e s
// INS : 62
// P1 : t i p o de c l a v e (01=113 , 02=131 , 03=163 , 04=193)
// 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 : tamao d e l c u e r p o GF( q ) en b i t s , 0 8 : U, 0 9 : u )
// Lc : 00 ( s i n d a t o s de e n t r a d a )
// Ejemplo : 0062010900
86
87
88
89
90
91
92
93
94
95
96
97

{
// 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
// INS : 63
// P1 : t i p o de c l a v e (01=113 , 02=131 , 03=163 , 04=193)
// 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 : tamao d e l c u e r p o GF( q ) en b i t s , 0 8 : U, 0 9 : u )
// 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
// Ejemplo : 006301081F0401A4CD29 . . .
}
98
99
100
101
102
103
104
105
106
107

{
// 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
// INS : 64
// P1 : t i p o de c l a v e (01=113 , 02=131 , 03=163 , 04=193)
// 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 : tamao d e l c ue r p o GF( q )
en b i t s , 0 8 : U, 0 9 : u )
// 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
// Ejemplo : 006401081F0401A4CD29 . . .
}
108
109
110
111
112
113
114

{
// Almacena e l mensaje a c i f r a r
// INS : 65
// P1 : t i p o de o p e r a c i n ( 0 1 : mensaje nuevo , 0 2 : anexar a
mensaje almacenado )
// P2 : 00 ( s i n uso en e s t a i n s t r u c c i n )
252

// 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
continuacin
// Ejemplo : 00650100080102030405060708
115
116
117
118

{
// Almacena l a e t i q u e t a
// INS : 66
// P1 : s i n uso en e s t a i n s t r u c c i n
// 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
// Ejemplo : 006600000454657374
}
119
120
121
122
123
124
125
126
127
128

{
// 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
// INS : 67
// P1 : t i p o de c l a v e (01=113 , 02=131 , 03=163 , 04=193)
// Ejemplo : 0067010000
}
129
130
131
132
133
134
135
136
137
138

{
// Almacena e l c r i p t o g r a m a a d e s c i f r a r
// INS : 68
// 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 )
// 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 continuacin
// Ejemplo : 006801003 B040182D553 . . .
139
140
141
142
143
144
145
146
147
148
149

{
// 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
// INS : 69
// P1 : t i p o de c l a v e (01=113 , 02=131 , 03=163 , 04=193)
// Ejemplo : 0069010000
}
150
151
152
153
154
155
156
157
158
159
160
Listado 6.1: Esquema de la aplicacin Java Card para curvas 2
6.5. Pruebas con tarjetas virtuales
6.5.
253
Pruebas con tarjetas virtuales
Las herramientas de desarrollo para Java Card de Sun incluyen el fichero ejecutable cref.exe, que es una implementacin en el lenguaje de programacin 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 bsicas mediante ficheros de instrucciones (scripts).
La implementacin que hace el programa cref.exe de la plataforma Java Card
no es completa, y adems vara en cada edicin de Java Card. Mientras que el
soporte de las capacidades criptogrficas en la versin de cref.exe que se incluye
con el paquete de desarrollo para Java Card 2.2.2 es bastante completo, la versin
para Java Card 3.0 proporcionada por Sun hasta el momento no implementa ninguna
funcionalidad criptogrfica.
A ttulo informativo, a continuacin se detallan las caractersticas criptogrficas
implementadas en la versin de cref.exe para Java Card 2.2.2:
Funcin HASH : ejecuta correctamente las funciones ALG_SHA y ALG_SHA_256.
Las otras dos variantes, ALG_SHA_384 y ALG_SHA_512, producen una excepcin
de tipo CardRuntime.
Funcin ENC : el modo ALG_AES_BLOCK_128_CBC_NOPAD se ejecuta correctamente, pero el modo ALG_AES_BLOCK_128_ECB_NOPAD, aunque no produce
errores en la compilacin, genera una excepcin CardRuntime.
Funcin MAC : no soporta ninguno de los mtodos 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 continuacin se muestran los pasos necesarios para generar un fichero de instrucciones con los datos necesarios para cargar e instalar la aplicacin en una tarjeta
virtual, donde como se puede observar es necesario aadir 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, aadindole las siguientes lneas al principio
del fichero:
254

powerup;
// Seleccin 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 edicin del fichero, aadindole las siguientes lneas al final:

// Creacin 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 aplicacin, stos debern ser incluidos inmediatamente
antes de la orden powerdown. Las siguientes lneas muestran un ejemplo de APDU
de prueba:
// Seleccin 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 ejecucin de las instrucciones se
almacenar en el fichero APDU.txt.
6.6.
Pruebas con tarjetas reales
En el momento de iniciar la elaboracin de esta Tesis, los fabricantes Gemalto,

Oberthur y G&D no disponan de productos comerciales con soporte para criptografa de curva elptica. 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 caractersticas. De entre todas ellas, el modelo seleccionado
finalmente fue JCOP 41, ya que estaban disponibles para su compra en diversas
tiendas online y adems implementaban funciones de ECC.
Tras la recepcin de las tarjetas JCOP 41, y la confirmacin 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 adems de implementar curvas elpticas sobre cuerpos primos incluyen algunas
de las funciones criptogrficas aadidas recientemente al estndar Java Card (AES,
SHA-256, etc.).
Debido a las peculiaridades de las tarjetas JCOP, con el objetivo de realizar un
mayor nmero de pruebas y comparaciones se decidi desarrollar tres versiones del
256
applet en lugar de las dos previstas inicialmente. Dichas versiones son las correspondientes 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 instalacin 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 aplicacin desde el entorno Eclipse utilizando las claves que por
defecto incluyen todas las tarjetas JCOP de desarrollo.
En cuanto al tamao de los applets, tal como puede apreciarse en la Figura 6.2
(compuesta por imgenes obtenidas del entorno de desarrollo Eclipse), la versin
JCOP-M2 (AID A00000000501) ocupa 5031 bytes, el tamao de la versin JCOPP2 (AID A00000000601) es 4328 bytes, y por ltimo la versin JCOP-P3 (AID
A00000000701) ocupa 4404 bytes. Dichas cantidades no incluyen ni las variables
que se alojarn en RAM (de tipo transient en Java Card) ni las que residirn en
memoria EEPROM (de tipo persistent), aunque s incluye las matrices formadas
por elementos constantes (es decir, las matrices de tipo final static).
La versin JCOP-M2 tiene un tamao 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 gestin de las curvas es
ms compleja en la versin JCOP-M2.
Por otra parte, el tamao de la versin JCOP-P3 es ligeramente superior al de
la versin JCOP-P2 debido a que las funciones MAC y HMAC (SHA-256 y HMACSHA-256) utilizadas en dicha versin generan unos datos de salida de mayor longitud
que las funciones correspondientes de la versin JCOP-P2 (SHA-1 y HMAC-SHA-1),
siendo necesario aumentar el tamao de los arrays con los que se trabaja de forma
interna.
Una vez realizada la descarga de la aplicacin en las tarjetas JCOP mediante
el entorno Eclipse y los complementos de NXP, las pruebas de comunicacin con el
applet Java se han realizado utilizando dos aplicaciones diferentes: el propio entorno
Eclipse, utilizado principalmente para depurar los diferentes applets mediante la
realizacin de pruebas individuales, y una aplicacin Java SE con interfaz grfica,
desarrollada por el autor de esta Tesis y presentada en detalle en 6.7.
6.7.
Aplicacin JCOPECIES
Tras comprobar la correcta implementacin y depuracin 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 Captulo 7 y facilitar a los posibles
6.7. Aplicacin JCOPECIES
257
Figura 6.2: Tamao de los aplets JCOP-M2, JCOP-P2 y JCOP-P3
usuarios la utilizacin del esquema de cifrado en tarjetas inteligentes, se decidi

desarrollar una aplicacin Java SE para PC que realizase las operaciones de cifrado
y descifrado.
Esta aplicacin, denominada de forma abreviada JCOPECIES, presenta cuatro
pantallas a las que se puede acceder mediante la pestaa apropiada, tal y como se
describe a continuacin:
258
Pestaa Configuracin (Figura 6.3): incluye los elementos que permiten seleccionar 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
pestaa permite generar nuevos pares de claves para una tarjeta y curva dada, as como recuperar el valor de la clave pblica seleccionada, mostrando la
Figura 6.6 el resultado final de ambos procesos. Por ltimo, esta pantalla incluye una caja de texto donde se pueden visualizar las APDU intercambiadas
con la tarjeta inteligente en cualquiera de las operativas implementadas por
la aplicacin (cifrado, descifrado, generacin de pares de claves y recuperacin
de la clave pblica).
Figura 6.3: Pestaa Configuracin
Pestaa Cifrado (Figura 6.7): permite aadir la curva pblica del destinatario
del criptograma, el mensaje en claro a cifrar y la etiqueta a utilizar de manera
opcional por la funcin MAC. El resultado del proceso de cifrado se muestra
en la caja de texto asociada al criptograma.
Pestaa Descifrado (Figura 6.8): permite incluir el criptograma a descifrar y
la etiqueta opcional para la funcin MAC, mostrando el mensaje original en
su caja de texto.
6.7. Aplicacin JCOPECIES
259
Figura 6.4: Lectores de tarjetas disponibles
Figura 6.5: Curvas implementadas en JCOP 41 y JCOP J3A
Pestaa Acerca (Figura 6.9): muestra informacin sobre la versin del programa JCOPECIES y sus autores.
Como parte de las distintas funciones implementadas, la aplicacin muestra de
forma grfica los errores debidos a las siguientes causas (Figura 6.10):
Falta de seleccin de un lector de tarjetas.
Seleccin de un lector donde no se ha introducido ninguna tarjeta.
Falta de seleccin de la curva de trabajo.
Utilizacin 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 caractersticas:
Figura 6.6: Generacin y recuperacin de una clave pblica de 192 bits
260
Figura 6.7: Pestaa Cifrado
Al mensaje original se le aaden tantos bytes como sea necesario hasta que la
longitud en bytes del mensaje as modificado sea mltiplo de 8 (en las tarjetas
JCOP 41, ya que implementa el algoritmo TDES) o mltiplo 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 codificacin en formato
hexadecimal del nmero de bytes que es necesario aadir.
A diferencia del esquema de relleno PKCS#5 habitual, si la longitud en bytes
del mensaje original en bytes ya es mltiplo de 8 (JCOP 41) o de 16 (JCOP
J3A), no se aade ningn byte adicional.
El motivo de incluir esa modificacin al esquema PKCS#5 se debe a las limitaciones en la longitud del mensaje original que impone la implementacin en Java
Card, y que por diseo del applet utiliza una nica APDU tanto para transmitir
el mensaje original a la tarjeta como para recuperar el criptograma. Proporcionalmente, en el mbito de la centena de bytes, la prdida de 8 16 bytes (segn la
tarjeta) para relleno es elevada, por lo que en esta implementacin se ha suprimido
la necesidad de aadir un nuevo bloque en tales casos.
261
Figura 6.8: Pestaa Descifrado
Debido a ello, existira un caso en el que podra producirse prdida de informacin al descifrar un mensaje, en concreto cuando la longitud del mensaje original
es mltiplo de 8 (JCOP 41) o 16 (JCOP J3A), y el valor de los ltimos bytes
es precisamente la codificacin hexadecimal del nmero (es decir, los ltimos bytes 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 situacin, y en caso de que sea as muestra por pantalla el mensaje Proceso cancelado: el contenido del mensaje provocara prdida de
informacin.
6.8.
Ejemplos de utilizacin
En los siguientes apartados se muestran dos ejemplos completos de los procesos

de cifrado y descifrado, incluyendo una descripcin detallada de los pasos necesarios
para realizar las operaciones descritas. Las imgenes que componen las figuras estn
tomadas de los complementos para tarjetas JCOP proporcionado por NXP para el
entorno de desarrollo Eclipse y de la aplicacin JCOPECIES.
262
Figura 6.9: Pestaa Acerca
Figura 6.10: Errores asociados al lector, la curva o la tarjeta
263
Tal como se puede apreciar en todas las figuras incluidas en el resto del presente
captulo, el primer comando en todos los casos es el de seleccin del applet. Esta
seleccin no es necesaria para el correcto funcionamiento de la aplicacin, pero se
ha incluido a fin de demostrar que no es necesario completar la secuencia de todos
los comandos en una nica sesin.
6.8.1.
Cifrado y descifrado en tarjetas JCOP 41 y el complemento de NXP para Eclipse
El ejemplo incluido en este apartado muestra el proceso cifrado de un mensaje 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 aplicacin Java Card
de cifrado y descifrado. Aunque en la instalacin del applet se genera un par de
claves para cada longitud permitida por el fabricante, como medida de precaucin
los usuarios pueden solicitar a la tarjeta la generacin 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 necesitaran
enviar para la generacin de dichas claves, y que son:
Seleccin del applet: A00000000501.
Generacin de un par de claves de 113 bits: 0061010000.
La Figura 6.12 muestra todos los parmetros asociados a las claves del usuario U.
El ltimo comando enviado permite obtener la clave privada de U, por lo que dicho
comando slo est disponible en la versin de pruebas del applet, siendo eliminada
de la versin definitiva de la aplicacin que sera utilizada por usuarios reales. Por
su parte, la Figura 6.13 muestra de manera equivalente los parmetros asociados a
las claves del usuario V.
Tal y como se puede apreciar en las Figuras 6.12 y 6.13, todos los parmetros
coinciden a excepcin de las claves privadas y pblicas, ya que las tarjetas JCOP
264
Figura 6.11: Generacin de nuevas claves en JCOP 41
41 utilizan una nica curva para cada una de las longitudes posibles, cambiando en
cada generacin aleatoria de claves nicamente los valores y para un usuario U.
Dada la curva 2 + = 3 + 2 + caracterizada por el conjunto de parmetros =(, (), , , , , ), los comandos empleados en la Figura 6.12 para la
obtencin de los parmetros de las claves asociadas al usuario U son los presentados
a continuacin:
Parmetro : 0062040100.
Parmetro : 0062040200.
Polinomio reductor (): 0062040300.
Punto de la curva que acta como el generador : 0062040400.
Cofactor : 0062040500.
Orden del punto : 0062040600.
Figura 6.12: Parmetros de las claves de 193 bits de U en JCOP 41
265
266
Figura 6.13: Parmetros de las claves de 193 bits de V en JCOP 41
267
Tamao de la clave (longitud en bits del cuerpo binario): 0062040700.

Clave pblica : 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 cdigo de error definido por el propio applet
(FF62), lo que indica que, a pesar de estar especificado el mtodo para obtener
el cofactor en Java Card, esta funcionalidad no est implementada en las tarjetas
JCOP 41.
Una vez obtenidos los parmetros de las propias claves por parte de los usuarios
U y V (con el objetivo, por ejemplo, de distribuir su clave pblica junto con los
parmetros 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 parmetro
de entrada opcional en el clculo del cdigo MAC, y la clave pblica del receptor
del mensaje cifrado. Una vez estos elementos estn almacenados en la memoria de
la tarjeta, el usuario U podr solicitar al applet la generacin del criptograma que
posteriormente deber enviar al usuario V. La Figura 6.14 muestra los comandos
necesarios, y que se detallan a continuacin:
Envo de la clave pblica del usuario V:
0064040833040147EF73CAC299773F20AF95E64B01B8EFED22A0AD8
DC53DD300AE2A3607E5D51CF66A82F623A69FD6D876C265128FFF
D9FD.
Envo del mensaje en claro a cifrar:
00650100201112131415161718212223242526272831323334353637384142
434445464748.
Envo de la etiqueta para el clculo del cdigo MAC : 006600000454657374.
Solicitud de generacin del criptograma: 0067040000.
El resultado de la operacin de cifrado es el criptograma
0401BC9A5BE00DB6F5FDDEA249434FED1665A0749236160C622301736
8B704A497646EBD7D87249647B4F6C900E3978BB887887A40F0FFE036B
8E9364F525E107ED6B3BD6E00D651E689F3F70F813B30AC66FD7BECC
931E850D19FE644F1886656C43E91FAE913,
268
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 comandos que V necesita enviar a la tarjeta a fin de obtener el mensaje descifrado
estn incluidos en la Figura 6.15 y listados a continuacin:
Envo de la etiqueta para el clculo del cdigo MAC : 006600000454657374.
Envo 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.
269
Figura 6.15: Comandos de descifrado ejecutados por V en JCOP 41
6.8.2.
Cifrado y descifrado en tarjetas JCOP J3A y la aplicacin JCOPECIES
A continuacin se muestra un ejemplo de cifrado y descifrado empleando la

aplicacin JCOPECIES y una tarjeta JCOP J3A con la configuracin P3 y la curva
sect193r1. La Figura 6.7 recoge los datos utilizados en el proceso de cifrado, y que
son los siguientes:
Clave pblica del destinatario:
042A38ACD50BDBBE2FE80DB46492E10CE988310A9E7679FAAE739
5DCEAC208B64D0AFE521A0B61DF4C2A2700D48E164D05.
Mensaje a cifrar: Texto Prueba cifrado 1, cuyo valor hexadecimal est representado por la cadena
507275656261206369667261646F2031.
Etiqueta: Cadena Test, cuyo valor hexadecimal es 54657374.
El resultado de este proceso de cifrado es el criptograma
270

04F465E627E750EDC11C0EF383AE077F964A9D12755CA94439A92A6C
DC89E259E41FCFBB3C1EADDDB4831EBBCA1D03F0BF89AD884D829
E76A98E100172F64E1054FDD117E97B04C9CFDBBE610BF3AACC75B4
10448EA679FC44C3C427C3466D275D
cuya codificacin Base64 es

BPRl5ifnUO3BHA7zg64Hf5ZKnRJ1XKlEOakqbNyJ4lnkH8+7PB6t3bSD
HrvKHQPwv4mtiE2CnnapjhABcvZOEFT90RfpewTJz9u+YQvzqsx1tBB
EjqZ5/ETDxCfDRm0nXQ==.
A continuacin es necesario utilizar la tarjeta JCOP J3A que incluye el par de
claves cuya clave pblica fue empleada en el cifrado del mensaje. En este caso, los
datos a incluir en la pestaa Descifrado son nicamente el criptograma y la etiqueta,
mientras que en la pestaa Configuracin es necesario especificar el lector, el tipo de
tarjeta y la curva elptica. La Figura 6.8 muestra el resultado del proceso de cifrado
tal como aparece en la pestaa 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 pestaa Configuracin, tal como puede apreciarse en la Figura 6.16.
Figura 6.16: Ventana APDU con datos de descifrado
Captulo 7
Resultados empricos
Resumen del captulo

Este captulo recoge las pruebas realizadas con las implementaciones de
ECIES para PC y Java Card, utilizando diferentes combinaciones de parmetros y algoritmos en funcin de las posibilidades criptogrficas de
cada una de las plataformas seleccionadas. A fin de analizar los resultados de las pruebas, el captulo incluye una descripcin detallada de las
caractersticas 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 continuacin se detallan las principales
caractersticas 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
Mdulo hardware: P5CT072.
CPU: Secure_MX51 (Memory eXtended/enhanced 80C51) de 8 bits.

Sistema operativo: JCOP 2.2.1.
Versin Java Card: 2.2.1 (implementacin parcial).

Versin GlobalPlatform: 2.1.1.
Tecnologa CMOS: 0,18 m con 5 capas de metal.

Frecuencia externa de reloj: hasta 10 MHz.
Mxima frecuencia interna de reloj: 30 MHz.

Memoria ROM: 160 Kbytes.
Memoria EEPROM: 72 Kbytes.

Memoria RAM: 4608 bytes.
Protocolos de comunicacin: ISO/IEC 7816 (con contactos) e ISO/IEC

14443 Tipo A (sin contactos).
Coprocesadores criptogrficos: TDES, AES y PKI (RSA, ECC, etc).
Cuerpo finito: 2 .
Longitudes de curvas: 113, 131, 163 y 193 bits.

Funcin KA: DH, donde la salida de la funcin es el resumen SHA-1 de

la primera coordenada del dato secreto compartido.
Funcin ENC : DES y TDES en modo CBC sin relleno.
Tarjetas JCOP J3A [201, 202]:
Mdulo hardware: P5CD080.
CPU: Secure_MX51 (Memory eXtended/enhanced 80C51) de 8 bits.

Sistema operativo: JCOP 2.4.1.
Versin Java Card: 2.2.2 (implementacin parcial).

Versin GlobalPlatform: 2.1.1.
Tecnologa CMOS: 0,14 m.
Frecuencia externa de reloj: hasta 10 MHz.
Mxima frecuencia interna de reloj: 30 MHz.

Memoria ROM: 200 Kbytes.
Memoria EEPROM: 80 Kbytes.

Memoria RAM: 6144 bytes.
Protocolos de comunicacin: ISO/IEC 14443 Tipo A (sin contactos).
7.1. Material utilizado
273
Coprocesadores criptogrficos: TDES, AES y PKI (RSA, ECC, etc).

Cuerpo finito: .
Longitudes de curvas: 128, 160 y 192 bits.

Funcin HASH : SHA-1 y SHA-256.
Funcin KA: DH con dos variantes, una en la que la salida de la funcin

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.
Funcin ENC : DES, TDES y AES en modo CBC sin relleno.
La Figura 7.1 presenta el diagrama de los componentes comunes de los mdulos
P5CT072 y P5CD080, donde se pueden apreciar claramente los tres coprocesadores
criptogrficos 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 configuracin durante el proceso de fabricacin.
Figura 7.1: Diagrama de los mdulos P5CT072 y P5CD080
Otro dato interesante es el hecho de que el chip tiene ms entradas (nueve en

el caso de la Figura 7.1) que el nmero de contactos de las tarjetas (tpicamente
ocho, ver 1.3.2.1). Ello se debe a que los chips se disean de manera genrica para
274
poder adaptarse a diferentes configuraciones segn 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 comunicacin 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 informacin 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 sealar que, a pesar de conocer la frecuencia de la seal externa
de reloj proporcionada a la tarjeta, no es posible sin embargo conocer la frecuencia
interna a la que las tarjetas realmente estn trabajando. La nica informacin que
ha sido posible obtener es la asociada a las caractersticas tcnicas de los dos modelos
de tarjetas, la cual indica que la frecuencia interna de trabajo tiene un valor mximo
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 captulo incluyen el tiempo
de transmisin de las APDU apropiadas (de peticin de una operacin y de envo 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 operacin pertinente desde
que dispone de todos los datos y ha recibido la orden de ejecucin hasta los datos
producidos estn listos para ser transmitidos). El tiempo de transmisin, por su
naturaleza, depende de dos parmetros: la longitud de los datos a transmitir, y la
velocidad a la que los datos son transmitidos por el canal de comunicacin.
7.2.
Configuraciones de prueba
Con el objetivo de intentar comparar de forma homognea las implementaciones

del esquema de cifrado ECIES en PC y Java Card, y debido a las limitaciones en
las funcionalidades criptogrficas disponible en las tarjetas JCOP 41 y JCOP J3A,
se han realizado pruebas con las configuraciones detalladas a continuacin.
Configuracin M1:

Funcin KA: DH.
Funcin KDF : KDF2.
276
Utilizacin como parmetro de entrada en la funcin KDF de la primera

coordenada del punto de la curva que representa el secreto compartido.
Utilizacin de la clave pblica temporal del emisor como entrada para la
funcin KDF.
Interpretacin de la salida de la funcin KDF como .
Utilizacin del formato comprimido en la representacin de los puntos de

la curva elptica.
Configuracin M2:

Funcin KA: DH.
Funcin KDF : KDF2.

Utilizacin como parmetro de entrada en la funcin KDF del resumen

SHA-1 de la primera coordenada del punto de la curva que representa el
secreto compartido.
Utilizacin del formato sin comprimir en la representacin de los puntos

Configuracin P1:

Funcin KA: DH.
Funcin KDF : KDF2.



7.2. Configuraciones de prueba
277
Utilizacin de la clave pblica temporal del emisor como entrada para la

funcin KDF.
Utilizacin del formato comprimido en la representacin de los puntos de

la curva elptica.
Configuracin P2:

Funcin KA: DH.
Funcin KDF : KDF2.

Utilizacin como parmetro de entrada en la funcin KDF del resumen

SHA-1 de la primera coordenada del punto de la curva que representa el
secreto compartido.

Configuracin P3:

Funcin KA: DH.
Funcin KDF : KDF2.
Funcin ENC : AES en modo CBC sin relleno.




278
Las configuraciones cuyo nombre comienza por la letra P indican la utilizacin

de curvas sobre cuerpos primos, mientras que las configuraciones cuyo identificador empieza con la letra M implican el uso de curvas sobre cuerpos binarios. Las
versiones P1 y M1 representan la implementacin de ECIES para PC que incorpora las recomendaciones de seguridad reseadas en el Captulo 4. Aunque estas dos
configuraciones no se pueden implementar en las tarjetas Java Card, se han incluido para poder realizar comparaciones con las otras configuraciones. Por su parte,
la configuracin M2 es la versin implementada en las tarjetas JCOP 41, siendo
la configuracin P2 equivalente a la versin M2 con la nica diferencia del cuerpo
finito empleado. Por ltimo, la configuracin P3 es la versin para tarjetas JCOP
J3A que emplea las caractersticas avanzadas de estas tarjetas (funciones SHA-256,
AES, etc.).
Respecto a las curvas elpticas 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 elpticas empleadas en las configuraciones
En las configuraciones M1 y P1 se han utilizado curvas elpticas 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 opcin las curvas cuyos coeficientes han
sido seleccionados aleatoriamente de forma reproducible siguiendo las indicaciones
de [255] (curvas con sufijo r1), y como segunda opcin 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 estn
definidas en [255], con la excepcin de las curvas P-192 [15] y c2pnb163v1 [272].
7.3. Factor de expansin
7.3.
279
Factor de expansin
Este apartado presenta las pruebas en las que se ha calculado el factor de expansin, interpretado en esta Tesis como la relacin entre la longitud del criptograma
(tripleta formado por la clave pblica temporal, el mensaje cifrado y el cdigo
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
tamao final de los criptogramas. La siguiente lista describe dichos elementos:
1. El cuerpo finito , que determina la longitud en bytes de la representacin
binaria asociada a los elementos del cuerpo (y que conforman las coordenadas
de los puntos de la curva elptica).
2. La representacin binaria de la clave pblica temporal del emisor (ya sea comprimida o sin comprimir).
3. La funcin de cifrado simtrico (TDES, AES, etc.), su modo de utilizacin
(ECB, CBC, etc.) y el mtodo de relleno (PKCS#5, sin relleno, etc.).
4. La longitud del cdigo MAC generado.
En el caso particular de las implementaciones Java Card, puesto que la longitud mxima 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 respuesta a una peticin de cifrado o descifrado est contenida en una nica APDU de
respuesta. La utilizacin de peticiones con mensajes y criptogramas cuya respuesta
excediera 255 bytes tendra las siguientes consecuencias:
1. El tiempo de la operacin aumentara al ser necesaria la transmisin de APDU
adicionales por el canal de transmisin.
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 utilizacin de mensajes de excesivo tamao provocara 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 continuacin, el factor de expansin puede ser
calculado como
280
(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 expansin calculado para distintas
combinaciones de claves y mensajes en claro, por sencillez en la exposicin se incluir
nicamente la frmula del valor en cada caso.
7.3.1.
Factor de expansin con la configuracin M1
Las pruebas llevadas a cabo con la configuracin M1 tienen las siguientes propiedades:
La longitud de los mensajes en claro es en todos los casos mltiplo 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 elptica se representan de forma comprimida.
El cdigo 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
frmula
1 = 1 +
+ 16 + 32 =
+ 49,
donde el byte inicial es el prefijo que indica la compresin del punto que representa
la clave pblica temporal , /8 representa el nmero de bytes necesarios para
representar un elemento del cuerpo 2 , el relleno PKCS#5 aade 16 bytes durante
el proceso de cifrado simtrico y, por ltimo, el cdigo MAC ocupa 32 bytes.
El Cuadro 7.2 y la Figura 7.4 muestran el factor de expansin calculado a partir
de la ecuacin (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
configuracin M1.
Curva elptica
sect113r1
sect131r1
sect163r1
sect193r1
sect233r1
sect239k1
sect283r1
sect409r1
sect571r1
281
16
5
5.13
5.38
5.63
5.94
5.94
6.31
7.31
8.56
Longitud del mensaje (bytes)

32
64
128 256 512 1024
3
2
1.5 1.25 1.13 1.06
3.06 2.03 1.52 1.26 1.13 1.06
3.19 2.09 1.55 1.27 1.14 1.07
3.31 2.16 1.58 1.29 1.14 1.07
3.47 2.23 1.62 1.31 1.15 1.08
3.47 2.23 1.62 1.31 1.15 1.08
3.66 2.33 1.66 1.33 1.17 1.08
4.16 2.58 1.79 1.39 1.2
1.1
4.78 2.89 1.95 1.47 1.24 1.12
Cuadro 7.2: Factor de expansin en curvas sobre 2 con la configuracin M1
Figura 7.4: Factor de expansin en curvas sobre 2 con la configuracin M1
282
7.3.2.
Factor de expansin con la configuracin M2
Las caractersticas especficas de las pruebas realizadas con la configuracin M2

son:
La longitud de los mensajes en claro es en todos los casos mltiplo 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 elptica 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 frmula
2 = 1 + 2
+ 20 = 2
+ 21,
8
8
donde el byte inicial es el prefijo aadido para indicar que el punto de la curva que
representa la clave pblica temporal no est comprimido, el valor /8 aparece
duplicado puesto que al no utilizarse compresin de puntos es necesario incluir las
dos coordenadas del punto, y finalmente el cdigo MAC ocupa 20 bytes.
Curva
El Cuadro 7.3 y la Figura 7.5 muestran el factor de expansin calculado mediante

la ecuacin (7.1) al cifrar mensajes de distinta longitud (16, 32, 48, 64, 80, 96, 112,
128, 144 y 160 bytes) utilizando la configuracin M2 con diferentes longitudes de
claves.
sect113r1
sect131r1
c2pnb163v1
sect193r1
16
4.19
4.44
4.94
5.44
32
2.59
2.72
2.97
3.22

48
64
80
96
112 128
2.06 1.8 1.64 1.53 1.46 1.4
2.15 1.86 1.69 1.57 1.49 1.43
2.31 1.98 1.79 1.66 1.56 1.49
2.48 2.11 1.89 1.74 1.63 1.55
144
1.35
1.38
1.44
1.49
160
1.32
1.34
1.39
1.44
Cuadro 7.3: Factor de expansin en curvas sobre 2 con la configuracin M2
7.3.3.
Factor de expansin con la configuracin P1
Las pruebas realizadas en este apartado tienen las siguientes caractersticas especficas:
283
Figura 7.5: Factor de expansin en curvas sobre 2 con la configuracin M2
La longitud de los mensajes en claro es, en todos los casos, mltiplo 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 elptica 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 mltiplo de 16 viene dada por la frmula
log
log
2
2
+ 16 + 32 =
+ 49,
1 = 1 +
8
8
donde el byte inicial es el prefijo aadido por el algoritmo de compresin de puntos
(y cuyos posibles valores son 0x02 0x03), (log2 )/8 representa el nmero de
bytes necesarios para representar un elemento del cuerpo , el relleno PKCS#5
aade 16 bytes durante el proceso de cifrado simtrico y, por ltimo, el cdigo MAC
ocupa 32 bytes.
la ecuacin (7.1) al cifrar mensajes de distinta longitud (16, 32, 64, 128, 256, 512 y
284
Curva elptica
1024 bytes) utilizando la configuracin P1 y haciendo uso de curvas con diferentes

longitudes de clave.
secp112r1
secp128r1
secp160r1
secp192k1
secp224r1
secp256k1
secp384r1
secp521r1
16
4.94
5.06
5.31
5.56
5.81
6.06
7.06
8.19

32
64
128 256 512 1024
2.97 1.98 1.49 1.25 1.12 1.06
3.03 2.02 1.51 1.25 1.13 1.06
3.16 2.08 1.54 1.27 1.13 1.07
3.28 2.14 1.57 1.29 1.14 1.07
3.41 2.2 1.6 1.3 1.15 1.08
3.53 2.27 1.63 1.32 1.16 1.08
4.03 2.52 1.76 1.38 1.19 1.09
4.59 2.8 1.9 1.45 1.22 1.11
Cuadro 7.4: Factor de expansin en curvas sobre con la configuracin P1
Figura 7.6: Factor de expansin en curvas sobre con la configuracin P1
7.3.4.
Las pruebas realizadas en este apartado tienen las siguientes caractersticas especficas:
285

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
dada por la frmula
log
log
2
2
+ 20 = 2
+ 21,
8
8
donde el byte inicial es el prefijo aadido para indicar que el punto de la curva que
representa la clave pblica temporal no est comprimido (y que por lo tanto toma
valor 0x04), el valor (log2 )/8 aparece duplicado ya que al no utilizarse compresin
de puntos es necesario incluir las dos coordenadas del punto, y finalmente el cdigo
MAC ocupa 32 bytes.
2 = 1 + 2
Curva
El Cuadro 7.5 y la Figura 7.7 muestran el factor de expansin calculado a partir

de la ecuacin (7.1) al cifrar mensajes de distinta longitud (16, 32, 48, 64, 80, 96,
112, 128, 144 y 160 bytes) utilizando la configuracin P2 con diferentes longitudes
de claves, segn las curvas consideradas.
secp128r1
secp160r1
P-192

16
32
48
64
80
96
112 128 144 160
4.31 2.66 2.1 1.83 1.66 1.55 1.47 1.41 1.37 1.33
4.81 2.91 2.27 1.95 1.76 1.64 1.54 1.48 1.42 1.38
5.31 3.16 2.44 2.08 1.86 1.72 1.62 1.54 1.48 1.43
7.3.5.
Las caractersticas especficas de las pruebas realizadas en este apartado son:

al utilizar el algoritmo AES en modo CBC sin relleno).
286
Debido a estas caractersticas, la diferencia 3 entre la longitud del criptograma

y la longitud del mensaje original cuando se utilizan curvas definidas sobre viene
dada por la frmula
log
log
2
2
+ 32 = 2
+ 33,
=1+2
8
8
donde el byte inicial es el prefijo aadido para indicar que el punto de la curva
que representa la clave pblica 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 cdigo MAC ocupa 32 bytes.
la ecuacin (7.1) al cifrar mensajes de distinta longitud (16, 32, 48, 64, 80, 96, 112,
128, 144 y 160 bytes) utilizando la configuracin P3 con diferentes claves.
Curva
secp128r1
secp160r1
P-192
287

16
32
48
64
80
96
112 128 144 160
5.06 3.03 2.35 2.02 1.81 1.68 1.58 1.51 1.45 1.41
5.56 3.28 2.52 2.14 1.91 1.76 1.65 1.57 1.51 1.46
6.06 3.53 2.69 2.27 2.01 1.84 1.72 1.63 1.56 1.51
288
7.4.
Tiempo de cifrado
El procedimiento seguido para obtener las mediciones del tiempo de cifrado en

todas las implementaciones tiene las siguientes caractersticas:
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 comn a todas
las pruebas, y mensajes de 176 bytes de longitud en los casos en los que la
respuesta se poda 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 funcin de la API de Java SE utilizada para obtener la medicin 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 implementacin de ECIES

para PC, el tiempo de inicio de la medicin es exactamente antes del clculo del
producto , despus de que todos los parmetros y variables estn cargados en
la memoria RAM del PC. Por su parte, el tiempo final de cada medicin ha sido
obtenido justo despus 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 presentacin.
En cuanto a las implementaciones Java Card, tal como se coment en 6.6,
se ha diseado una aplicacin Java SE de lnea de comandos que se encarga del
envo y recepcin de los comandos APDU, as como de la medicin de tiempos. La
comunicacin 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 medicin en
estas pruebas constituye el instante anterior al envo de la APDU con la peticin 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 recepcin de la APDU de respuesta, por lo que los tiempos
as medidos incluyen tanto el tiempo de transmisin 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
7.4.1.
289
Tiempo de cifrado en PC con la configuracin M1
Al igual que con la configuracin P1, nicamente la versin de Java para PC

dispone de las funcionalidades criptogrficas requeridas por la configuracin M1. El
Cuadro 7.7 y la Figura 7.9 muestran el tiempo de cifrado de la versin para PC de
ECIES.
16
32
48
64
80
96
112
128
144
160
176
113
28.82
27.91
27.52
27.80
27.64
27.71
27.62
27.53
27.55
28.14
28.34
131
35.61
36.02
36.34
36.71
36.62
36.50
36.42
36.40
36.63
36.21
36.26
Longitud del cuerpo

163
193
233
54.94 76.57 102.84
54.4 80.26 103.81
55.01 81.45 103.43
54.35 81.92 102.33
57.60 82.05 102.93
57.23 82.57 103.72
58.03 81.53 102.92
59.61 82.46 103.24
58.61 81.34 103.21
58.00 81.51 102.51
59.67 82.53 102.31
finito 2 (bits)
239
283
106.52 131.56
106.24 133.21
106.12 132.31
105.46 132.04
105.44 132.62
105.32 131.77
105.52 132.34
105.42 131.73
105.30 130.62
105.33 129.72
105.54 129.96
409
220.78
220.52
219.85
220.66
221.53
220.30
220.43
222.71
225.65
224.45
225.53
571
370.40
370.97
369.78
368.64
368.81
370.62
370.36
368.68
369.73
368.42
368.50
Cuadro 7.7: Tiempo de cifrado con curvas sobre 2 en PC (configuracin M1)
7.4.2.
Tiempo de cifrado en PC y Java Card con la configuracin M2
La configuracin M2 ha sido probada tanto en la versin PC de ECIES como en la

implementacin Java Card desarrollada para la tarjeta JCOP 41. El Cuadro 7.8 y la
Figura 7.10 muestran los resultados de la versin 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 configuracin P1
Puesto que la configuracin P1 utiliza unas funciones criptogrficas que no estn

disponibles en la tarjeta Java Card, esta configuracin ha sido utilizada nicamente
en la implementacin PC de ECIES. El Cuadro 7.11 y la Figura 7.13 muestran los
resultados de la versin PC.
290
Figura 7.9: Tiempo de cifrado con curvas sobre 2 en PC (configuracin M1)
16
32
48
64
80
96
112
128
144
160
176
Longitud del cuerpo

113
131
25.91
34.9
26.04
35.15
25.68
35.24
25.99
35.13
25.61
35.04
25.92
35.02
26.01
34.82
26.22
34.79
26.51
34.67
26.55
35.14
26.78
35.07
finito 2 (bits)
163
193
53.56
77.99
55.49
78.13
55.49
78.28
54.27
78.17
54.31
77.97
53.94
77.66
53.36
77.12
53.18
77.93
53.59
79.32
53.69
79.24
53.71
79.50
Cuadro 7.8: Tiempo de cifrado con curvas sobre 2 en PC (configuracin M2)
291
Figura 7.10: Tiempo de cifrado con curvas sobre 2 en PC (configuracin M2)
16
32
48
64
80
96
112
128
144
160
176
Longitud del cuerpo

113
131
296.74
314.65
297.35
314.76
306.58
324.33
307.49
331.62
314.23
332.18
314.59
332.55
323.76
341.66
331.39
348.78
331.53
349.39
331.82
350.70
341.52
358.64
finito 2 (bits)
163
193
332.71
367.64
333.82
368.88
342.34
384.44
349.65
384.58
349.94
384.98
351.54
386.45
360.50
401.76
367.11
401.81
367.57
403.46
368.74
403.70
384.40
418.98
Cuadro 7.9: Tiempo de cifrado con curvas sobre 2 en JCOP 41 e interfaz sin contactos (configuracin M2)
292
Figura 7.11: Tiempo de cifrado con curvas sobre 2 en JCOP 41 e interfaz sin contactos (configuracin M2)
16
32
48
64
80
96
112
128
144
160
176
Longitud del cuerpo

113
131
363.51
384.52
379.26
399.71
398.18
418.68
413.51
433.60
428.94
448.95
444.44
464.41
463.38
483.65
478.95
498.73
494.01
514.38
509.34
529.41
528.36
548.35
finito 2 (bits)
163
193
407.35
446.56
423.00
461.89
441.77
481.21
457.30
496.31
472.47
511.39
487.81
526.91
506.62
545.77
522.03
561.14
537.20
576.33
552.31
591.55
571.23
610.54
Cuadro 7.10: Tiempo de cifrado con curvas sobre 2 en JCOP 41 e interfaz con
contactos (configuracin M2)
293
Figura 7.12: Tiempo de cifrado con curvas sobre 2 en JCOP 41 e interfaz con contactos (configuracin M2)
16
32
48
64
80
96
112
128
144
160
176
112
23.53
23.48
23.72
24.43
23.31
23.28
24.08
23.86
23.9
24.33
23.55
Longitud
128
160
23.94 39.01
23.94 39.28
23.88 40.03
24.64 40.12
24.51 40.05
24.39 39.99
24.57 40.20
24.51 41.49
24.65 40.64
24.83 40.45
24.12 39.77
del cuerpo finito (bits)

192
224
256
384
54.47 68.61 79.06 142.33
54.89 68.95 79.63 141.05
54.82
69
78.89 141.12
54.63 68.91 79.31 141.02
54.27 69.03 78.61 141.28
54.91 69.71 80.92 141.39
54.49 69.15 81.33 142.29
54.78 68.81 82.56 141.84
54.25 69.09 80.18 142.10
54.23 69.3 79.81 142.22
53.96 69.88 79.33 143.07
521
226.02
225.91
225.44
226.55
226.63
225.67
226.64
227.53
228.13
229.36
228.08
Cuadro 7.11: Tiempo de cifrado con curvas sobre en PC (configuracin P1)
294
Figura 7.13: Tiempo de cifrado con curvas sobre en PC (configuracin P1)
7.4.4.
Tiempo de cifrado en PC y Java Card con la configuracin P2
La configuracin P2 ha sido probada tanto en la versin PC de ECIES como en

la implementacin Java Card desarrollada para las tarjetas JCOP J3A de NXP. El
Cuadro 7.12 y la Figura 7.14 muestran los resultados de la versin PC, mientras que
el Cuadro 7.13 y la Figura 7.15 presentan el tiempo de cifrado utilizando tarjetas
JCOP J3A.
7.4.5.
Tiempo de cifrado en PC y Java Card con la configuracin P3
La configuracin 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
versin 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.
Longitud mensaje (bytes)
16
32
48
64
80
96
112
128
144
160
295
Longitud del cuerpo finito

128
160
25.87
40.95
25.79
41.45
25.84
41.02
25.98
40.57
26.21
40.58
25.78
40.04
25.75
40.67
26.15
41.73
26.34
40.94
26.98
41.63
(bits)
192
57.59
57.37
57.29
57.23
56.77
56.70
56.61
56.67
56.99
57.04
296
16
32
48
64
80
96
112
128
144
160
176

128
160
481.55
518.24
482.26
520.29
489.63
526.76
491.59
534.67
499.66
535.46
501.82
536.85
512.23
544.14
519.80
551.29
521.07
552.35
522.50
554.08
529.22
561.74
(bits)
192
587.76
589.71
597.61
603.90
605.29
606.50
620.53
621.59
623.32
623.73
636.95
Cuadro 7.13: Tiempo de cifrado con curvas sobre en JCOP J3A e interfaz sin
contactos (configuracin P2)
Figura 7.15: Tiempo de cifrado con curvas sobre en JCOP J3A e interfaz sin contactos (configuracin P2)
16
32
48
64
80
96
112
128
144
160
297

128
160
23.37
40.49
23.63
40.75
24.97
40.50
25.39
39.54
25.53
39.45
25.45
39.55
24.57
39.23
24.62
39.44
24.67
39.37
24.73
39.44
(bits)
192
57.96
58.32
58.12
58.21
57.91
58.13
58.06
58.03
58.11
58.31
298
16
32
48
64
80
96
112
128
144
160

128
160
512.54
543.31
515.09
544.96
527.88
564.82
535.06
565.95
536.18
567.78
537.58
568.58
551.27
588.09
558.10
588.98
558.89
590.59
560.78
591.69
(bits)
192
613.50
615.51
634.21
635.42
637.21
639.29
657.83
658.56
660.66
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 contactos (configuracin P3)
7.5. Tiempo de descifrado
7.5.
299
Tiempo de descifrado
El procedimiento seguido para obtener las mediciones del tiempo de descifrado

tiene las mismas caractersticas generales que el empleado para el proceso de cifrado.
El punto de medicin de los tiempos inicial y final en la versin PC son equivalentes a
los del proceso de cifrado, y de forma anloga, la medicin en la implementacin Java
Card se ha realizado mediante la misma aplicacin Java SE de lnea 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 encuentra 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 configuracin M1
Al igual que con la configuracin P1, nicamente la versin de Java para PC

dispone de las funcionalidades criptogrficas requeridas por la configuracin M1. El
Cuadro 7.16 y la Figura 7.18 muestran el tiempo de descifrado de esta versin.
16
32
48
64
80
96
112
128
144
160
176
113
28.9
29.0
28.7
28.9
29.3
29.3
29.4
29.3
29.5
29.4
29.7
131
38.5
38.3
38.1
38.1
37.9
38.5
37.9
38.3
38.3
38.4
38.9
Longitud del
163 193
62.6 91.8
61.9 90.8
66.4 90.2
66.3 90.0
66.3 89.0
66.1 87.9
65.6 87.7
65.8 88.0
66.2 88.9
66.4 89.4
66.5 89.8
cuerpo
233
103.4
103.6
103.7
103.2
103.8
103.0
103.7
103.8
104.4
104.1
104.5
finito 2 (bits)
239
283
409
112.1 132.8 226.1
111.7 132.9 226.4
112.1 132.9 228.9
113.4 132.8 227.9
110.8 132.8 227.2
110.7 132.7 228.2
110.5 132.6 228.7
110.3 132.6 227.8
111.0 132.6 227.7
111.8 132.7 228.2
111.6 132.8 228.2
571
356.7
361.2
361.5
359.5
358.0
358.7
358.7
366.4
363.8
364.5
364.6
Cuadro 7.16: Tiempo de descifrado con curvas sobre 2 en PC (configuracin M1)
7.5.2.
Tiempo de descifrado en PC y Java Card con la configuracin M2
La configuracin M2 ha sido probada tanto en la versin PC de ECIES como en la

implementacin Java Card desarrollada para la tarjeta JCOP 41. El Cuadro 7.17 y la
Figura 7.19 muestran los resultados de la versin PC, el Cuadro 7.18 y la Figura 7.20
300
Figura 7.18: Tiempo de descifrado con curvas sobre 2 en PC (configuracin 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 configuracin P1
Puesto que la configuracin P1 utiliza unas funciones criptogrficas que no estn

disponibles en la tarjeta Java Card, esta configuracin ha sido utilizada nicamente
en la implementacin PC de ECIES. El Cuadro 7.20 y la Figura 7.22 muestran los
resultados de la medicin del proceso de descifrado en la versin de ECIES para PC.
7.5.4.
Tiempo de descifrado en PC y Java Card con la configuracin P2
La configuracin P2 ha sido probada tanto en la versin PC de ECIES como en la

implementacin Java Card desarrollada para la tarjeta JCOP J3A. El Cuadro 7.21 y
la Figura 7.23 muestran los resultados de la versin PC, mientras que el Cuadro 7.22
y la Figura 7.24 presentan el tiempo de descifrado utilizando tarjetas JCOP J3A.
16
32
48
64
80
96
112
128
144
160
176
Longitud del cuerpo

113
131
25.68
34.18
25.19
33.91
25.14
34.25
25.16
33.98
25.47
35.01
25.22
34.80
25.84
34.92
25.68
35.25
25.75
35.35
25.38
35.36
25.45
35.99
301
finito 2 (bits)
163
193
52.64
76.79
52.85
76.98
52.95
77.74
52.71
77.65
52.97
77.56
52.81
77.82
53.04
77.36
52.97
77.16
53.03
76.71
53.35
76.84
53.93
76.76
Cuadro 7.17: Tiempo de descifrado con curvas sobre 2 en PC (configuracin M2)
Figura 7.19: Tiempo de descifrado con curvas sobre 2 en PC (configuracin M2)
302
16
32
48
64
80
96
112
128
144
160
176
Longitud del cuerpo

113
131
197.74
203.12
198.83
204.34
208.54
213.66
215.00
220.45
215.61
220.65
216.64
221.94
225.60
230.63
232.63
237.81
233.31
238.58
234.46
239.58
244.41
249.53
finito 2 (bits)
163
193
212.04
222.08
213.33
223.20
222.49
232.61
229.37
239.37
229.50
239.59
230.89
241.15
239.70
249.49
246.80
256.74
247.46
257.38
248.60
258.62
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
16
32
48
64
80
96
112
128
144
160
176
Longitud del cuerpo

113
131
223.78
228.21
239.00
243.50
257.95
262.37
273.21
277.62
288.56
292.12
304.13
308.53
323.23
327.38
338.22
342.64
353.64
358.06
368.92
373.29
387.98
392.21
303
finito 2 (bits)
163
193
236.18
245.19
251.47
260.57
270.15
279.39
285.54
294.63
300.84
310.06
316.22
325.14
335.59
344.07
350.69
359.56
366.12
374.88
381.45
390.04
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
304
16
32
48
64
80
96
112
128
144
160
176
112
24.99
25.79
25.73
25.80
25.82
25.66
25.69
25.97
25.66
25.95
25.93
Longitud
128
160
25.57 42.37
25.93 41.95
26.14 41.37
26.08 40.97
26.28 40.67
26.26 38.96
26.26 69.43
26.12 39.59
26.21 39.83
26.40 40.34
26.66 40.11
del cuerpo finito (bits)

192
224
256
384
56.10 76.80 82.63 144.21
57.06 76.97 82.83 144.59
56.43 76.84 82.67 144.26
55.51 76.67 82.60 144.10
55.49 74.30 82.90 145.54
55.36 74.54 82.99 148.35
55.34 74.72 82.31 148.89
56.15 74.13 84.72 148.56
56.05 74.19 84.95 148.72
55.96 74.34 84.25 148.32
56.07 74.42 85.41 149.38
521
230.38
231.94
229.00
228.36
227.93
228.80
227.63
227.62
228.39
230.85
228.95
Cuadro 7.20: Tiempo de descifrado con curvas sobre en PC (configuracin P1)
Figura 7.22: Tiempo de descifrado con curvas sobre en PC (configuracin P1)
16
32
48
64
80
96
112
128
144
160
176

128
160
26.78
39.02
26.15
39.11
26.07
38.93
26.11
39.07
25.86
40.28
26.06
40.06
27.09
40.12
25.97
40.35
26.22
40.63
26.52
39.67
25.90
40.12
305
(bits)
192
56.08
56.36
56.16
56.34
56.49
55.56
56.19
57.34
56.87
56.91
57.22
306
16
32
48
64
80
96
112
128
144
160
176

128
160
213.84
219.32
215.38
220.76
222.53
227.80
229.85
234.73
230.25
235.90
232.01
237.65
238.41
243.87
246.35
251.39
247.43
252.50
249.00
254.06
256.57
261.46
(bits)
192
233.71
234.92
242.35
249.42
250.15
251.97
258.24
266.07
266.63
268.55
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
7.5.5.
307
Tiempo de descifrado en PC y Java Card con la configuracin P3
La configuracin 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
versin 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.
16
32
48
64
80
96
112
128
144
160

128
160
27.25
41.29
26.5
41.35
28.44
41.01
26.21
40.37
27.03
40.33
26.55
40.26
26.9
40.25
26.18
40.2
26.34
39.85
27.09
40.78
(bits)
192
56.05
56.83
57.18
56.97
57.04
57.16
57.4
58.21
58.85
58.73
16
32
48
64
80
96
112
128
144
160

128
160
237.17
243.94
239.39
246.01
253.16
259.39
260.92
267.00
261.53
267.43
264.34
269.79
276.72
282.42
284.84
290.01
285.52
291.41
287.92
293.33
(bits)
192
258.30
260.24
273.56
280.97
282.28
284.02
296.59
304.60
305.52
307.45
Cuadro 7.24: Tiempo de descifrado con curvas sobre en JCOP J3A e interfaz sin
308
Figura 7.26: Tiempo de descifrado con curvas sobre en JCOP J3A e interfaz sin
7.6. Rendimiento comparado
7.6.
309
Rendimiento comparado
El objetivo de este apartado es presentar algunas comparaciones de especial inters, 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 implementacin, 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 versin de ECIES para PC.
Figura 7.27: Comparacin del tiempo de ejecucin en PC (configuraciones M1 y P1)
A continuacin se presenta una comparativa del tiempo medio de cifrado y descifrado (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 (Figura 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 grfico 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 comparacin del tiempo de cifrado y descifrado empleado por las tarjetas JCOP 41 (con la configuracin M2) y JCOP J3A (con la
configuracin P2) al gestionar un mensaje en claro de 64 bytes. De manera similar,
la Figura 7.32 muestra la misma comparacin utilizando un mensaje de 160 bytes.
310
Figura 7.28: Comparacin del tiempo de ejecucin entre las versiones PC y Java Card
(configuracin M2)
(configuracin P2)
7.6. Rendimiento comparado
311
(configuracin 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 informacin tcnica de
estas tarjetas por tratarse de datos confidenciales (descripcin del sistema operativo
JCOP, detalles de la implementacin de las operaciones aritmticas 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 interesante con el fin de obtener una aproximacin del rendimiento comparado de
ambas tarjetas.
312
Figura 7.31: Comparacin del tiempo de ejecucin en las tarjetas JCOP 41 (configuracin M2) y JCOP J3A (configuracin P2) al cifrar un mensaje de 64 bytes
Figura 7.32: Comparacin del tiempo de ejecucin en JCOP 41 (configuracin M2) y

JCOP J3A (configuracin P2) al cifrar un mensaje de 160 bytes
Captulo 8
Conclusiones, aportaciones y trabajo
futuro
Resumen del captulo

Este captulo presenta las conclusiones derivadas del estudio e implementacin 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 artculos y presentaciones en congresos
como de soluciones ideadas para evitar las distintas limitaciones detectadas. Por ltimo, se incluyen las posibles lneas de trabajo que podran
seguirse como continuacin de esta Tesis.
8.1.
Conclusiones
Tal como se ha comentado en diversos apartados, ECIES es un esquema de cifrado que dispone de mltiples opciones de implementacin. 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 configuraciones 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 estn
agrupadas en funcin de los objetivos descritos en la Introduccin.
313
314
8.1.1.
El esquema ECIES como estndar
A continuacin se detallan las conclusiones a las que ha sido posible llegar respecto a la consideracin del esquema ECIES como estndar:
1. El esquema de cifrado y descifrado ECIES se encuentra especificado en los
estndares ANSI X9.63 [16], IEEE 1363a [109], ISO/IEC 18033-2 [136] y SECG
SEC 1 [254]. Las caractersticas concretas de cada una de dichas versiones estn
descritas en 4.4 y 4.5.
Aunque las implementaciones de los cuatro estndares 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 permitidas en cada estndar, as como en las caractersticas particulares (p. ej.,
el uso de parmetros opcionales, la interpretacin de algunos elementos, etc.)
incluidas en esas versiones de ECIES.
2. A partir de las caractersticas particulares de cada estndar, hemos construido
11 configuraciones genricas (es decir, independientes de las funciones HASH,
KA, KDF, ENC y MAC especficas utilizadas), de manera que cada una de
ellas sea vlida al menos en un estndar. Dichas configuraciones se encuentran
descritas en 4.7.
3. De la revisin de las 11 configuraciones y de su aplicabilidad a cada estndar, se
puede afirmar que existen dos configuraciones (C01 y C02) compatibles con las
ltimas versiones de los cuatro estndares mencionados. Dichas configuraciones
tienen como elemento caracterstico la utilizacin de la funcin XOR como
algoritmo de cifrado simtrico.
Como consecuencia de la existencia de esas configuraciones y de al menos una
funcin especfica permitida de forma comn 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 estndares analizados.
8.1.2.
Conjunto de parmetros compatibles con todos los estndares
En relacin al conjunto de parmetros compatibles con todos los estndares se

pueden realizar las siguientes conclusiones:
1. Existen dos configuraciones genricas de ECIES compatibles con los cuatro
estndares analizados, denominadas C01 y C02, y descritas en 4.7.
8.1. Conclusiones
315
2. Dichas versiones compatibles tienen como elemento caracterstico la utilizacin

de la funcin XOR como algoritmo de cifrado simtrico. Las diferencias entre
ambas configuraciones residen en la funcin HASH empleada, la funcin MAC,
el uso de parmetros opcionales en la funcin MAC, o una combinacin de los
tres elementos citados.
3. A modo de ejemplo, se ha desarrollado una versin concreta compatible con
los cuatro estndares utilizando una seleccin especfica de funciones HASH,
KA, KDF, ENC y MAC de entre las mostradas en el Cuadro 4.10. La versin
as construida, denominada ECIES-4, constituye el Algoritmo 4.16.
Sin embargo, es importante resaltar que la utilizacin de la funcin XOR como
algoritmo de cifrado simtrico provoca determinados problemas de seguridad
que, si se implementan las medidas necesarias para evitarlos y que permiten
mantener la compatibilidad con los cuatro estndares, limitan la utilizacin del
esquema ECIES, tal como se detall en 4.9. Puesto que no existen ms configuraciones compatibles con los cuatro estndares, la mejor solucin consiste
en utilizar una de las dos configuraciones compatibles con los tres estndares
ms recientes (C05 y C06), y que permiten desarrollar implementaciones de
ECIES ms seguras y flexibles en cuanto a su funcionalidad.
8.1.3.
Desarrollo de la implementacin de ECIES para PC
Las conclusiones que se derivan del desarrollo de la implementacin de ECIES

para plataformas PC son las siguientes:
1. El lenguaje de programacin Java, uno de los ms extendidos actualmente,
permite la implementacin de todas las funciones de la criptografa de curvas elpticas sin necesidad de utilizar bibliotecas (libraries) adicionales. Como
ejemplo de ello, existen diversas bibliotecas criptogrficas, analizadas en 3.3,
que incluyen funcionalidades de la ECC desarrolladas por empresas o grupos
de programadores, siendo los ejemplos ms 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 parmetros presentes en
los estndares analizados. Debido a ello el autor de esta Tesis decidi desarrollar la versin de ECIES para PC implementando todas las clases necesarias
para utilizar los algoritmos relacionados con la ECC y las operaciones aritmticas, tanto para los puntos de las curvas elpticas como para los elementos de
los cuerpos finitos.
Esta opcin ha permitido un grado de flexibilidad superior, al ser posible incorporar cualquier algoritmo durante el propio desarrollo, aunque ha requerido
316

un tiempo de desarrollo superior al de otras alternativas. El diagrama de clases
de la aplicacin puede consultarse en 5.2, mientras que la descripcin funcional
de la aplicacin completa se encuentra en 5.3. Para mejorar la comprensin
del proceso de cifrado y descifrado, se ha incluido en 6.8 un ejemplo de cada
tipo de operacin utilizando la aplicacin desarrollada.
3. En cuanto a los algoritmos y caractersticas de ECIES incluidas en el desarrollo

para PC, puesto que el objetivo principal de esa versin de ECIES consiste en
poder realizar pruebas con distintas combinaciones de funciones y parmetros,
adems de las combinaciones M1, M2, P1, P2 y P3 (definidas en 7.2), se
decidi incluir las funciones HASH, KA, KDF, ENC y MAC ms habituales
en los estndares analizados, as como las opciones que permiten diferenciar
las configuraciones descritas en 4.7.
8.1.4.
Estudio de la eficiencia de la implementacin PC
A continuacin 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 aadida 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 tamao sea menor de 500 bytes, y especialmente cuando la longitud es menor de 64 bytes, el factor de expansin (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 tamao.
2. Dada una determinada curva, el tiempo de cifrado y descifrado es prcticamente 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 vara 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
8.1. Conclusiones
317
realizadas con puntos de la curva y elementos de los cuerpos finitos respecto

a las operaciones de cifrado simtrico.
4. El tiempo de cifrado y descifrado en la versin de ECIES para PC aumenta de

manera ms rpida que la longitud de las claves, tal como puede apreciarse en
los Cuadros 8.1 y 8.2, donde la interpretacin de las columnas es la siguiente:
Long. 2 y Long. representan la longitud en bits de las curvas de trabajo definidas sobre cuerpos finitos binarios y primos, respectivamente; Ratio 1
indica la relacin 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 longitudes 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 funcin 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 relacin 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
sect113r1
113
sect131r1
131
sect163r1
163
sect193r1
193
sect233r1
233
sect239k1
239
sect283r1
383
sect409r1
409
sect571r1
571
Ratio 1
1.00
1.16
1.44
1.71
2.06
2.11
3.39
3.62
5.05
Cifrado
28.34
36.26
59.67
82.53
102.31
105.54
129.96
225.53
368.50
Ratio 2
1.00
1.28
2.11
2.91
3.61
3.72
4.59
7.96
13.00
Descifrado Ratio 3
29.7
1.00
38.9
1.31
66.5
2.24
89.8
3.02
104.5
3.52
111.6
3.75
132.8
4.47
228.2
7.68
364.6
12.28
Cuadro 8.1: Crecimiento del tiempo de cifrado y descifrado en PC (configuracin M1)
5. La implementacin de la aritmtica de curvas definidas sobre cuerpos en

PC es ms eficiente que la implementacin sobre cuerpos 2 . Esto se debe a
la utilizacin de bases polinmicas en lugar de bases normales en la implementacin de las operaciones con cuerpos binarios. Las bases normales son ms
eficientes y permitiran obtener mejores resultados, pero su uso est restringido
por las patentes expuestas en 2.6.9.
318

Curva
Long.
secp112r1
112
secp128r1
128
secp160r1
160
secp192k1
192
secp224r1
224
secp256k1
256
secp384r1
384
secp521r1
521
Ratio 1
1.00
1.14
1.43
1.71
2.00
2.29
3.43
4.65
Cifrado Ratio 2
23.55
1.00
24.12
1.02
39.77
1.69
53.96
2.29
69.88
2.97
79.33
3.37
143.07
6.07
228.08
9.68
Descifrado
25.93
26.66
40.11
56.07
74.42
85.41
149.38
228.95
Ratio 3
1.00
1.03
1.55
2.16
2.87
3.29
5.76
8.83
Cuadro 8.2: Crecimiento del tiempo de cifrado y descifrado en PC (configuracin P1)
8.1.5.
Desarrollo de la implementacin 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 criptografa de curva elptica por parte de los grandes
fabricantes de tarjetas inteligentes (Gemalto, Oberthur, G&D, etc.) es todava
escaso.
2. En el mercado existe una amplia gama de tarjetas JCOP (desarrolladas inicialmente por IBM, y en la actualidad por NXP) compatibles con distintas
versiones de Java Card. De entre las tarjetas JCOP que implementan funcionalidades de la ECC, fueron seleccionados para su uso en esta Tesis los modelos
JCOP 41 y JCOP J3A, debido principalmente a su disponibilidad. Para dichas 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 ms fiables, sera deseable que los fabricantes 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 slo 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 longitudes sern paulatinamente ms importantes segn aumenten los requisitos de
seguridad de las aplicaciones con el paso del tiempo.
8.1. Conclusiones
319
5. A pesar de estar definida en las API de Java Card, la funcin HMAC no est
incluida en las tarjetas JCOP probadas. Aunque el desarrollo de la funcin
HMAC apropiada no ha sido complejo, el rendimiento global mejorara si
dicha funcin fuera ejecutada a travs de la llamada estndar al API Java
Card.
6. Igualmente sera deseable que el API Java Card aadiera en el futuro la funcin
KDF2, puesto que de hecho actualmente dicha API no incluye ninguna funcin
KDF.
7. De manera equivalente sera recomendable que las tarjetas comerciales incorporaran en el futuro prximo las modalidades con relleno del algoritmo AES
definidas en Java Card 3.0, lo que evitara la codificacin de sistemas alternativos de relleno por parte de las aplicaciones que se comunican con la tarjeta
inteligente.
8.1.6.
Estudio de la eficiencia de la implementacin Java Card
La siguiente lista recoge las conclusiones obtenidas gracias a las pruebas realizadas en tarjetas JCOP 41 con la configuracin M2 y en tarjetas JCOP J3A con las
configuraciones P2 y P3.
1. Los tiempos de cifrado y descifrado incluyen tanto el tiempo de transmisin
(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 envo de comandos mediante dos interfaces (con contactos y sin contactos) presentan un rendimiento diferente
en funcin de la interfaz empleada. Aunque la falta de detalles tcnicos sobre
las tarjetas slo permiten realizar suposiciones sobre este hecho, el motivo ms
probable podra ser la diferente frecuencia de la seal externa de reloj utilizada
en ambas interfaces (4.8 MHz frente a 13.56 MHz), lo que genera que la utilizacin de la interfaz sin contactos ofrezca mejores resultados en las pruebas
de cifrado y descifrado.
3. Adems de las diferencias respecto al tiempo de cifrado y descifrado, la utilizacin 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 prcticamente lineal, mientras
que en la interfaz sin contactos el aumento del tiempo de cifrado se produce
por escalones.
320

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 seal externa de reloj. Los tiempos de descifrado muestran el mismo comportamiento en estas
circunstancias (Figuras 7.20 y 7.21).
4. La sobrecarga aadida 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 transmisin 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 incrementar 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
relacin 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 funcin del cuadro); la columna Descifrado contiene el tiempo de descifrado para cada curva medido en
milisegundos; finalmente Ratio 3 muestra la relacin entre el tiempo de descifrado 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).
Curva
Long. 2
sect113r1
113
sect131r1
131
c2pnb163v1
163
sect193r1
193
Ratio 1
1.00
1.16
1.44
1.70
Cifrado Ratio 2
341.52
1.00
358.64
1.05
384.40
1.13
418.98
1.23
Descifrado
244.41
249.53
258.53
267.34
Ratio 3
1.00
1.02
1.06
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 versin para PC,

donde el tiempo de cifrado y descifrado aumenta ms rpidamente que la longitud de las curvas empleadas. Una posible explicacin de este resultado lo
constituye la utilizacin del criptoprocesador de clave pblica en las tarjetas
JCOP, lo que permite que la diferencia en rendimiento entre operaciones realizadas con una u otra curva sea en proporcin ms pequea que la medida al
8.1. Conclusiones
Curva
Long. 2
sect113r1
113
sect131r1
131
c2pnb163v1
163
sect193r1
193
321
Ratio 1
1.00
1.16
1.44
1.70
Cifrado Ratio 2
528.36
1.00
548.35
1.04
571.23
1.08
640.54
1.21
Descifrado
387.98
392.21
400.50
408.76
Ratio 3
1.00
1.01
1.03
1.05
Cuadro 8.4: Crecimiento del tiempo de cifrado y descifrado en JCOP 41 e interfaz con
Curva
Long.
secp128r1
128
secp160r1
160
P-192
192
Ratio 1
1.00
1.25
1.5
Cifrado
529.22
561.74
636.95
Ratio 2
1.00
1.06
1.20
Descifrado Ratio 3
256.57
1.00
261.46
1.02
275.85
1.08
Cuadro 8.5: Crecimiento del tiempo de cifrado y descifrado en JCOP J3A e interfaz
sin contactos (configuracin P2)
utilizar directamente la CPU del PC (aunque el rendimiento global del criptoprocesador de la tarjeta inteligente sea peor que el de la CPU). Es decir, el
criptoprocesador de las tarjetas JCOP, a pesar de las limitaciones tecnolgicas propias de arquitecturas de 8 bits, comparativamente est ms optimizado
para la aritmtica 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 podra deberse, a falta de ms datos sobre el funcionamiento de las tarjetas y sus coprocesadores, a que en la operacin de cifrado se
ejecuta un paso adicional relacionado con la aritmtica de puntos de la curva
y elementos del cuerpo finito (la generacin 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
Curva
Long.
secp128r1
128
secp160r1
160
P-192
192
Ratio 1
1.00
1.25
1.5
Cifrado
560.78
591.69
668.73
Ratio 2
1.00
1.06
1.19
Descifrado Ratio 3
287.92
1.00
293.33
1.02
307.45
1.07
Cuadro 8.6: Crecimiento del tiempo de cifrado y descifrado en JCOP J3A e interfaz
sin contactos (configuracin P3)
322

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 razn para este hecho la menor optimizacin del proceso de generacin
del par de claves aleatorias en respecto a 2 .
8. Debido a la naturaleza de la comunicacin mediante comandos APDU entre

una aplicacin externa y una tarjeta inteligente, y a las caractersticas criptogrficas implementadas en las tarjetas JCOP analizadas, si se desea que la
respuesta a una peticin de cifrado o descifrado est contenida en una nica
APDU de respuesta, es necesario limitar la longitud mxima de los mensajes
en claro a 176 bytes en el caso de las configuraciones M2 y P2, y 160 bytes para
la configuracin P3. La diferencia se debe a que la configuracin P3 genera un
cdigo MAC de 32 bytes, mientras que el cdigo generado en las implementaciones P2 y M2 es de 20 bytes. Esta longitud podra extenderse en el caso de
que las tarjetas JCOP permitieran representar los puntos de una curva elptica
de forma comprimida.
9. La utilizacin de mensajes en claro de longitudes mayores a las expuestas en el
punto anterior provocara un deterioro del rendimiento de la implementacin.
Por una parte, sera necesario intercambiar varias APDU para poder recuperar
la totalidad del criptograma (o del mensaje en claro en la operacin de descifrado). 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 utilizacin
de mensajes de excesivo tamao provocara que las variables tuvieran que ser
almacenadas en memoria EEPROM en lugar de en memoria RAM, siendo la
memoria EEPROM notablemente ms lenta que la memoria RAM.
Como ejemplo de esta afirmacin, la primera implementacin de la versin
JCOP-M2, que guardaba todas las variables en memoria EEPROM en lugar
de en memoria RAM, ofreca 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 versin final de la configuracin M2 que almacena todas las variables en memoria RAM. En esta ltima versin, la cantidad
de memoria RAM libre tras la asignacin de todas las variables es de 16 bytes, 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 puede afirmar que en la mayora de los casos de cifrado, el incremente relativo
al pasar de un mensaje de 16 bytes a otro de 160 bytes es de aproximadamente el 10 %, tal como puede observarse en los Cuadros 8.7 y 8.8 (relativos
8.1. Conclusiones
323
Curva
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 excepcin
a esta afirmacin la consitutuyen las pruebas realizadas con tarjetas JCOP 41
empleando la interfaz con contactos, donde el incremento es mucho mayor.
sect113r1
sect131r1
c2pnb163v1
sect193r1
Cif. 16
296.74
314.65
332.71
367.64
Cif. 160
331.82
350.70
368.74
403.70
Ratio 1
1.12
1.11
1.11
1.10
Descif. 16
197.74
203.12
212.04
222.08
Descif. 160
234.46
239.58
248.60
258.62
Ratio 2
1.20
1.18
1.17
1.16
Curva
Cuadro 8.7: Incremento relativo del tiempo de ejecucin en JCOP 41 e interfaz sin
sect113r1
sect131r1
c2pnb163v1
sect193r1
Cif. 16
363.51
384.52
407.35
446.56
Cif. 160
509.34
529.41
552.31
591.55
Ratio 1
1.40
1.38
1.35
1.32
Descif. 16
223.78
228.21
236.18
245.19
Descif. 160
368.92
373.29
381.45
390.04
Ratio 2
1.65
1.64
1.62
1.59
Curva
Cuadro 8.8: Incremento relativo del tiempo de ejecucin en JCOP 41 e interfaz con
secp128r1
secp160r1
P-192
Cif. 16
481.55
518.24
587.76
Cif. 160
522.50
554.08
623.73
Ratio 1
1.08
1.07
1.06
Des. 16
213.84
219.32
233.71
Des. 160
249.00
254.06
268.55
Ratio 2
1.16
1.16
1.15
Cuadro 8.9: Incremento relativo del tiempo de ejecucin en JCOP J3A e interfaz sin
Respecto al proceso de descifrado es posible hacer una afirmacin equivalente,

ya que el incremento en la mayora de los casos es aproximadamente del 20 %,
con la excepcin 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 criptografa de curvas elpticas en tarjetas sin coprocesador PKI, no ha sido posible determinar el rendimiento de las aplicaciones sin utilizar dicho criptoprocesador. Sin embargo,
debido a la naturaleza de las operaciones a realizar (multiplicacin escalar de
Curva
324
secp128r1
secp160r1
P-192
Cif. 16
512.54
543.31
613.50
Cif. 160
560.78
591.69
668.73
Ratio 1
1.09
1.09
1.09
Descif. 16
237.17
243.94
253.16
Descif. 160
287.92
293.33
307.46
Ratio 2
1.21
1.20
1.21
Cuadro 8.10: Incremento relativo del tiempo de ejecucin en JCOP J3A e interfaz sin
un punto de la curva, generacin pseudoaleatoria de un punto de la curva,

etc.), es razonable suponer que el rendimiento sin coprocesador se degradara
de manera muy marcada. La falta de tarjetas inteligentes con soporte ECC
pero sin criptoprocesador PKI podra ser un argumento ms a favor de esta
suposicin.
8.1.7.
Comparativa entre las versiones PC y Java Card
A continuacin se resumen las conclusiones derivadas de la comparacin entre

las implementaciones de ECIES para PC y Java Card:
1. Como era de esperar, el rendimiento de la implementacin en tarjetas Java
Card con un procesador de 8 bits, coprocesador criptogrfico y memoria RAM
limitada es sensiblemente inferior al de la versin para PC, que ha sido ejecutada en un equipo con procesador de 32 bits y una cantidad de memoria
ampliamente superior a la requerida por la aplicacin.
2. Dada la decisin de realizar pruebas con mensajes con una longitud mxima
de 176 bytes (160 bytes en las pruebas con las tarjetas JCOP J3A y la configuracin P3), al no existir dicha limitacin para la version PC, el nmero de
pruebas en las que es posible establecer una comparacin entre las versiones
PC y Java Card es pequeo comparado con el nmero de pruebas realizadas
en la versin PC.
3. Mientras que el tiempo de cifrado y descifrado es prcticamente el mismo en
la versin 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.
Configuracin 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 estndares son susceptibles de sufrir ataques debido a la utilizacin de la funcin XOR como
algoritmo de cifrado simtrico.
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 estndares 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 solucin compatible con todos los estndares la funcionalidad de ECIES queda seriamente limitada, se hace necesario seleccionar
otra configuracin como punto de partida para cualquier implementacin segura de ECIES. Dado que exceptuando C01 y C02 no existen ms configuraciones
compatibles con los cuatro estndares, las candidatas lgicas son aquellas configuraciones recogidas en los tres estndares ms 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 mltiples versiones compatibles con dichas configuraciones, y que se diferencien en la funcin HASH, la funcin MAC, el uso
de argumentos opcionales en la funcin de autenticacin o una combinacin
de esos tres elementos.
4. El Algoritmo 4.17 define una versin del esquema de cifrado, denominada
ECIES-3, que constituye una de las posibles 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 el algoritmo
de cifrado AES en modo CBC con relleno PKCS#5 y claves de 256 bytes,
la funcin resumen SHA-256, la funcin de derivacin de claves KDF2 y la
funcin de autenticacin HMAC-SHA-256.
8.2.
Aportaciones
La presente Tesis doctoral incluye la especificacin y desarrollo de una implementacin software de ECIES, para lo cual se ha creado una versin utilizando Java
SE para entornos PC, y otra versin (con tres variantes) para tarjetas Java Card.
Hasta donde el autor de esta Tesis conoce, se trata de la primera implementacin
del protocolo ECIES en ambas plataformas, permitiendo adems en la versin para
PC la seleccin de manera dinmica de la configuracin especfica a utilizar por el
usuario.
Como era predecible, durante el desarrollo el autor ha encontrado diversas dificultades y obstculos. En primer lugar, los estndares que incluyen ECIES como
algoritmo de cifrado presentan un nmero de opciones muy elevado, estando en
326
algunos casos dichas opciones desaconsejadas en estndares posteriores debido al

descubrimiento de alguna vulnerabilidad. Ello ha provocado que la tarea de comparacin y seleccin de las opciones a implementar haya sido especialmente laboriosa
en comparacin con la implementacin de otros estndares criptogrficos.
El segundo obstculo digno de mencin ha sido la enorme dificultad para conseguir tarjetas Java Card que implementen criptografa de curva elptica. Ninguno de
los principales fabricantes de tarjetas (Gemalto, Oberthur, G&D, etc.) disponan de
productos comerciales que incluyeran primitivas para trabajar con ECC en el momento 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 obtencin de dichas tarjetas no fue sencilla.
Debido a la compra de la lnea 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
aos, debido a limitaciones comerciales las tiendas de electrnica de internet slo
pueden comercializar las tarjetas JCOP originales de IBM, como por ejemplo el
modelo JCOP 41 utilizado en esta Tesis y que tiene implementada la versin 2.2.1
del sistema operativo JCOP. Aunque esta tarjeta implementa funciones ECC sobre
cuerpos binarios, al tratarse de tarjetas con casi 7 aos de antigedad no disponan
de otros algoritmos como AES o SHA-256.
Gracias a la colaboracin con NXP, fue posible acceder a las nuevas tarjetas
J3A con sistema operativo JCOP v2.4.1. Estas tarjetas, adems de los algoritmos
mencionados, implementan las funciones ECC sobre cuerpos finitos primos, por lo
que gracias a este producto ha sido posible realizar una comparacin ms 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 permitido dar a conocer parte de la investigacin mediante presentaciones en congresos
y artculos 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]: presentacin
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 criptografa de curva elptica
[82]: presentacin en el I Simposio sobre Seguridad Informtica dentro del I
Congreso Espaol de Informtica (CEDI) celebrado en Granada en septiembre
de 2005, junto con la publicacin en las actas del congreso.
Sobre la clasificacin de curvas hiperelpticas de gnero 2 definidas en cuerpos
finitos [102]: publicacin en las actas del I Simposio sobre Seguridad Infor-
8.3. Trabajo futuro
327
mtica dentro del I Congreso Espaol de Informtica (CEDI) celebrado en

Granada en septiembre de 2005.
Elliptic Curve Cryptography. Java platform implementations [83]: presentacin
en la 23rd International Conference for Automation of Engineering and Research (SAER-2009) - International Conference on Information Technologies
(InfoTech-2009) celebrado en Varna (Bulgaria) en septiembre de 2009, junto
con la publicacin en las actas del congreso. Este mismo artculo fue publicado posteriormente en el nmero 4 del International Journal on Information
Techonologies & Security [84].
A Java implementation of the Elliptic Curve Integrated Encryption Scheme
[85]: presentacin en el 2010 International Conference on Security & Management (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]: publicacin 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 (nmero 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 publicacin en la revista
Journal of Systems and Software (actualmente en estado de revisin).
Performance evaluation of the Elliptic Curve Integrated Encryption Scheme
implemented in PC and Java Card [88]: enviado para su publicacin en la
revista Computers & Mathematics with Applications (actualmente en estado
de revisin).
Java Card implementation of the Elliptic Curve Integrated Encryption Scheme
using prime and binary finite fields [89]: enviado para su publicacin en la
revista International Journal of Information Security (actualmente en estado
de revisin).
8.3.
Trabajo futuro
El trabajo efectuado en esta Tesis sugiere la posibilidad de continuar algunas

de las lneas de investigacin desarrolladas e incluso iniciar otras nuevas asociadas
a aspectos que, aunque estn situados fuera de los objetivos de la presente Tesis, se
encuentran relacionados con los temas tratados.
328
Respecto a la implementacin en PC de ECIES, las operaciones aritmticas

de los cuerpos y 2 podran optimizarse a fin de aumentar la velocidad de
las operaciones de cifrado y descifrado. En concreto, una posible mejora consistira en utilizar coordenadas homogneas y mixtas en lugar de nicamente
coordenadas afines en las operaciones relacionadas con los puntos de una curva
elptica, puesto que dependiendo de la operacin (suma de puntos, multiplicacin de un punto por un escalar, etc.) cada tipo de coordenadas requiere un
esfuerzo computacional diferente, siendo necesario analizar qu combinacin
de tipos de coordenadas sera ms eficiente para las operaciones de cifrado y
descifrado.
Una funcionalidad que se podra aadir a la implementacin en PC (no as a
la implementacin en tarjetas inteligentes, por los requisitos de procesamiento
necesarios) consiste en la implementacin de los algoritmos incluidos en los
estndares para la generacin aleatoria de curvas elpticas, as como la funcin
necesaria para contar los puntos de una curva elptica, incluyendo las opciones
pertinentes en la interfaz del programa para que un usuario pudiera generar
aleatoriamente una curva en funcin de los parmetros introducidos por dicho
usuario (tamao del cuerpo finito, tipo de curva, etc.) y posteriormente obtener
el cardinal de dicha curva. Sera 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 desarrollados estn optimizados para el cifrado y descifrado de mensajes cuya longitud
est limitada a una nica APDU. Puesto que una aplicacin comercial de
ECIES podra requerir el cifrado y descifrado de datos de mayor longitud, sera necesario redisear los applets con el objetivo de que pudieran gestionar
volmenes de datos mayores sin que su rendimiento se viera penalizado, para
lo que es imprescindible incrementar la reutilizacin de las variables de manera 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 elpticas, ECDSA, se
encuentra ms extendido que el protocolo de cifrado, ECIES, su implementacin 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 estndares, es decir, las firmas delegadas [162, 273], mltiples
[160, 242] o en nombre de un grupo [19, 20]. Una nueva lnea de investigacin
consistira en comprobar la viabilidad, y en su caso realizar la implementacin,
de dichos esquemas no estndares de firma en tarjetas inteligentes.
Igualmente interesante sera 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 lser, de

implantacin inica, etc.).
Por ltimo, en funcin de la disponibilidad en el mercado de otras tarjetas Java
Card que implementen funciones ECC, sera recomendable comparar el rendimiento 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.
Notacin
0x
Prefijo que identifica las cadenas binarias hexadecimales
A2 ()
Plano afn sobre el cuerpo
Elemento del cuerpo que define la curva
Elementos del cuerpo que define la curva
Mensaje cifrado
Criptograma
Discriminante de una curva elptica
Diferencia entre la longitud del criptograma y el mensaje en claro usando la configuracin C
Curva elptica
()
Curva elptica definida sobre el cuerpo
EK
Clave de cifrado
Cuerpo finito, equivalente a
Cuerpo finito primo
Cuerpo finito binario
()
Polinomio irreducible de grado que define la base polinmica de 2
Punto de la curva que acta como generador
Gnero de una curva algebraica
Cofactor de la curva
Primer exponente del polinomio reductor ()

331
332
Notacin
Segundo exponente del polinomio reductor ()
Tercer exponente del polinomio reductor ()
Nmero entero que especifica el cuerpo finito 2
Mensaje en claro sin cifrar
MK
Clave MAC
Nmero primo que representa el orden del punto
Punto en el infinito
P2 ()
Plano proyectivo sobre el cuerpo
Representacin binaria del punto
Punto de la curva con coordenadas expresadas indistintamente como

( , ) o ( , )
Nmero primo que especifica el cuerpo finito
Nmero de elementos del cuerpo
Primera coordenada del punto , equivalente a
Segunda coordenada del punto , equivalente a
Conjunto de parmetros que caracterizan la curva
Clave privada del usuario U
Clave pblica del usuario U
Usuario que enva el criptograma
Clave privada del usuario V
Clave pblica del usuario V
Usuario que recibe el criptograma
Funcin 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 fr Sicherheit in der Informationstechnik (Federal Office 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
Gnus Not Unix
GPL
General Public Licence
GSM
Global System for Mobile Communications
HMAC
Hashed Message Authentication Code
IAIK
Institut fr Angewandte Informationsverarbeitung und Kommunikationstechnologie (Institute for Applied Information Processing 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 (Release 6). TS 31.102. 2008.
[5] 3RD GENERATION PARTNERSHIP PROJECT (3GPP). Universal Subscriber 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. Contribucin 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. 143158. 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 scheme based on the Diffie-Hellman problem. Indito, 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 bibliogrficas. Contenido, forma y estructura. UNE 50104-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. Pgina 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 transport 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 finantial 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 platforms - 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.
255270. 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. 246268.
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. Pgina 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. 2968. ISSN
0025-5718.
http://dx.doi.org/10.1090/S0025-5718-1993-1199989-X
[24] BACH, E. y SHALLIT, J. Algorithmic number theory. Cambridge (Massachusetts): MIT Press, 1996. ISBN 0-262-02405-5.
[25] BARRN VIDALES, J. Diseo e implementacin de un esquema de cifrado
hbrido basado en DHIES. Director: Debrup Chakraborty. Centro de Investigacin y de Estudios Avanzados del Instituto Politcnico Nacional, Mjico,
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. 116. 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 encryption schemes. Lecture Notes in Computer Science. 1998, vol. 1462, pp.
549570. 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. 4773. 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 Cryptography. 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. 203213.
ISSN 0002-9920.
http://www.ams.org/notices/199902/boneh.pdf
[32] BOUNCE CASTLE. The legion of the Bouncy Castle. Pgina web.
http://www.bouncycastle.org
[33] BRAINPOOL. ECC Brainpool. Pgina 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: SpringerVerlag, 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 FR 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 JIMNEZ, C.; DAZ MUOZ, R. y MEJAS OSORIO, P.

Algunas aplicaciones de las curvas elpticas a la criptografa. Director: Eric
Donders Orellana. Facultad de Ciencias Fsicas y Matemticas. Universidad
Central de Chile, 2007.
http://www.criptored.upm.es/descarga/EficienciaCCE_RSA.zip
[39] CARD CONTACT SOFTWARE. Open Smart Card Development Platform
(OpenSCDP). Pgina web.
http://www.openscdp.org
[40] CENTRO CRIPTOLGICO NACIONAL (CCN). Tecnologa de identificacin 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. Inventores: 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 invencin, 5.787.028. 199807-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
invencin, 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. Vanstone, A. J. Menezes, M. Qu. Fecha de solicitud: 1999-04-01. Estados Unidos,
patente de invencin, 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. Vanstone, R. C. Mullin, G. B. Agnew. Fecha de solicitud: 2000-09-06. Estados
Unidos, patente de invencin, 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. Vanstone, A. J. Menezes. Fecha de solicitud: 2001-08-29. Estados Unidos, patente
de invencin, 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. Inventores: S. A. Vanstone, R. Mullin, A. Antipa, R. Gallant. Fecha de solicitud:
2000-10-02. Estados Unidos, patente de invencin, 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 programmers guide. Boston: Addison-Wesley, 2000. ISBN 0-201-70329-7.
[49] COHEN, H. A course in computational algebraic number theory. Berln:
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. Indito, 1999.
http://www.math.mcgill.ca/connell/
[52] CONSEJO SUPERIOR DE INVESTIGACIONES CIENTFICAS. Procedimiento y dispositivo de encriptacin mediante un criptosistema tipo RSA. Inventores: L. Hernndez, J. Muoz, A. Queiruga. Fecha de solicitud: 2003-02-14.
Espaa, patente de invencin, 2.217.959. 2006-02-01.
http://dx.doi.org/10261/4968
[53] COPPERSMITH, D. et al. Low-exponent RSA with related messages. Lecture Notes in Computer Science. 1996, vol. 1070, pp. 19. ISBN 978-3-54061186-8.
http://dx.doi.org/10.1007/3-540-68339-9_1
[54] CORON, J. S. y MAY, A. Deterministic polynomial-time equivalence of computing the RSA secret key and factoring. Journal of Cryptology. Enero 2007,
vol. 20, num. 1, pp. 3950. 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 encryption schemes secure against adaptive chosen ciphertext attack. SIAM
Journal on Computing. Diciembre 2003, vol. 33, num. 1, pp. 167226. ISSN
0097-5397.
http://dx.doi.org/10.1137/S0097539702403773
Referencias
345
[56] CRYPTIX. The Cryptix project. Pgina 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/DOC/RHU/WP5/023/3. NESSIE Project, 2002.
https://www.cosic.esat.kuleuven.be/nessie/reports/phase2/
Evaluation.zip
[59] DETHLOFF, J. y GRTRUPP, H. Identification switch. Inventores: J. Dethloff, H. Grtrupp. Fecha de solicitud: 1969-09-15. Estados Unidos, patente de
invencin, 3.678.250. 1972-07-18.
http://www.google.com/patents/about?id=zjUvAAAAEBAJ&dq=3678250
[60] DETHLOFF, J. y GRTRUPP, H. Identification system. Inventores: J. Dethloff, H. Grtrupp. Fecha de solicitud: 1970-08-17. Estados Unidos, patente de
invencin, 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.
644654. ISSN 0018-9448.
http://dx.doi.org/10.1109/TIT.1976.1055638
[62] DINERS CLUB. Company history of Diners Club. Pgina 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. 7182. 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: Proceedings of the 23rd Annual Symposium on the Theory of Computing. Nueva
Orleans, 1991. pp 542552. 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] DURN DAZ, R.; HERNNDEZ ENCINAS, L. y MUOZ 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. Indito, 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. 469472. ISSN 0018-9448.
[70] ELKIES, N. Elliptic and modular curves over finite fields and related computational issues. En: Proceedings of Computational Perspectives on Number
Theory. Chicago, 1998. pp 2176. 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.
Indito, 2000.
http://www.tml.hut.fi/Research/TeSSA/Papers/Elo/Elo_Nordsec2000.
pdf
[72] ENGE, A. Elliptic curves and their applications to cryptography: An introduction. Boston: Kluwer Academic Publishers, 1999. ISBN 0-7923-8589-6.
[73] ERICKSON, M. y VAZZANA, A. Introduction to number theory. Boca Ratn
(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 tcnico TR102. European Committee for Banking Standards, 2003.
http://www.ecbs.org
[75] EUROPEAN TELECOMMUNICATION STANDARDS INSTITUTE (ETSI). Smart cards - UICC-terminal interface - Physical and logical characteristics . 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. 865874. ISSN 0025-5718.
http://dx.doi.org/10.1090/S0025-5718-1994-1218343-6
[77] FREY, G. Applications of arithmetical geometry to cryptographic constructions. En: Proceedings of the Fifth International Conference on Finite Fields
and Applications, pp 128161. Augsburg (Alemania), 2001. ISBN 3-540-411097.
http://www.iem.uni-due.de/zahlentheorie/preprints/nna1.ps
[78] FSTER SABATER, A.; et al. Tcnicas criptogrficas de proteccin de datos.
3a ed. Madrid: RA-MA, 2004. ISBN 84-7897-594-2.
[79] GALINDO, D.; MARTN, 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 1727. 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 technology. Boston: Kluwer Academic Publishers, 2004. ISBN 1-4020-7889-7.
[81] GAYOSO MARTNEZ, V. et al. Elliptic Curve Criptography: Java implementation issues. En: Proceedings of the 39th IEEE International Carnahan
Conference on Security Technology (ICCST 2005), pp 238241. Las Palmas
de Gran Canaria, 2005. ISBN 0-7803-9245-0.
http://dx.doi.org/10.1109/CCST.2005.1594866
[82] GAYOSO MARTNEZ, V. et al. Estado del arte de las implementaciones
Java de criptografa de curva elptica. En: Actas del I Simposio sobre Seguridad Informtica, I Congreso Espaol de Informtica (CEDI), pp. 127134.
Granada, 2005. ISBN: 84-9732-447-1.
[83] GAYOSO MARTNEZ, V.; HERNNDEZ ENCINAS, L. y SNCHEZ VILA, C. Elliptic Curve Cryptography. Java platform implementations. En:
Proceedigs of the 23rd International Conference on Information Technologies
(InfoTech-2009), pp. 2027. Varna (Bulgaria), 2009. ISBN: 978-954-438-771-6.
[84] GAYOSO MARTNEZ, V.; HERNNDEZ ENCINAS, L. y SNCHEZ VILA, C. Elliptic Curve Cryptography. Java platform implementations. International Journal on Information Techonologies & Security. Diciembre 2009,
num. 4, pp. 6572. ISSN: 1313-8251.
348
Referencias
[85] GAYOSO MARTNEZ, V.; HERNNDEZ ENCINAS, L. y SNCHEZ VILA, C. A Java implementation of the Elliptic Curve Integrated Encryption
Scheme. En: Proceedings of the 2010 International Conference on Security
& Management - SAM10, vol.n II, pp. 495501. Las Vegas, 2010. ISBN: 160132-162-7.
[86] GAYOSO MARTNEZ, V.; HERNNDEZ ENCINAS, L. y SNCHEZ VILA, 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. 14. Atlanta, 2010. ISBN: 978-1-4244-7408-0.
http://dx.doi.org/10.1109/ISIAS.2010.5604194
[87] GAYOSO MARTNEZ, V.; HERNNDEZ ENCINAS, L. y SNCHEZ VILA, C. Security and practical considerations when implementing the Elliptic
Curve Integrated Encryption Scheme. Enviado a: Journal of Systems and
Software. 2010. ISSN 0164-1212.
[88] GAYOSO MARTNEZ, V.; HERNNDEZ ENCINAS, L. y SNCHEZ VILA, C. Performance evaluation of the Elliptic Curve Integrated Encryption
Scheme implemented in PC and Java Card. Enviado a: Computers & Mathematics with Applications. 2010. ISSN 0898-1221.
[89] GAYOSO MARTNEZ, V.; HERNNDEZ ENCINAS, L. y SNCHEZ VILA, 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.
[90] GAYOSO MARTNEZ, V.; HERNNDEZ ENCINAS, L. y SNCHEZ VILA, C. A survey of the elliptic curve integrated encryption scheme. Journal
of Computer Science and Engineering. Agosto 2010, vol. 2, num. 2, pp. 713.
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. 1946. 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. 2932. 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. 365377. San Francisco, 1982. ISBN 0-89791-070-2.
http://dx.doi.org/10.1145/800070.802212
[94] GOLDWASSER, S. y MICALI, S. Probabilistic encryption. Journal of Computer and System Sciences. Abril 1984, vol. 28, num. 2, pp. 270299. 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. 316329. 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 Island): American Mathematical Society, 1989. ISBN 0-8218-4530-6.
[97] GUTHERY, S. B. y JURGENSEN, T. M. Smart card: Developers kit. Indianpolis (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 - ICDCSW02, pp. 272278. 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. Berln: 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. 336341. ISSN 00975397.
http://dx.doi.org/10.1137/0217019
[102] HERNNDEZ ENCINAS, L. et al. Sobre la clasificacin de curvas hiperelpticas de gnero 2 definidas en cuerpos finitos. En: Actas del I Simposio sobre
Seguridad Informtica, I Congreso Espaol de Informtica (CEDI), pp. 3136.
Granada, 2005. ISBN 84-9732-447-1.
350
Referencias
[103] HESS, E. et al. Information leakage attacks against smart card implementations of cryptographic algorithms and countermeasures - A survey. En:
Proceedings of the EUROSMART Security Conference, pp. 5564. 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 invencin, 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. Pgina 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: Physical 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 application providers. 2a ed. ISO/IEC 7816-5. 2004.
Identification cards Integrated circuit cards Part 6: Interindustry data elements for interchange. 2a ed. ISO/IEC 7816-6. 2004.
Identification cards Integrated circuit(s) cards with contacts Part 7: Interindustry 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: Electronic 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 application management in a multi-application environment. ISO/IEC 7816-13.
2007.
Identification cards Integrated circuit cards Part 15: Cryptographic information application. ISO/IEC 7816-15. 2004.
Information technology ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding 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 codes (MACs) Part 2: Mechanisms using a dedicated hash-function. ISO/IEC
9797-2. 2002.
Information technology Security techniques Hash-functions Part 2: Hashfunctions using an n-bit block cipher. 3a ed. ISO/IEC 10118-2. 2010.
Information technology Security techniques Hash-functions Part 3: Dedicated 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 144432. 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. Pgina 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 elpticas. Indito, 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 Mathematical Society. 2000, vol. 16, pp. 231260.
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. 115125.
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 Ratn
[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. 201206. ISBN 978-3-54064040-0.
[147] KOBLITZ, N. Elliptic curve cryptosystems. Mathematics of Computation.
Enero 1987, vol. 48, num. 177, pp. 203209. 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. Berln:
[149] KOBLITZ, N. Algebraic aspects of cryptography. Berln: 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. 104113. 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 Analysis and related attacks. Informe tcnico. 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. 388397. ISBN 978-3-54066347-8.
http://dx.doi.org/10.1007/3-540-48405-1_25
[153] KRANTZ, S. G. Handbook of typography for the mathematical sciences. Boca
Ratn (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 Engineering 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. 426442.
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. 225233. 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. 637646. 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 Mathematics. Noviembre 1987, vol. 126, num. 3, pp. 649673. 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. Indito, 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 - CCS96, pp. 4857. Nueva Delhi (India), 1996.
http://dx.doi.org/10.1145/238168.238185
[163] MAOSCO LTD. MULTOS smart card technology. Pgina web.
http://www.multos.com
[164] MASSACHUSETTS INSTITUTE OF TECHNOLOGY. Cryptographic communications system and method. Inventores: R. L. Rivest, A. Shamir y L. Adleman. Fecha de solicitud: 1977-12-14. Estados Unidos, patente de invencin,
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. Indito, 2000.

https://www.cosic.esat.kuleuven.be/nessie/workshop/submissions/
misty1.zip
[166] MATSUSHITA ELECTRIC INDUSTRIAL CO., LTD. Public key cryptosystem with an elliptic curve. Inventores: A. Miyaji, M. Tatebayashi. Fecha de
solicitud: 1992-05-26. Estados Unidos, patente de invencin, 5.272.755. 199312-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.
195213. 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 Academic Publishers, 1993. ISBN 0-79239-368-6.
[169] MENEZES, A. J. y VANSTONE, S. A. Vanstone. Elliptic curve cryptosystems and their implementation. Journal of Cryptology. Septiembre 1993, vol.
6, num. 4, pp. 209224. 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. 16391646. ISSN
0018-9448.
http://dx.doi.org/10.1109/18.259647
[171] MENEZES, A.; QU, M. y VANSTONE, S. Some new key agreement protocols providing implicit authentication. En: Proceedings of the Workshop on
Selected Areas in Cryptography - SAC 95, pp. 2232. 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. 308318.
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 Computer Science. 1986, vol. 218, pp. 417426. 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 electrnico. Pgina web.
http://www.dnielectronico.es/oficina_prensa/noticias/noticia12.
html
[177] MINISTERIO DEL INTERIOR. Pasaporte electrnico (pasaporte-e). Pgina
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 International Carnahan Conference on Security Technology (ICCST 2001), pp 213222.
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 Ratn (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. 179192. ISSN 0305-0041.
[181] MULDER, E. et al. Differential power and electromagnetic attacks on a FPGA implementation of elliptic curve cryptosystems. Computers and Electrical
Engineering. Septiembre 2007, vol. 33, num. 56, pp. 367382. ISSN 0045-7906.
http://dx.doi.org/10.1016/j.compeleceng.2007.05.009
[182] NAGELL, T. Sur les proprits arithmtiques des cubiques planes du premier
genre. Acta Mathematica. 1929, vol. 52, pp. 93126. 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 logarithm 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 cipher. Ver. 1.1. SP 800-67. 2008.
http://csrc.nist.gov/publications/nistpubs/800-67/SP800-67.pdf
Secure hashing - Approved algorithms. Pgina 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. Pgina 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-199912324 named New European Schemes for Signatures, Integrity, and Encryption. 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 authentication. Inventor: R. E. Crandall. Fecha de solicitud: 2000-04-06. Estados
Unidos, patente de invencin, 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. Massey, J. K. Omura. Fecha de solicitud: 1982-09-14. Estados Unidos, patente de
invencin, 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: 198209-14. Estados Unidos, patente de invencin, 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. Onyszchuk, R. C. Mullin, S. A. Vanstone. Fecha de solicitud: 1985-05-30. Estados
Unidos, patente de invencin, 4.745.568. 1988-05-17.
http://www.google.com/patents/about?id=OJc2AAAAEBAJ&dq=4745568
[209] ORACLE CORP. BigInteger (Java Platform SE 6). Pgina web.
http://download.oracle.com/javase/6/docs/api/java/math/
BigInteger.html
[210] ORACLE CORP. Java Card Technology. Pgina web.
http://www.oracle.com/technetwork/java/javacard/overview/index.
html
362
Referencias
[211] ORACLE CORP. Java smart card I/O API. Pgina web.
http://jcp.org/en/jsr/detail?id=268
[212] ORACLE CORP. Java technology. Pgina web.
http://java.com/en/about
[213] ORACLE CORP. OpenJDK. Pgina web.
http://openjdk.java.net
[214] ORACLE CORP. Oracle completes acquisition of Sun. Pgina web.
http://www.oracle.com/us/corporate/press/044428
[215] ORTEGA JUANCAS, S. Algunas aplicaciones de las curvas elpticas a la criptografa. Director: Juan Gabriel Tena Ayuso. Secretariado de Publicaciones e
Intercambio Cientfico de la Universidad de Valladolid, 1997.
http://dialnet.unirioja.es/servlet/tesis?codigo=11638
[216] PC/SC WORKGROUP. The PC/SC workgroup. Pgina web.
http://www.pcscworkgroup.com
[217] PREZ ORTIZ, J. A. Diccionario urgente de estilo cientfico del espaol. Indito, 1999.
http://www.dlsi.ua.es/~japerez/pub/pdf/duece1999.pdf
[218] PIETILINEN, H. Elliptic curve cryptography on smart cards. Director: Eljas 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. 644654. ISSN 00189448.
[220] POLLARD, J. M. Theorems on factorization and primality testing. Mathematical Proceedings of the Cambridge Philosophical Society. Noviembre 1974,
vol. 76, num. 3, pp. 521528. 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. 331334. 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. 918924.
http://dx.doi.org/10.1090/S0025-5718-1978-0491431-9
[223] QUISQUATER, J. The adolescence of smart cards. Future Generation Computer Systems. Julio 1997, vol. 13, num. 1, pp. 37. 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 encryption scheme and primitives. Informe tcnico 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 tcnico 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 (Inglaterra): John Wiley & Sons, 2003. ISBN 0-470-85668-8.
[227] RIEMANN, B. Theorie der Abelschen functionen. Journal fr die reine und
angewandte Mathematik. Enero 1857, num. 54, pp. 115155. 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: Birkhuser, 1994. ISBN 0-8176-3743-5.
[229] RIVEST, R. L.; SHAMIR, A. y ADLEMAN, L.. A method for obtaining digital signatures and public-key cryptosystems. Communications of the ACM.
Enero 1983, vol. 26, num. 1, pp. 9699.
http://dx.doi.org/10.1145/359340.359342
[230] ROCH, G. Ueber die anzahl der willkurlichen constanten in algebraischen
functionen. Journal fr die reine und angewandte Mathematik. Enero 1865,
num. 64, pp. 372376. 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 Laboratories 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 discrete log algorithm for anomalous elliptic curves. Commentarii Mathematici
Universitatis Sancti Pauli. Enero 1998, vol. 47, num. 1, pp. 8192.
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. 247270.
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.
483494.
http://dx.doi.org/10.1090/S0025-5718-1985-0777280-6
[239] SCHOOF, R. Counting points on elliptic curves over finite fields. Journal de
Thorie de Nombres de Bordeaux. 1995, vol. 7, pp. 219254.
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. 353356.
http://dx.doi.org/10.1090/S0025-5718-98-00887-4
[241] SHANKS, D. Class number, a theory of factorization, and genera. En: Proceedings of 1969 Number Theory Institute. Stony Brook (Nueva York), 1969.
pp 415440. 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. 14641473. 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. Indito, 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. 193196. ISSN
0933-2790.
http://dx.doi.org/10.1007/s001459900052
[248] SOCIT INTERNATIONALE POUR LINNOVATION. 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] SOCIT INTERNATIONALE POUR LINNOVATION. Data-transfer system. Inventor: R. Moreno. Fecha de solicitud: 1975-03-21. Estados Unidos,
http://www.google.com/patents/about?id=-6c1AAAAEBAJ&dq=4007355
[250] SOCIT INTERNATIONALE POUR LINNOVATION. 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 prctico de estilo. Barcelona: Urano, 1992. ISBN 84-7953020-0.
[252] SOURCEFORGE. OpenCard Framework. Pgina 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). Recommended 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 tcnico
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 Ratn (Florida): Chapman & Hall/CRC, 2006. ISBN 1-58488-508-4.
[258] SVENDA, P. Cryptographic algorithms re-implementation for JavaCard. Pgina web.
http://www.fi.muni.cz/~xsvenda/jcalgs.html
[259] TECHNISCHE UNIVERSITT DARMSTADT. FlexiProvider. Pgina web.
http://www.cdc.informatik.tu-darmstadt.de/flexiprovider/
[260] TECHNISCHE UNIVERSITT GRAZ. IAIK crypto toolkit. Pgina web.
http://jce.iaik.tugraz.at
[261] UJALDN MARTNEZ, M. Arquitectura del PC. Volumen I. Microprocesadores. Madrid: Ciencia 3 Distribucin, 2003. ISBN 978-84-95391-86-5.
[262] UNIVERSAL SMART CARDS. JCOP range (Java Card OS). Pgina web.
http://www.usmartcards.com/prod-jcop-range-java-card-os-10.php
[263] UNIVERSIDAD POLITCNICA DE MADRID. Cmo citar una bibliografa.
Pgina web.
http://www.upm.es/upm/biblioteca/citabibliografia.html
[264] WAGSTAFF, S. S. Jr. Cryptanalysis of number theoretic ciphers. Boca Ratn
Referencias
367
[265] WASHINGTON, L. C. Elliptic curves. Number theory and cryptography. 2a ed.

Boca Ratn (Florida): Chapman & Hall/CRC, 2008. ISBN 978-1-4200-7146-7.
[266] WEIL, A. Larithmtique sur les courbes algbriques. Acta Mathematica.
1929, vol. 52, pp. 281315. ISSN 0001-5962.
http://dx.doi.org/10.1007/BF02592688
[267] WIENER, M. J. Cryptoanalysis of short RSA secret exponents. IEEE Transactions on Information Theory. Mayo 1990, vol. 36, num. 3, pp. 553558.
ISSN 0018-9448.
http://dx.doi.org/10.1109/18.54902
[268] WIKIPEDIA. Java Card Open Platform. Pgina web.
http://en.wikipedia.org/wiki/Java_Card_OpenPlatform
[269] WILES, A. Modular elliptic curves and Fermats Last Theorem. Annals of
Mathematics. Mayo 1995, vol. 141, num. 3, pp. 443551. ISSN 0003-486X.
http://www.jstor.org/stable/2118559
[270] WILLIAMS, H. C. A modification of the RSA public key encryption procedure. IEEE Transactions on Information Theory. Noviembre 1980, vol. 26,
num. 6, pp. 726729. ISSN 0018-9448.
[271] WILLIAMS, H. C. A +1 method of factoring. Mathematics of Computation.
Julio 1982, vol. 39, num. 159, pp. 225234. ISSN 0025-5718.
http://dx.doi.org/10.1090/S0025-5718-1982-0658227-7
[272] WIRELESS APPLICATION PROTOCOL FORUM (WAP FORUM). Wireless 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. 282290. ISBN 978-3-540-64382-1.
368
Referencias

2O Implementacio N de Tarjetas Inteligentes Java Card

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

2O Implementacio N de Tarjetas Inteligentes Java Card

Încărcat de

Drepturi de autor:

Formate disponibile

Universidad Politcnica de Madrid

Escuela Tcnica Superior de Ingenieros de Telecomunicacin

Consejo Superior de Investigaciones Cientficas

Departamento de Matemtica Aplicada a las

Luis Hernndez Encinas

Realizado el acto de lectura y defensa de la Tesis el da

Para Laura y Blanca.

I do not have a name. You can call me V.

Reputation is what other people know about you.

1.1. Historia de las tarjetas inteligentes . . . . . . . . . . . . . . . . . . . 19

1.6.1. Tarjetas Java Card . . . . . . . . . . . . . . . . . . . . . . . . 36

2.5.2. Mecanismo de encapsulacin de datos DEM . . . . . . . . . . 69

2.6.6. Comprobacin de los parmetros de una curva elptica . . . . 90

3.1. Programacin orientada a objetos . . . . . . . . . . . . . . . . . . . . 99

4.1. Criptosistemas de curvas elpticas . . . . . . . . . . . . . . . . . . . . 129

4.3. Componentes funcionales de ECIES . . . . . . . . . . . . . . . . . . . 138

5.1. Diseo del esquema ECIES a implementar . . . . . . . . . . . . . . . 181

5.1.3. Aritmtica de puntos de la curva y de elementos del cuerpo

5.3.8. Men Cuerpo GF()/Cuerpo GF(2^m) . . . . . . . . . . . . . 214

5.3.11. Pestaa Cifrado . . . . . . . . . . . . . . . . . . . . . . . . . . 222

6.1. Elementos criptogrficos de ECIES disponibles en Java Card . . . . . 243

6.3.2. Herramientas de lnea de comandos de Sun . . . . . . . . . . . 247

7.1. Material utilizado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271

7.5.4. Tiempo de descifrado en PC y Java Card con la configuracin

8.1. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313

Longitudes de clave en RSA y ECC . . . . . . . . . . . . . . . . . . .

1.1. Diners Club, la primera tarjeta de crdito del mundo . . . . . . . . . 20

1.3. Prototipo de D.N.I. electrnico de Espaa . . . . . . . . . . . . . . . 21

1.7. Control de acceso con tarjeta inteligente sin contactos . . . . . . . . . 22

1.20. Arquitectura MULTOS . . . . . . . . . . . . . . . . . . . . . . . . . . 38

1.23. Elementos de la arquitectura PC/SC . . . . . . . . . . . . . . . . . . 42

2.1. Modelos de seguridad en criptosistemas de clave pblica . . . . . . . 56

3.5. Mtodos implicados en la gestin de un applet . . . . . . . . . . . . . 119

4.4. Maleabilidad debido a la funcin XOR . . . . . . . . . . . . . . . . . 176

5.25. Men principal con el elemento Cuerpo GF() activado . . . . . . . . 215

5.30. Pestaa Cifrado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222

5.60. Identificador del fichero para el mensaje descifrado . . . . . . . . . . . 241

7.7. Factor de expansin en curvas sobre con la configuracin P2

7.8. Factor de expansin en curvas sobre con la configuracin P3

7.9. Tiempo de cifrado con curvas sobre 2 en PC (configuracin M1) . . 290

7.11. Tiempo de cifrado con curvas sobre 2 en JCOP 41 e interfaz sin

7.32. Comparacin del tiempo de ejecucin en JCOP 41 (configuracin M2)

Comparacin de las longitudes de clave entre RSA y ECC . . . . . .

Comparacin del rendimiento de ECC, RSA y los esquemas DLP

Comparacin de las implementaciones hardware de RSA y ECC . . .

1.1. Valores del byte CLA permitidos . . . . . . . . . . . . . . . . . . . . 44

6.1. Funcionalidades ECC en Java Card . . . . . . . . . . . . . . . . . . . 246

7.5. Factor de expansin en curvas sobre con la configuracin P2

7.6. Factor de expansin en curvas sobre con la configuracin P3

7.7. Tiempo de cifrado con curvas sobre 2 en PC (configuracin M1) . . 289

7.24. Tiempo de descifrado con curvas sobre en JCOP J3A e interfaz

Establecimiento de clave Diffie-Hellman . . . . . . . . . . . . . . . . 58

Generacin de claves RSA . . . . . . . . . . . . . . . . . . . . . . . . 60

Generacin de claves para el criptosistema ElGamal . . . . . . . . . 65

Cifrado de mensajes en el criptosistema ElGamal . . . . . . . . . . . 66

Descifrado de mensajes en el criptosistema ElGamal . . . . . . . . . 66

Compresin de un punto = (, ) de la curva . . . . . . . . . . . . 89

Descompresin de un punto = (, ) de la curva . . . . . . . . . . 89

2.10. Generacin aleatoria de una curva sobre 2 . . . . . . . . . . . . . 90

Criptosistema Massey-Omura con curvas elpticas . . . . . . . . . . 130

Criptosistema ElGamal con curvas elpticas . . . . . . . . . . . . . . 130

Criptosistema Menezes-Vanstone con curvas elpticas . . . . . . . . . 131

Funcin ANSI-X9.63-KDF . . . . . . . . . . . . . . . . . . . . . . . 142