Implementación En Tarjetas Inteligentes Java Card De Protocolos De Cifrado Y Descifrado Basados En Curvas Elípticas

Universidad Politécnica de Madrid Escuela Técnica Superior de Ingenieros de Telecomunicación

Consejo Superior de Investigaciones Cientíﬁcas Instituto de Física Aplicada

Implementación en tarjetas inteligentes Java Card de protocolos de cifrado y descifrado basados en curvas elípticas

Tesis Doctoral

Víctor Gayoso Martínez Ingeniero de Telecomunicación

2010

Departamento de Matemática Aplicada a las Tecnologías de la Información

Departamento de Tratamiento de la Información y Codiﬁcación

Directores

Carmen Sánchez Ávila Doctora en Ciencias Matemáticas

Luis Hernández Encinas Doctor en Ciencias Matemáticas

Madrid 2010

TRIBUNAL CALIFICADOR

Tribunal nombrado por el Magfco. y Excmo. Sr. Rector de la Universidad Poli- técnica de Madrid el día de de .

Presidente Dr. D.

Vocal Dr. D.

Secretario Dr. D.

Realizado el acto de lectura y defensa de la Tesis el día de de en Madrid.

Caliﬁcación:

EL PRESIDENTE LOS VOCALES

EL SECRETARIO

Para Laura y Blanca. THV6IGRlIG1pIHZpZGEgeSBhbGllbnRvIGRlIG1pIHNlci4=

I do not have a name. You can call me V. Alan Moore. V for Vendetta.

Reputation is what other people know about you. Honor is what you know about yourself. Lois McMaster Bujold. A Civil Campaign.

AGRADECIMIENTOS

En primer lugar me gustaría mostrar mi agradecimiento a mis tutores Luis Her- nández y Carmen Sánchez por su esfuerzo continuo y su paciencia inﬁnita revisando cada borrador de esta Tesis, dándome siempre buenos y acertados consejos.

En especial, me gustaría agradecer a Luis la magníﬁca oportunidad de haber podido trabajar con él estos dos últimos años en el Consejo Superior de Investiga- ciones Cientíﬁcas, tiempo del que siempre guardaré el mejor de los recuerdos y en el que tanto he aprendido.

El resto de agradecimientos son para:

Mi mujer y mi hija, a las que tanto debo.

Mis padres, por apoyarme y ayudarme siempre que lo he necesitado.

Mi hermana, con la que a pesar de la distancia sigo compartiendo tantas cosas.

Mis amigos Óscar, Sixto, Enrique, Mónica, María José, Carlos Daniel, José Ig- nacio, Blanca, Marta, David, Rafa, Enrique, Gema, Antonio, Ma Carmen y tantos otros, por seguir siendo los mejores amigos en los buenos y los malos momentos.

La empresa NXP, y muy especialmente Juan Moreno, por proporcionarme las tarjetas JCOP J3A empleadas en esta Tesis, sin las cuales no habría podido desarrollar una parte importante de la investigación.

El departamento de Tratamiento de la Información y Codiﬁcación del Instituto de Física Aplicada del CSIC, por la profesionalidad y compañerismo demostrados en estos dos últimos años.

Índice general

Introducción1 Antecedentes ...... 1 Justiﬁcación ...... 3 Objetivos ...... 10 Metodología ...... 11 Clasiﬁcación ...... 12 Estructura ...... 13 Notas de estilo ...... 15

1. Tarjetas inteligentes 19 1.1. Historia de las tarjetas inteligentes ...... 19 1.2. ¿Qué es una tarjeta inteligente? ...... 22 1.3. Tipos de tarjetas inteligentes ...... 25 1.3.1. Tarjetas de memoria ...... 25 1.3.2. Tarjetas con microprocesador ...... 25 1.3.3. Tarjetas con coprocesador ...... 28 1.4. Propiedades físicas y eléctricas ...... 28 1.5. Estándares ...... 31 1.5.1. La norma ISO/IEC 7816 ...... 31 1.5.2. La norma ISO/IEC 14443 ...... 33 1.5.3. Las normas ETSI y 3GPP ...... 33 1.5.4. Las normas Global Platform ...... 35 1.6. Sistemas operativos de tarjetas inteligentes ...... 35

xi xii Índice general

1.6.1. Tarjetas Java Card ...... 36 1.6.2. Tarjetas MULTOS ...... 37 1.6.3. Tarjetas Windows for Smart Cards ...... 37 1.7. Arquitecturas de acceso a las tarjetas inteligentes desde PC ...... 38 1.7.1. Arquitectura OpenCard Framework ...... 38 1.7.2. Arquitectura PC/SC ...... 40 1.8. Comunicación con la tarjeta inteligente ...... 41 1.8.1. APDU de tipo comando ...... 43 1.8.2. APDU de tipo respuesta ...... 46

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

2.6.6. Comprobación de los parámetros de una curva elíptica . . . . 90 2.6.7. Seguridad ...... 91 2.6.8. Estándares relacionados ...... 92 2.6.9. Patentes ...... 95

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

4. Estudio y análisis del esquema de cifrado ECIES 129 4.1. Criptosistemas de curvas elípticas ...... 129 4.2. Esquema de cifrado DHIES ...... 136 xiv Índice general

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

5. Implementación de ECIES en entorno PC 181 5.1. Diseño del esquema ECIES a implementar ...... 181 5.1.1. Cifrado ...... 182 5.1.2. Descifrado ...... 183 Índice general xv

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

6. Implementación de ECIES en Java Card 243 6.1. Elementos criptográﬁcos de ECIES disponibles en Java Card . . . . . 243 6.1.1. Java Card 2.1 ...... 244 6.1.2. Java Card 2.1.1 ...... 244 6.1.3. Java Card 2.2 ...... 244 6.1.4. Java Card 2.2.1 ...... 244 6.1.5. Java Card 2.2.2 ...... 244 6.1.6. Java Card 3.0 ...... 245 6.2. Resumen de funcionalidad ECC en Java Card ...... 246 6.3. Entorno de desarrollo ...... 246 6.3.1. NetBeans ...... 247 xvi Índice general

6.3.2. Herramientas de línea de comandos de Sun ...... 247 6.3.3. Eclipse ...... 248 6.4. Esquema de la aplicación ...... 248 6.5. Pruebas con tarjetas virtuales ...... 253 6.6. Pruebas con tarjetas reales ...... 255 6.7. Aplicación JCOPECIES ...... 256 6.8. Ejemplos de utilización ...... 261 6.8.1. Cifrado y descifrado en tarjetas JCOP 41 y el complemento de NXP para Eclipse ...... 263 6.8.2. Cifrado y descifrado en tarjetas JCOP J3A y la aplicación JCOPECIES ...... 269

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

7.5.4. Tiempo de descifrado en PC y Java Card con la conﬁguración P2 ...... 300 7.5.5. Tiempo de descifrado en PC y Java Card con la conﬁguración P3 ...... 307 7.6. Rendimiento comparado ...... 309

8. Conclusiones, aportaciones y trabajo futuro 313 8.1. Conclusiones ...... 313 8.1.1. El esquema ECIES como estándar ...... 314 8.1.2. Conjunto de parámetros compatibles con todos los estándares 314 8.1.3. Desarrollo de la implementación de ECIES para PC ...... 315 8.1.4. Estudio de la eficiencia de la implementación PC ...... 316 8.1.5. Desarrollo de la implementación de ECIES en tarjetas Java Card ...... 318 8.1.6. Estudio de la eficiencia de la implementación Java Card . . . . 319 8.1.7. Comparativa entre las versiones PC y Java Card ...... 324 8.1.8. Configuración de ECIES resistente a ataques ...... 324 8.2. Aportaciones ...... 325 8.3. Trabajo futuro ...... 327

Notación 331

Glosario 333

Referencias 339

Índice de ﬁguras

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

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

xix xx Índice de ﬁguras

1.23. Elementos de la arquitectura PC/SC ...... 42 1.24. Modelo de comunicación con la tarjeta inteligente ...... 43 1.25. Esquema de una APDU de tipo comando ...... 43 1.26. Posibles estructuras de un comando APDU ...... 45 1.27. APDU de tipo respuesta ...... 46 1.28. Posibles códigos de respuesta ...... 47

2.1. Modelos de seguridad en criptosistemas de clave pública ...... 56 2.2. Curva y2 = x3 con un nodo en el punto (0, 0) ...... 72 2.3. Curva y2 + xy − x3 = 0 con una cúspide en el punto (0, 0) ...... 72 2.4. Curva elíptica y2 = x3 − 10x + 15 ...... 74 2.5. Curva elíptica y2 = x3 − 10x + 9 ...... 74 2.6. Suma de puntos de la curva R = P + Q ...... 76 2.7. Suma de puntos de la curva R = P + Q = O ...... 77 2.8. Suma de puntos de la curva R = P + P = 2P ...... 77 2.9. Suma de puntos de la curva R = P + 2P = 3P ...... 78 2.10. Suma de puntos R = P + Q sobre un cuerpo primo ...... 83 2.11. Suma de puntos R = P + P = 2P sobre un cuerpo primo ...... 84 2.12. Suma de puntos R = P + 2P = 3P sobre un cuerpo primo ...... 84

3.1. Ediciones del lenguaje Java ...... 103 3.2. Ejemplo de utilización de proveedores criptográﬁcos en Java . . . . . 106 3.3. Arquitectura Java Card y de su entorno de ejecución ...... 117 3.4. Métodos para la gestión del ciclo de vida de un applet Java Card . . 118 3.5. Métodos implicados en la gestión de un applet ...... 119 3.6. Compartición de objetos en Java Card ...... 120 3.7. Esquema de conversión a ﬁcheros 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 ﬁguras xxi

4.4. Maleabilidad debido a la función XOR ...... 176

5.1. Diagrama de clases de la aplicación ECIES ...... 187 5.2. Ventana principal del entorno de desarrollo NetBeans ...... 190 5.3. Ventana principal de la aplicación ...... 192 5.4. Opciones del menú Programa ...... 192 5.5. Ejemplo de ventana con aspecto Nimbus ...... 193 5.6. Ejemplo de ventana con aspecto Windows ...... 193 5.7. Ventana de la opción Ayuda ...... 194 5.8. Ventana de la opción Acerca de ...... 195 5.9. Pantalla de confirmación de la opción Salir ...... 195 5.10. Opción Sencillo ...... 196 5.11. Opción Avanzado ...... 197 5.12. Opciones del menú Perfiles ...... 198 5.13. Submenú ISO/IEC del menú Test ...... 201 5.14. Submenú SECG del menú Test ...... 202 5.15. Curvas correspondientes al submenú ANSI ...... 203 5.16. Curvas correspondientes al submenú Brainpool ...... 204 5.17. Curvas correspondientes al submenú NIST ...... 205 5.18. Curvas correspondientes al submenú SECG ...... 206 5.19. Opciones del menú Utilidades ...... 207 5.20. Ventana de creación de los ficheros de claves ...... 208

5.21. Ventana de generación de clave en cuerpos Fp ...... 213

5.22. Ventana de generación de clave en cuerpos F2m ...... 213

5.23. Ventana de descompresión de puntos en cuerpos Fp ...... 214

5.24. Ventana de descompresión de puntos en cuerpos F2m ...... 215 5.25. Menú principal con el elemento Cuerpo GF(p) activado ...... 215 5.26. Menú principal con el elemento Cuerpo GF(2^m) activado ...... 216 5.27. Pestaña Conﬁguración ...... 216 5.28. Pestaña Parámetros con el menú Cuerpo GF(p) activado ...... 219 5.29. Pestaña Parámetros con el menú Cuerpo GF(2^m) activado . . . . . 220 xxii Índice de ﬁguras

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

5.60. Identiﬁcador del ﬁchero para el mensaje descifrado ...... 241 5.61. Contenido de la caja de texto de la etiqueta ...... 241 5.62. Ventana con el resultado del proceso de descifrado ...... 242

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

7.1. Diagrama de los módulos P5CT072 y P5CD080 ...... 273 7.2. Tarjetas JCOP y lector PC/SC empleados en las pruebas ...... 274 7.3. Frecuencias de trabajo en la interfaz con contactos y sin contactos . . 275

7.4. Factor de expansión en curvas sobre F2m con la conﬁguración M1 . . 281

7.5. Factor de expansión en curvas sobre F2m con la conﬁguración M2 . . 283

7.6. Factor de expansión en curvas sobre Fp con la conﬁguración P1 . . . 284

7.7. Factor de expansión en curvas sobre Fp con la conﬁguración P2 . . . 286

7.8. Factor de expansión en curvas sobre Fp con la conﬁguración P3 . . . 287

7.9. Tiempo de cifrado con curvas sobre F2m en PC (conﬁguración M1) . . 290

7.10. Tiempo de cifrado con curvas sobre F2m en PC (conﬁguración M2) . . 291 xxiv Índice de ﬁguras

7.11. Tiempo de cifrado con curvas sobre F2m en JCOP 41 e interfaz sin contactos (conﬁguración M2) ...... 292

7.12. Tiempo de cifrado con curvas sobre F2m en JCOP 41 e interfaz con contactos (conﬁguración M2) ...... 293

7.13. Tiempo de cifrado con curvas sobre Fp en PC (conﬁguración P1) . . . 294

7.14. Tiempo de cifrado con curvas sobre Fp en PC (conﬁguración P2) . . . 295

7.15. Tiempo de cifrado con curvas sobre Fp en JCOP J3A e interfaz sin contactos (conﬁguración P2) ...... 296

7.16. Tiempo de cifrado con curvas sobre Fp en PC (conﬁguración P3) . . . 297

7.17. Tiempo de cifrado con curvas sobre Fp en JCOP J3A e interfaz sin contactos (conﬁguración P3) ...... 298

7.18. Tiempo de descifrado con curvas sobre F2m en PC (conﬁguración M1) 300

7.19. Tiempo de descifrado con curvas sobre F2m en PC (conﬁguración M2) 301

7.20. Tiempo de descifrado con curvas sobre F2m en JCOP 41 e interfaz sin contactos (conﬁguración M2) ...... 302

7.21. Tiempo de descifrado con curvas sobre F2m en JCOP 41 e interfaz con contactos (conﬁguración M2) ...... 303

7.22. Tiempo de descifrado con curvas sobre Fp en PC (conﬁguración P1) . 304

7.23. Tiempo de descifrado con curvas sobre Fp en PC (conﬁguración P2) . 305

7.24. Tiempo de descifrado con curvas sobre Fp en JCOP J3A e interfaz sin contactos (conﬁguración P2) ...... 306

7.25. Tiempo de descifrado con curvas sobre Fp en PC (conﬁguración P3) . 308

7.26. Tiempo de descifrado con curvas sobre Fp en JCOP J3A e interfaz sin contactos (configuración P3) ...... 308 7.27. Comparación del tiempo de ejecución en PC (configuraciones M1 y P1)309 7.28. Comparación del tiempo de ejecución entre las versiones PC y Java Card (configuración M2) ...... 310 7.29. Comparación del tiempo de ejecución entre las versiones PC y Java Card (configuración P2) ...... 310 7.30. Comparación del tiempo de ejecución entre las versiones PC y Java Card (configuración P3) ...... 311 7.31. Comparación del tiempo de ejecución en las tarjetas JCOP 41 (con- figuración M2) y JCOP J3A (configuración P2) al cifrar un mensaje de 64 bytes ...... 312 Índice de figuras xxv

7.32. Comparación del tiempo de ejecución en JCOP 41 (conﬁguración M2) y JCOP J3A (conﬁguración P2) al cifrar un mensaje de 160 bytes . . 312

Índice de cuadros

1. Comparación de las longitudes de clave entre RSA y ECC ...... 2 2. Comparación del rendimiento de ECC, RSA y los esquemas DLP medido en unidades de tiempo necesarias para cada operación . . . .3 3. Comparación de las implementaciones hardware de RSA y ECC . . .4

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

2.1. Versiones simpliﬁcadas de la ecuación de Weierstrass ...... 82

3.1. Clases e interfaces del paquete javacard.security ...... 125 3.2. Clases e interfaces del paquete javacardx.crypto ...... 125

4.1. Comparativa del proceso de cifrado en ECIES, PSEC y ACE . . . . . 133 4.2. Número de operaciones para el cifrado en ECIES, PSEC y ACE . . . 134 4.3. Rendimiento del cifrado en ECIES, PSEC y ACE ...... 135 4.4. Comparativa de longitudes en bytes para ECIES, PSEC y ACE . . . 135 4.5. Función HASH ...... 168 4.6. Función KA ...... 169 4.7. Función KDF ...... 169 4.8. Función ENC ...... 169 4.9. Función MAC ...... 170 4.10. Funciones comunes permitidas en los cuatro estándares ...... 170 4.11. Combinaciones de parámetros admitidas al menos en un estándar . . 171 4.12. Comparativa de las conﬁguraciones permitidas en cada estándar . . . 172

xxvii xxviii Índice de cuadros

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

7.1. Curvas elípticas empleadas en las conﬁguraciones ...... 278

7.2. Factor de expansión en curvas sobre F2m con la conﬁguración M1 . . 281

7.3. Factor de expansión en curvas sobre F2m con la conﬁguración M2 . . 282

7.4. Factor de expansión en curvas sobre Fp con la conﬁguración P1 . . . 284

7.5. Factor de expansión en curvas sobre Fp con la conﬁguración P2 . . . 285

7.6. Factor de expansión en curvas sobre Fp con la conﬁguración P3 . . . 287

7.7. Tiempo de cifrado con curvas sobre F2m en PC (conﬁguración M1) . . 289

7.8. Tiempo de cifrado con curvas sobre F2m en PC (conﬁguración M2) . . 290

7.9. Tiempo de cifrado con curvas sobre F2m en JCOP 41 e interfaz sin contactos (conﬁguración M2) ...... 291

7.10. Tiempo de cifrado con curvas sobre F2m en JCOP 41 e interfaz con contactos (conﬁguración M2) ...... 292

7.11. Tiempo de cifrado con curvas sobre Fp en PC (conﬁguración P1) . . . 293

7.12. Tiempo de cifrado con curvas sobre Fp en PC (conﬁguración P2) . . . 295

7.13. Tiempo de cifrado con curvas sobre Fp en JCOP J3A e interfaz sin contactos (conﬁguración P2) ...... 296

7.14. Tiempo de cifrado con curvas sobre Fp en PC (conﬁguración P3) . . . 297

7.15. Tiempo de cifrado con curvas sobre Fp en JCOP J3A e interfaz sin contactos (conﬁguración P3) ...... 298

7.16. Tiempo de descifrado con curvas sobre F2m en PC (conﬁguración M1) 299

7.17. Tiempo de descifrado con curvas sobre F2m en PC (conﬁguración M2) 301

7.18. Tiempo de descifrado con curvas sobre F2m en JCOP 41 e interfaz sin contactos (conﬁguración M2) ...... 302

7.19. Tiempo de descifrado con curvas sobre F2m en JCOP 41 e interfaz con contactos (conﬁguración M2) ...... 303

7.20. Tiempo de descifrado con curvas sobre Fp en PC (conﬁguración P1) . 304

7.21. Tiempo de descifrado con curvas sobre Fp en PC (conﬁguración P2) . 305

7.22. Tiempo de descifrado con curvas sobre Fp en JCOP J3A e interfaz sin contactos (conﬁguración P2) ...... 306

7.23. Tiempo de descifrado con curvas sobre Fp en PC (conﬁguración P3) . 307 Índice de cuadros xxix

7.24. Tiempo de descifrado con curvas sobre Fp en JCOP J3A e interfaz sin contactos (conﬁguración P3) ...... 307

8.1. Crecimiento del tiempo de cifrado y descifrado en PC (configuración M1) ...... 317 8.2. Crecimiento del tiempo de cifrado y descifrado en PC (configuración P1)...... 318 8.3. Crecimiento del tiempo de cifrado y descifrado en JCOP 41 e interfaz sin contactos (configuración M2) ...... 320 8.4. Crecimiento del tiempo de cifrado y descifrado en JCOP 41 e interfaz con contactos (configuración M2) ...... 321 8.5. Crecimiento del tiempo de cifrado y descifrado en JCOP J3A e interfaz sin contactos (configuración P2) ...... 321 8.6. Crecimiento del tiempo de cifrado y descifrado en JCOP J3A e interfaz sin contactos (configuración P3) ...... 321 8.7. Incremento relativo del tiempo de ejecución en JCOP 41 e interfaz sin contactos (configuración M2) ...... 323 8.8. Incremento relativo del tiempo de ejecución en JCOP 41 e interfaz con contactos (configuración M2) ...... 323 8.9. Incremento relativo del tiempo de ejecución en JCOP J3A e interfaz sin contactos (configuración P2) ...... 323 8.10. Incremento relativo del tiempo de ejecución en JCOP J3A e interfaz sin contactos (configuración P3) ...... 324

Índice de algoritmos

2.1. Establecimiento de clave Diﬃe-Hellman ...... 58 2.2. Generación de claves RSA ...... 60 2.3. Cifrado RSA ...... 61 2.4. Descifrado RSA ...... 61 2.5. Generación de claves para el criptosistema ElGamal ...... 65 2.6. Cifrado de mensajes en el criptosistema ElGamal ...... 66 2.7. Descifrado de mensajes en el criptosistema ElGamal ...... 66 2.8. Compresión de un punto P = (x, y) de la curva ...... 89 2.9. Descompresión de un punto P = (x, y) de la curva ...... 89

2.10. Generación aleatoria de una curva sobre F2m ...... 90 2.11. Comprobación de los parámetros de una curva ...... 91 2.12. Validación de una clave pública Q ...... 91 4.1. Criptosistema Massey-Omura con curvas elípticas ...... 130 4.2. Criptosistema ElGamal con curvas elípticas ...... 130 4.3. Criptosistema Menezes-Vanstone con curvas elípticas ...... 131 4.4. Función ANSI-X9.63-KDF ...... 142 4.5. Función NIST-800-56-Concatenation-KDF ...... 143 4.6. Función KDF1 ...... 144 4.7. Función KDF2 ...... 144 4.8. Función HMAC ...... 146 4.9. Cifrado ECIES en ANSI X9.63 ...... 149 4.10. Cifrado ECIES en IEEE 1363a ...... 154 4.11. Fase KEM del cifrado ECIES en ISO/IEC 18033-2 ...... 157

xxxi xxxii Índice de algoritmos

4.12. Función DEM1 de la fase DEM del cifrado ECIES en ISO/IEC 18033-2 ...... 158 4.13. Función DEM2 de la fase DEM del cifrado ECIES en ISO/IEC 18033-2 ...... 158 4.14. Función DEM3 de la fase DEM del cifrado ECIES en ISO/IEC 18033-2 ...... 159 4.15. Cifrado ECIES en SEC 1 ...... 163 4.16. Cifrado ECIES compatible con los cuatro estándares (ECIES-4) . . . 173 4.17. Cifrado ECIES compatible con los cuatro estándares (ECIES-3) . . . 179 5.1. Cifrado ECIES en la versión PC (fase KEM )...... 182 5.2. Cifrado ECIES en la versión PC (fase DEM )...... 183 5.3. Descifrado ECIES en la versión PC (fase KEM )...... 184 5.4. Descifrado ECIES en la versión PC (fase DEM )...... 184 5.5. Generación de una semilla aleatoria ...... 209 Introducción

Antecedentes

En 1976, Whitfield Diffie y Martin Hellman [61] desarrollaron los conceptos que permitieron el nacimiento de la criptografía de clave pública. Desde entonces, numerosos criptosistemas han sido propuestos, aunque sólo unos pocos han soportado con éxito el escrutinio de la comunidad científica. Entre los elementos analizados por los expertos destacan principalmente las características de eficiencia, complejidad y seguridad de los algoritmos, las cuales dependen en gran medida del problema matemático en que están basados. Algunos de los problemas relacionados con los criptosistemas actuales son:

∙ Factorización en enteros (Integer Factorization Problem o IFP), fundamento del criptosistema RSA [66, 232, 229].

∙ Logaritmo discreto (Discrete Logarithm Problem o DLP), base matemática para el algoritmo ElGamal [69].

∙ Logaritmo discreto en curvas elípticas (Elliptic Curve Discrete Logarithm Pro- blem o ECDLP), núcleo de la criptografía basada en curvas elípticas.

En 1985, Neal Koblitz [147] y Victor Miller [174] propusieron de forma independiente el uso de curvas elípticas en criptografía (Elliptic Curve Cryptography o ECC), cuya seguridad depende del ECDLP. Desde entonces, la ECC se ha aplicado a campos tan diversos como la creación de criptosistemas para el cifrado y descifrado de datos [16, 109, 136, 254], la generación y veriﬁcación de ﬁrmas digitales [15, 184], la factorización de enteros [49, 159], las técnicas de primalidad [23, 49, 95], e incluso ocupó un lugar destacado en la demostración del último teorema de Fermat por parte de Andrew Wiles [269].

1 2 Introducción

Al igual que en el caso del IFP y del DLP, no se conoce ningún algoritmo que resuelva de forma eﬁciente el ECDLP. De hecho, se estima que el ECDLP es el más difícil de resolver de los tres problemas mencionados [37, 147, 168], lo que convertiría la criptografía con curvas elípticas en el criptosistema más resistente. Gracias a esta mayor resistencia, la longitud de las claves en ECC es 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 simétrico que utilice una clave de n bits), tal como se puede observar en el Cuadro1 y la Figura1 (cuyos datos han sido obtenidos de [99] y [184]), lo que favorece su uso en sistemas con recursos limitados como por ejemplo los teléfonos móviles y las tarjetas inteligentes.

Nivel de seguridad Longitud de la Longitud de la (bits) clave RSA (bits) clave ECC (bits) 80 1024 160-223 112 2048 224-255 128 3072 256-283 192 7680 384-511 256 15360 512-571

Cuadro 1: Comparación de las longitudes de clave entre RSA y ECC

Debido a su reciente aparición, al menos en comparación con otros algoritmos de clave pública como el propio criptosistema RSA, las propiedades y posibilidades de utilización de la criptografía de curva elíptica han sido estudiadas en menor profundidad que otras opciones criptográficas, lo que ha motivado su menor implantación en el entorno de las soluciones de seguridad. Sin embargo, ello no impide que existan estudios que reflejen el rendimiento comparado de RSA y ECC en operaciones de cifrado/descifrado y firma/verificación, como por ejemplo el informe [233] realizado por RSA Labs, donde entre los datos ofrecidos se encuentra el Cuadro2. En dicho cuadro, las cantidades reflejadas hacen referencia al número de unidades temporales necesarias para realizar las operaciones citadas, tomando como unidad de referencia el tiempo necesario para realizar una multiplicación modular de 1024 bits. Por su parte, los autores de [38] presentaron una comparación entre ECC y RSA utilizando dos implementaciones hardware distintas, diseñadas para conseguir la mejor optimización en el espacio ocupado y la velocidad de ejecución del proceso de cifrado, respectivamente. Los resultados de dicho análisis se presentan en el Cua- dro3, donde se puede comprobar que el tiempo de procesamiento global (cifrado más descifrado) de ECC mejora respecto al de RSA al pasar de utilizar implementaciones software a emplear diseños hardware optimizados para las operaciones criptográficas Introducción 3

Figura 1: Longitudes de clave en RSA y ECC

ECC 160 bits RSA 1024 bits (con CRT) DLP 1024 bits Cifrado 120 17 480 Descifrado 60 384 240 Firma 60 384 240 Veriﬁcación 120 17 480

Cuadro 2: Comparación del rendimiento de ECC, RSA y los esquemas DLP medido en unidades de tiempo necesarias para cada operación 4 Introducción necesarias.

Optimización Tiempo (ms) Puertas lógicas RSA 1024 4.90 34000 Espacio ECC 163 0.66 3260 RSA 1024 2.60 150000 Velocidad ECC 163 0.35 48400 RSA 3072 184 50000 Espacio ECC 283 29 6660 RSA 3072 110 189200 Velocidad ECC 283 1.3 80100

Cuadro 3: Comparación de las implementaciones hardware de RSA y ECC

En resumen, los datos presentados conﬁrman las mejores prestaciones globales de ECC respecto de RSA, por lo que es de esperar que los criptosistemas basados en curvas elípticas aumenten su importancia y utilidad aún más en el futuro según se incrementen en paralelo los requisitos de seguridad.

Justiﬁcación

A la vista de la situación planteada en el apartado anterior, y dada la escasez de implementaciones software de ECC en general (y en tarjetas inteligentes en particular), se estimó la importancia de desarrollar diversas aplicaciones que implementaran un protocolo de cifrado y descifrado sobre curvas elípticas en entornos PC y tarjetas inteligentes, siendo Java el lenguaje de programación elegido debido a su popularidad y presencia en entornos comerciales (ver §3.2y§3.4). A título informativo, la cifra de desarrolladores Java supera en la actualidad los 6 millones, existiendo más de 4.500 millones de dispositivos habilitados con tecnología Java (principalmente ordenadores personales, teléfonos móviles y tarjetas inteligentes) [212]. El siguiente paso consistió en analizar los diferentes esquemas de cifrado existentes y seleccionar uno de los candidatos para su implementación. Los primeros esquemas basados en curvas elípticas que surgieron fueron el equivalente de los 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 elíptica. Si bien es cierto que en las curvas utilizadas habitualmente el número de puntos es un valor tan elevado que esta limitación es más teórica que práctica, la obligatoriedad de construir tablas donde se relacionen cada uno de los posibles mensajes (y que éstas sean previamente conocidas por todos los usuarios) limita la utilidad de estos criptosistemas a entornos Introducción 5 cerrados donde todos los posibles mensajes estén estipulados (empresas, pequeños grupos, etc.). El criptosistema Menezes-Vanstone [169] fue diseñado para solventar esa limi- tación, puesto que en lugar de hacer corresponder cada mensaje con un punto de la curva, este esquema representa los mensajes en claro como pares ordenados cuyos componentes son elementos del cuerpo finito sobre el que se define la curva elíptica. De esta manera, es posible dividir cualquier mensaje en claro en bloques, donde cada bloque pueda ser codificado como un par ordenado (por ejemplo, convirtiendo una cadena de caracteres o bytes en su equivalente numérico). Como contrapartida 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 El- Gamal para curvas elípticas, donde el criptograma siempre tiene la misma longitud independientemente del mensaje en claro). En el esquema Menezes-Vanstone el factor de expansión (que se define como el cociente entre la longitud del criptograma resultante y la longitud del mensaje original) es 2, puesto que a partir del mensaje en claro compuesto por dos elementos del cuerpo finito se obtiene un criptograma formado por cuatro elementos del mismo cuerpo. En comparación, la variante de ElGamal con curvas elípticas tiene el mismo factor de expansión si se considera que el mensaje en claro es un punto de la curva, mientras que si se interpreta que el número total de mensajes posibles es igual al número de puntos de la curva (que es del orden del número de elementos del cuerpo finito), entonces el factor de expansión sería aproximadamente 4 (ver §4.1). El hecho de tener un factor de expansión igual a 2 ó 4 conlleva que el cifrado de volúmenes de información elevados generen criptogramas de tamaño mucho mayor que si se utilizara un algoritmo de clave simétrica como por ejemplo AES (Advanced Encryption Standard). Otra desventaja derivada del diseño del criptosistema Menezes-Vanstone consiste en la realización de operaciones con los puntos de las curvas elípticas en cada proceso de cifrado. Al ser necesario dividir los mensajes en claro de gran tamaño en múltiples segmentos, y realizar un operación de cifrado asimétrico con cada uno de ellos, la diferencia en tiempo de ejecución del esquema Menezes-Vanstone respecto a un algoritmo de cifrado simétrico se incrementa conforme aumenta el número de segmentos a cifrar, puesto que las operaciones con puntos son más lentas que los cálculos realizados por los algoritmos de clave simétrica. De manera adicional a las desventajas de carácter práctico señaladas, Klaus Kie- fer demostró en 1998 que, bajo ciertas ciertas condiciones, el criptosistema Menezes- Vanstone es inseguro [146]. Kiefer demostró además que, en contra de lo estipulado en su especificación, este criptosistema no puede ser considerado un algoritmo de cifrado probabilístico. Debido a todas las razones comentadas, con el paso de los años la comunidad académica ha ido abandonando el estudio de las versiones con curvas elípticas de 6 Introducción los criptosistemas Massey-Omura, ElGamal y Menezes-Vanstone. Sin embargo, el descubrimiento de las limitaciones de esos criptosistemas no significó que se abando- nara la búsqueda de un criptosistema de curvas elípticas que fuera práctico y seguro, sino que provocó un cambio de dirección, pasando a ocupar el centro de atención los esquemas de cifrado híbridos (descritos en §2.5). Los principales esquemas híbri- dos que emplean curvas elípticas son ECIES (Elliptic Curve Integrated Encryption Scheme), PSEC (Provably Secure Elliptic Curve encryption scheme) [199, 243] y ACE (Advanced Cryptographic Engine) [55, 243]. De los tres esquemas, ECIES es el que está presente en un mayor número de estándares (ANSI X9.63 [16], IEEE 1363a [109], ISO/IEC 18033-2 [136] y SECG SEC 1 [254]). Por su parte, PSEC se puede encontrar en ISO/IEC 18033-2 [136], IETF RFC 4051 [68] y en el conjunto de algoritmos seleccionados por el proyecto NESSIE (New European Schemes for Signatures, Integrity and Encryption) [195, 196], mientras que ACE está presente en ISO/IEC 18033-2 [136] y en la selección final de NESSIE [195, 196]. Las principales diferencias entre los esquemas ECIES, PSEC y ACE, presentadas en §4.1, son las siguientes:

∙ Tanto en ECIES como en PSEC, la clave pública del receptor del criptograma es un punto de la curva, mientras que en ACE la clave pública está formada por cuatro puntos.

∙ PSEC utiliza dos veces una función de derivación de claves, mientras que ECIES y ACE sólo la utilizan una vez.

∙ ECIES y ACE utilizan la primera coordenada de un punto de la curva generado durante los cálculos intermedios (en lugar de las dos coordenadas) como parámetro de entrada de la función de derivación de claves, mientras que en PSEC es obligatorio utilizar las dos coordenadas.

∙ Los criptogramas de ECIES están formados por tres elementos (un punto de la curva, el mensaje cifrado con una clave simétrica y un dato utilizado para la autenticación del mensaje), mientras que los criptogramas de PSEC incluyen además un elemento derivado de los cálculos intermedios (y representado como una cadena binaria) y los criptogramas del esquema ACE añaden dos puntos de la curva elíptica.

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

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

1. Utilización de bibliotecas criptográﬁcas de terceros adaptadas a la arquitectura de seguridad Java. 2. Uso de bibliotecas criptográﬁcas de terceros con clases y sintaxis propietarias, no adaptadas a la arquitectura Java. 8 Introducción

3. Desarrollo propio de los algoritmos relacionados con la ECC y de las operaciones aritméticas con los puntos de las curvas elípticas y con los elementos de los cuerpos ﬁnitos.

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

∙ Elliptic curve cryptography on smart cards [218]: se trata de un Proyecto Fin de Carrera presentado el año 2000 en el que, con el objetivo de comparar ECC y RSA en tarjetas inteligentes, se muestra una implementación de los algoritmos Nyberg-Rueppel de ﬁrma digital y Menezes-Vanstone de cifrado. La implementación desarrollada emplea únicamente curvas deﬁnidas sobre cuerpos F2m , utilizando para la realización de las pruebas el emulador software incluido en Java Card 2.1, sin presentar ningún resultado con tarjetas reales.

∙ Smart-card implementation of Elliptic Curve Cryptography and DPA-based attacks [142]: este artículo analiza los ataques de canal lateral (también conocidos como side channel attacks) diseñados específicamente para tarjetas inteligentes que implementen criptografía de curva elíptica. El artículo se centra en el análisis de seguridad, proponiendo algunas medidas para evitar ataques de análisis de potencia (Differential Power Analysis o DPA) al utilizar curvas sobre cuerpos F2m , pero sin tratar específicamente el esquema ECIES. ∙ Lessons learned on implementing ECDSA on a Java smart card [71]: artículo que describe las dificultades de implementar clases propietarias para la eje- cución del algoritmo de firma digital ECDSA [15, 184], y que concluye que dicha implementación en tarjetas Java Card no es práctica, siendo preferible que existan clases estándar incluidas en la tarjeta, y que éstas utilicen un coprocesador. Como dato ilustrativo, el tiempo necesario para obtener el inverso de un elemento de un cuerpo finito Fp, con ⌈log2 p⌉ = 50, es de 370 segundos. ∙ Implementation of ECC/ECDSA Cryptography Algorithms Based on Java Card [98]: se trata de una implementación de ECDSA en una placa de simulación NGICC (Next Generation Integrated Circuit Card) de 32 bits con coprocesador criptográfico y soporte nativo para funciones de ECC mediante API de Java Card. Tras la implementación, los autores comparan el rendimiento de ECDSA con RSA para concluir que la ejecución de ECDSA es más eficiente.

∙ Elliptic curve cryptosystems on smart cards [178]: artículo que describe de forma teórica la implementación de un protocolo de acuerdo de clave para tarjetas inteligentes basado en las operaciones del algoritmo de ﬁrma digital ECDSA. Este trabajo presenta una comparación del rendimiento entre RSA y ECDSA en un PC, pero no incluye comparaciones en tarjetas inteligentes ni aporta detalles sobre el sistema operativo de las tarjetas a utilizar.

∙ Implementing Elliptic Curve Cryptography on PC and smart card [28]: artículo en que los autores implementaron las clases necesarias para realizar aritmética modular y de puntos en tarjetas Java Card 2.0 y 2.1. Como ejemplo del bajo rendimiento de la implementación, la suma de dos puntos de una curva de 109 bits definida sobre F2m tardaba 10 minutos, debido a que la tarjeta empleada no disponía de API especificas para ECC ni de coprocesador matemático. Este trabajo reitera la imposibilidad de desarrollar implementaciones eficientes con 10 Introducción

curvas elípticas en tarjetas inteligentes sin utilizar las clases y los métodos deﬁnidos en las API estándar 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 estándar de Java Card. Aunque técnicamente es posible crear clases y métodos que realicen operaciones comúnmente conocidas como “de bajo nivel” (por ejemplo, Petr Svenda ha creado implementaciones del algoritmo AES y de la función resumen SHA-512 utilizando código Java Card [258]), los resultados ofrecidos por implementaciones desarrolladas sin acceso al coprocesador indican que dichas implementaciones no son de utilidad para entornos comerciales, donde el tiempo de respuesta de las tarjetas a una ope- ración no debería superar la cantidad de un segundo (compárese este dato, por ejemplo, con los 10 minutos utilizados en la suma de dos puntos según [28], o con el tiempo medio de 4 segundos al cifrar con AES un único bloque de datos con la implementación descrita en [258]).

Objetivos

El objetivo general de la presente Tesis Doctoral consiste en implementar el protocolo de cifrado ECIES (Elliptic Curve Integrated Encryption Scheme), tanto en plataforma PC como en tarjetas inteligentes Java Card, a ﬁn de:

∙ Analizar la viabilidad de diferentes implementaciones para determinadas combinaciones de parámetros.

∙ Comparar el rendimiento de las implementaciones en PC y Java Card, tanto por separado como de forma conjunta.

∙ Recomendar combinaciones especíﬁcas para su utilización en distintos tipos de dispositivos, en función de las características de los dispositivos y del nivel de seguridad deseado.

Para conseguir este objetivo general, se pretenden alcanzar los siguientes objetivos particulares:

1. Analizar el protocolo de cifrado y descifrado ECIES con el ﬁn de determinar hasta qué punto las diferentes propuestas hechas para el mismo conforman un estándar coherente y homogéneo.

2. Proponer un conjunto (o conjuntos) de parámetros que sean compatibles con todos los estándares analizados. Introducción 11

3. Desarrollar una implementación de ECIES utilizando el lenguaje de progra- mación Java sobre una plataforma PC que permita trabajar con los conjuntos de parámetros propuestos y curvas deﬁnidas sobre cuerpos ﬁnitos primos y binarios.

4. Estudiar la eﬁciencia en términos de tiempo de computación y de factor de expansión de la implementación para PC.

5. Implementar el protocolo ECIES en tarjetas inteligentes de tipo Java Card, según la oferta y disponibilidad de tarjetas existentes en el mercado, con curvas deﬁnidas tanto sobre cuerpos ﬁnitos primos como binarios.

6. Caracterizar en términos de eficiencia la implementación realizada en las tarjetas Java Card utilizando curvas definidas sobre los dos cuerpos finitos anteriormente mencionados.

7. Comparar la implementación de ECIES llevada a cabo sobre la plataforma PC con la desarrollada en Java Card, teniendo presentes las diferencias existentes en sus respectivas arquitecturas, así como las características de programación de cada una de las plataformas.

8. Recomendar una conﬁguración de ECIES que asegure su resistencia a los diferentes tipos de ataques conocidos, comprobando si dicha conﬁguración es aplicable tanto a la plataforma PC como a Java Card.

Es importante aclarar que queda fuera del ámbito de la presente Tesis el estudio de la seguridad de las implementaciones ECC en Java Card para evitar ataques de canal lateral. La existencia de este tipo de ataques es bien conocida en la comunidad académica tanto en sus aspectos más generales [103, 145, 150, 151, 152], como de manera especíﬁca para implementaciones de curvas elípticas [30, 92, 142, 181]. Sin embargo, puesto que la implementación Java Card desarrollada en esta Tesis utiliza tarjetas inteligentes comerciales de las que no se ha podido obtener información sobre las soluciones implementadas para evitar este tipo de ataques, y dado que el equipamiento necesario (equipos láser y de implantación iónica, laboratorio de tratamientos químicos, etc.) para realizar este tipo de ataques es extremadamente costoso, los análisis de ataques de canal lateral para las tarjetas empleadas quedan reservados para organismos o instituciones dedicadas de forma preeminente a este tipo de actividades.

Metodología

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

Clasiﬁcación

El tema principal de la presente Tesis Doctoral, según la MSC (Mathematics Subject Classiﬁcation) 2010 de la AMS (American Mathematical Society) [13] es:

94A60 Cryptography

De acuerdo a la misma clasiﬁcación, a continuación se enumeran los identiﬁca- dores de los restantes temas asociados a esta Tesis, junto con la descripción proporcionada por la AMS.

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

Estructura

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

En el Capítulo 6 se presenta una implementación del esquema de cifrado ECIES para tarjetas Java Card, indicando las particularidades existentes en función de la versión Java Card implementada por las tarjetas inteligentes utilizadas en esta Tesis. De manera adicional, este capítulo incluye la descripción funcional de la aplicación desarrollada para la comunicación con las tarjetas inteligentes comerciales empleadas en la Tesis. El Capítulo 7 recoge las pruebas realizadas con las implementaciones de ECIES para PC y Java Card, utilizando diferentes combinaciones de parámetros y algoritmos en función de las posibilidades criptográﬁcas de cada una de las plataformas seleccionadas. A ﬁn de analizar los resultados de las pruebas, se ha incluido una descripción detallada de las características de las tarjetas inteligentes empleadas en dichas pruebas. Por último, el Capítulo 8 presenta las conclusiones derivadas del estudio e imple- mentación del esquema de cifrado ECIES y de los resultados obtenidos mediante las pruebas con las versiones desarrolladas para PC y Java Card. De manera adicional, se describen las aportaciones realizadas por esta Tesis, tanto en forma de artículos y presentaciones en congresos como de soluciones ideadas para evitar las distintas limitaciones detectadas. Por último, se incluyen las posibles líneas de trabajo que podrían seguirse como continuación de esta Tesis.

Notas de estilo

La presente Tesis Doctoral ha sido redactada utilizando el sistema de composi- ción de textos LATEX, empleando para ello la distribución MiKTeX 2.8 y el programa de edición WinEdt 5.5. Respecto a la conﬁguración y las decisiones de estilo en LATEX, se han consultado numerosas fuentes, aunque las principales han sido [153] para los aspectos generales de composición, y [203] para las características tipográﬁcas asociadas a la notación matemática. En la elaboración de la bibliografía, se han seguido principalmente los consejos sugeridos para la redacción de tesis doctorales de la Universidad Politécnica de Madrid [263], que se basan principalmente en las normas ISO 690 [110] y 690-2 [111] (sustituidas en 2010 por una nueva edición de ISO 690 [112]), así como en el documento equivalente UNE 50-104-94 de AENOR [12]. Para algunos aspectos puntuales se han consultado las recomendaciones de Juan Antonio Pérez Ortiz [217] (que a su vez recoge algunas de las indicaciones de Ramón Sol [251]). El objetivo ha sido componer una bibliografía adaptada en lo posible al están- dar ISO y que permitiera una correcta legibilidad. Algunas de las características principales del estilo utilizado son:

∙ Escritura del nombre de los autores incluyendo en primer lugar el apellido (o 16 Introducción

apellidos) en mayúscula y posteriormente la inicial (o iniciales) del nombre. En el caso de empresas o instituciones, se ha intentado mantener el mismo formato mediante la inclusión del nombre completo en mayúsculas.

∙ Separación de los nombres de los autores mediante el carácter punto y coma.

∙ En el caso de existencia de cuatro o más autores, inclusión únicamente del primer autor junto al término «et al.» que indica la existencia de autores adicionales.

∙ Utilización de letras mayúsculas en los títulos de las obras únicamente en la primera letra y en los casos necesarios, como por ejemplo los nombres propios (p. ej. Diﬃe-Hellman), los acrónimos (p. ej. RSA) o los nombres de algoritmos o funciones que normalmente se redacten en mayúscula (p. ej., Triple Data Encryption o Elliptic Curve Cryptography).

∙ Utilización del nombre de ciudades en su variante castellana en caso de existir (p. ej., Londres o Nueva York).

∙ Utilización de las abreviaturas habituales en la descripción de las característi- cas de las publicaciones periódicas (vol., num., pp., etc.).

∙ Inclusión de la versión del documento en el caso de estándares o de documentos electrónicos, empleando el término ver. como abreviatura.

∙ Utilización del término inédito para los documentos electrónicos elaborados por su autor que no hayan sido presentados a congresos o incluidos en libros o revistas especializadas.

∙ Empleo del nombre oﬁcial de las publicaciones periódicas sin abreviar.

∙ En el caso de las páginas web, inclusión del nombre de la compañía, organismo o individuo responsable del contenido, así como del título de la página.

∙ Inclusión del código asociado al estándar en las normas nacionales e internacionales.

∙ En las patentes, inclusión de los inventores tras el nombre de la empresa (o individuo) responsable y del título de la patente. Utilización de las fechas de solicitud y conﬁrmación de la patente, así como del código identiﬁcador de la patente y del país donde ha sido aprobada.

∙ Inclusión del enlace al documento citado en los casos en los que exista una copia en formato electrónico en internet, utilizando de manera preferente enlaces compatibles con el sistema DOI (Document Object Identiﬁer). La validez de los enlaces fue comprobada por última vez el 5 de noviembre de 2010. Introducción 17

A lo largo del texto, se interpretarán los siguientes términos como se indica a continuación [80]:

∙ Algoritmo: procedimiento que toma una serie de datos de entrada y genera como resultado un valor o conjunto de valores asociados a los datos de entrada.

∙ Criptograma: cadena binaria que contiene el mensaje cifrado y que es enviado al receptor por el usuario emisor. Tomado en sentido amplio, el criptograma incluye, además del mensaje cifrado, los elementos adicionales que posibiliten la recuperación del mensaje original (códigos de autenticación, claves públicas, etc.).

∙ Protocolo: algoritmo en el que de forma general intervienen distintos usuarios o entidades, y que se encuentra definido mediante una secuencia de pasos que especifican las acciones que deben ser completadas a fin de lograr el objetivo final.

∙ Usuario: persona o elemento inanimado (por ejemplo, un ordenador) que envía, recibe o manipula información.

Tanto la notación como los términos del glosario incluidos en esta Tesis han sido obtenidos a partir de las obras incluidas en la bibliografía.

Capítulo 1

Tarjetas inteligentes

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

1.1. Historia de las tarjetas inteligentes

Las tarjetas de plástico se empezaron a utilizar como método de identificación en Estados Unidos a partir de los años 50. La primera de estas tarjetas (Figura 1.1) fue utilizada por Diners Club [62], y permitía al portador de la tarjeta utilizarla para realizar pagos en un selecto grupo de restaurantes y hoteles que destacaban por su exclusividad. Poco después, Visa y MasterCard comenzaron a emitir igualmente tarjetas de plástico, lo que extendió su uso no sólo por Estados Unidos sino también en Europa y a continuación por el resto del mundo. Al principio, los mecanismos de seguridad implementados en estas tarjetas de plástico eran bastante simples (impresiones gráficas, firma del cliente, etc.), por lo que con el paso del tiempo fue necesario mejorar su nivel de seguridad. Esta necesidad, junto con la reducción de costes en el proceso de generación de las tarjetas, introdujo el uso de la banda magnética (Figura 1.2). Esta banda permitía grabar

19 20 1. Tarjetas inteligentes

Figura 1.1: Diners Club, la primera tarjeta de crédito del mundo datos que pudieran ser leídos por los lectores apropiados, lo que inicialmente estaba al alcance únicamente de los usuarios legítimos del sistema. Sin embargo, con el paso del tiempo la capacidad de leer y modiﬁcar el contenido de la banda magnética se hizo accesible a colectivos al margen de la ley, lo que provocó una nueva evolución en las medidas de seguridad. Esta evolución tuvo lugar en los años 70 con la introducción de los microprocesadores para tarjetas.

Figura 1.2: Tarjeta con banda magnética

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

∙ Tarjetas de identiﬁcación de ciudadanos (por ejemplo, DNIe de España a partir de 2006 [176], Figura 1.3).

Figura 1.3: Prototipo de D.N.I. electrónico de España

∙ Sistema de telefonía móvil digital GSM y UMTS (Universal Mobile Telecom- munication System), donde toma el papel de módulo de identiﬁcación del usuario con las denominaciones SIM (Subscriber Identity Module) y UICC (Universal Integrated Circuit Card), respectivamente (Figura 1.4).

Figura 1.4: Tarjeta SIM de Telefónica movistar

∙ Aplicaciones bancarias como el monedero electrónico, de manera que la tarjeta puede llegar a contener valor monetario en sí misma (por ejemplo, Dinamarca desde 1992 [74], Figura 1.5).

Figura 1.5: Tarjeta monedero Danmont de la serie emitida en 1994 22 1. Tarjetas inteligentes

∙ Sanidad, donde funciona como un archivo de los aspectos más relevantes del historial médico de un paciente, realizando la identiﬁcación del mismo ante los sistemas centrales del sistema de sanidad (por ejemplo, Alemania desde 2006 [246], Figura 1.6).

Figura 1.6: Ejemplo de tarjeta de salud de la República Federal Alemana

∙ Control de acceso a ediﬁcios, con sistemas avanzados que pueden llegar a incluir elementos biométricos. En ellos, la tarjeta inteligente almacena todos los datos necesarios para autenticar a una determinada persona (por ejemplo, los datos de la huella digitalizada, como se muestra en la Figura 1.7).

Figura 1.7: Control de acceso con tarjeta inteligente sin contactos

1.2. ¿Qué es una tarjeta inteligente?

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

Figura 1.8: Aspecto externo de una tarjeta inteligente volátiles utilizados durante una determinada sesión de trabajo, una memoria no volátil normalmente de tipo EEPROM (Electrically Erasable and Programable Read Only Memory) donde se almacenan los datos relativos a las aplicaciones instaladas en la tarjeta, un procesador que ejecuta las instrucciones de acuerdo al sistema operativo, buses internos para la comunicación de todos los elementos mencionados y buses externos para la comunicación de la tarjeta inteligente con el dispositivo lector a través de los contactos [65].

Figura 1.9: Diagrama de bloques de una tarjeta inteligente

Los datos almacenados en la memoria EEPROM sólo son accesibles a través de los comandos implementados por el sistema operativo, el cual controla que el usuario que intenta acceder tenga los permisos necesarios para hacerlo. Gracias a este control de la ejecución de cada comando, es posible garantizar niveles elevados de protección de los datos frente a ataques externos. Otros tipos de memoria no volátil menos utilizados son Flash EEPROM, EPROM (Erasable Programmable Read Only Memory) o FRAM (Ferroelectric Random-Access Memory). 24 1. Tarjetas inteligentes

Por otra parte, el chip que incluyen las tarjetas inteligentes se encapsula de tal forma que quede igualmente protegido contra accesos mediante técnicas electromag- néticas que no precisen contacto físico con la tarjeta. La tecnología de fabricación de estos chips ha ido evolucionando con el paso del tiempo, pasando por tecnologías CMOS (Complementary Metal-Oxide Semiconductor) de 0.8 m, 0.5 m, 0.35 m y 0.13 m actualmente, lo que permite conseguir una mayor densidad de memoria en el espacio destinado al chip. A este respecto, la cantidad en micras de la tecnología de fabricación hace referencia a la mínima resolución de la maquinaria responsable de integrar sus circuitos mediante técnicas de litografía, ya que la correspondencia entre tecnología de integración y distancia de integración dejó de veriﬁcarse a partir de la tecnología de 0.25 m [261]. En cuanto a la arquitectura de los microprocesadores, ésta puede variar desde los 8 bits en las tarjetas más básicas hasta los 32 bits utilizados para las aplicaciones más complejas. Para la fabricación de las tarjetas inteligentes se parte de una oblea de silicio que contiene múltiples ejemplares del chip. Una vez identiﬁcados y aislados uno a uno los chips de la oblea, se pegan y se sueldan sobre los contactos. Se añade entonces una resina protectora que aísla al chip de la humedad, formando el elemento denominado “micromódulo”. El plástico, fabricado de forma independiente, es rebajado en la posición donde se alojará el chip, de forma que dé cabida al mismo bajo los contactos sin dañarse. Utilizando técnicas de pegado mediante combinación de calor y presión, el micro- módulo se coloca en el hueco formado en el plástico, quedando por tanto el chip totalmente encapsulado bajo los contactos, de acuerdo a la Figura 1.10.

Figura 1.10: Encapsulado del chip bajo los contactos 1.3. Tipos de tarjetas inteligentes 25

1.3. Tipos de tarjetas inteligentes

1.3.1. Tarjetas de memoria

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

1.3.2. Tarjetas con microprocesador

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

1.3.2.1. Tarjetas con contactos

Las tarjetas con contactos representan el tipo de tarjeta más extendido en la actualidad, gracias sobre todo a su presencia en los teléfonos móviles GSM y UMTS, y se encuentran deﬁnidas en las normas ISO/IEC 7816 (ver §1.5.1). Para que una tarjeta con contactos funcione correctamente, debe ser introducida en un lector de manera que exista contacto físico entre la tarjeta y el lector. Aunque los estándares deﬁnen ocho contactos, dependiendo del entorno en que se vaya a utilizar la tarjeta inteligente es posible que no se empleen todos. Por ejemplo, las tarjetas SIM/UICC actuales utilizan únicamente cinco de los ocho contactos disponibles, aunque existen planes para la utilización de los tres contactos restantes. 26 1. Tarjetas inteligentes

En la Figura 1.11 se pueden observar de forma gráﬁca los diferentes contactos de una tarjeta inteligente tal como se encuentran estandarizados en la norma ISO/IEC 7816-2 [114].

Figura 1.11: Contactos de una tarjeta inteligente

La función de cada contacto es la siguiente:

∙ Vcc: proporciona alimentación al chip. Los voltajes admisibles son 1.8 V, 3 V ó 5 V, con una desviación máxima del 10 %.

∙ RST: este contacto se utiliza para resetear el microprocesador, procedimiento denominado warm reset. En comparación, el procedimiento cold reset consiste en detener la alimentación del chip para reanudarla posteriormente.

∙ CLK: puesto que las tarjetas inteligentes no poseen un generador interno de la señal de reloj, necesitan recibir a través de este contacto la señal externa de reloj.

∙ GND: este contacto se utiliza para el voltaje de referencia (valor de cero vol- tios).

∙ Vpp: el contacto Vpp es opcional y sólo se utiliza para programar la memoria EEPROM en tarjetas antiguas.

∙ I/O: este contacto permite la transmisión de datos entre la tarjeta y el lector en modo half-duplex, de manera que la información sólo puede ser transmitida en un sentido en cada momento.

Actualmente se encuentra en proceso de estandarización el futuro uso de los contactos Vpp y RFU para la implementación del protocolo USB (Universal Serial Bus) de alta velocidad entre el lector y la tarjeta, para lo que se necesitan dos contactos, así como para la comunicación entre la tarjeta y la antena externa que permita su uso en entornos contactless. 1.3. Tipos de tarjetas inteligentes 27

1.3.2.2. Tarjetas sin contactos

En comparación con las tarjetas del apartado anterior, las tarjetas sin contactos no necesitan contacto físico con otro elemento, ya que se comunican con el lector mediante ondas electromagnéticas de manera similar a la utilizada en la tecnología RFID (Radio Frequency Identiﬁcation) [40]. La distancia entre la tarjeta y el lector depende del tipo de tarjeta, pero en general varía desde unos pocos centímetros hasta un metro. La Figura 1.12 muestra el diagrama de una tarjeta sin contactos, así como del lector necesario para acceder a la información de la tarjeta.

Figura 1.12: Esquema de una tarjeta inteligente sin contactos

El estándar de tarjetas sin contacto más extendido es el ISO/IEC 14443 (ver §1.5.2), el cual emplea técnicas de acoplamiento magnético con una frecuencia de 13.56 MHz y tiene un alcance de hasta 10 cm. Si a una tarjeta de este tipo se le añaden los contactos como vía complementaria de comunicación, entonces se trata de una tarjeta de interfaz dual. La principal aplicación de las tarjetas contactless son el pago de pequeñas cantidades (tarjetas monedero) y el control de acceso (ediﬁcios, transporte público, etc.), donde la rapidez y el carácter local de las transacciones son las características principales. De manera más general, sin el requisito de adoptar la forma de una tarjeta inteligente, la tecnología sin contactos puede encontrarse en multitud de herramientas de logística y seguridad, como por ejemplo los nuevos pasaportes. De hecho, desde agosto de 2006 todos los pasaportes españoles que se expiden corresponden al 28 1. Tarjetas inteligentes denominado pasaporte electrónico (pasaporte-e), el cual incorpora un chip embebido en su portada posterior que incluye información sobre su titular [177].

1.3.3. Tarjetas con coprocesador

Las tarjetas inteligentes utilizadas en entornos de seguridad normalmente incluyen un coprocesador de apoyo al procesador principal. Los coprocesadores son circuitos integrados especializados en los cálculos de aritmética modular y la gestión de enteros de gran tamaño, lo que permite liberar de este trabajo al procesador principal. El uso de coprocesadores permite que ciertas operaciones criptográﬁcas, que en otras tarjetas tardarían varios minutos en realizarse, puedan ser completadas en pocos segundos. La inclusión de coprocesadores aumenta el precio ﬁnal de las tarjetas inteligentes, motivo por el cual en algunos entornos (como el de las telecomunicaciones) su presencia sea actualmente minoritaria.

1.4. Propiedades físicas y eléctricas

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

Figura 1.13: Formato de tarjeta ID-1

Figura 1.14: Formato de tarjeta ID-00

Figura 1.15: Formato de tarjeta ID-000 (alternativamente plug-in o mini-SIM) 30 1. Tarjetas inteligentes

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 químicos.

∙ PC (Policarbonato): presenta un rango de uso desde -100∘C a +135∘C, con un punto de fusión cercano a 250∘C.

∙ PET (Polietileno Tereftalato): se trata de un plástico con un alto grado de cristalinidad muy utilizado en envases de bebidas y textiles como sustituto del PVC.

En lo relativo a sus características eléctricas, tal como se ha anticipado 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 gráﬁca tanto el voltaje asociado a cada clase como la frecuencia de la señal externa de reloj aplicable a las tarjetas con contactos, y que debe situarse entre 1 y 20 MHz en los tres casos (excepto durante el proceso de inicio, donde hasta que se establezca la frecuencia de trabajo ﬁnal, ésta debe- rá situarse obligatoriamente entre 1 y 5 MHz). Como aclaración, la frecuencia de 1.5. Estándares 31

Figura 1.17: Diagrama de voltajes admisibles trabajo del procesador no siempre coincide con la frecuenta suministrada por el dispositivo lector, ya que las tarjetas pueden implementar divisores o multiplicadores para ajustar la frecuencia interna [226]. Para más información sobre las características físicas y lógicas de las tarjetas inteligentes, se recomienda consultar el libro de Rankl y Eﬃng [226].

1.5. Estándares

1.5.1. La norma ISO/IEC 7816

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

∙ Parte 1 [113]: especiﬁca las características físicas de las tarjetas, en cuanto al tamaño del plástico, su grosor, etc.

∙ Parte 2 [114]: engloba todos los elementos que deﬁnen las dimensiones y la lo- 32 1. Tarjetas inteligentes

calización de los contactos. Igualmente, especiﬁca la función que debe cumplir cada uno de estos contactos.

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

∙ Parte 4 [116]: especifica los comandos para el intercambio de información 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 estándar también define la estructura lógica con la que la memoria se divide en ficheros y los tipos de datos que pueden ser almacenados en las tarjetas.

∙ Parte 5 [117]: deﬁne la estructura de los sistemas de numeración utilizados en el entorno de las tarjetas inteligentes, así como el procedimiento de registro para identiﬁcadores de aplicación.

∙ Parte 6 [118]: especiﬁca los elementos de datos utilizados (nombre, descripción, formato, codiﬁcación y diseño), así como los medios de recuperación de dichos elementos.

∙ Parte 7 [119]: dado que la tarjeta inteligente puede utilizarse como dispositivo de almacenamiento de datos, en esta parte de la norma se especiﬁcan los comandos utilizados para la gestión de las estructuras de bases de datos y el lenguaje SCQL (Structured Card Query Language).

∙ Parte 8 [120]: los comandos relacionados con la seguridad son deﬁnidos en esta parte de la norma (siendo complementarios a los deﬁnidos en la parte 7816-4). Se incluyen protocolos para que la tarjeta preste servicios de seguridad (como algoritmos de cifrado) y métodos para proporcionar seguridad en la interfaz entre la tarjeta y el exterior.

∙ Parte 9 [121]: define los comandos para la gestión de ficheros (por ejemplo, la creación y borrado de ficheros). Estos comandos abarcan todo el ciclo de vida de los ficheros en la tarjeta. En un anexo de esta norma se muestra cómo controlar la carga segura de datos en las tarjetas.

∙ Parte 10 [122]: este documento especiﬁca las señales eléctricas y el ATR (Ans- wer to Reset) de las tarjetas síncronas.

∙ Parte 11 [123]: especiﬁca el uso de los comandos y de los datos relacionados con la veriﬁcación de la identidad de una persona a través de métodos biométricos. 1.5. Estándares 33

Mientras que los comandos utilizados se deﬁnen a su vez en la norma ISO/IEC 7816-4, los datos se deﬁnen parcialmente en esta norma y están importados de la norma ISO/IEC 19785-1 [138].

∙ Parte 12 [124]: deﬁne las condiciones de funcionamiento de una tarjeta inteligente través de la interfaz USB. A estas tarjetas se las denomina USB-ICC (Integrated Circuit Card).

∙ Parte 13 [125]: especiﬁca los comandos para la gestión de aplicaciones en entornos multiaplicación. Estos comandos cubren el ciclo de vida completo de las aplicaciones en una tarjeta inteligente.

∙ Parte 14: este documento no existe, siendo la parte 14 una referencia sin uso práctico.

∙ Parte 15 [126]: define una aplicación que contiene información sobre la funcionalidad criptográfica. Además, especifica una sintaxis común en ASN.1 (Abs- tract Syntax Notation One) y tanto el formato de codificación de la información como los mecanismos para compartir esta información.

1.5.2. La norma ISO/IEC 14443

El conjunto de especificaciones ISO/IEC 14443 define define dos tipos de tarjetas sin contactos (Tipo A y Tipo B, ambas operando a 13.56 MHz), cuyas principales diferencias son el tipo de modulación empleado y los detalles del protocolo de ini- cialización. Las partes que constituyen esta norma son:

∙ Parte 1 [132]: especiﬁca las características físicas de las tarjetas.

∙ Parte 2 [133]: deﬁne los campos magnéticos que deben utilizarse tanto para proporcionar potencia a la tarjeta como para establecer la comunicación entre lector y tarjeta.

∙ Parte 3 [134]: especiﬁca el protocolo y los comandos para establecer la comu- nicación entre un lector y varias tarjetas, incluyendo las técnicas para evitar colisiones en la transmisión.

∙ Parte 4 [135]: incluye los detalles del protocolo half-duplex de bloques (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 Telecommu- nications Standards Institute) y transferida posteriormente a la organización 3GPP 34 1. Tarjetas inteligentes

(3rd Generation Partnership Project) [1,6], define la interfaz entre la tarjeta SIM y el teléfono móvil durante la fase de operación en red del sistema GSM, así como la organización interna de la información en la tarjeta. Mediante esta especificación, se asegura la correcta interoperabilidad entre la tarjeta y el terminal, independientemente de los fabricantes de ambos dispositivos. Entre otros detalles, la norma TS 11.11 especifica:

∙ Los requisitos físicos a cumplir por la tarjeta SIM en cuanto a señales eléctricas y protocolos de transmisión. ∙ El modelo lógico a utilizar como base para el diseño de la estructura de ﬁcheros de la tarjeta SIM. ∙ Las funciones de seguridad, haciendo hincapié en el proceso de autenticación del usuario frente a la red. ∙ Los comandos y sus respectivas respuestas a transmitir entre el teléfono móvil y la tarjeta SIM. ∙ Los contenidos en detalle de los ﬁcheros para su utilización en redes GSM.

Dentro de las características físicas se definen dos formatos, conocidos como ID-1 (tamaño tarjeta de crédito) y plug-in o mini-SIM (formato de inferior tamaño para poder utilizar la tarjeta dentro de los teléfonos móviles, equivalente al formato ID- 000 del estándar ISO/IEC 7816). En ambos casos, las características físicas deben cumplir los requisitos expresados en la normas ISO 7816-1 y 7816-2, a menos que se especifique lo contrario. A nivel eléctrico se mantienen los requisitos de la norma 7816-3, aunque en este caso el único protocolo obligatorio es T=0, el protocolo semi-dúplex asíncrono y orientado a byte [97]. Por último, respecto a la estructura de ficheros, éstos se organizan de forma jerárquica. Existen tres tipos de ficheros elementales: transparentes (secuencia de bytes sin organización interna), lineales con longitud de registro fija (secuencia de registros todos con la misma longitud) y cíclicos con longitud de registro fija (similares a los lineales, con la diferencia de que los registros se sobrescriben por orden de antigüedad). Por su parte, la norma TS 11.14, igualmente desarrollada por ETSI y transferida a 3GPP [2,7], define la interfaz entre la tarjeta SIM y el terminal móvil para la comunicación con aplicaciones SIM Application Toolkit (en adelante STK) y la realización de servicios avanzados. STK proporciona mecanismos que permiten a las aplicaciones residentes en la tarjeta SIM interactuar y operar con cualquier teléfono móvil que implemente dichos mecanismos y sus comandos asociados. Entre los distintos procedimientos incluidos pueden destacarse los siguientes: 1.6. Sistemas operativos de tarjetas inteligentes 35

∙ Proﬁle Download: mecanismo por el cual el terminal informa a la SIM de sus características como parte del proceso de inicialización de la SIM, y que permite a las aplicaciones STK conocer exactamente qué servicios del terminal podrán utilizar.

∙ Proactive SIM : procedimiento por el cual la tarjeta SIM puede iniciar acciones que deben ser ejecutadas por el terminal. Este sistema se ideó como una forma de superar la limitación del protocolo T=0, donde la comunicación sólo puede ser iniciada por el terminal.

∙ Data Download: mecanismo por el que un servidor puede enviar datos a una aplicación de la tarjeta SIM, utilizando distintos servicios portadores como los mensajes cortos SMS (Short Message Service) o la difusión CBS (Cell Broadcast Service).

La norma TS 11.14, de aplicación en las tarjetas SIM de la telefonía GSM, evolucionó hasta convertirse en la norma TS 31.111 [5] al aplicarse a las tarjetas UICC de UMTS. De manera equivalente, la norma TS 11.11, que tuvo su origen en ETSI para entornos GSM, se dividió en las normas TS 31.101 [3] y TS 31.102 [4] en su deﬁnición para entornos UMTS.

1.5.4. Las normas Global Platform

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

1.6. Sistemas operativos de tarjetas inteligentes

En el mundo de las tarjetas inteligentes existen dos tipos de sistemas operativos: los cerrados o propietarios y los abiertos. La principal diferencia consiste en que 36 1. Tarjetas inteligentes

Figura 1.18: Arquitectura Global Platform

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

1.6.1. Tarjetas Java Card

Puesto que el lenguaje de programación Java es objeto de un estudio detallado en el Capítulo 3, de momento únicamente se mencionará el hecho de que Java Card es actualmente el sistema operativo abierto de mayor difusión en los principales entornos comerciales de tarjetas inteligentes [210]. La Figura 1.19 muestra la arquitectura básica del sistema Java Card. 1.6. Sistemas operativos de tarjetas inteligentes 37

Figura 1.19: Arquitectura Java Card

1.6.2. Tarjetas MULTOS

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

1.6.3. Tarjetas Windows for Smart Cards

En 1998 Microsoft anunció su sistema operativo Windows for Smart Cards (WSC), que pretendía convertirse en una alternativa a Java Card. Sin embargo, pocos años después Microsoft canceló el proyecto debido a la escasa acogida que había tenido este sistema operativo, principalmente debido a que sus competidores Java Card y MULTOS ya contaban para entonces con una base lo suﬁcientemente sólida de clientes en sus respectivas industrias. WSC era un sistema operativo multiaplicación que permitía el desarrollo de aplicaciones en los lenguajes C y Basic utilizando las herramientas de desarrollo 38 1. Tarjetas inteligentes

Figura 1.20: Arquitectura MULTOS propias de Microsoft.

1.7. Arquitecturas de acceso a las tarjetas inteligentes desde PC

1.7.1. Arquitectura OpenCard Framework

El término OpenCard Framework (OCF) hace referencia a un estándar desarrollado por un consorcio industrial (entre cuyos miembros ﬁguraban mayoritariamente fabricantes de tarjetas inteligentes, ver Figura 1.21) que proporciona una arquitectura interoperable para la comunicación con dispositivos lectores y tarjetas inteligentes disponible en varias plataformas software y hardware. Se trata, por tanto, de un es- tándar abierto que incluye un conjunto de API (Application Programming Interface) para posibilitar el desarrollo de aplicaciones mediante la programación en el lenguaje Java. OCF está diseñado para funcionar en cualquier plataforma Java, como por 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 versión Java 1.1. La arquitectura OCF [100] se compone principalmente de tres elementos:

∙ La capa CardTerminal: proporciona acceso a las tarjetas y a los lectores físicos para los que los fabricantes han creado los controladores apropiados. También incluye las API para los terminales PS/SC soportados. Este método garantiza la compatibilidad con lectores existentes y futuros. 1.7. Arquitecturas de acceso a las tarjetas inteligentes desde PC 39

Figura 1.21: Consorcio OpenCard

∙ La capa CardService: OCF representa las funciones asociadas a las tarjetas inteligentes a través de card services. Cada servicio deﬁne una interfaz de alto nivel que puede emplearse para acceder a determinadas funciones particulares, siendo el ejemplo más representativo FileAccessCardService para la gestión de los ﬁcheros.

∙ El componente ApplicationManagement: se encarga de localizar, seleccionar, instalar, desinstalar, bloquear y desbloquear aplicaciones almacenadas en una determinada tarjeta, eliminando el problema de la dependencia del proveedor de tarjetas.

La Figura 1.22 presenta un esquema que muestra la interrelación entre los 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 aplicación externa a la tarjeta, para lo que se emplea un lector de tarjetas. La aplicación envía un comando CommandAPDU a la tarjeta pasándolo al driver del lector, quien a su vez lo reenvía a la tarjeta. Como respuesta, la tarjeta envía un comando ResponseAPDU que el driver entrega a la aplicación. Las funciones de una tarjeta están determinadas por el conjunto de APDU que es capaz de interpretar. A pesar de los estándares existentes, el rango de comandos que entiende cada tarjeta depende en cierta medida del fabricante en cuestión. De igual manera, cada lector de tarjetas tiene distintas funcionalidades, desde el lector más simple con un único slot o ranura a los más complejos que incluyen accesorios de identiﬁcación biométrica. El problema de nuevo es la inexistencia de un único driver 40 1. Tarjetas inteligentes

Figura 1.22: Elementos de la arquitectura OCF para acceder a los servicios del lector de tarjetas. Sin embargo, gracias a estándares como OCF este problema queda parcialmente solucionado, al disponer de un canal por el que es posible enviar cualquier APDU independientemente del dispositivo lector y de la tarjeta inteligente empleados (siempre que el lector sea compatible con la arquitectura OCF). El OpenCard Consortium se disolvió tras la publicación de su versión 1.2, quedando su tecnología obsoleta tras la aparición del API Java Smartcard I/O [211], aunque todavía puede encontrarse información en forma de proyectos evolucionados a partir de OCF como Open Smart Card Development Platform (OpenSCDP) [39] o de repositorios de la información original en Sourceforge [252].

1.7.2. Arquitectura PC/SC

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

1.8. Comunicación con la tarjeta inteligente

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

Figura 1.23: Elementos de la arquitectura PC/SC 1.8. Comunicación con la tarjeta inteligente 43 respuesta de la aplicación para su envío al lector de tarjetas (y con ello, a la aplica- ción que se comunica con el propio lector, ya sea un programa en un ordenador, el sistema operativo de un teléfono móvil, etc.).

Figura 1.24: Modelo de comunicación con la tarjeta inteligente

La comunicación entre el lector y la tarjeta se basa normalmente en el protocolo T=0 (orientado a byte) o T=1 (orientado a bloque). Otros protocolos alternativos como T=USB o T=RF también pueden ser utilizados, aunque su uso se encuentra mucho menos extendido.

1.8.1. APDU de tipo comando

La estructura de un comando APDU viene deﬁnida 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 1. Tarjetas inteligentes

Un comando APDU consta de una cabecera y opcionalmente de un cuerpo, siendo sus elementos los siguientes:

∙ CLA (1 byte): este campo obligatorio identiﬁca la clase de comando. La espe- ciﬁcación ISO/IEC 7816-4 incluye los valores CLA válidos para su utilización, tal como aparecen en el Cuadro 1.1.

CLA Tipo de instrucción 0x0n, 0x1n Instrucciones estándar 7816-4 0x20 - 0x7F Reservado 0x8n, 0x9n Instrucciones 7816-4 específicas para aplicaciones 0xAn Instrucciones específicas de aplicación o fabricante 0xB0 - 0xCF Instrucciones específicas de aplicación o fabricante 0xD0 - FE Instrucciones específicas de aplicación o fabricante 0xFF Reservado para selección de tipo de protocolo

Cuadro 1.1: Valores del byte CLA permitidos

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

Si se utiliza el protocolo T=0, dependiendo de la presencia de datos en el comando, y de si es necesaria una respuesta, existen cuatro variantes del comando 1.8. Comunicación con la tarjeta inteligente 45

INS Nombre de la instrucción 0E Erase Binary 20 Verify 70 Manage Channel 82 External Authenticate 84 Get Challenge 88 Internal Authenticate A4 Select File B0 Read Binary B2 Read Record C0 Get Response C2 Envelope CA Get Data D0 Write Binary D2 Write Record D6 Update Binary DA Put Data DC Update Record E2 Append Record

Cuadro 1.2: Valores del byte CLA permitidos

APDU, tal como puede comprobarse en la Figura 1.26. De forma habitual, las aplicaciones utilizan varios comandos APDU con distintas estructuras de datos durante su ejecución.

Figura 1.26: Posibles estructuras de un comando APDU 46 1. Tarjetas inteligentes

1.8.2. APDU de tipo respuesta

El formato de una respuesta APDU es mucho más simple, tal como se muestra en la Figura 1.27.

Figura 1.27: APDU de tipo respuesta

Al igual que los comandos, las APDU de tipo respuesta incluyen campos tanto obligatorios como opcionales:

∙ Datos (longitud variable, dependiente del campo Le del comando APDU, ca- rácter opcional): este campo contiene los datos devueltos por la aplicación de la tarjeta.

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

∙ SW2 (1 byte, obligatorio): este campo constituye el segundo byte de estado, que proporciona información adicional a la ofrecida por el primer byte de estado.

Los valores posibles para los bytes de estado están definidos en la especificación ISO 7816-4. La Figura 1.28 muestra de forma gráfica la clasificación de los posibles bytes de estado. 1.8. Comunicación con la tarjeta inteligente 47

Figura 1.28: Posibles códigos de respuesta

Capítulo 2

Criptografía de clave pública basada en curvas elípticas

Resumen del capítulo En este capítulo se exponen las principales características de la cripto- grafía de clave pública y de la basada en curvas elípticas, comenzando por la presentación de conceptos y definiciones de los algoritmos cripto- gráficos de clave pública más extendidos hasta la fecha. A continuación, se describen las ecuaciones generales que definen las curvas elípticas, la particularización de la teoría de curvas elípticas para cuerpos finitos, las aplicaciones más importantes de las curvas elípticas en criptografía y los estándares relacionados con cada una de estas aplicaciones. Este capítulo concluye con un resumen de las principales patentes existentes en ECC.

2.1. Introducción

Criptología es el nombre genérico que engloba dos disciplinas opuestas y a la vez complementarias: criptografía y criptoanálisis. La criptografía se ocupa del diseño de procedimientos para el cifrado y descifrado de la información, mientras que el criptoanálisis se encarga del estudio de los métodos para obtener la información original sin tener acceso a los datos secretos requeridos en el funcionamiento normal de los algoritmos criptográﬁcos. Ambas disciplinas se han desarrollado habitualmente de forma paralela, puesto que cualquier método de cifrado siempre lleva aparejada su correspondiente técnica de criptoanálisis [78].

49 50 2. Criptografía de clave pública basada en curvas elípticas

La criptografía como medio para proteger la información es un arte tan antiguo como la propia escritura. Hasta el siglo pasado, la única técnica utilizada era la criptografía de clave simétrica, donde la clave de cifrado coincide con la de 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 simétrico, principalmente su eficiencia y robustez, la necesidad de disponer de una clave para cada par de usuarios representa una gran limitación, siendo un elemento especialmente crítico en los sistemas informáticos distribuidos. Frente a este problema, la solución consiste en utilizar criptografía de clave pública o asimétrica, donde por su naturaleza cada usuario dispone de una clave privada y una clave pública, de manera que precisamente esta clave pública pueda ser distribuida sin que ello represente un riesgo para la integridad del sistema. La finalidad de la criptografía de clave pública es múltiple, y puede definirse mediante las siguientes características:

∙ Conﬁdencialidad o privacidad: únicamente los usuarios autorizados deben ser capaces de acceder a la información que se desea proteger.

∙ Integridad: capacidad de veriﬁcación de que un mensaje no ha sido alterado en su transmisión desde el emisor hasta el receptor.

∙ Autenticación: el destinatario de un mensaje debe poder identiﬁcar sin ninguna duda al emisor del mensaje.

∙ No repudio: un emisor no debe ser capaz de negar la autoría de un mensaje.

Desde que en 1976 Diﬃe y Hellman [61] introdujeron el concepto de criptografía de clave pública, esta rama de la criptografía ha tenido una vertiginosa evolución, lo que ha generado la aparición tanto de algoritmos criptográﬁcos como de técnicas de criptoanálisis de una creciente complejidad. Tal como se adelantó en la Introduc- ción, los problemas matemáticos utilizados actualmente por los criptosistemas más extendidos son:

∙ Factorización de enteros (IFP) Dado un número entero positivo n, el problema de la factorización de enteros, denominado IFP (Integer Factorization Problem), consiste en determinar su factorización en números primos [172]. Es decir, expresar el número n de la m1 m2 mk forma n = p1 p2 ⋅ ⋅ ⋅ pk , donde los valores pi representan números primos distintos, cada uno con orden de multiplicidad mi ≥ 1. ∙ Logaritmo discreto (DLP)

Dado el conjunto ℤp de los números enteros módulo un número primo p, un ∗ ∗ generador del grupo multiplicativo ℤp y un elemento ∈ ℤp, el problema del 2.2. Aplicaciones de la criptografía de clave pública 51

logaritmo discreto, denominado DLP (Discrete Logarithm Problem), consiste en encontrar el entero x que cumpla la condición x ≡ (mod p) siendo 0 ≤ x ≤ p − 2 [172].

∙ Logaritmo discreto en curvas elípticas (ECDLP)

Dada una curva elíptica definida sobre el cuerpo finito Fq (donde q es un número primo o una potencia de 2), un subgrupo de orden n de los puntos de la curva que sea finito y cíclico, un punto de la curva G que sea generador del subgrupo cíclico y un punto P perteneciente a dicho subgrupo, el problema del logaritmo discreto aplicado a una curva elíptica, denominado ECDLP (Elliptic Curve Discrete Logarithm Problem), consiste en encontrar el número entero k tal que P = k ⋅ G [99].

2.2. Aplicaciones de la criptografía de clave pública

En base a las características de conﬁdencialidad, integridad, autenticación y no repudio, es posible dividir las aplicaciones prácticas de la criptografía de clave pública en tres grandes grupos: establecimiento de clave, ﬁrma digital y cifrado/descifrado.

⎧  Establecimiento de clave  ⎨ Aplicaciones prácticas Firma digital   ⎩ Cifrado/descifrado

2.2.1. Establecimiento de clave

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

⎧ ⎨ Transporte de clave Establecimiento de clave ⎩ Acuerdo de clave 52 2. Criptografía de clave pública basada en curvas elípticas

En la práctica, existen más diferencias entre los esquemas de acuerdo de clave y los esquemas de transporte de clave. Por ejemplo, en los esquemas de acuerdo de clave se pueden utilizar pares de claves (pública y privada) de uso temporal, generadas a propósito para dicha comunicación, mientras que en los esquemas de transporte de clave, el usuario que inicia la comunicación debe conocer la clave pública permanente del otro usuario (o al menos, lo suficientemente permanente para que no haya sido sustituida por una clave pública diferente desde su última comunicación). Los esquemas de establecimiento de clave más extendidos en la actualidad son el Diffie-Hellman [61] y algunas de sus variantes como STS (Station-to-Station) [16] o ECDH (Elliptic Curve Diffie-Hellman) [147, 174]. En §2.6.8.1 se puede encontrar más información sobre el protocolo ECDH.

2.2.2. Firma digital

La firma digital tiene como objetivo cumplir los objetivos de integridad, auten- ticación y no repudio, de manera que una firma electrónica sea equivalente a una firma manuscrita en cualquier transacción [78, 172]. Desde el punto de vista técnico y de forma simplificada, una firma digital es el resultado de cifrar la salida obtenida mediante una función resumen de una determinada información, de manera que cualquier usuario pueda verificar la identidad de la persona que firmó los datos y garantizar que la información objeto de la comprobación no ha sido modificada desde su firma. Las firmas digitales pueden dividirse en dos grupos: con anexo y con recuperación del mensaje. En las firmas con anexo, es necesario disponer tanto de la firma digital como del mensaje original a fin de poder realizar la comprobación de la firma. Por el contrario, en las firmas digitales con recuperación del mensaje, el propio mensaje se extrae del contenido de la firma.

⎧ ⎨ Con anexo Firma digital ⎩ Con recuperación del mensaje

Los principales esquemas de ﬁrma digital utilizados actualmente son el basado en el criptosistema RSA [232] y los algoritmos DSA (Digital Signature Algorithm) [184] y ECDSA (Elliptic Curve Digital Signature Algorithm) [15, 184]. Se ofrece más información sobre el algoritmo ECDSA en §2.6.8.2. 2.2. Aplicaciones de la criptografía de clave pública 53

2.2.3. Cifrado/descifrado

Los criptosistemas de clave pública tienen como objetivo cifrar el contenido de la información a transmitir de manera que ésta sólo pueda ser descifrada por un usuario legítimo. Para ello, de forma genérica dichos usuarios deben seguir el siguiente procedimiento:

1. Preparación del sistema Como paso inicial, los usuarios deben acordar qué opciones (tipo de claves, algoritmos, etc.) van a utilizar a ﬁn de garantizar la conﬁdencialidad de la comunicación posterior.

2. Comprobaciones previas y obtención de claves Una vez decididas las claves asimétricas a utilizar, el usuario que enviará el mensaje cifrado debe conseguir la clave pública del usuario receptor del criptograma, comprobando a continuación la validez de dicha clave.

3. Cifrado Cada vez que el usuario emisor desee enviar un mensaje cifrado, deberá utilizar el esquema de cifrado previamente acordado, junto con la clave pública del usuario receptor, a ﬁn de componer el criptograma.

4. Descifrado Una vez recibido el criptograma, el usuario receptor utilizará el esquema de cifrado, junto con su clave privada, para descifrar el mensaje y así obtener la información original.

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

2.3. Seguridad en criptosistemas de clave pública

En el estudio de la seguridad de los criptosistemas, existen dos conceptos que son fundamentales y que representan las características que sería deseable encontrar en cualquier criptosistema: la seguridad semántica y la no maleabilidad [25, 27, 224]. Seguridad semántica fue un concepto establecido por Goldwasser y Micali [93] en 1982, y consiste en la incapacidad de un atacante para obtener información alguna sobre el texto sin cifrar m a partir del mensaje cifrado c y de la clave pública de cifrado. Goldwasser y Micali demostraron posteriormente [94] la equivalencia entre seguridad semántica y la propiedad de un mensaje de ser indistinguible (IND). Esta propiedad consiste en la incapacidad de un atacante para distinguir pares de mensajes cifrados entre sí a partir de la correspondiente información sin cifrar. Por lo tanto, la característica de ser indistinguible está relacionada con el concepto de privacidad. Por su parte, el concepto de no maleabilidad (NM) fue presentado por Dolev, Dwork y Naor [64] en 1991, representando la incapacidad de un atacante de, a partir de un mensaje cifrado c, obtener un mensaje cifrado diferente c′ tal que los respectivos mensajes en claro estén relacionados. Esta propiedad, tal como está expresada, está relacionada con la capacidad de un mensaje de ser manipulado. La resistencia de un criptosistema se puede interpretar en base al tipo de ataques que es capaz de soportar con éxito. A su vez, los posibles ataques se pueden clasiﬁcar según los métodos empleados y el material al que tenga acceso el atacante. En una primera clasiﬁcación, es posible diferenciar entre ataques pasivos y activos [172]:

∙ Ataques pasivos: un atacante pasivo es aquel que, teniendo acceso al canal por el que se comunican los usuarios legítimos, se limita a obtener información del canal, por lo que su objetivo principal es comprometer la conﬁdencialidad de la comunicación. ∙ Ataques activos: un atacante activo es aquel que, además de recuperar los criptogramas del canal de comunicación, trata de borrar, introducir o alterar de alguna forma las transmisiones realizadas por los participantes. El objetivo de este tipo de atacante es múltiple, ya que además de comprometer la conﬁ- dencialidad de los mensajes puede intentar alterar la integridad de los datos e incluso la autenticidad de los mensajes.

Dentro de los ataques pasivos, existen diferentes tipos que se diferencian en el tipo de información a disposición del atacante [172], de manera que en algunos casos se podrá suponer que el adversario cuenta con acceso a un oráculo, elemento que puede ser interpretado como una caja negra que se encarga de cifrar o descifrar mensajes elegidos por el atacante, pero sin revelar ningún tipo de información adicional. Por supuesto, estas máquinas ideales no existen en la práctica, pero a efectos de modelar 2.3. Seguridad en criptosistemas de clave pública 55 la seguridad de un criptosistema tienen un papel muy importante en la deﬁnición de los tipos de ataques y en la evaluación de la seguridad de los criptosistemas [172, 224]. Los principales tipos de ataques pasivos, en función de los recursos al alcance del atacante [172], son:

∙ Ataque con texto en claro conocido (Known Plaintext Attack o KPA): el 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 mínimo, 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 elección. Para ello, es posible suponer que el atacante hace uso de un oráculo de cifrado que puede utilizar durante un cierto tiempo, con la restricción de que en ningún caso el atacante podrá obtener del oráculo la clave de cifrado. El objetivo del ataque consiste de nuevo en determinar la clave de descifrado o, en su defecto, un algoritmo que le permita derivar el texto en claro de otros mensajes cifrados que no hayan sido generados por el atacante.

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

∙ Ataque con sólo texto cifrado (Ciphertext-Only Attack o COA): el atacante sólo tiene acceso a una colección de textos cifrados, y su objetivo consiste en obtener los mensajes en claro o, mejor aún, la clave de descifrado.

∙ Ataque con texto cifrado elegido (Chosen Ciphertext Attack o CCA): el atacante puede obtener los textos en claro correspondientes a un conjunto arbitrario de textos cifrados de su propia elección mediante el uso de un oráculo de descifrado. De nuevo, se supone imposible obtener del oráculo la clave de descifrado. El objetivo último del ataque en este caso consiste en obtener dicha clave de descifrado.

∙ Ataque adaptativo de texto cifrado elegido (Adaptive Chosen Ciphertext Attack o ACCA): equivalente al ataque de texto cifrado elegido, con la diferencia de que el atacante puede elegir los textos cifrados subsiguientes en base a la información obtenida de los procesos de descifrado anteriores. El objetivo en este tipo de ataque es igual que en los CCA. 56 2. Criptografía de clave pública basada en curvas elípticas

Puesto que tanto el esquema de cifrado como la clave pública de un usuario legítimo se consideran información pública y conocida, en los criptosistemas de clave pública siempre será posible desarrollar ataques de tipo CPA en los que el atacante seleccione el mensaje en claro a fin de obtener el correspondiente mensaje cifrado. De hecho, en estos criptosistemas no hay diferencia práctica entre los ataques de clase CPA y ACPA, ya que el atacante puede generar mensajes cifrados a su conveniencia sin ninguna dificultad. Es posible reducir aún más el número de tipos de ataques a considerar en criptosistemas de clave pública, ya que CPA y ACPA incluyen los ataques de tipo KPA, y de igual manera CCA y ACCA (denotados como CCA1 y CCA2 por algunos autores, por ejemplo en [27]) tienen un carácter más amplio que los ataques de clase COA, puesto que cualquier mensaje cifrado considerado en un ataque de tipo COA formaría parte del conjunto de mensajes cifrados utilizados en CCA y ACCA, pero no al contrario. Por lo tanto, se puede concluir que en criptografía de clave pública los tipos de ataques diferenciados a considerar son CPA, CCA y ACCA. Relacionando esta clasificación con los conceptos IND y NM expuestos anteriormente, es posible 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 A ⇒ B, tal como se demostró en [27].

Figura 2.1: Modelos de seguridad en criptosistemas de clave pública

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

2.4. Principales esquemas de cifrado y establecimien- to de clave

En los siguientes apartados se presenta un resumen de los principales algoritmos de cifrado y establecimiento de clave utilizados actualmente, donde u y U represen- 2.4. Principales esquemas de cifrado y establecimiento de clave 57 tan la clave privada y pública respectivamente del usuario U, el mensaje original sin cifrar se denotará por la letra m, la información cifrada será identiﬁcada como c, y el criptograma C incluye no solamente el mensaje cifrado sino también 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 C será completamente equivalente al mensaje cifrado c).

2.4.1. Establecimiento de clave Diﬃe-Hellman

2.4.1.1. Descripción

En su ya clásico 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 criptografía de clave pública. El sistema propuesto, conocido desde entonces como protocolo de establecimiento o acuerdo de clave de Diffie- Hellman, representa un mecanismo por el que dos usuarios intercambian pequeñas cantidades de información a través de un canal que habitualmente es considerado inseguro de manera que, al final del procedimiento, únicamente ellos conozcan la clave secreta compartida [61, 172]. Es importante tener en cuenta que el protocolo de acuerdo de clave Diffie- Hellman, tal como fue planteado por sus autores, no constituye un criptosistema, puesto que no lleva a cabo el cifrado y descifrado de información, sino que sólo permite el intercambio de pequeñas cantidades de información a fin de derivar una clave secreta. En su propuesta, Diffie y Hellman se limitaron a describir de forma general los conceptos de firma digital, cifrado asimétrico y establecimiento de clave, aunque sí incluyeron indicaciones para la implementación del esquema de acuerdo de clave. El protocolo Diffie-Hellman, recogido en el Algoritmo 2.1, presenta de manera ordenada los pasos que los usuarios participantes en el intercambio deben dar a fin de obtener una clave secreta común con la que poder cifrar toda la comunicación posterior [148]. Después de llevar a cabo los pasos anteriores, U y V conocen y comparten un ∗ elemento común del grupo ℤp y que es desconocido para cualquier otro usuario. Dicho elemento es el siguiente:

v u u v uv ∗ ( ) = ( ) = ∈ ℤp.

Si en el Algoritmo 2.1 los valores u y v son ﬁjos, y en lugar de generar los elementos u y v en cada transmisión dichos valores son obtenidos de un servidor de claves, nos encontramos ante una versión del protocolo de intercambio Diﬃe- 58 2. Criptografía de clave pública basada en curvas elípticas

Algoritmo 2.1 Establecimiento de clave Diﬃe-Hellman 1. Si U y V son los dos usuarios que participan en el protocolo, en primer lugar deben seleccionar y hacer público un número primo p y un generador ∗ ∗ i ∈ ℤp, donde ℤp = { : i = 1, . . . , p − 1} y 1 < < p − 1. 2. A continuación U debe generar un número entero aleatorio u, con 1 < u < u ∗ p − 1, calcular ∈ ℤp y transmitir este elemento a V. 3. De forma análoga, V tiene que generar un número aleatorio v, con 1 < v < v ∗ p − 1, calcular ∈ ℤp y transmitir el elemento calculado a U.

v v u ∗ 4. Tras recibir , U debe calcular el valor de ( ) ∈ ℤp. 5. De manera equivalente, una vez recibido el valor u, V debe proceder a u v ∗ calcular el valor de ( ) ∈ ℤp.

Hellman denominada protocolo de intercambio Diﬃe-Hellman con exponentes ﬁjos, y que en realidad es la descrita en [61].

2.4.1.2. Ejemplo

A continuación se incluye un sencillo ejemplo del protocolo de establecimiento de clave Diﬃe-Hellman:

1. Los usuarios U y V eligen públicamente el número primo p = 541 y el grupo ∗ ℤ541, cuyo orden es n = p − 1 = 540. Además, seleccionan un generador de ∗ dicho grupo, = 51 ∈ ℤ541. 2. A continuación, U genera un número aleatorio u = 301 y calcula

u (mod p) = 51301 (mod 541) ≡ 94 (mod 541) ,

transmitiendo el valor 94 a V.

3. Análogamente, V genera un número aleatorio v = 197, calcula

v (mod p) = 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

378u (mod p) = 378301 (mod 541) ≡ 113 (mod 541) . 2.4. Principales esquemas de cifrado y establecimiento de clave 59

5. Por otra parte, V recibe 94 y calcula

94v (mod p) = 94197 (mod 541) ≡ 113 (mod 541) .

Al ﬁnalizar el protocolo, tanto U como V comparten el dato

uv (mod 541) = 51301⋅197 (mod 541) ≡ 113 (mod 541) .

2.4.1.3. Seguridad

Este esquema de establecimiento de clave se basa en el DLP y en lo que se conoce como el problema Diffie-Hellman (Diffie-Hellman Problem o DHP). Una definición formal de este problema es la siguiente: dado un grupo G finito y cíclico, con generador , y unos elementos = x, = y ∈ G, el problema consiste en determinar el elemento del grupo dado por = x⋅y [144]. El DHP es, hoy por hoy, un problema muy difícil de resolver desde el punto de vista computacional. Resulta claro que si un atacante pudiera resolver el problema DLP, habría resuelto el DHP. En efecto, si dados los elementos G, n, y u, el atacante es capaz de determinar u en tiempo polinómico, podría usar este algoritmo para calcular u o v en el caso del problema Diffie-Hellman, y puesto que conocería los valores v y u obtenidos del canal inseguro, bastaría con determinar el valor del primero elevado a u o el del segundo elevado a v 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 poli- nómico. Por esta razón se suele expresar que la seguridad del esquema de acuerdo de clave Diffie-Hellman está basada en la seguridad del DLP. Existen numerosas técnicas de ataque del DLP, recopiladas por ejemplo en [172]. Entre las principales se pueden destacar los métodos baby-step giant-step [241], ro de Pollard (Pollard’s Rho) [222] o el ataque Pohlig-Hellman [219].

2.4.2. Criptosistema RSA

2.4.2.1. Descripción

En 1978, Ron Rivest, Adi Shamir y Leonard Adleman [229] propusieron una implementación práctica de los conceptos presentados anteriormente por Diffie y Hellman. Aprovechando la dificultad de factorizar números enteros muy grandes, describieron los pasos necesarios para cifrar y descifrar mensajes que previamente hubieran sido convertidos en cadenas numéricas. Su propuesta incluía detalles sobre cómo realizar las operaciones de cifrado y descifrado de forma eficiente, y cómo 60 2. Criptografía de clave pública basada en curvas elípticas calcular los parámetros que componen las claves públicas y privadas. El esquema de cifrado, tal como está descrito en [229], es independiente del tipo de mensaje, estando la información cifrada directamente con la clave pública V y no por una clave simétrica temporal. En 1983 les fue concedida la patente que solicitaron en 1977 [164], aunque en el año 2000 los autores dejaron sin efecto dicha patente para que el algoritmo RSA pudiera ser utilizado libremente. El protocolo RSA consta de tres partes [66, 232]:

1. Generación de las claves.

2. Cifrado del mensaje.

3. Descifrado del mensaje.

En los siguientes apartados se describen en detalle las fases mencionadas.

Generación de las claves

Cada usuario (lo que representa tanto al usuario U que desea enviar el mensaje m como al usuario V que recibe la información cifrada c, equivalente en este caso al criptosistema C) debe elegir su par de claves, pública y privada. Para ello es necesario completar los pasos del Algoritmo 2.2, descrito utilizando la notación del usuario V.

Algoritmo 2.2 Generación de claves RSA 1. Elegir dos números primos grandes p y q distintos pero de, aproximadamente, el mismo tamaño.

2. Calcular los valores n = p ⋅ q y (n) = (p − 1) ⋅ (q − 1), donde la función (n) es el indicador de Euler para el número n.

3. Elegir de forma aleatoria un entero positivo e, con 2 < e < (n), tal que mcd(e, (n)) = 1.

4. Calcular, mediante el algoritmo de Euclides extendido, el único entero que veriﬁca 1 < d < (n), de modo que e ⋅ d ≡ 1 (mod (n)).

5. Asignar como clave pública del usuario V el par V = (n, e), siendo su clave privada correspondiente v = d. Además del elemento d, también deben permanecer secretos los números p, q y (n).

A los valores e y d así obtenidos se les denomina exponente de cifrado y exponente de descifrado, respectivamente. Por su parte, el entero n se denomina módulo del criptosistema RSA. 2.4. Principales esquemas de cifrado y establecimiento de clave 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 pública de V, V = (nV , eV ), de un directorio público de claves.

2. Convertir el mensaje original m en el número entero m perteneciente al conjunto ∗ . ℤnV 3. Calcular el valor numérico c asociado al mensaje cifrado c mediante la ex- presión

eV c = m (mod nV ),

siendo enviado este valor a V.

Nótese que el factor de expansión del criptosistema RSA, es decir, el cociente entre la longitud del criptograma y el mensaje original, es exactamente 1, considerando que tanto el valor numérico del mensaje, m, como del criptograma, c, se codiﬁcan en formato binario utilizando ⌈log2 nV ⌉ bits.

Descifrado del mensaje

Una vez que el usuario V recibe el mensaje cifrado c, para recuperar el mensaje original m debe seguir las instrucciones del Algoritmo 2.4.

Algoritmo 2.4 Descifrado RSA

1. Obtener la clave privada v = dV . 2. Calcular el valor

dV eV dV eV dV c (mod nV ) = (m ) (mod nV ) = m (mod nV ) = m,

transformándolo a continuación en el mensaje m.

2.4.2.2. Ejemplo

A continuación se presenta un sencillo ejemplo de cifrado con RSA donde los parámetros empleados son pequeños para una mayor claridad del proceso. 62 2. Criptografía de clave pública basada en curvas elípticas

Generación de las claves

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 números primos de forma secreta, en este caso p = 383 y q = 521.

2. El siguiente paso consiste en multiplicar los valores p y q para obtener el módulo RSA n, determinando el indicador de Euler (n):

n = p ⋅ q = 383 ⋅ 521 = 199543,

(n) = (p − 1) (q − 1) = 382 ⋅ 520 = 198640.

3. A continuación, V debe seleccionar un exponente de cifrado dentro del rango 2 < e < 198640, tomando por ejemplo e = 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 dV = 132427. 5. Tras los pasos anteriores, V podrá dar a conocer su clave pública, V = (nV , eV ) = (199543, 3), manteniendo oculta tanto su clave privada, v = dV = 132427, así como los valores p = 383, q = 521 y (n) = 198640.

Cifrado del mensaje

Cuando el usuario U desee enviar un mensaje a V, por ejemplo el nombre del criptosistema, ‘RSA’, deberá seguir los pasos mencionados en §2.4.2.1:

1. U debe localizar y obtener la clave pública de V, V = (nV , eV ) = (199543, 3). 2. A continuación, U escribirá el mensaje a enviar como un número menor que n = 199543 y primo con él. Para ello, por ejemplo, se puede considerar la siguiente representación de letras mediante números, donde por simplicidad no se ha considerado la letra Ñ. 2.4. Principales esquemas de cifrado y establecimiento de clave 63

A 7→ 0,B 7→ 1, c 7→ 2,...,Y 7→ 24,Z 7→ 25.

Este sistema emplea la base 26 para representar cualquier palabra. De este modo, como se veriﬁca la desigualdad

263 = 17576 < n = 199543 < 456976 = 264,

cada mensaje parcial puede contener, como máximo, tres letras. En el ejemplo considerado se utilizarán las letras

R 7→ 17,S 7→ 18,A 7→ 0,

con lo que el mensaje es

m = RSA 7→ m = 17 ⋅ 262 + 18 ⋅ 26 + 0 = 11492 + 468 + 0 = 11960.

Antes de proceder al cifrado, U debe comprobar que el máximo común divisor de 199543 y 11960 es 1, lo que efectivamente ocurre en este caso. 3. A continuación, U cifrará el mensaje anterior mediante el siguiente cálculo:

eV 3 c = m (mod nV ) = 11960 (mod 199543) ≡

≡ 1710777536000 (mod 199543) ≡ 15446 (mod 199543).

Este valor podría 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:

c = 15446 = 22 ⋅ 262 + 22 ⋅ 26 + 2 7→ c = WWC.

Descifrado del mensaje

Una vez que el usuario V reciba el mensaje cifrado enviado por U, c=WWC, debe realizar los pasos indicados en §2.4.2.1:

1. Recuperar su clave privada; en este caso v = dV = 132427. 2. A continuación, debe representar el mensaje cifrado en base 26 como un núme- ro, obteniendo c = 15446. Hecho esto, V descifrará el criptograma mediante las siguientes operaciones:

dV 132427 m = c (mod nV ) ≡ 15446 (mod 199543) = 11960 (mod 199543) ,

m = 11960 = 17 ⋅ 262 + 18 ⋅ 26 + 0 7→ m = RSA. 64 2. Criptografía de clave pública basada en curvas elípticas

2.4.2.3. Seguridad

El criptosistema RSA se basa en dos problemas matemáticos relacionados entre sí: el IFP y el problema RSA. El problema RSA puede deﬁnirse de la siguiente manera [172]: dado un número entero positivo n que sea el producto de dos números primos distintos p y q, un número entero positivo e tal que el máximo común divisor sea mcd(e, (p−1) (q−1)) = 1 y un número entero c, el problema consiste en encontrar el número entero m tal que me ≡ c (mod n). La equivalencia entre resolver el IFP y el problema RSA quedó establecida en 2007, cuando Coron y May [54] demostraron la existencia de un algoritmo determi- nístico de tiempo polinómico capaz de factorizar el elemento n, supuesto conocidos los valores e y d, con e, d < (n). De manera adicional, existen variantes del criptosistema RSA para las cuales también ha sido probada tal equivalencia, como por ejemplo los criptosistemas de Rabin [225], Williams [270] y Kurosawa [156]. Existe un gran número de ataques sobre el algoritmo RSA [35, 264], siendo los más importantes los siguientes:

∙ Ataques de factorización: consisten en intentar factorizar el módulo n. Den- tro de este tipo de técnica podemos citar los métodos de Pollard [220, 221], Williams [271], Lehman [158] y Shanks [241].

∙ Ataques a exponentes de cifrado pequeños: estos métodos están derivados del intento de conseguir un proceso de cifrado más eﬁciente [101, 53].

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

2.4.3. Criptosistema de El Gamal

2.4.3.1. Descripción

En 1985, Taher ElGamal [69] propuso un esquema de firma digital y cifrado que utilizaba la clave pública de V para cifrar una clave simétrica K, con la que a su vez se cifraba el mensaje original. La principal novedad de su propuesta consistía en unir para su envío tanto la clave simétrica temporal como la información original cifrada con dicha clave, aprovechando la complejidad del cálculo de los logaritmos sobre cuerpos finitos. En su propuesta, ElGamal aconsejaba no cifrar más de un mensaje (o más de un bloque del mensaje original, si por su longitud el mensaje debía ser 2.4. Principales esquemas de cifrado y establecimiento de clave 65 dividido en varias partes) con la misma clave K, por lo que en la práctica una nueva clave K siempre acompañará al mensaje cifrado en cada envío de información confidencial de U a V. Como en todo criptosistema de clave pública, en el de ElGamal se pueden identificar tres fases [179]:

1. Generación de claves.

2. Cifrado de mensajes.

3. Descifrado de mensajes.

Generación de claves

Todo usuario V que desee generar claves para el criptosistema de ElGamal debe seguir el Algoritmo 2.5.

Algoritmo 2.5 Generación de claves para el criptosistema ElGamal 1. Generar un número primo grande p (de alrededor de 300-310 dígitos, es decir, de aproximadamente 1024 bits).

∗ 2. Elegir un generador del grupo multiplicativo ℤp. 3. Generar un número aleatorio u, con 2 ≤ v ≤ p − 2, y calcular el valor de v (mod p).

4. Asignar como clave pública de V el trío V = (p, , v), siendo su clave privada el número v. En caso de que todos los usuarios utilicen los mismos valores p y , la clave pública del usuario V quedaría reducida al elemento V = v.

Cifrado de mensajes

Si el usuario U desea enviar un mensaje m cifrado al usuario V, U debe seguir los pasos indicados en el Algoritmo 2.6. El factor de expansión del algoritmo de ElGamal es igual a 2, debido a que la longitud del criptograma es el doble de la longitud del mensaje a cifrar, considerando que tanto el valor numérico del mensaje, m, como los elementos f y g, se codiﬁcan en formato binario utilizando ⌈log2 p⌉ bits. 66 2. Criptografía de clave pública basada en curvas elípticas

Algoritmo 2.6 Cifrado de mensajes en el criptosistema ElGamal 1. Obtener la clave pública de V, V = ( v), así como los valores p y .

2. Representar el mensaje m como el valor entero m ∈ {0, 1, . . . , p − 1}.

3. Generar un número aleatorio k, 2 ≤ k ≤ p − 2, y utilizarlo para calcular los valores

f = k (mod p) , g = m ⋅ ( v)k (mod p) .

4. Enviar el criptograma C = (f, g) a V, donde f y g representan las codiﬁca- ciones alfanuméricas de los valores f y g.

Descifrado de mensajes

Una vez que el usuario V recibe el criptograma C = (f, g) enviado por el usuario U, para obtener el mensaje original, m, V debe realizar el Algoritmo 2.7:

Algoritmo 2.7 Descifrado de mensajes en el criptosistema ElGamal 1. Utilizar su clave privada, v, para calcular

ℎ = f p−1−v (mod p) ≡ f −v (mod p) ≡ −k v (mod p) .

2. Calcular el valor numérico asociado al mensaje original multiplicando por g el valor anterior mediante la operación

ℎ ⋅ g (mod p) ≡ −k v ⋅ m ⋅ ( v)k (mod p) ≡ m,

obteniendo a continuación el mensaje m original a partir del valor m.

2.4.3.2. Ejemplo

A continuación se presenta un sencillo ejemplo de cifrado con el algoritmo de ElGamal.

Generación de las claves

Para generar sus claves, el usuario V debe seguir los pasos expuestos en §2.4.3.1:

1. V debe comenzar seleccionando el primo p = 15485863 que se utilizará para ∗ crear el conjunto ℤ15485863 y su grupo multiplicativo ℤ15485863. 2.4. Principales esquemas de cifrado y establecimiento de clave 67

∗ 2. A continuación, V elige como generador el elemento = 7 de ℤ15485863. 3. Posteriormente, V genera el número aleatorio v = 21702 que será utilizado como clave privada, calculando además el valor

v (mod p) = 721702 (mod 15485863) ≡ 8890431 (mod 15485863) .

4. Si los dos usuarios deciden utilizar los mismos valores de p y , entonces la clave pública de V será V = 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 p = 15485863, el generador = 7 y V = 8890431. 2. Supongamos que U quiere enviar a V el mensaje m=LAURA. Antes de cifrar el mensaje, es necesario codiﬁcarlo de manera equivalente al procedimiento utilizado en el ejemplo RSA, obteniendo el valor m asociado a m:

m = LAURA 7→ m = 11 ⋅ 264 + 0 ⋅ 263 + 20 ⋅ 262 + 17 ⋅ 26 + 0 = 5040698.

3. Tras representar el mensaje como un número entero, el usuario U genera el número aleatorio k = 480 y calcula el valor

f = k (mod p) = 7480 (mod 15485863) ≡ 12001315 (mod 15485863) .

A continuación, realiza los siguientes cálculos:

( v)k (mod p) ≡ 8890431480 (mod 15485863) = 9846598 (mod 15485863) .

g = m ⋅ ( v)k (mod p) ≡ 2829967 (mod 15485863) .

4. Por último, U debe obtener el equivalente alfanumérico del par ( u, m⋅( v)u) = (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: C = (BAGVLB, GFIX). 68 2. Criptografía de clave pública basada en curvas elípticas

Descifrado del mensaje

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, v = 21702, para realizar los siguiente cálculos, teniendo en cuenta que f = k (mod p):

f v (mod p) ≡ 1200131521702 (mod 15485863) ≡ 9846598 (mod 15485863) ,

ℎ = −kv ≡ 14823281 (mod 15485863) .

2. A continuación, V obtendrá el valor numérico del mensaje original mediante el cálculo

m = ℎ ⋅ g = 14823281 ⋅ 2829967 (mod 15485863) ≡ 5040698 (mod 15485863) .

Una vez obtenido m, V podrá recuperar el texto del mensaje original mediante la siguiente conversión:

m = 5040698 = 11 ⋅ 264 + 0 ⋅ 263 + 20 ⋅ 262 + 17 ⋅ 26 + 0 7→ m = LAURA.

2.4.3.3. Seguridad

La seguridad de este criptosistema se basa en la diﬁcultad computacional que supone resolver el DLP [36], del que ya se han realizado algunos comentarios en §2.1 y §2.4.1.3. Por esta razón, se dice que la seguridad del criptosistema de ElGamal es equivalente a la del logaritmo discreto.

2.5. Esquemas de cifrado híbrido DEM -KEM

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

Debido a la contribución de Shoup, las técnicas más modernas relacionadas con los esquemas de cifrado híbrido de clave pública dividen el esquema en dos etapas claramente diferenciadas, denominadas KEM (Key Encapsulation Mechanism) y DEM (Data Encapsulation Mechanism). La popularidad que ha alcanzado recientemente la técnica DEM -KEM se basa, en parte, a que la seguridad del esquema resulta más sencilla de analizar considerando los dos bloques por separado [30]. Los siguientes apartados incluyen la deﬁnición formal de las etapas KEM y DEM, utilizando para ello la notación deﬁnida en [243].

2.5.1. Mecanismo de encapsulación de clave KEM

Cualquier mecanismo KEM debe incluir los siguientes elementos:

∙ Un algoritmo de generación de clave KEM.KeyGen(), que produce una clave pública PK y su correspondiente clave privada SK, formando el par (PK,SK ).

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

∙ Un algoritmo de descifrado KEM.Decrypt(SK,C 0), que toma como entrada una clave secreta privada SK y la clave cifrada C0, devolviendo como salida la clave K.

∙ Un entero positivo, denominado KEM.OutputKeyLen, que representa la longitud de la clave K.

2.5.2. Mecanismo de encapsulación de datos DEM

Los mecanismos DEM deben incluir los siguientes elementos:

∙ Un algoritmo de cifrado DEM.Encrypt(K,L,M ) que tome como entrada una clave K, una etiqueta L y un mensaje M, generando como salida el texto cifrado C1.

∙ Un algoritmo de descifrado DEM.Decrypt(K,L,C 1), que produzca el mensaje M a partir de las entradas K, L y C1, tal que

DEM.Decrypt(K,L,DEM.Encrypt(K,L,M ))=M.

∙ Los elementos K, L, M y C1 representan cadenas de bytes, donde L y M pueden tener longitudes variables, siendo la longitud de K el valor DEM.KeyLen. 70 2. Criptografía de clave pública basada en curvas elípticas

2.5.3. Esquema de cifrado híbrido con etapas KEM -DEM

En base a las deﬁniciones de las etapas DEM y KEM, es posible describir de forma genérica los pasos necesarios para cifrar un mensaje M utilizando el esquema de cifrado híbrido genérico H-PKE=H-PKE KEM,DEM . La única condición que debe cumplirse es que, para que las etapas DEM y KEM sean compatibles, las longitudes KEM.OutputKeyLen y DEM.KeyLen deben coincidir. Por tanto, dado un par de claves pública y privada (PK,SK), para cifrar un mensaje M con una etiqueta L y opciones de cifrado opt, el esquema de cifrado H-PKE debe realizar los siguientes pasos:

1. Ejecutar el algoritmo de cifrado de la fase KEM para generar la clave K y su versión cifrada C0. 2. Cifrar M y la etiqueta L con la clave K utilizando el algoritmo de cifrado de la fase DEM, generando el elemento C1.

3. Generar el criptograma C = C0 || C1, donde || representa la operación de con- catenación.

De manera equivalente, para descifrar el criptograma C con la etiqueta L y la clave SK, el algoritmo de descifrado de H-PKE debe realizar las siguientes operaciones:

1. Interpretar el criptograma C como C0||C1.

2. Descifrar el elemento C0 utilizando el algoritmo de descifrado de la fase KEM y la clave SK para obtener K.

3. Descifrar el elemento C1 con la etiqueta L utilizando el algoritmo de descifrado de la fase KEM y la clave K, obteniendo M.

2.6. Criptografía basada en curvas elípticas

Tal como se ha comentado anteriormente, en 1987 Neal Koblitz [147] propuso utilizar curvas elípticas sobre cuerpos finitos para implementar algunos 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 cálculos que es necesario realizar sobre los puntos de una curva elíptica, incluyendo ejemplos sobre cómo elegir dichos puntos. De forma adicional, Koblitz describió có- mo se podría implementar el proceso de acuerdo de clave Diffie-Hellman utilizando curvas elípticas, lo que constituye el esquema ECDH (Elliptic Curve Diffie-Hellman). 2.6. Criptografía basada en curvas elípticas 71

Por su parte, Victor Miller [174] realizó su propuesta desde un punto de vista más teórico en relación al modelo general descrito por Diﬃe y Hellman, pero sin realizar comparaciones con otras implementaciones existentes. En los siguientes apartados se presentan los conceptos fundamentales relacionados con las curvas elípticas y con su aplicación a la criptografía.

2.6.1. Deﬁnición de curva elíptica

2 Dados el cuerpo F y el plano afín A (F) = F2 deﬁnido sobre F, se representa el plano proyectivo correspondiente como el conjunto

2 3 P (F) = {(X,Y,Z) ∈ F ∣ (X,Y,Z) ∕= (0, 0, 0)} junto con la relación de equivalencia ∼, definida de manera que dos puntos del plano proyectivo (X,Y,Z) y (X′,Y ′,Z′) son equivalentes si y sólo si existe un valor ∕= 0 tal que (X′,Y ′,Z′) = (X, Y, Z) [175]. A la clase de equivalencia del punto (X,Y,Z) de la representará como [X : Y : Z]. Una curva plana definida sobre un cuerpo F puede expresarse en el plano afín 2 A (F) mediante la ecuación f(x, y) = 0 en coordenadas no homogéneas, o alter- 2 nativamente en el plano proyectivo P (F) mediante la ecuación F (X,Y,Z) = 0 en coordenadas homogéneas [265], donde un polinomio es homogéneo si todos sus monomios tienen el mismo grado. Se considera que dicha curva tiene puntos racionales cuando las coordenadas del punto pertenecen al cuerpo F (no necesariamente ℚ)[244]. La existencia de puntos racionales en una curva depende del género g de la propia curva, concepto derivado del teorema de Riemann [227] y que permite clasificar las curvas planas en función del grado del polinomio que la define y de sus singularidades mediante la expresión

(n − 1)(n − 2) X mP (mP − 1) (2.1) g = − i i , 2 2 Pi

siendo n el orden de la curva y mPi la multiplicidad de cada punto singular Pi [96]. Un punto de una curva es singular si y sólo si las derivadas parciales de la expresión se anulan en dicho punto [149]. Los puntos singulares de una curva cúbica plana se denominan nodo si el punto tiene dos tangentes distintas y cúspide si el punto tiene una tangente doble [73]. Se dice que una curva es singular o no regular cuando tiene al menos un punto singular, mientras que es regular o no singular cuando no contiene puntos singulares [72]. Las Figuras 2.2y 2.3 muestran dos ejemplos de puntos singulares en forma de nodo y cúspide, respectivamente. 72 2. Criptografía de clave pública basada en curvas elípticas

Figura 2.2: Curva y2 = x3 con un nodo en el punto (0, 0)

Figura 2.3: Curva y2 + xy − x3 = 0 con una cúspide en el punto (0, 0) 2.6. Criptografía basada en curvas elípticas 73

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

∙ Una curva de género g = 0 no tiene puntos racionales o bien tiene infinitos. Sin embargo, puede no tener puntos enteros, tener una cantidad finita de ellos o tener infinitos. ∙ Una curva de género g = 1 no tiene puntos racionales, tiene un número finito de ellos o bien tiene infinitos, pero sólo puede tener una cantidad finita de puntos enteros. ∙ Una curva de género g ≥ 2 sólo puede tener una cantidad finita de puntos racionales.

A partir de las deﬁniciones anteriores, se puede aﬁrmar que una curva elíptica E sobre el cuerpo F es una curva proyectiva regular de género 1 que tiene al menos un punto racional [140, 149, 245]. Toda curva elíptica admite un tipo de ecuación canónica llamada forma de Weierstrass, cuya expresión en coordenadas homogéneas es

2 2 3 2 3 6 (2.2) E : Y Z + a1XYZ + a3YZ = X + a2X Z + a4XZ + a6Z , donde a1, a2, a3, a4, a6 ∈ F y Δ ∕= 0, siendo Δ el discriminante de E que se calcula de la siguiente manera [168]:

2 3 2 ⎫ Δ = −d2d8 − 8d4 − 27d6 + 9d2d4d6  2  d2 = a1 + 4a2 ⎬ d4 = 2a4 + a1a3 2  d6 = a3 + 4a6  2 2 2 ⎭ d8 = a1a6 + 4a2a6 − a1a3a4 + a2a3 − a4

En la práctica, la ecuación de Weirstrass se suele expresar en su forma no ho- mogénea, donde la relación entre ambas ecuaciones es f(x, y) = F (x, y, 1), y alternativamente F (X,Y,Z) = f(X/Z, Y/Z) ⋅ Z3, resultando la siguiente ecuación afín:

2 3 2 (2.3) E : y + a1xy + a3y = x + a2x + a4x + a6.

Las Figuras 2.4y 2.5 muestran dos ejemplos de curvas elípticas deﬁnidas sobre el cuerpo de los números reales. 74 2. Criptografía de clave pública basada en curvas elípticas

Figura 2.4: Curva elíptica y2 = x3 − 10x + 15

Figura 2.5: Curva elíptica y2 = x3 − 10x + 9 2.6. Criptografía basada en curvas elípticas 75

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

∙ Una curva plana cúbica no singular con un punto racional.

∙ Una curva no singular de género 1 con un punto racional.

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

2.6.2. Estructura de grupo

Sea E una curva elíptica sobre un cuerpo F definida mediante la ecuación (2.3), y sean los puntos de la curva P = (xP , yP ), Q = (xQ, yQ) y R = (xR, yR), donde O = [0 : 1 : 0] representa el punto en el infinito en coordenadas homogéneas. En estas condiciones, se define la operación + de la siguiente manera [50, 148, 245]:

1. Para todo punto P de la curva, P + O = O + P = P .

2. Dado un punto P , entonces −P = (xP , −yP − a1 xP − a3), de manera que P + (−P ) = O. Es importante resaltar que P y −P son los únicos puntos de la curva cuya primera coordenada es xP .

3. Dados dos puntos P y Q tales que P ∕= ±Q, entonces R = P + Q, con

⎫ x = 2 + a − a − x − x , R 1 2 P Q    yR = (xP − xR) − yP − a1 xR − a3, ⎬  yQ − yP  = .  xQ − xP ⎭ 76 2. Criptografía de clave pública basada en curvas elípticas

4. Dado un punto P , el punto R = P + P = 2P tiene como coordenadas los valores

x = 2 + a − a − x − x , ⎫ R 1 2 P Q    yR = (xP − xR) − yP − a1 xR − a3, ⎬  2  3 xP + 2 a2 xP + a4 − a1 yP  = . ⎭ 2 yP + a1 xP + a3

Las siguientes figuras muestran de forma gráfica algunos ejemplos de operaciones realizadas sobre la curva y2 = x3 − 10x + 15 definida sobre el cuerpo de los números reales: suma de dos puntos P = (xP , yP ) y Q = (xQ, yQ) tal que xP ∕= xQ e yP ∕= yQ (Figura 2.6); suma de P y Q tal que xP = xQ e yP ∕= yQ (Figura 2.7); suma de P con P siendo el resultado 2P (Figura 2.8) y suma de P con 2P siendo el resultado 3P (Figura 2.9).

Figura 2.6: Suma de puntos de la curva R = P + Q

Según indica el teorema de Mordell-Weil [180, 266], la operación suma de puntos deﬁnida de esta manera cumple las propiedades descritas a continuación, lo que permite dotar a los puntos de la curva E de la estructura de grupo abeliano:

∙ Asociatividad: (P + Q) + R = P + (Q + R) para todo P, Q, R ∈ E. 2.6. Criptografía basada en curvas elípticas 77

Figura 2.7: Suma de puntos de la curva R = P + Q = O

Figura 2.8: Suma de puntos de la curva R = P + P = 2P 78 2. Criptografía de clave pública basada en curvas elípticas

Figura 2.9: Suma de puntos de la curva R = P + 2P = 3P

∙ Existencia de elemento neutro: P + O = P para todo punto P ∈ E.

∙ Existencia de elemento opuesto: dado un punto P = (x, y), existe un único punto P ′ tal que P + P ′ = O, donde P ′ = −P .

∙ Conmutatividad: P + Q = Q + P para todo P,Q ∈ E.

Esta característica implica que todos los puntos racionales de una curva elíptica definida sobre ℚ (o sobre una extensión de ℚ) pueden obtenerse a partir de un número finito de ellos. En el caso de los cuerpos finitos, el número de generadores es 1 ó 2 [228].

2.6.3. Curvas elípticas sobre cuerpos ﬁnitos

2.6.3.1. Orden y característica de un cuerpo ﬁnito

El orden de un cuerpo ﬁnito F es el número de elementos de dicho cuerpo. Es posible demostrar que la existencia de un cuerpo ﬁnito de orden q está ligada a la condición de que el valor q sea una potencia prima del tipo q = pm, donde al valor p se le denomina característica del cuerpo y debe ser un número primo, mientras que el valor m puede ser cualquier entero positivo [99]. 2.6. Criptografía basada en curvas elípticas 79

En general, en los criptosistemas basados en curvas elípticas se utilizan dos tipos m de cuerpos finitos Fq con q = p elementos: Fp y F2m . Si el cuerpo es del tipo Fp (donde p es un primo impar y m tiene valor 1), se le denomina cuerpo finito primo; por el contrario, si el cuerpo finito es del tipo F2m (donde evidentemente p es igual a 2 y m puede ser cualquier número entero mayor o igual que 1), se le conoce como cuerpo finito binario [215].

En los cuerpos ﬁnitos primos, los elementos del cuerpo Fp se representan mediante los números enteros {0, 1, 2, . . . , p − 1}. En este caso, el elemento neutro de la operación suma es el entero 0, el elemento unitario de la operación producto es el entero 1, la suma de elementos se realiza mediante la suma de enteros módulo p y la multiplicación de elementos del cuerpo se efectúa igualmente mediante la multiplicación de números enteros módulo p [24].

En comparación, en los cuerpos finitos de tipo F2m , los elementos del cuerpo se representan mediante cadenas de bits de longitud m. Si f(x) es un polinomio irreducible de grado m con coeficientes en F2, entonces el cuerpo F2m puede interpretarse como el conjunto de polinomios con coeficientes en F2 de grado estrictamente menor que el grado de f(x) [24], o lo que es lo mismo:

F2m = F2[x]/(f(x)).

Los parámetros que deﬁnen el tamaño del cuerpo ﬁnito son imprescindibles para calcular la longitud de las curvas elípticas y de las claves asociadas a dichas curvas. Esta longitud debe ser interpretada como el número de bits necesarios para representar el entero p en curvas sobre cuerpos primos (es decir, el valor ⌈log2 p⌉), mientras que en el caso de curvas sobre cuerpos binarios la longitud coincide con el valor del elemento m.

2.6.3.2. Orden de una curva elíptica

Se define el orden de una curva E sobre un cuerpo Fq de característica p, de- notándose mediante la expresión #E(Fq), como el número de puntos de E(Fq). Si el cuerpo sobre el que está definido la curva es finito, entonces el orden de la curva siempre será finito, y estará formado por los puntos que satisfacen la ecuación de la curva más el punto en el infinito. El teorema de Hasse [143] determina la siguiente expresión para el orden de una curva:

√ #E(Fq) = q + 1 − t, ∣t∣ ≤ 2 q, donde el elemento t representa la traza de la curva [99]. 80 2. Criptografía de clave pública basada en curvas elípticas

2.6.3.3. Versiones simpliﬁcadas de la ecuación de Weierstrass

Dependiendo de si el cuerpo Fq tiene característica 2, 3 o cualquier otro valor [50], es posible simpliﬁcar aún más la ecuación (2.3), tal como se describe a continuación:

1. Si la característica de F no es 2 ni 3, el cambio de variables

x − 3a2 − 12a y − 3a x a3 + 4a a − 12a (x, y) −→ 1 2 , 1 − 1 1 2 3 36 216 24

transforma la ecuación (2.3) en

(2.4) y2 = x3 + ax + b,

cuyo discriminante pasa a ser

Δ = −16 (4a3 + 27b2).

2. Si la característica de F es 2 aparecen dos casos distintos dependiendo del valor de a1.

a) Si a1 ∕= 0, entonces el cambio de variables 2 2 2 a3 3 a1a4 + a3 (x, y) −→ a1x + , a1y + 3 a1 a1 transforma la curva dada por la ecuación (2.3) en la curva

(2.5) y2 + xy = x3 + ax2 + b.

Esta curva se denomina “no supersingular” [99] y su discriminante es Δ = b.

b) Si a1 = 0, entonces el cambio de variables

(x, y) −→ (x + a2, y) transforma la ecuación (2.3) en

(2.6) y2 + cy = x3 + ax + b.

A esta curva se la denomina “supersingular” [99] y su discriminante es 2.6. Criptografía basada en curvas elípticas 81

Δ = c4.

3. Si la característica de F es 3, de nuevo nos encontramos con dos casos distintos en función del valor de a1.

2 a) Si a1 ∕= −a2, entonces el cambio de variables 2a4 + a1a3 2a4 + a1a3 (x, y) −→ x + 2 , y + a1x + a1 2 + a3 a1 + 4a2 a1 + 4a2 transforma la curva dada por la ecuación (2.3) en la curva

(2.7) y2 = x3 + ax2 + b.

Dicha curva se denomina “no supersingular” [99] y su discriminante es Δ = −a3b.

2 b) Si a1 = −a2, entonces el cambio de variables

(x, y) −→ (x, y + a1x + a3) transforma la ecuación (2.3) de E en la curva

(2.8) y2 = x3 + ax + b.

A esta curva se la denomina “supersingular” [99] y su discriminante es Δ = −a3.

Una curva elíptica E sobre un cuerpo Fq de característica p definida por la ecua- ción cúbica en coordenadas homogéneas F (X,Y,Z) = 0 se dice que es supersingular si el coeficiente de (XYZ)p−1 en (F (X,Y,Z))p−1 es cero. Por el contrario, la curva es no supersingular si el coeficiente de (XYZ)p−1 en (F (X,Y,Z))p−1 es distinto de cero. De manera equivalente, se puede afirmar que una curva E definida sobre un cuerpo finito con característica p es supersingular si p divide a t, siendo t la traza de la curva [99], mientras que si p no divide a t, entonces la curva es no supersingular. El Cuadro 2.1 presenta un resumen de los distintos tipos de ecuaciones en fun- ción de la característica de F y de las condiciones adicionales que se impongan sobre cada curva. 82 2. Criptografía de clave pública basada en curvas elípticas

Car. de F Ecuación Supersingular Condición ∕= 2, 3 y2 = x3 + ax + b No – 2 3 2 2 y + xy = x + ax + b No a1 ∕= 0 2 3 2 y + cy = x + ax + b Sí a1 = 0 2 3 2 2 3 y = x + ax + b No a1 ∕= −a2 2 3 2 3 y = x + ax + b Sí a1 = −a2 Cuadro 2.1: Versiones simpliﬁcadas de la ecuación de Weierstrass

2.6.3.4. Estructura de grupo en curvas sobre cuerpos ﬁnitos

La operación suma definida en §2.6.2 sigue manteniendo su validez cuando la curva E está definida sobre el cuerpo finito Fq. En el caso particular de curvas sobre cuerpos primos Fp (con p > 3) y dadas por la ecuación (2.4), la operación + queda particularizada de la siguiente manera [99], donde P = (xP , yP ), Q = (xQ, yQ), R = (xR, yR) y los elementos que constituyen las coordenadas pertenecen a Fp.

1. Para todo punto P de la curva, P + O = O + P = P .

2. Dado un punto P , entonces P + (−P ) = O, siendo −P = (xP , −yP ). 3. Dados dos puntos P y Q tales que P ∕= ±Q, entonces R = P + Q, con

⎫ x = 2 − x − x , R P Q    yR = (xP − xR) − yP , ⎬  yQ − yP  = .  xQ − xP ⎭

4. Dado un punto P , el punto R = P + P = 2P tiene como coordenadas los valores

x = 2 − 2 x , ⎫ R P    yR = (xP − xR) − yP , ⎬  2  3 xP + a  = . ⎭ 2 yP

Las fórmulas anteriores implican que la suma de dos puntos P y Q conlleva la realización de 1 inversión, 2 multiplicaciones y 1 elevación al cuadrado en Fp, 2.6. Criptografía basada en curvas elípticas 83 mientras que para obtener 2 P a partir del punto P es necesario realizar 1 inversión, 2 multiplicaciones y 2 elevaciones al cuadrado en Fp. Las operaciones de suma y diferencia de elementos del cuerpo finito no se suelen contabilizar debido a que, en comparación con las otras operaciones mencionadas, son las que requieren menor tiempo de computación. Las siguientes figuras muestran de forma gráfica las siguientes operaciones reali- 2 3 zadas en la curva y = x +11x+3 definida sobre F17: suma de los puntos P = (4, 3) y Q = (9, 7), con resultado R = (6, 9) (Figura 2.10); suma de P = (7, 7) con P = (7, 7), siendo el resultado R = 2P = (2, 13) (Figura 2.11) y suma de P = (7, 7) con 2P = (2, 13), siendo el resultado R = 3P = (4, 3) (Figura 2.12).

Figura 2.10: Suma de puntos R = P + Q sobre un cuerpo primo

En el caso particular de curvas sobre cuerpos binarios con ecuaciones como la dada en (2.5), la operación + queda particularizada del siguiente modo [50], donde P = (xP , yP ), Q = (xQ, yQ), R = (xR, yR) y los elementos que conforman las coordenadas pertenecen a F2m .

1. Para todo punto P de la curva, P + O = O + P = P .

2. Dado un punto P , entonces P + (−P ) = O, siendo −P = (xP , xP + yP ).

3. Dados dos puntos P y Q tales que P ∕= ±Q, entonces R = P + Q, con 84 2. Criptografía de clave pública basada en curvas elípticas

Figura 2.11: Suma de puntos R = P + P = 2P sobre un cuerpo primo

Figura 2.12: Suma de puntos R = P + 2P = 3P sobre un cuerpo primo 2.6. Criptografía basada en curvas elípticas 85

⎫ x = 2 + + x + x + a, R P Q    yR = (xP + xR) + xR + yP , ⎬  yP + yQ  = .  xP + xQ ⎭

4. Dado un punto P , el punto R = P + P = 2P tiene como coordenadas los valores

2 ⎫ xR = + + a,   ⎬ yR = (xP + xR) + xR + yP ,  yP  = xP + . ⎭ xP

Con las fórmulas anteriores, tanto la suma de dos puntos P y Q como la obtención de 2 P a partir del punto P necesitan 1 inversión, 2 multiplicaciones y 1 elevación al cuadrado en F2m . Al igual que en el caso de los cuerpos primos, las operaciones de suma y diferencia de elementos del cuerpo binario no se han contabilizado debido a su menor tiempo de ejecución respecto al de las otras operaciones referidas, por lo que su aportación al tiempo de procesamiento total puede considerarse despreciable.

2.6.3.5. Multiplicación de un punto por un escalar

De manera adicional a la operación suma, existe otra operación ampliamente utilizada en los cálculos con puntos de una curva. Se trata del producto de un punto P de la curva por el entero positivo n, que se calcula sumando el punto P un número n de veces consigo mismo:

n P = P + P + ... + P.

Aunque en algunos textos la notación recogida para esta operación es [n]P o n ⋅ P , se ha decidido utilizar la notación simplificada n P con el fin de conseguir una mayor sencillez en la exposición. Cuando la curva elíptica está definida sobre un cuerpo finito, es necesario tener en cuenta el hecho de que el producto de un punto cualquiera perteneciente a una curva por el orden de dicha curva es igual al punto en el infinito. Es decir:

#E(Fq) P = O. 86 2. Criptografía de clave pública basada en curvas elípticas

Es importante resaltar que, en curvas deﬁnidas sobre cuerpos ﬁnitos, el orden de un punto cualquiera P siempre será un divisor del orden de la curva. Al valor del cociente de dicha división se le denomina cofactor, de manera que si n es el orden de P , entonces se cumplirá que el cofactor ℎ será

#E( ) ℎ = Fq . n

2.6.4. Bases polinómicas y bases normales

Además de su interpretación como el conjunto de polinomios de grado menor que m, F2m = F2[x]/(f(x)), el cuerpo ﬁnito F2m también puede entenderse como un espacio vectorial de dimensión m sobre F2. En este caso, puede utilizarse una base de dicho espacio vectorial { 0, 1, . . . , m−1}, de forma que cualquier elemento a ∈ F2m quede representado como el vector

m−1 X a = ai i = (a0, a1, . . . , am−1), donde ai ∈ {0, 1} , i=0 el cual en la práctica se representa como una cadena de bits de longitud m.

2.6.4.1. Bases polinómicas

Las representaciones de los elementos de F2m = F2[x]/(f(x)) mediante bases polinómicas utilizan una base formada por el conjunto de polinomios

{xm−1, xm−2, . . . , x, 1}.

De esta manera, un elemento cualquiera a ∈ F2m puede representarse como la cadena de bits a = (am−1 am−2 . . . a1 a0) que se corresponden con los coeﬁcientes del polinomio

m−1 m−2 a(x) = am−1 x + am−2 x + ... + a1 x + a0.

Utilizando esta técnica, el elemento unitario se representa mediante la cadena de bits (0 0 ... 0 0 1), mientras que el elemento neutro queda representado mediante la cadena (0 0 ... 0 0 0).

La suma de dos elementos de F2m se realiza mediante la operación XOR aplicada sobre los bits de las cadenas que representan a los elementos que participan en la suma. Respecto a la multiplicación de elementos de F2m , esta operación se realiza 2.6. Criptografía basada en curvas elípticas 87 mediante el producto de los polinomios módulo el polinomio irreducible f(x) de grado m que deﬁne el cuerpo F2m , al que se le conoce como polinomio reductor. De esta forma, el producto de dos elementos del cuerpo es el resto de la división entre f(x) del producto de ambos polinomios. El procedimiento que suele seguirse para elegir el polinomio irreducible de grado m es el siguiente:

1. Si existe un trinomio irreducible de la forma xm + xk + 1, entonces de entre las distintas posibilidades se elige el de menor término medio xk. Es importante hacer constar que estos trinomios sólo existen para algunos valores de m.

2. En caso de no existir un polinomio con las características comentadas en el paso 1, se elige un pentanomio de la forma xm + xk3 + xk2 + xk1 + 1. De entre las distintas opciones iniciales, se elige el polinomio con menor valor k3. Después, de entre el conjunto de polinomios con el valor k3 se elige el de menor valor k2. Por último, del conjunto de polinomios con valores k3 y k2 se elige el de menor valor k1. En comparación con los trinomios, los pentanomios irreducibles existen para todo valor m ≥ 4.

Para mayor información, tanto en [16] como en [108] es posible encontrar listas de trinomios y pentanomios irreducibles sobre F2.

2.6.4.2. Bases normales

Una base normal de F2m sobre F2 tiene la forma n o , 2, . . . , 2m−1 , donde ∈ F2m . Por tanto, cualquier elemento a ∈ F2m queda representado como

m−1 X 2i a = ai , donde ai ∈ {0, 1} . i=0

En el caso de las bases normales, a los elementos a ∈ F2m se les suele representar como la cadena de bits (a0a1 . . . am−1) de longitud m (nótese el cambio en el orden de los subíndices respecto a las bases polinómicas), donde ai ∈ {0, 1}. Em- pleando esta técnica, el elemento unitario se representa mediante la cadena de bits (1 1 ... 1 1 1), mientras que el elemento neutro queda representado mediante la cadena (0 0 ... 0 0 0). Al igual que en las bases polinómicas, la suma de dos elementos de F2m se realiza mediante la operación XOR aplicada sobre los bits de las cadenas que los representan. 88 2. Criptografía de clave pública basada en curvas elípticas

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

2.6.5. Representación de los puntos de una curva elíptica

Dada una curva elíptica E deﬁnida sobre un cuerpo ﬁnito Fq de característica p, un punto P de la curva puede representarse de forma comprimida o descomprimida [257], tal como se describe a continuación:

∙ Forma descomprimida La forma descomprimida de un punto P = (x, y) es la cadena 0x04||X||Y , donde X e Y son las representaciones hexadecimales de la primera y segunda coordenadas del punto, teniendo ambas cadenas hexadecimales una longitud

de ⌈(log2 q)/8⌉ bytes. ∙ Forma comprimida La forma comprimida de un punto P = (x, y) es la cadena C || X, donde X es la representación hexadecimal de la primera coordenada del punto, y el elemento C puede tener como valores 0x02 ó 0x03 dependiendo del punto, calculándose este valor según el Algoritmo 2.8, tal como se encuentra descrito en [254].

En cuanto al procedimiento para recuperar las coordenadas x e y del punto P a partir de su forma comprimida, es necesario seguir las indicaciones del Algoritmo 2.9, que se encuentra descrito igualmente en [254]. 2.6. Criptografía basada en curvas elípticas 89

Algoritmo 2.8 Compresión de un punto P = (x, y) de la curva 1. Obtener la representación binaria hexadecimal X de la coordenada x, que

deberá tener una longitud de ⌈log2 q)/8⌉ bytes. 2. Calcular el valor del elemento y˜ de la siguiente manera:

a) Si q = p, siendo p un número primo, realizar la asignación y˜ = y (mod 2).

m b) Si q = 2 y x = 0F, entonces y˜ = 0. Por el contrario, si x ∕= 0F, entonces m−1 es necesario calcular el elemento z = zm−1 ⋅ x + ... + z1 ⋅ x + z0 tal −1 que z = y ⋅ x , y tomar como valor de y˜ el elemento z0.

3. Si y˜ = 0, asignar al byte C el valor 0x02. En caso contrario, asignarle el valor 0x03.

4. Generar como representación comprimida de P la cadena C∣∣X.

Algoritmo 2.9 Descompresión de un punto P = (x, y) de la curva

1. Interpretar la cadena hexadecimal, de longitud ⌈(log2 q)/8⌉ + 1 bytes, como los elementos concatenados C∣∣X, donde la longitud de C es de un byte.

2. Convertir la cadena X en el elemento x del cuerpo Fq. 3. Si el valor del byte C es 0x02, realizar la asignación y˜ = 0. Si por el contrario C =0x03, es necesario hacer y˜ = 1.

4. Derivar el valor de y a partir de los elementos x e y˜ de la siguiente manera:

a) Si q = p, siendo p un número primo, calcular el elemento del cuerpo Fp ≡ x3 + a x + b (mod p), y calcular una raíz cuadrada de módulo p. Si ≡ y˜ (mod 2), hacer y = . Si por el contrario no se cumple la equivalencia indicada, tomar y = p − .

b) Si q = 2m y x = 0, realizar la asignación y = b2m−1 . En cambio, −2 si x ∕= 0, calcular el elemento = x + a + b x del cuerpo F2m , y m−1 encontrar a continuación un elemento z = zm−1 ⋅x +...+z1 ⋅x+z0 2 de F2m tal que z + z = . Si z0 =y ˜, calcular y = x ⋅ z, mientras que si z0 ∕=y ˜, calcular y = x ⋅ (z + 1).

5. Obtener como salida del proceso el punto P = (x, y). 90 2. Criptografía de clave pública basada en curvas elípticas

2.6.6. Comprobación de los parámetros de una curva elíptica

En la implementación de funcionalidades de los criptosistemas basados en curvas elípticas, uno de los puntos más críticos suele ser la generación de los parámetros asociados a una curva y su posterior comprobación. El presente apartado tiene como objetivo mostrar algunos de los algoritmos utilizados en estas tareas, comenzando por el Algoritmo 2.10, utilizado para generar una curva de forma aleatoria en el caso particular de los cuerpos ﬁnitos F2m [183, 172].

Algoritmo 2.10 Generación aleatoria de una curva sobre F2m 1. Elegir una semilla aleatoria s.

2. Aplicar la función resumen SHA-1 al elemento s para obtener una cadena de bits B de longitud n.

3. Asignar b al elemento de F2m cuya representación en binario es B. 4. Incluir b en la expresión E : y2 + x ⋅ y = x3 + x2 + b.

5. Calcular el orden #E(F2m ) y asignar su valor a N. 6. Si N ∕= 2q, siendo q un número primo, entonces volver al paso 1. En caso contrario, continuar.

7. Generar un elemento G ∈ E(F2m ) de orden q.

8. Validar la curva con parámetros P= (E, F2m , q, 2,G) según el Algoritmo 2.11. Si la validación es negativa, volver al paso 1.

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

Algoritmo 2.11 Comprobación de los parámetros de una curva 1. Asignar el valor l = #F = pm al cardinal del cuerpo base F.

2. Comprobar que #E(F) = ℎ ⋅ n (siendo ℎ el cofactor de la curva y n el orden de un punto de la curva) mediante la generación de puntos aleatorios y la comprobación de que tienen orden ℎ, n o ℎ ⋅ n.

3. Comprobar que n es un número primo, para evitar los ataques basados en el método del descenso de Weil [30].

4. Comprobar que n > 2160 para evitar los ataques de tipo BSGS/Rho [29].

5. Comprobar que n ∕= p para evitar los ataques de tipo anómalo [29].

6. Comprobar que lt ∕≡ 1 (mod n) para todos los valores t ≤ 100 a ﬁn de evitar el ataque de tipo supersingular (también conocidos como MOV/Frey-Rück [29]).

7. Comprobar que G pertenece a la curva y tiene orden n.

Algoritmo 2.12 Validación de una clave pública Q

1. Si Q/∈ E(Fq), entonces la clave pública Q no es válida. 2. Si Q = O, la clave pública Q no es válida.

3. Si n Q ∕= O, la clave pública Q no es válida.

2.6.7. Seguridad

De manera equivalente a otros protocolos y algoritmos, la criptografía de curva elíptica también tiene ataques que tienen en cuenta sus aspectos especíﬁcos. En los siguientes apartados, se describen las características principales de estos ataques sobre ECC.

2.6.7.1. Curvas supersingulares

Las curvas definidas sobre el cuerpo Fq con característica p se denominan supersingulares si cumplen la condición #E(Fq) ≡ 1 (mod p) [265]. En curvas sobre Fp, por ejemplo, una curva supersingular contendrá exactamente p + 1 elementos. El ataque de Frey y Rück [76], que es una generalización del trabajo de Menezes, Okamoto y Vanstone [170] (conocido habitualmente como el ataque MOV), reduce el ECDLP en una curva definida supersingular sobre E(Fq) al DLP definido en un B cuerpo finito Fq para algún B ≥ 1, el cual es más sencillo de resolver. 92 2. Criptografía de clave pública basada en curvas elípticas

Este ataque sólo es práctico si el parámetro B es pequeño, y para comprobar si una curva es vulnerable a este ataque es necesario realizar la siguiente comprobación, donde n es el orden del generador G:

qB ∕≡ 1 (mod n) , ∀ B, 1 ≤ B ≤ 100.

2.6.7.2. Curvas anómalas

Las curvas anómalas se caracterizan por contener exactamente q elementos en Fq [265]. Semaev [240], Smart [247] y Satoh y Araki [235] demostraron que el ECDLP planteado para curvas anómalas puede ser resuelto de manera eﬁciente, por lo que para excluir de los algoritmos de generación de claves este tipo de curvas es necesario realizar la comprobación

#E(Fq) ∕= q.

2.6.7.3. Descenso de Weil

En 2002, Gaudry, Hess y Smart [91] adaptaron una idea de Frey [77] para resolver el ECDLP utilizando el descenso de Weil para convertir el ECDLP en un problema de curvas hiperelípticas. Tanto Jacobson, Menezes y Stein [141] como Maurer, Menezes y Teske [167] encontraron varias curvas deﬁnidas sobre cuerpo F2m , siendo m un número compuesto, donde el método era viable. Por otra parte, Menezes y Qu [173] demostraron que este método no es aplicable a cuerpos ﬁnitos F2m cuando m es un número primo, por lo que los estándares y recomendaciones más recientes únicamente incluyen (en los apartados que tratan sobre cuerpos binarios) curvas elípticas donde m es un número primo.

2.6.8. Estándares relacionados

En el ámbito de los algoritmos y protocolos criptográﬁcos, los hallazgos teóricos no pueden emplearse directamente, sino que es necesario deﬁnir las conversiones y la gestión de datos sobre los que se aplicarán las nuevas técnicas. La información precisa que permite realizar implementaciones prácticas se detalla en los estándares desarrollados por diferentes organizaciones tanto nacionales como supranacionales, así como por consorcios industriales. A continuación se enumeran las principales organizaciones dedicadas a esta labor de estandarización y que han desarrollado alguna norma relacionada con las curvas elípticas y su aplicación a la critografía: 2.6. Criptografía basada en curvas elípticas 93

∙ ISO La Organización Internacional para la Estandarización (International Orga- nization for Standardization o ISO) es el organismo encargado de promover el desarrollo de las normas internacionales de fabricación, comercio y comu- nicación para todas las ramas industriales (a excepción de la eléctrica y la electrónica), especialmente en los temas relacionados con las normas de productos y seguridad para las empresas y organizaciones a nivel internacional.

∙ IEC La Comisión Electrotécnica Internacional (International Electrotechnical Com- mission o IEC) es un organismo de estandarización en los campos eléctrico, electrónico y de otras tecnologías relacionadas. Numerosas normas se desarro- llan conjuntamente con ISO, siendo entonces denominadas normas ISO/IEC.

∙ IEEE El Instituto de Ingenieros Eléctricos y Electrónicos (Institute of Electrical and Electronics Engineers o IEEE) es una asociación técnico-profesional mundial dedicada a la estandarización de tecnologías derivadas de la electricidad: inge- niería computacional, tecnologías biomédica y aeroespacial, energía eléctrica, control, telecomunicaciones, electrónica de consumo, etc.

∙ IETF El Grupo de Trabajo en Ingeniería de Internet (Internet Engineering Task Force o IETF) es una organización internacional de estandarización que tiene como objetivo velar para que la arquitectura de la red y los protocolos técni- cos de Internet funcionen correctamente, actuando en áreas como transporte, seguridad, etc.

∙ ANSI El Instituto Nacional Estadounidense de Estándares (American National Stan- dards Institute o ANSI) es una organización sin ánimo de lucro que supervisa el desarrollo de estándares para productos, servicios, procesos y sistemas en los Estados Unidos, siendo miembro de ISO y de IEC. ANSI también se encarga de coordinar estándares estadounidenses con estándares internacionales, de modo que los productos de Estados Unidos puedan utilizarse en todo el mundo.

∙ NIST El Instituto Nacional de Estándares y Tecnología (National Institute of Stan- dards and Technology o NIST) es una agencia de la Administración de Tecno- logía del Departamento de Comercio de los Estados Unidos. La misión de este instituto es promover la innovación y la competencia industrial en Estados Unidos mediante avances en las normas aplicadas y en la propia tecnología. 94 2. Criptografía de clave pública basada en curvas elípticas

Las principales áreas de actuación del NIST son biotecnología, nanotecnología, tecnologías de la información y fabricación avanzada.

∙ SECG El Grupo de Estándares para la Criptografía Eﬁciente (Standards for Eﬃcient Cryptography Group o SECG) es un consorcio internacional fundado en 1998, siendo su principal objetivo facilitar la adopción de la criptografía de curva elíptica. Entre sus miembros se encuentran compañías como Certicom, Entrust, Fujitsu y Visa.

En los próximos apartados se presentan los diferentes estándares relacionados con la criptografía basada en curvas elípticas, agrupados según el campo de aplicación.

2.6.8.1. Protocolos de establecimiento de clave

Mediante el término ECDH nos referimos al esquema de acuerdo de clave basado en el mecanismo Diﬃe-Hellman [61] y las curvas elípticas, deﬁnido en [147] y [174]. Este protocolo se encuentra incluido en los estándares ANSI X9.63 [16] e IEEE 1363 [108, 109]. También puede encontrarse en los documentos SP 800-56A del NIST [189] y SEC 1 del SECG [254]. Además de lo anterior, el algoritmo ECDH forma parte de la Suite B [194] de la NSA (National Security Agency). En el campo de los protocolos de acuerdo de clave, existe otro esquema ampliamente conocido que utiliza curvas elípticas: el protocolo ECQMV (Elliptic Curve Menezes-Qu-Vanstone) [171], incluido igualmente en los documentos ANSI X9.63 [16], IEEE 1363 [108] y 1363a [109], NIST SP 800-56A [189] y SECG SEC 1 [254].

2.6.8.2. Protocolos de ﬁrma digital

La norma FIPS 186-2 [184] incluye los algoritmos y esquemas de ﬁrma digital que pueden ser empleados por las distintas agencias del gobierno de los EE.UU. Dichos algoritmos son DSA, RSA y ECDSA (Elliptic Curve Digital Signature Algorithm). ECDSA es el equivalente al algoritmo DSA empleando curvas elípticas [257]. En los apéndices de FIPS 186-2 [184] y en el estándar ANSI X9.62 [15] se presenta el esquema ECDSA y se describen distintas curvas que pueden ser utilizadas en los procedimientos de ﬁrma. Aunque el documento [184] sólo tiene ámbito de aplicación interna en los EE.UU., al ser información de dominio público, en la práctica se utiliza también fuera de ese ámbito. El esquema ECDSA también se encuentra recogido en el estándar IEEE 1363 [108] y en el documento SEC 1 [254]. Por último, ECDSA es el algoritmo seleccionado por la NSA en la Suite B [194]. 2.6. Criptografía basada en curvas elípticas 95

2.6.8.3. Protocolos de cifrado

Los primeros esquemas de cifrado basados en curvas elípticas 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 más extendido en la actualidad que emplea curvas elípticas es conocido de forma genérica como ECIES (Elliptic Curve Integra- ted Encryption Scheme), y se basa en el modelo propuesto por Bellare y Rogaway en 1997 [26] y reﬁnado posteriormente por Abdalla, Bellare y Rogaway en 1998 [8] y 2001 [9, 10], constituyendo una variante del esquema ElGamal. ECIES puede encontrarse en el estándar ANSI X9.63 [16], en el anexo IEEE 1363a [109] al documento IEEE 1363 [108] y en el estándar ISO/IEC 18033-2 [136]. Asimismo, puede encontrarse una amplia descripción de ECIES, así como numerosos detalles técnicos para su implementación, en el documento SEC 1 [254] realizado por el consorcio industrial SECG.

2.6.9. Patentes

En la actualidad existe un gran número de patentes reconocidas sobre ECC. La siguiente lista muestra algunas de las patentes de mayor relevancia para la presente Tesis.

∙ US 4.567.600 - Method and apparatus for maintaining the privacy of digital messages conveyed by public transmission [205]: describe una forma de realizar cálculos eficientes en cuerpos F2m con bases normales. ∙ US 4.587.627 - Computational method and apparatus for finite field arithmetic [206]: incluye descripciones para mejorar la eficiencia de los cálculos en cuerpos F2m empleando bases normales. ∙ US 4.745.568 - Computational method and apparatus for finite field multiplication [208]: presenta un diseño para la implementación eficiente en hardware del producto de dos elementos del cuerpo F2m utilizando bases normales. ∙ US 5.146.500 - Public key cryptographic system using elliptic curves over rings [207]: describe la utilización de curvas elípticas sobre el anillo ℤm, donde m es un número compuesto.

∙ US 5.272.755 - Public key cryptosystem with an elliptic curve [166]: presenta un criptosistema de curvas elípticas sobre cuerpos Fp donde el orden de la curva es exactamente p. 96 2. Criptografía de clave pública basada en curvas elípticas

∙ US 5.463.690 - Method and apparatus for public key exchange in a cryptographic system [197]: describe un criptosistema de curvas elípticas sobre cuerpos primos, donde los primos tienen el formato p = 2q − C, siendo C un valor pequeño en comparación con 2q. Se trata de una extensión de las patentes US 5.159.632 y US 5.271.061 del mismo autor (no incluidas en este listado por dicho motivo).

∙ US 5.581.616 - Method and apparatus for digital signature authentication [198]: incluye una optimización en el proceso de veriﬁcación de ﬁrmas digitales con curvas elípticas, al deducir la primera coordenada de la suma de dos puntos únicamente a partir de la primera coordenada de dichos puntos.

∙ US 5.787.028 - Multiple bit multiplier [42]: presenta un diseño hardware y las funciones necesarias para la multiplicación en cuerpos F2m n . ∙ US 5.854.759 - Methods and apparatus for efficient finite field basis conversion [231]: describe un método para realizar cambios de base en cuerpos F2m de manera eficiente.

∙ US 5.933.504 - Strengthened public key protocol [44]: recoge procedimientos y recomendaciones para evitar ataques de subgrupos pequeños.

∙ US 6.078.667 - Generating unique and unpredictable values [43]: presenta mé- todos especíﬁcos de generación de números aleatorios para ser utilizados como claves privadas.

∙ US 6.212.279 - Method of elliptic curve cryptographic key exchange using reduced base tau expansion in non-adjacent form [192]: incluye indicaciones para realizar multiplicaciones eﬁcientes en curvas sobre cuerpos F2m en las operaciones de acuerdo de clave.

∙ US 6.243.467 - Method of elliptic curve digital signature generation and verifi- cation using reduced base tau expansion in non-adjacent form [193]: describe el procedimiento para realizar multiplicaciones eficientes en curvas sobre cuerpos F2m en operaciones de firma digital. ∙ US 6.252.960 - Compression and decompression of elliptic curve data points [104]: incluye las operaciones necesarias para realizar la compresión y descom- presión de puntos de una curva elíptica.

∙ US 6.618.483 - Elliptic curve encryption systems [45]: presenta un esquema de cifrado que emplea directamente el producto de la clave privada temporal del emisor y la clave pública del receptor como clave de cifrado, incluyendo la compresión de puntos para su transmisión. Se trata de una extensión de la patente US 6.141.420 (no incluida en este listado por ese motivo). 2.6. Criptografía basada en curvas elípticas 97

∙ US 6.704.870 - Digital signatures on a smartcard [46]: describe una implemen- tación del algoritmo ECDSA con ciertas modiﬁcaciones que tiene en conside- ración las limitaciones de las tarjetas inteligentes.

∙ US 6.782.100 - Accelerated finite field operations on an elliptic curve [47]: recoge una optimización para la multiplicación en cuerpos F2m de un punto de la curva cuya característica principal consiste en no emplear en ciertos pasos la segunda coordenada, recuperando el valor de la segunda coordenada del producto al final de la operación.

∙ EP 1 496 644 A2 - Method for signature and session key generation [41]: describe el protocolo de acuerdo de clave MQV, representando una continuación de la patente EP 0 739 105 A1 (no incluida en este listado por ese motivo).

Capítulo 3

Capacidades criptográﬁcas en Java

Resumen del capítulo

Este capítulo tiene como objetivo presentar las capacidades criptográﬁ- cas del lenguaje Java, en concreto las disponibles en las ediciones Java Standard Edition y Java Card, para lo cual se ofrece una introducción a la programación orientada a objetos y al lenguaje Java en general, junto con un resumen de las principales bibliotecas criptográﬁcas desarrolladas con este lenguaje de programación. En el apartado que hace referencia a Java Card, se ha incluido una descripción detallada de las características generales de este sistema operativo y de las peculiaridades de su modelo de programación.

3.1. Programación orientada a objetos

Los lenguajes de programación orientados a objetos, entre los que se encuentra Java, tienen en común ciertas características desarrolladas en torno al propio concepto de “objeto”, que no es más que la instanciación o concreción de una clase. A su vez, una clase es el molde o prototipo que especiﬁca las variables y métodos comunes de un determinado tipo de elemento. Entre las características que Java comparte con otros lenguajes de programación es imprescindible mencionar los mecanismos de encapsulación, herencia y polimor- ﬁsmo [107], tal como se describen en los siguientes apartados.

99 100 3. Capacidades criptográﬁcas en Java

3.1.1. Encapsulación

La encapsulación consiste en la ocultación de variables y métodos de un objeto, permitiendo su modiﬁcación sólo a través de determinados métodos “públicos”. Este procedimiento conlleva los siguientes beneﬁcios:

∙ Modularidad: el código de un objeto puede ser creado y mantenido independientemente del código de otros objetos. La creación e intercambio de código es, de esta manera, más sencilla. ∙ Ocultación de la información: los objetos pueden ofrecer una interfaz pública para la comunicación con otros objetos, manteniendo a la vez ciertos métodos y variables ocultos, de manera que se puedan modiﬁcar sin afectar a los demás objetos.

3.1.2. Herencia

La herencia es un concepto que relaciona clases de manera jerárquica. Esto permite que los descendientes de una clase hereden todas las variables y métodos de sus ascendientes, además de crear los suyos propios. A estos descendientes se les llama subclases. Al padre inmediato de una clase se le denomina superclase. Una subclase es una versión especializada de su superclase correspondiente que hereda todos sus métodos y variables de instancia.

3.1.3. Polimorﬁsmo

A los métodos que actúan sobre los objetos se les pasa información en forma de parámetros en la llamada al método. Estos parámetros representan los valores de entrada a cada función implementada por la aplicación. Para completar dos tareas diferentes en la mayoría de los lenguajes de programación es necesario tener dos funciones independientes con nombres diferentes. El polimorﬁsmo (un objeto y muchas formas) es un concepto simple que permite que un método tenga múltiples implementaciones que se seleccionan en base al tipo de objeto que se le pasa en la llamada al método, lo que se conoce como “sobrecarga del método”.

3.2. El lenguaje Java

3.2.1. Introducción al lenguaje Java

Los orígenes de Java se remontan al año 1990, cuando un equipo de la compa- ñía Sun Microsystems investigaba, bajo la dirección de James Gosling, el diseño y 3.2. El lenguaje Java 101 elaboración de software para pequeños dispositivos electrónicos en el entorno de un proyecto denominado Green Project. En un primer momento se pensó en la utili- zación de lenguajes de programación como C o C++, pero puesto que para poder compilar un programa en estos lenguajes era preciso adaptarlo a las características de la plataforma en la que debía funcionar, y que cada pocas semanas aparecían en el mercado versiones más potentes y baratas de los chips utilizados, el software que había sido diseñado para un chip determinado debía necesariamente modificarse y adaptarse para explotar las características de los nuevos chips. De esta forma, se hizo patente la necesidad de introducir un nuevo lenguaje de programación que permitiera desarrollar programas independientemente de la plataforma subyacente. Los dispositivos que se pretendían fabricar eran calculadoras, relojes, equipos de música, cafeteras, etc., todos ellos de pequeña capacidad computacional, por lo que el nuevo lenguaje debía ser capaz de generar programas pequeños y rápidos, además de ser fiables y robustos. La primera versión de este nuevo 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, razón por la cual Sun decidió darle una segunda oportunidad apli- cándolo al por entonces incipiente mercado de la navegación por internet. El equipo de James Gosling se planteó como objetivo la utilización de Java como lenguaje de desarrollo para aplicaciones que pudiesen funcionar a través de internet, y como resultado de su trabajo se presentó en 1995 un navegador escrito completamente en Java, denominado HotJava. Este navegador permitía la integración de pequeñas aplicaciones en el interior de las páginas web. El desarrollo de HotJava hizo patente que las características de Java se adaptaban satisfactoriamente a las características de internet. A partir de aquella primera y sencilla versión, Java fue creciendo progresivamente en tamaño y complejidad, ofreciendo un lenguaje de programación utilizado en gran cantidad de campos técnico-científicos. Desde su versión J2SE 1.4, la evolución del lenguaje ha estado regulada por el JCP (Java Community Process), que utiliza las JSR (Java Specification Request) para proponer y especificar cambios en la plataforma Java. El lenguaje en sí mismo está especificado en la JLS (Java Language Specification). Para evitar confusiones con la nomenclatura, a continuación se presentan las distintas versiones del lenguaje Java en función de su fecha de aparición:

∙ JDK 1.0 (23 de enero de 1996): constituyó la versión inicial. La denominación JDK hace referencia al software de desarrollo Java Development Kit. ∙ JDK 1.1 (19 de febrero de 1997): reestructuró el modelo de interfaces gráﬁcas AWT (Abstract Window Toolkit) y presentó el concepto RMI (Remote Method Invocation). 102 3. Capacidades criptográﬁcas en Java

∙ J2SE 1.2 (Playground, 8 de diciembre de 1998): representó el cambio a la denominación Java 2 y el nombre J2SE (Java 2 Platform, Standard Edition) para distinguir esta plataforma de J2EE (Java 2 Platform, Enterprise Edition). Su característica más importante es que la API gráﬁca (Swing) fue integrada en las clases básicas.

∙ J2SE 1.3 (Kestrel, 8 de mayo de 2000): incluyó la máquina virtual HotSpot JVM.

∙ J2SE 1.4 (Merlin, 6 de febrero de 2002): fue el primer lanzamiento de la plataforma Java gestionado por el JCP como el subproyecto JSR 59. Su principal novedad fue la inclusión de un modelo de seguridad integrada que permitía extensiones criptográﬁcas de terceros.

∙ J2SE 5.0 (Tiger, 30 de septiembre de 2004): signiﬁcó el cambio de la numera- ción tipo 1.X a la X.0.

∙ Java SE 6 (Mustang, 11 de diciembre de 2006): en esta versión, Sun cambió el nombre J2SE por Java SE y eliminó el “.0” del número de versión.

∙ Java SE 7 (Dolphin, prevista para 2011): entre otras novedades, permitirá operar con clases BigDecimal utilizando operadores ariméticos en lugar de llamadas a métodos.

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

∙ Java Standard Edition (Java SE): proporciona un entorno de ejecución y un conjunto de API para aplicaciones de ordenadores personales. De manera adicional deﬁne el núcleo de funcionalidades presente en las otras ediciones. 3.2. El lenguaje Java 103

∙ Java Enterprise Edition (Java EE): esta edición constituye un conjunto amplia- do respecto de la versión Standard, estando orientada a entornos empresariales.

∙ Java Micro Edition (Java ME): esta versión deﬁne un subconjunto extendido de la edición Standard, especialmente diseñada para su utilización en teléfonos móviles y PDAs (Personal Digital Assistant).

∙ Java Card (JC): es la versión especíﬁca del lenguaje Java para el mercado de tarjetas inteligentes.

La Figura 3.1 muestra de manera gráﬁca 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 aplicación desarrollada para la plataforma Java. El usuario final utiliza el JRE como parte del entorno Java instalado o como conectores (plugins) en sus navega- dores web [57]. El JRE está constituido por una Java Virtual Machine (JVM), que es el programa que interpreta el código Java, y por las librerías de clases estándar que implementan las diferentes API de Java. Ambos elementos, JVM y API, deben ser consistentes entre sí, de ahí que sean distribuidas de forma conjunta. La máquina virtual Java se inicia automáticamente cuando se lanza el proceso que se desea ejecutar y se detiene cuando éste finaliza. Su objetivo es el de proporcionar un entorno de ejecución independiente de la plataforma hardware y del 104 3. Capacidades criptográficas en Java sistema operativo, que oculte los detalles de la plataforma subyacente y permita que un programa se ejecute siempre de la misma forma en cualquier entorno. La JVM es un programa nativo, es decir, ejecutable en una plataforma específica, capaz de interpretar y ejecutar instrucciones expresadas en un código binario especial denominado bytecode, el cual es generado por el compilador del lenguaje Java. La JVM es una de las piezas fundamentales de la plataforma Java. Básicamente se sitúa en un nivel superior al hardware del sistema sobre el que se pretende ejecutar la aplicación, y actúa como un puente que entiende tanto el bytecode como las instrucciones nativas del sistema. Así, cuando se escribe una aplicación Java, se hace pensando que será ejecutada en una máquina virtual Java, que en última instancia convierte de bytecode a código nativo del dispositivo. La gran ventaja de la máquina virtual Java consiste en permitir la portabilidad del mismo bytecode a diferentes arquitecturas y sistemas operativos. Además de lo anterior, la JVM provee definiciones para el conjunto de 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 implementa- ción aprobada de la JVM debe ser capaz de ejecutar cualquier clase incluida en las especificaciones Java. El código resultante de la compilación es ejecutado por la JVM, la cual realiza la emulación del conjunto de instrucciones, bien por un proceso de interpretación o más habitualmente mediante un compilador JIT (Just In Time), como el compilador HotSpot de Sun. Esta última opción convierte el bytecode a código nativo de la plataforma destino la primera vez que debe interpretar ese bytecode y lo almacena, de manera que si es necesario ejecutar el mismo código de nuevo ya no es necesaria una nueva interpretación del bytecode, lo que permite una ejecución considerablemente más rápida en los casos es que la misma porción de código se ejecuta en más de una ocasión. Los principales inconvenientes son el tiempo necesario al principio del proceso para la compilación a código nativo y los requisitos de memoria para su almacenamiento temporal. La JVM verifica todo bytecode antes de ejecutarlo, por lo que cualquier secuencia de bytecode con un formato desconocido o erróneo no es ejecutada por no ser válida. En más detalle, la JVM tiene instrucciones para los siguientes grupos de tareas:

∙ Operaciones aritméticas.

∙ Carga y almacenamiento de elementos.

∙ Conversión de tipos.

∙ Creación y manipulación de objetos.

∙ Gestión de pilas (push/pop). 3.2. El lenguaje Java 105

∙ Transferencias de control (branching).

∙ Invocación y retorno de los métodos.

∙ Lanzamiento de excepciones.

3.2.3. Características criptográﬁcas de Java

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

Figura 3.2: Ejemplo de utilización de proveedores criptográﬁcos en Java es el caso, y por ejemplo la versión Java SE 6 incluye los siguientes proveedores criptográﬁcos:

∙ SUN

∙ SunRsaSign

∙ SunJCE

∙ SunPKCS11

∙ SunJGSS

∙ SunSASL

∙ XMLDSig

∙ SunPCSC

∙ SunMSCAPI

La razón por la que se incluye un número tan elevado de proveedores se debe a que, inicialmente, los motores criptográficos se crearon de manera independiente 3.2. El lenguaje Java 107 atendiendo a necesidades muy específicas, por lo que el grado de solapamiento de los anteriores proveedores en relación a los algoritmos soportados es mínimo. Por 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 generación de códigos MAC (HmacSHA1, HmacSHA256, etc.) y algoritmos de cifrado simétrico (DES, AES, etc.), y así sucesivamente. Sin embargo, al examinar los algoritmos implementados en los distintos proveedores JCA/JCE desarrollados por Sun, no es posible encontrar ninguna referencia a la criptografía de curva elíptica. De hecho, antes de la versión J2SE 5.0, la arquitectura JCA/JCE no incluía clases para algoritmos relacionados con criptografía de curva elíptica ni tenía estandarizados los nombres de dichos algoritmos para poder realizar llamadas desde un programa Java, por lo que los usuarios que deseaban emplear estos algoritmos dependían de software propietario de otras compañías. Es- ta situación era muy negativa, y afortunadamente la versión J2SE 5.0 solucionó en parte este problema, ya que a partir de dicha versión se inició la inclusión de clases, interfaces y nombres estándar para facilitar a los proveedores el soporte ECC. En concreto, dentro del paquete java.security se incluyeron las interfaces

∙ spec.ECField

∙ interfaces.ECKey

∙ interfaces.ECPublicKey

∙ interfaces.ECPrivateKey y las clases

∙ spec.ECFieldF2m

∙ spec.ECFieldFp

∙ spec.ECGenParameterSpec

∙ spec.ECParameterSpec

∙ spec.ECPoint

∙ spec.ECPrivateKeySpec

∙ spec.ECPublicKeySpec

∙ spec.EllipticCurve 108 3. Capacidades criptográﬁcas en Java

Además, se deﬁnieron los nombres estándar que podían ser utilizados en las llamadas a las clases, tal como se indica a continuación:

∙ Cipher: ECIES. ∙ KeyPairGenerator: EC. ∙ KeyFactory: EC. ∙ KeyAgreement: ECDH, ECMQV. ∙ Signature: NONEwithECDSA, SHA1withECDSA, SHA256withECDSA, SHA- 384withECDSA y SHA512withECDSA.

Con estos elementos, aunque los motores criptográﬁcos de Sun no incluyan implementaciones de ECC, las aplicaciones que deseen utilizar funcionalidades de crip- tografía de curva elíptica al menos pueden hacer uso de bibliotecas criptográﬁcas interoperables y adaptadas a la arquitectura JCA/JCE que hayan sido desarrolladas por terceras empresas.

3.3. Bibliotecas criptográﬁcas

Existen multitud de bibliotecas (libraries) y módulos criptográﬁcos 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 eﬁciencia del código nativo, la mayoría de estas implementaciones están desarrolladas en lenguajes como C++ o directamente en ensamblador. Sin embargo, por ser el objetivo de la presente Tesis, en los siguientes apartados se describirán en mayor detalle los principales productos Java: Cryptix, Bouncy Castle, IAIK y FlexiProvider. La información recogida en los siguientes apartados representa un resumen de [81], [82] y [83]. 3.3. Bibliotecas criptográﬁcas 109

3.3.1. Cryptix

Cryptix [56] fue la primera biblioteca criptográfica de código 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 im- plementación Java del estándar OpenPGP (Cryptix OpenPGP) y un paquete para la utilización de criptografía de curva elíptica (Cryptix Elliptix). Sin actividad desde 2005, en su propia página web se indica que el proyecto se encuentra abandonado. Sin embargo, a efectos comparativos con otras distribuciones resulta interesante conocer el grado de desarrollo del paquete Cryptix Elliptix. Su objetivo era poder proporcionar una implementación Java de los estándares IEEE 1363 [108], ANSI X9.62 [15] y X9.63 [16]. En la última versión proporcionada, el paquete incluía soporte para aritmética tanto sobre Fp (con coordenadas proyectivas) como sobre F2m (con coordenadas afines sobre base polinómica). Sin embargo, no proporcionaba soporte para la generación de los parámetros de la curva. Asimismo, las operaciones de alto nivel (por ejemplo, la firma digital y la verificación de dichas firmas) tampoco estaban disponibles en dicha versión.

3.3.2. Bouncy Castle

Legion of the Bouncy Castle [32] es un grupo de voluntarios que ha desarrollado implementaciones de código abierto de API criptográﬁcas en los lenguajes Java y C#. Su última versión (la 1.45, publicada en enero de 2010) está organizada de tal manera que contiene dos conjuntos de API:

∙ Una API independiente (lo que Bouncy Castle denomina light-weight) de bajo nivel que puede ser utilizada en cualquier entorno (desde Java ME hasta Java SE 6) sin necesidad de compatibilidad con la arquitectura JCE.

∙ Un proveedor ajustado al esquema JCA/JCE.

Además de lo anterior, Bouncy Castle proporciona los siguientes recursos:

∙ Una implementación de la arquitectura JCE 1.2.1.

∙ Una biblioteca para la lectura y escritura de objetos ASN.1.

∙ Una API TLS para el modo cliente.

∙ Generadores de certificados X.509 en sus versiones 1, 2 y 3, así como generadores de listas de revocación de certificados (CRL) y archivos PKCS#12 (utilizados para almacenar claves privadas junto con su correspondiente certi- ficado de clave pública). 110 3. Capacidades criptográficas en Java

∙ Generadores y procesadores para S/MIME y CMS (PKCS7/RFC 3852), OCSP (RFC 2560), TSP (RFC 3161) y OpenPGP (RFC 2440).

En lo referente a criptografía de curvas elípticas, Bouncy Castle incluye implementaciones de ECDH, ECDSA y ECIES, aunque como elemento mejorable la implementación de ECIES sólo permite un conjunto de parámetros ﬁjos (algoritmo de acuerdo de clave ECDH, función HMAC-SHA1 y algoritmo de derivación de claves KDF2). Puesto que son muchas las clases implementadas para dichas funcionalidades, únicamente las siguientes clases del paquete org.bouncycastle.math.ec serán citadas como ejemplo:

∙ ECCurve: representa una curva elíptica mediante su ecuación de Weierstrass.

∙ ECFieldElements: representa un elemento del cuerpo ﬁnito utilizado.

∙ ECPoint: representa los puntos de una curva elíptica e implementa la aritmé- tica de los puntos.

Todas las clases abstractas anteriores (ECCurve, ECFieldElements y ECPoint) son implementadas por dos subclases derivadas, Fp y F2m, representando a las curvas definidas sobre cuerpos finitos primos y binarios, respectivamente. A principios de 2008 se publicó un estudio [161] que demostraba la posibilidad de utilizar un fallo en la implementación de la clase ECPoint para realizar ataques reales (por ejemplo, contra el esquema de cifrado ECIES). Esta vulnerabilidad fue posteriormente corregida en la versión 1.33. Por el grado de soporte (tanto para operaciones de firma como cifrado) y desarrollo continuado, Bouncy Castle es posiblemente uno de los mejores paquetes cripto- gráficos de uso gratuito que se puede encontrar actualmente en internet, tanto para aplicaciones ECC como para las que utilicen otros algoritmos (RSA, AES, etc.).

3.3.3. IAIK

El Institut für Angewandte Informationsverarbeitung und Kommunikationstech- nologie (Institute for Applied Information Processing and Communications) de la Universidad de Graz [260] ha desarrollado un conjunto de herramientas criptográfi- cas escritas en Java, cuyos principales exponentes son IAIK-JCE (módulo principal con los algoritmos RSA, DES, AES, Blowfish, etc., y cuya versión más reciente es la 3.18, lanzada en agosto de 2009), IAIK-iSaSiLk (implementación Java de TLS 1.0 y SSL 3.0, cuya versión 4.4 está disponible desde febrero de 2010) e IAIK-ECC (cuya versión 2.19 fue lanzada en agosto de 2009). 3.3. Bibliotecas criptográficas 111

El paquete IAIK Elliptic Curve Cryptography Library presenta las siguientes características:

∙ Es compatible con los estándares IEEE 1363 [108] y ANSI X9.62 [15].

∙ Incluye una implementación ECDSA compatible con la arquitectura de 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 aritmética sobre cuerpos primos y binarios. En cuerpos binarios se emplea únicamente la representación sobre base polinómico por problemas de patentes.

∙ Permite deﬁnir y realizar operaciones con los puntos de la curva en coordenadas aﬁnes y proyectivas.

∙ Ofrece una implementación de ECDH con y sin multiplicación del cofactor.

∙ Calcula la codiﬁcación ASN.1 correspondiente a ﬁrmas digitales, claves públi- cas y claves privadas.

Además de lo anterior, la biblioteca IAIK-ECC permite las siguientes opciones de personalización:

∙ Precálculo de puntos: permite precalcular y almacenar un conjunto de puntos para mejorar la generación de claves y la realización de firmas posteriores. El precálculo no tiene ninguna influencia sobre la verificación de firmas, y debe ser utilizada en caso de generación de muchos puntos y firmas sobre la misma curva. Por defecto esta opción se encuentra desactivada.

∙ Codificación: es posible especificar el identificador de objeto (OID) o codificar los parámetros explícitamente. Por defecto la opción utilizada es la codificación explícita.

∙ Comprobación de puntos: la implementación permite opcionalmente comprobar si los puntos decodiﬁcados se encuentran sobre una determinada curva. Por defecto esta opción se encuentra desactivada.

Es necesario destacar como aspecto negativo la ausencia de una implementación de ECIES. El software IAIK está disponible gratuitamente en forma de versiones beta y de evaluación, siendo necesario adquirir una licencia para la utilización del producto completo. 112 3. Capacidades criptográﬁcas en Java

3.3.4. FlexiProvider

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

∙ Curvas sobre Fp de ANSI X9.62: prime192v1, prime192v2, prime192v3, pri- me239v1, prime239v2, prime239v3 y prime256v1.

∙ Curvas sobre F2m de ANSI X9.62: c2pnb163v1, c2pnb163v2, c2pnb163v3, c2tnb- 191v1, c2tnb191v2, c2tnb191v3, c2pnb208w1, c2tnb239v1, c2tnb239v2, c2tnb- 239v3, c2pnb272w1, c2tnb359v1, c2pnb368w1 y c2tnb431r1.

∙ Curvas sobre Fp de SEC 2: secp112r1, secp112r2, secp128r1, secp128r2, secp160- k1, secp160r1, secp160r2, secp192k1, secp224k1, secp224r1, secp256k1, secp384- r1 y secp521r1.

∙ Curvas sobre Fp del Grupo Brainpool: brainpoolP160r1, brainpoolP192r1, brainpoolP224r1, brainpoolP256r1, brainpoolP320r1, brainpoolP384r1 y brain- poolP512r1.

∙ Curvas sobre Fp del Grupo CDC: desde la curva primeCurve 1 a la curva primeCurve 38.

La versión del algoritmo ECIES del paquete ECProvider es notablemente ﬂe- xible, permitiendo un elevado número de combinaciones de parámetros. Además del código binario y la documentación, su página web incluye ejemplos y tutoriales sobre cómo utilizar los paquetes comentados. Por todos estos motivos, los paquetes del proyecto FlexiProvider constituyen una alternativa muy interesante para el desarrollo de aplicaciones que utilicen funcionalidades ECC. 3.4. Java Card 113

3.4. Java Card

3.4.1. Introducción al lenguaje Java Card

La tecnología Java Card combina un subconjunto del lenguaje Java con un entorno de ejecución 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 características de seguridad de las tarjetas inteligentes. Poco después de presentar el primer borrador de las API Java Card, a Schlumberger se le unieron Gemplus y Bull pasando a crear el Java Card Forum, un consorcio creado para identificar y resolver los problemas asociados a la tecnología Java Card. Tras la presentación de Java Card 1.0, Sun comenzó a colaborar activamente con los fabricantes de tarjetas y el resultado fue el anuncio en noviembre de 1997 de Java Card 2.0. Esta nueva versión era bastante diferente de la inicial, ya que proporcionaba un mecanismo de programación orientado a objetos y mejoraba el nivel de detalle de la especificación del entorno de ejecución de aplicaciones, aunque por contra no incluía la especificación del formato de los applet (aplicaciones Java Card) para su descarga. Debido a la necesidad de adaptar las capacidades del lenguaje Java a las limitaciones físicas de las tarjetas inteligentes, desde su inicio se hizo evidente la imposibilidad de implementar algunas de sus características, tal como se describe en detalle en §3.4.5. Ello no ha impedido, sin embargo, su masiva utilización en industrias como la de la telefonía móvil. La versión Java Card 2.1 fue lanzada en marzo de 1999 y consistía en tres especificaciones: Java Card API, Java Card Runtime Environment y Java Card Virtual Machine.

∙ Java Card API: define los paquetes Java tanto del núcleo como de las extensiones disponibles para las tarjetas inteligentes. ∙ Java Card Runtime Environment (Java Card RE): define el comportamiento en tiempo de ejecución de los applets. ∙ Java Card Virtual Machine (JCVM): define un subconjunto del lenguaje Java y una máquina virtual para las tarjetas inteligentes.

Aparte de mejorar las API existentes, la versión 2.1 deﬁnió explícitamente la máquina virtual y el formato de applets de forma que su descarga fuera interoperable. 114 3. Capacidades criptográﬁcas en Java

La versión 2.2 fue lanzada en septiembre de 2002, y entre sus novedades se pueden citar las siguientes:

∙ Implementación de JCRMI (Java Card Remote Method Invocation).

∙ Soporte para cuatro canales lógicos.

∙ Mejoras en la gestión de los recursos de memoria.

∙ Inclusión de nuevas clases para algoritmos criptográﬁcos (AES, claves para algoritmos de curva elíptica, etc.).

En marzo de 2006 se anunció la disponibilidad de la revisión Java Card 2.2.2, que incluyó las siguientes mejoras:

∙ Extensión del soporte de canales lógicos, permitiendo la gestión de hasta veinte canales.

∙ Implementación de los algoritmos resumen (también llamados algoritmos hash [78, 172]) SHA-256, SHA-384 y SHA-512.

∙ Inclusión de un paquete de extensión con clases relacionadas con la tecnología de reconocimiento biométrico.

Finalmente, en marzo de 2008 se publicaron las especiﬁcaciones Java Card 3.0, que a ﬁn de adaptarse a las necesidades de los servicios actuales presenta dos ediciones diferenciadas:

∙ Classic Edition: representa una evolución de Java Card 2.2.2, incluyendo no sólo la corrección de errores detectados desde el lanzamiento de la anterior versión, sino también nuevas características como la posibilidad de usar claves RSA de 4096 bits o el soporte para claves y algoritmos descritos en la Suite B de la NSA [194].

∙ Connected Edition: esta versión presenta un entorno de ejecución mejorado y una nueva máquina virtual que proporciona características orientadas a red como el soporte de aplicaciones web mediante servlets.

3.4.2. Java Card API

En este apartado se presenta de forma resumida la lista de API Java Card disponibles para su utilización en la versión 3.0 Classic Edition: 3.4. Java Card 115

∙ java.lang Este paquete representa el pilar fundamental del lenguaje Java, con soporte para algunas de sus clases básicas. En Java Card, este paquete constituye un subconjunto del paquete java.lang de Java Standard Edition, donde sólo están permitidas algunas clases como Object (la raíz de todas las clases Ja- va) o Throwable (la clase base para todas las excepciones), y dentro de ellas únicamente se encuentran disponibles algunos métodos.

∙ java.io Se trata de un subconjunto del paquete java.io de la edición Standard que contiene como única clase java.io.IOException, la cual es la superclase de java.rmi.RemoteException. Su presencia es necesaria para mantener una jerarquía de excepciones idéntica a la de la versión Standard.

∙ java.rmi Incluye las clases básicas para la funcionalidad JCRMI.

∙ javacard.framework Representa el conjunto de clases e interfaces que conforman el núcleo de la funcionalidad de un applet Java Card. Por ejemplo, incluye la clase Applet que es básica para la ejecución e interacción de un applet con el JCRE, o la clase APDU utilizada para la comunicación con la tarjeta inteligente con independencia del protocolo físico empleado.

∙ javacard.framework.service Proporciona un entorno de clases e interfaces que permiten a los applet Java Card ser incluidos en un registro de manera que posteriormente se puedan re- enviar las APDU entrantes a las aplicaciones registradas. También incluye una interfaz que incluye métodos para procesar los comandos APDU de múltiples servicios.

∙ javacard.security Su diseño se basa en el paquete java.security de Java SE e incluye las clases e interfaces que dan soporte a algunas de las funcionalidades criptográﬁcas de las tarjetas Java Card, por ejemplo las relacionadas con generación de números aleatorios, resúmenes y ﬁrmas digitales.

∙ javacardx.apdu Se trata del primer paquete de extensión del API Java Card. Los paquetes de extensión son fácilmente identificables por comenzar siempre por el término javacardx. En concreto, este API permite la comunicación con la tarjeta mediante APDU según el formato definido en las normas ISO/IEC 7816. 116 3. Capacidades criptográficas en Java

∙ javacardx.biometry Esta interfaz contiene la funcionalidad necesaria para implementar capacidades biométricas en Java Card.

∙ javacardx.crypto Se trata de un paquete de extensión que incluye las funcionalidades crip- tográficas para el cifrado y descifrado de datos, funcionalidades que pueden estar sujetas a controles de exportación. Tanto este paquete como el javacard.security definen las interfaces que los applet utilizarán, pero no proporcionan ninguna implementación, que debe ser desarrollada por el 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 métodos para cifrar y descifrar mensajes, y la interfaz KeyEncryption que define los métodos para permitir el acceso a la implementación de una clave determinada.

∙ javacardx.external Este paquete permite el acceso a subsistemas de memoria que no son directamente gestionables por el entorno de ejecución de las tarjetas Java Card. Se compone principalmente de la clase Memory y la interfaz MemoryAccess.

∙ javacardx.framework Este paquete opcional incluye las clases e interfaces para la implementación eﬁciente de applets Java. Si el paquete está presente, también deben estarlo los subpaquetes math, tlv y util.

∙ javacardx.framework.math Este paquete contiene funcionalidad común para la utilización de aritmética BCD (Binary-Coded Decimal) y el cálculo de paridades.

∙ javacardx.framework.tlv Paquete para la gestión de datos con formato BER TLV basados en las reglas de codiﬁcación ASN.1 BER del estándar ISO/IEC 8825-1 [127], incluyendo la edición y procesamiento de objetos BER TLV en los buﬀers de entrada/salida.

∙ javacardx.framework.util Se trata de una API que contiene utilidades para la gestión de arrays de componentes de tipo byte, short o int.

∙ javacardx.framework.util.intx Este paquete incluye la clase JCint, equivalente en su deﬁnición a la clase javacard.framework.Util, pero con el objetivo de utilizar datos de tipo int. 3.4. Java Card 117

3.4.3. Java Card Runtime Environment

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

Figura 3.3: Arquitectura Java Card y de su entorno de ejecución

3.4.3.1. Ciclo de vida de la máquina virtual Java Card

El ciclo de vida de la máquina virtual Java Card coincide con el de la propia tarjeta: comienza una vez la tarjeta inteligente ha sido creada y probada (aunque antes de que sea entregada a su propietario ﬁnal) y termina cuando la tarjeta es descartada o destruida. La JCVM no se ve afectada cuando se retira la alimentación 118 3. Capacidades criptográﬁcas en Java a la tarjeta, puesto que su estado se almacena en memoria no volátil (al contrario de lo que ocurre con los datos almacenados en la RAM, que sí se pierden cuando no existe alimentación). Una vez la JCVM comienza su ejecución, inicializa el JCRE y crea todos los objetos del entorno que estarán disponibles a lo largo de la vida útil de la tarjeta. Tras su inicio, las interacciones con la tarjeta son controladas por alguno de los applets que residen en ella.

3.4.3.2. Ciclo de vida de un applet Java Card

Cada applet que pueda residir en una tarjeta Java Card queda unívocamente identificado por su Application ID (AID). Tal como queda definido en la norma ISO/IEC 7816-5 [117], un AID es una secuencia de entre 5 y 16 bytes que sirve para la selección directa de aplicaciones. Para adaptarse a las especificaciones Java Card, todos los applets deben exten- der la clase abstracta Applet, que define los métodos utilizados por el JCRE para controlar el ciclo de vida de un applet, tal como puede apreciarse en la Figura 3.4.

Figura 3.4: Métodos para la gestión del ciclo de vida de un applet Java Card

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

Figura 3.5: Métodos implicados en la gestión de un applet

Al ﬁnalizar su ciclo de vida, el JCRE notiﬁca al applet que ha sido deseleccionado invocando el método Applet.deselect(), que típicamente incluye la lógica para almacenar los datos que todavía se encontraran en la memoria RAM y devolver el applet a su estado inactivo.

3.4.3.3. Sesiones Java Card y canales lógicos

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

3.4.3.4. Aislamiento de applets y compartición de objetos

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

Figura 3.6: Compartición de objetos en Java Card

1. El applet a solicita acceso a la interfaz compartida del applet c mediante una llamada al método JCSystem.getAppletShareableInterfaceObject(). 2. El entorno de ejecución JCRE solicita entonces al applet c su interfaz compartida invocando el método getShareableInterfaceObject() en nombre del applet a. 3.4. Java Card 121

3. Si el applet c permite la compartición, el applet a obtendrá una referencia a los objetos compartidos del applet c, que podrá utilizar a partir de dicho momento.

En comparación, puesto que los applets a y b están en el mismo contexto de ejecución, no necesitan realizar la operativa anterior para compartir objetos.

3.4.4. Java Card VM

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

Figura 3.7: Esquema de conversión a ﬁcheros CAP 122 3. Capacidades criptográﬁcas en Java

3.4.5. Limitaciones del lenguaje Java Card

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

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

∙ Carga dinámica de clases Java Card no permite la carga dinámica de clases, por lo que los applets que se ejecutan en la tarjeta sólo pueden hacer referencia a clases que ya estuvieran presentes en la tarjeta antes del inicio de la ejecución del applet.

∙ Ejecución multihilo A diferencia de Java SE, Java Card no permite múltiples hilos de ejecución. Por dicho motivo, los applets Java Card no pueden utilizar la clase Thread ni ninguno de los términos relacionados con la ejecución multihilo.

∙ Clonado Java Card no permite el clonado de objetos, por lo que la clase Object no implementa el método clone, ni proporciona un interfaz Cloneable que pueda ser utilizado por las aplicaciones.

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

3.4.6. Características criptográﬁcas en Java Card

De forma equivalente a la situación en Java SE, las API criptográficas de Java Card definen una serie de servicios criptográficos y las interfaces para acceder a dichos servicios, lo cual en la práctica permite la separación de interfaces e implementaciones. Por ofrecer un ejemplo sencillo, para proporcionar la funcionalidad de resúmenes mediante el algoritmo MD5, un proveedor JCRE puede crear una imple- mentación de la clase MessageDigestMD5 que extienda la clase MessageDigest. De esta forma, la clase MessageDigestMD5 impondría sus métodos frente a los de la clase base en lo que respecta a la implementación del algoritmo MD5. Entrando en detalle, las API criptográficas de Java Card replican el 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 diseño limitaciones para su exporta- ción. En los siguientes apartados se detallan las principales características de ambos paquetes.

3.4.6.1. javacard.security

El paquete javacard.security contiene varias interfaces para implementar claves simétricas y asimétricas, la clase generadora de claves (key builder), las clases para realizar autenticaciones de resúmenes de mensajes y ﬁrmas digitales, así como la clase utilizada en la generación de datos aleatorios (los cuales son producidos en la forma de arrays de tipo byte de longitud variable y deﬁnible en la llamada al método). El Cuadro 3.1 detalla todas las clases e interfaces del paquete javacard.security disponibles en Java Card 3.0 Classic Edition.

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

Clase o interfaz Descripción ECKey Interfaz base para implementaciones de claves pú- blicas y privadas para curvas elípticas 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 correspondería con una parte del mensaje de la que ya se hubiera obtenido previamente su valor Key Interfaz base para todas las claves KeyAgreement Clase abstracta base para la implementación de 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 pública y otra privada) KoreanSEEDKey Clave de 128 bits para operaciones con el algoritmo Korean Seed MessageDigest Clase abstracta base para algoritmos resumen PrivateKey Interfaz base para claves privadas de algoritmos asimétricos PublicKey Interfaz base para claves públicas de algoritmos asimétricos RandomData Clase abstracta base para la generación de datos aleatorios RSAPrivateCrtKey Interfaz de una clave privada RSA con el formato CRT (Chinese Remainder Theorem) RSAPrivateKey Interfaz de una clave privada RSA con el formato módulo/exponente RSAPublicKey Interfaz de una clave pública RSA SecretKey Interfaz base para todas las claves de algoritmos simétricos Signature Clase abstracta base para algoritmos de firma digital 3.4. Java Card 125

Clase o interfaz Descripción SignatureMessageRecovery Interfaz para operaciones de ﬁrma con recupera- ción de mensaje

Cuadro 3.1: Clases e interfaces del paquete javacard.security

3.4.6.2. javacardx.crypto

El paquete javacardx.crypto es una API de extensión que contiene la clase cipher, la cual permite el uso de algoritmos de cifrado, y la interfaz KeyEncrypt, que permite implementar claves de cifrado. El Cuadro 3.2 muestra las clases del paquete javacardx.crypto.

Clase o interfaz Descripción Cipher Clase abstracta base que proporciona la funcionalidad para cifrado y descifrado de datos KeyEncryption 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 versión en incluir soporte para criptografía de curva elíptica. En concreto, en dicha versión se deﬁnieron los siguientes elementos:

∙ Nuevas clases ECKey, ECPrivateKey y ECPublicKey para la creación y gestión de claves ECC públicas y privadas sobre cuerpos primos y binarios.

∙ Extensión de la clase KeyPair para permitir la manipulación de pares de claves sobre cuerpos Fp y F2m . ∙ Extensión de la clase KeyAgreement con las funciones de acuerdo de clave DH (Diﬃe-Hellman) y DHC (Diﬃe-Hellman with Cofactor), con la peculiaridad de que la salida de esas funciones no es la primera coordenada del elemento secreto compartido, sino el resultado de pasar este dato a través de la función SHA-1.

∙ Extensión de la clase KeyBuilder, que deﬁne las longitudes de clave permitidas para ECC y otros criptosistemas. En el caso de curvas elípticas sobre cuerpos primos, las longitudes válidas en Java Card 2.2 son 112, 128, 160 y 192 bits, mientras que en el caso de curvas sobre cuerpos binarios, las longitudes posibles son 113, 131, 163 y 193 bits. 126 3. Capacidades criptográﬁcas en Java

∙ Extensión de la clase Signature con la implementación del esquema de ﬁrma digital ECDSA utilizando la función resumen SHA-1.

Las versiones Java Card 2.2.1 y 2.2.2 no introdujeron ninguna novedad en re- lación a la criptografía de curvas elípticas. En cambio, la versión Java Card 3.0 sí presenta algunas novedades en cuanto al soporte ECC, tal como se detalla a conti- nuación:

∙ Mientras que las longitudes permitidas para los cuerpos binarios continúan siendo 113, 131, 163 y 193 bits, en los cuerpos primos es posible elegir como longitud 112, 128, 160, 192, 224, 256 y 384 bits.

∙ La implementación de las funciones de acuerdo de clave DH y DHC se ha extendido para incluir un modo especial en el que la salida de la función es directamente el elemento secreto compartido, eliminando la utilización de la función SHA-1 en la generación de ese dato.

∙ Debido a la disponibilidad en Java Card de la familia de funciones resumen SHA-2, la implementación del esquema de ﬁrma digital ECDSA permite a partir de la versión Java Card 3.0 utilizar ECDSA en combinación con las funciones SHA-1, SHA-224, SHA-256, SHA-384 y SHA-512.

3.5. Programación en Java Card

El desarrollo de una aplicación Java Card conlleva los siguientes pasos:

1. Escribir el código Java de la aplicación en ﬁcheros con extensión .java.

2. Compilar el código para obtener ﬁcheros con extensión .class.

3. Convertir los ﬁcheros .class en un ﬁchero CAP.

4. Veriﬁcar que el ﬁchero .cap es válido.

5. Instalar el ﬁchero CAP en la tarjeta.

La principal diferencia respecto al desarrollo de aplicaciones Java SE consiste en la necesidad de convertir los ficheros .class en ficheros .cap. Este paso se realiza fuera de la tarjeta inteligente y permite optimizar el tamaño de la aplicación. Los ficheros CAP son en realidad contenedores con formato JAR (que a su vez son una extensión del formato de compresión ZIP) donde se almacenan los paquetes convertidos. Junto con el fichero .cap, la herramienta de conversión de Java Card genera un fichero de 3.5. Programación en Java Card 127

Figura 3.8: Fases del desarrollo de un applet Java Card exportación con extensión .exp que contiene información sobre la interfaz pública de todas las clases del paquete. La Figura 3.8 muestra de forma gráﬁca el proceso completo de desarrollo de un applet Java Card.

Capítulo 4

Estudio y análisis del esquema de cifrado ECIES

Resumen del capítulo

En este capítulo se describen de forma completa las distintas variantes de ECIES incluidas en los estándares ANSI X9.63, IEEE 1363a, ISO/IEC 18033-2 y SECG SEC 1, identiﬁcando las principales diferencias existentes entre los cuatro estándares mencionados. De forma adicional, se incluye un análisis de la seguridad de ECIES que recoge las indicaciones y recomendaciones sugeridas en los estudios más recientes sobre este tema.

4.1. Criptosistemas de curvas elípticas

Los primeros esquemas de cifrado basados en curvas elípticas 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 envío de un cierto mensaje m al usuario V, donde E es una curva elíptica deﬁnida sobre el cuerpo ﬁnito de q elementos Fq y existe una relación públicamente conocida de mensajes en claro m y puntos de la curva Pm.

129 130 4. Estudio y análisis del esquema de cifrado ECIES

Algoritmo 4.1 Criptosistema Massey-Omura con curvas elípticas 1. U debe generar un número entero aleatorio c, con 0 < c < #E, siendo c y el orden de la curva #E primos relativos, y transmitir el punto de la curva calculado como c Pm a V. 2. A continuación, V debe generar un número entero aleatorio d (donde igualmente 0 < d < #E y los valores d y #E son primos relativos), y transmitir el punto de la curva d c Pm a U. 3. Tras su recepción, U transmitirá de vuelta a V el punto de la curva ′ ′ c d c Pm = d Pm, puesto que c c ≡ 1 (mod #E).

4. Por último, el usuario V obtendrá el punto de la curva curva Pm asociado ′ ′ al mensaje m calculando d d Pm, ya que d d ≡ 1 (mod #E).

De forma equivalente, dada una curva E, un generador G y una relación pública- mente conocida de mensajes en claro y puntos de la curva, el Algoritmo 4.2 muestra los pasos necesarios para que el usuario U envíe el mensaje m cifrado al usuario V utilizando la versión del esquema de ElGamal con curvas elípticas.

Algoritmo 4.2 Criptosistema ElGamal con curvas elípticas 1. V debe elegir aleatoriamente un valor v y hacer pública su clave V = v G.

2. A partir del mensaje m y del punto de la curva Pm que le corresponda, el usuario U debe generar aleatoriamente un valor k y enviar el par de puntos (k G, Pm + k V ) a V. 3. Tras la recepción del par de puntos, el usuario V recuperará el punto de la curva que representa el mensaje en claro multiplicando el punto k G por el valor v, con lo que obtendrá v(k G) = k(v G) = k V , y restando a continua- ción el punto así generado de Pm + k V .

Una de las principales desventajas de los esquemas anteriores consiste en el limitado número de mensajes a cifrar, siendo necesario establecer una relación entre cada mensaje y un punto de la curva elíptica. Si bien es cierto que si se utilizan curvas elípticas cuyo orden #E es un valor elevado esta limitación es más teórica que práctica, la obligatoriedad de construir tablas donde se relacionen cada uno de los posibles mensajes (y que estos sean previamente conocidos) limita la utilidad de estos criptosistemas a entornos cerrados donde todos los posibles mensajes estén estipulados (empresas, pequeños grupos de usuarios, etc.). El criptosistema Menezes-Vanstone con curvas elíptica fue diseñado precisamente para solventar esa limitación, puesto que en lugar de hacer corresponder cada mensaje con un punto de la curva E, representaban los mensajes en claro como 4.1. Criptosistemas de curvas elípticas 131

∗ ∗ ∗ pares ordenados del producto cartesiano Fq × Fq, donde Fq = Fq ∖ {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 codiﬁcado fácilmente en un par ordenado (por ejemplo, utilizando una codiﬁcación similar a la empleada en los ejemplos de §2.4.2.2y§2.4.3.2). Como contrapartida negativa, en lugar de transformar cada mensaje en un único punto de la curva (independientemente de cuál fuera el mensaje, como ocurría con las versiones de Massey-Omura y ElGamal), la longitud del mensaje cifrado depende de la longitud del mensaje en claro. El Algoritmo 4.3 muestra de forma resumida los pasos necesarios para completar los procesos de cifrado y descifrado de un mensaje representado como el elemento ∗ ∗ x = (x1, x2) ∈ Fq × Fq utilizando el criptosistema Menezes-Vanstone con curvas elípticas. En la notación empleada, el punto G tiene orden n y es un generador de un subgrupo cíclico de E, mientras que como es habitual v y V = v G representan respectivamente la clave privada y pública del usuario V.

Algoritmo 4.3 Criptosistema Menezes-Vanstone con curvas elípticas 1. U debe elegir aleatoriamente un valor k ∈ {1, . . . , n − 1} y calcular los valores Y0 = k G ∈ E, y1 = c1 x1 (mod p) y y2 = c2 x2 (mod p), donde el elemento (c1, c2) = k V .

2. A continuación, U enviará el criptograma C = (Y0, y1, y2) a V. 3. Tras la recepción del criptograma, el usuario V recuperará el par or- −1 denado x = (x1, x2) mediante las operaciones x1 = y1 c1 (mod q) y −1 x2 = y2 c2 (mod q), donde v Y0 = (c1, c2).

En este esquema, el factor de expansión es 2, puesto que a partir del mensaje ∗ en claro x = (x1, x2), compuesto por dos elementos del cuerpo finito Fq, se obtiene ∗ el criptograma (Y0, y1, y2), donde y1, y2 ∈ Fq e Y0 ∈ E (y por lo tanto tiene dos coordenadas que pertenecen al cuerpo primo que define la curva), con lo que el número total de elementos del cuerpo finito a transmitir es 4. Si se utiliza compresión de puntos (ver §2.6.5), entonces el factor de expansión se reduce prácticamente a 1.5, puesto que además de la primera coordenada del punto es necesario enviar un byte que incluye la información necesaria para recuperar la segunda coordenada. En comparación, el factor de expansión de la variante de ElGamal con curvas elípticas es 2 si se considera que el mensaje en claro es un punto de la curva, mientras que si se interpreta que el número total de mensajes es #E(Fq) ≈ q, entonces el factor de expansión sería aproximadamente 4 [218]. El hecho de tener un factor de expansión igual a 2 conlleva que el cifrado de volúmenes de información elevados genere criptogramas de tamaño mucho mayor que utilizando un algoritmo de clave simétrica como por ejemplo AES. 132 4. Estudio y análisis del esquema de cifrado ECIES

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

ECIES PSEC ACE u ∈ [1, n − 1] r ∈ {0, 1}l u ∈ [1, n − 1] U = u G K = KDF (032∣∣r) U = u G P = u V K = t∣∣k1∣∣k2 P = u W ′ P = (xP , yP ) u = t (mod n) P = u Z K =KDF (U∣∣xP ) U = u G P = (xP ′ , yP ′ ) K = k1∣∣k2 P = u V = H(U∣∣P ) L ′ c =ENC k1 (m) s = r KDF (132∣∣U∣∣P ) u = u (mod n) ′ tag=MACk2 (c) c =ENC k1 (m) Q = u X + u Y ′ C =(U, c,tag) tag=MACk2 (c) K =KDF (U∣∣xP ) C =(U, c, s,tag) K = k1∣∣k2

c =ENC k1 (m)

tag=MACk2 (c) C =(U, P, Q, c,tag)

Cuadro 4.1: Comparativa del proceso de cifrado en ECIES, PSEC y ACE

El signiﬁcado de los elementos incluidos en el Cuadro 4.1 es el siguiente:

∙ G: generador del subgrupo cíclico del grupo de puntos de la curva elíptica utilizada en los cálculos. ∙ n: orden del punto G. ∙ u: clave privada temporal del usuario U que envía el criptograma. ∙ U: clave pública temporal de U, de manera que U = u G. ∙ v: clave privada permanente del usuario V que recibe el criptograma. ∙ V : clave pública permanente de V. En ECIES y PSEC, V = v G, mientras que en ACE la clave pública está compuesta por cuatro puntos de la curva, de manera que V = (W, X, Y, Z). ∙ r: cadena binaria aleatoria cuya longitud l está preﬁjada.

∙ 032: cadena binaria de 32 bits que representa el número entero 0.

∙ 132: cadena binaria de 32 bits que representa el número entero 1. ∙ t: cadena binaria de ( + 128) bits que debe interpretarse como un número entero, donde es un parámetro de seguridad que toma el valor de la longitud en bits asociada al cuerpo ﬁnito sobre el que se construye la curva elíptica (es

decir, el valor ⌈log2 p⌉ o m, según el tipo de cuerpo ﬁnito). 134 4. Estudio y análisis del esquema de cifrado ECIES

Como puede apreciarse en el Cuadro 4.1, las principales diferencias entre los esquemas ECIES, PSEC y ACE son las siguientes:

∙ Tanto en ECIES como en PSEC, la clave pública del receptor del criptograma es el punto de la curva V = v G, mientras que en ACE la clave pública está formada por cuatro puntos, de manera que V = (W, X, Y, Z).

∙ PSEC utiliza dos veces la función KDF, mientras que ECIES y ACE sólo la utilizan una vez.

∙ ECIES y ACE utilizan la primera coordenada de un punto de la curva generado durante los cálculos intermedios (en lugar de las dos coordenadas) como parámetro de entrada de la función KDF, mientras que en PSEC es obligatorio utilizar las dos coordenadas.

∙ PSEC es el único esquema que utiliza la función XOR durante el proceso de generación de claves (independientemente de su posible utilización como función de cifrado simétrico).

∙ Los criptogramas de ECIES están formados por tres elementos (el punto U, el mensaje cifrado c y la etiqueta tag), mientras que los criptogramas de PSEC añaden además el elemento s y los de ACE incluyen dos puntos de la curva elíptica (P y Q).

Una vez presentado el esquema general del proceso de cifrado de los tres esquemas, y con el fin de seleccionar el más adecuado, es necesario evaluar tres aspectos fundamentales: eficiencia, seguridad y adaptabilidad a las plataformas hardware de trabajo. Respecto al análisis de su eficiencia, los siguientes cuadros muestran datos to- mados de [196]. En concreto, el Cuadro 4.2 muestra una comparativa del número de operaciones necesarias para llevar a cabo el proceso de cifrado en los tres esquemas. En él se puede comprobar que ECIES es el esquema que, de forma global, utiliza menos operaciones.

ECIES PSEC ACE Producto escalar 2 2 5 Suma de puntos 0 0 1 Generación de números aleatorios 1 1 1 Llamadas a función KDF 1 2 1 Llamadas a función H 0 1 1 Llamadas a función MAC 1 1 1 Llamadas a función resumen 1 1 1

Cuadro 4.2: Número de operaciones para el cifrado en ECIES, PSEC y ACE 4.1. Criptosistemas de curvas elípticas 135

Por su parte, el Cuadro 4.3 presenta el número de ciclos de reloj y el tiempo de procesado de la operación de cifrado para los tres esquemas utilizando en todos los casos el mismo PC equipado con un procesador Pentium III con una frecuencia de reloj de 500 MHz [196].

ECIES PSEC ACE Ciclos de reloj (miles) 2500 2500 6250 Tiempo (milisegundos) 5 5 12.5

Cuadro 4.3: Rendimiento del cifrado en ECIES, PSEC y ACE

Otro de los aspectos a tener en cuenta para evaluar la eﬁciencia de los tres esquemas de cifrado es su factor de expansión. El Cuadro 4.4 muestra las longitudes en bytes de las claves públicas y privadas, así como del criptograma generado, considerando que la longitud de los elementos del cuerpo, del mensaje a cifrar y de la salida de la función resumen son, respectivamente, 20, 16 y 20 bytes, y habiendo sido utilizada la técnica de compresión de puntos en la representación binaria de los puntos de la curva.

ECIES PSEC ACE Clave privada 20 20 80 Clave pública 20 20 80 Criptograma 36 52 76

Cuadro 4.4: Comparativa de longitudes en bytes para ECIES, PSEC y ACE

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

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

4.2. Esquema de cifrado DHIES

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

DHIES tal como aparece en [10], donde M representa el mensaje a cifrar, gv la clave pública del destinatario, gu y u respectivamente las claves temporales pública y privada del remitente, ℰ el algoritmo de cifrado simétrico, T el algoritmo de generación de códigos MAC y H la función resumen. Es necesario tener en cuenta que esta descripción de DHIES emplea de forma genérica un grupo ﬁnito cíclico G con notación multiplicativa, de ahí que el término gu represente la multiplicación del elemento g ∈ G realizada u veces.

Figura 4.1: Esquema de funcionamiento de DHIES

El funcionamiento del esquema DHIES deﬁnido en [10] es el siguiente: cuando el remitente desea cifrar y enviar al destinatario un mensaje M, lo primero que debe hacer es elegir aleatoriamente un valor u para construir gu, que actuará como clave pública temporal. Este dato permite que el diseño se ajuste al modelo de acuerdo de clave Diﬃe-Hellman [61], ya que el elemento guv pasa a convertirse en el valor secreto compartido que únicamente el remitente y el destinatario pueden calcular. Una vez obtenido el valor secreto, este dato se hace pasar por la función resumen y se divide el resultado en dos elementos, una clave MAC denominada macKey y una clave para el algoritmo de cifrado simétrico denominada encKey. A continuación se cifra el mensaje M con la clave encKey y se pasa el mensaje cifrado denominado encM por la función MAC utilizando la clave macKey, dando como resultado el elemento tag. Por último, se envía al destinatario de forma conjunta la clave pública 138 4. Estudio y análisis del esquema de cifrado ECIES temporal gu, el resultado tag de la función MAC y el mensaje cifrado encM. En este esquema, es muy importante que el número de elementos del grupo escogido sea un número primo. De lo contrario, podría suceder que existieran dos valores distintos u y u′ tales que guv = gu′v, por lo que existirían dos elementos que generarían la misma salida de la función resumen, resultando un esquema débil desde el punto de vista de maleabilidad [243].

4.3. Componentes funcionales de ECIES

A lo largo de los restantes capítulos de esta Tesis Doctoral, se utilizará el término genérico ECIES para referirse a los distintos esquemas de cifrado incluidos en los estándares de seguridad más relevantes. A pesar de sus diferencias, las versiones de ECIES incluidas en los estándares analizados se adaptan a un mismo modelo general, representado mediante la Figura 4.2 (proceso de cifrado) y la Figura 4.3 (proceso de descifrado).

Figura 4.2: Diagrama funcional del proceso de cifrado en ECIES

En los siguientes apartados se presentan los elementos que ambos usuarios deben acordar de manera previa, utilizando canales de información donde la privacidad no es un factor importante, ya que la información a intercambiar no es crítica. 4.3. Componentes funcionales de ECIES 139

Figura 4.3: Diagrama funcional del proceso de descifrado en ECIES

La notación empleada en la descripción de los elementos será utilizada posteriormente en los apartados dedicados a las implementaciones de ECIES recogidas en los estándares analizados.

4.3.1. Parámetros de la curva

En el caso de curvas elípticas deﬁnidas sobre el cuerpo Fp, con p > 3 primo, el conjunto de parámetros a utilizar es

P= (p, a, b, G, n, ℎ), cuyos elementos se detallan a continuación:

∙ p es el número primo que especiﬁca el cuerpo ﬁnito Fp.

∙ a y b son los elementos de Fp que deﬁnen la curva E(Fp) dada por la expresión y2 = x3 + ax + b.

∙ G es el punto que actúa como generador de un subgrupo cíclico de puntos de la curva, siendo sus coordenadas (xG, yG). ∙ n es el número primo que representa el orden del punto G. 140 4. Estudio y análisis del esquema de cifrado ECIES

∙ ℎ es el cofactor de la curva, calculado como #E(Fp)/n.

En cambio, si la curva está deﬁnida sobre el cuerpo F2m , el conjunto de paráme- tros es

P= (m, f(x), a, b, G, n, ℎ), donde el signiﬁcado de los elementos no mencionados anteriormente es el siguiente:

∙ m es el número entero que especifica el cuerpo finito F2m . ∙ f(x) es un polinomio irreducible de grado m que define la base polinómica de F2m .

∙ a y b son los elementos de F2m que deﬁnen la curva E(F2m ) dada por la expresión y2 + xy = x3 + ax2 + b.

4.3.2. Funciones resumen

Las funciones resumen, identiﬁcadas indistintamente en las descripciones de los algoritmos de esta Tesis como funciones H o HASH (a excepción de los apartados donde se indique la utilización de la notación propia de algún estándar), toman como entrada una cadena de bytes de longitud variable y producen como salida una cadena de bytes de longitud ﬁja, tras la aplicación de varias operaciones sobre la cadena inicial [78, 172]. Las funciones resumen con mayor presencia en las distintas implementaciones de ECIES, agrupadas por familias, son las siguientes:

∙ SHA-1, SHA-224, SHA-256, SHA-384 y SHA-512 [183].

∙ RIPEMD-128 y RIPEMD-160 [63].

∙ WHIRLPOOL [131].

4.3.3. Funciones de generación del secreto compartido

Las funciones de generación del secreto compartido utilizadas en ECIES, denominadas de manera genérica funciones KA (Key Agreement), tienen como objetivo generar un valor secreto compartido entre dos usuarios, utilizando para ello una clave privada u del usuario U y una clave pública V del usuario V. Las principales funciones KA utilizadas en las implementaciones analizadas son: 4.3. Componentes funcionales de ECIES 141

∙ Primitiva Diﬃe-Hellman (DH).

La operativa consiste en calcular un punto de la curva P = (xP , yP ) = u V e identiﬁcar P o xP como el secreto compartido. ∙ Primitiva Diﬃe-Hellman con cofactor (DHC). ′ En este caso, la operación consiste en obtener el punto P = (xP ′ , yP ′ ) = ℎ u V , donde ℎ es el cofactor de la curva elíptica a la que pertenecen todos los puntos ′ considerados, de manera que el secreto compartido sea P o xP ′ .

Para que los cálculos con cualquiera de las dos primitivas sean válidos, es necesario comprobar que el punto de la curva generado, ya sea P o P ′, es distinto del punto en el inﬁnito O.

4.3.4. Funciones de derivación de claves

Las funciones de derivación de claves, denotadas como funciones KDF (Key Derivation Function) sirven para generar claves a partir de un dato secreto compartido. La lista de funciones de derivación de claves permitidas por las principales implementaciones de ECIES está compuesta por:

∙ ANSI-X9.63-KDF [16]. ∙ NIST-800-56-Concatenation-KDF [189]. ∙ KDF1 [136]. ∙ KDF2 [136].

Las funciones ANSI-X9.63-KDF y NIST-800-56-Concatenation-KDF son muy similares, diferenciándose básicamente en el orden en que se sitúan los elementos antes de su paso por la función resumen. Por su parte, las funciones KDF1 y KDF2 se encuentran deﬁnidas en el estándar ISO/IEC 18033-2 [136]. A continuación se presenta la descripción de cada una de las funciones, donde se ha utilizado la notación propia de los respectivos estándares:

∙ ANSI-X9.63-KDF. Sea Z una cadena de bits que representa el secreto compartido, H una función resumen aprobada por ANSI, keydatalen un entero que representa la longitud en bits de la clave a generar tal que keydatalen < hashlen⋅232 − 1, siendo hashlen la longitud en bits del resultado de la función resumen empleada, y SharedInfo una cadena de bits opcional que consiste en un dato compartido de forma previa por emisor y receptor. Con estos elementos, la clave se genera mediante el Algoritmo 4.4. 142 4. Estudio y análisis del esquema de cifrado ECIES

Algoritmo 4.4 Función ANSI-X9.63-KDF 1. Inicializar una variable denominada counter, de 32 bits y formato big-endian, con el valor 0000000116. 2. Establecer un bucle de tipo for desde i = 1 hasta i = ⌈keydatalen/ℎasℎlen⌉ que consiste en calcular Hi = H(Z ||counter||[SharedInfo]), donde por ser opcional el elemento SharedInfo se representa entre corchetes, e incrementar tanto i como counter en cada ejecución del bucle, con lo que el valor de counter depende directamente del elemento i.

3. Si el cociente r = keydatalen/ℎasℎlen es un número entero, generar la clave KeyData mediante la concatenación

KeyData=H1∣∣H2∣∣ ⋅ ⋅ ⋅ ∣∣Hr.

4. Si el cociente r = keydatalen/ℎasℎlen no fuera un número entero, realizar la concatenación y seleccionar los primeros keydatalen bits como valor de la clave.

∙ NIST-800-56-Concatenation-KDF. Se considera una cadena de bits Z que representa el secreto compartido, una función resumen H, un entero keydatalen que representa la longitud en bits de la clave a generar, y que debe ser menor o igual que el valor hashlen⋅232−1, siendo hashlen la longitud en bits del resultado de la función resumen empleada, y una cadena de bits opcional OtherInfo, que consiste en un dato compartido de forma previa por emisor y receptor. Con estos elementos, la clave se genera mediante el Algoritmo 4.5. En cuanto al elemento OtherInfo de NIST-800-56-Concatenation-KDF, su estructura es

OtherInfo=AlgID||UInfo||VInfo[||SuppPubInfo][||SuppPrivInfo],

donde el signiﬁcado de cada elemento es el siguiente:

AlgID: cadena de bits que informa sobre cómo obtener la clave y con qué algoritmos será utilizada. UInfo: cadena de bits con información pública sobre el emisor del mensaje cifrado, incluyendo al menos un identiﬁcador de ese usuario. VInfo: cadena de bits con información pública sobre el receptor del mensaje cifrado, incluyendo al menos un identiﬁcador de ese usuario. SuppPubInfo: cadena de bits opcional con información pública mutua- mente conocida por el emisor y el receptor del criptograma. 4.3. Componentes funcionales de ECIES 143

Algoritmo 4.5 Función NIST-800-56-Concatenation-KDF 1. Inicializar una variable denominada counter, de 32 bits y formato big-endian, con el valor 0000000116. 2. Calcular el valor de reps = ⌈keydatalen/ℎasℎlen⌉. Si reps > 232 − 1, ﬁna- lizar la operación devolviendo un error.

3. Establecer un bucle de tipo for desde i = 1 hasta reps que consiste en calcular Hi = H(counter||Z ||OtherInfo), incrementar la variable counter (mod 232) tratándolo como un entero sin signo de 32 bits, e incrementar la variable i. De esta manera, el valor de counter depende directamente del número de iteración marcado por el elemento i.

4. Si el cociente keydatalen/hashlen es un número entero, generar la clave denominada DerivedKeyingMaterial mediante la concatenación

DerivedKeyingMaterial=H1||H2||⋅ ⋅ ⋅ ||Hreps.

5. Si el cociente keydatalen/hashlen no fuera un número entero, realizar la concatenación y seleccionar los keydatalen bits más a la izquierda como valor de la clave.

SuppPrivInfo: cadena de bits opcional con información privada mutua- mente conocida por el emisor y el receptor del criptograma.

Cada uno de esos cinco elementos debe tener una longitud ﬁja, o en su defecto adaptarse al formato Datalen||Data, donde Datalen debe tener una longitud ﬁja y se utilizará para informar de la longitud en bytes del elemento Data.

Por su parte, las funciones de derivación de claves KDF1 y KDF2 no permiten parámetros opcionales como entrada. Sus características más señaladas son:

∙ KDF1. La función KDF1 toma como entrada una cadena de bytes x y un número entero positivo l que representa una longitud, generando como salida una cadena de bytes distinta de la inicial y de longitud l que se obtiene mediante el Algoritmo 4.6.

∙ KDF2. La función KDF2 es igual que KDF1, con la única diferencia de que el contador recorre los números 1 a k en lugar de recorrer el rango entre 0 y k − 1, tal como queda recogido en el Algoritmo 4.7. 144 4. Estudio y análisis del esquema de cifrado ECIES

Algoritmo 4.6 Función KDF1 1. Crear una variable denominada i ∈ ℤ, siendo contador(i) la representación binaria de i utilizando 4 bytes y elegir una función resumen H.

2. Calcular el valor k = ⌈l/H.len⌉, siendo H.len la longitud de la salida de la función resumen.

3. Establecer un bucle de tipo for desde i = 0 hasta k − 1 que consiste en calcular Hi = H(x||contador(i)) e incrementar a continuación la variable i. 4. Concatenar cada una de las cadenas resumen individuales para obtener como resultado de la función el dato

KDF1(x, l) = H(x∣∣contador(0)) ∣∣ ⋅ ⋅ ⋅ ∣∣ H(x∣∣contador(k − 1)).

Algoritmo 4.7 Función KDF2 1. Crear una variable denominada i ∈ ℤ, siendo contador(i) la representación binaria de i utilizando 4 bytes y elegir una función resumen H.

2. Calcular el valor k = ⌈l/H.len⌉, siendo H.len la longitud de la salida de la función resumen.

3. Establecer un bucle de tipo for desde i = 1 hasta k que consiste en calcular Hi = H(x||contador(i)) e incrementar a continuación la variable i. 4. Concatenar cada una de las cadenas resumen individuales para obtener como resultado de la función el dato

KDF2(x, l) = H(x∣∣contador(1)) ∣∣ ⋅ ⋅ ⋅ ∣∣ H(x∣∣contador(k)). 4.3. Componentes funcionales de ECIES 145

4.3.5. Función de cifrado simétrico

Mediante el término ENC se representará a lo largo de la presente Tesis el algoritmo de cifrado simétrico utilizado en ECIES. La lista de algoritmos permitidos en los principales estándares es la siguiente:

∙ XOR.

∙ TDES, también conocido como TDEA (Triple Data Encryption Algorithm), en modo CBC (Cipher-Block Chaining), tal como aparece descrito en [190] y en el ahora descatalogado [14].

∙ AES en modo CBC y CTR [185, 187].

∙ MISTY1 en modo CBC [165, 204].

∙ CAST-128 en modo CBC [11].

∙ Camellia en modo CBC [18].

∙ SEED en modo CBC [157].

4.3.6. Funciones generadoras de códigos de autenticación para mensajes

De forma genérica, las funciones MAC toman como entrada una cadena de bytes y un número entero positivo que representa una longitud, y producen como salida una cadena de bytes (distinta de la inicial y de la longitud indicada) denominada comúnmente tag o etiqueta. Por su parte, las funciones HMAC (Hashed Message Authentication Code) representan un tipo especial de funciones MAC, siendo su característica principal la utilización de una función resumen. El Algoritmo 4.8 muestra el funcionamiento de las funciones HMAC que utilizan una clave k para autenticar una cadena binaria x. Las funciones MAC cuyo uso está más extendido son:

∙ HMAC-SHA-1-80 y HMAC-SHA-1-160 con claves de 160 bits [154, 186].

∙ HMAC-SHA-224-112 y HMAC-SHA-224-224 con claves de 224 bits [186].

∙ HMAC-SHA-256-128 y HMAC-SHA-256-256 con claves de 256 bits [186].

∙ HMAC-SHA-384-192 y HMAC-SHA-384-384 con claves de 384 bits [186].

∙ HMAC-SHA-512-256 y HMAC-SHA-512-512 con claves de 512 bits [186]. 146 4. Estudio y análisis del esquema de cifrado ECIES

Algoritmo 4.8 Función HMAC 1. Asignar a la variable l la longitud de la salida de la función resumen H a emplear internamente por la función HMAC.

2. Comprobar la longitud de la clave k y realizar la operación adecuada:

∙ Si la longitud de k es superior al valor de l, la asignación k′ =H (k).

∙ Si la longitud de k es menor que el valor de l, rellenar con ceros por la derecha hasta conseguir que la longitud de k′ sea igual a L, de manera que k′ = k∣∣000 ... 0.

∙ Si no se produce ninguno de los casos anteriores, realizar la asignación k′ = k.

3. Inicializar la cadena binaria identiﬁcada como opad, de longitud l, con el valor hexadecimal 0x36.

4. Inicializar de igual manera la cadena binaria de longitud l e identiﬁcador ipad utilizando el valor hexadecimal 0x5C.

5. Calcular la salida de la función HMAC utilizando la clave k y el dato de entrada x mediante la operación

HMAC (x)=H ((k′ L opad)||H ((k′ L ipad)||x)).

∙ HMAC-RIPEMD-128-128 con claves de 128 bits [154].

∙ HMAC-RIPEMD-160-160 con claves de 160 bits [154].

∙ CMAC-AES-128, CMAC-AES-192 y CMAC-AES-256 [188].

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

4.4. Versiones de ECIES

El esquema DHIES fue empleado, junto con otras propuestas, en la preparación de los estándares ANSI X9.63 [16] e IEEE 1363a [109]. Como resultado de los estudios realizados durante la elaboración de esos documentos, las versiones de ECIES incluidas en dichos estándares 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 estándares ANSI X9.63 e IEEE 1363a avanzaba, ISO/IEC decidió reunir un grupo de expertos para trabajar en el estándar de cifrado asimétrico ISO/IEC 18033-2 [136], de manera que durante su elaboración este grupo tomó como punto de partida los estándares existentes (ya fuera en fase de borrador o definitivos), especialmente IEEE 1363a al representar el estándar más reciente sobre ECIES en aquellos momentos. Tras varios años de trabajo, el grupo de expertos que trabajaba en el estándar ISO/IEC 18033-2 introdujo cambios en la implementación de ECIES que afectaban a la compatibilidad con los estándares anteriores, por lo que actualmente para realizar una implementación de ECIES es imprescindible conocer las diferencias entre los estándares mencionados a fin de tomar las decisiones de diseño oportunas. Los siguientes apartados pretenden resumir las características más importantes de cada una de las distintas versiones de ECIES recogidas en los principales estándares criptográficos de cifrado asimétrico.

4.4.1. Versión de ANSI X9.63

Aunque los borradores del estándar ANSI X9.63 incluían dos esquemas de cifrado (Elliptic Curve Encryption Scheme y Elliptic Curve Augmented Encryption Scheme), cuya diferencia consistía en que el segundo esquema utilizaba una fun- ción MAC para generar una etiqueta (mientras que el primero no la utilizaba), en la versión ﬁnal del estándar [16] se describe una única versión con el nombre de ECIES.

4.4.1.1. Notación y parámetros utilizados

Los datos que emisor y receptor necesitan acordar antes de comenzar el proceso de cifrado son, utilizando la notación empleada por ANSI X9.63, los siguientes:

∙ Parámetros de dominio P, junto con una indicación de la base utilizada y un polinomio reductor f(x) de grado m y con coeﬁcientes en F2, en caso de elegir curvas del tipo E(F2m ). 148 4. Estudio y análisis del esquema de cifrado ECIES

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

∙ Función MAC aprobada por ANSI, donde la entrada de la función estará formada por los datos MacData, la clave MacKey tendrá una longitud de mackeylen bits y la salida de la función se representará como MacTag.

∙ Formato de los elementos opcionales SharedData1 y SharedData2, en caso de ser utilizados.

En ANSI X9.63, las funciones KDF, KA y ENC están descritas en el propio documento, siendo respectivamente las funciones ANSI-X9.63-KDF, DH/DHC y XOR. Los demás elementos que intervienen en las operaciones son:

∙ EncData: mensaje que el emisor desea enviar al receptor, representado como una cadena de bits.

∙ MaskedEncData: el resultado de cifrar el mensaje EncData.

∙ de: clave privada temporal del emisor, componente del par (de,Qe).

∙ Qe: clave pública temporal del emisor, componente del par (de,Qe). Su repre- sentación como cadena de bits es QE.

∙ Q: clave pública del receptor.

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

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

∙ z: elemento del cuerpo ﬁnito Fq que representa el secreto compartido que se utilizará en el proceso de derivación de claves. Su representación como cadena de bits es Z.

∙ EncKey: clave de cifrado a utilizar por la función ENC.

∙ MacKey: clave a utilizar por la función MAC.

∙ MacTag: cadena de bits obtenida como salida de la función MAC. 4.4. Versiones de ECIES 149

Algoritmo 4.9 Cifrado ECIES en ANSI X9.63

1. El emisor debe comenzar creando una pareja de claves temporales (de,Qe), para lo cual debe seleccionar de forma aleatoria o pseudoaleatoria un valor de perteneciente al conjunto {1, 2, . . . , n−1}, de manera que su correspondiente clave pública sea Qe = de G. A continuación, representará la clave pública Qe como la cadena de bits QE. 2. El emisor utilizará la función KA para generar un dato secreto compartido z ∈ Fq a partir de los valores de, Q y ℎ. Este valor secreto compartido será a continuación convertido en la cadena de bits Z.

3. El emisor utilizará la función KDF para generar a partir de Z (y opcionalmente también del valor SharedData1) un dato KeyData cuya longitud debe ser igual a la suma enckeylen+mackeylen.

4. A partir del elemento KeyData, el emisor adoptará sus enckeylen bits más a la izquierda como la clave de cifrado EncKey, y utilizará los mackeylen bits más a la derecha como la clave MacKey a utilizar con la función MAC.

5. El emisor empleará el algoritmo XOR para cifrar el mensaje EncData con la clave EncKey, generando el mensaje cifrado MaskedEncData.

6. El emisor utilizará la función MAC para generar el elemento MacTag, que representa la salida correspondiente a la concatenación del mensaje cifrado MaskedEncData junto con el dato compartido y opcional SharedData2 al utilizar la clave MacKey.

7. Finalmente, el emisor enviará al receptor la cadena de bits

QE||MaskedEncData||MacTag,

compuesta por la clave pública temporal QE, el mensaje cifrado MaskedEnc- Data y la etiqueta MacTag. 150 4. Estudio y análisis del esquema de cifrado ECIES

4.4.1.2. Proceso de cifrado

El proceso de cifrado de la versión de ECIES incluida en ANSI X9.63 presenta los pasos descritos en el Algoritmo 4.9.

4.4.1.3. Opciones disponibles

∙ Función HASH : Cualquier función resumen aprobada por ANSI. El catálogo de estándares de ANSI de 2010 [17] indica que dichas funciones son las siguientes:

SHA-1. SHA-224. SHA-256. SHA-384. SHA-512. ∙ Función KA:

DH. DHC. ∙ Función KDF :

ANSI-X9.63-KDF. ∙ Función ENC :

XOR (sin límite en la longitud de los mensajes a cifrar). ∙ Función MAC : Está permitida cualquier función MAC aprobada por ANSI que utilice claves de al menos 80 bits y que genere salidas cuya longitud mínima sea igualmente de 80 bits, citando el propio estándar como ejemplo la familia de funciones HMAC, por lo que junto con la lista de funciones resumen permitidas por ANSI se obtienen las siguientes opciones:

HMAC-SHA-1. HMAC-SHA-224. HMAC-SHA-256. HMAC-SHA-384. 4.4. Versiones de ECIES 151

HMAC-SHA-512. Como aclaración, aunque el documento X9.63 data del año 2001, en la lista de funciones permitidas se han incluido algoritmos estandarizados en fecha posterior (SHA-224, HMAC-SHA-224, etc.) puesto que, en lugar de citar especíﬁcamente en algunos apartados los nombres de los algoritmos permitidos, el documento X9.63 se limita a indicar que las funciones permitidas son aquellas aprobadas por ANSI, lo que permite hábilmente la actualización del estándar sin que sea necesario publicar nuevas versiones.

4.4.2. Versión de IEEE 1363a

La versión de ECIES incluida en en el estándar IEEE 1363a [109] está basada tanto en el esquema DHIES como en la implementación recogida en ANSI X9.63.

4.4.2.1. Notación y parámetros utilizados

A continuación se presentan, manteniendo la notación utilizada por IEEE 1363a, los datos que los usuarios emisor y receptor necesitan acordar antes de comenzar el proceso de cifrado:

∙ Parámetros de dominio (q, a, b, G, r, k), donde r representa el orden del generador G y k es el cofactor de la curva, junto con una indicación del tipo de representación de los elementos de Fq. ∙ Función resumen H permitida por IEEE, donde hLen representa la longitud en bytes de los resúmenes calculados.

∙ Función MAC, donde la salida tendrá una longitud tBits.

∙ Formato de los elementos opcionales P1 y P2, en caso de ser utilizados.

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

∙ Empleo de un algoritmo de cifrado de ﬂujo o de un algoritmo de cifrado por bloques. 152 4. Estudio y análisis del esquema de cifrado ECIES

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

∙ M: mensaje que el emisor desea enviar al receptor, representado como una cadena de l bits.

∙ C: el resultado de cifrar el mensaje M.

∙ u: clave privada temporal del emisor, componente del par de claves (u, v).

∙ v: clave pública temporal del emisor, componente del par de claves (u, v).

∙ w′: clave pública del receptor.

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

∙ P2: cadena de bytes con información compartida por emisor y receptor, y que será utilizada por la función MAC.

∙ z: elemento del cuerpo ﬁnito Fq que representa el secreto compartido que se utilizará en el proceso de derivación de claves.

∙ Z: representación como cadena de bytes del secreto compartido z ∈ Fq.

∙ K1: clave de cifrado a utilizar por la función de cifrado simétrico ENC.

∙ K2: clave a utilizar por la función MAC.

∙ T : cadena de bits obtenida como salida de la función MAC.

∙ tBits: longitud en bits de la salida de la función MAC.

∙ k1: longitud en bits de la clave de cifrado.

∙ k2: longitud en bits de la clave para la función MAC.

En este estándar, tanto la cadena P1 como P2 pueden estar vacías, por lo que realmente su uso es opcional. 4.4. Versiones de ECIES 153

Algoritmo 4.10 Cifrado ECIES en IEEE 1363a 1. El emisor debe comenzar creando una pareja de claves temporales (u, v), donde u ∈ {1, . . . , r − 1} y v = r u.

2. El emisor utilizará la función KA para generar un dato secreto compartido z a partir de los valores u y w′. Opcionalmente también utilizará k 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 continuación convertido en la cadena de bytes Z, al igual que la clave pública v del emisor se convertirá en la cadena de bytes V .

3. Si los usuarios han decidido utilizar el modo DHAES, entonces el elemento VZ se construye como VZ =V ||Z. En caso contrario, VZ =Z.

4. Si el método de cifrado elegido consiste en un esquema de cifrado de bloques, el emisor utilizará la función KDF para generar, a partir de los elementos VZ y P1, un dato K de longitud k1 + k2 bits. A partir del elemento K, el emisor adoptará sus k1 bits más a la izquierda como la clave de cifrado K1, y utilizará los k2 bits más a la derecha como la clave K2 a utilizar en la función MAC. En cambio, si el método de cifrado simétrico es un algoritmo de cifrado en ﬂujo, existe la opción de invertir el orden con que se interpretan las claves K2 y K1, de manera que en el modo DHAES la clave MAC se obtiene tomando los k2 bits más a la izquierda de la salida de la función KDF, mientras que en el modo no-DHAES se consigue mediante los k2 bits más a la derecha.

5. El emisor procederá a cifrar el mensaje M con la clave K1 para obtener el mensaje cifrado C.

6. En el modo DHAES, el emisor debe convertir la longitud en bits de P2 en una cadena de 8 bytes L2. Si los usuarios no han decidido utilizar el modo DHAES, la cadena L2 estará vacía (aunque P2 contenga datos).

7. El emisor utilizará la función MAC con la clave K2 para generar el elemento T, que representa la etiqueta correspondiente a la concatenación del mensaje cifrado, denotado como C, junto con el dato compartido P2 y la cadena de bytes (potencialmente vacía) L2. 8. Finalmente, el emisor enviará al receptor la tripleta (V,C,T ). 154 4. Estudio y análisis del esquema de cifrado ECIES

4.4.2.2. Proceso de cifrado

El proceso de cifrado de la versión de ECIES incluida en IEEE 1363a presenta los pasos indicados en el Algoritmo 4.10. IEEE 1363a permite que el mismo par de claves (u, v) sea reutilizado en nuevos procesos de cifrado con destino el mismo usuario o incluso con distintos destinatarios, aunque en el caso de volver a utilizar el mismo par de claves recomienda variar el parámetro P1 a ﬁn de que el dato K sea distinto en cada ocasión.

4.4.2.3. Opciones disponibles

∙ Función HASH :

SHA-1. SHA-256. SHA-384. SHA-512. RIPEMD-160. ∙ Función KA:

DH (denominada ECSVDP-DH en la norma). DHC (denominada ECSVDP-DHC en la norma). ∙ Función KDF :

ANSI-X9.63-KDF (denominada en el estándar KDF2, no confundir con la función del mismo nombre descrita en §4.3.4).

∙ Función ENC :

XOR (el estándar recomienda cifrar mensajes de reducido tamaño y, si se utiliza el modo no-DHAES, que su longitud sea constante para una misma clave pública del receptor a emplear). TDES en modo CBC y relleno PKCS#5 con bloques de 64 bits y claves de 128 ó 192 bits. AES en modo CBC y relleno PKCS#5 con bloques de 128 bits y claves de 128, 192 ó 256 bits 4.4. Versiones de ECIES 155

∙ Función MAC : El estándar deﬁne la función MAC1, equivalente a las funciones de tipo HMAC, donde las funciones resumen permitidas son las del propio documento [109], obteniendo por tanto como lista de funciones MAC permitidas las siguientes:

HMAC-SHA-1. HMAC-SHA-256. HMAC-SHA-384. HMAC-SHA-512. HMAC-RIPEMD-160. 4.4.3. Versión de ISO/IEC 18033-2

4.4.3.1. Notación y parámetros utilizados

Los datos que los usuarios emisor y receptor necesitan acordar antes de comenzar el proceso de cifrado son los siguientes, donde se ha mantenido la notación utilizada por ISO/IEC 18033-2 [136]:

∙ Conjunto de parámetros (ℋ, G, g, , ), donde ℋ es el cuerpo primo o binario de trabajo, g representa el elemento generador del grupo cíclico G ⊂ ℋ, es el orden del elemento g y es el cofactor de la curva.

∙ Función de derivación de claves KDF (pudiendo optar entre las funciones KDF1 y KDF2).

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

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

∙ Función ENC, donde la longitud en bytes de la clave se denotará mediante el término SC.KeyLen.

∙ Utilización del modo OldCofactorMode, que implica el uso del cofactor tanto en la fase de cifrado como de descifrado. 156 4. Estudio y análisis del esquema de cifrado ECIES

∙ Utilización del modo CofactorMode, que requiere del uso del cofactor única- mente en el proceso de descifrado.

∙ Utilización del modo CheckMode, que obliga a la comprobación durante el proceso de descifrado de la pertenencia de la clave pública temporal del emisor a G. Únicamente uno de los modos OldCofactorMode, CofactorMode y CheckMode puede ser utilizado en un mismo proceso de cifrado.

∙ Utilización o no del modo SingleHashMode, que permite elegir que la entrada a la función KDF sea únicamente la primera coordenada del dato secreto compartido o de manera adicional la clave pública temporal generada por el emisor.

∙ Formato de codiﬁcación de los puntos (comprimido o sin comprimir).

La notación empleada en ISO/IEC 18033-2 incluye además los siguientes elementos:

∙ M: mensaje que el emisor desea enviar al receptor.

∙ c: el resultado de cifrar el mensaje M.

∙ (x, ℎ): par formado por las claves privada y pública del receptor.

∙ (r, g˜): par formado por una clave privada y una clave pública temporales generadas por el emisor.

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

∙ z: elemento del cuerpo ﬁnito Fq que representa el secreto compartido que se utilizará en el proceso de derivación de claves.

∙ Z: representación como cadena de bytes de la clave pública temporal del emisor.

∙ K: valor obtenido como salida de la función KDF.

∙ k: clave de cifrado a utilizar por el esquema de cifrado simétrico ENC.

∙ k′: clave a utilizar por la función MAC.

∙ T : valor obtenido como salida de la función MAC.

∙ PEH : primera coordenada del punto que actúa como valor secreto compartido. 4.4. Versiones de ECIES 157

4.4.3.2. Proceso de cifrado

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

Algoritmo 4.11 Fase KEM del cifrado ECIES en ISO/IEC 18033-2 1. El emisor debe comenzar generando un número aleatorio r perteneciente al conjunto {1, 2, . . . , − 1}.

2. A continuación, si los usuarios utilizan el modo OldCofactorMode, calculará r′ = r ⋅ (mod ). En caso contrario, realizará la asignación r′ = r.

3. Tras el paso anterior, el emisor calculará los puntos de la curva g˜ = r ⋅ g y ℎ˜ = r′ ⋅ ℎ.

4. Una vez obtenidos los puntos g˜ y ℎ˜, el emisor obtendrá la codiﬁcación hexadecimal C0 correspondiente a la clave pública temporal g˜ en función del formato de codiﬁcación elegido (comprimido o sin comprimir).

5. Si los usuarios han decidido utilizar el modo SingleHashMode, entonces el dato secreto compartido Z será la cadena nula. En caso contrario, Z = C0. 6. A continuación el emisor codiﬁcará en formato hexadecimal la primera coordenada del elemento ℎ˜, obteniendo el elemento PEH.

7. Acto seguido, utilizará la función KDF para generar K, tomando como entrada la concatenación Z∣∣PEH, es decir, la clave pública temporal del emisor (o la cadena nula, en su caso) y la representación binaria de la primera coordenada del dato secreto compartido.

Es interesante comentar que, mientras DEM1 es la función DEM recomendada por ISO/IEC 18033-2 (y consecuentemente sólo incluye vectores de test para esa función), el propio documento informa que la principal razón para incluir las funciones DEM2 y DEM3 ha sido el mantenimiento de compatibilidad con estándares anteriores.

4.4.3.3. Opciones disponibles

Las opciones disponibles en el estándar ISO/IEC 18033-2 son: 158 4. Estudio y análisis del esquema de cifrado ECIES

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

2. A continuación el emisor cifrará el mensaje original M con la clave k, generando el mensaje cifrado c.

3. Tras el último paso, obtendrá la etiqueta TG correspondiente a la salida de la función MAC, tomando como entrada la cadena de bytes concatenada c∣∣L∣∣L.len, donde L representa los datos compartidos entre emisor y receptor y L.len la longitud codiﬁcada en 8 bytes de la longitud en bits de L.

4. Por último, el emisor concatenará el texto cifrado y la etiqueta, enviando al receptor el elemento C1 = c∣∣TG junto con la clave pública temporal C0.

Algoritmo 4.13 Función DEM2 de la fase DEM del cifrado ECIES en ISO/IEC 18033-2 1. El emisor debe interpretar el elemento K como k∣∣k′, donde k actuará como clave para el algoritmo de cifrado simétrico, con longitud SC.KeyLen, y k′ será la clave de la función MAC, con longitud MA.KeyLen.

2. El emisor cifrará el mensaje original M con la clave k, generando el mensaje cifrado c.

3. Tras el último paso, obtendrá la etiqueta TG correspondiente a la salida de la función MAC, tomando como entrada la cadena de bytes concatenada c∣∣L, donde L es una cadena binaria de datos compartidos entre emisor y receptor.

4. Por último, el emisor concatenará el texto cifrado y la etiqueta, enviando al receptor el elemento C1 = c∣∣TG junto con la clave pública temporal C0. 4.4. Versiones de ECIES 159

Algoritmo 4.14 Función DEM3 de la fase DEM del cifrado ECIES en ISO/IEC 18033-2 1. El emisor debe dividir el elemento K en k∣∣k′, donde k actuará como clave para el algoritmo de cifrado de ﬂujo (y por lo tanto su longitud debe coincidir con la longitud del mensaje a cifrar), y k′ será la clave de la función MAC, con longitud MA.KeyLen.

2. El emisor cifrará el mensaje original M con la clave k mediante la operación c = k L M.

4. Por último, el emisor concatenará el texto cifrado y la etiqueta, enviando al receptor el elemento C1 = c∣∣TG junto con la clave pública temporal C0.

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

Hash-function one. Hash-function two. Hash-function three. Hash-function four. Cualquiera de las funciones resumen deﬁnidas en ISO/IEC 10118-3 [131] con la condición de que el número de bytes ofrecidos como salida de la función sea múltiplo de 8. Las funciones especíﬁcas que cumplen ese requisito son las siguientes:

SHA-1. SHA-256. SHA-384. SHA-512. RIPEMD-128. RIPEMD-160. WHIRLPOOL. 160 4. Estudio y análisis del esquema de cifrado ECIES

∙ Función KA:

DH. DHC. ∙ Función KDF :

KDF1. KDF2. ∙ Función ENC :

XOR con una longitud de mensaje en claro deﬁnida y constante para todos los procesos de cifrado. XOR diseñado para el cifrado de mensajes de longitud variable, donde en lugar de utilizar directamente la clave de cifrado generada por la función KDF, ésta se utiliza como semilla para la generación de la clave XOR deﬁnitiva adaptada a la longitud del mensaje en claro mediante una nueva ejecución de la función KDF.

Cualquier algoritmo incluido en ISO/IEC 18033-3 [137] con la condición de que la longitud de los mensajes medida en bits sea múltiplo de 8. Los algoritmos descritos en [137] son los siguientes:

TDES en modo CBC y relleno PKCS#5 con bloques de 64 bits y claves de 128 ó 192 bits. AES en modo CBC y relleno PKCS#5 con bloques de 128 bits y claves de 128, 192 ó 256 bits. MISTY1 en modo CBC y relleno PKCS#5 con bloques de 64 bits y claves de 128 bits. CAST-128 en modo CBC y relleno PKCS#5 con bloques de 64 bits y claves de 128 bits. Camellia en modo CBC y relleno PKCS#5 con bloques de 128 bits y claves de 128, 192 ó 256 bits. SEED en modo CBC y relleno PKCS#5 con bloques de 128 bits y claves de 128 bits.

∙ Función MAC : Cualquiera de las cuatro variantes CBC-MAC incluidas en ISO/IEC 9797-1 [128] que utilizan internamente una función de cifrado de bloques, denominadas en [128] de la siguiente manera: 4.4. Versiones de ECIES 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. Versión de SECG SEC 1

El consorcio SECG publicó la primera versión del documento SEC 1 el año 2000. Desde entonces ha publicado distintos borradores que han culminado con la publicación de la versión 2.0 en mayo de 2009 [254]. Este documento incluye, además de algunos apartados dedicados a los fundamentos matemáticos y los detalles sobre cómo generar y elegir los parámetros de dominio adecuados, una amplia descripción de los esquemas de cifrado, ﬁrma digital y acuerdo de clave basados en ECC.

4.4.4.1. Notación y parámetros utilizados

Los datos que los usuarios, identiﬁcados como emisor y receptor, necesitan acordar antes de comenzar el proceso de cifrado son los siguientes, donde se ha mantenido la notación utilizada por SEC 1:

∙ Conjunto de parámetros T = (p, a, b, G, n, ℎ) en caso de utilizar curvas deﬁ- nidas sobre cuerpos ﬁnitos Fp, o parámetros T = (m, f(x), a, b, G, n, ℎ) si se utilizan curvas del tipo E(F2m ), donde en ambos casos n representa el orden del generador G y ℎ es el cofactor de la curva.

∙ Función de derivación de clave KDF, que genera una cadena de bytes de longitud enckeylen+mackeylen.

∙ Función resumen H, donde hashlen representa la longitud en bytes de los re- súmenes calculados y hashmaxlen indica la longitud máxima en bytes de los mensajes que pueden ser utilizados como entrada para la función resumen.

∙ Función MAC, donde la longitud en bytes de la clave se denotará mediante el término mackeylen, mientras que la longitud en bytes de la etiqueta producida por la función se representará como maclen. 162 4. Estudio y análisis del esquema de cifrado ECIES

∙ Función ENC, donde la longitud en bytes de la clave se denotará mediante el término enckeylen.

∙ Formato de los elementos SharedInfo1 y SharedInfo2.

∙ Utilización o no de la representación de puntos con compresión.

La notación empleada en [254] incluye los siguientes elementos:

∙ M: mensaje que el emisor desea enviar al receptor.

∙ EM : mensaje cifrado por el emisor.

∙ C: el resultado de cifrar el mensaje M.

∙ (dV ,QV ): par formado por la clave privada y la clave pública de V .

∙ (k, R): par formado por una clave privada y una clave pública temporales generadas por el emisor.

∙ SharedInfo1: cadena de bytes con información compartida por los dos usuarios, y que será utilizada en la función KDF.

∙ SharedInfo2: cadena de bytes con información compartida por emisor y receptor, y que será utilizada por la función MAC.

∙ z: elemento del cuerpo ﬁnito Fq que representa el secreto compartido que se utilizará en el proceso de derivación de claves.

∙ Z: representación como cadena de bytes del secreto compartido z ∈ Fq.

∙ EK: clave de cifrado a utilizar por el esquema de cifrado simétrico ENC.

∙ MK: clave a utilizar por la función MAC.

∙ D: valor obtenido como salida de la función MAC.

4.4.4.2. Proceso de cifrado

El proceso de cifrado de la versión de ECIES incluido en SEC 1 presenta los pasos indicados en el Algoritmo 4.15. 4.4. Versiones de ECIES 163

Algoritmo 4.15 Cifrado ECIES en SEC 1 1. El usuario emisor debe comenzar creando una pareja de claves temporales (k, R), con R = (xR, yR). Para ello, debe seleccionar aleatoria o pseudoalea- toriamente un valor k perteneciente al conjunto {1, 2, . . . , n − 1}, de manera que su correspondiente clave pública sea R = k G.

2. Dependiendo del tipo de compresión que los usuarios hayan decidido utilizar para representar los puntos de la curva elíptica, es necesario convertir el punto R en la cadena de bytes R.

3. En función del tipo de primitiva Diﬃe-Hellman (con o sin cofactor) que el emisor como el receptor hayan acordado utilizar, el usuario emisor generará un dato secreto compartido z ∈ Fq a partir de la clave secreta temporal k y de la clave pública QV . Este valor secreto compartido será convertido en la cadena de bytes Z.

4. El emisor utilizará la función KDF acordada con el otro usuario para generar a partir de Z (y opcionalmente también del valor SharedInfo1) un dato K cuya longitud será enckeylen+mackeylen.

5. A partir del elemento K, el emisor adoptará sus enckeylen bytes más a la izquierda como la clave de cifrado EK, y utilizará los mackeylen bytes más a la derecha como la clave MK a utilizar con la función MAC. Únicamente en el caso de que la función de cifrado sea XOR y no se desee compatibilidad con estándares anteriores, entonces la interpretación del orden de las claves de cifrado y autenticación será exactamente la contraria.

6. El emisor empleará el algoritmo de cifrado simétrico ENC, junto con el mensaje M y la clave EK, para generar el mensaje cifrado EM.

7. El usuario emisor utilizará la función MAC acordada al inicio del proceso para generar el elemento D, que representa la etiqueta correspondiente a la concatenación del mensaje cifrado EM 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 C = (R,EM,D) compuesto por la representación binaria de la clave pública temporal R, el mensaje cifrado EM y la etiqueta D. Una posible forma de proceder a su envío consiste en concatenar los elementos de forma que el criptograma sea

C = R∣∣EM ∣∣D. 164 4. Estudio y análisis del esquema de cifrado ECIES

4.4.4.3. Opciones disponibles

La siguiente lista muestra las distintas opciones permitidas en SEC 1:

∙ Función HASH :

SHA-1. SHA-224. SHA-256. SHA-384. SHA-512. ∙ Función KA:

DH. DHC. ∙ Función KDF :

ANSI-X9.63-KDF [16]. NIST-800-56-Concatenation-KDF [189]. ∙ Función ENC :

XOR (sin límite en la longitud de los mensajes a cifrar). TDES con tres claves en modo CBC [190] (SEC 1 no especifica el método de relleno). AES en modo CBC y claves de 128, 192 ó 256 bits [185, 187] (sin especificar el método de relleno). AES en modo CTR y claves de 128, 192 ó 256 bits [185, 187] (SEC 1 no define el método de relleno). ∙ Función MAC :

HMAC-SHA-1-80 (clave de 160 bits y salida truncada a 80 bits). HMAC-SHA-1-160 (clave de 160 bits y salida de 160 bits). HMAC-SHA-224-112 (clave de 224 bits y salida truncada a 112 bits). HMAC-SHA-224-224 (clave de 224 bits y salida de 224 bits). HMAC-SHA-256-128 (clave de 256 bits y salida truncada a 128 bits). HMAC-SHA-256-256 (clave de 256 bits y salida de 256 bits). 4.5. Diferencias en las versiones de ECIES 165

HMAC-SHA-384-192 (clave de 384 bits y salida truncada a 192 bits). HMAC-SHA-384-384 (clave de 384 bits y salida de 384 bits). HMAC-SHA-512-256 (clave de 512 bits y salida truncada a 256 bits). HMAC-SHA-512-512 (clave de 512 bits y salida de 512 bits). CMAC-AES-128 (clave de 128 bits y salida de 128 bits). CMAC-AES-192 (clave de 192 bits y salida de 128 bits). CMAC-AES-256 (clave de 256 bits y salida de 128 bits). 4.5. Diferencias en las versiones de ECIES

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

4.5.1. Diferencias entre DHIES y ANSI X9.63

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

∙ DHIES no permite parámetros opcionales en las funciones KDF y MAC, mientras que X9.63 permite parámetros en ambas funciones.

∙ DHIES utiliza una función resumen para producir las claves kMAC y kENC . En comparación, X9.63 utiliza una función KDF donde los datos son procesados mediante un procedimiento iterativo. ∙ DHIES interpreta los bits iniciales de la salida de la función KDF como la clave MAC, y los bits ﬁnales como la clave ENC. En X9.63, el orden es precisamente el opuesto. ∙ X9.63 sólo permite utilizar la función XOR como algoritmo de cifrado simétri- co. En comparación, DHIES permite utilizar algoritmos de cifrado en bloque, dejando abierta la elección del algoritmo especíﬁco. 166 4. Estudio y análisis del esquema de cifrado ECIES

4.5.2. Diferencias entre ANSI X9.63 e IEEE 1363a

La siguiente lista reﬂeja 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 párrafos serán referidos simplemente como ‘X9.63’ y ‘1363a’.

∙ X9.63 permite utilizar parámetros opcionales como entrada en la función KDF, aunque no menciona el contenido de dichos parámetros. En comparación, el modo DHAES de 1363a obliga a utilizar la representación binaria de la clave temporal pública del emisor como parámetro. ∙ En cualquier caso, aunque X9.63 utilizara la clave pública temporal como parámetro en la función KDF, este dato se concatenaría en tercera posición en la cadena binaria que representa el argumento de la función resumen utilizada internamente dentro de la función KDF (es decir, en las iteraciones de la función sería necesario calcular H(xP ∣∣counter∣∣U)), mientras que en IEEE 1363a la clave pública temporal ocuparía el primer lugar en la concatenación (siendo necesario por tanto calcular el valor H(U∣∣xP ∣∣counter)) ∙ 1363a interpreta los bits iniciales de la salida de la función KDF como la clave MAC, y los bits posteriores como la clave ENC, cuando utiliza cifrado en ﬂujo, mientras que la interpretación es la opuesta cuando 1363a utiliza cifrado en bloque. En comparación, X9.63 interpreta siempre la salida de la función KDF como kENC ∣∣kMAC .

4.5.3. Diferencias entre IEEE 1363a e ISO/IEC 18033-2

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

∙ 18033-2 no permite parámetros en la función KDF, mientras que 1363a sí los permite. ∙ 1363a permite utilizar tanto cadenas de bits como de bytes, mientras que 18033-2 sólo permite cadenas de bytes. ∙ 1363a sugiere utilizar siempre los mismos parámetros (funciones resumen y MAC, algoritmo de cifrado simétrico, etc.) para una clave pública del remitente determinada, mientras que en 18033-2 es obligatorio no cambiar los parámetros en relación a la misma clave pública del destinatario. 4.5. Diferencias en las versiones de ECIES 167

∙ 1363a establece como longitud mínima del orden del elemento generador 160 bits, mientras que 18033-2 no hace referencia a longitudes mínimas.

Es interesante comentar que, entre el estándar IEEE 1363a y los primeros borradores de ISO/IEC 18033-2, existían más diferencias, como se puede apreciar en el documento de Shoup [243], que denotaremos por ‘Shoup01’, y que sirvió como punto de partida para el estándar ISO/IEC 18033-2. Esas diferencias, que posteriormente desaparecieron en la versión ﬁnal del estándar con el ﬁn de asegurar una mayor compatibilidad con otros estándares, son las siguientes:

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

4.5.4. Diferencias entre ISO/IEC 18033-2 y SEC 1

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

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

∙ Mientras que 18033-2 no hace referencia a longitudes mínimas, SEC 1 establece que la elección de los cuerpos ﬁnitos debe estar guiada por los siguientes requisitos:

Cuerpos Fp: el valor p debe ser tal que ⌈log2 p⌉ ∈ {192, 224, 256, 384, 521}.

Cuerpos F2m : debe cumplirse la propiedad m ∈ {163, 233, 239, 283, 409, 571}.

4.6. Comparación de las funciones permitidas en los estándares

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

ANSI X9.63 IEEE 1363a ISO/IEC 18033-2 SECG SEC 1 SHA-1 SHA-1 SHA-1 SHA-1 SHA-224 SHA-256 SHA-256 SHA-224 SHA-256 SHA-384 SHA-384 SHA-256 SHA-384 SHA-512 SHA-512 SHA-384 SHA-512 RIPEMD-160 RIPEMD-128 SHA-512 RIPEMD-160 WHIRLPOOL

Cuadro 4.5: Función HASH

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

ANSI X9.63 IEEE 1363a ISO/IEC 18033-2 SECG SEC 1 DH DH DH DH DHC DHC DHC DHC

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

ANSI X9.63 IEEE 1363a ISO/IEC 18033-2 SECG SEC 1 X9.63-KDF X9.63-KDF KDF1 X9.63-KDF KDF2 NIST-800-56

Cuadro 4.7: Función KDF

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

ANSI X9.63 IEEE 1363a ISO/IEC 18033-2 SECG SEC 1 XOR XOR XOR XOR TDES/CBC/PKCS5 XOR⊥ TDES/CBC/* AES/CBC/PKCS5 TDES/CBC/PKCS5 AES/CBC/* AES/CBC/PKCS5 AES/CTR/* MISTY1/CBC/PKCS5 CAST-128/CBC/PKCS5 Camellia/CBC/PKCS5 SEED/CBC/PKCS5

Cuadro 4.8: Función ENC

Por último, el Cuadro 4.9 presenta las funciones MAC permitidas en los diferentes estándares, donde con el objetivo de optimizar el tamaño del cuadro resultante se ha sustituido el preﬁjo HMAC por H. Las funciones HMAC-SHA-1 y 170 4. Estudio y análisis del esquema de cifrado ECIES

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

ANSI X9.63 IEEE 1363a ISO/IEC 18033-2 SECG SEC 1 H-SHA-1 H-SHA-1 H-SHA-1 H-SHA-1-80/160 H-SHA-224 H-SHA-256 H-SHA-256 H-SHA-224-112/224 H-SHA-256 H-SHA-384 H-SHA-384 H-SHA-256-128/256 H-SHA-384 H-SHA-512 H-SHA-512 H-SHA-384-192/384 H-SHA-512 H-RIPEMD-160 H-RIPEMD-128 H-SHA-512-256/512 H-RIPEMD-160 CMAC-AES-128/192/256 H-WHIRLPOOL

Cuadro 4.9: Función MAC

Como resumen ﬁnal, el Cuadro 4.10 muestra las funciones permitidas simultá- neamente por los cuatro estándares revisados.

HASH KA KDF ENC MAC SHA-1 DH KDF2 XOR HMAC-SHA-1 SHA-256 DHC HMAC-SHA-256 SHA-384 HMAC-SHA-384 SHA-512 HMAC-SHA-512

Cuadro 4.10: Funciones comunes permitidas en los cuatro estándares

4.7. Comparación de las conﬁguraciones permitidas en los estándares

Tal como se ha mostrado en los anteriores apartados, los diferentes estándares en los que se encuentra descrito el esquema ECIES contienen múltiples opciones no siempre compatibles entre sí. El primer paso para realizar una implementación del esquema de cifrado ECIES consiste, por tanto, en identificar todas las posibles opciones, a fin de tomar unas decisiones sobre la funcionalidad final a implementar. Un análisis detallado de las distintas combinaciones de parámetros muestra que existen 11 configuraciones posibles que puedan ser implementadas al menos por 4.7. Comparación de las configuraciones permitidas en los estándares171 un estándar (las restantes configuraciones, no incluidas, son incompatibles con los cuatro estándares). Puesto que todos ellos permiten utilizar como función KA las funciones DH y DHC, el análisis se reduce a comparar los siguientes elementos: el tipo y número de argumentos de las funciones KDF y MAC, la interpretación del elemento K a partir del cual se generan las claves de cifrado y autenticación, y por última la clase de función de cifrado simétrico elegida (en flujo o en bloque).

El Cuadro 4.11 muestra los datos mencionados en el párrafo anterior, donde xP es la codificación binaria de la primera coordenada del punto P = (xP , yP ), Param1 representa una cadena binaria con parámetros para la función KDF, kENC y kMAC son respectivamente las claves de cifrado y autenticación generadas a partir del dato K (que a su vez es la salida de la función KDF ), c es el mensaje cifrado con el algoritmo de cifrado simétrico (ya sea una función de cifrado en flujo o en bloque), y por último Param2 representa una cadena binaria con parámetros para la función MAC (por ejemplo, la codificación de un texto que conocen emisor y receptor).

Opciones de conﬁguración Arg. KDF Interp. K Alg. simétrico Arg. MAC

C01 xP kENC ∣∣kMAC Flujo c C02 xP kENC ∣∣kMAC Flujo c, Param2 C03 xP kMAC ∣∣kENC Flujo c C04 xP kMAC ∣∣kENC Flujo c, Param2 C05 xP kENC ∣∣kMAC Bloque c C06 xP kENC ∣∣kMAC Bloque c, Param2 C07 xP , Param1 kENC ∣∣kMAC Bloque c C08 xP , Param1 kENC ∣∣kMAC Bloque c, Param2 C09 U∣∣xP kENC ∣∣kMAC Bloque c Id. de conﬁguración C10 U∣∣xP kENC ∣∣kMAC Bloque c, Param2 C11 U∣∣xP , Param1 kENC ∣∣kMAC Bloque c, Param2

Cuadro 4.11: Combinaciones de parámetros admitidas al menos en un estándar

Una vez presentadas las personalizaciones de ECIES que son aceptadas al menos en un estándar, el Cuadro 4.12 muestra el resumen de los estándares que permiten cada una de las conﬁguraciones. 172 4. Estudio y análisis del esquema de cifrado ECIES

Identiﬁcador de personalización C01 C02 C03 C04 C05 C06 C07 C08 C09 C10 C11 X9.63 ✓ ✓ 1363a ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ 18033-2 ✓ ✓ ✓ ✓ ✓ ✓ SEC 1 ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ Cuadro 4.12: Comparativa de las conﬁguraciones permitidas en cada estándar

4.8. Versión de ECIES compatible con todos los es- tándares

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

4.9. Seguridad de ECIES

De manera adicional a los ataques generales sobre curvas elípticas expuestos en §2.6.7, con el paso del tiempo han surgido ataques especíﬁcos 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 deﬁnido como la capacidad de un atacante de generar un criptograma válido asociado al mensaje en claro y a partir del conocimiento del criptograma derivado del mensaje x, cuando entre los mensajes x 4.9. Seguridad de ECIES 173

Algoritmo 4.16 Cifrado ECIES compatible con los cuatro estándares (ECIES-4) 1. Elegir un valor aleatorio u ∈ {1, 2, . . . , q − 1} como clave privada temporal de U, y generar la clave pública U = u G.

2. Calcular un punto P = (xP , yP ) de la curva mediante la operación P = u V , donde V es la clave pública del usuario receptor.

3. Generar el elemento K del que se obtendrán las clave de cifrado y autenti- cación mediante la operación K =KDF (xP ), siendo la función KDF elegida ANSI-X9.63-KDF (sin parámetros opcionales) y la función HASH empleada SHA-1.

4. Interpretar K como kENC ∣∣kMAC , donde la longitud en bits de kENC es igual a la longitud en bits del mensaje en claro m, y la longitud de kMAC es 160 bits. L 5. Producir el mensaje cifrado c = kENC m utilizando la función de cifrado de ﬂujo XOR.

6. Calcular la etiqueta tag utilizando el método tag = MAC (c), donde la fun- ción MAC elegida es HMAC-SHA-1 con salida de 160 bits.

7. Enviar la tripleta C = (U, c,tag) como criptograma concatenando los tres elementos, de manera que la cadena binaria recibida por el usuario receptor sea U∣∣c∣∣tag. e y existe alguna relación [67]. En el contexto de ECIES, la maleabilidad se puede dividir en benigna o maligna, dependiendo de si el ataque es capaz de producir resultados prácticos.

4.9.1.1. Maleabilidad benigna

Shoup [243] demostró que, si se utiliza únicamente la primera coordenada xP como entrada de la función KDF, el esquema ECIES es vulnerable frente ataques de tipo ACCA y, en consecuencia, es maleable. En efecto, dado un criptograma (U, c, tag) compuesto por la representación binaria U de la clave pública temporal U del emisor, el mensaje cifrado c y la etiqueta tag, si se sustituye el punto de la curva U por −U, al aplicar la función KA se obtiene como material para generar la clave el elemento −uV en lugar de uV . Pero puesto que tanto en uV como en −uV la coordenada x tiene el mismo valor, la entrada a la función KDF será la misma en ambos casos. La conclusión es que, a partir de un criptograma (U, c, tag) válido, es posible construir otro criptograma (−U, c, tag) igualmente válido. 174 4. Estudio y análisis del esquema de cifrado ECIES

Una posible forma de resolver este problema fue propuesta por el propio Shoup, y consiste en añadir la clave pública temporal U como entrada de la función KDF, con lo que el criptograma (−U, c, tag) ya no sería válido, dado que la salida de la función KDF sería diferente en ambos casos. Otra posible solución consiste en utilizar el punto P generado mediante la función KA en lugar de únicamente su primera coordenada como entrada de la función KDF, con lo que de nuevo dejaría de ser válido un criptograma que contuviera −U en lugar de U. Respecto a la solución mencionada anteriormente, algunos autores como Jacques Stern [256] indican la validez y equivalencia desde el punto de vista de seguridad de ambas opciones. Sin embargo, a pesar de estar recogida esta opción en algunas obras [30], en los cuatro estándares estudiados la segunda opción no es utilizada. Independientemente de la vulnerabilidad reseñada, Shoup indicó que, en caso de utilizar la función Diﬃe-Hellman con cofactor, es igualmente posible crear un ataque que afecte a la maleabilidad del esquema, puesto que si al punto U se le añade un elemento distinto de O cuyo orden divida el cofactor ℎ, entonces de nuevo a partir de un criptograma válido sería posible generar otro criptograma igualmente válido. La solución más sencilla para este problema consiste en utilizar la función DH sin emplear el cofactor. Shoup caracterizó estos problemas como maleabilidad benigna, dando a entender que no representan un peligro demasiado importante, ya que hasta la fecha no se ha demostrado que este ataque sirva para obtener ningún resultado práctico. Sin embargo, desde el punto de vista formal, si se desea que el esquema ECIES sea no maleable, es necesario solucionar estos problemas.

4.9.1.2. Maleabilidad en el uso de la función XOR como algoritmo de cifrado

Shoup demostró en [243] que el esquema ECIES es también maleable, aunque en este caso de forma no benigna, cuando se utiliza la función XOR como función de cifrado con mensajes de longitud variable, lo que representa un riesgo en ataques de tipo ACCA. En efecto, dado el criptograma

(U, c,tag), supongamos que está formado a partir de los siguientes elementos:

1. La representación binaria U de la clave pública temporal U del emisor.

2. El mensaje en claro m formado por la concatenación de las cadenas m1 y m2, con longitudes respectivas l1 y l2. 4.9. Seguridad de ECIES 175

3. La salida de la función KDF, k∣∣k′, donde la clave de cifrado es la cadena k, ′ ′ que tiene longitud l1 + l2, y la clave MAC es la cadena k , con longitud l . La cadena k se puede construir como la concatenación k1∣∣k2, cuyas longitudes respectivas son l1 y l2.

4. El mensaje cifrado c formado por la concatenación de las cadenas c1 y c2, donde la cadena c1 = m1 ⊕ k1 tiene longitud l1 y la cadena c2 = m2 ⊕ k2 tiene longitud l2. 5. La etiqueta tag consistente en la salida de la función MAC tomando como entrada c y utilizando la clave k′.

Bajo esas premisas, es posible construir de forma artiﬁcial otro criptograma

(U,ˆc, tagˆ ) también válido para los siguientes datos:

1. La representación binaria U de la clave pública temporal U del emisor.

2. Una cadena Δ con longitud l1 y contenido indiferente para el resultado ﬁnal. L 3. El mensaje en claro mˆ = m1 Δ de longitud l1. ˆ ˆ ˆ ˆ 4. La salida de la función KDF, k = k1∣∣k2 = k1∣∣k2, donde la cadena k1 = k1 ˆ tiene longitud l1 y la cadena k2 = k2 tiene longitud l2. L 5. El mensaje cifrado ˆc = c1 Δ de longitud l1. 6. La etiqueta tagˆ consistente en la salida de la función MAC tomando como entrada ˆc y utilizando la clave k2.

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 ﬁja en el caso de utilización de la función XOR [109, 136, 243].

2. Cambiar el orden de interpretación de las claves MAC y de cifrado obtenidas a partir de la función KA, de manera que la clave MAC se obtenga a partir de los bits más a la izquierda de la salida de la función KDF [10, 109, 254, 243, 256].

3. Prohibir la utilización de las funciones de cifrado en ﬂujo en ECIES, permitiendo únicamente los algoritmos de cifrado de bloques [224, 243]. 176 4. Estudio y análisis del esquema de cifrado ECIES

Figura 4.4: Maleabilidad debido a la función XOR 4.9. Seguridad de ECIES 177

4.9.2. Ataques de subgrupos pequeños

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

∙ Calcular el orden de la clave pública del destinatario, comprobando que es igual a n.

∙ Utilizar la primitiva DHC en lugar de la función DH, comprobando que el elemento ℎ u V ∕= O.

∙ Reemplazar el dato secreto compartido por su resumen (por ejemplo, mediante la función SHA-1) antes de utilizar ese dato como entrada de la función KDF.

∙ Utilizar la clave pública temporal del emisor como entrada de la función KDF.

En un escenario típico, la validez de la clave pública del destinatario será realizada por un organismo de certiﬁcación, por lo que esta solución no tendría impacto en una solución comercial. Por otra parte, la utilización de la función DHC conlleva otras desventajas, tal como se menciona en §4.9.1.1, siendo una de las razones por las que los vectores de test de [130, 253] únicamente utilizan la función DH. Respecto a la utilización del resumen del dato secreto compartido en lugar de su valor completo, aunque se menciona en [109] y fue implementado en Java Card 2.2, en la práctica ninguno de los vectores de tests de [130] y [253] lo utilizan, y en la última versión de Java Card se ha añadido un nuevo modo de operación en el que no se aplica ninguna función resumen a la salida de la función KA. Finalmente, la opción más extendida en los estándares analizados consiste en utilizar la clave pública temporal del emisor como entrada de la función KDF, de modo que en el diseño de la propia función KDF se incluye una función resumen de tal manera que a partir de la salida de la función KDF no sea posible obtener ninguna información útil que pudiera llevar a determinar el valor u utilizado. Como consideración 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 información relativa a este par de claves, dicha información no sería útil para posteriores procesos de cifrado. 178 4. Estudio y análisis del esquema de cifrado ECIES

4.9.3. Elección dinámica de parámetros y funciones

Aunque algunos autores como Shoup [243] consideran que es fundamental para la seguridad de ECIES mantener las mismas funciones KDF, ENC y MAC durante el ciclo de vida de un par de claves determinado, y en algunos estándares como IEEE 1363a esté recomendada esta forma de proceder, en la práctica no existe consenso [224] sobre el riesgo real que implicaría el cambio de parámetros y funciones durante el ciclo de vida de unas claves dadas. Por otra parte, puesto que seguir la recomendación de Shoup no parece tener ningún efecto negativo, la prudencia sugiere en este caso imponer como requisito que ni las funciones ni los parámetros puedan ser modificados durante el ciclo de vida de un par de claves. Esto significa que, en la fase inicial de acuerdo de opciones de los usuarios legítimos, éstos deben realizar las comprobaciones adecuadas para asegurar que, para un par de claves específico, solamente se utilizará un conjunto de parámetros a lo largo del ciclo de vida de esas claves.

4.10. Versión de ECIES segura

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

Algoritmo 4.17 Cifrado ECIES compatible con los cuatro estándares (ECIES-3) 1. Elegir un valor aleatorio u ∈ {1, 2, . . . , q − 1} como clave privada temporal de U, y generar la clave pública U = u G.

2. Calcular un punto P = (xP , yP ) de la curva mediante la operación P = u V , donde V es la clave pública del usuario receptor.

3. Generar el elemento K del que se obtendrán las clave de cifrado y autenti- cación mediante la operación K =KDF (xP ), siendo la función KDF elegida KDF2 (equivalente a ANSI-X9.63-KDF sin parámetros opcionales) y la fun- ción HASH empleada SHA-256.

4. Interpretar K como kENC ∣∣kMAC , donde las longitudes en bits de kENC y kMAC son 256 bits. 5. Producir el mensaje cifrado c = ENC (m), donde la función de cifrado simé- trico ENC es el algoritmo AES en modo CBC y relleno PKCS#5 utilizando claves de 256 bits.

6. Calcular la etiqueta tag utilizando el método tag = MAC (c||Param2), donde la función MAC elegida es HMAC-SHA-256 con salida de 256 bits y el elemento Param2 representa la concatenación de una cadena binaria (que representa un dato conocido por usuario y emisor) junto con la longitud en bits de dicho dato empleando para su codiﬁcación 8 bytes.

7. Enviar la tripleta C = (U, c,tag) como criptograma concatenando los tres elementos, de manera que la cadena binaria recibida por el usuario receptor sea U∣∣c∣∣tag.

Capítulo 5

Implementación de ECIES en entorno PC

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

5.1. Diseño del esquema ECIES a implementar

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

181 182 5. Implementación de ECIES en entorno PC funciones KA (tanto DH como DHC) en Java Card es el resultado de utilizar la función resumen SHA-1 tomando como entrada la primera coordenada del punto de la curva que actúa como secreto compartido. Puesto que la presente Tesis pretende comparar el rendimiento de ECIES en plataformas PC y Java Card, y para ello es fundamental que las versiones comparadas tengan las mismas características, fue necesario añadir a la deﬁnición de ECIES para PC las particulares versiones de las funciones de acuerdo de clave DH y DHC de Java Card. Tras estas consideraciones, se incluye en los siguientes apartados la descripción de la funcionalidad completa de la versión de ECIES para PC, utilizando para ello el modelo KEM -DEM popularizado en los últimos años y descrito en §2.5.

5.1.1. Cifrado

El Algoritmo 5.1 describe la fase KEM del proceso de cifrado de la versión de ECIES desarrollada para PC, mientras que el Algoritmo 5.2 muestra la fase DEM del proceso de cifrado de dicha versión. De manera global, la entrada del proceso de cifrado KEM -DEM está formada por un mensaje en claro m, una longitud l y una clave pública V , y la salida consiste en el criptograma C.

Algoritmo 5.1 Cifrado ECIES en la versión PC (fase KEM ) 1. Decidir el formato de representación de los puntos (comprimida o sin comprimir).

2. Elegir un valor u ∈ {1, 2, . . . , q − 1} como clave privada temporal de U.

3. Generar la clave pública del usuario U, U = u G, cuya representación hexadecimal es U.

4. Calcular el punto de la curva P = (xP , yP ) = u V mediante la función DH. La representación hexadecimal de su primera coordenada será xP . 5. Obtener el dato K mediante una de las siguientes opciones:

a) K = KDF (xP ).

b) K = KDF (HASH (xP )).

c) K = KDF (U∣∣xP ).

d) K = KDF (U∣∣HASH (xP )). 5.1. Diseño del esquema ECIES a implementar 183

Algoritmo 5.2 Cifrado ECIES en la versión PC (fase DEM )

1. Interpretar K de una de las siguientes maneras, donde kENC es la clave de cifrado simétrico, y kMAC es la clave para la función de autenticación del mensaje, estando las longitudes de ambos elementos determinadas por el usuario (o por la longitud del propio mensaje, en el caso de utilizar la función XOR):

a) kENC ∣∣kMAC .

b) kMAC ∣∣kENC .

2. Calcular el mensaje cifrado c = ENC(m) empleando la clave kENC y el algoritmo de cifrado simétrico seleccionado por el usuario.

3. Calcular la etiqueta tag = MAC (c||[dat]||long) utilizando la clave kMAC y la función MAC seleccionada por el usuario, donde dat es una cadena de texto opcional acordada por ambos usuarios y el elemento long, que tiene una longitud ﬁja de 8 bytes, contiene el valor de la longitud en bits del dato dat. Como aclaración, los elementos dat y long equivalen al dato Param2 mencionado en el Capítulo 4.

4. Enviar el criptograma C =(U, c,tag) generado mediante la concatenación de sus elementos.

5.1.2. Descifrado

El Algoritmo 5.3 describe la fase KEM del proceso de descifrado de la versión de ECIES desarrollada para PC, en la que se obtiene el material del que se derivan las claves de cifrado y autenticación. Por su parte, el Algoritmo 5.4 muestra la fase DEM del proceso de descifrado de dicha versión, donde se utilizan las claves de cifrado y autenticación para recuperar el mensaje en claro. De manera global, la entrada del proceso de descifrado está formada por un criptograma C y una clave privada v, mientras que la salida consiste en el mensaje en claro m.

5.1.3. Aritmética de puntos de la curva y de elementos del cuerpo ﬁnito

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 ﬁnito. 184 5. Implementación de ECIES en entorno PC

Algoritmo 5.3 Descifrado ECIES en la versión PC (fase KEM ) 1. Interpretar C como la concatenación U∣∣c∣∣tag, veriﬁcando que las longitudes y el formato de cada elemento de la cadena son correctos.

2. Recuperar la clave U a partir de su representación binaria U, comprobando que el punto U tiene orden q.

3. Realizar la multiplicación Q = (xQ, yQ) = v U, y comprobar que Q ∕= O. 4. Obtener el dato K mediante una de las siguientes opciones:

a) K = KDF (xQ).

b) K = KDF (HASH (xQ)).

c) K = KDF (U∣∣xQ).

d) K = KDF (U∣∣HASH (xQ)).

Algoritmo 5.4 Descifrado ECIES en la versión PC (fase DEM )

a) kENC ∣∣kMAC .

b) kMAC ∣∣kENC .

2. Calcular la etiqueta MAC (c||[dat]||long) utilizando la clave kMAC y la fun- ción MAC seleccionada por el usuario mediante las opciones de la aplicación, donde dat y long son los elementos descritos en el Algoritmo 5.2. Si al realizar la comparación el resultado es tag ∕= MAC(c), devolver un error.

3. Descifrar el mensaje original mediante la clave kENC y el algoritmo de cifrado simétrico seleccionado por el usuario, con lo que se obtiene m = ENC −1(c). 5.1. Diseño del esquema ECIES a implementar 185

En lo que respecta a la aritmética de puntos de la curva, la complejidad de las operaciones de suma de dos puntos P y Q y de obtención de 2 P a partir del punto P se puede determinar en función del número de operaciones que es necesario realizar con los elementos de Fq. En la estimación de la complejidad no se suelen tener en cuenta las operaciones de suma y diferencia de elementos del cuerpo ﬁnito debido a que, en comparación con las demás operaciones, son las que requieren menor tiempo de computación.

Dados los elementos a, b ∈ Fq, las operaciones que se utilizan en la práctica para estimar la complejidad de una determinada implementación de la aritmética de puntos son las siguientes:

∙ Multiplicación: a ⋅ b. ∙ Inversión: a−1. ∙ Elevación al cuadrado: a2.

Tal como se indicó en §2.6.3.3, la suma de los puntos P y Q realizada con coordenadas afines requiere 1 inversión, 2 multiplicaciones y 1 elevación al cuadrado tanto en Fp como en F2m , mientras que para obtener el punto 2 P a partir de P igualmente con coordenadas afines es necesario realizar 1 inversión, 2 multiplicaciones y 2 elevaciones al cuadrado al utilizar la fórmula para Fp y una elevación al cuadrado menos si se emplea la fórmula para F2m . Existen otros sistemas de coordenadas que utilizan coordenadas proyectivas y ecuaciones homogéneas de las curvas (coordenadas proyectivas estándar, Jacobianas, López-Dahab, mixtas, etc.) [50, 99]. Estos sistemas implementan la aritmética de puntos de manera más eficiente, dado que en los cálculos con coordenadas proyectivas no es necesario realizar operaciones de inversión, que son las más costosas desde un punto de vista computacional (aunque es cierto que, a cambio, en estos sistemas crece el número de multiplicaciones y elevaciones al cuadrado). Sin embargo, en esta Tesis se han utilizado exclusivamente las fórmulas con coordenadas afines en la implementación de la aritmética de puntos. Los motivos para esta decisión son los siguientes:

1. La utilización de coordenadas aﬁnes produce que el desarrollo y depuración del código Java sea más sencillo, ya que es posible comparar los resultados con los de otras implementaciones (Bouncy Castle, FlexiProvider, etc.). 2. Debido a las características de las plataformas hardware utilizadas y a la ventaja comparativa del PC (procesador de 32 bits, memoria ilimitada en compara- ción con las necesidades del programa, etc.), la ejecución de la implementación para PC es de forma natural más rápida que la ejecución de la implementación para tarjetas Java Card, por lo que la optimización de la versión de ECIES para PC no ha sido considerado un objetivo prioritario. 186 5. Implementación de ECIES en entorno PC

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 conﬁdencial, no podrá realizarse ninguna comparación basada en este elemento.

5.2. Diagrama de clases

La aplicación ECIES que se ha desarrollado para entornos PC como parte de esta Tesis Doctoral está compuesta por 22 clases (agrupadas por conveniencia dentro del paquete victor.tesis), tal como puede observarse en la Figura 5.1, donde las clases pertenecientes a la aplicación aparecen en color azul, mientras que las clases estándar FileFilter, FileView, JDialog, JFrame, Object y PlainDocument de Java, de las que heredan algunas de las clases del programa, aparecen en color gris. A continuación se incluye una breve descripción de cada una de las clases, listadas por orden alfabético:

∙ Constantes Interfaz que incluye algunas constantes utilizadas por las demás clases del programa.

∙ Curva La clase abstracta Curva define los métodos que serán implementados por las clases CurvaFp y CurvaF2m, y que contienen la lógica para crear y utilizar curvas elípticas definidas sobre un cuerpo finito.

∙ CurvaF2m La clase CurvaF2m incluye la implementación adaptada a los cuerpos ﬁnitos binarios de los métodos deﬁnidos por la clase abstracta Curva.

∙ CurvaFp La clase CurvaFp incluye la implementación adaptada a los cuerpos ﬁnitos primos de los métodos deﬁnidos por la clase abstracta Curva.

∙ ECIES ECIES es la clase principal de la aplicación, y por ello contiene el método main. Desde ECIES se realizan las invocaciones a las demás clases del paquete, siendo responsable además de generar la interfaz gráﬁca y gestionar el procesamiento provocado por las acciones del usuario.

∙ ElementoCuerpo 5.2. Diagrama de clases 187

Figura 5.1: Diagrama de clases de la aplicación ECIES 188 5. Implementación de ECIES en entorno PC

La clase abstracta ElementoCuerpo define los métodos con denominación co- mún que serán implementados por ElementoCuerpoFp y ElementoCuerpoF2m, y que contienen la lógica para definir y gestionar elementos de un cuerpo finito. ∙ ElementoCuerpoF2m La clase ElementoCuerpoF2m incluye la implementación adaptada a los cuerpos finitos binarios de los métodos definidos por la clase ElementoCuerpo. ∙ ElementoCuerpoFp La clase ElementoCuerpoFp incluye la implementación adaptada a los cuerpos finitos primos de los métodos definidos por la clase abstracta ElementoCuerpo. ∙ FicheroPubPri La clase FicheroPubPri define los iconos azul y rojo utilizados por la aplica- ción en las ventanas de selección de ficheros para identificar los archivos con claves públicas y privadas, respectivamente. ∙ FiltroDocumentos La clase FiltroDocumentos incluye los elementos que permiten limitar el tipo de datos de entrada (dígitos, caracteres hexadecimales o alfabeto ASCII) de las cajas de texto utilizadas por la aplicación. ∙ FiltroFicheros La clase FiltroFicheros permite crear los filtros necesarios con el objetivo de de mostrar únicamente los ficheros con extensión .pri y .pub en las ventanas de selección de ficheros de claves públicas y privadas respectivamente. ∙ IntArray La clase IntArray implementa la lógica de soporte para la realización de operaciones relacionadas con bases polinómicas en cuerpos binarios. ∙ JDialogAcerca La clase JDialogAcerca es utilizada para mostrar información sobre la versión de la aplicación ECIES y sobre los autores del desarrollo. ∙ JDialogAyuda La clase JDialogAyuda incluye los elementos gráficos de la ventana emergente utilizada por ECIES para presentar al usuario la página HTML con informa- ción sobre la aplicación. ∙ JDialogClave La clase JDialogClave es utilizada por la aplicación ECIES durante la inter- pretación de los contenidos de un fichero que contenga una clave privada, a fin de permitir al usuario introducir su código de acceso a dicha clave. 5.2. Diagrama de clases 189

∙ JDialogDescompresión La clase JDialogDescompresión implementa la funcionalidad ofrecida por la ventana emergente del submenú Descompresión de puntos, descrito en §5.3.7.3.

∙ JDialogFicheros La clase JDialogFicheros representa la ventana emergente utilizada por el submenú Crear ﬁcheros con claves, cuya funcionalidad está descrita en §5.3.7.1.

∙ JDialogGenerarClave La clase JDialogGenerarClave implementa la lógica utilizada por la ventana emergente del submenú Clave aleatoria, descrito en §5.3.7.2.

∙ Punto La clase abstracta Punto define los métodos que serán implementados por las clases PuntoFp y PuntoF2m, y que contienen la lógica para crear puntos de una curva elíptica definida sobre un cuerpo finito y operar con ellos.

∙ PuntoF2m La clase PuntoF2m incluye la implementación adaptada a los cuerpos ﬁnitos binarios de los métodos deﬁnidos por la clase abstracta Punto.

∙ PuntoFp La clase PuntoFp incluye la implementación adaptada a los cuerpos ﬁnitos primos de los métodos deﬁnidos por la clase abstracta Punto.

∙ Utilidades La clase Utilidades incluye los métodos 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 implementación de la aritmética de puntos de la curva y de elementos de los cuerpos ﬁnitos se ha realizado utilizando la clase estándar BigInteger [209] de Java SE, que permite operar con valores enteros de longitud variable, e incluye funciones como la suma con otro elemento BigInteger (método add), el cálculo de la longitud en bits del valor entero (biLength), la obtención del inverso módulo otro elemento del mismo tipo (modInverse), el resultado de la operación XOR con otra variable BigInteger (xor) o la exponenciación modular (modPow), entre otras funciones. 190 5. Implementación de ECIES en entorno PC

5.3. Descripción funcional de la aplicación

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

Figura 5.2: Ventana principal del entorno de desarrollo NetBeans

5.3.1. Ventana principal

La aplicación ECIES permite dos modos de funcionamiento: un modo sencillo donde el usuario no necesita seleccionar parámetros de funcionamiento, pues éstos ya están prefijados (correspondiéndose con los parámetros definidos en §5.3.3.1), y un modo avanzado que posibilita realizar pruebas con múltiples combinaciones de los parámetros disponibles en ECIES. El modo seleccionado por defecto es el modo sencillo, aunque durante la ejecución del programa el modo activo puede modificarse a través del menú Modo. Al iniciar el programa, lo primero que aparece en pantalla es la ventana principal, 5.3. Descripción funcional de la aplicación 191 tal como muestra la Figura 5.3. En ella pueden observarse las tres zonas principales en que se divide la pantalla, y que se corresponden con las áreas delimitadas mediante un recuadro rojo, azul y verde respectivamente en la Figura 5.3.

∙ Barra del menú principal: proporciona acceso a todos los menús y opciones del programa. Los elementos que se encuentran disponibles en el modo sencillo cuando se inicia la ejecución son Programa, Modo, Curvas, Utilidades y Cuerpo GF(p), mientras que si se utiliza el modo avanzado entonces también estarán disponibles los elementos Perﬁles y Test.

∙ Barra de pestañas: permite seleccionar la pestaña activa mediante una presen- tación tabular. En el modo sencillo las pestañas disponibles son Parámetros, Cifrado y Descifrado, a las que se añade la pestaña Conﬁguración en el modo avanzado.

∙ Pestaña activa: área de presentación donde se sitúan los elementos pertenecientes la pestaña en uso.

5.3.2. Menú Programa

El menú Programa consta de los submenús Aspecto, Ayuda, Acerca de y Salir.

5.3.2.1. Submenú Aspecto

La opción Aspecto (ver Figura 5.4) permite adaptar las características de todos los elementos de la aplicación (textos, iconos, colores, etc.) a las de los temas grá- ﬁcos disponibles en Java. Las posibilidades existentes en la versión Java SE 6 para plataformas PC son:

∙ Metal: apariencia Java multiplataforma presente desde las primeras versiones del JDK.

∙ Nimbus: nueva apariencia Java multiplataforma disponible desde la revisión 10 de Java SE 6.

∙ Motif: aspecto Unix.

∙ Windows: apariencia nativa de las aplicaciones Windows.

∙ Windows Clásico: tema gráﬁco muy similar al anterior pero con un aspecto más clásico. 192 5. Implementación de ECIES en entorno PC

Figura 5.3: Ventana principal de la aplicación

Figura 5.4: Opciones del menú Programa 5.3. Descripción funcional de la aplicación 193

Por motivos estéticos, se ha decidido implementar únicamente los dos temas más modernos, en concreto Nimbus (Figura 5.5) y Windows (Figura 5.6). Si la distribución Java SE instalada en el PC de trabajo implementa la estética Nimbus, éste será el tema seleccionado por defecto al iniciar la aplicación. En caso contrario, el aspecto gráﬁco utilizado será el propio de Windows.

Figura 5.5: Ejemplo de ventana con aspecto Nimbus

Figura 5.6: Ejemplo de ventana con aspecto Windows

5.3.2.2. Submenú Ayuda

La opción Ayuda (ver Figura 5.4) permite acceder a una ventana en la que se presenta la ayuda del programa en formato HTML, tal como puede apreciarse en la Figura 5.7. 194 5. Implementación de ECIES en entorno PC

Figura 5.7: Ventana de la opción Ayuda

5.3.2.3. Submenú Acerca de

La opción Acerca de (ver Figura 5.4) muestra información general sobre la versión del programa y los responsables del desarrollo, tal como aparece en la Figura 5.8.

5.3.2.4. Submenú Salir

La opción Salir (ver Figura 5.4), al igual que el icono situado en la esquina superior derecha en todas las aplicaciones Windows, permite abandonar la aplicación. Sin embargo, en previsión de la activación accidental de esta opción, antes de abandonar el programa se mostrará al usuario una pantalla de conﬁrmación, tal como queda reﬂejado 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. 5.3. Descripción funcional de la aplicación 195

Figura 5.8: Ventana de la opción Acerca de

Figura 5.9: Pantalla de conﬁrmación de la opción Salir 196 5. Implementación de ECIES en entorno PC

5.3.3.1. Opción Sencillo

El modo sencillo (Figura 5.10) utiliza una parametrización ﬁja del esquema ECIES, correspondiente a la versión ECIES-3, que consiste en los siguientes elementos:

∙ Función resumen HASH : SHA-256.

∙ Función KDF : KDF2.

∙ Función MAC : HMAC-SHA-256-256.

∙ Función de cifrado ENC : AES en modo CBC con relleno PKCS#5.

∙ Longitud de la clave MAC : 32 bytes.

∙ Longitud de la clave de cifrado: 32 bytes.

∙ Inclusión de la clave temporal del emisor como parámetro de KDF : activado.

∙ Interpretación de la salida de la función KDF : ENC ||MAC.

∙ Representación binaria: comprimida.

Junto a la utilización de los parámetros anteriores, el modo sencillo oculta los menús Perﬁles y Test de la barra de menús, así como la pestaña Conﬁguración, ya que estos elementos sólo tienen utilidad en el modo avanzado.

Figura 5.10: Opción Sencillo

5.3.3.2. Opción Avanzado

El modo avanzado (Figura 5.11) permite, en comparación con el modo sencillo, especiﬁcar todos los parámetros para los que el esquema ECIES puede utilizar distintas opciones. En concreto, los elementos que es posible parametrizar son los siguientes: 5.3. Descripción funcional de la aplicación 197

Figura 5.11: Opción Avanzado

∙ Función resumen HASH.

∙ Función KDF.

∙ Función MAC.

∙ Función de cifrado ENC.

∙ Inclusión de la clave pública temporal del emisor como parámetro de KDF.

∙ Utilización de la primera coordenada del secreto compartido o de su resumen.

∙ Interpretación de la salida de la función KDF.

∙ Representación binaria comprimida o sin comprimir.

Además de lo anterior, el modo avanzado habilita los menús Perﬁles y Test de la barra de menús, así como la pestaña Conﬁguración.

5.3.4. Menú Perﬁles (modo avanzado)

El menú Perfiles (Figura 5.12) permite, en el modo avanzado, definir los valores de los elementos de la pestaña Configuración relacionados con un mismo modo de operación. Las opciones que el usuario puede elegir están relacionadas con las configuraciones M1, M2, P1, P2 y P3 descritas en §7.2 y utilizadas en las pruebas del Capítulo 7. 198 5. Implementación de ECIES en entorno PC

Figura 5.12: Opciones del menú Perﬁles

5.3.4.1. Opción Conﬁguración M1

La opción Conﬁguración M1, diseñada para su utilización por la aplicación de PC, emplea los siguientes valores:

∙ Cuerpo sobre el que se deﬁne la curva elíptica: F2m . ∙ Función HASH : SHA-256.

∙ Función KA: DH.

∙ Función KDF : KDF2.

∙ Función ENC : AES en modo CBC con relleno PKCS#5.

∙ Función MAC : HMAC-SHA-256-256.

∙ Longitud de la clave de cifrado simétrico: 32 bytes.

∙ Longitud de la clave MAC : 32 bytes.

∙ Inclusión de la clave temporal del emisor como parámetro de KDF : sí.

∙ Utilización de la coordenada del secreto compartido o de su resumen: coordenada.

∙ Interpretación de la salida de la función KDF : ENC ||MAC.

∙ Representación binaria de los puntos de la curva: comprimida.

5.3.4.2. Opción Conﬁguración M2

La opción Conﬁguración M2, diseñada para su utilización tanto por la aplicación de PC como por las tarjetas JCOP 41, personaliza los elementos de ECIES con los siguientes valores: 5.3. Descripción funcional de la aplicación 199

∙ Cuerpo sobre el que se deﬁne la curva elíptica: F2m . ∙ Función HASH : SHA-1.

∙ Función KA: DH.

∙ Función KDF : KDF2.

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

∙ Función MAC : HMAC-SHA-1-160.

∙ Longitud de la clave de cifrado simétrico: 16 bytes.

∙ Longitud de la clave MAC : 20 bytes.

∙ Inclusión de la clave temporal del emisor como parámetro de KDF : no.

∙ Utilización de la coordenada del secreto compartido o de su resumen: resumen.

∙ Interpretación de la salida de la función KDF : ENC ||MAC.

∙ Representación binaria de los puntos de la curva: sin comprimir.

5.3.4.3. Opción Conﬁguración P1

La opción Conﬁguración P1, diseñada para su utilización por la aplicación de PC, personaliza los elementos de ECIES con los siguientes valores:

∙ Cuerpo sobre el que se deﬁne la curva elíptica: Fp. ∙ Función HASH : SHA-256.

∙ Función KA: DH.

∙ Función KDF : KDF2.

∙ Función ENC : AES en modo CBC con relleno PKCS#5.

∙ Función MAC : HMAC-SHA-256-256.

∙ Longitud de la clave de cifrado simétrico: 32 bytes.

∙ Longitud de la clave MAC : 32 bytes.

∙ Inclusión de la clave temporal del emisor como parámetro de KDF : sí.

∙ Utilización de la coordenada del secreto compartido o de su resumen: coordenada. 200 5. Implementación de ECIES en entorno PC

∙ Interpretación de la salida de la función KDF : ENC ||MAC.

∙ Representación binaria de los puntos de la curva: comprimida.

5.3.4.4. Opción Conﬁguración P2

La opción Conﬁguración P2, diseñada para su utilización tanto por la aplicación de PC como por las tarjetas JCOP J3A, utiliza los siguientes elementos:

∙ Cuerpo sobre el que se deﬁne la curva elíptica: Fp. ∙ Función HASH : SHA-1.

∙ Función KA: DH.

∙ Función KDF : KDF2.

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

∙ Función MAC : HMAC-SHA-1-160.

∙ Longitud de la clave de cifrado simétrico: 16 bytes.

∙ Longitud de la clave MAC : 20 bytes.

∙ Inclusión de la clave temporal del emisor como parámetro de KDF : no.

∙ Utilización de la coordenada del secreto compartido o de su resumen: resumen.

∙ Interpretación de la salida de la función KDF : ENC ||MAC.

∙ Representación binaria de los puntos de la curva: sin comprimir.

5.3.4.5. Opción Conﬁguración P3

La opción Conﬁguración P3, diseñada para su utilización tanto por la aplicación de PC como por las tarjetas JCOP J3A, personaliza los elementos de ECIES con los siguientes valores:

∙ Cuerpo sobre el que se deﬁne la curva elíptica: Fp. ∙ Función HASH : SHA-256.

∙ Función KA: DH.

∙ Función KDF : KDF2. 5.3. Descripción funcional de la aplicación 201

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

∙ Función MAC : HMAC-SHA-256-256.

∙ Longitud de la clave de cifrado simétrico: 16 bytes.

∙ Longitud de la clave MAC : 32 bytes.

∙ Inclusión de la clave temporal del emisor como parámetro de KDF : no.

∙ Utilización de la coordenada del secreto compartido o de su resumen: coordenada.

∙ Interpretación de la salida de la función KDF : ENC ||MAC.

∙ Representación binaria de los puntos de la curva: sin comprimir.

5.3.5. Menú Test (modo avanzado)

El menú Test es similar al menú Perfiles, puesto que permite configurar los pa- rámetros de ECIES de la pestaña Configuración en el modo avanzado, pero además añade los valores necesarios de la pestaña Parámetros de acuerdo a los documentos de prueba relacionados en cada caso.

5.3.5.1. Submenú ISO/IEC

El submenú ISO/IEC (Figura 5.13) incluye los tests C.2.2 y C.2.3 recogidos en ISO/IEC 18033-2 [136].

Figura 5.13: Submenú ISO/IEC del menú Test

5.3.5.2. Submenú SECG

El submenú SECG (Figura 5.14) incluye los tests GEC2-3.1 y GEC2-3.2 recogidos en el documento SECG GEC 2 [253]. 202 5. Implementación de ECIES en entorno PC

Figura 5.14: Submenú SECG del menú Test

5.3.6. Menú Curvas

El menú Curvas permite cargar en la pestaña Parámetros información correspondiente a la curva seleccionada en función de su proveedor y del identiﬁcador asignado a la curva.

5.3.6.1. Submenú ANSI

El submenú ANSI (Figura 5.15) incluye las siguientes curvas deﬁnidas sobre cuerpos primos y binarios en el documento ANSI X9.62 [15]:

∙ Curvas sobre Fp: ansix9p192r1, ansix9p192k1, ansix9p224r1, ansix9p224k1, an- six9p256r1, ansix9p256k1, ansix9p384r1 y ansix9p521r1.

∙ Curvas sobre F2m : ansix9t163r2, ansix9t163k1, ansix9t193r1, ansix9t193r2, an- six9t233r1, ansix9t233k1, ansix9t239k1, ansix9t283r1, ansix9t283k1, ansix9t409r1, ansix9t409k1, ansix9t571r1 y ansix9t571k1.

El signiﬁcado de los elementos utilizados en los identiﬁcadores de las curvas ANSI se explica a continuación:

∙ ansix9 : identiﬁca las curvas deﬁnidas por ANSI en [15].

∙ p: indica que se trata de una curva sobre cuerpos primos.

∙ t: identiﬁca las curvas sobre cuerpos binarios.

∙ Primera cadena de dígitos: expresa el tamaño en bits del cuerpo sobre el que está deﬁnida la curva.

∙ r: informa que los coeﬁcientes de la curva se han generado de forma aleatoria mediante una semilla y una función resumen de acuerdo al procedimiento descrito en [15]. 5.3. Descripción funcional de la aplicación 203

Figura 5.15: Curvas correspondientes al submenú ANSI

∙ k: identifica las curvas de Koblitz (también conocidas como curvas anóma- las binarias) que facilitan la realización de operaciones con los puntos de la curva. En curvas sobre cuerpos binarios, las curvas de Koblitz están definidas mediante la ecuación y2 + x y = x3 + a x2 + 1, con a ∈ {0, 1}. ANSI X9.62 también utiliza el término k para referirse a curvas definidas sobre cuerpos primos, dadas por la ecuación y2 = x3 + a x + b, donde a = 0 y el valor de b es muy pequeño en comparación con p (3, 5, 7, etc.).

∙ Dígito ﬁnal: permite diferenciar curvas donde el resto de los parámetros utilizados por esta notación coinciden.

Es importante resaltar que las curvas publicadas en la versión de 2005 del es- tándar X9.62 no coinciden con las incluidas en la edición de 1998, puesto que tal como se describe en [15], algunas se eliminaron por no ser consideradas seguras a la vista de los últimos avanzas en criptoanálisis (c2pnb176w1, c2pnb163v3, etc.). De manera adicional, la edición de 2005 cambió los identiﬁcadores de las restantes curvas (por ejemplo, la curva ansix9p192r1 de la edición de 2005 es la misma que la curva prime192v1 de la edición de 1998). 204 5. Implementación de ECIES en entorno PC

5.3.6.2. Submenú Brainpool

El submenú Brainpool (Figura 5.16) incluye las siguientes curvas deﬁnidas sobre cuerpos primos, tal como aparecen recogidas en la página web del grupo de trabajo Brainpool [33]:

∙ Curvas sobre Fp: P160r1, P192r1, P224r1, P256r1, P320r1, P384r1 y P512r1.

Es necesario indicar que Brainpool no dispone de curvas sobre cuerpos binarios F2m . El signiﬁcado de los elementos utilizados en los identiﬁcadores de las curvas Brainpool se muestra a continuación:

∙ P: identifica las curvas sobre cuerpos primos. ∙ Primera cadena de dígitos: expresa el tamaño en bits del cuerpo sobre el que está definida la curva. ∙ r: informa que los coeficientes de la curva se han generado aleatoriamente según el procedimiento descrito en [34]. ∙ Dígito final: permite identificar diferentes curvas donde el resto de los pará- metros utilizados por esta notación coinciden.

Figura 5.16: Curvas correspondientes al submenú Brainpool

5.3.6.3. Submenú NIST

El submenú NIST (Figura 5.17) incluye las siguientes curvas deﬁnidas sobre cuerpos primos y binarios en el documento FIPS 186-3 [184]:

∙ Curvas sobre Fp: P-192, P-224, P-256, P-384 y P-521.

∙ Curvas sobre F2m : K-163, B-163, K-233, B-233, K-283, B-283, K-409, B-409, K-571 y B-571. 5.3. Descripción funcional de la aplicación 205

Figura 5.17: Curvas correspondientes al submenú NIST

El signiﬁcado de los elementos utilizados como parte de los identiﬁcadores de las curvas NIST es el siguiente:

∙ P: identiﬁca 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 (deﬁnida sobre cuerpos binarios).

∙ Cadena de dígitos: expresa el tamaño en bits del cuerpo sobre el que está deﬁnida la curva.

5.3.6.4. Submenú SECG

El submenú SECG (Figura 5.18) incluye las siguientes curvas deﬁnidas sobre cuerpos primos y binarios en el documento SEC 2 [255]:

∙ Curvas sobre Fp: secp112r1, secp112r2, secp128r1, secp128r2, secp160k1, secp- 160r1, secp160r2, secp192k1, secp224k1, secp224r1, secp256k1, secp384r1 y secp521r1. 206 5. Implementación de ECIES en entorno PC

Figura 5.18: Curvas correspondientes al submenú SECG

∙ Curvas sobre F2m : sect113r1, sect113r2, sect131r1, sect131r2, sect163k1, sect- 163r1, sect163r2, sect193r1, sect193r2, sect233k1, sect233r1, sect239k1, sect- 283k1, sect283r1, sect409k1, sect409r1, sect571k1 y sect571r1.

El signiﬁcado de los elementos utilizados como parte de los identiﬁcadores de las curvas del consorcio SECG se detalla a continuación:

∙ secp: identiﬁca las curvas sobre cuerpos primos.

∙ sect: indica que se trata de una curva sobre cuerpos binarios.

∙ Primera cadena de dígitos: expresa el tamaño en bits del cuerpo sobre el que está deﬁnida la curva. 5.3. Descripción funcional de la aplicación 207

∙ r: indica que los coeﬁcientes de la curva han sido seleccionados aleatoriamente de forma veriﬁcable.

∙ k: informa que se trata de una curva de Koblitz (deﬁnida sobre cuerpos binarios).

∙ Dígito ﬁnal: permite identiﬁcar diferentes curvas donde el resto de los pará- metros utilizados por esta notación coinciden.

5.3.7. Menú Utilidades

El menú Utilidades ofrece funcionalidades que, sin ser imprescindibles para la utilización del programa de cifrado ECIES, facilitan considerablemente su uso.

5.3.7.1. Opción Crear ﬁcheros con claves

La opción Crear ficheros con claves (ver Figura 5.19) permite generar un par de claves utilizando la información de las curvas estándares referidas en §5.3.6, alma- cenando la información resultante en un fichero con extensión .pri que contiene la clave privada y un fichero con extensión .pub que alberga la clave pública.

Figura 5.19: Opciones del menú Utilidades

Al seleccionar esta opción, el usuario debe introducir o seleccionar en la nueva ventana (Figura 5.20) los siguientes datos:

∙ Cuerpo (obligatorio): posibilidad de elegir entre cuerpos primos o binarios.

∙ Proveedor de la curva (obligatorio): organismo responsable de la generación y publicación de los datos de la curva. Las opciones disponibles son ANSI, Brainpool, NIST y SECG.

∙ Curva (obligatorio): nombre identiﬁcativo empleado por el proveedor para cada curva. 208 5. Implementación de ECIES en entorno PC

Figura 5.20: Ventana de creación de los ﬁcheros de claves

∙ Código de seguridad (obligatorio): código de acceso o contraseña para permitir el almacenamiento seguro de la clave. La implementación de la seguridad de este almacenamiento se realiza mediante la función resumen SHA-256 y el algoritmo de cifrado AES, de manera que la clave privada nunca se almacenará en claro, siendo necesario introducir el código de seguridad para poder utilizar la clave privada en las operaciones de descifrado. La clave con la que se cifra la información consiste en los primeros 16 bytes de la salida de la función SHA-256, donde la entrada se corresponde con el código de seguridad.

∙ Nombre de fichero (obligatorio): los dos ficheros a generar, tanto el que contiene la clave pública como el utilizado para almacenar la clave privada, comparti- rán el mismo nombre de fichero, diferenciándose en la extensión (.pub y .pri, respectivamente).

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

deseado.

∙ Información adicional (opcional): texto que, en caso de ser incluido en los ﬁcheros de claves, será utilizado por el programa como identiﬁcador de la clave.

Algoritmo 5.5 Generación de una semilla aleatoria Ejecutar el siguiente bucle seis veces: 1. Obtener el tiempo en milisegundos mediante la función estándar del lenguaje Java SE System.currentTimeMillis().

2. Multiplicar el valor obtenido por el número de iteración.

3. Identiﬁcar los últimos tres dígitos del resultado de la multiplicación.

4. Concatenar esos tres dígitos con los obtenidos en las anteriores iteraciones, formando una cadena ﬁnal de dieciocho dígitos.

Los ficheros de claves generados contienen toda la información necesaria para poder identificar las claves y realizar las operaciones de cifrado y descifrado, utilizando internamente una estructura XML para almacenar los distintos datos. A continuación se muestra un ejemplo del contenido de un fichero .pub que alberga la clave pública de un usuario:

HEXA Fp Pública SEC secp112r1 Clave de Víctor

DB7C2ABF62E35E668076BEAD208B

DB7C2ABF62E35E668076BEAD2088 659EF8BA043916EEDE8911702B22 09487239995A5EE76B55F9C2F098 A89CE5AF8724C0A23E0E0FF77500 DB7C2ABF62E35E7628DFAC6561C5 CBB0C998897515D8AF9E474ADEF0 210 5. Implementación de ECIES en entorno PC

7B492D22D7872C4CCAB5B58620CC

Continuando con el mismo ejemplo, el ﬁchero .pri que contiene la clave privada del usuario anterior tendría el siguiente contenido:

HEXA Fp Privada SEC secp112r1 Clave de Víctor

DB7C2ABF62E35E668076BEAD208B

DB7C2ABF62E35E668076BEAD2088 659EF8BA043916EEDE8911702B22 09487239995A5EE76B55F9C2F098 A89CE5AF8724C0A23E0E0FF77500 DB7C2ABF62E35E7628DFAC6561C5 7D1C0CF1FC2B741B960A7AE0093B7485

A continuación se muestra otro ejemplo de ﬁcheros .pub y .pri, en esta ocasión representando un par de claves deﬁnidas sobre un cuerpo binario:

HEXA F2m Pública SEC sect113r1 5.3. Descripción funcional de la aplicación 211

Clave de Luis 71 09 3088250CA6E7C7FE649CE85820F7 E8BEE4D3E2260744188BE0E9C723 9D73616F35F4AB1407D73562C10F A52830277958EE84D1315ED31886 0100000000000000D9CCEC8A39E56F 5AC878E613A8C0EB857D2C007453 5F9964C68A87793F17F13669DB44

HEXA F2m Privada SEC sect113r1 Clave de Luis 71 09 3088250CA6E7C7FE649CE85820F7 E8BEE4D3E2260744188BE0E9C723 9D73616F35F4AB1407D73562C10F A52830277958EE84D1315ED31886 0100000000000000D9CCEC8A39E56F 9442D1ACEE5F3C384AA8060424A3CCEA

El signiﬁcado de cada uno de los elementos de ambos ﬁcheros XML es el siguiente: 212 5. Implementación de ECIES en entorno PC

∙ : número de clave (ya sea pública o privada) relativo al ﬁ- chero, dado que los ﬁcheros .pri y .pub permiten ser utilizados como agendas de claves y almacenar más de una clave.

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

∙ : cuerpo de la curva elíptica utilizada en la generación de las claves. En función del cuerpo seleccionado, los posibles textos para esta opción son Fp y F2m.

∙ : cadena informativa que incluye los elementos (que puede tener los valores Privada y Pública), (cuyos valores posibles son ANSI, Brainpool, NIST y SEC) y por último , el nombre especíﬁco que cada proveedor otorga a sus curvas.

∙ : información adicional utilizada por el programa para presentarla por pantalla, de manera que el usuario pueda seleccionar la clave adecuada durante los procesos de cifrado y descifrado.

∙ , , , , : parámetros comunes para curvas deﬁnidas tanto sobre un cuerpo primo como binario.

∙

: parámetro asociado a las curvas deﬁnidas sobre un cuerpo primo.

∙ , , , : parámetros de la curvas deﬁnidas sobre un cuerpo binario.

∙ , : coordenadas del punto que representa la clave pública creada.

∙ : clave privada del usuario cifrada con el algoritmo AES mediante el código de acceso.

5.3.7.2. Opción Clave aleatoria

La opción Clave aleatoria (ver Figura 5.19) ofrece la posibilidad de generar una clave privada pseudoaleatoria a partir de los datos de entrada, que dependiendo del cuerpo de trabajo son:

∙ Cuerpos Fp: número primo p y semilla de aleatoriedad. 5.3. Descripción funcional de la aplicación 213

∙ Cuerpos F2m : parámetro m, que representa el número de bits utilizado en la representación binaria de los elementos de ese cuerpo, y semilla de aleatoriedad.

Dependiendo del cuerpo de trabajo, y que es seleccionable por el usuario desde el menú Cuerpo GF(p)/Cuerpo GF(2^m) descrito en §5.3.8, la ventana de trabajo del menú Clave aleatoria es diferente, tal como puede apreciarse en las Figuras 5.21 y 5.22.

Figura 5.21: Ventana de generación de clave en cuerpos Fp

Figura 5.22: Ventana de generación de clave en cuerpos F2m 214 5. Implementación de ECIES en entorno PC

5.3.7.3. Opción Descompresión de puntos

La opción Descompresión de puntos (ver Figura 5.19) permite, tras introducir los datos asociados a una curva elíptica y a un punto de la curva en formato comprimido, obtener ambas coordenadas de dicho punto. Dependiendo del cuerpo de trabajo, la ventana del menú Descompresión de puntos es diferente, tal como puede comprobarse en las Figuras 5.23y 5.24.

Figura 5.23: Ventana de descompresión de puntos en cuerpos Fp

5.3.8. Menú Cuerpo GF(p)/Cuerpo GF(2^m)

El último elemento del menú principal permite intercambiar el tipo de cuerpo sobre el que se encuentra deﬁnida la curva elíptica de trabajo. Si el nombre de la opción es Cuerpo GF(p), al pulsar sobre ese título el usuario comprobará que el nombre es sustituido por Cuerpo GF(2^m), siendo seleccionada de manera automá- tica la pestaña Parámetros donde se encuentran las cajas de texto de los parámetros asociados al nuevo cuerpo. Las Figuras 5.25y 5.26 muestran el aspecto de la barra de menú principal cuando el cuerpo de trabajo es Fp y F2m respectivamente. 5.3. Descripción funcional de la aplicación 215

Figura 5.24: Ventana de descompresión de puntos en cuerpos F2m

De forma equivalente, si se encuentra seleccionada la opción Cuerpo GF(2^m) y el usuario pulsa sobre ese título, el nombre del elemento cambiará por el de Cuerpo GF(p), siendo seleccionada automáticamente la pestaña Parámetros donde se sitúan las cajas de texto con los parámetros asociados al nuevo cuerpo.

Figura 5.25: Menú principal con el elemento Cuerpo GF(p) activado

5.3.9. Pestaña Conﬁguración (en modo avanzado)

La pestaña Conﬁguración, que sólo es visible cuando se encuentra seleccionado el modo avanzado, permite conﬁgurar los elementos de ECIES independientemente 216 5. Implementación de ECIES en entorno PC

Figura 5.26: Menú principal con el elemento Cuerpo GF(2^m) activado

de si el cuerpo de trabajo es Fp o F2m . La Figura 5.27 muestra los elementos de esta pestaña, y que son presentados a continuación indicando las opciones disponibles.

∙ Función resumen HASH :

SHA-1. SHA-256. SHA-384. SHA-512. ∙ Función de derivación de claves KDF :

KDF1. KDF2. ∙ Función de generación de códigos MAC :

HMAC-SHA-1-160. HMAC-SHA-256-256. HMAC-SHA-384-384. HMAC-SHA-512-512. ∙ Función de cifrado simétrico ENC :

XOR. AES en modo CBC con relleno PKCS#5. AES en modo ECB con relleno PKCS#5. TDES en modo CBC sin relleno. TDES en modo CBC con relleno PKCS#5. ∙ Longitud en bytes de la clave a utilizar por la función MAC. 5.3. Descripción funcional de la aplicación 217

Figura 5.27: Pestaña Conﬁguración

∙ Longitud en bytes de la clave a utilizar por el algoritmo de cifrado simétrico. ∙ Opción de incluir la clave pública temporal U del emisor como entrada de la función KDF. ∙ Utilización de la primera coordenada del dato secreto compartido u V o de la salida a través de la función resumen seleccionada previamente por el usuario. ∙ Orden en que se debe interpretar la salida de la función de generación de claves (MAC ||ENC o ENC ||MAC ). ∙ Representación binaria de los puntos de la curva comprimida o sin comprimir.

5.3.10. Pestaña Parámetros

La pestaña Parámetros muestra los elementos de la curva elíptica a los que es necesario dar valores para poder realizar operaciones de cifrado o descifrado con 218 5. Implementación de ECIES en entorno PC

ECIES. Esta operación puede realizarse mediante tres procedimientos:

1. Introducción manual de los parámetros por parte del usuario de la aplicación a través de las cajas de texto de esta pestaña.

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

3. Selección de la clave pública del destinatario o de la clave privada del propio usuario de la aplicación mediante las opciones apropiadas de las pestañas Ci- frado y Descifrado. En estos casos, si los ﬁcheros que incluyen dichas claves contienen todos los elementos necesarios, el usuario no deberá añadir ningún dato en la pestaña Parámetros.

En los casos en los que la aplicación aporte algunos de los datos (es decir, el usuario seleccione una curva o indique al programa el fichero con la clave a recuperar), las cajas de texto de esta pestaña se mantienen habilitadas, lo que implica que el usuario podría modificar dichos datos. Si dicha modificación conlleva algún error (por ejemplo, el elemento generador o la clave pública no pertenecen a la curva modificada), éste será convenientemente detectado durante la ejecución de cualquiera de las operaciones del programa (cifrado, descifrado, generación de la clave pública a partir de los datos de la curva y de la clave privada, etc.). En cuanto al contenido de esta pestaña, dependiendo de si el cuerpo finito de trabajo, denominado de forma genérica Fq, es Fp o F2m , la pestaña Parámetros mostrará distintos elementos, tal como puede apreciarse en las Figuras 5.28y 5.29. Independientemente del cuerpo finito seleccionado, los parámetros comunes que aparecen en esta pestaña en ambos casos son los siguientes:

∙ a: primer parámetro de la curva elíptica E cuya ecuación es (2.4) o (2.5), con a ∈ Fq.

∙ b: segundo parámetro de la curva elíptica, con b ∈ Fq.

∙ Gx: primera coordenada del generador G, donde G = (Gx,Gy). Gx es un elemento del cuerpo base Fq, mientras que G es un punto de la curva elíptica.

∙ Gy: segunda coordenada del generador G, con Gy ∈ Fq. ∙ n: orden del punto G. 5.3. Descripción funcional de la aplicación 219

Figura 5.28: Pestaña Parámetros con el menú Cuerpo GF(p) activado

∙ h: cofactor del punto G, de manera que ℎ = #E(Fq)/n, siendo #E(Fq) el número de puntos de la curva elíptica.

∙ u: clave privada temporal del usuario emisor, donde u ∈ Fq.

∙ v: clave privada permanente del usuario receptor, siendo v ∈ Fq. ∙ Ux: primera coordenada de la clave pública temporal del usuario emisor. La clave pública es U, donde U = (Ux,Uy). Ux es un elemento de Fq y U es un punto de la curva elíptica.

∙ Uy: segunda coordenada de la clave pública temporal del usuario emisor, donde Uy ∈ Fq. ∙ Vx: primera coordenada de la clave pública permanente del usuario receptor. La clave pública es V , donde V = (Vx,Vy). Vy es un elemento de Fq, mientras que V es un punto de la curva elíptica. 220 5. Implementación de ECIES en entorno PC

Figura 5.29: Pestaña Parámetros con el menú Cuerpo GF(2^m) activado

∙ Vy: segunda coordenada de la clave pública permanente del usuario receptor, donde V y ∈ Fq.

Cuando el menú Cuerpo GF(p) está activado, el único elemento relacionado con este cuerpo que aparece en la pestaña es:

∙ p: número primo utilizado por el cuerpo ﬁnito Fp.

Por el contrario, cuando el menú Cuerpo GF(2^m) está activado, los nuevos elementos que aparecen en la pestaña son:

∙ m: exponente utilizado por el cuerpo ﬁnito F2m .

∙ k3 : exponente del polinomio reductor f(x) = xm + xk3 + xk2 + xk1 + 1.

∙ k2 : exponente del polinomio reductor f(x). 5.3. Descripción funcional de la aplicación 221

∙ k1 : exponente del polinomio reductor f(x).

Independientemente del cuerpo de trabajo, la pestaña Parámetros incluye los siguientes elementos:

∙ Formato: representación de los datos precedentes en formato hexadecimal o decimal.

∙ Resultado: información acerca del resultado de la ejecución.

∙ Generar: botón que permite calcular las coordenadas de las claves públicas U y V a partir de las claves privadas u y v.

∙ Borrar: botón para el borrado de todos los datos de esta pantalla.

Si la operación de cálculo de las coordenadas U y V es correcta, el contenido del elemento Resultado será el texto:

Proceso finalizado correctamente.

Por el contrario, los posibles mensajes de error que puede mostrar el elemento Resultado son:

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

5.3.11. Pestaña Cifrado

La pestaña Cifrado muestra todos los elementos necesarios para generar un 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 gestión de opciones, las cajas de texto y los botones de operación, tal como puede apreciarse en la Figura 5.30. La primera sección está formada por los siguientes elementos: 222 5. Implementación de ECIES en entorno PC

Figura 5.30: Pestaña Cifrado

∙ Clave pública receptor: clave pública permanente del destinatario del criptograma. Si el usuario pulsa la opción Texto, la pestaña Parámetros pasará a ser la pestaña en uso, de manera que el usuario pueda introducir manualmente los datos asociados a la clave pública del receptor. En cambio, si el usuario elige la opción Fichero, el programa permitirá seleccionar el fichero donde se encuentra la clave pública, tal como puede apreciarse en la Figura 5.31. Si el procesamiento del fichero con la clave pública es correcto, en la pestaña Parámetros aparecerán los datos obtenidos del fichero con extensión .pub seleccionado.

∙ Mensaje a cifrar: mensaje en claro que el emisor desea enviar al receptor. Si el usuario pulsa la opción Texto (opción por defecto), deberá introducir el mensaje manualmente, sin que exista ningún límite en la longitud del mensaje generado por el usuario. Por el contrario, si el usuario elige la opción Fichero, el programa permitirá seleccionar el ﬁchero cuyo contenido binario será utilizado como mensaje en claro, tal como puede observarse en la Figura 5.32. Si el procesamiento del ﬁchero que representa el mensaje es correcto y su tamaño 5.3. Descripción funcional de la aplicación 223

es superior a 1 Kbyte, aunque internamente se utilizará el ﬁchero completo en el proceso de cifrado, únicamente se mostrarán en la caja de texto asociada al mensaje en claro los primeros 1024 bytes, utilizando una fuente de color azul para indicar este hecho. En comparación, la fuente de texto de color negro indica que todo el contenido del ﬁchero se encuentra presente en la caja de texto.

∙ Criptograma: tripleta de elementos resultado de la operativa de cifrado que el emisor debe enviar al receptor tras su generación. Si el usuario pulsa la opción Texto (opción por defecto), el contenido del criptograma será únicamente mostrado por pantalla en su caja de texto asociada. Por el contrario, si el usuario elige la opción Fichero, el programa permitirá al usuario seleccionar un ﬁchero (Figura 5.33) de manera que, además de mostrarse el criptograma en la caja de texto, su contenido será almacenado en el ﬁchero indicado. Únicamente en este último caso, si el tamaño del criptograma supera el límite de 1 Kbyte, entonces sólo se mostrarán (utilizando de nuevo una fuente de color azul) los primeros 1024 bytes del criptograma. Comparativamente, la fuente de texto de color negro indica que el contenido del criptograma se encuentra íntegramente representado en la caja de texto.

Figura 5.31: Selección del ﬁchero con la clave pública

En caso de elegir la opción Fichero en cualquiera de los tres elementos anteriores, aparecerá en la ventana principal del programa el nombre del fichero seleccionado junto al elemento en cuestión, excepto en el caso de la clave pública del receptor, donde si el fichero con la clave incluye el elemento , y su contenido es válido, entonces se mostrará la cadena de texto que contenga . Si el fichero con la clave pública contuviera más de una clave, y alguna de dichas claves no tuviera un nodo válido, a fin de poder identificar dicha clave, el programa calculará su posición en el fichero de claves y mostrará el texto Clave sin identificador #i, 224 5. Implementación de ECIES en entorno PC

Figura 5.32: Selección del ﬁchero con el mensaje en claro

Figura 5.33: Selección del fichero donde se almacenará el criptograma 5.3. Descripción funcional de la aplicación 225 donde i tendrá como valor la posición de la clave. Por último, si el fichero contuviera solamente una clave, y el elemento no fuera válido o no estuviera presente, el programa utilizará como identificador el nombre del fichero. La Figura 5.34 muestra las diversas variantes existentes en la representación del identificador de la clave pública.

Figura 5.34: Modalidades de identiﬁcación de la clave pública

La segunda sección de la pestaña Cifrado está compuesta por las siguientes cajas de texto:

∙ Mensaje a cifrar: contenido del mensaje en claro a cifrar (o sus primeros 1024 bytes en caso de que el mensaje se haya obtenido de un ﬁchero y su longitud sea mayor que ese límite).

∙ Etiqueta: elemento de uso opcional a utilizar por la función MAC.

∙ Criptograma: mensaje cifrado empaquetado (constituyendo una tripleta de elementos) obtenido mediante el esquema ECIES (o sus primeros 1024 bytes en caso de que el usuario haya decidido almacenar el criptograma en un ﬁchero y su longitud sea mayor que ese valor).

∙ Resultado: campo con información acerca del resultado de la ejecución.

Las cajas de texto del mensaje en claro y de la etiqueta permiten mostrar su contenido interpretado como texto o en formato hexadecimal. En caso de que el mensaje 226 5. Implementación de ECIES en entorno PC

Figura 5.35: Contenido del mensaje en claro no interpretable como texto a cifrar no sea interpretable como texto ASCII, al seleccionar el formato Texto apa- recerá en una fuente de color rojo la leyenda El contenido no es interpretable como texto, tal como muestra la Figura 5.35. Asimismo, el programa permite visualizar el criptograma en formato hexadecimal y Base64, permitiendo que pueda ser enviado de forma cómoda por correo electrónico utilizando esta última codiﬁcación. La tercera sección de la pestaña Cifrado está formada por los siguientes elementos:

∙ Cifrar: botón que desencadena la generación de un criptograma ECIES a partir del mensaje en claro, la etiqueta y los parámetros asociados.

∙ Borrar: botón que permite borrar el contenido de las cajas de texto de esta pantalla y devolver las opciones de conﬁguración de la primera sección a su estado inicial.

La Figura 5.36 muestra un ejemplo del proceso de cifrado, en el que se ha seleccionado la clave pública del receptor de un fichero que contiene un elemento válido (y que por tanto es el utilizado como identificador de la clave pública), 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 operación. Si la operación efectuada es correcta, los posibles mensajes de éxito que puede mostrar el elemento Resultado son:

Clave pública recuperada correctamente. Proceso finalizado correctamente.

Por el contrario, algunos de los posibles mensajes de error que puede mostrar el elemento Resultado son:

Falta seleccionar la función resumen en Configuración. Falta seleccionar la función KDF en Configuración. Falta seleccionar la función MAC en Configuración. 5.3. Descripción funcional de la aplicación 227

Figura 5.36: Ejemplo de cifrado ECIES

Falta seleccionar la función de cifrado simétrico en Configuración. Falta especificar la longitud de la clave MAC en Configuración. Falta seleccionar la clave pública del receptor del mensaje. El texto en Base64 del criptograma es incorrecto. El punto generador G=(Gx,Gy) no pertenece a la curva. La clave pública del receptor V=(Vx,Vy) no pertenece a la curva. Longitud de la clave AES incorrecta. Los ficheros security policy de Java necesitan ser sustituidos. Error durante el cálculo del código MAC.

5.3.12. Pestaña Descifrado

La pestaña Descifrado muestra todos los elementos necesarios en el proceso de descifrado de un criptograma mediante el esquema ECIES. La ventana está dividida en tres secciones, delimitadas en la Figura 5.37 mediante recuadros de color verde, 228 5. Implementación de ECIES en entorno PC azul y rojo, y que se corresponden con el área de gestión de opciones, las cajas de texto y los botones de operación.

Figura 5.37: Pestaña Descifrado

La primera sección está formada por las siguientes opciones:

∙ Clave privada receptor: clave privada fija del destinatario del criptograma. Si el usuario pulsa la opción Texto, la pestaña Parámetros pasará a ser la pestaña en uso, de manera que el usuario pueda introducir manualmente los datos asociados a su clave privada. En cambio, si el usuario elige la opción Fichero, el programa permitirá seleccionar el fichero donde se encuentra la clave privada, tal como puede comprobarse en la Figura 5.38. Si el procesamiento del fichero con la clave privada es correcto, en la pestaña Parámetros aparecerán los datos obtenidos del fichero con extensión .pri seleccionado. ∙ Criptograma: mensaje cifrado empaquetado (tripleta de elementos) que el emisor ha enviado al receptor. Si el usuario pulsa la opción Texto (opción por defecto), deberá introducir el criptograma manualmente, sin que exista ningún 5.3. Descripción funcional de la aplicación 229

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

∙ Mensaje descifrado: resultado de la operación de descifrado ECIES. Si el usuario pulsa la opción Texto (opción 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 opción Fichero, el programa permitirá al usuario seleccionar un ﬁchero (Figura 5.40) de manera que, además de mostrarse el mensaje en claro en la caja de texto, su contenido será almacenado en el ﬁchero indicado. Únicamente en este último caso, si el tamaño del mensaje descifrado supera el límite de 1 Kbyte, entonces sólo se mostrarán (utilizando de nuevo una fuente de color azul) los primeros 1024 bytes del mensaje. Com- parativamente, la fuente de texto de color negro indica que el contenido del mensaje en claro se encuentra incluido en la caja de texto.

Figura 5.38: Selección del ﬁchero con la clave privada

En caso de elegir la opción Fichero en cualquiera de los tres elementos anteriores, aparecerá en la ventana el nombre del fichero seleccionado junto al elemento en cuestión, excepto en el caso de la clave privada del receptor del criptograma, donde si el fichero con la clave incluye un elemento válido, entonces se mostrará la cadena de texto que contenga . Si el fichero con la clave pública contuviera 230 5. Implementación de ECIES en entorno PC

Figura 5.39: Selección del ﬁchero con el criptograma

Figura 5.40: Selección del fichero donde se almacenará el mensaje en claro 5.3. Descripción funcional de la aplicación 231 más de una clave privada, y alguna de dichas claves no tuviera un campo válido, a fin de poder identificar dicha clave el programa calculará su posición en el fichero de claves y mostrará el texto Clave sin identificador #i, donde i tomará como valor la posición de la clave. Por último, si el fichero contuviera solamente una clave, y el elemento no fuera válido, el programa utilizará como identificador el nombre del fichero. La Figura 5.41 muestra las diversas variantes existentes en la representación del identificador de la clave privada.

Figura 5.41: Modalidades de identiﬁcación de la clave privada

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

∙ Criptograma: contenido del mensaje cifrado empaquetado recibido por el destinatario. ∙ Etiqueta: elemento de uso opcional a utilizar por la función MAC. ∙ Mensaje descifrado: mensaje en claro obtenido tras el proceso de descifrado ECIES. 232 5. Implementación de ECIES en entorno PC

Figura 5.42: Ventana de solicitud del código de acceso

Figura 5.43: Enmascaramiento de la clave privada

∙ Resultado: campo con información acerca del resultado de la ejecución.

Las cajas de texto de la etiqueta y el mensaje descifrado permiten mostrar su contenido interpretado como texto o en formato hexadecimal. En caso de que el mensaje en claro no sea interpretable como texto ASCII, al seleccionar el forma- to Texto aparecerá en una fuente de color rojo la cadena El contenido no es interpretable como texto, tal como muestra la Figura 5.44.

Figura 5.44: Contenido del mensaje descifrado no interpretable como texto

Por otra parte, el programa permite introducir el contenido del criptograma en formato hexadecimal y Base64. La tercera sección de la pestaña Descifrado está formada por los siguientes elementos:

∙ Descifrar: botón que desencadena el proceso de descifrado ECIES a partir del criptograma, la etiqueta y los parámetros asociados. ∙ Borrar: botón que permite borrar el contenido de las cajas de texto de esta pantalla y devolver las opciones de conﬁguración de la primera sección a su estado inicial. 5.3. Descripción funcional de la aplicación 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 válido (y que por tanto es el representado como identificador de la clave privada), el fichero Quijote cifrado.out contiene el criptograma y el fichero Quijote descifrado.txt se uti- lizará para almacenar el mensaje en claro resultante de la operación.

Figura 5.45: Ejemplo de descifrado ECIES

Si la operación efectuada es correcta, los posibles mensajes de éxito que puede mostrar el elemento Resultado son:

Clave privada recuperada correctamente. Proceso finalizado 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 5. Implementación de ECIES en entorno PC

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

5.4. Ejemplos de utilización

5.4.1. Ejemplo de cifrado

El presente ejemplo constituye una muestra de las posibilidades de utilización real del modo sencillo del programa de cifrado ECIES para PC, en el que todos los datos de interés (clave pública del destinatario, mensaje en claro y criptograma) se almacenan en ﬁchero. Tras iniciar la aplicación, los pasos que debe completar el usuario son los siguientes:

1. Seleccionar la pestaña Cifrado en la ventana inicial.

2. Seleccionar la opción Fichero correspondiente al elemento Clave pública receptor.

3. Utilizando las capacidades de navegación de la ventana emergente aparecida, seleccionar el ﬁchero con la clave pública del usuario receptor del mensaje y pulsar sobre el botón Abrir. En este ejemplo, el ﬁchero seleccionado es Fp 521 SHA-256.pub (Figura 5.46). Aparecerá a continuación de nuevo la ventana principal de ECIES con la in- formación asociada al elemento de la clave pública, que en este caso particular es el texto Clave pública Bernardo (Figura 5.47).

4. Seleccionar la opción Fichero correspondiente al elemento Mensaje a cifrar.

5. Utilizando las capacidades de navegación de la ventana emergente aparecida, seleccionar el ﬁchero con el mensaje en claro a cifrar y pulsar sobre el botón Abrir. En este ejemplo, el mensaje a cifrar será el contenido del ﬁchero Quijote - Capítulo I.txt (Figura 5.48). 5.4. Ejemplos de utilización 235

Figura 5.46: Selección del ﬁchero con la clave pública del destinatario

Figura 5.47: Identiﬁcador de la clave pública del destinatario

Figura 5.48: Selección del ﬁchero con el mensaje en claro 236 5. Implementación de ECIES en entorno PC

Aparecerá a continuación de nuevo la ventana principal de ECIES con los primeros 1024 bytes del ﬁchero 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: Identiﬁcador del ﬁchero con el mensaje en claro

6. Seleccionar la opción Fichero correspondiente al elemento Criptograma.

7. Utilizando las capacidades de navegación de la ventana emergente aparecida, seleccionar de entre los existentes el fichero donde se almacenará el criptograma (o alternativamente introducir un nombre para la creación de un nuevo fichero para tal fin) y pulsar sobre el botón Guardar. En este ejemplo, el fichero que albergará el criptograma es Quijote cifrado.out (Figura 5.50). Aparecerá a continuación de nuevo la ventana principal de ECIES con el nombre del fichero (Figura 5.51).

8. Añadir (opcionalmente) una etiqueta, la cual será utilizada en el cálculo del código MAC. En el ejemplo, el texto de la etiqueta es Prueba de cifrado (Figura 5.52).

9. Pulsar el botón Cifrar. Si la operación de cifrado ha concluido 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 ﬁchero Quijote cifrado.out. 5.4. Ejemplos de utilización 237

Figura 5.50: Selección del ﬁchero para el criptograma

Figura 5.51: Identiﬁcador del ﬁchero para el criptograma

Figura 5.52: Contenido de la caja de texto de la etiqueta 238 5. Implementación de ECIES en entorno PC

Figura 5.53: Ventana con el resultado del proceso de cifrado

5.4.2. Ejemplo de descifrado

El siguiente ejemplo muestra los pasos necesarios para descifrar un criptograma, donde todos los datos de interés (clave privada del destinatario, criptograma y mensaje en claro resultante) se almacenan en forma de ﬁchero. Tras iniciar la aplicación, los pasos que debe completar el usuario son los siguientes:

1. Seleccionar la pestaña Descifrado en la ventana inicial.

2. Seleccionar la opción Fichero correspondiente al elemento Clave privada receptor.

3. Utilizando las capacidades de navegación de la ventana emergente aparecida, seleccionar el ﬁchero con la clave privada del usuario receptor del mensaje y pulsar sobre el botón Abrir. En este ejemplo, el ﬁchero seleccionado es Fp 521 SHA-256.pri (Figura 5.54). 5.4. Ejemplos de utilización 239

Figura 5.54: Selección del ﬁchero con la clave privada del destinatario

Aparecerá a continuación la ventana de introducción del código de acceso (Figura 5.55), el cual permitirá la utilización de la clave privada por parte del usuario.

Figura 5.55: Introducción de la contraseña para el acceso a la clave privada

Si el código introducido es el correcto, tras pulsar el botón Procesar aparecerá de nuevo la ventana principal de ECIES con la información asociada al elemento de la clave pública, que en este caso particular es el texto Clave privada Bernardo (Figura 5.56). 4. Seleccionar la opción Fichero correspondiente al elemento Criptograma. 5. Utilizando las capacidades de navegación de la ventana emergente aparecida, seleccionar el fichero con el criptograma y pulsar sobre el botón Abrir. En este ejemplo, el mensaje a cifrar será el contenido del fichero Quijote cifrado.out (Figura 5.57). Aparecerá a continuación de nuevo la ventana principal de ECIES con los primeros 1024 bytes del fichero en formato Base64 y en color azul, indicando 240 5. Implementación de ECIES en entorno PC

Figura 5.56: Identiﬁcador de la clave privada del destinatario

Figura 5.57: Selección del ﬁchero con el criptograma

que el mensaje no se muestra completo en la caja de texto (Figura 5.58). 6. Seleccionar la opción Fichero correspondiente al elemento Mensaje descifrado. 7. Utilizando las capacidades de navegación de la ventana emergente aparecida, seleccionar de entre los existentes el fichero donde se almacenará el mensaje descifrado (o alternativamente introducir un nombre para la creación de un nuevo fichero para tal fin) y pulsar sobre el botón Guardar. En este ejemplo, el fichero donde que albergará el criptograma es Quijote descifrado.txt (Figura 5.59). Aparecerá a continuación de nuevo la ventana principal de ECIES con el nombre del fichero (Figura 5.60). 8. Añadir una etiqueta (en caso de que se utilizara durante el proceso de cifrado), la cual será utilizada en el cálculo del código MAC. En el ejemplo, el texto de la etiqueta es Prueba de cifrado (Figura 5.61). 9. Pulsar el botón Descifrar en la ventana principal. Si la operación de descifrado ha concluido satisfactoriamente, aparecerá el texto Proceso finalizado 5.4. Ejemplos de utilización 241

Figura 5.58: Identiﬁcador del ﬁchero con criptograma

Figura 5.59: Selección del ﬁchero para el mensaje descifrado

Figura 5.60: Identiﬁcador del ﬁchero para el mensaje descifrado 242 5. Implementación de ECIES en entorno PC

Figura 5.61: Contenido de la caja de texto de la etiqueta

correctamente junto al elemento Resultado, y la caja de texto del elemen- to Mensaje descifrado mostrará los primero 1024 bytes del mensaje original en color azul (Figura 5.62), indicando que el mensaje descifrado completo se encuentra almacenado en el ﬁchero Quijote descifrado.txt.

Figura 5.62: Ventana con el resultado del proceso de descifrado Capítulo 6

Implementación de ECIES en Java Card

Resumen del capítulo

En este capítulo se presenta una implementación del esquema de cifrado ECIES para tarjetas Java Card, indicando las particularidades existentes en función de la versión Java Card implementada por las tarjetas inteligentes utilizadas en esta Tesis. De manera adicional, este capítu- lo incluye la descripción funcional de la aplicación desarrollada para la comunicación con las tarjetas inteligentes comerciales empleadas en la Tesis.

6.1. Elementos criptográﬁcos de ECIES disponibles en Java Card

Tal como se indicó en el Capítulo 4, debido al carácter híbrido del esquema de cifrado ECIES, su implementación requiere de elementos de diversa naturaleza criptográfica. El grado de soporte de dichos elementos es muy variable dependiendo de la versión Java Card que incluyan las tarjetas, por lo que a fin de identificar qué funcionalidades y opciones es posible implementar, los siguientes apartados ofrecen un resumen de los elementos relacionados con ECIES presentes en cada versión de la plataforma Java Card.

243 244 6. Implementación de ECIES en Java Card

6.1.1. Java Card 2.1

La única característica criptográﬁca relacionada con ECIES incluida en la versión Java Card 2.1 es la función resumen SHA-1.

6.1.2. Java Card 2.1.1

En la revisión Java Card 2.1.1 no se introdujo ninguna novedad respecto a las funciones requeridas por ECIES, por lo que el único algoritmo disponible relacionado con esquema de cifrado seguía siendo la función resumen SHA-1.

6.1.3. Java Card 2.2

Java Card 2.2 fue la primera versión en incluir soporte para ECC, que junto con el resto de las novedades conforman la siguiente lista de características criptográﬁcas relacionadas con ECIES:

∙ Función HASH : SHA-1.

∙ Función KA: DH y DHC, aunque con la particularidad de que el resultado obtenido consiste en la salida de la primera coordenada del elemento secreto compartido tras pasar por la función SHA-1.

∙ Función ENC : AES con bloques de 128 bits utilizando los modos CBC y ECB, en ambos casos sin relleno, y longitudes de claves 128, 192 y 256 bits.

∙ Claves ECC: soporte para claves de 113, 131, 163 y 193 bits en cuerpos binarios y claves de 112, 128, 160 y 192 bits en cuerpos primos.

6.1.4. Java Card 2.2.1

La revisión Java Card 2.2.1 no introdujo ninguna novedad en lo relativo a los elementos necesarios para implementar ECIES, por lo que la lista de elementos es idéntica a la mostrada en el apartado anterior.

6.1.5. Java Card 2.2.2

La principal novedad de Java Card 2.2.2 fue la introducción de los algoritmos HMAC y de la familia de funciones resumen SHA-2. La lista detallada de capacidades criptográﬁcas directamente relacionadas con la implementación de ECIES es la siguiente: 6.1. Elementos criptográﬁcos de ECIES disponibles en Java Card 245

∙ Función HASH : SHA-1, SHA-256, SHA-384, SHA-512.

∙ Función KA: DH y DHC en curvas elípticas, manteniendo la particularidad reseñada en los apartados anteriores.

∙ Función ENC : AES con bloques de 128 bits utilizando los modos CBC y ECB, en ambos casos sin relleno, y longitudes de claves 128, 192 y 256 bits.

∙ Función MAC : HMAC-SHA-1, HMAC-SHA-256, HMAC-SHA-384 y HMAC- SHA-512.

∙ 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.6. Java Card 3.0

Por último, la versión Java Card 3.0.1 ha extendido el número de modos de funcionamiento del algoritmo AES y de las longitudes de clave disponibles para los cuerpos primos, añadiendo a la familia de funciones resumen el algoritmo SHA- 224. La lista completa de funcionalidades relacionadas con ECIES presente en esta versión es la siguiente:

∙ Función HASH : disponibilidad de las funciones SHA-1, SHA-224, SHA-256, SHA-384 y SHA-512.

∙ Función KA: DH y DHC en curvas elípticas, con la novedad de que a partir de esta versión es posible decidir si el valor obtenido es la primera coordenada del elemento secreto compartido o su salida al pasar por la función SHA-1.

∙ Función ENC : AES con bloques de 128, 192 y 256 bits utilizando los modos CBC y ECB sin relleno. Además se ofrecen los modo CBC y ECB con relleno compatible con el documento PKCS#5 [234] y el modo ECB compatible con los métodos 1 y 2 de la norma ISO 9797 [128], en ambos casos con bloques de 128 bits. En todos los casos mencionados, las longitudes de clave admisibles son 128, 192 y 256 bits.

∙ Función MAC : HMAC-SHA-1, HMAC-SHA-256, HMAC-SHA-384 y HMAC- SHA-512. La función HMAC-SHA-224, aunque por coherencia debería haber estado incluida, no forma parte de la especiﬁcación Java Card 3.0.

∙ Claves ECC: soporte para claves de 113, 131, 163 y 193 bits en cuerpos binarios y claves de 112, 128, 160, 192, 224, 256 y 384 bits en cuerpos primos. 246 6. Implementación de ECIES en Java Card

6.2. Resumen de funcionalidad ECC en Java Card

El Cuadro 6.1 recoge de forma resumida la información presentada en los anteriores apartados, donde DH y DHC son las funciones de acuerdo de clave Diﬃe-Hellman con y sin cofactor, mientras que DH∗ y DHC∗ representan las mismas funciones con la particularidad de que la salida de la función es el resumen de la primera coordenada del elemento secreto compartido proporcionado por las funciones DH y DHC.

JC 2.2 JC 2.2.1 JC 2.2.2 JC 3.0 SHA-1 SHA-1 SHA-1 SHA-1 SHA-256 SHA-224 HASH SHA-384 SHA-256 SHA-512 SHA-384 SHA-512 DH∗ DH∗ DH∗ DH∗ DHC∗ DHC∗ DHC∗ DHC∗ KA DH DHC DES DES DES DES TDES TDES TDES TDES ENC AES-128 AES-128 AES-128 AES-128 AES-192 AES-256 HMAC-SHA-1 HMAC-SHA-1 HMAC-SHA-256 HMAC-SHA-256 MAC HMAC-SHA-384 HMAC-SHA-384 HMAC-SHA-512 HMAC-SHA-512 112,128,160,192 112,128,160,192 112,128,160,192 112,128,160,192, Fp 224,256,384 F2m 113,131,163,193 113,131,163,193 113,131,163,193 113,131,163,193 Cuadro 6.1: Funcionalidades ECC en Java Card

6.3. Entorno de desarrollo

Durante las diferentes fases de investigación de la presente Tesis Doctoral se han utilizado tres entornos de desarrollo para tarjetas Java Card, tal como se describe en los siguientes apartados. 6.3. Entorno de desarrollo 247

6.3.1. NetBeans

Aunque en un primer momento se decidió utilizar la herramienta de desarrollo NetBeans en su versión 6.7, por ser la primera con soporte de la tecnología Java Card, esta opción fue descartada tras realizar las primeras pruebas y comprobar la correcta estructura de la aplicación diseñada, ya que NetBeans sólo permite compilar applets empleando las bibliotecas Java Card 3.0, lo que impide su descarga en tarjetas reales por tratarse de una versión muy reciente para la que los fabricantes de tarjetas inteligentes todavía no tienen productos comerciales.

6.3.2. Herramientas de línea de comandos de Sun

La segunda opción para el desarrollo de applets Java Card fue utilizar directamente los ejecutables mediante línea de comandos proporcionados por Sun. Para ello, fue necesario conﬁgurar el PC de trabajo de la siguiente manera:

1. Instalación de JDK 1.5 en la carpeta «C:\Java\jdk1.5.0_21».

2. Conﬁguración de la variable del sistema JAVA_HOME con la localización del directorio «C:\Java\jdk1.5.0_21».

3. Instalación del paquete Java Card 2.2.2 en «C:\java_card_kit-2_2_2».

4. Conﬁguración de la variable del sistema JC_HOME con el valor de la carpeta «C:\java_card_kit-2_2_2».

5. Instalación de la versión 1.6.2 del software Ant en «C:\apache-ant-1.6.2».

6. Conﬁguración de la variable del sistema ANT_HOME con el valor del directorio «C:\apache-ant-1.6.2».

7. Modiﬁcación de la variable PATH del sistema para que incluya la cadena « %JAVA_HOME%\bin; %JC_HOME %\bin; %ANT_HOME %\bin».

La generación del applet se efectúa en dos pasos: en el primero, se realiza la compilación del fichero con extensión .java, generando un fichero .class; en el segundo paso, se obtiene el fichero con extensión .cap que será posteriormente descargado en la tarjeta (para más información sobre el proceso de compilación de los applets en Java Card, ver §3.5). Para realizar la compilación del fichero JCECIES.java, es necesario seguir los siguientes pasos:

1. Guardar el ﬁchero JCECIES.java en «C:\JCECIES\src\victor\tesis\». 248 6. Implementación de ECIES en Java Card

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 ﬁn de generar el ﬁchero con extensión .cap asociado al applet, es necesario seguir las siguientes indicaciones:

1. Acceder al directorio «C:\JCECIES\src».

2. Crear un ﬁchero 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 ﬁcheros tesis.cap, tesis.exp y tesis.jca, que serán utilizados para descargar el applet en tarjetas reales o virtuales (ver §6.5).

6.3.3. Eclipse

Tras recibir las tarjetas JCOP 41 y JCOP J3A utilizadas en la Tesis (ver §6.6y §7.1), el entorno de desarrollo seleccionado para completar el desarrollo de los applets fue Eclipse 3.2, puesto que primero IBM y más tarde NXP han desarrollado sucesivas versiones de los complementos (plug-ins) para Eclipse que permiten programar y descargar applets de manera sencilla en tarjetas de prueba JCOP. La Figura 6.1 muestra la ventana principal de la aplicación Eclipse 3.2 con los complementos de NXP instalados.

6.4. Esquema de la aplicación

Antes de iniciar la fase de trabajo con tarjetas reales, en previsión de que no fuera posible conseguir tarjetas que implementaran curvas deﬁnidas tanto sobre cuerpos primos como binarios, se diseñaron dos versiones de la aplicación Java Card cuya 6.4. Esquema de la aplicación 249

Figura 6.1: Ventana principal del entorno de desarrollo Eclipse

única diferencia fuera precisamente el tipo de curvas empleadas. Estas dos versiones fueron desarrolladas y depuradas utilizando las herramientas de consola descritas en §6.3.2, de manera independiente respecto al modelo de tarjetas sobre el que se descargaran los applets. El Listado 6.1 muestra el esquema general de la aplicación Java Card diseñada para curvas elípticas deﬁnidas sobre cuerpos binarios. En el caso de curvas elípticas sobre cuerpos primos la aplicación es equivalente, representando los valores 01, 02, 03 y 04 del parámetro P1 en ese caso las curvas de 112, 128, 160 y 192 bits de longitud.

1 package victor.tesis; 2 3 import javacard .framework. ∗ ; 4 import javacard.security . ∗ ; 5 import javacardx.crypto . ∗ ; 6 7 public class JCECIESF2m extends Applet 8 { 9 // Declaración de variables 10 11 public static void i n s t a l l ( byte [ ] bArray , short bOffset , byte bLength ) 12 { 13 new JCECIESF2m( ) ; 14 } 15 protected JCECIESF2m( ) 250 6. Implementación de ECIES en Java Card

16 { 17 // Inicialización de variables y objetos 18 } 19 20 public boolean s e l e c t ( ) 21 { 22 return true ; 23 } 24 25 public void process(APDU apdu) 26 { 27 // Procesamiento de las APDU recibidas para su gestión 28 29 byte [] buffer = apdu.getBuffer(); 30 31 i f (selectingApplet()) 32 { 33 return ; 34 } 35 36 switch ( b u f f e r [ ISO7816 .OFFSET_INS ] ) 37 { 38 case 0x61 : 39 processINS61(apdu) ; 40 break ; 41 case 0x62 : 42 processINS62(apdu) ; 43 break ; 44 case 0x63 : 45 processINS63(apdu) ; 46 break ; 47 case 0x64 : 48 processINS64(apdu) ; 49 break ; 50 case 0x65 : 51 processINS65(apdu) ; 52 break ; 53 case 0x66 : 54 processINS66(apdu) ; 55 break ; 56 case 0x67 : 57 processINS67(apdu) ; 58 break ; 59 case 0x68 : 60 processINS68(apdu) ; 61 break ; 62 case 0x69 : 63 processINS69(apdu) ; 64 break ; 65 } 66 } 67 private void processINS61(APDU apdu) 6.4. Esquema de la aplicación 251

68 { 69 // Crea nuevas claves de longitud 113, 131, 163 y 193 70 // INS : 61 71 // P1: tipo de clave (01=113, 02=131, 03=163, 04=193) 72 // P2: 00 (sin uso en esta instrucción) 73 // Lc: 00 (sin datos de entrada) 74 // Ejemplo: 0061010000 75 76 } 77 78 private void processINS62(APDU apdu) 79 { 80 // Obtiene los parámetros de las claves 81 // INS : 62 82 // P1: tipo de clave (01=113, 02=131, 03=163, 04=193) 83 // P2: tipo de dato (01: a, 02: b, 03: f(x), 04: G, 05: h, 06: n, 07: tamaño del cuerpo GF(q) en bits, 08: U, 09: u) 84 // Lc: 00 (sin datos de entrada) 85 // Ejemplo: 0062010900 86 87 } 88 89 private void processINS63(APDU apdu) 90 { 91 // Almacena valores en los objetos de las claves 92 // INS : 63 93 // P1: tipo de clave (01=113, 02=131, 03=163, 04=193) 94 // P2: tipo de dato (01: a, 02: b, 03: f(x), 04: G, 05: h, 06: n, 07: tamaño del cuerpo GF(q) en bits, 08: U, 09: u) 95 // Lc: longitud en bytes del dato incluido a continuación 96 // Ejemplo: 006301081F0401A4CD29... 97 } 98 99 private void processINS64(APDU apdu) 100 { 101 // Almacena el valor de la clave pública del destinatario 102 // INS : 64 103 // P1: tipo de clave (01=113, 02=131, 03=163, 04=193) 104 // P2: tipo de dato (00: crea clave aleatoria, 01: a, 02: b, 03: f(x), 04: G, 05: h, 06: n, 07: tamaño del cuerpo GF(q) en bits, 08: U, 09: u) 105 // Lc: longitud en bytes del dato incluido a continuación 106 // Ejemplo: 006401081F0401A4CD29... 107 } 108 109 private void processINS65(APDU apdu) 110 { 111 // Almacena el mensaje a cifrar 112 // INS : 65 113 // P1: tipo de operación (01: mensaje nuevo, 02: anexar a mensaje almacenado) 114 // P2: 00 (sin uso en esta instrucción) 252 6. Implementación de ECIES en Java Card

115 // Lc: longitud en bytes de la porción de mensaje incluido a continuación 116 // Ejemplo: 00650100080102030405060708 117 } 118 119 private void processINS66(APDU apdu) 120 { 121 // Almacena la etiqueta 122 // INS : 66 123 // P1: sin uso en esta instrucción 124 // P2: 00 (sin uso en esta instrucción) 125 // Lc: longitud en bytes de la etiqueta incluida a continuación 126 // Ejemplo: 006600000454657374 127 } 128 129 private void processINS67(APDU apdu) 130 { 131 // Solicita la generación del criptograma 132 // INS : 67 133 // P1: tipo de clave (01=113, 02=131, 03=163, 04=193) 134 // P2: 00 (sin uso en esta instrucción) 135 // Lc: 00 (sin datos de entrada) 136 // Ejemplo: 0067010000 137 } 138 139 private void processINS68(APDU apdu) 140 { 141 // Almacena el criptograma a descifrar 142 // INS : 68 143 // P1: tipo de operación (01: criptograma nuevo, 02: anexar a criptograma almacenado) 144 // P2: 00 (sin uso en esta instrucción) 145 // Lc: longitud en bytes de la porción de criptograma incluido a continuación 146 // Ejemplo: 006801003B040182D553... 147 148 } 149 150 private void processINS69(APDU apdu) 151 { 152 // Almacena el descifrado del criptograma 153 // INS : 69 154 // P1: tipo de clave (01=113, 02=131, 03=163, 04=193) 155 // P2: 00 (sin uso en esta instrucción) 156 // Lc: 00 (sin datos de entrada) 157 // Ejemplo: 0069010000 158 } 159 160 }

Listado 6.1: Esquema de la aplicación Java Card para curvas F2m 6.5. Pruebas con tarjetas virtuales 253

6.5. Pruebas con tarjetas virtuales

Las herramientas de desarrollo para Java Card de Sun incluyen el fichero ejecutable cref.exe, que es una implementación en el lenguaje de programación C del JCRE. Utilizando este programa junto con apdutool.exe, es posible simular el comportamiento de una tarjeta Java Card, cargar aplicaciones y enviarles comandos para realizar pruebas básicas mediante ficheros de instrucciones (scripts). La implementación que hace el programa cref.exe de la plataforma Java Card no es completa, y además varía en cada edición de Java Card. Mientras que el soporte de las capacidades criptográficas en la versión de cref.exe que se incluye con el paquete de desarrollo para Java Card 2.2.2 es bastante completo, la versión para Java Card 3.0 proporcionada por Sun hasta el momento no implementa ninguna funcionalidad criptográfica. A título informativo, a continuación se detallan las características criptográficas implementadas en la versión de cref.exe para Java Card 2.2.2:

∙ Función HASH : ejecuta correctamente las funciones ALG_SHA y ALG_SHA_256. Las otras dos variantes, ALG_SHA_384 y ALG_SHA_512, producen una excepción de tipo CardRuntime.

∙ Función ENC : el modo ALG_AES_BLOCK_128_CBC_NOPAD se ejecuta correctamente, pero el modo ALG_AES_BLOCK_128_ECB_NOPAD, aunque no produce errores en la compilación, genera una excepción CardRuntime.

∙ Función MAC : no soporta ninguno de los métodos HMAC deﬁnidos en las API de Java Card (ALG_HMAC_SHA1, ALG_HMAC_SHA_256, ALG_HMAC_SHA_384 y ALG_HMAC_SHA_512).

A continuación se muestran los pasos necesarios para generar un ﬁchero de instrucciones con los datos necesarios para cargar e instalar la aplicación en una tarjeta virtual, donde como se puede observar es necesario añadir el elemento 0x7F al ﬁnal 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 ﬁchero JCECIES.scr en el directorio «C:\JCECIES\src».

3. Editar el ﬁchero JCECIES.scr, añadiéndole las siguientes líneas al principio del ﬁchero: 254 6. Implementación de ECIES en Java Card

powerup;

// Selección del applet instalador con AID A00000006203010801 // CLA: 0x00, INS: 0xA4, P1: 0x04, P2: 0x00, Lc: 0x09 // Datos: 0xA0 0x00 0x00 0x00 0x62 0x03 0x01 0x08 0x01

0x00 0xA4 0x04 0x00 0x09 0xA0 0x00 0x00 0x00 0x62 0x03 0x01 \\ 0x08 0x01 0x7F; 4. Continuar la edición del ﬁchero, añadiéndole las siguientes líneas al ﬁnal: // Creación del applet JCECIES con AID A00000006203010C0101 // CLA: 0x80, INS: 0xB8, P1: 0x00, P2: 0x00, Lc: 0x0B // Datos: 0x0A 0xA0 0x00 0x00 0x00 0x62 0x03 0x01 0x0C 0x01 0x01

0x80 0xB8 0x00 0x00 0x0B 0x0A 0xA0 0x00 0x00 0x00 0x62 0x03 \\ 0x01 0x0C 0x01 0x01 0x7F;

powerdown;

Si en el mismo ﬁchero de instrucciones se desean incluir los comandos APDU necesarios para probar la aplicación, éstos deberán ser incluidos inmediatamente antes de la orden powerdown. Las siguientes líneas muestran un ejemplo de APDU de prueba:

// Selección del applet JCECIES con AID A00000006203010C0101 // CLA: 0x00, INS: 0xA4, P1: 0x04, P2: 0x00, Lc: 0x0A // Datos: 0xA0 0x00 0x00 0x62 0x03 0x01 0x0C 0x01 0x01

0x00 0xA4 0x04 0x00 0x0A 0xA0 0x00 0x00 0x00 0x62 0x03 0x01 \\ 0x0C 0x01 0x01 0x7F;

// Comando INS 10 // CLA: 0x80, INS: 0x10, P1: 0x00, P2: 0x00, Lc: 0x01 // Datos: 0x11

0x80 0x10 0x00 0x00 0x01 0x11 0x7F;

// Comando INS 20 // CLA: 0x80, INS: 0x20, P1: 0x00, P2: 0x00, Lc: 0x01 // Datos: 0x22

0x80 0x20 0x00 0x00 0x01 0x22 0x7F; 6.6. Pruebas con tarjetas reales 255

// Comando INS 30 // CLA: 0x80, INS: 0x30, P1: 0x00, P2: 0x00, Lc: 0x01 // Datos: 0x33

0x80 0x30 0x00 0x00 0x01 0x33 0x7F;

Por último, para ejecutar un ﬁchero 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 ﬁchero de instrucciones JCECIES.scr y ejecutar el comando apdutool.exe -o APDU.txt JCECIES.scr

Mediante el último comando, el resultado de la ejecución de las instrucciones se almacenará en el ﬁchero APDU.txt.

6.6. Pruebas con tarjetas reales

En el momento de iniciar la elaboración de esta Tesis, los fabricantes Gemalto, Oberthur y G&D no disponían de productos comerciales con soporte para cripto- grafía de curva elíptica. Afortunadamente, sí estaban disponibles para su compra en internet [262] tarjetas JCOP (Java Card Open Platform), fabricadas inicialmente por IBM y posteriormente por NXP [268]. Existe en el mercado una amplia gama de tarjetas JCOP (JCOP 20, 30, 40, 31, 41, etc.) con diferentes características. De entre todas ellas, el modelo seleccionado finalmente fue JCOP 41, ya que estaban disponibles para su compra en diversas tiendas online y además implementaban funciones de ECC. Tras la recepción de las tarjetas JCOP 41, y la confirmación de que estas tarjetas únicamente implementaban curvas sobre cuerpos binarios, el autor de esta Tesis se puso en contacto con la empresa NXP a fin de solicitar el último modelo de tarjetas JCOP disponibles. Gracias a las gestiones realizadas por Juan Moreno y la generosidad de NXP, fue posible hacer pruebas con tarjetas del modelo JCOP J3A, que además de implementar curvas elípticas sobre cuerpos primos incluyen algunas de las funciones criptográficas añadidas recientemente al estándar Java Card (AES, SHA-256, etc.). Debido a las peculiaridades de las tarjetas JCOP, con el objetivo de realizar un mayor número de pruebas y comparaciones se decidió desarrollar tres versiones del 256 6. Implementación de ECIES en Java Card 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 instalación de los applets en las tarjetas JCOP se realizó mediante el entorno de desarrollo Eclipse 3.2 junto con los complementos JCOP Tools 3.2.8 y SmartMX Target-Pack for JCOP Tools 1.2.9 proporcionados por NXP, que permiten realizar la descarga de la aplicación desde el entorno Eclipse utilizando las claves que por defecto incluyen todas las tarjetas JCOP de desarrollo. En cuanto al tamaño de los applets, tal como puede apreciarse en la Figura 6.2 (compuesta por imágenes obtenidas del entorno de desarrollo Eclipse), la versión JCOP-M2 (AID A00000000501) ocupa 5031 bytes, el tamaño de la versión JCOP- P2 (AID A00000000601) es 4328 bytes, y por último la versión JCOP-P3 (AID A00000000701) ocupa 4404 bytes. Dichas cantidades no incluyen ni las variables que se alojarán en RAM (de tipo transient en Java Card) ni las que residirán en memoria EEPROM (de tipo persistent), aunque sí incluye las matrices formadas por elementos constantes (es decir, las matrices de tipo final static). La versión JCOP-M2 tiene un tamaño superior a las otras dos puesto que las tarjetas JCOP 41 implementan 4 tipos de curvas, mientras que las tarjetas JCOP J3A permiten utilizar únicamente 3 curvas, por lo que la gestión de las curvas es más compleja en la versión JCOP-M2. Por otra parte, el tamaño de la versión JCOP-P3 es ligeramente superior al de la versión JCOP-P2 debido a que las funciones MAC y HMAC (SHA-256 y HMAC- SHA-256) utilizadas en dicha versión generan unos datos de salida de mayor longitud que las funciones correspondientes de la versión JCOP-P2 (SHA-1 y HMAC-SHA-1), siendo necesario aumentar el tamaño de los arrays con los que se trabaja de forma interna. Una vez realizada la descarga de la aplicación en las tarjetas JCOP mediante el entorno Eclipse y los complementos de NXP, las pruebas de comunicación con el applet Java se han realizado utilizando dos aplicaciones diferentes: el propio entorno Eclipse, utilizado principalmente para depurar los diferentes applets mediante la realización de pruebas individuales, y una aplicación Java SE con interfaz gráfica, desarrollada por el autor de esta Tesis y presentada en detalle en §6.7.

6.7. Aplicación JCOPECIES

Tras comprobar la correcta implementación y depuración de los applets Java Card en las tarjetas JCOP 41 y J3A efectuada mediante el entorno Eclipse, con el objetivo de realizar las pruebas descritas en el Capítulo 7 y facilitar a los posibles 6.7. Aplicación JCOPECIES 257

Figura 6.2: Tamaño de los aplets JCOP-M2, JCOP-P2 y JCOP-P3 usuarios la utilización del esquema de cifrado en tarjetas inteligentes, se decidió desarrollar una aplicación Java SE para PC que realizase las operaciones de cifrado y descifrado. Esta aplicación, denominada de forma abreviada JCOPECIES, presenta cuatro pantallas a las que se puede acceder mediante la pestaña apropiada, tal y como se describe a continuación: 258 6. Implementación de ECIES en Java Card

∙ Pestaña Conﬁguración (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 pestaña permite generar nuevos pares de claves para una tarjeta y curva dada, así como recuperar el valor de la clave pública seleccionada, mostrando la Figura 6.6 el resultado ﬁnal 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 aplicación (cifrado, descifrado, generación de pares de claves y recuperación de la clave pública).

Figura 6.3: Pestaña Conﬁguración

∙ Pestaña Cifrado (Figura 6.7): permite añadir la curva pública del destinatario del criptograma, el mensaje en claro a cifrar y la etiqueta a utilizar de manera opcional por la función MAC. El resultado del proceso de cifrado se muestra en la caja de texto asociada al criptograma.

∙ Pestaña Descifrado (Figura 6.8): permite incluir el criptograma a descifrar y la etiqueta opcional para la función MAC, mostrando el mensaje original en su caja de texto. 6.7. Aplicación JCOPECIES 259

Figura 6.4: Lectores de tarjetas disponibles

Figura 6.5: Curvas implementadas en JCOP 41 y JCOP J3A

∙ Pestaña Acerca (Figura 6.9): muestra información sobre la versión del programa JCOPECIES y sus autores.

Como parte de las distintas funciones implementadas, la aplicación muestra de forma gráﬁca los errores debidos a las siguientes causas (Figura 6.10):

∙ Falta de selección de un lector de tarjetas. ∙ Selección de un lector donde no se ha introducido ninguna tarjeta. ∙ Falta de selección de la curva de trabajo. ∙ Utilización de una tarjeta que no tiene instalado el applet adecuado para los modelos JCOP 41 y JCOP J3A.

Respecto a la longitud del mensaje a cifrar, se ha implementado una variante del esquema de padding o relleno PKCS#5 [234] que tiene las siguientes características:

Figura 6.6: Generación y recuperación de una clave pública de 192 bits 260 6. Implementación de ECIES en Java Card

Figura 6.7: Pestaña Cifrado

∙ Al mensaje original se le añaden tantos bytes como sea necesario hasta que la longitud en bytes del mensaje así modiﬁcado sea múltiplo de 8 (en las tarjetas JCOP 41, ya que implementa el algoritmo TDES) o múltiplo de 16 (en las tarjetas JCOP J3A, puesto que el applet para esas tarjetas utiliza AES).

∙ El contenido de cada uno de los bytes adicionales es la codiﬁcación en formato hexadecimal del número de bytes que es necesario añadir.

∙ A diferencia del esquema de relleno PKCS#5 habitual, si la longitud en bytes del mensaje original en bytes ya es múltiplo de 8 (JCOP 41) o de 16 (JCOP J3A), no se añade ningún byte adicional.

El motivo de incluir esa modiﬁcación al esquema PKCS#5 se debe a las limitaciones en la longitud del mensaje original que impone la implementación en Java Card, y que por diseño del applet utiliza una única APDU tanto para transmitir el mensaje original a la tarjeta como para recuperar el criptograma. Proporcional- mente, en el ámbito de la centena de bytes, la pérdida de 8 ó 16 bytes (según la tarjeta) para relleno es elevada, por lo que en esta implementación se ha suprimido la necesidad de añadir un nuevo bloque en tales casos. 6.8. Ejemplos de utilización 261

Figura 6.8: Pestaña Descifrado

Debido a ello, existiría un caso en el que podría producirse pérdida de informa- ción al descifrar un mensaje, en concreto cuando la longitud del mensaje original es múltiplo de 8 (JCOP 41) o 16 (JCOP J3A), y el valor de los últimos n bytes es precisamente la codiﬁcación hexadecimal del número n (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 situación, y en caso de que sea así muestra por pantalla el mensaje Proceso cancelado: el contenido del mensaje provocaría pérdida de información.

6.8. Ejemplos de utilización

En los siguientes apartados se muestran dos ejemplos completos de los procesos de cifrado y descifrado, incluyendo una descripción detallada de los pasos necesarios para realizar las operaciones descritas. Las imágenes que componen las ﬁguras están tomadas de los complementos para tarjetas JCOP proporcionado por NXP para el entorno de desarrollo Eclipse y de la aplicación JCOPECIES. 262 6. Implementación de ECIES en Java Card

Figura 6.9: Pestaña Acerca

Figura 6.10: Errores asociados al lector, la curva o la tarjeta 6.8. Ejemplos de utilización 263

Tal como se puede apreciar en todas las ﬁguras incluidas en el resto del presente capítulo, el primer comando en todos los casos es el de selección del applet. Esta selección no es necesaria para el correcto funcionamiento de la aplicación, pero se ha incluido a ﬁn de demostrar que no es necesario completar la secuencia de todos los comandos en una única sesión.

6.8.1. Cifrado y descifrado en tarjetas JCOP 41 y el 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 aplicación Java Card de cifrado y descifrado. Aunque en la instalación del applet se genera un par de claves para cada longitud permitida por el fabricante, como medida de precaución los usuarios pueden solicitar a la tarjeta la generación de nuevos pares de claves en cualquier momento, por ejemplo cuando reciban sus tarjetas. En el caso del producto JCOP 41, las longitudes disponibles para curvas deﬁnidas sobre cuerpos F2m son 113, 131, 163 y 193 bits. La Figura 6.11 muestra los comandos que tanto el usuario U como V necesitarían enviar para la generación de dichas claves, y que son:

∙ Selección del applet: A00000000501.

∙ Generación de un par de claves de 113 bits: 0061010000.

∙ Generación de un par de claves de 131 bits: 0061020000.

∙ Generación de un par de claves de 163 bits: 0061030000.

∙ Generación de un par de claves de 193 bits: 0061040000.

La Figura 6.12 muestra todos los parámetros asociados a las claves del usuario U. El último comando enviado permite obtener la clave privada de U, por lo que dicho comando sólo está disponible en la versión de pruebas del applet, siendo eliminada de la versión deﬁnitiva de la aplicación que sería utilizada por usuarios reales. Por su parte, la Figura 6.13 muestra de manera equivalente los parámetros asociados a las claves del usuario V. Tal y como se puede apreciar en las Figuras 6.12y 6.13, todos los parámetros coinciden a excepción de las claves privadas y públicas, ya que las tarjetas JCOP 264 6. Implementación de ECIES en Java Card

Figura 6.11: Generación de nuevas claves en JCOP 41

41 utilizan una única curva para cada una de las longitudes posibles, cambiando en cada generación aleatoria de claves únicamente los valores u y U para un usuario U. Dada la curva y2 + xy = x3 + ax2 + b caracterizada por el conjunto de pará- metros P=(m, f(x), a, b, G, n, ℎ), los comandos empleados en la Figura 6.12 para la obtención de los parámetros de las claves asociadas al usuario U son los presentados a continuación:

∙ Selección del applet: A00000000501.

∙ Parámetro a: 0062040100.

∙ Parámetro b: 0062040200.

∙ Polinomio reductor f(x): 0062040300.

∙ Punto de la curva que actúa como el generador G: 0062040400.

∙ Cofactor ℎ: 0062040500.

∙ Orden del punto G: 0062040600. 6.8. Ejemplos de utilización 265

Figura 6.12: Parámetros de las claves de 193 bits de U en JCOP 41 266 6. Implementación de ECIES en Java Card

Figura 6.13: Parámetros de las claves de 193 bits de V en JCOP 41 6.8. Ejemplos de utilización 267

∙ Tamaño de la clave (longitud en bits del cuerpo binario): 0062040700. ∙ Clave pública U: 0062040800. ∙ Clave privada u: 0062040900.

Tal como puede apreciarse en las Figuras 6.12y 6.13, la respuesta de la tarjeta al comando 0062040500 consiste en un código de error deﬁnido por el propio applet (FF62), lo que indica que, a pesar de estar especiﬁcado el método para obtener el cofactor en Java Card, esta funcionalidad no está implementada en las tarjetas JCOP 41. Una vez obtenidos los parámetros de las propias claves por parte de los usuarios U y V (con el objetivo, por ejemplo, de distribuir su clave pública junto con los parámetros de la curva a otros usuarios), para poder generar un criptograma es necesario enviar a la tarjeta el mensaje a cifrar, la etiqueta a utilizar como parámetro de entrada opcional en el cálculo del código MAC, y la clave pública del receptor del mensaje cifrado. Una vez estos elementos estén almacenados en la memoria de la tarjeta, el usuario U podrá solicitar al applet la generación del criptograma que posteriormente deberá enviar al usuario V. La Figura 6.14 muestra los comandos necesarios, y que se detallan a continuación:

∙ Selección del applet: A00000000501. ∙ Envío de la clave pública V del usuario V:

0064040833040147EF73CAC299773F20AF95E64B01B8EFED22A0AD8 DC53DD300AE2A3607E5D51CF66A82F623A69FD6D876C265128FFF D9FD.

∙ Envío del mensaje en claro a cifrar:

00650100201112131415161718212223242526272831323334353637384142 434445464748.

∙ Envío de la etiqueta para el cálculo del código MAC : 006600000454657374. ∙ Solicitud de generación del criptograma: 0067040000.

El resultado de la operación de cifrado es el criptograma

0401BC9A5BE00DB6F5FDDEA249434FED1665A0749236160C622301736 8B704A497646EBD7D87249647B4F6C900E3978BB887887A40F0FFE036B 8E9364F525E107ED6B3BD6E00D651E689F3F70F813B30AC66FD7BECC 931E850D19FE644F1886656C43E91FAE913, 268 6. Implementación de ECIES en Java Card

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 ﬁn de obtener el mensaje descifrado están incluidos en la Figura 6.15 y listados a continuación:

∙ Selección del applet: A00000000501. ∙ Envío de la etiqueta para el cálculo del código MAC : 006600000454657374. ∙ Envío del criptograma: 00680100670401BC9A5BE00DB6F5FDDEA249434FED1665A07492361 60C6223017368B704A497646EBD7D87249647B4F6C900E3978BB88788 7A40F0FFE036B8E9364F525E107ED6B3BD6E00D651E689F3F70F813 B30AC66FD7BECC931E850D19FE644F1886656C43E91FAE913. ∙ Solicitud de descifrado del criptograma: 0069040000.

A la solicitud de descifrado, la tarjeta responde con la cadena hexadecimal

1112131415161718212223242526272831323334353637384142434445464748, la cual coincide con el contenido del mensaje original que U deseaba enviar a V. 6.8. Ejemplos de utilización 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 apli- cación JCOPECIES

A continuación se muestra un ejemplo de cifrado y descifrado empleando la aplicación JCOPECIES y una tarjeta JCOP J3A con la conﬁguración P3 y la curva sect193r1. La Figura 6.7 recoge los datos utilizados en el proceso de cifrado, y que son los siguientes:

∙ Clave pública del destinatario:

042A38ACD50BDBBE2FE80DB46492E10CE988310A9E7679FAAE739 5DCEAC208B64D0AFE521A0B61DF4C2A2700D48E164D05.

∙ Mensaje a cifrar: Texto Prueba cifrado 1, cuyo valor hexadecimal está representado por la cadena

507275656261206369667261646F2031.

∙ Etiqueta: Cadena Test, cuyo valor hexadecimal es 54657374.

El resultado de este proceso de cifrado es el criptograma 270 6. Implementación de ECIES en Java Card

04F465E627E750EDC11C0EF383AE077F964A9D12755CA94439A92A6C DC89E259E41FCFBB3C1EADDDB4831EBBCA1D03F0BF89AD884D829 E76A98E100172F64E1054FDD117E97B04C9CFDBBE610BF3AACC75B4 10448EA679FC44C3C427C3466D275D cuya codiﬁcación Base64 es

BPRl5ifnUO3BHA7zg64Hf5ZKnRJ1XKlEOakqbNyJ4lnkH8+7PB6t3bSD HrvKHQPwv4mtiE2CnnapjhABcvZOEFT90RfpewTJz9u+YQvzqsx1tBB EjqZ5/ETDxCfDRm0nXQ==.

A continuación es necesario utilizar la tarjeta JCOP J3A que incluye el par de claves cuya clave pública fue empleada en el cifrado del mensaje. En este caso, los datos a incluir en la pestaña Descifrado son únicamente el criptograma y la etiqueta, mientras que en la pestaña Configuración es necesario especificar el lector, el tipo de tarjeta y la curva elíptica. La Figura 6.8 muestra el resultado del proceso de cifrado tal como aparece en la pestaña Descifrado. De manera complementaria, si el usuario desea comprobar qué APDU han sido transmitidas durante el proceso de descifrado, puede acceder a estos datos mediante la pestaña Configuración, tal como puede apreciarse en la Figura 6.16.

Figura 6.16: Ventana APDU con datos de descifrado Capítulo 7

Resultados empíricos

Resumen del capítulo Este capítulo recoge las pruebas realizadas con las implementaciones de ECIES para PC y Java Card, utilizando diferentes combinaciones de pa- rámetros y algoritmos en función de las posibilidades criptográﬁcas de cada una de las plataformas seleccionadas. A ﬁn de analizar los resultados de las pruebas, el capítulo incluye una descripción detallada de las características de las tarjetas inteligentes empleadas en dichas pruebas.

7.1. Material utilizado

Las pruebas ejecutadas con las distintas conﬁguraciones detalladas en §7.2 se han realizado sobre tres plataformas hardware diferentes: un PC y dos modelos de tarjetas inteligentes de la empresa NXP. A continuación se detallan las principales características de cada una de las plataformas mencionadas:

∙ Plataforma PC:

Procesador: Intel Pentium D a 3 GHz. Memoria RAM: 2 Gbytes. Sistema operativo: Windows XP con Service Pack 3. Versiones Java: Java SE 5.0 y Java SE 6. ∙ Tarjetas JCOP 41 [200, 202]:

271 272 7. Resultados empíricos

Módulo hardware: P5CT072. CPU: Secure_MX51 (Memory eXtended/enhanced 80C51) de 8 bits. Sistema operativo: JCOP 2.2.1. Versión Java Card: 2.2.1 (implementación parcial). Versión GlobalPlatform: 2.1.1. Tecnología CMOS: 0,18 m con 5 capas de metal. Frecuencia externa de reloj: hasta 10 MHz. Máxima frecuencia interna de reloj: 30 MHz. Memoria ROM: 160 Kbytes. Memoria EEPROM: 72 Kbytes. Memoria RAM: 4608 bytes. Protocolos de comunicación: ISO/IEC 7816 (con contactos) e ISO/IEC 14443 Tipo A (sin contactos). Coprocesadores criptográﬁcos: TDES, AES y PKI (RSA, ECC, etc).

Cuerpo ﬁnito: F2m . Longitudes de curvas: 113, 131, 163 y 193 bits. Función HASH : SHA-1. Función KA: DH, donde la salida de la función es el resumen SHA-1 de la primera coordenada del dato secreto compartido. Función ENC : DES y TDES en modo CBC sin relleno. ∙ Tarjetas JCOP J3A [201, 202]:

Módulo hardware: P5CD080. CPU: Secure_MX51 (Memory eXtended/enhanced 80C51) de 8 bits. Sistema operativo: JCOP 2.4.1. Versión Java Card: 2.2.2 (implementación parcial). Versión GlobalPlatform: 2.1.1. Tecnología CMOS: 0,14 m. Frecuencia externa de reloj: hasta 10 MHz. Máxima frecuencia interna de reloj: 30 MHz. Memoria ROM: 200 Kbytes. Memoria EEPROM: 80 Kbytes. Memoria RAM: 6144 bytes. Protocolos de comunicación: ISO/IEC 14443 Tipo A (sin contactos). 7.1. Material utilizado 273

Coprocesadores criptográﬁcos: TDES, AES y PKI (RSA, ECC, etc).

Cuerpo finito: Fp. Longitudes de curvas: 128, 160 y 192 bits. Función HASH : SHA-1 y SHA-256. Función KA: DH con dos variantes, una en la que la salida de la función es el resumen SHA-1 de la primera coordenada del secreto compartido, y otra en la que la salida es directamente el valor de la primera coordenada. Función ENC : DES, TDES y AES en modo CBC sin relleno. La Figura 7.1 presenta el diagrama de los componentes comunes de los módulos P5CT072 y P5CD080, donde se pueden apreciar claramente los tres coprocesadores criptográficos que incorporan los productos JCOP 41 y J3A. Para evitar confusiones es necesario comentar que, aunque las tarjetas JCOP 41 incluyen el coprocesador para AES, no permiten utilizar este algoritmo debido a que se encuentra inhabilitado en esas tarjetas por un error de configuración durante el proceso de fabricación.

Figura 7.1: Diagrama de los módulos P5CT072 y P5CD080

Otro dato interesante es el hecho de que el chip tiene más entradas (nueve en el caso de la Figura 7.1) que el número de contactos de las tarjetas (típicamente ocho, ver §1.3.2.1). Ello se debe a que los chips se diseñan de manera genérica para 274 7. Resultados empíricos poder adaptarse a diferentes conﬁguraciones según las necesidades de los clientes: en las tarjetas JCOP utilizadas, por ejemplo, únicamente se utiliza uno de los tres contactos de entrada/salida para la comunicación serie entre el lector y el chip. Por otra parte, la Figura 7.2 muestra una imagen real de las tarjetas JCOP 41 y JCOP J3A utilizadas, así como del lector PC/SC Omnikey 5321 [105] empleado en las pruebas.

Figura 7.2: Tarjetas JCOP y lector PC/SC empleados en las pruebas

Puesto que las tarjetas JCOP 41 permiten utilizar tanto la interfaz con contactos como la interfaz sin contactos, las pruebas de cifrado y descifrado realizadas con las tarjeas JCOP 41 han sido duplicadas a ﬁn de obtener resultados mediante ambas interfaces. Tal como se puede apreciar en la Figura 7.3, que muestra la informa- ción proporcionada por una herramienta de Omnikey relativa a la tarjeta JCOP 41 utilizando el protocolo T=0 (con contactos) y T=CL (sin contactos), la frecuencia utilizada en la interfaz con contactos es de 4.80 MHz, mientras si se utiliza la interfaz sin contactos la frecuencia es 13.56 MHz. Es importante señalar que, a pesar de conocer la frecuencia de la señal externa de reloj proporcionada a la tarjeta, no es posible sin embargo conocer la frecuencia interna a la que las tarjetas realmente están trabajando. La única información que ha sido posible obtener es la asociada a las características técnicas de los dos modelos de tarjetas, la cual indica que la frecuencia interna de trabajo tiene un valor máximo de 30 MHz para ambos modelos. 7.2. Conﬁguraciones de prueba 275

Figura 7.3: Frecuencias de trabajo en la interfaz con contactos y sin contactos

Independientemente de lo anterior, es necesario aclarar que los tiempos de cifrado y descifrado calculados en las pruebas descritas en este capítulo incluyen el tiempo de transmisión de las APDU apropiadas (de petición de una operación y de envío del resultado desde la tarjeta al lector) junto con el tiempo de procesamiento efectivo (es decir, el tiempo que tarda la tarjeta en realizar la operación pertinente desde que dispone de todos los datos y ha recibido la orden de ejecución hasta los datos producidos están listos para ser transmitidos). El tiempo de transmisión, por su naturaleza, depende de dos parámetros: la longitud de los datos a transmitir, y la velocidad a la que los datos son transmitidos por el canal de comunicación.

7.2. Conﬁguraciones de prueba

Con el objetivo de intentar comparar de forma homogénea las implementaciones del esquema de cifrado ECIES en PC y Java Card, y debido a las limitaciones en las funcionalidades criptográﬁcas disponible en las tarjetas JCOP 41 y JCOP J3A, se han realizado pruebas con las conﬁguraciones detalladas a continuación.

∙ Conﬁguración M1:

Cuerpo sobre el que se deﬁne la curva elíptica: F2m . Función HASH : SHA-256. Función KA: DH. Función KDF : KDF2. Función ENC : AES en modo CBC con relleno PKCS#5. Función MAC : HMAC-SHA-256-256. Longitud de la clave de cifrado simétrico: 32 bytes. 276 7. Resultados empíricos

Longitud de la clave MAC : 32 bytes. Utilización como parámetro de entrada en la función KDF de la primera coordenada del punto de la curva que representa el secreto compartido. Utilización de la clave pública temporal del emisor como entrada para la función KDF.

Interpretación de la salida de la función KDF como kENC ∣∣kMAC . Utilización del formato comprimido en la representación de los puntos de la curva elíptica. ∙ Conﬁguración M2:

Cuerpo sobre el que se deﬁne la curva elíptica: F2m . Función HASH : SHA-1. Función KA: DH. Función KDF : KDF2. Función ENC : TDES en modo CBC sin relleno. Función MAC : HMAC-SHA-1-160. Longitud de la clave de cifrado simétrico: 16 bytes. Longitud de la clave MAC : 20 bytes. Utilización como parámetro de entrada en la función KDF del resumen SHA-1 de la primera coordenada del punto de la curva que representa el secreto compartido.

Interpretación de la salida de la función KDF como kENC ∣∣kMAC . Utilización del formato sin comprimir en la representación de los puntos de la curva elíptica. ∙ Conﬁguración P1:

Cuerpo sobre el que se deﬁne la curva elíptica: Fp. Función HASH : SHA-256. Función KA: DH. Función KDF : KDF2. Función ENC : AES en modo CBC con relleno PKCS#5. Función MAC : HMAC-SHA-256-256. Longitud de la clave de cifrado simétrico: 32 bytes. Longitud de la clave MAC : 32 bytes. Utilización como parámetro de entrada en la función KDF de la primera coordenada del punto de la curva que representa el secreto compartido. 7.2. Conﬁguraciones de prueba 277

Utilización de la clave pública temporal del emisor como entrada para la función KDF.

Interpretación de la salida de la función KDF como kENC ∣∣kMAC . Utilización del formato comprimido en la representación de los puntos de la curva elíptica. ∙ Conﬁguración P2:

Cuerpo sobre el que se deﬁne la curva elíptica: Fp. Función HASH : SHA-1. Función KA: DH. Función KDF : KDF2. Función ENC : TDES en modo CBC sin relleno. Función MAC : HMAC-SHA-1-160. Longitud de la clave de cifrado simétrico: 16 bytes. Longitud de la clave MAC : 20 bytes. Utilización como parámetro de entrada en la función KDF del resumen SHA-1 de la primera coordenada del punto de la curva que representa el secreto compartido.

Interpretación de la salida de la función KDF como kENC ∣∣kMAC . Utilización del formato sin comprimir en la representación de los puntos de la curva elíptica. ∙ Conﬁguración P3:

Cuerpo sobre el que se deﬁne la curva elíptica: Fp. Función HASH : SHA-256. Función KA: DH. Función KDF : KDF2. Función ENC : AES en modo CBC sin relleno. Función MAC : HMAC-SHA-256-256. Longitud de la clave de cifrado simétrico: 16 bytes. Longitud de la clave MAC : 32 bytes. Utilización como parámetro de entrada en la función KDF de la primera coordenada del punto de la curva que representa el secreto compartido.

Interpretación de la salida de la función KDF como kENC ∣∣kMAC . Utilización del formato sin comprimir en la representación de los puntos de la curva elíptica. 278 7. Resultados empíricos

Las configuraciones cuyo nombre comienza por la letra P indican la utilización 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 implementación de ECIES para PC que incorpora las recomendaciones de seguridad reseñadas en el Capítulo 4. Aunque estas dos configuraciones no se pueden implementar en las tarjetas Java Card, se han incluido para poder realizar comparaciones con las otras configuraciones. Por su parte, la configuración M2 es la versión implementada en las tarjetas JCOP 41, siendo la configuración P2 equivalente a la versión M2 con la única diferencia del cuerpo finito empleado. Por último, la configuración P3 es la versión para tarjetas JCOP J3A que emplea las características avanzadas de estas tarjetas (funciones SHA-256, AES, etc.). Respecto a las curvas elípticas utilizadas en las pruebas, el Cuadro 7.1 presenta las curvas empleadas en cada una de las configuraciones.

M1 M2 P1 P2 P3 sect113r1 sect113r1 secp112r1 secp128r1 secp128r1 sect131r1 sect131r1 secp128r1 secp160r1 secp160r1 sect163r1 c2pnb163v1 secp160r1 P-192 P-192 sect193r1 sect193r1 secp192k1 sect233r1 secp224r1 sect239k1 secp256k1 sect283r1 secp384r1 sect409r1 secp521r1 sect571r1

Cuadro 7.1: Curvas elípticas empleadas en las conﬁguraciones

En las configuraciones M1 y P1 se han utilizado curvas elípticas publicadas por SECG, puesto que este consorcio proporciona curvas con un amplio rango respecto a su longitud. En concreto, se ha tomado una curva de cada una de las longitudes disponibles en [255], eligiendo como primera opción las curvas cuyos coeficientes han sido seleccionados aleatoriamente de forma reproducible siguiendo las indicaciones de [255] (curvas con sufijo r1), y como segunda opción las curvas Koblitz (curvas con sufijo k1). Por su parte, las curvas de las configuraciones P2, P3 y M2 son las implementadas en las tarjetas JCOP 41 y JCOP J3A, donde todas las curvas están definidas en [255], con la excepción de las curvas P-192 [15] y c2pnb163v1 [272]. 7.3. Factor de expansión 279

7.3. Factor de expansión

Este apartado presenta las pruebas en las que se ha calculado el factor de expan- sión, interpretado en esta Tesis como la relación entre la longitud del criptograma C (tripleta formado por la clave pública temporal, el mensaje cifrado y el código MAC ) y la longitud del mensaje original, obteniendo de esta manera una medida de la eﬁciencia en cuanto a ancho de banda de ECIES. Debido a la naturaleza de ECIES, existen diversos elementos que contribuyen al tamaño ﬁnal de los criptogramas. La siguiente lista describe dichos elementos:

1. El cuerpo ﬁnito Fq, que determina la longitud en bytes de la representación binaria asociada a los elementos del cuerpo (y que conforman las coordenadas de los puntos de la curva elíptica).

2. La representación binaria de la clave pública temporal del emisor (ya sea comprimida o sin comprimir).

3. La función de cifrado simétrico (TDES, AES, etc.), su modo de utilización (ECB, CBC, etc.) y el método de relleno (PKCS#5, sin relleno, etc.).

4. La longitud del código MAC generado.

En el caso particular de las implementaciones Java Card, puesto que la longitud máxima de un comando APDU es 255 bytes, el conjunto de longitudes de los mensajes a cifrar utilizados en estas pruebas se ha seleccionado de manera que la respuesta a una petición de cifrado o descifrado esté contenida en una única APDU de respuesta. La utilización de peticiones con mensajes y criptogramas cuya respuesta excediera 255 bytes tendría las siguientes consecuencias:

1. El tiempo de la operación aumentaría al ser necesaria la transmisión de APDU adicionales por el canal de transmisión.

2. Dado que tanto los mensajes a cifrar como los criptogramas a descifrar deben ser almacenados temporalmente en la memoria de las tarjetas inteligentes para su procesado, y puesto que la cantidad de RAM en las tarjetas es muy limitada, la utilización de mensajes de excesivo tamaño provocaría que los elementos de tipo array que albergan los datos a cifrar o descifrar tuvieran que ser almacenados en memoria EEPROM en lugar de en memoria RAM, con el consiguiente deterioro del rendimiento general.

En todas las pruebas referidas a continuación, el factor de expansión puede ser calculado como 280 7. Resultados empíricos

∣C∣ ∣m∣ + (7.1) FE = = , ∣m∣ ∣m∣ donde ∣C∣ es la longitud en bytes del criptograma, ∣m∣ 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 ﬁguras de los siguientes apartados recogen el factor de expansión calculado para distintas combinaciones de claves y mensajes en claro, por sencillez en la exposición se incluirá únicamente la fórmula del valor en cada caso.

7.3.1. Factor de expansión con la conﬁguración M1

Las pruebas llevadas a cabo con la conﬁguración M1 tienen las siguientes propiedades:

∙ La longitud de los mensajes en claro es en todos los casos múltiplo de 16 (lo que genera un bloque de 16 bytes adicional al utilizar el algoritmo AES en modo CBC con relleno PKCS#5).

∙ Los puntos de la curva elíptica se representan de forma comprimida.

∙ El código MAC tiene una longitud de 32 bytes.

Con ello, la diferencia M1 entre la longitud del criptograma y la longitud del mensaje original cuando se utilizan curvas deﬁnidas sobre F2m viene dada por la fórmula

lmm lmm = 1 + + 16 + 32 = + 49, M1 8 8 donde el byte inicial es el preﬁjo que indica la compresión del punto que representa la clave pública temporal U, ⌈m/8⌉ representa el número de bytes necesarios para representar un elemento del cuerpo F2m , el relleno PKCS#5 añade 16 bytes durante el proceso de cifrado simétrico y, por último, el código MAC ocupa 32 bytes. El Cuadro 7.2 y la Figura 7.4 muestran el factor de expansión calculado a partir de la ecuación (7.1) al cifrar mensajes de distinta longitud (16, 32, 64, 128, 256, 512 y 1024 bytes) utilizando las diferentes longitudes de clave consideradas en la conﬁguración M1. 7.3. Factor de expansión 281

Longitud del mensaje (bytes) 16 32 64 128 256 512 1024 sect113r1 5 3 2 1.5 1.25 1.13 1.06 sect131r1 5.13 3.06 2.03 1.52 1.26 1.13 1.06 sect163r1 5.38 3.19 2.09 1.55 1.27 1.14 1.07 sect193r1 5.63 3.31 2.16 1.58 1.29 1.14 1.07 sect233r1 5.94 3.47 2.23 1.62 1.31 1.15 1.08 sect239k1 5.94 3.47 2.23 1.62 1.31 1.15 1.08 sect283r1 6.31 3.66 2.33 1.66 1.33 1.17 1.08 Curva elíptica sect409r1 7.31 4.16 2.58 1.79 1.39 1.2 1.1 sect571r1 8.56 4.78 2.89 1.95 1.47 1.24 1.12

Cuadro 7.2: Factor de expansión en curvas sobre F2m con la conﬁguración M1

Figura 7.4: Factor de expansión en curvas sobre F2m con la conﬁguración M1 282 7. Resultados empíricos

7.3.2. Factor de expansión con la conﬁguración M2

Las características especíﬁcas de las pruebas realizadas con la conﬁguración M2 son:

∙ La longitud de los mensajes en claro es en todos los casos múltiplo de 16 (siendo la longitud del mensaje cifrado igual a la longitud del mensaje original al utilizar el algoritmo TDES en modo CBC sin relleno).

∙ Los puntos de la curva elíptica se representan sin comprimir.

∙ El código MAC tiene una longitud de 20 bytes.

Con estos elementos, la diferencia M2 entre la longitud del criptograma y la longitud del mensaje original cuando se utilizan curvas deﬁnidas sobre F2m viene dada por la fórmula

lmm lmm = 1 + 2 ⋅ + 20 = 2 ⋅ + 21, M2 8 8 donde el byte inicial es el prefijo añadido para indicar que el punto de la curva que representa la clave pública temporal no está comprimido, el valor ⌈m/8⌉ aparece duplicado puesto que al no utilizarse compresión de puntos es necesario incluir las dos coordenadas del punto, y finalmente el código MAC ocupa 20 bytes. El Cuadro 7.3 y la Figura 7.5 muestran el factor de expansión calculado mediante la ecuación (7.1) al cifrar mensajes de distinta longitud (16, 32, 48, 64, 80, 96, 112, 128, 144 y 160 bytes) utilizando la configuración M2 con diferentes longitudes de claves.

Longitud del mensaje (bytes) 16 32 48 64 80 96 112 128 144 160 sect113r1 4.19 2.59 2.06 1.8 1.64 1.53 1.46 1.4 1.35 1.32 sect131r1 4.44 2.72 2.15 1.86 1.69 1.57 1.49 1.43 1.38 1.34 c2pnb163v1 4.94 2.97 2.31 1.98 1.79 1.66 1.56 1.49 1.44 1.39 Curva sect193r1 5.44 3.22 2.48 2.11 1.89 1.74 1.63 1.55 1.49 1.44

Cuadro 7.3: Factor de expansión en curvas sobre F2m con la conﬁguración M2

7.3.3. Factor de expansión con la conﬁguración P1

Las pruebas realizadas en este apartado tienen las siguientes características es- pecíﬁcas: 7.3. Factor de expansión 283

Figura 7.5: Factor de expansión en curvas sobre F2m con la conﬁguración M2

∙ La longitud de los mensajes en claro es, en todos los casos, múltiplo de 16 (lo que genera un bloque de 16 bytes adicional al utilizar el algoritmo AES en modo CBC con relleno PKCS#5). ∙ Los puntos de la curva elíptica se representan de forma comprimida. ∙ El código MAC tiene una longitud de 32 bytes.

Con ello, la diferencia P 1 entre la longitud del criptograma y la longitud del mensaje original cuando se utilizan curvas deﬁnidas sobre Fp para cifrar mensajes cuya longitud en bytes es múltiplo de 16 viene dada por la fórmula

llog pm llog pm = 1 + 2 + 16 + 32 = 2 + 49, P 1 8 8 donde el byte inicial es el preﬁjo añadido por el algoritmo de compresión de puntos

(y cuyos posibles valores son 0x02 ó 0x03), ⌈(log2 p)/8⌉ representa el número de bytes necesarios para representar un elemento del cuerpo Fp, el relleno PKCS#5 añade 16 bytes durante el proceso de cifrado simétrico y, por último, el código MAC ocupa 32 bytes. El Cuadro 7.4 y la Figura 7.6 muestran el factor de expansión calculado mediante la ecuación (7.1) al cifrar mensajes de distinta longitud (16, 32, 64, 128, 256, 512 y 284 7. Resultados empíricos

1024 bytes) utilizando la conﬁguración P1 y haciendo uso de curvas con diferentes longitudes de clave. Longitud del mensaje (bytes) 16 32 64 128 256 512 1024 secp112r1 4.94 2.97 1.98 1.49 1.25 1.12 1.06 secp128r1 5.06 3.03 2.02 1.51 1.25 1.13 1.06 secp160r1 5.31 3.16 2.08 1.54 1.27 1.13 1.07 secp192k1 5.56 3.28 2.14 1.57 1.29 1.14 1.07 secp224r1 5.81 3.41 2.2 1.6 1.3 1.15 1.08 secp256k1 6.06 3.53 2.27 1.63 1.32 1.16 1.08

Curva elíptica secp384r1 7.06 4.03 2.52 1.76 1.38 1.19 1.09 secp521r1 8.19 4.59 2.8 1.9 1.45 1.22 1.11

Cuadro 7.4: Factor de expansión en curvas sobre Fp con la conﬁguración P1

Figura 7.6: Factor de expansión en curvas sobre Fp con la conﬁguración P1

7.3.4. Factor de expansión con la conﬁguración P2

Las pruebas realizadas en este apartado tienen las siguientes características es- pecíﬁcas: 7.3. Factor de expansión 285

∙ Los puntos de la curva elíptica se representan sin comprimir.

∙ El código MAC tiene una longitud de 20 bytes.

Con estos elementos, la diferencia P 2 entre la longitud del criptograma y la longitud del mensaje original cuando se utilizan curvas deﬁnidas sobre Fp viene dada por la fórmula

llog pm llog pm = 1 + 2 ⋅ 2 + 20 = 2 ⋅ 2 + 21, P 2 8 8 donde el byte inicial es el prefijo añadido para indicar que el punto de la curva que representa la clave pública temporal U no está comprimido (y que por lo tanto toma valor 0x04), el valor ⌈(log2 p)/8⌉ aparece duplicado ya que al no utilizarse compresión de puntos es necesario incluir las dos coordenadas del punto, y finalmente el código MAC ocupa 32 bytes. El Cuadro 7.5 y la Figura 7.7 muestran el factor de expansión calculado a partir de la ecuación (7.1) al cifrar mensajes de distinta longitud (16, 32, 48, 64, 80, 96, 112, 128, 144 y 160 bytes) utilizando la configuración P2 con diferentes longitudes de claves, según las curvas consideradas.

Longitud del mensaje (bytes) 16 32 48 64 80 96 112 128 144 160 secp128r1 4.31 2.66 2.1 1.83 1.66 1.55 1.47 1.41 1.37 1.33 secp160r1 4.81 2.91 2.27 1.95 1.76 1.64 1.54 1.48 1.42 1.38

Curva P-192 5.31 3.16 2.44 2.08 1.86 1.72 1.62 1.54 1.48 1.43

Cuadro 7.5: Factor de expansión en curvas sobre Fp con la conﬁguración P2

7.3.5. Factor de expansión con la conﬁguración P3

Las características especíﬁcas de las pruebas realizadas en este apartado son:

∙ La longitud de los mensajes en claro es en todos los casos múltiplo de 16 (siendo la longitud del mensaje cifrado igual a la longitud del mensaje original al utilizar el algoritmo AES en modo CBC sin relleno).

∙ Los puntos de la curva elíptica se representan sin comprimir. 286 7. Resultados empíricos

Figura 7.7: Factor de expansión en curvas sobre Fp con la conﬁguración P2

∙ El código MAC tiene una longitud de 32 bytes.

Debido a estas características, la diferencia P 3 entre la longitud del criptograma y la longitud del mensaje original cuando se utilizan curvas deﬁnidas sobre Fp viene dada por la fórmula

llog pm llog pm = 1 + 2 ⋅ 2 + 32 = 2 ⋅ 2 + 33, P 3 8 8 donde el byte inicial es el prefijo añadido para indicar que el punto de la curva que representa la clave pública temporal no está comprimido, el valor ⌈(log2 p)/8⌉ aparece duplicado puesto que representa la longitud en bytes de dos elementos del cuerpo finito Fp, y por último el código MAC ocupa 32 bytes. El Cuadro 7.6 y la Figura 7.8 muestran el factor de expansión calculado mediante la ecuación (7.1) al cifrar mensajes de distinta longitud (16, 32, 48, 64, 80, 96, 112, 128, 144 y 160 bytes) utilizando la configuración P3 con diferentes claves. 7.3. Factor de expansión 287

Longitud del mensaje (bytes) 16 32 48 64 80 96 112 128 144 160 secp128r1 5.06 3.03 2.35 2.02 1.81 1.68 1.58 1.51 1.45 1.41 secp160r1 5.56 3.28 2.52 2.14 1.91 1.76 1.65 1.57 1.51 1.46

Curva P-192 6.06 3.53 2.69 2.27 2.01 1.84 1.72 1.63 1.56 1.51

Cuadro 7.6: Factor de expansión en curvas sobre Fp con la conﬁguración P3

Figura 7.8: Factor de expansión en curvas sobre Fp con la conﬁguración P3 288 7. Resultados empíricos

7.4. Tiempo de cifrado

El procedimiento seguido para obtener las mediciones del tiempo de cifrado en todas las implementaciones tiene las siguientes características:

1. Para cada longitud de curva disponible se han utilizado mensajes de longitud 16, 32, 48, 64, 80, 96, 112, 128, 144 y 160 bytes de forma común a todas las pruebas, y mensajes de 176 bytes de longitud en los casos en los que la respuesta se podía incluir en una única APDU. Todos los bytes del mensaje han sido inicializados con el valor 0xFF.

2. El tiempo de cifrado referido a cada curva representa la media de 20 procesos de cifrado consecutivos.

3. La función de la API de Java SE utilizada para obtener la medición de tiempos es System.nanoTime(), que proporciona el valor actual en nanosegundos del reloj del sistema.

En el caso particular de las mediciones utilizando la implementación de ECIES para PC, el tiempo de inicio de la medición es exactamente antes del cálculo del producto u V , después de que todos los parámetros y variables estén cargados en la memoria RAM del PC. Por su parte, el tiempo final de cada medición ha sido obtenido justo después de que el criptograma esté construido en la memoria RAM como una cadena hexadecimal, antes de que se muestren los datos por pantalla para evitar la influencia de los retrasos asociados a dicha presentación. En cuanto a las implementaciones Java Card, tal como se comentó en §6.6, se ha diseñado una aplicación Java SE de línea de comandos que se encarga del envío y recepción de los comandos APDU, así como de la medición de tiempos. La comunicación con la tarjeta inteligente se ha realizado mediante el API Smart Card I/O de Java y el lector PC/SC Omnikey 5321. El tiempo de inicio de la medición en estas pruebas constituye el instante anterior al envío de la APDU con la petición de cifrado (estando en ese momento todos los datos necesarios cargados en la memoria RAM de la tarjeta inteligente), mientras que el tiempo final ha sido obtenido en el instante posterior a la recepción de la APDU de respuesta, por lo que los tiempos así medidos incluyen tanto el tiempo de transmisión de los datos como el tiempo de procesamiento en la tarjeta inteligente. Para mayor claridad en la lectura, el tiempo de cifrado se encuentra expresado en todas las figuras y cuadros incluidos en los siguientes apartados en milisegundos, aunque no se indique expresamente. 7.4. Tiempo de cifrado 289

7.4.1. Tiempo de cifrado en PC con la conﬁguración M1

Al igual que con la configuración P1, únicamente la versión de Java para PC dispone de las funcionalidades criptográficas requeridas por la configuración M1. El Cuadro 7.7 y la Figura 7.9 muestran el tiempo de cifrado de la versión para PC de ECIES.

Longitud del cuerpo ﬁnito F2m (bits) 113 131 163 193 233 239 283 409 571 16 28.82 35.61 54.94 76.57 102.84 106.52 131.56 220.78 370.40 32 27.91 36.02 54.4 80.26 103.81 106.24 133.21 220.52 370.97 48 27.52 36.34 55.01 81.45 103.43 106.12 132.31 219.85 369.78 64 27.80 36.71 54.35 81.92 102.33 105.46 132.04 220.66 368.64 80 27.64 36.62 57.60 82.05 102.93 105.44 132.62 221.53 368.81 96 27.71 36.50 57.23 82.57 103.72 105.32 131.77 220.30 370.62 112 27.62 36.42 58.03 81.53 102.92 105.52 132.34 220.43 370.36 128 27.53 36.40 59.61 82.46 103.24 105.42 131.73 222.71 368.68 144 27.55 36.63 58.61 81.34 103.21 105.30 130.62 225.65 369.73 160 28.14 36.21 58.00 81.51 102.51 105.33 129.72 224.45 368.42

Longitud del mensaje (bytes) 176 28.34 36.26 59.67 82.53 102.31 105.54 129.96 225.53 368.50

Cuadro 7.7: Tiempo de cifrado con curvas sobre F2m en PC (conﬁguración M1)

7.4.2. Tiempo de cifrado en PC y Java Card con la conﬁgu- ración M2

La conﬁguración M2 ha sido probada tanto en la versión PC de ECIES como en la implementación Java Card desarrollada para la tarjeta JCOP 41. El Cuadro 7.8 y la Figura 7.10 muestran los resultados de la versión PC, el Cuadro 7.9 y la Figura 7.11 presentan el tiempo de cifrado utilizando tarjetas JCOP 41 y la interfaz sin contactos, y ﬁnalmente 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 conﬁguración P1

Puesto que la configuración P1 utiliza unas funciones criptográficas que no están disponibles en la tarjeta Java Card, esta configuración ha sido utilizada únicamente en la implementación PC de ECIES. El Cuadro 7.11 y la Figura 7.13 muestran los resultados de la versión PC. 290 7. Resultados empíricos

Figura 7.9: Tiempo de cifrado con curvas sobre F2m en PC (conﬁguración M1)

Longitud del cuerpo ﬁnito F2m (bits) 113 131 163 193 16 25.91 34.9 53.56 77.99 32 26.04 35.15 55.49 78.13 48 25.68 35.24 55.49 78.28 64 25.99 35.13 54.27 78.17 80 25.61 35.04 54.31 77.97 96 25.92 35.02 53.94 77.66 112 26.01 34.82 53.36 77.12 128 26.22 34.79 53.18 77.93 144 26.51 34.67 53.59 79.32 160 26.55 35.14 53.69 79.24

Longitud del mensaje (bytes) 176 26.78 35.07 53.71 79.50

Cuadro 7.8: Tiempo de cifrado con curvas sobre F2m en PC (conﬁguración M2) 7.4. Tiempo de cifrado 291

Figura 7.10: Tiempo de cifrado con curvas sobre F2m en PC (conﬁguración M2)

Longitud del cuerpo ﬁnito F2m (bits) 113 131 163 193 16 296.74 314.65 332.71 367.64 32 297.35 314.76 333.82 368.88 48 306.58 324.33 342.34 384.44 64 307.49 331.62 349.65 384.58 80 314.23 332.18 349.94 384.98 96 314.59 332.55 351.54 386.45 112 323.76 341.66 360.50 401.76 128 331.39 348.78 367.11 401.81 144 331.53 349.39 367.57 403.46 160 331.82 350.70 368.74 403.70

Longitud del mensaje (bytes) 176 341.52 358.64 384.40 418.98

Cuadro 7.9: Tiempo de cifrado con curvas sobre F2m en JCOP 41 e interfaz sin contactos (conﬁguración M2) 292 7. Resultados empíricos

Figura 7.11: Tiempo de cifrado con curvas sobre F2m en JCOP 41 e interfaz sin contactos (conﬁguración M2)

Longitud del cuerpo ﬁnito F2m (bits) 113 131 163 193 16 363.51 384.52 407.35 446.56 32 379.26 399.71 423.00 461.89 48 398.18 418.68 441.77 481.21 64 413.51 433.60 457.30 496.31 80 428.94 448.95 472.47 511.39 96 444.44 464.41 487.81 526.91 112 463.38 483.65 506.62 545.77 128 478.95 498.73 522.03 561.14 144 494.01 514.38 537.20 576.33 160 509.34 529.41 552.31 591.55

Longitud del mensaje (bytes) 176 528.36 548.35 571.23 610.54

Cuadro 7.10: Tiempo de cifrado con curvas sobre F2m en JCOP 41 e interfaz con contactos (conﬁguración M2) 7.4. Tiempo de cifrado 293

Figura 7.12: Tiempo de cifrado con curvas sobre F2m en JCOP 41 e interfaz con contactos (conﬁguración M2)

Longitud del cuerpo ﬁnito Fp (bits) 112 128 160 192 224 256 384 521 16 23.53 23.94 39.01 54.47 68.61 79.06 142.33 226.02 32 23.48 23.94 39.28 54.89 68.95 79.63 141.05 225.91 48 23.72 23.88 40.03 54.82 69 78.89 141.12 225.44 64 24.43 24.64 40.12 54.63 68.91 79.31 141.02 226.55 80 23.31 24.51 40.05 54.27 69.03 78.61 141.28 226.63 96 23.28 24.39 39.99 54.91 69.71 80.92 141.39 225.67 112 24.08 24.57 40.20 54.49 69.15 81.33 142.29 226.64 128 23.86 24.51 41.49 54.78 68.81 82.56 141.84 227.53 144 23.9 24.65 40.64 54.25 69.09 80.18 142.10 228.13 160 24.33 24.83 40.45 54.23 69.3 79.81 142.22 229.36

Longitud del mensaje (bytes) 176 23.55 24.12 39.77 53.96 69.88 79.33 143.07 228.08

Cuadro 7.11: Tiempo de cifrado con curvas sobre Fp en PC (conﬁguración P1) 294 7. Resultados empíricos

Figura 7.13: Tiempo de cifrado con curvas sobre Fp en PC (conﬁguración P1)

7.4.4. Tiempo de cifrado en PC y Java Card con la conﬁgu- ración P2

La conﬁguración P2 ha sido probada tanto en la versión PC de ECIES como en la implementación Java Card desarrollada para las tarjetas JCOP J3A de NXP. El Cuadro 7.12 y la Figura 7.14 muestran los resultados de la versión PC, mientras que el Cuadro 7.13 y la Figura 7.15 presentan el tiempo de cifrado utilizando tarjetas JCOP J3A.

7.4.5. Tiempo de cifrado en PC y Java Card con la conﬁgu- ración P3

La conﬁguración P3 ha sido igualmente probada en las versiones para PC y tarjetas JCOP J3A. El Cuadro 7.14 y la Figura 7.16 muestran los resultados de la versión PC, mientras que el Cuadro 7.15 y la Figura 7.17 presentan el tiempo de cifrado de mensajes de distinta longitud utilizando tarjetas JCOP J3A. 7.4. Tiempo de cifrado 295

Longitud del cuerpo ﬁnito Fp (bits) 128 160 192 16 25.87 40.95 57.59 32 25.79 41.45 57.37 48 25.84 41.02 57.29 64 25.98 40.57 57.23 80 26.21 40.58 56.77 96 25.78 40.04 56.70 112 25.75 40.67 56.61 128 26.15 41.73 56.67 144 26.34 40.94 56.99

Longitud mensaje (bytes) 160 26.98 41.63 57.04

Cuadro 7.12: Tiempo de cifrado con curvas sobre Fp en PC (conﬁguración P2)

Figura 7.14: Tiempo de cifrado con curvas sobre Fp en PC (conﬁguración P2) 296 7. Resultados empíricos

Longitud del cuerpo ﬁnito Fp (bits) 128 160 192 16 481.55 518.24 587.76 32 482.26 520.29 589.71 48 489.63 526.76 597.61 64 491.59 534.67 603.90 80 499.66 535.46 605.29 96 501.82 536.85 606.50 112 512.23 544.14 620.53 128 519.80 551.29 621.59 144 521.07 552.35 623.32 160 522.50 554.08 623.73

Longitud del mensaje (bytes) 176 529.22 561.74 636.95

Cuadro 7.13: Tiempo de cifrado con curvas sobre Fp en JCOP J3A e interfaz sin contactos (conﬁguración P2)

Figura 7.15: Tiempo de cifrado con curvas sobre Fp en JCOP J3A e interfaz sin contactos (conﬁguración P2) 7.4. Tiempo de cifrado 297

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

Longitud mensaje (bytes) 160 24.73 39.44 58.31

Cuadro 7.14: Tiempo de cifrado con curvas sobre Fp en PC (conﬁguración P3)

Figura 7.16: Tiempo de cifrado con curvas sobre Fp en PC (conﬁguración P3) 298 7. Resultados empíricos

Longitud del cuerpo ﬁnito Fp (bits) 128 160 192 16 512.54 543.31 613.50 32 515.09 544.96 615.51 48 527.88 564.82 634.21 64 535.06 565.95 635.42 80 536.18 567.78 637.21 96 537.58 568.58 639.29 112 551.27 588.09 657.83 128 558.10 588.98 658.56 144 558.89 590.59 660.66

Longitud mensaje (bytes) 160 560.78 591.69 668.73

Cuadro 7.15: Tiempo de cifrado con curvas sobre Fp en JCOP J3A e interfaz sin contactos (conﬁguración P3)

Figura 7.17: Tiempo de cifrado con curvas sobre Fp en JCOP J3A e interfaz sin contactos (conﬁguración P3) 7.5. Tiempo de descifrado 299

7.5. Tiempo de descifrado

El procedimiento seguido para obtener las mediciones del tiempo de descifrado tiene las mismas características generales que el empleado para el proceso de cifrado. El punto de medición de los tiempos inicial y ﬁnal en la versión PC son equivalentes a los del proceso de cifrado, y de forma análoga, la medición en la implementación Java Card se ha realizado mediante la misma aplicación Java SE de línea de comandos, la cual se encarga de enviar y recibir las APDU apropiadas. Continuando con el objetivo de facilitar la lectura, el tiempo de cifrado se encuentra expresado en todas las ﬁguras y cuadros incluidos en los siguientes apartados en milisegundos, aunque no se indique expresamente.

7.5.1. Tiempo de descifrado en PC con la conﬁguración M1

Al igual que con la configuración P1, únicamente la versión de Java para PC dispone de las funcionalidades criptográficas requeridas por la configuración M1. El Cuadro 7.16 y la Figura 7.18 muestran el tiempo de descifrado de esta versión.

Longitud del cuerpo ﬁnito F2m (bits) 113 131 163 193 233 239 283 409 571 16 28.9 38.5 62.6 91.8 103.4 112.1 132.8 226.1 356.7 32 29.0 38.3 61.9 90.8 103.6 111.7 132.9 226.4 361.2 48 28.7 38.1 66.4 90.2 103.7 112.1 132.9 228.9 361.5 64 28.9 38.1 66.3 90.0 103.2 113.4 132.8 227.9 359.5 80 29.3 37.9 66.3 89.0 103.8 110.8 132.8 227.2 358.0 96 29.3 38.5 66.1 87.9 103.0 110.7 132.7 228.2 358.7 112 29.4 37.9 65.6 87.7 103.7 110.5 132.6 228.7 358.7 128 29.3 38.3 65.8 88.0 103.8 110.3 132.6 227.8 366.4 144 29.5 38.3 66.2 88.9 104.4 111.0 132.6 227.7 363.8 160 29.4 38.4 66.4 89.4 104.1 111.8 132.7 228.2 364.5

Longitud del mensaje (bytes) 176 29.7 38.9 66.5 89.8 104.5 111.6 132.8 228.2 364.6

Cuadro 7.16: Tiempo de descifrado con curvas sobre F2m en PC (conﬁguración M1)

7.5.2. Tiempo de descifrado en PC y Java Card con la conﬁ- guración M2

La conﬁguración M2 ha sido probada tanto en la versión PC de ECIES como en la implementación Java Card desarrollada para la tarjeta JCOP 41. El Cuadro 7.17 y la Figura 7.19 muestran los resultados de la versión PC, el Cuadro 7.18 y la Figura 7.20 300 7. Resultados empíricos

Figura 7.18: Tiempo de descifrado con curvas sobre F2m en PC (conﬁguración M1) presentan el tiempo de descifrado utilizando tarjetas JCOP 41 y la interfaz sin contactos, y ﬁnalmente 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 conﬁguración P1

Puesto que la configuración P1 utiliza unas funciones criptográficas que no están disponibles en la tarjeta Java Card, esta configuración ha sido utilizada únicamente en la implementación PC de ECIES. El Cuadro 7.20 y la Figura 7.22 muestran los resultados de la medición del proceso de descifrado en la versión de ECIES para PC.

7.5.4. Tiempo de descifrado en PC y Java Card con la conﬁ- guración P2

La conﬁguración P2 ha sido probada tanto en la versión PC de ECIES como en la implementación Java Card desarrollada para la tarjeta JCOP J3A. El Cuadro 7.21y la Figura 7.23 muestran los resultados de la versión PC, mientras que el Cuadro 7.22 y la Figura 7.24 presentan el tiempo de descifrado utilizando tarjetas JCOP J3A. 7.5. Tiempo de descifrado 301

Longitud del cuerpo ﬁnito F2m (bits) 113 131 163 193 16 25.68 34.18 52.64 76.79 32 25.19 33.91 52.85 76.98 48 25.14 34.25 52.95 77.74 64 25.16 33.98 52.71 77.65 80 25.47 35.01 52.97 77.56 96 25.22 34.80 52.81 77.82 112 25.84 34.92 53.04 77.36 128 25.68 35.25 52.97 77.16 144 25.75 35.35 53.03 76.71 160 25.38 35.36 53.35 76.84

Longitud del mensaje (bytes) 176 25.45 35.99 53.93 76.76

Cuadro 7.17: Tiempo de descifrado con curvas sobre F2m en PC (conﬁguración M2)

Figura 7.19: Tiempo de descifrado con curvas sobre F2m en PC (conﬁguración M2) 302 7. Resultados empíricos

Longitud del cuerpo ﬁnito F2m (bits) 113 131 163 193 16 197.74 203.12 212.04 222.08 32 198.83 204.34 213.33 223.20 48 208.54 213.66 222.49 232.61 64 215.00 220.45 229.37 239.37 80 215.61 220.65 229.50 239.59 96 216.64 221.94 230.89 241.15 112 225.60 230.63 239.70 249.49 128 232.63 237.81 246.80 256.74 144 233.31 238.58 247.46 257.38 160 234.46 239.58 248.60 258.62

Longitud del mensaje (bytes) 176 244.41 249.53 258.53 268.34

Cuadro 7.18: Tiempo de descifrado con curvas sobre F2m en JCOP 41 e interfaz sin contactos (conﬁguración M2)

Figura 7.20: Tiempo de descifrado con curvas sobre F2m en JCOP 41 e interfaz sin contactos (conﬁguración M2) 7.5. Tiempo de descifrado 303

Longitud del cuerpo ﬁnito F2m (bits) 113 131 163 193 16 223.78 228.21 236.18 245.19 32 239.00 243.50 251.47 260.57 48 257.95 262.37 270.15 279.39 64 273.21 277.62 285.54 294.63 80 288.56 292.12 300.84 310.06 96 304.13 308.53 316.22 325.14 112 323.23 327.38 335.59 344.07 128 338.22 342.64 350.69 359.56 144 353.64 358.06 366.12 374.88 160 368.92 373.29 381.45 390.04

Longitud del mensaje (bytes) 176 387.98 392.21 400.50 408.76

Cuadro 7.19: Tiempo de descifrado con curvas sobre F2m en JCOP 41 e interfaz con contactos (conﬁguración M2)

Figura 7.21: Tiempo de descifrado con curvas sobre F2m en JCOP 41 e interfaz con contactos (conﬁguración M2) 304 7. Resultados empíricos

Longitud del cuerpo ﬁnito Fp (bits) 112 128 160 192 224 256 384 521 16 24.99 25.57 42.37 56.10 76.80 82.63 144.21 230.38 32 25.79 25.93 41.95 57.06 76.97 82.83 144.59 231.94 48 25.73 26.14 41.37 56.43 76.84 82.67 144.26 229.00 64 25.80 26.08 40.97 55.51 76.67 82.60 144.10 228.36 80 25.82 26.28 40.67 55.49 74.30 82.90 145.54 227.93 96 25.66 26.26 38.96 55.36 74.54 82.99 148.35 228.80 112 25.69 26.26 69.43 55.34 74.72 82.31 148.89 227.63 128 25.97 26.12 39.59 56.15 74.13 84.72 148.56 227.62 144 25.66 26.21 39.83 56.05 74.19 84.95 148.72 228.39 160 25.95 26.40 40.34 55.96 74.34 84.25 148.32 230.85

Longitud del mensaje (bytes) 176 25.93 26.66 40.11 56.07 74.42 85.41 149.38 228.95

Cuadro 7.20: Tiempo de descifrado con curvas sobre Fp en PC (conﬁguración P1)

Figura 7.22: Tiempo de descifrado con curvas sobre Fp en PC (conﬁguración P1) 7.5. Tiempo de descifrado 305

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

Longitud del mensaje (bytes) 176 25.90 40.12 57.22

Cuadro 7.21: Tiempo de descifrado con curvas sobre Fp en PC (conﬁguración P2)

Figura 7.23: Tiempo de descifrado con curvas sobre Fp en PC (conﬁguración P2) 306 7. Resultados empíricos

Longitud del cuerpo ﬁnito Fp (bits) 128 160 192 16 213.84 219.32 233.71 32 215.38 220.76 234.92 48 222.53 227.80 242.35 64 229.85 234.73 249.42 80 230.25 235.90 250.15 96 232.01 237.65 251.97 112 238.41 243.87 258.24 128 246.35 251.39 266.07 144 247.43 252.50 266.63 160 249.00 254.06 268.55

Longitud del mensaje (bytes) 176 256.57 261.46 275.85

Cuadro 7.22: Tiempo de descifrado con curvas sobre Fp en JCOP J3A e interfaz sin contactos (conﬁguración P2)

Figura 7.24: Tiempo de descifrado con curvas sobre Fp en JCOP J3A e interfaz sin contactos (conﬁguración P2) 7.5. Tiempo de descifrado 307

7.5.5. Tiempo de descifrado en PC y Java Card con la conﬁ- guración P3

La conﬁguración P3 ha sido igualmente probada en las versiones para PC y tarjetas JCOP J3A. El Cuadro 7.23 y la Figura 7.25 muestran los resultados de la versión PC, mientras que el Cuadro 7.24 y la Figura 7.26 presentan el tiempo de descifrado de mensajes de distinta longitud utilizando tarjetas JCOP J3A.

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

Longitud mensaje (bytes) 160 27.09 40.78 58.73

Cuadro 7.23: Tiempo de descifrado con curvas sobre Fp en PC (conﬁguración P3)

Longitud del cuerpo ﬁnito Fp (bits) 128 160 192 16 237.17 243.94 258.30 32 239.39 246.01 260.24 48 253.16 259.39 273.56 64 260.92 267.00 280.97 80 261.53 267.43 282.28 96 264.34 269.79 284.02 112 276.72 282.42 296.59 128 284.84 290.01 304.60 144 285.52 291.41 305.52

Longitud mensaje (bytes) 160 287.92 293.33 307.45

Cuadro 7.24: Tiempo de descifrado con curvas sobre Fp en JCOP J3A e interfaz sin contactos (conﬁguración P3) 308 7. Resultados empíricos

Figura 7.25: Tiempo de descifrado con curvas sobre Fp en PC (conﬁguración P3)

Figura 7.26: Tiempo de descifrado con curvas sobre Fp en JCOP J3A e interfaz sin contactos (conﬁguración P3) 7.6. Rendimiento comparado 309

7.6. Rendimiento comparado

El objetivo de este apartado es presentar algunas comparaciones de especial inte- rés, tomando como partida los datos obtenidos en las pruebas de cifrado y descifrado expuestas en los apartados anteriores. A ﬁn de analizar el rendimiento general de las curvas sobre cuerpos primos y binarios en una misma implementación, la Figura 7.27 muestra el tiempo medio de cifrado y descifrado de un mismo mensaje de 160 bytes de longitud para cada una de las curvas incluidas en las conﬁguraciones M1 y P1, aplicables exclusivamente a la versión de ECIES para PC.

Figura 7.27: Comparación del tiempo de ejecución en PC (conﬁguraciones M1 y P1)

A continuación 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 (Figu- ra 7.28), P2 (Figura 7.29) y P3 (Figura 7.30). Es importante tener en cuenta que, dada la escala utilizada en las figuras, para poder mostrar en el mismo gráfico los resultados de las implementaciones en PC y Java Card, los tiempos de cifrado y descifrado en PC se encuentran superpuestos en gran parte de su trazado. La Figura 7.31 muestra la comparación del tiempo de cifrado y descifrado empleado por las tarjetas JCOP 41 (con la configuración M2) y JCOP J3A (con la configuración P2) al gestionar un mensaje en claro de 64 bytes. De manera similar, la Figura 7.32 muestra la misma comparación utilizando un mensaje de 160 bytes. 310 7. Resultados empíricos

Figura 7.28: Comparación del tiempo de ejecución entre las versiones PC y Java Card (conﬁguración M2)

Figura 7.29: Comparación del tiempo de ejecución entre las versiones PC y Java Card (conﬁguración P2) 7.6. Rendimiento comparado 311

Figura 7.30: Comparación del tiempo de ejecución entre las versiones PC y Java Card (conﬁguración P3)

Es necesario tener en cuenta que, al tratarse de modelos con distintas versiones del sistema operativo JCOP (sobre las que se han cargado applets diferentes, aunque similares), y dado que no ha sido posible acceder a toda la información técnica de estas tarjetas por tratarse de datos conﬁdenciales (descripción del sistema operativo JCOP, detalles de la implementación de las operaciones aritméticas sobre cuerpos primos y binarios, tipos de contramedidas implementadas para evitar ataques de canal lateral, etc.), no es posible determinar el motivo preciso de la diferencia de resultados. Sin embargo, aun con las limitaciones mencionadas, este estudio es interesante con el ﬁn de obtener una aproximación del rendimiento comparado de ambas tarjetas. 312 7. Resultados empíricos

Figura 7.31: Comparación del tiempo de ejecución en las tarjetas JCOP 41 (conﬁgura- ción M2) y JCOP J3A (conﬁguración P2) al cifrar un mensaje de 64 bytes

Figura 7.32: Comparación del tiempo de ejecución en JCOP 41 (conﬁguración M2) y JCOP J3A (conﬁguración P2) al cifrar un mensaje de 160 bytes Capítulo 8

Conclusiones, aportaciones y trabajo futuro

Resumen del capítulo Este capítulo presenta las conclusiones derivadas del estudio e imple- mentación del esquema de cifrado ECIES y de los resultados obtenidos mediante las pruebas con las versiones desarrolladas para PC y Java Card. De manera adicional, se describen las aportaciones realizadas por esta Tesis, tanto en forma de artículos y presentaciones en congresos como de soluciones ideadas para evitar las distintas limitaciones detectadas. Por último, se incluyen las posibles líneas de trabajo que podrían seguirse como continuación de esta Tesis.

8.1. Conclusiones

Tal como se ha comentado en diversos apartados, ECIES es un esquema de cifrado que dispone de múltiples opciones de implementación. En la presente Tesis Doctoral se ha estudiado en profundidad el protocolo de cifrado ECIES y se han desarrollado varias aplicaciones (para PC y tarjetas JCOP 41 y JCOP J3A) con el objetivo de realizar pruebas en estas tres plataformas hardware con cinco conﬁgu- raciones diferentes (M1, M2, P1, P2 y P3). Como resultado del estudio previo realizado y de las pruebas efectuadas es posible presentar las conclusiones detalladas en los siguientes apartados, las cuales están agrupadas en función de los objetivos descritos en la Introducción.

313 314 8. Conclusiones, aportaciones y trabajo futuro

8.1.1. El esquema ECIES como estándar

A continuación se detallan las conclusiones a las que ha sido posible llegar respecto a la consideración del esquema ECIES como estándar:

1. El esquema de cifrado y descifrado ECIES se encuentra especiﬁcado en los estándares ANSI X9.63 [16], IEEE 1363a [109], ISO/IEC 18033-2 [136] y SECG SEC 1 [254]. Las características concretas de cada una de dichas versiones están descritas en §4.4y§4.5. Aunque las implementaciones de los cuatro estándares mencionados se basan, en última instancia, en el esquema de cifrado DHIES [9, 10], existe una gran variedad en lo relativo a las funciones HASH, KA, KDF, ENC y MAC permitidas en cada estándar, así como en las características particulares (p. ej., el uso de parámetros opcionales, la interpretación de algunos elementos, etc.) incluidas en esas versiones de ECIES.

2. A partir de las características particulares de cada estándar, hemos construido 11 configuraciones genéricas (es decir, independientes de las funciones HASH, KA, KDF, ENC y MAC específicas utilizadas), de manera que cada una de ellas sea válida al menos en un estándar. Dichas configuraciones se encuentran descritas en §4.7.

3. De la revisión de las 11 configuraciones y de su aplicabilidad a cada estándar, se puede afirmar que existen dos configuraciones (C01 y C02) compatibles con las últimas versiones de los cuatro estándares mencionados. Dichas configuraciones tienen como elemento característico la utilización de la función XOR como algoritmo de cifrado simétrico. Como consecuencia de la existencia de esas configuraciones y de al menos una función específica permitida de forma común para cada una de las funciones HASH, KA, KDF, ENC y MAC, se puede concluir que ECIES es un esquema de cifrado que, a pesar de sus muchas opciones, permite ser implementado de manera compatible con los cuatro estándares analizados.

8.1.2. Conjunto de parámetros compatibles con todos los es- tándares

En relación al conjunto de parámetros compatibles con todos los estándares se pueden realizar las siguientes conclusiones:

1. Existen dos conﬁguraciones genéricas de ECIES compatibles con los cuatro estándares analizados, denominadas C01 y C02, y descritas en §4.7. 8.1. Conclusiones 315

2. Dichas versiones compatibles tienen como elemento característico la utilización de la función XOR como algoritmo de cifrado simétrico. Las diferencias entre ambas conﬁguraciones residen en la función HASH empleada, la función MAC, el uso de parámetros opcionales en la función MAC, o una combinación de los tres elementos citados.

3. A modo de ejemplo, se ha desarrollado una versión concreta compatible con los cuatro estándares utilizando una selección específica de funciones HASH, KA, KDF, ENC y MAC de entre las mostradas en el Cuadro 4.10. La versión así construida, denominada ECIES-4, constituye el Algoritmo 4.16. Sin embargo, es importante resaltar que la utilización de la función XOR como algoritmo de cifrado simétrico provoca determinados problemas de seguridad que, si se implementan las medidas necesarias para evitarlos y que permiten mantener la compatibilidad con los cuatro estándares, limitan la utilización del esquema ECIES, tal como se detalló en §4.9. Puesto que no existen más configuraciones compatibles con los cuatro estándares, la mejor solución consiste en utilizar una de las dos configuraciones compatibles con los tres estándares más recientes (C05 y C06), y que permiten desarrollar implementaciones de ECIES más seguras y flexibles en cuanto a su funcionalidad.

8.1.3. Desarrollo de la implementación de ECIES para PC

Las conclusiones que se derivan del desarrollo de la implementación de ECIES para plataformas PC son las siguientes:

1. El lenguaje de programación Java, uno de los más extendidos actualmente, permite la implementación de todas las funciones de la criptografía de curvas elípticas sin necesidad de utilizar bibliotecas (libraries) adicionales. Como ejemplo de ello, existen diversas bibliotecas criptográﬁcas, analizadas en §3.3, que incluyen funcionalidades de la ECC desarrolladas por empresas o grupos de programadores, siendo los ejemplos más conocidos Bouncy Castle, IAIK y FlexiProvider.

2. Las bibliotecas mencionadas, sin embargo, o no implementan ECIES o, en caso de hacerlo, no permiten utilizar todas las funciones y parámetros presentes en los estándares analizados. Debido a ello el autor de esta Tesis decidió desarrollar la versión de ECIES para PC implementando todas las clases necesarias para utilizar los algoritmos relacionados con la ECC y las operaciones aritmé- ticas, tanto para los puntos de las curvas elípticas como para los elementos de los cuerpos ﬁnitos. Esta opción ha permitido un grado de ﬂexibilidad superior, al ser posible incorporar cualquier algoritmo durante el propio desarrollo, aunque ha requerido 316 8. Conclusiones, aportaciones y trabajo futuro

un tiempo de desarrollo superior al de otras alternativas. El diagrama de clases de la aplicación puede consultarse en 5.2, mientras que la descripción funcional de la aplicación completa se encuentra en §5.3. Para mejorar la comprensión del proceso de cifrado y descifrado, se ha incluido en §6.8 un ejemplo de cada tipo de operación utilizando la aplicación desarrollada.

3. En cuanto a los algoritmos y características de ECIES incluidas en el desarrollo para PC, puesto que el objetivo principal de esa versión de ECIES consiste en poder realizar pruebas con distintas combinaciones de funciones y parámetros, además de las combinaciones M1, M2, P1, P2 y P3 (deﬁnidas en §7.2), se decidió incluir las funciones HASH, KA, KDF, ENC y MAC más habituales en los estándares analizados, así como las opciones que permiten diferenciar las conﬁguraciones descritas en §4.7.

8.1.4. Estudio de la eﬁciencia de la implementación PC

A continuación se presentan las conclusiones que se han podido obtener mediante las pruebas realizadas en PC con las conﬁguraciones M1, M2, P1, P2 y P3.

1. La sobrecarga añadida durante el proceso de cifrado, deﬁnida en esta Tesis como la diferencia entre la longitud del criptograma C y la longitud del mensaje en claro m, es irrelevante en las conﬁguraciones M1 y P1 para mensajes cuya longitud supere 500 bytes. Por el contrario, para mensajes cuyo tamaño sea menor de 500 bytes, y especialmente cuando la longitud es menor de 64 bytes, el factor de expansión (es decir, el cociente entre las longitudes de C y m) tiene un valor elevado. Esto implica que, a efectos de ancho de banda, ECIES es especialmente útil para cifrar mensajes de mediano y gran tamaño.

2. Dada una determinada curva, el tiempo de cifrado y descifrado es práctica- mente constante para todas las longitudes del mensaje a cifrar empleadas en las pruebas con las conﬁguraciones M1 y P1. Ello se debe a que el tiempo de procesamiento de las funciones HASH, ENC, y MAC apenas varía para las longitudes de mensajes utilizadas, siendo las operaciones con los puntos de la curva y los elementos del cuerpo ﬁnito 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 ﬁnitos respecto a las operaciones de cifrado simétrico.

4. El tiempo de cifrado y descifrado en la versión de ECIES para PC aumenta de manera más rápida que la longitud de las claves, tal como puede apreciarse en los Cuadros 8.1y 8.2, donde la interpretación de las columnas es la siguiente: Long. F2m y Long. Fp representan la longitud en bits de las curvas de trabajo definidas sobre cuerpos finitos binarios y primos, respectivamente; Ratio 1 indica la relación entre la longitud de la curva de trabajo y la longitud de la curva sect113r1 (Cuadro 8.1) o secp112r1 (Cuadro 8.2), medidas ambas 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 fun- ción del cuadro); la columna Descifrado contiene el tiempo de descifrado de un mensaje de 176 bytes de longitud para cada curva medido en milisegundos; finalmente Ratio 3 muestra la relación entre el tiempo de descifrado utilizando la curva de trabajo y el tiempo de cifrado con la curva sect113r1 o secp112r1 (dependiendo del cuadro).

Curva Long. F2m Ratio 1 Cifrado Ratio 2 Descifrado Ratio 3 sect113r1 113 1.00 28.34 1.00 29.7 1.00 sect131r1 131 1.16 36.26 1.28 38.9 1.31 sect163r1 163 1.44 59.67 2.11 66.5 2.24 sect193r1 193 1.71 82.53 2.91 89.8 3.02 sect233r1 233 2.06 102.31 3.61 104.5 3.52 sect239k1 239 2.11 105.54 3.72 111.6 3.75 sect283r1 383 3.39 129.96 4.59 132.8 4.47 sect409r1 409 3.62 225.53 7.96 228.2 7.68 sect571r1 571 5.05 368.50 13.00 364.6 12.28

Cuadro 8.1: Crecimiento del tiempo de cifrado y descifrado en PC (conﬁguración M1)

5. La implementación de la aritmética de curvas definidas sobre cuerpos Fp en PC es más eficiente que la implementación sobre cuerpos F2m . Esto se debe a la utilización de bases polinómicas en lugar de bases normales en la implemen- tación de las operaciones con cuerpos binarios. Las bases normales son más eficientes y permitirían obtener mejores resultados, pero su uso está restringido por las patentes expuestas en §2.6.9. 318 8. Conclusiones, aportaciones y trabajo futuro

Curva Long. Fp Ratio 1 Cifrado Ratio 2 Descifrado Ratio 3 secp112r1 112 1.00 23.55 1.00 25.93 1.00 secp128r1 128 1.14 24.12 1.02 26.66 1.03 secp160r1 160 1.43 39.77 1.69 40.11 1.55 secp192k1 192 1.71 53.96 2.29 56.07 2.16 secp224r1 224 2.00 69.88 2.97 74.42 2.87 secp256k1 256 2.29 79.33 3.37 85.41 3.29 secp384r1 384 3.43 143.07 6.07 149.38 5.76 secp521r1 521 4.65 228.08 9.68 228.95 8.83

Cuadro 8.2: Crecimiento del tiempo de cifrado y descifrado en PC (conﬁguración P1)

8.1.5. Desarrollo de la implementación de ECIES en tarjetas Java Card

Las conclusiones que se pueden extraer del proceso de desarrollo de los applets Java Card que implementan ECIES, denominados JCOP-M2, JCOP-P2 y JCOP-P3, son las siguientes:

1. El soporte actual a la criptografía de curva elíptica por parte de los grandes fabricantes de tarjetas inteligentes (Gemalto, Oberthur, G&D, etc.) es todavía escaso.

2. En el mercado existe una amplia gama de tarjetas JCOP (desarrolladas 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 más fiables, sería 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 sólo incluyen curvas construidas sobre cuerpos binarios.

4. Los fabricantes deben esforzarse en el futuro en implementar todas las curvas sobre cuerpos ﬁnitos incluidas en Java Card 3.0, especialmente aquellas de longitud 224, 256 y 384 bits deﬁnidas sobre cuerpos binarios. Estas longitudes serán paulatinamente más importantes según 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 función HMAC no está incluida en las tarjetas JCOP probadas. Aunque el desarrollo de la función HMAC apropiada no ha sido complejo, el rendimiento global mejoraría si dicha función fuera ejecutada a través de la llamada estándar al API Java Card. 6. Igualmente sería deseable que el API Java Card añadiera en el futuro la función KDF2, puesto que de hecho actualmente dicha API no incluye ninguna función KDF. 7. De manera equivalente sería recomendable que las tarjetas comerciales incor- poraran en el futuro próximo las modalidades con relleno del algoritmo AES definidas en Java Card 3.0, lo que evitaría la codificación de sistemas alternativos de relleno por parte de las aplicaciones que se comunican con la tarjeta inteligente.

8.1.6. Estudio de la eﬁciencia de la implementación Java Card

La siguiente lista recoge las conclusiones obtenidas gracias a las pruebas realizadas en tarjetas JCOP 41 con la conﬁguración M2 y en tarjetas JCOP J3A con las conﬁguraciones P2 y P3.

1. Los tiempos de cifrado y descifrado incluyen tanto el tiempo de transmisión (del lector a la tarjeta con la APDU de tipo comando, y de la tarjeta al lector con la APDU de tipo respuesta) como el tiempo de procesamiento realizado por la tarjeta, por lo que es necesario tener en cuenta este hecho al realizar comparaciones. 2. Las tarjetas JCOP 41, que permiten el envío de comandos mediante dos interfaces (con contactos y sin contactos) presentan un rendimiento diferente en función de la interfaz empleada. Aunque la falta de detalles técnicos sobre las tarjetas sólo permiten realizar suposiciones sobre este hecho, el motivo más probable podría ser la diferente frecuencia de la señal externa de reloj utilizada en ambas interfaces (4.8 MHz frente a 13.56 MHz), lo que genera que la uti- lización de la interfaz sin contactos ofrezca mejores resultados en las pruebas de cifrado y descifrado. 3. Además de las diferencias respecto al tiempo de cifrado y descifrado, la utiliza- ción de distintas interfaces produce comportamientos marcadamente distintos en la misma tarjeta. Si se observan los tiempos de cifrado para las tarjetas JCOP 41 en ambos casos (Figuras 7.11y 7.12), se puede comprobar que en la interfaz con contactos el comportamiento es prácticamente lineal, mientras que en la interfaz sin contactos el aumento del tiempo de cifrado se produce por escalones. 320 8. Conclusiones, aportaciones y trabajo futuro

De nuevo, con los datos disponibles sobre el modelo JCOP 41, únicamente se puede conjeturar que, a igualdad del resto de los factores, el comportamiento del coprocesador 3DES depende de la frecuencia de la señal externa de reloj. Los tiempos de descifrado muestran el mismo comportamiento en estas circunstancias (Figuras 7.20y 7.21).

4. La sobrecarga añadida durante el proceso de cifrado en las conﬁguraciones 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.7y 7.8, lo que implica que la transmisión de esos mensajes es poco eﬁciente 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.5y 8.6, donde el significado de las columnas es el siguiente: Long. Fp y Long. F2m representan la longitud en bits de las curvas definidas sobre cuerpos primos y binarios, respectivamente; Ratio 1 indica la relación entre la longitud de la curva de trabajo y la longitud de la curva sect113r1 (Cuadros 8.3y 8.4) o secp128r1 (Cuadros 8.5y 8.6), medidas ambas longitudes en bits; la columna Cifrado contiene el tiempo de cifrado para cada curva medido en milisegundos; Ratio 2 expresa el cociente entre el tiempo de cifrado de un mensaje de 176 bytes utilizando la curva de trabajo y el tiempo de cifrado con la curva sect113r1 o secp128r1 (en función del cuadro); la columna Descifrado contiene el tiempo de descifrado para cada curva medido en milisegundos; finalmente Ratio 3 muestra la relación 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. F2m Ratio 1 Cifrado Ratio 2 Descifrado Ratio 3 sect113r1 113 1.00 341.52 1.00 244.41 1.00 sect131r1 131 1.16 358.64 1.05 249.53 1.02 c2pnb163v1 163 1.44 384.40 1.13 258.53 1.06 sect193r1 193 1.70 418.98 1.23 267.34 1.09

Cuadro 8.3: Crecimiento del tiempo de cifrado y descifrado en JCOP 41 e interfaz sin contactos (conﬁguración M2)

Este comportamiento es el contrario que el observado en la versión para PC, donde el tiempo de cifrado y descifrado aumenta más rápidamente que la longitud de las curvas empleadas. Una posible explicación de este resultado lo constituye la utilización del criptoprocesador de clave pública en las tarjetas JCOP, lo que permite que la diferencia en rendimiento entre operaciones realizadas con una u otra curva sea en proporción más pequeña que la medida al 8.1. Conclusiones 321

Curva Long. F2m Ratio 1 Cifrado Ratio 2 Descifrado Ratio 3 sect113r1 113 1.00 528.36 1.00 387.98 1.00 sect131r1 131 1.16 548.35 1.04 392.21 1.01 c2pnb163v1 163 1.44 571.23 1.08 400.50 1.03 sect193r1 193 1.70 640.54 1.21 408.76 1.05

Cuadro 8.4: Crecimiento del tiempo de cifrado y descifrado en JCOP 41 e interfaz con contactos (conﬁguración M2)

Curva Long. Fp Ratio 1 Cifrado Ratio 2 Descifrado Ratio 3 secp128r1 128 1.00 529.22 1.00 256.57 1.00 secp160r1 160 1.25 561.74 1.06 261.46 1.02 P-192 192 1.5 636.95 1.20 275.85 1.08

Cuadro 8.5: Crecimiento del tiempo de cifrado y descifrado en JCOP J3A e interfaz sin contactos (conﬁguración 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 tecnológi- cas propias de arquitecturas de 8 bits, comparativamente está más optimizado para la aritmética de puntos de la curva y de elementos del cuerpo ﬁnito que la CPU del PC.

6. El tiempo de descifrado en las tarjetas Java Card es sensiblemente inferior al tiempo de cifrado. Esto podría deberse, a falta de más datos sobre el funcionamiento de las tarjetas y sus coprocesadores, a que en la operación de cifrado se ejecuta un paso adicional relacionado con la aritmética de puntos de la curva y elementos del cuerpo ﬁnito (la generación pseudoaleatoria del par de claves temporal) que no es necesario durante el descifrado.

7. Mientras que el tiempo de descifrado para longitudes de clave equivalentes es similar en las tarjetas JCOP 41 y JCOP J3A cuando ambas utilizan la interfaz sin contactos, en cambio el tiempo de cifrado es claramente superior en las tarjetas JCOP J3A en condiciones similares. Puesto que los tiempos de

Curva Long. Fp Ratio 1 Cifrado Ratio 2 Descifrado Ratio 3 secp128r1 128 1.00 560.78 1.00 287.92 1.00 secp160r1 160 1.25 591.69 1.06 293.33 1.02 P-192 192 1.5 668.73 1.19 307.45 1.07

Cuadro 8.6: Crecimiento del tiempo de cifrado y descifrado en JCOP J3A e interfaz sin contactos (conﬁguración P3) 322 8. Conclusiones, aportaciones y trabajo futuro

descifrado en ambos casos son similares, no es posible atribuir la diferencia al producto escalar realizado durante el procedimiento Diffie-Hellman (ya que se realiza tanto en el proceso de cifrado como de descifrado), lo que deja como posible razón para este hecho la menor optimización del proceso de generación del par de claves aleatorias en Fp respecto a F2m . 8. Debido a la naturaleza de la comunicación mediante comandos APDU entre una aplicación externa y una tarjeta inteligente, y a las características crip- tográficas implementadas en las tarjetas JCOP analizadas, si se desea que la respuesta a una petición de cifrado o descifrado esté contenida en una única APDU de respuesta, es necesario limitar la longitud máxima de los mensajes en claro a 176 bytes en el caso de las configuraciones M2 y P2, y 160 bytes para la configuración P3. La diferencia se debe a que la configuración P3 genera un código MAC de 32 bytes, mientras que el código generado en las implementaciones P2 y M2 es de 20 bytes. Esta longitud podría extenderse en el caso de que las tarjetas JCOP permitieran representar los puntos de una curva elíptica de forma comprimida.

9. La utilización de mensajes en claro de longitudes mayores a las expuestas en el punto anterior provocaría un deterioro del rendimiento de la implementación. Por una parte, sería necesario intercambiar varias APDU para poder recuperar la totalidad del criptograma (o del mensaje en claro en la operación de 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 utilización de mensajes de excesivo tamaño provocaría que las variables tuvieran que ser almacenadas en memoria EEPROM en lugar de en memoria RAM, siendo la memoria EEPROM notablemente más lenta que la memoria RAM. Como ejemplo de esta afirmación, la primera implementación de la versión JCOP-M2, que guardaba todas las variables en memoria EEPROM en lugar de en memoria RAM, ofrecía un tiempo medio (teniendo en cuenta las cuatro curvas implementadas) de cifrado de aproximadamente 2 segundos utilizando la interfaz con contactos, en lugar del tiempo medio de aproximadamente 500 milisegundos necesario en la versión final de la configuración M2 que almacena todas las variables en memoria RAM. En esta última versión, la cantidad de memoria RAM libre tras la asignación de todas las variables es de 16 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 ﬁja la longitud de la clave y aumentando la longitud del mensaje en claro, se puede aﬁrmar que en la mayoría de los casos de cifrado, el incremente relativo al pasar de un mensaje de 16 bytes a otro de 160 bytes es de aproximadamente el 10 %, tal como puede observarse en los Cuadros 8.7y 8.8 (relativos 8.1. Conclusiones 323

a las tarjetas JCOP 41 utilizando la interfaz sin contactos y con contactos, respectivamente), y los Cuadros 8.9y 8.10 (referidos a las tarjetas JCOP J3A utilizando las conﬁguraciones P2 y P3, respectivamente). La única excepción a esta aﬁrmación la consitutuyen las pruebas realizadas con tarjetas JCOP 41 empleando la interfaz con contactos, donde el incremento es mucho mayor.

Cif. 16 Cif. 160 Ratio 1 Descif. 16 Descif. 160 Ratio 2 sect113r1 296.74 331.82 1.12 197.74 234.46 1.20 sect131r1 314.65 350.70 1.11 203.12 239.58 1.18 c2pnb163v1 332.71 368.74 1.11 212.04 248.60 1.17 Curva sect193r1 367.64 403.70 1.10 222.08 258.62 1.16

Cuadro 8.7: Incremento relativo del tiempo de ejecución en JCOP 41 e interfaz sin contactos (conﬁguración M2)

Cif. 16 Cif. 160 Ratio 1 Descif. 16 Descif. 160 Ratio 2 sect113r1 363.51 509.34 1.40 223.78 368.92 1.65 sect131r1 384.52 529.41 1.38 228.21 373.29 1.64 c2pnb163v1 407.35 552.31 1.35 236.18 381.45 1.62 Curva sect193r1 446.56 591.55 1.32 245.19 390.04 1.59

Cuadro 8.8: Incremento relativo del tiempo de ejecución en JCOP 41 e interfaz con contactos (conﬁguración M2)

Cif. 16 Cif. 160 Ratio 1 Des. 16 Des. 160 Ratio 2 secp128r1 481.55 522.50 1.08 213.84 249.00 1.16 secp160r1 518.24 554.08 1.07 219.32 254.06 1.16

Curva P-192 587.76 623.73 1.06 233.71 268.55 1.15

Cuadro 8.9: Incremento relativo del tiempo de ejecución en JCOP J3A e interfaz sin contactos (conﬁguración P2)

Respecto al proceso de descifrado es posible hacer una aﬁrmación equivalente, ya que el incremento en la mayoría de los casos es aproximadamente del 20 %, con la excepción de nuevo de las tarjetas JCOP 41 y la interfaz con contactos, donde el incremento es ciertamente superior.

11. Debido a la falta de las clases relacionadas con la criptografía de curvas elíp- ticas en tarjetas sin coprocesador PKI, no ha sido posible determinar el rendimiento de las aplicaciones sin utilizar dicho criptoprocesador. Sin embargo, debido a la naturaleza de las operaciones a realizar (multiplicación escalar de 324 8. Conclusiones, aportaciones y trabajo futuro

Cif. 16 Cif. 160 Ratio 1 Descif. 16 Descif. 160 Ratio 2 secp128r1 512.54 560.78 1.09 237.17 287.92 1.21 secp160r1 543.31 591.69 1.09 243.94 293.33 1.20

Curva P-192 613.50 668.73 1.09 253.16 307.46 1.21

Cuadro 8.10: Incremento relativo del tiempo de ejecución en JCOP J3A e interfaz sin contactos (conﬁguración P3)

un punto de la curva, generación pseudoaleatoria de un punto de la curva, etc.), es razonable suponer que el rendimiento sin coprocesador se degradaría de manera muy marcada. La falta de tarjetas inteligentes con soporte ECC pero sin criptoprocesador PKI podría ser un argumento más a favor de esta suposición.

8.1.7. Comparativa entre las versiones PC y Java Card

A continuación se resumen las conclusiones derivadas de la comparación entre las implementaciones de ECIES para PC y Java Card:

1. Como era de esperar, el rendimiento de la implementación en tarjetas Java Card con un procesador de 8 bits, coprocesador criptográﬁco y memoria RAM limitada es sensiblemente inferior al de la versión 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 aplicación. 2. Dada la decisión de realizar pruebas con mensajes con una longitud máxima de 176 bytes (160 bytes en las pruebas con las tarjetas JCOP J3A y la conﬁ- guración P3), al no existir dicha limitación para la version PC, el número de pruebas en las que es posible establecer una comparación entre las versiones PC y Java Card es pequeño comparado con el número de pruebas realizadas en la versión PC. 3. Mientras que el tiempo de cifrado y descifrado es prácticamente el mismo en la versión PC para una misma curva y longitudes del mensaje inferiores a 176 bytes, tanto en las tarjetas JCOP 41 como en JCOP J3A el tiempo de cifrado es superior al de descifrado.

8.1.8. Conﬁguración de ECIES resistente a ataques

Una vez analizada la seguridad de ECIES en §4.9, las conclusiones que se pueden obtener sobre la resistencia a ataques de las distintas versiones de ECIES son las siguientes: 8.2. Aportaciones 325

1. Las conﬁguraciones C01 y C02 compatibles con los cuatro estándares son susceptibles de sufrir ataques debido a la utilización de la función XOR como algoritmo de cifrado simétrico.

2. De las tres soluciones al problema de la maleabilidad descritas en §4.9.1.2, la única que es posible implementar manteniendo la compatibilidad con los cuatro estándares consiste en ﬁjar la longitud de los mensajes a cifrar, tal como se ha comentado en §8.1.1.

3. Puesto que con la única solución compatible con todos los estándares la funcionalidad de ECIES queda seriamente limitada, se hace necesario seleccionar otra configuración como punto de partida para cualquier implementación segura de ECIES. Dado que exceptuando C01 y C02 no existen más configuraciones compatibles con los cuatro estándares, las candidatas lógicas son aquellas configuraciones recogidas en los tres estándares más recientes, que resultan ser C05 y C06. Al igual que sucedió en §4.8, es posible definir a partir de las configuraciones C05 y C06 múltiples versiones compatibles con dichas configuraciones, y que se diferencien en la función HASH, la función MAC, el uso de argumentos opcionales en la función de autenticación o una combinación de esos tres elementos.

4. El Algoritmo 4.17 define una versión del esquema de cifrado, denominada ECIES-3, que constituye una de las posibles variantes compatibles con las 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 función resumen SHA-256, la función de derivación de claves KDF2 y la función de autenticación HMAC-SHA-256.

8.2. Aportaciones

La presente Tesis doctoral incluye la especificación y desarrollo de una imple- mentación software de ECIES, para lo cual se ha creado una versión utilizando Java SE para entornos PC, y otra versión (con tres variantes) para tarjetas Java Card. Hasta donde el autor de esta Tesis conoce, se trata de la primera implementación del protocolo ECIES en ambas plataformas, permitiendo además en la versión para PC la selección de manera dinámica de la configuración específica a utilizar por el usuario. Como era predecible, durante el desarrollo el autor ha encontrado diversas dificultades y obstáculos. En primer lugar, los estándares que incluyen ECIES como algoritmo de cifrado presentan un número de opciones muy elevado, estando en 326 8. Conclusiones, aportaciones y trabajo futuro algunos casos dichas opciones desaconsejadas en estándares posteriores debido al descubrimiento de alguna vulnerabilidad. Ello ha provocado que la tarea de compa- ración y selección de las opciones a implementar haya sido especialmente laboriosa en comparación con la implementación de otros estándares criptográficos. El segundo obstáculo digno de mención ha sido la enorme dificultad para conseguir tarjetas Java Card que implementen criptografía de curva elíptica. Ninguno de los principales fabricantes de tarjetas (Gemalto, Oberthur, G&D, etc.) disponían de productos comerciales que incluyeran primitivas para trabajar con ECC en el 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 obtención de dichas tarjetas no fue sencilla. Debido a la compra de la línea de productos JCOP por parte de NXP en 2008, a pesar de que NXP ha creado nuevas versiones de las tarjetas JCOP en los últimos años, debido a limitaciones comerciales las tiendas de electrónica de internet sólo pueden comercializar las tarjetas JCOP originales de IBM, como por ejemplo el modelo JCOP 41 utilizado en esta Tesis y que tiene implementada la versión 2.2.1 del sistema operativo JCOP. Aunque esta tarjeta implementa funciones ECC sobre cuerpos binarios, al tratarse de tarjetas con casi 7 años de antigüedad no disponían de otros algoritmos como AES o SHA-256. Gracias a la colaboración con NXP, fue posible acceder a las nuevas tarjetas J3A con sistema operativo JCOP v2.4.1. Estas tarjetas, además de los algoritmos mencionados, implementan las funciones ECC sobre cuerpos finitos primos, por lo que gracias a este producto ha sido posible realizar una comparación más amplia de ECIES con sendas versiones Java Card para cuerpos primos y binarios. El trabajo realizado en las sucesivas etapas de esta Tesis Doctoral ha permitido dar a conocer parte de la investigación mediante presentaciones en congresos y artículos en revistas especializadas, contribuciones todas ellas aceptadas tras las procedentes revisiones ciegas por pares. En este sentido, las aportaciones realizadas han sido las siguientes:

∙ Elliptic Curve Criptography: Java implementation issues [81]: presentación en la 39th IEEE International Carnahan Conference on Security Technology (ICCST) celebrado en Las Palmas de Gran Canaria en octubre de 2005, siendo publicado en las actas del congreso.

∙ Estado del arte de las implementaciones Java de criptografía de curva elíptica [82]: presentación en el I Simposio sobre Seguridad Informática dentro del I Congreso Español de Informática (CEDI) celebrado en Granada en septiembre de 2005, junto con la publicación en las actas del congreso.

∙ Sobre la clasificación de curvas hiperelípticas de género 2 definidas en cuerpos finitos [102]: publicación en las actas del I Simposio sobre Seguridad Infor- 8.3. Trabajo futuro 327

mática dentro del I Congreso Español de Informática (CEDI) celebrado en Granada en septiembre de 2005.

∙ Elliptic Curve Cryptography. Java platform implementations [83]: presentación en la 23rd International Conference for Automation of Engineering and Re- search (SAER-2009) - International Conference on Information Technologies (InfoTech-2009) celebrado en Varna (Bulgaria) en septiembre de 2009, junto con la publicación en las actas del congreso. Este mismo artículo fue publicado posteriormente en el número 4 del International Journal on Information Techonologies & Security [84].

∙ A Java implementation of the Elliptic Curve Integrated Encryption Scheme [85]: presentación en el 2010 International Conference on Security & Manage- ment (SAM) celebrado en Las Vegas en julio de 2010, siendo publicado en las actas del congreso de manera adicional.

∙ A comparison of the standardized versions of ECIES [86]: publicación en las actas del 6th International Conference on Information Assurance and Security (IAS), celebrado en Atlanta en agosto de 2010.

∙ A survey of the elliptic curve integrated encryption scheme [90]: publicado en el volumen 2 (número 2) de la revista Journal of Computer Science and Engineering en agosto de 2010.

∙ Security and practical considerations when implementing the Elliptic Curve Integrated Encryption Scheme [87]: enviado para su publicación en la revista Journal of Systems and Software (actualmente en estado de revisión).

∙ Performance evaluation of the Elliptic Curve Integrated Encryption Scheme implemented in PC and Java Card [88]: enviado para su publicación en la revista Computers & Mathematics with Applications (actualmente en estado de revisión).

∙ Java Card implementation of the Elliptic Curve Integrated Encryption Scheme using prime and binary ﬁnite ﬁelds [89]: enviado para su publicación en la revista International Journal of Information Security (actualmente en estado de revisión).

8.3. Trabajo futuro

El trabajo efectuado en esta Tesis sugiere la posibilidad de continuar algunas de las líneas de investigación desarrolladas e incluso iniciar otras nuevas asociadas a aspectos que, aunque estén situados fuera de los objetivos de la presente Tesis, se encuentran relacionados con los temas tratados. 328 8. Conclusiones, aportaciones y trabajo futuro

∙ Respecto a la implementación en PC de ECIES, las operaciones aritméticas de los cuerpos Fp y F2m podrían optimizarse a fin de aumentar la velocidad de las operaciones de cifrado y descifrado. En concreto, una posible mejora con- sistiría en utilizar coordenadas homogéneas y mixtas en lugar de únicamente coordenadas afines en las operaciones relacionadas con los puntos de una curva elíptica, puesto que dependiendo de la operación (suma de puntos, multiplica- ción de un punto por un escalar, etc.) cada tipo de coordenadas requiere un esfuerzo computacional diferente, siendo necesario analizar qué combinación de tipos de coordenadas sería más eficiente para las operaciones de cifrado y descifrado.

∙ Una funcionalidad que se podría añadir a la implementación en PC (no así a la implementación en tarjetas inteligentes, por los requisitos de procesamiento necesarios) consiste en la implementación de los algoritmos incluidos en los estándares para la generación aleatoria de curvas elípticas, así como la función necesaria para contar los puntos de una curva elíptica, incluyendo las opciones pertinentes en la interfaz del programa para que un usuario pudiera generar aleatoriamente una curva en función de los parámetros introducidos por dicho usuario (tamaño del cuerpo ﬁnito, tipo de curva, etc.) y posteriormente obtener el cardinal de dicha curva. Sería necesario para ello comparar los algoritmos existentes, principalmente los desarrollados por Schoof [238, 239], Atkins [22], Elkies [70] y Satoh [236].

∙ En cuanto las implementaciones en tarjetas inteligentes, los applets desarrollados están optimizados para el cifrado y descifrado de mensajes cuya longitud esté limitada a una única APDU. Puesto que una aplicación comercial de ECIES podría requerir el cifrado y descifrado de datos de mayor longitud, se- ría necesario rediseñar los applets con el objetivo de que pudieran gestionar volúmenes de datos mayores sin que su rendimiento se viera penalizado, para lo que es imprescindible incrementar la reutilización de las variables de 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 elípticas, ECDSA, se encuentra más extendido que el protocolo de cifrado, ECIES, su implementa- ción resulta menos interesante, ya que incluso en Java Card existen primitivas para utilizar ECDSA. Sin embargo, lo que no se encuentra implementado son las firmas no estándares, es decir, las firmas delegadas [162, 273], múltiples [160, 242] o en nombre de un grupo [19, 20]. Una nueva línea de investigación consistiría en comprobar la viabilidad, y en su caso realizar la implementación, de dichos esquemas no estándares de firma en tarjetas inteligentes.

∙ Igualmente interesante sería realizar un estudio sobre la resistencia a ataques de canal lateral de las implementaciones realizadas sobre las tarjetas JCOP 8.3. Trabajo futuro 329

41 y JCOP J3A, utilizando para ello el material adecuado (equipos láser, de implantación iónica, etc.).

∙ Por último, en función de la disponibilidad en el mercado de otras tarjetas Java Card que implementen funciones ECC, sería recomendable comparar el 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.

Notación

0x Prefijo que identifica las cadenas binarias hexadecimales 2 A (F) Plano afín sobre el cuerpo F a Elemento del cuerpo F que define la curva E b Elementos del cuerpo F que define la curva E c Mensaje cifrado C Criptograma Δ Discriminante de una curva elíptica

C Diferencia entre la longitud del criptograma y el mensaje en claro usan- do la conﬁguración C E Curva elíptica

E(F) Curva elíptica deﬁnida sobre el cuerpo F EK Clave de cifrado

F Cuerpo ﬁnito, equivalente a Fq

Fp Cuerpo ﬁnito primo

F2m Cuerpo ﬁnito binario

f(x) Polinomio irreducible de grado m que deﬁne la base polinómica de F2m G Punto de la curva que actúa como generador g Género de una curva algebraica ℎ Cofactor de la curva k1 Primer exponente del polinomio reductor f(x)

331 332 Notación

k2 Segundo exponente del polinomio reductor f(x) k3 Tercer exponente del polinomio reductor f(x)

m Número entero que especifica el cuerpo finito F2m m Mensaje en claro sin cifrar MK Clave MAC n Número primo que representa el orden del punto G O Punto en el infinito 2 P (F) Plano proyectivo sobre el cuerpo F P Representación binaria del punto P P Punto de la curva E con coordenadas expresadas indistintamente como (Px,Py) o (xP , yP )

p Número primo que especiﬁca el cuerpo ﬁnito Fp

q Número de elementos del cuerpo Fq

Px Primera coordenada del punto P , equivalente a xP

Py Segunda coordenada del punto P , equivalente a yP P Conjunto de parámetros que caracterizan la curva E u Clave privada del usuario U U Clave pública del usuario U U Usuario que envía el criptograma v Clave privada del usuario V V Clave pública del usuario V V Usuario que recibe el criptograma ⌈⌉ Función techo Glosario

3FF 3rd Form Factor 3GPP 3rd Generation Partnership Project ABS Acrilonitrilo Butadieno Estireno ACCA Adaptive Chosen Ciphertext Attack ACE Advanced Cryptographic Engine ACPA Adaptive Chosen Plaintext Attack AES Advanced Encryption Standard AMS American Mathematical Society ANSI American National Standards Institute APDU Application Protocol Data Unit API Application Programming Interface ASCII American Standard Code for Information Interchange ASN.1 Abstract Syntax Notation One ATM Automated Teller Machine ATR Answer to Reset AWT Abstract Window Toolkit BCD Binary-Coded Decimal BER Basic Encoding Rules BSI Bundesamt für Sicherheit in der Informationstechnik (Federal Of- ﬁce for Security)

333 334 Glosario

CAP Converted Applet CBC Cipher-Block Chaining CCA Chosen Ciphertext Attack CER Canonical Encoding Rules CLA Class CLK Clock CMOS Complementary Metal-Oxide Semiconductor CMS Cryptographic Message Syntax COA Ciphertext-Only Attack CPA Chosen Plaintext Attack CPU Central Processing Unit CRL Certificate Revocation List CRT Chinese Remainder Theorem CTR Counter DEM Data Encapsulation Mechanism DER Distinguished Encoding Rules DES Data Encryption Standard DHAES Diffie-Hellman Augmented Encryption Scheme DH Diffie-Hellman DHC Diffie-Hellman with Cofactor DHIES Diffie-Hellman Integrated Encryption Scheme DHP Diffie-Hellman Problem DLAES Discrete Logarithm Augmented Encryption Scheme DLP Discrete Logarithm Problem DOI Document Object Identifier DSA Digital Signature Algorithm ECC Elliptic Curve Cryptography ECDH Elliptic Curve Diffie-Hellman ECDLP Elliptic Curve Discrete Logarithm Problem Glosario 335

ECDSA Elliptic Curve Digital Signature Algorithm ECIES Elliptic Curve Integrated Encryption Scheme ECMQV Elliptic Curve Menezes-Qu-Vanstone EEPROM Electrically Erasable and Programmable Read Only Memory EPROM Erasable Programmable Read Only Memory ETSI European Telecommunications Standards Institute FRAM Ferroelectric Random-Access Memory GDLP Generalized Discrete Logarithm Problem GND Ground GNU Gnu’s Not Unix GPL General Public Licence GSM Global System for Mobile Communications HMAC Hashed Message Authentication Code IAIK Institut für Angewandte Informationsverarbeitung und Kommu- nikationstechnologie (Institute for Applied Information Proces- sing and Communications) ICC Integrated Circuit Card ID Identiﬁer 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). Speciﬁcation 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

[2] 3RD GENERATION PARTNERSHIP PROJECT (3GPP). Speciﬁcation of 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. http://www.3gpp.org/ftp/specs/html-info/1114.htm

[3] 3RD GENERATION PARTNERSHIP PROJECT (3GPP). UICC-terminal interface; physical and logical characteristics. Ver. 6.5.1 (Release 6). TS 31.101. 2006. http://www.3gpp.org/ftp/specs/html-info/31101.htm

[4] 3RD GENERATION PARTNERSHIP PROJECT (3GPP). Characteristics of the Universal Subscriber Identity Module (USIM) application. Ver. 6.21.0 (Re- lease 6). TS 31.102. 2008. http://www.3gpp.org/ftp/specs/html-info/31102.htm

[5] 3RD GENERATION PARTNERSHIP PROJECT (3GPP). Universal Subscri- ber Identity Module (USIM) Application Toolkit (USAT). Ver. 6.13.0 (Release 6). TS 31.111. 2009. http://www.3gpp.org/ftp/specs/html-info/31111.htm

[6] 3RD GENERATION PARTNERSHIP PROJECT (3GPP). Speciﬁcation of the Subscriber Identity Module - Mobile Equipment (SIM-ME) interface. Ver. 4.15.0 (Release 4). TS 51.011. 2005. http://www.3gpp.org/ftp/specs/html-info/51011.htm

[7] 3RD GENERATION PARTNERSHIP PROJECT (3GPP). Speciﬁcation of 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

http://www.3gpp.org/ftp/specs/html-info/51014.htm

[8] ABDALLA, M.; BELLARE, M. y ROGAWAY, P. DHAES: An encryption scheme based on the Diﬃe-Hellman problem. Contribución a IEEE P1363a, 1998. http://grouper.ieee.org/groups/1363/P1363a/contributions/dhaes. pdf

[9] ABDALLA, M.; BELLARE, M y ROGAWAY, P. “The oracle Diﬃe-Hellman assumptions and an analysis of DHIES”. Lecture Notes in Computer Science. 2001, vol. 2020, pp. 143–158. ISBN 3-540-41898-9. http://dx.doi.org/10.1007/3-540-45353-9_12

[10] ABDALLA, M.; BELLARE, M. y ROGAWAY, P. DHIES: An encryption scheme based on the Diﬃe-Hellman problem. Inédito, 2001. http://www.cs.ucdavis.edu/~rogaway/papers/dhies.pdf

[11] ADAMS, C. The CAST-128 encryption algorithm. Request for Comments (RFC) 2144. Internet Engineering Task Force (IETF), 1997. http://www.ietf.org/rfc/rfc2144.txt

[12] AENOR. Referencias bibliográﬁcas. Contenido, forma y estructura. UNE 50- 104-94. Enero 1994. http://www.aenor.es/aenor/normas/normas/fichanorma.asp?tipo= N&codigo=N0005073&PDF=Si

[13] AMERICAN MATHEMATICAL SOCIETY. MSC 2010 database. Página web. http://www.ams.org/mathscinet/msc/msc.html

[14] AMERICAN NATIONAL STANDARDS INSTITUTE (ANSI). Triple Data Encryption: Modes of operation. X9.52. 1998.

[15] AMERICAN NATIONAL STANDARDS INSTITUTE (ANSI). Public key cryptography for the ﬁnancial 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 ﬁnancial 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 ﬁ- nantial industry american national standards, draft standards for trial use, technical reports and technical guides. Marzo 2010. http://www.x9.org/standards/catalog/X9_Standards_Catalog.pdf [18] AOKI K. et al. “Camellia: A 128-bit block cipher suitable for multiple plat- forms - Design and analysis”. Lecture Notes in Computer Science, 2001, vol. 2012, pp. 39-56. ISBN 3-540-42069-X. http://dx.doi.org/10.1007/3-540-44983-3_4 [19] ATENIESE, G. et al. “A practical and provably secure coalition-resistant group signature scheme ”. Lecture Notes in Computer Science. 2000, vol. 1880, pp. 255–270. ISBN 978-3-540-67907-3. http://dx.doi.org/10.1007/3-540-44598-6_16 [20] ATENIESE, G. y DE MEDEIROS, B. “Eﬃcient group signatures without trapdoors”. Lecture Notes in Computer Science. 2003, vol. 2894, pp. 246–268. ISBN 978-3-540-20592-0. http://dx.doi.org/10.1007/978-3-540-40061-5_15 [21] APPLE INC. How to identify a micro-SIM. Página web. http://support.apple.com/kb/HT4192 [22] ATKIN, A. O. L. “The number of points on an elliptic curve modulo a prime”. Correos enviados al Number Theory Mailing List, 1988-1992.

[23] ATKIN, A. O. L. y MORAIN, F. “Elliptic curves and primality proving”. Mathematics of Computation. Julio 1993, vol. 61, num. 203, pp. 29–68. ISSN 0025-5718. http://dx.doi.org/10.1090/S0025-5718-1993-1199989-X [24] BACH, E. y SHALLIT, J. Algorithmic number theory. Cambridge (Massachu- setts): MIT Press, 1996. ISBN 0-262-02405-5.

[25] BARRÓN VIDALES, J. “Diseño e implementación de un esquema de cifrado híbrido basado en DHIES”. Director: Debrup Chakraborty. Centro de Inves- tigación y de Estudios Avanzados del Instituto Politécnico Nacional, Méjico, 2008. http://www.cs.cinvestav.mx/Estudiantes/TesisGraduados/2008/ tesisJesusBarron.pdf [26] BELLARE, M. y ROGAWAY, P. “Minimizing the use of random oracles in authenticated encryption schemes”. Lecture Notes in Computer Science. 1997, vol. 1334, pp. 1–16. ISBN 978-3-540-63696-0. 342 Referencias

http://dx.doi.org/10.1007/BFb0028457

[27] BELLARE, M. et al. “Relations among notions of security for public-key encryption schemes”. Lecture Notes in Computer Science. 1998, vol. 1462, pp. 549–570. ISSN 3-540-64892-5. http://dx.doi.org/10.1007/BFb0055718

[28] BERTA, I. Z. y MANN, Z. Á. “Implementing Elliptic Curve Cryptography on PC and smart card”. Periodica Polytechnica Electrical Enginnering. 2002, vol. 46, num. 1-2, pp. 47–73. ISSN 0324-6000. http://www.pp.bme.hu/ee/2002_1/pdf/ee2002_1_04.pdf

[29] BLAKE, I.; SEROUSSI, G. y SMART, N. Elliptic curves in cryptography. Cambridge: Cambridge University Press, 1999. ISBN 0-521-65374-6.

[30] BLAKE, I.; SEROUSSI, G. y SMART, N. Advances in Elliptic Curve Crypto- graphy. Cambridge: Cambridge University Press, 2005. ISBN 0-521-60415-X.

[31] BONEH, D. “Twenty years of attacks on the RSA cryptosystem”. Notices of the American Mathematical Society. Febrero 1999, vol. 46, num. 2, pp. 203–213. ISSN 0002-9920. http://www.ams.org/notices/199902/boneh.pdf

[32] BOUNCE CASTLE. The legion of the Bouncy Castle. Página web. http://www.bouncycastle.org

[33] BRAINPOOL. ECC Brainpool. Página web. http://www.ecc-brainpool.org

[34] BRAINPOOL. ECC Brainpool standard curves and curve generation. Ver. 1.0. 2005. www.ecc-brainpool.org/download/Domain-parameters.pdf

[35] BRESSOUD, D. M. Factorization and primality testing. Nueva York: Springer- Verlag, 1989. ISBN 0-387-97040-1.

[36] BUCHMANN, J. A. Introduction to cryptography. 2a ed. Nueva York: Springer, 2004. ISBN 0-387-21156-X.

[37] BUNDESAMT FÜR SICHERHEIT IN DER INFORMATIONSTECHNIK (BSI). Elliptic Curve Cryptography. Ver. 1.11. TR-03111. 2009. https://www.bsi.bund.de/cae/servlet/contentblob/471398/ publicationFile/30615/BSI-TR-03111_pdf.pdf Referencias 343

[38] CARBONELL JIMÉNEZ, C.; DÍAZ MUÑOZ, R. y MEJÍAS OSORIO, P. Algunas aplicaciones de las curvas elípticas a la criptografía. Director: Eric Donders Orellana. Facultad de Ciencias Físicas y Matemáticas. Universidad Central de Chile, 2007. http://www.criptored.upm.es/descarga/EficienciaCCE_RSA.zip

[39] CARD CONTACT SOFTWARE. Open Smart Card Development Platform (OpenSCDP). Página web. http://www.openscdp.org

[40] CENTRO CRIPTOLÓGICO NACIONAL (CCN). Tecnología de identiﬁca- ción por radiofrecuencia (RFID). CCN-STIC-443. 2009. https://www.ccn-cert.cni.es/index.php?option=com_wrapper&view= wrapper&Itemid=188&lang=es

[41] CERTICOM CORP. Method for signature and session key generation. Inven- tores: S. A. Vanstone, A. J. Menezes, M. Qu. Fecha de solicitud: 1996-04-15. Patente internacional, WO 96/33565. 1996-10-24. http://v3.espacenet.com/publicationDetails/originalDocument?CC= WO&NR=9633565A1&KC=A1&FT=D&date=19961024&DB=EPODOC&locale=es_lp

[42] CERTICOM CORP. Multiple bit multiplier. Inventor: R. C. Mullin. Fecha de solicitud: 1996-03-29. Estados Unidos, patente de invención, 5.787.028. 1998- 07-28. http://www.google.com/patents/about?id=wnETAAAAEBAJ&dq=5787028

[43] CERTICOM CORP. Generating unique and unpredictable values. Inventor: D. B. Johnson. Fecha de solicitud: 1996-10-10. Estados Unidos, patente de invención, 6.078.667. 2000-06-20. http://www.google.com/patents/about?id=rUUEAAAAEBAJ&dq=6078667

[44] CERTICOM CORP. Strengthened public key protocol. Inventores: S. A. Vans- tone, A. J. Menezes, M. Qu. Fecha de solicitud: 1999-04-01. Estados Unidos, patente de invención, 5.933.504. 2003-05-13. http://www.google.com/patents/about?id=rNoOAAAAEBAJ&dq=5933504

[45] CERTICOM CORP. Elliptic curve encryption systems. Inventores: S. A. Vans- tone, R. C. Mullin, G. B. Agnew. Fecha de solicitud: 2000-09-06. Estados Unidos, patente de invención, 6.618.483 B1. 2003-09-09. http://www.google.com/patents/about?id=AeEOAAAAEBAJ&dq=6618483 344 Referencias

[46] CERTICOM CORP. Digital signatures on a smartcard. Inventores: S. A. Vans- tone, A. J. Menezes. Fecha de solicitud: 2001-08-29. Estados Unidos, patente de invención, 6.704.870 B2. 2004-03-09. http://www.google.com/patents/about?id=rZ0SAAAAEBAJ&dq=6704870

[47] CERTICOM CORP. Accelerated ﬁnite ﬁeld operations on an elliptic curve. In- ventores: S. A. Vanstone, R. Mullin, A. Antipa, R. Gallant. Fecha de solicitud: 2000-10-02. Estados Unidos, patente de invención, 6.782.100. 2004-08-24. http://www.google.com/patents/about?id=XGESAAAAEBAJ&dq=6782100

[48] CHEN, Z. Java Card technology for smart cards: Architecture and program- mer’s guide. Boston: Addison-Wesley, 2000. ISBN 0-201-70329-7.

[49] COHEN, H. A course in computational algebraic number theory. Berlín: Springer-Verlag, 1993. ISBN 3-540-55640-0.

[50] COHEN, H. et al. Handbook of elliptic and hyperelliptic curve cryptography. Florida: Chapman & Hall/CRC, 2006. ISBN 1-58488-518-1.

[51] CONNELL, I. Elliptic Curve Handbook. Inédito, 1999. http://www.math.mcgill.ca/connell/

[52] CONSEJO SUPERIOR DE INVESTIGACIONES CIENTÍFICAS. Procedi- miento y dispositivo de encriptación mediante un criptosistema tipo RSA. In- ventores: L. Hernández, J. Muñoz, A. Queiruga. Fecha de solicitud: 2003-02-14. España, patente de invención, 2.217.959. 2006-02-01. http://dx.doi.org/10261/4968

[53] COPPERSMITH, D. et al. “Low-exponent RSA with related messages”. Lec- ture Notes in Computer Science. 1996, vol. 1070, pp. 1–9. ISBN 978-3-540- 61186-8. http://dx.doi.org/10.1007/3-540-68339-9_1

[54] CORON, J. S. y MAY, A. “Deterministic polynomial-time equivalence of computing the RSA secret key and factoring”. Journal of Cryptology. Enero 2007, vol. 20, num. 1, pp. 39–50. ISSN 0933-2790. http://dx.doi.org/10.1007/s00145-006-0433-6

[55] CRAMER, R. y SHOUP, V. “Design and analysis of practical public-key encryption schemes secure against adaptive chosen ciphertext attack”. SIAM Journal on Computing. Diciembre 2003, vol. 33, num. 1, pp. 167–226. ISSN 0097-5397. http://dx.doi.org/10.1137/S0097539702403773 Referencias 345

[56] CRYPTIX. The Cryptix project. Página web. http://www.cryptix.org

[57] DEITEL, P. y DEITEL, H. M. Java: How to program. 8a ed. Upper Saddle River (Nueva Jersey): Pearson Prentice Hall, 2009. ISBN 0-13605-306-8.

[58] DENT, A. W. ACE-KEM and the general KEM-DEM structure. NES/DO- C/RHU/WP5/023/3. NESSIE Project, 2002. https://www.cosic.esat.kuleuven.be/nessie/reports/phase2/ Evaluation.zip

[59] DETHLOFF, J. y GRÖTRUPP, H. Identiﬁcation switch. Inventores: J. Deth- loﬀ, H. Grötrupp. Fecha de solicitud: 1969-09-15. Estados Unidos, patente de invención, 3.678.250. 1972-07-18. http://www.google.com/patents/about?id=zjUvAAAAEBAJ&dq=3678250

[60] DETHLOFF, J. y GRÖTRUPP, H. Identiﬁcation system. Inventores: J. Deth- loﬀ, H. Grötrupp. Fecha de solicitud: 1970-08-17. Estados Unidos, patente de invención, 3.641.316. 1972-02-08. http://www.google.com/patents/about?id=fFY6AAAAEBAJ&dq=3641316

[61] DIFFIE, W. y HELLMAN, M. E. “New directions in cryptography”. IEEE Transactions on Information Theory. Noviembre 1976, vol. 22, num. 6, pp. 644–654. ISSN 0018-9448. http://dx.doi.org/10.1109/TIT.1976.1055638

[62] DINERS CLUB. Company history of Diners Club. Página web. https://www.dinersclubus.com/dce_content/aboutdinersclub/ companyhistory

[63] DOBBERTIN, H.; BOSSELAERS, A. y PRENEEL, B. “RIPEMD-160: A strengthed version of RIPEMD”. Lecture Notes in Computer Science. 1996, vol. 1039, pp. 71–82. ISBN 3-540-60865-6. http://dx.doi.org/10.1007/3-540-60865-6_44

[64] DOLEV, D.; DWORK, C. y NAOR, M. “Non-malleable cryptograpy”. En: Pro- ceedings of the 23rd Annual Symposium on the Theory of Computing. Nueva Orleans, 1991. pp 542–552. ISBN 0-89791-397-3. http://dx.doi.org/10.1145/103418.103474

[65] DREIFUS, H. y MONK, J. T. Smart cards: A guide to building and managing smart card applications. Nueva York: Wiley, 1998. ISBN 0-471-15748-1. 346 Referencias

[66] DURÁN DÍAZ, R.; HERNÁNDEZ ENCINAS, L. y MUÑOZ MASQUÉ, J. El criptosistema RSA. Madrid: RA-MA, 2005. ISBN 84-7897-651-5.

[67] DWORK, C. y NAOR, M. Non-malleability: Introduction and survey of recent develpments. Inédito, 2003. http://www.wisdom.weizmann.ac.il/~naor/PAPERS/ref_nmc.pdf

[68] EASTLAKE, D. E. Additional XML Security Uniform Resource Identiﬁers (URIs). Request for Comments (RFC) 4051. Internet Engineering Task Force (IETF), 2005. http://www.ietf.org/rfc/rfc4051.txt

[69] ELGAMAL, T. “A public key cryptosystem and a signature scheme based on discrete logarithms”. IEEE Transactions on Information Theory. Julio 1985, vol. 31, num. 4, pp. 469–472. ISSN 0018-9448. http://dx.doi.org/10.1109/TIT.1985.1057074

[70] ELKIES, N. “Elliptic and modular curves over ﬁnite ﬁelds and related computational issues”. En: Proceedings of Computational Perspectives on Number Theory. Chicago, 1998. pp 21–76. ISBN 0-8218-0880-X. http://www.ams.org/mathscinet-getitem?mr=1486831

[71] ELO, T. Lessons learned on implementing ECDSA on a Java smart card. Inédito, 2000. http://www.tml.hut.fi/Research/TeSSA/Papers/Elo/Elo_Nordsec2000. pdf

[72] ENGE, A. Elliptic curves and their applications to cryptography: An introduction. Boston: Kluwer Academic Publishers, 1999. ISBN 0-7923-8589-6.

[73] ERICKSON, M. y VAZZANA, A. Introduction to number theory. Boca Ratón (Florida): Chapman & Hall/CRC, 2008. ISBN 1-58488-937-3.

[74] EUROPEAN COMMITTEE FOR BANKING STANDARDS. Overview of electronic purse products. Ver. 4.0. Informe técnico TR102. European Com- mittee for Banking Standards, 2003. http://www.ecbs.org

[75] EUROPEAN TELECOMMUNICATION STANDARDS INSTITUTE (ET- SI). Smart cards - UICC-terminal interface - Physical and logical 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 m-divisibility and the discrete logarithm in the divisor class group of curves”. Mathematics of Computation. Abril 1994, vol. 62, num. 206, pp. 865–874. ISSN 0025-5718. http://dx.doi.org/10.1090/S0025-5718-1994-1218343-6

[77] FREY, G. “Applications of arithmetical geometry to cryptographic construc- tions”. En: Proceedings of the Fifth International Conference on Finite Fields and Applications, pp 128–161. Augsburg (Alemania), 2001. ISBN 3-540-41109- 7. http://www.iem.uni-due.de/zahlentheorie/preprints/nna1.ps

[78] FÚSTER SABATER, A.; et al. Técnicas criptográﬁcas de protección de datos. 3a ed. Madrid: RA-MA, 2004. ISBN 84-7897-594-2.

[79] GALINDO, D.; MARTÍN, S. y VILLAR, J. L. “The security of PSEC-KEM versus ECIES-KEM”. En: Proceedings of the 26th Symposium on Information Theory in the BeNeLux, pp 17–27. Bruselas, 2005. ISBN 90-71048-21-7. http://www.dgalindo.es/kemsFullBenelux.pdf

[80] GATTIKER, U. E. The information security dictionary: Deﬁning the terms that deﬁne security for E-business, Internet, information, and wireless technology. Boston: Kluwer Academic Publishers, 2004. ISBN 1-4020-7889-7.

[81] GAYOSO MARTÍNEZ, V. et al. “Elliptic Curve Criptography: Java implementation issues”. En: Proceedings of the 39th IEEE International Carnahan Conference on Security Technology (ICCST 2005), pp 238–241. Las Palmas de Gran Canaria, 2005. ISBN 0-7803-9245-0. http://dx.doi.org/10.1109/CCST.2005.1594866

[82] GAYOSO MARTÍNEZ, V. et al. “Estado del arte de las implementaciones Java de criptografía de curva elíptica”. En: Actas del I Simposio sobre Segu- ridad Informática, I Congreso Español de Informática (CEDI), pp. 127–134. Granada, 2005. ISBN: 84-9732-447-1.

[83] GAYOSO MARTÍNEZ, V.; HERNÁNDEZ ENCINAS, L. y SÁNCHEZ ÁVI- LA, C. “Elliptic Curve Cryptography. Java platform implementations”. En: Proceedigs of the 23rd International Conference on Information Technologies (InfoTech-2009), pp. 20–27. Varna (Bulgaria), 2009. ISBN: 978-954-438-771-6. http://dx.doi.org/10261/18590

[84] GAYOSO MARTÍNEZ, V.; HERNÁNDEZ ENCINAS, L. y SÁNCHEZ ÁVI- LA, C. “Elliptic Curve Cryptography. Java platform implementations”. Inter- national Journal on Information Techonologies & Security. Diciembre 2009, num. 4, pp. 65–72. ISSN: 1313-8251. 348 Referencias

http://dx.doi.org/10261/21232

[85] GAYOSO MARTÍNEZ, V.; HERNÁNDEZ ENCINAS, L. y SÁNCHEZ ÁVI- LA, C. “A Java implementation of the Elliptic Curve Integrated Encryption Scheme”. En: Proceedings of the 2010 International Conference on Security & Management - SAM’10, vol.n II, pp. 495–501. Las Vegas, 2010. ISBN: 1- 60132-162-7.

[86] GAYOSO MARTÍNEZ, V.; HERNÁNDEZ ENCINAS, L. y SÁNCHEZ ÁVI- LA, C. “A comparison of the standardized versions of ECIES”. En: Proceedings of the 6th International Conference on Information Assurance and Security (IAS 2010)m pp. 1–4. Atlanta, 2010. ISBN: 978-1-4244-7408-0. http://dx.doi.org/10.1109/ISIAS.2010.5604194

[87] GAYOSO MARTÍNEZ, V.; HERNÁNDEZ ENCINAS, L. y SÁNCHEZ ÁVI- LA, C. “Security and practical considerations when implementing the Elliptic Curve Integrated Encryption Scheme”. Enviado a: Journal of Systems and Software. 2010. ISSN 0164-1212.

[88] GAYOSO MARTÍNEZ, V.; HERNÁNDEZ ENCINAS, L. y SÁNCHEZ ÁVI- LA, C. “Performance evaluation of the Elliptic Curve Integrated Encryption Scheme implemented in PC and Java Card”. Enviado a: Computers & Mathe- matics with Applications. 2010. ISSN 0898-1221.

[89] GAYOSO MARTÍNEZ, V.; HERNÁNDEZ ENCINAS, L. y SÁNCHEZ ÁVI- LA, C. “Java Card implementation of the Elliptic Curve Integrated Encryption Scheme using prime and binary ﬁnite ﬁelds”. Enviado a: International Journal of Information Security. 2010. ISSN 1615-5262.

[90] GAYOSO MARTÍNEZ, V.; HERNÁNDEZ ENCINAS, L. y SÁNCHEZ ÁVI- LA, C. “A survey of the elliptic curve integrated encryption scheme”. Journal of Computer Science and Engineering. Agosto 2010, vol. 2, num. 2, pp. 7–13. ISSN 2043-9091. http://sites.google.com/site/jcseuk/volumes/V2-I2-P7-13.pdf

[91] GAUDRY, P.; HESS, F. y SMART, N. “Constructive and destructive facets of Weil descent on elliptic curves”. Journal of Cryptology. Marzo 2002, vol. 15, num. 1, pp. 19–46. ISSN 0933-2790. http://dx.doi.org/10.1007/s00145-001-0011-x

[92] GEISELMANN, W. y STEINWANDT, R. “Power attacks on a side-channel resistant elliptic curve implementation”. Information Processing Letters. Julio 2004, vol. 91, num. 1, pp. 29–32. ISSN 0020-0190. http://dx.doi.org/10.1016/j.ipl.2003.12.009 Referencias 349

[93] GOLDWASSER, S. y MICALI, S. “Probabilistic encryption & how to play mental poker keeping secret all partial information”. En: Proceedings of the ACM symposium on theory of computing - STOC 82, pp. 365–377. San Fran- cisco, 1982. ISBN 0-89791-070-2. http://dx.doi.org/10.1145/800070.802212

[94] GOLDWASSER, S. y MICALI, S. “Probabilistic encryption”. Journal of Com- puter and System Sciences. Abril 1984, vol. 28, num. 2, pp. 270–299. ISSN 0022-0000. http://dx.doi.org/10.1016/0022-0000(84)90070-9

[95] GOLDWASSER, S. y KILIAN, J. “Almost all primes can be quickly certiﬁed”. En: Proceedings of the 18th Annual ACM Symposium on Theory of Computing, pp. 316–329. Berkeley (California), 1986. ISBN 0-89791-193-8. http://dx.doi.org/10.1145/12130.12162

[96] GRIFFITHS, P. A. Introduction to algebraic curves. Providence (Rhode Is- land): American Mathematical Society, 1989. ISBN 0-8218-4530-6.

[97] GUTHERY, S. B. y JURGENSEN, T. M. Smart card: Developer’s kit. India- nápolis (Indiana): Macmillan Technical Publishing, 1998. ISBN 1-57870-027-2.

[98] HANN, J. et al. “Implementation of ECC/ECDSA Cryptography Algorithms Based on Java Card”. En: Proceedings of the 22nd International Conference on Distributed Computing Systems - ICDCSW’02, pp. 272–278. Viena, 2002. ISBN 0-7695-1588-6. http://dx.doi.org/10.1109/ICDCSW.2002.1030781

[99] HANKERSON, D.; MENEZES, A. y VANSTONE, S. Guide to Elliptic Curve Cryptography. Nueva York: Springer-Verlag, 2004. ISBN 0-387-95273-X.

[100] HANSMANN, U.; et al. Smart card application development using Java. Ber- lín: Springer, 2000. ISBN 3-540-65829-7.

[101] HASTAD, J. “Solving simultaneous modular equations of low degree”. SIAM Journal of Computing. Abril 1988, vol. 17, num. 2, pp. 336–341. ISSN 0097- 5397. http://dx.doi.org/10.1137/0217019

[102] HERNÁNDEZ ENCINAS, L. et al. “Sobre la clasificación de curvas hiperelíp- ticas de género 2 definidas en cuerpos finitos”. En: Actas del I Simposio sobre Seguridad Informática, I Congreso Español de Informática (CEDI), pp. 31–36. Granada, 2005. ISBN 84-9732-447-1. 350 Referencias

[103] HESS, E. et al. “Information leakage attacks against smart card implementations of cryptographic algorithms and countermeasures - A survey”. En: Proceedings of the EUROSMART Security Conference, pp. 55–64. Marsella, 2000. http://www.torsten-schuetze.de/reports/leakage.pdf

[104] HEWLETT-PACKARD COMPANY. Compression and decompression of elliptic curve data points. Inventor: G. Seroussi. Fecha de solicitud: 1998-08-04. Estados Unidos, patente de invención, 6.252.960. 2001-06-26. http://www.google.com/patents/about?id=mcIIAAAAEBAJ&dq=6252960

[105] HID GLOBAL. HID Products OMNIKEY 5321 CL USB Reader. Página web. http://www.hidglobal.com/prod_detail.php?prod_id=331

[106] HOOK, D. Beginning cryptography with Java. Indianapolis: Wiley Publishing, 2005. ISBN 0-7645-9633-0.

[107] HORTON, I. Beginning Java 2. Birmingham (Reino Unido): Wrox Press, 1999. ISBN 1-86100-223-8.

[108] INSTITUTE OF ELECTRICAL AND ELECTRONICS ENGINEERS (IEEE). Standard speciﬁcations 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 speciﬁcations 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

[111] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION (ISO). Information and documentation – Bibliographic references – Part 2: Electronic documents or parts thereof. ISO 690-2. 1997. http://www.iso.org/iso/iso_catalogue/catalogue_ics/catalogue_ detail_ics.htm?csnumber=25921 Referencias 351

[112] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION (ISO). 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 [113] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION (ISO). Identification cards – Integrated circuit(s) cards with contacts – Part 1: Phy- sical characteristics. ISO/IEC 7816-1. 1998. http://www.iso.org/iso/catalogue_detail?csnumber=29257 [114] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION (ISO). 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 [115] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION (ISO). Information technology – Identification cards – Integrated circuit(s) cards with contacts – Part 3: Electronic signals and transmission protocols. 3a ed. ISO/IEC 7816-3. 2006. http://www.iso.org/iso/catalogue_detail.htm?csnumber=38770 [116] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION (ISO). Information technology – Identification cards – Integrated circuit(s) cards with contacts – Part 4: Interindustry commands for interchange. 2a ed. ISO/IEC 7816-4. 2005. http://www.iso.org/iso/catalogue_detail.htm?csnumber=36134 [117] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION (ISO). Identification cards – Integrated circuit cards – Part 5: Registration of application providers. 2a ed. ISO/IEC 7816-5. 2004. http://www.iso.org/iso/catalogue_detail?csnumber=34259 [118] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION (ISO). Identification cards – Integrated circuit cards – Part 6: Interindustry data ele- ments for interchange. 2a ed. ISO/IEC 7816-6. 2004. http://www.iso.org/iso/catalogue_detail?csnumber=38780 [119] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION (ISO). Identification cards – Integrated circuit(s) cards with contacts – Part 7: Inte- rindustry commands for Structured Card Query Language (SCQL). ISO/IEC 7816-7. 1999. http://www.iso.org/iso/catalogue_detail?csnumber=28869 352 Referencias

[120] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION (ISO). Identiﬁcation cards – Integrated circuit cards – Part 8: Commands for security operations. 2a ed. ISO/IEC 7816-8. 2004. http://www.iso.org/iso/catalogue_detail?csnumber=37989

[121] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION (ISO). Identiﬁcation cards – Integrated circuit cards – Part 9: Commands for card management. 2a ed. ISO/IEC 7816-9. 2004. http://www.iso.org/iso/catalogue_detail?csnumber=37990

[122] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION (ISO). Identiﬁcation cards – Integrated circuit(s) cards with contacts – Part 10: Elec- tronic signals and answer to reset for synchronous cards. ISO/IEC 7816-10. 1999. http://www.iso.org/iso/catalogue_detail?csnumber=30558

[123] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION (ISO). Identiﬁcation cards – Integrated circuit cards – Part 11: Personal veriﬁcation through biometric methods. ISO/IEC 7816-11. 2004. http://www.iso.org/iso/catalogue_detail?csnumber=31419

[124] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION (ISO). Identiﬁcation cards - Integrated circuit cards – Part 12: Cards with contacts – USB electrical interface and operating procedures. ISO/IEC 7816-12. 2005. http://www.iso.org/iso/catalogue_detail?csnumber=40604

[125] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION (ISO). Identiﬁcation cards – Integrated circuit cards – Part 13: Commands for application management in a multi-application environment. ISO/IEC 7816-13. 2007. http://www.iso.org/iso/catalogue_detail?csnumber=40605

[126] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION (ISO). Identiﬁcation cards – Integrated circuit cards – Part 15: Cryptographic information application. ISO/IEC 7816-15. 2004. http://www.iso.org/iso/catalogue_detail?csnumber=35168

[127] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION (ISO). Information technology – ASN.1 encoding rules: Speciﬁcation of Basic En- coding Rules (BER), Canonical Encoding Rules (CER) and Distinguished En- coding Rules (DER). ISO/IEC 8825-1. 2008. http://www.iso.org/iso/catalogue_detail?csnumber=54011 Referencias 353

[128] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION (ISO). Information technology – Security techniques – Message authentication codes – Part 1: Mechanisms using a block cipher. ISO/IEC 9797-1. 1999. http://www.iso.org/iso/catalogue_detail?csnumber=30656

[129] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION (ISO). Information technology – Security techniques – Message authentication codes (MACs) – Part 2: Mechanisms using a dedicated hash-function. ISO/IEC 9797-2. 2002. http://www.iso.org/iso/catalogue_detail?csnumber=31136

[130] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION (ISO). Information technology – Security techniques – Hash-functions – Part 2: Hash- functions using an n-bit block cipher. 3a ed. ISO/IEC 10118-2. 2010. http://www.iso.org/iso/iso_catalogue/catalogue_ics/catalogue_ detail_ics.htm?csnumber=44737

[131] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION (ISO). Information technology – Security techniques – Hash-functions – Part 3: De- dicated hash-functions. ISO/IEC 10118-3. 2004. http://www.iso.org/iso/catalogue_detail?csnumber=39876

[132] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION (ISO). Identiﬁcation cards – Contactless integrated circuit(s) cards – Proximity cards – Part 1: Physical characteristics. 2a ed. ISO/IEC 14443-1. 2008. http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_ detail.htm?csnumber=39693

[133] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION (ISO). Identiﬁcation cards – Contactless integrated circuit cards – Proximity cards – Part 2: Radio frequency power and signal interface. 2a ed. ISO/IEC 14443- 2. 2010. http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_ detail.htm?csnumber=50941

[134] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION (ISO). Identiﬁcation cards – Contactless integrated circuit(s) cards – Proximity cards – Part 3: Initialization and anticollision. ISO/IEC 14443-3. 2001. http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_ detail.htm?csnumber=28730 354 Referencias

[135] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION (ISO). Identiﬁcation cards – Contactless integrated circuit(s) cards – Proximity cards – Part 4: Initialization and anticollision. 2a ed. ISO/IEC 14443-4. 2008. http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_ detail.htm?csnumber=50648

[136] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION (ISO). Information technology – Security techniques – Encryption algorithms – Part 2: Asymmetric ciphers. ISO/IEC 18033-2. 2006. http://www.iso.org/iso/catalogue_detail?csnumber=37971

[137] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION (ISO). Information technology – Security techniques – Encryption algorithms – Part 3: Block ciphers. ISO/IEC 18033-3. 2005. http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_ detail.htm?csnumber=37972

[138] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION (ISO). Information technology – Biometric Exchange Formats Framework – Part 1: Data element speciﬁcation. ISO/IEC 19785-1. 2006. http://www.iso.org/iso/catalogue_detail?csnumber=41047

[139] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION (ISO). Joint Technical Comittee (JTC) 1/Sub-comittee (SC) 17. Página web. http://www.iso.org/iso/standards_development/technical_ committees/list_of_iso_technical_committees/iso_technical_ committee.htm?commid=45144

[140] IVORRA CASTILLO, C. Curvas elípticas. Inédito, 2010. www.uv.es/ivorra/Libros/Elipticas.pdf

[141] JACOBSON, M.; MENEZES, A. y STEIN, A. “Solving Elliptic Curve Discrete Logarithm Problems using Weil descent”. Journal of the Ramanujan Mathe- matical Society. 2000, vol. 16, pp. 231–260. http://eprint.iacr.org/2001/041.pdf

[142] JOYE, M. “Smart-card implementation of elliptic curve cryptography and DPA-type attacks”. En: Proceedings of the 6th International Conference on Smart Card Research and Advanced Applications (CARDIS), pp. 115–125. Toulouse, 2004. ISBN 1-4020-8146-4. http://joye.site88.net/papers/Joy04cardis.pdf Referencias 355

[143] KATZ, N. M. y MAZUR, B. Arithmetic moduli of elliptic curves. Princeton (Nueva Jersey): Princeton University Press, 1985. ISBN 0-691-08352-5.

[144] KATZ, J. y LINDELL, Y. Introduction to modern cryptography. Boca Ratón (Florida): Chapman & Hall/CRC, 2008. ISBN 1-58488-551-3.

[145] KAYA KOÇ, Ç. (editor). Cryptographic engineering. Nueva York: Springer, 2009. ISBN 978-0-387-71816-3.

[146] KIEFER, K. “A weakness of the Menezes-Vanstone cryptosystem”. Lecture Notes in Computer Science. 1998, vol. 1361, pp. 201–206. ISBN 978-3-540- 64040-0. http://dx.doi.org/10.1007/BFb0028170 [147] KOBLITZ, N. “Elliptic curve cryptosystems”. Mathematics of Computation. Enero 1987, vol. 48, num. 177, pp. 203–209. ISSN 0025-5718. http://dx.doi.org/10.1090/S0025-5718-1987-0866109-5 [148] KOBLITZ, N. A course in number theory and cryptography. 2a ed. Berlín: Springer-Verlag, 1994. ISBN 3-540-96576-9.

[149] KOBLITZ, N. Algebraic aspects of cryptography. Berlín: Springer-Verlag, 1998. ISBN 3-540-63446-0.

[150] KOCHER, P. “Timing attacks on implementations of Diffie-Hellman, RSA, DSS, and other systems”. Lecture Notes in Computer Science. 1996, vol. 1109, pp. 104–113. ISBN 978-3-540-61512-5. http://dx.doi.org/10.1007/3-540-68697-5_9 [151] KOCHER, P.; JAFFE, J. y JUN, B. Introduction to Differential Power Analy- sis and related attacks. Informe técnico. Cryptographic Research, 1998. http://www.cryptography.com/public/pdf/DPATechInfo.pdf [152] KOCHER, P.; JAFFE, J. y JUN, B. “Differential Power Analysis”. Lecture Notes in Computer Science. 1999, vol. 1666, pp. 388–397. ISBN 978-3-540- 66347-8. http://dx.doi.org/10.1007/3-540-48405-1_25 [153] KRANTZ, S. G. Handbook of typography for the mathematical sciences. Boca Ratón (Florida): Chapman & Hall/CRC, 2001. ISBN 1-58488-149-6.

[154] KRAWCZYK, H.; BELLARE, M. y CANETTI, R. HMAC: Keyed hashing for message authentication. Request for Comments (RFC) 2104. Internet Engi- neering Task Force (IETF), 1997. http://www.ietf.org/rfc/rfc2104.txt 356 Referencias

[155] KUROSAWA, K. y DESMEDT, Y. “A new paradigm of hybrid encryption scheme”. Lecture Notes in Computer Science. 2004, vol. 3152, pp. 426–442. ISBN 3-540-22668-0. http://dx.doi.org/10.1007/978-3-540-28628-8_26 [156] KUROSAWA, K.; ITO, T. y TAKEUCHI, M. “Public key cryptosystem using a reciprocal number with the same intractability as factoring a large number”. Cryptologia. Octubre 1983, vol. 7, num. 4, pp. 225–233. ISSN 0161-1194. http://dx.doi.org/10.1080/0161-118891862972 [157] LEE, H.J. et al. The SEED encryption algorithm. Request for Comments (RFC) 4269. Internet Engineering Task Force (IETF), 2005. http://www.ietf.org/rfc/rfc4269.txt [158] LEHMAN, S. “Factoring large integers”. Mathematics of Computation. Abril 1974, vol. 28, num. 126, pp. 637–646. ISSN 0025-5718. http://dx.doi.org/10.1090/S0025-5718-1974-0340163-2 [159] LENSTRA, H. W. “Factoring integers with elliptic curves”. Annals of Mathe- matics. Noviembre 1987, vol. 126, num. 3, pp. 649–673. ISSN 0003-486X. http://www.jstor.org/stable/1971363 [160] LEUNG, K. y HUI, L. “Multiple signature handling in workﬂow systems”. En: Proceedings of the 33rd International Conference on System Sciences, pp. 6033. Hawaii, 2000. ISBN 0-7695-0493-0. http://dx.doi.org/10.1109/HICSS.2000.926854 [161] MALL, D. y ZHONG, Q. Open source is not enough. Attacking the EC-package of Bouncycastle version 1.x_132. Inédito, 2008. http://eprint.iacr.org/2008/113 [162] MAMBO, M.; USUDA, K. y OKAMOTO, E. “Proxy signatures for delegating signing operation”. En: Proceedings of the 3rd ACM Conference on Computer and Communications Security - CCS’96, pp. 48–57. Nueva Delhi (India), 1996. http://dx.doi.org/10.1145/238168.238185 [163] MAOSCO LTD. MULTOS smart card technology. Página web. http://www.multos.com [164] MASSACHUSETTS INSTITUTE OF TECHNOLOGY. Cryptographic communications system and method. Inventores: R. L. Rivest, A. Shamir y L. Ad- leman. Fecha de solicitud: 1977-12-14. Estados Unidos, patente de invención, 4.405.829. 1983-09-20. http://www.google.com/patents?vid=4405829 Referencias 357

[165] MATSUI, M. Speciﬁcation of MISTY1 - A 64-bit block cipher. Inédito, 2000. https://www.cosic.esat.kuleuven.be/nessie/workshop/submissions/ misty1.zip

[166] MATSUSHITA ELECTRIC INDUSTRIAL CO., LTD. Public key cryptosystem with an elliptic curve. Inventores: A. Miyaji, M. Tatebayashi. Fecha de solicitud: 1992-05-26. Estados Unidos, patente de invención, 5.272.755. 1993- 12-21. http://www.google.com/patents/about?id=nB4bAAAAEBAJ&dq=5272755

[167] MAURER, M.; MENZES, A. y TESKE, E. “Analysis of the GHS Weil descent attack on the ECDLP over characteristic two ﬁnite ﬁelds of composite degree (extended abstract)”. Lecture Notes in Computer Science. 2001, vol. 2247, pp. 195–213. ISBN 978-3-540-43010-0. http://dx.doi.org/10.1007/3-540-45311-3_19

[168] MENEZES, A. J. Elliptic curve public key cryptosystems. Boston: Kluwer Aca- demic Publishers, 1993. ISBN 0-79239-368-6.

[169] MENEZES, A. J. y VANSTONE, S. A. Vanstone. “Elliptic curve cryptosystems and their implementation”. Journal of Cryptology. Septiembre 1993, vol. 6, num. 4, pp. 209–224. ISSN 0933-2790. http://dx.doi.org/10.1007/BF00203817

[170] MENEZES, A. J.; OKAMOTO, T. y VANSTONE, S. A. Vanstone. “Reducing elliptic curve logarithms to logarithms in a ﬁnite ﬁeld”. IEEE Transactions on Information Theory. Septiembre 1993, vol. 39, num. 5, pp. 1639–1646. ISSN 0018-9448. http://dx.doi.org/10.1109/18.259647

[171] MENEZES, A.; QU, M. y VANSTONE, S. “Some new key agreement protocols providing implicit authentication”. En: Proceedings of the Workshop on Selected Areas in Cryptography - SAC ’95, pp. 22–32. Ottawa (Canadá), 1995. http://leonardo.ee.queensu.ca/sac/sac95/papers/SAC_95_003.pdf

[172] MENEZES, A.; VAN OORSCHOT, P. y VANSTONE, S. Handbook of applied cryptography. Florida: CRC Press, 1996. ISBN: 0-8493-8523-7. http://www.cacr.math.uwaterloo.ca/hac/

[173] MENEZES, A. y QU, M. “Analysis of the Weil descent attack of Gaudry, Hess and Smart”. Lecture Notes in Computer Science. 2001, vol. 2020, pp. 308–318. ISBN 978-3-540-41898-6. http://dx.doi.org/10.1007/3-540-45353-9_23 358 Referencias

[174] MILLER, V. S. “Use of elliptic curves in cryptography”. Lecture Notes in Com- puter Science. 1986, vol. 218, pp. 417–426. ISBN 3-540-16463-4. http://dx.doi.org/10.1007/3-540-39799-X_31

[175] MILNE, J. S. Elliptic curves. Charleston (Carolina del Sur): BookSurge, 2006. ISBN 1-4196-5257-5.

[176] MINISTERIO DEL INTERIOR. DNI electrónico. Página web. http://www.dnielectronico.es/oficina_prensa/noticias/noticia12. html

[177] MINISTERIO DEL INTERIOR. Pasaporte electrónico (pasaporte-e). Página web. http://www.mir.es/SGACAVT/pasaport/concepto.html

[178] MOHAMMED, E.; EMARAH, A. E. y EL-SHENNAWY, K. “Elliptic curve cryptosystems on smart cards”. En: Proceedings of the 35th IEEE Internatio- nal Carnahan Conference on Security Technology (ICCST 2001), pp 213–222. Londres, 2001. ISBN 0-7803-6636-0 . http://dx.doi.org/10.1109/.2001.962835

[179] MOLLIN, R. A. An introduction to cryptography. 2a ed. Boca Ratón (Florida): Chapman & Hall/CRC, 2007. ISBN 1-58488-618-8.

[180] Mordell, L. J. “On the rational solutions of the indeterminate equations of the third and fourth degrees”. Proceedings of the Cambridge Philosophical Society. 1922, vol. 21, pp. 179–192. ISSN 0305-0041.

[181] MULDER, E. et al. “Diﬀerential power and electromagnetic attacks on a FP- GA implementation of elliptic curve cryptosystems”. Computers and Electrical Engineering. Septiembre 2007, vol. 33, num. 5–6, pp. 367–382. ISSN 0045-7906. http://dx.doi.org/10.1016/j.compeleceng.2007.05.009

[182] NAGELL, T. “Sur les propriétés arithmétiques des cubiques planes du premier genre”. Acta Mathematica. 1929, vol. 52, pp. 93–126. ISSN 0001-5962. http://dx.doi.org/10.1007/BF02592681

[183] NATIONAL INSTITUTE OF STANDARDS AND TECHNOLOGY (NIST). Secure hash standard. FIPS 180-3. 2008. http://csrc.nist.gov/publications/fips/fips180-3/fips180-3_ final.pdf Referencias 359

[184] NATIONAL INSTITUTE OF STANDARDS AND TECHNOLOGY (NIST). Digital Signature Standard (DSS). FIPS 186-3. 2009. http://csrc.nist.gov/publications/fips/fips186-3/fips_186-3.pdf [185] NATIONAL INSTITUTE OF STANDARDS AND TECHNOLOGY (NIST). Advanced Encryption Standard. FIPS 197. 2001. http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf [186] NATIONAL INSTITUTE OF STANDARDS AND TECHNOLOGY (NIST). The Keyed-Hash Message Authentication Code (HMAC). FIPS 198-1. 2008. http://csrc.nist.gov/publications/fips/fips198-1/FIPS-198-1_ final.pdf [187] NATIONAL INSTITUTE OF STANDARDS AND TECHNOLOGY (NIST). 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 [188] NATIONAL INSTITUTE OF STANDARDS AND TECHNOLOGY (NIST). 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 [189] NATIONAL INSTITUTE OF STANDARDS AND TECHNOLOGY (NIST). 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 [190] NATIONAL INSTITUTE OF STANDARDS AND TECHNOLOGY (NIST). 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 [191] NATIONAL INSTITUTE OF STANDARDS AND TECHNOLOGY (NIST). Secure hashing - Approved algorithms. Página web. http://csrc.nist.gov/groups/ST/toolkit/secure_hashing.html [192] NATIONAL SECURITY AGENCY. Method of elliptic curve cryptographic key exchange using reduced base tau expansion in non-adjacent form. Inventores: R. W. Reiter, J. A. Solinas. Fecha de solicitud: 1998-07-23. Estados Unidos, patente de invención, 6.212.279. 2001-04-03. http://www.google.com/patents/about?id=4pgGAAAAEBAJ&dq=6212279 360 Referencias

[193] NATIONAL SECURITY AGENCY. Method of elliptic curve digital signature generation and veriﬁcation using reduced base tau expansion in non-adjacent form. Inventores: R. W. Reiter, J. A. Solinas. Fecha de solicitud: 1998-07-23. Estados Unidos, patente de invención, 6.243.467. 2001-06-05. http://www.google.com/patents/about?id=fcsIAAAAEBAJ&dq=6243467

[194] NATIONAL SECURITY AGENCY (NSA). Suite B cryptography. Página web. http://www.nsa.gov/ia/programs/suiteb_cryptography/index.shtml

[195] NESSIE CONSORTIUM. Portfolio of recommended cryptographic primitives. Ver. 1.0. 2003. https://www.cosic.esat.kuleuven.be/nessie/deliverables/ decision-final.pdf

[196] NESSIE CONSORTIUM. Final report of European project number IST-1999- 12324 named New European Schemes for Signatures, Integrity, and Encry- ption. Ver. 0.15. 2004. https://www.cosic.esat.kuleuven.be/nessie/Bookv015.pdf

[197] NEXT COMPUTER, INC. Method and apparatus for public key exchange in a cryptographic system. Inventor: R. E. Crandall. Fecha de solicitud: 1993-12-14. Estados Unidos, patente de invención, 5.463.690. 1995-10-31. 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 invención, 5.581.616. 2001-09-04. http://www.google.com/patents/about?id=92kIAAAAEBAJ&dq=5581616

[199] NTT CORPORATION. PSEC-KEM speciﬁcation. 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. http://www.ietf.org/rfc/rfc2994.txt

[205] OMNET ASSOCIATES. Method and apparatus for maintaining the privacy of digital messages conveyed by public transmission. Inventores: J. L. Mas- sey, J. K. Omura. Fecha de solicitud: 1982-09-14. Estados Unidos, patente de invención, 4.567.600. 1986-01-28. http://www.google.com/patents/about?id=i-M5AAAAEBAJ&dq=4567600

[206] OMNET ASSOCIATES. Computational method and apparatus for ﬁnite ﬁeld arithmetic. Inventores: J. K. Omura, J. L. Massey. Fecha de solicitud: 1982- 09-14. Estados Unidos, patente de invención, 4.587.627. 1986-05-06. http://www.google.com/patents/about?id=lNsyAAAAEBAJ&dq=4587627

[207] OMNISEC A.G. Public key cryptographic system using elliptic curves over rings. Inventor: U. Maurer. Fecha de solicitud: 1991-03-22. Estados Unidos, patente de invención, 5.146.500. 1992-09-08. 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 ﬁnite ﬁeld multiplication. Inventores: I. M. Onysz- chuk, R. C. Mullin, S. A. Vanstone. Fecha de solicitud: 1985-05-30. Estados Unidos, patente de invención, 4.745.568. 1988-05-17. http://www.google.com/patents/about?id=OJc2AAAAEBAJ&dq=4745568

[209] ORACLE CORP. BigInteger (Java Platform SE 6). Página web. http://download.oracle.com/javase/6/docs/api/java/math/ BigInteger.html

[210] ORACLE CORP. Java Card Technology. Página web. http://www.oracle.com/technetwork/java/javacard/overview/index. html 362 Referencias

[211] ORACLE CORP. Java smart card I/O API. Página web. http://jcp.org/en/jsr/detail?id=268 [212] ORACLE CORP. Java technology. Página web. http://java.com/en/about [213] ORACLE CORP. OpenJDK. Página web. http://openjdk.java.net [214] ORACLE CORP. Oracle completes acquisition of Sun. Página web. http://www.oracle.com/us/corporate/press/044428 [215] ORTEGA JUANCAS, S. Algunas aplicaciones de las curvas elípticas a la crip- tografía. Director: Juan Gabriel Tena Ayuso. Secretariado de Publicaciones e Intercambio Científico de la Universidad de Valladolid, 1997. http://dialnet.unirioja.es/servlet/tesis?codigo=11638 [216] PC/SC WORKGROUP. The PC/SC workgroup. Página web. http://www.pcscworkgroup.com [217] PÉREZ ORTIZ, J. A. Diccionario urgente de estilo científico del español. Iné- dito, 1999. http://www.dlsi.ua.es/~japerez/pub/pdf/duece1999.pdf [218] PIETILÄINEN, H. “Elliptic curve cryptography on smart cards”. Director: El- jas Soisalon-Soininen. Faculty of Information Technology, Helsinki University of Technology, Finlandia, 2000. http://henna.laurikari.net/Dippa/di.pdf [219] POHLIG, S. C. y HELLMAN, M. E. “An improved algorithm for computing logarithms over GF (p) and its cryptographic significance”. IEEE Transactions on Information Theory. Enero 1978, vol. 24, num. 1, pp. 644–654. ISSN 0018- 9448. http://dx.doi.org/10.1109/TIT.1978.1055817 [220] POLLARD, J. M. “Theorems on factorization and primality testing”. Mathe- matical Proceedings of the Cambridge Philosophical Society. Noviembre 1974, vol. 76, num. 3, pp. 521–528. ISSN 0305-0041. http://dx.doi.org/10.1017/S0305004100049252 [221] POLLARD, J. M. “A Monte Carlo method for factorization”. BIT Numerical Mathematics. Septiembre 1975, vol. 15, num. 3, pp. 331–334. ISSN 0006-3835. http://dx.doi.org/10.1007/BF01933667 Referencias 363

[222] POLLARD, J. M. “Monte Carlo methods for index computation (mod p)”. Mathematics of Computation. Julio 1978, vol. 32, num. 143, pp. 918–924. http://dx.doi.org/10.1090/S0025-5718-1978-0491431-9

[223] QUISQUATER, J. “The adolescence of smart cards”. Future Generation Com- puter Systems. Julio 1997, vol. 13, num. 1, pp. 3–7. ISSN 0167-739X. http://dx.doi.org/10.1016/S0167-739X(97)89108-X

[224] QUISQUATER, J. y KOEUNE, F. ECIES - Security evaluation of the encryption scheme and primitives. Informe técnico 1015. Cryptrec, 2002. http://www.ipa.go.jp/security/enc/CRYPTREC/fy15/doc/1015_ECIES_ report.pdf

[225] RABIN, M. O. Digitalized signatures and public key functions as intractable as factorization. Informe técnico 212. Massachussetts Institute of Technology (MIT), 1979. http://publications.csail.mit.edu/lcs/pubs/pdf/MIT-LCS-TR-212. pdf

[226] RANKL, W. y EFFING, W. Smart card handbook. 3a ed. West Sussex (Ingla- terra): John Wiley & Sons, 2003. ISBN 0-470-85668-8.

[227] RIEMANN, B. “Theorie der Abel’schen functionen”. Journal für die reine und angewandte Mathematik. Enero 1857, num. 54, pp. 115–155. ISSN 0075-4102. http://dx.doi.org/10.1515/crll.1857.54.115

[228] RIESEL, H. Prime numbers and computer methods for factorization. 2a ed. Boston: Birkhäuser, 1994. ISBN 0-8176-3743-5.

[229] RIVEST, R. L.; SHAMIR, A. y ADLEMAN, L.. “A method for obtaining digital signatures and public-key cryptosystems”. Communications of the ACM. Enero 1983, vol. 26, num. 1, pp. 96–99. http://dx.doi.org/10.1145/359340.359342

[230] ROCH, G. “Ueber die anzahl der willkurlichen constanten in algebraischen functionen”. Journal für die reine und angewandte Mathematik. Enero 1865, num. 64, pp. 372–376. ISSN 0075-4102. http://dx.doi.org/10.1515/crll.1865.64.372

[231] RSA DATA SECURITY INC. Methods and apparatus for efficient finite field basis conversion. Inventores: B. S. Kaliski, Jr., Y. L. Yin. Fecha de solicitud: 1997-05-05. Estados Unidos, patente de invención, 5.854.759. 1998-12-29. http://www.google.com/patents/about?id=HHIYAAAAEBAJ&dq=5854759 364 Referencias

[232] RSA LABORATORIES. RSA cryptography standard. Ver. 2.1. PKCS #1. 2002. ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-1/pkcs-1v2-1.pdf

[233] RSA LABORATORIES. Overview of Elliptic Curve Cryptosystems. RSA La- boratories Technical Note. 1997. http://www.rsa.com/rsalabs/node.asp?id=2013

[234] RSA LABORATORIES. Password-based cryptography standard. Ver. 2.1. PKCS#5. 2006. ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-5v2/pkcs5v2_1.pdf

[235] SATOH, T. y ARAKI, K. “Fermat quotients and the polynomial time discrete log algorithm for anomalous elliptic curves”. Commentarii Mathematici Universitatis Sancti Pauli. Enero 1998, vol. 47, num. 1, pp. 81–92. http://mathpc-satoh.math.titech.ac.jp/en/A1998.html

[236] SATOH, T. “The canonical lift of an ordinary elliptic curve over a ﬁnite ﬁeld and its point counting”. Journal of the Ramanujan Mathematical Society. 2000, vol. 15, num. 4, pp. 247–270. http://mathpc-satoh.math.titech.ac.jp/en/A2000.html

[237] SCHNEIER, B. Applied cryptography. 2a ed. Nueva York: John Willey & Sons, 1996. ISBN 0-471-11709-9.

[238] SCHOOF, R. “Elliptic curves over ﬁnite ﬁelds and the computation of square roots mod p”. Mathematics of Computation. Abril 1985, vol. 44, num. 170, pp. 483–494. http://dx.doi.org/10.1090/S0025-5718-1985-0777280-6

[239] SCHOOF, R. “Counting points on elliptic curves over ﬁnite ﬁelds”. Journal de Théorie de Nombres de Bordeaux. 1995, vol. 7, pp. 219–254. http://www.mat.uniroma2.it/~schoof/ctg.pdf

[240] SEMAEV, I. A. “Evaluation of discrete logarithms in a group of p-torsion points of an elliptic curve in characteristic p”. Mathematics of Computation. Enero 1998, vol. 67, num. 221, pp. 353–356. http://dx.doi.org/10.1090/S0025-5718-98-00887-4

[241] SHANKS, D. “Class number, a theory of factorization, and genera”. En: Pro- ceedings of 1969 Number Theory Institute. Stony Brook (Nueva York), 1969. pp 415–440. ISBN 0-82181-420-6. http://www.ams.org/mathscinet-getitem?mr=47:4932 Referencias 365

[242] SHIEH, S. et al. “Digital multisignature schemes for authenticating delegates in mobile code systems”. IEEE Transactions on Vehicular Technology. Julio 2000, vol. 49, num. 4, pp. 1464–1473. ISSN 0018-9545. http://dx.doi.org/10.1109/25.875284 [243] SHOUP, V. A proposal for an ISO standard for public key encryption. Ver. 2.1. Inédito, 2001. http://eprint.iacr.org/2001/112.pdf [244] SILVERMAN, J. H. y TATE, J. Rational points on elliptic curves. Nueva York: Springer-Verlag, 1992. ISBN 0-387-97825-9.

[245] SILVERMAN, J. H. The arithmetic of elliptic curves. 2a ed. Nueva York: Springer-Verlag, 2009. ISBN 978-0-387-09493-9.

[246] SMART CARD ALLIANCE. German electronic health card. 2006. http://www.smartcardalliance.org/resources/pdf/German_Health_ Card.pdf [247] SMART, N. “The discrete logarithm problem on elliptic curves of trace one”. Journal of Cryptology. Noviembre 1999, vol. 12, num. 3, pp. 193–196. ISSN 0933-2790. http://dx.doi.org/10.1007/s001459900052 [248] SOCIÉTÉ INTERNATIONALE POUR L’INNOVATION. Methods of data storage and data storage systems. Inventor: R. Moreno. Fecha de solicitud: 1975-03-21. Estados Unidos, patente de invención, 3.971.916. 1976-07-27. http://www.google.com/patents/about?id=5js9AAAAEBAJ&dq=3971916 [249] SOCIÉTÉ INTERNATIONALE POUR L’INNOVATION. Data-transfer system. Inventor: R. Moreno. Fecha de solicitud: 1975-03-21. Estados Unidos, patente de invención, 4.007.355. 1977-02-08. http://www.google.com/patents/about?id=-6c1AAAAEBAJ&dq=4007355 [250] SOCIÉTÉ INTERNATIONALE POUR L’INNOVATION. Systems for storing and transferring data. Inventor: R. Moreno. Fecha de solicitud: 1976-05-13. Estados Unidos, patente de invención, 4.092.524. 1978-05-30. http://www.google.com/patents/about?id=l0IxAAAAEBAJ&dq=4092524 [251] SOL, R. Manual práctico de estilo. Barcelona: Urano, 1992. ISBN 84-7953- 020-0.

[252] SOURCEFORGE. OpenCard Framework. Página web. http://sourceforge.net/projects/opencard/ 366 Referencias

[253] STANDARDS FOR EFFICIENT CRYPTOGRAPHY GROUP (SECG). Test vectors for SEC 1. Ver. 0.3. GEC 2. 1999. http://www.secg.org/download/aid-390/gec2.pdf

[254] STANDARDS FOR EFFICIENT CRYPTOGRAPHY GROUP (SECG). Elliptic Curve Cryptography. Ver. 2.0. SEC 1. 2009. http://www.secg.org/download/aid-780/sec1-v2.pdf

[255] STANDARDS FOR EFFICIENT CRYPTOGRAPHY GROUP (SECG). Re- commended elliptic curve domain parameters. Ver. 2.0. SEC 2. 2010. http://www.secg.org/download/aid-784/sec2-v2.pdf

[256] STERN, J. Evaluation report on the ECIES cryptosystem. Informe técnico 1016. Cryptrec, 2002. http://www.ipa.go.jp/security/enc/CRYPTREC/fy15/doc/1016_Stern. ECIES.pdf

[257] STINSON, D. R. Cryptography: Theory and practice. 3a ed. Boca Ratón (Flo- rida): Chapman & Hall/CRC, 2006. ISBN 1-58488-508-4.

[258] SVENDA, P. Cryptographic algorithms re-implementation for JavaCard. Pá- gina web. http://www.fi.muni.cz/~xsvenda/jcalgs.html

[259] TECHNISCHE UNIVERSITÄT DARMSTADT. FlexiProvider. Página web. http://www.cdc.informatik.tu-darmstadt.de/flexiprovider/

[260] TECHNISCHE UNIVERSITÄT GRAZ. IAIK crypto toolkit. Página web. http://jce.iaik.tugraz.at

[261] UJALDÓN MARTÍNEZ, M. Arquitectura del PC. Volumen I. Microprocesa- dores. Madrid: Ciencia 3 Distribución, 2003. ISBN 978-84-95391-86-5.

[262] UNIVERSAL SMART CARDS. JCOP range (Java Card OS). Página web. http://www.usmartcards.com/prod-jcop-range-java-card-os-10.php

[263] UNIVERSIDAD POLITÉCNICA DE MADRID. Cómo citar una bibliografía. Página web. http://www.upm.es/upm/biblioteca/citabibliografia.html

[264] WAGSTAFF, S. S. Jr. Cryptanalysis of number theoretic ciphers. Boca Ratón (Florida): Chapman & Hall/CRC, 2003. ISBN 1-58488-153-4. Referencias 367

[265] WASHINGTON, L. C. Elliptic curves. Number theory and cryptography. 2a ed. Boca Ratón (Florida): Chapman & Hall/CRC, 2008. ISBN 978-1-4200-7146-7.

[266] WEIL, A. “L’arithmétique sur les courbes algébriques”. Acta Mathematica. 1929, vol. 52, pp. 281–315. ISSN 0001-5962. http://dx.doi.org/10.1007/BF02592688

[267] WIENER, M. J. “Cryptoanalysis of short RSA secret exponents”. IEEE Tran- sactions on Information Theory. Mayo 1990, vol. 36, num. 3, pp. 553–558. ISSN 0018-9448. http://dx.doi.org/10.1109/18.54902

[268] WIKIPEDIA. Java Card Open Platform. Página web. http://en.wikipedia.org/wiki/Java_Card_OpenPlatform

[269] WILES, A. “Modular elliptic curves and Fermat’s Last Theorem”. Annals of Mathematics. Mayo 1995, vol. 141, num. 3, pp. 443–551. ISSN 0003-486X. http://www.jstor.org/stable/2118559

[270] WILLIAMS, H. C. “A modiﬁcation of the RSA public key encryption proce- dure”. IEEE Transactions on Information Theory. Noviembre 1980, vol. 26, num. 6, pp. 726–729. ISSN 0018-9448. http://dx.doi.org/10.1109/TIT.1980.1056264

[271] WILLIAMS, H. C. “A p+1 method of factoring”. Mathematics of Computation. Julio 1982, vol. 39, num. 159, pp. 225–234. ISSN 0025-5718. http://dx.doi.org/10.1090/S0025-5718-1982-0658227-7

[272] WIRELESS APPLICATION PROTOCOL FORUM (WAP FORUM). Wire- less Transport Layer Security (WTLS). Ver. 06. WAP-261-WTLS. 2001. http://www.openmobilealliance.org/tech/affiliates/wap/ wap-261-wtls-20010406-a.pdf

[273] ZHANG, K. “Threshold proxy signature schemes”. Lecture Notes in Computer Science. 1998, vol. 1396, pp. 282–290. ISBN 978-3-540-64382-1. http://dx.doi.org/10.1007/BFb0030429 368 Referencias