Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
Implementacin en tarjetas
inteligentes Java Card de
protocolos de cifrado y descifrado
basados en curvas elpticas
Tesis Doctoral
Vctor Gayoso Martnez
Ingeniero de Telecomunicacin
2010
Departamento de Tratamiento de la
Informacin y Codificacin
Directores
Carmen Snchez vila
Doctora en Ciencias Matemticas
TRIBUNAL CALIFICADOR
Tribunal nombrado por el Magfco. y Excmo. Sr. Rector de la Universidad Polide
de
.
tcnica de Madrid el da
Presidente Dr. D.
Vocal
Dr. D.
Vocal
Dr. D.
Vocal
Dr. D.
Secretario
Dr. D.
de
Calificacin:
EL PRESIDENTE
LOS VOCALES
EL SECRETARIO
ix
AGRADECIMIENTOS
En primer lugar me gustara mostrar mi agradecimiento a mis tutores Luis Hernndez y Carmen Snchez por su esfuerzo continuo y su paciencia infinita revisando
cada borrador de esta Tesis, dndome siempre buenos y acertados consejos.
En especial, me gustara agradecer a Luis la magnfica oportunidad de haber
podido trabajar con l estos dos ltimos aos en el Consejo Superior de Investigaciones Cientficas, tiempo del que siempre guardar el mejor de los recuerdos y en
el que tanto he aprendido.
El resto de agradecimientos son para:
Mi mujer y mi hija, a las que tanto debo.
Mis padres, por apoyarme y ayudarme siempre que lo he necesitado.
Mi hermana, con la que a pesar de la distancia sigo compartiendo tantas cosas.
Mis amigos scar, Sixto, Enrique, Mnica, Mara Jos, Carlos Daniel, Jos Ignacio, Blanca, Marta, David, Rafa, Enrique, Gema, Antonio, Ma Carmen y tantos
otros, por seguir siendo los mejores amigos en los buenos y los malos momentos.
La empresa NXP, y muy especialmente Juan Moreno, por proporcionarme las
tarjetas JCOP J3A empleadas en esta Tesis, sin las cuales no habra podido desarrollar una parte importante de la investigacin.
El departamento de Tratamiento de la Informacin y Codificacin del Instituto
de Fsica Aplicada del CSIC, por la profesionalidad y compaerismo demostrados
en estos dos ltimos aos.
ndice general
Introduccin
Antecedentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Justificacin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Metodologa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Clasificacin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Estructura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Notas de estilo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1. Tarjetas inteligentes
19
ndice general
xii
49
2.1. Introduccin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
2.2. Aplicaciones de la criptografa de clave pblica . . . . . . . . . . . . . 51
2.2.1. Establecimiento de clave . . . . . . . . . . . . . . . . . . . . . 51
2.2.2. Firma digital . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
2.2.3. Cifrado/descifrado . . . . . . . . . . . . . . . . . . . . . . . . 53
2.3. Seguridad en criptosistemas de clave pblica . . . . . . . . . . . . . . 54
2.4. Principales esquemas de cifrado y establecimiento de clave . . . . . . 56
2.4.1. Establecimiento de clave Diffie-Hellman . . . . . . . . . . . . . 57
2.4.2. Criptosistema RSA . . . . . . . . . . . . . . . . . . . . . . . . 59
2.4.3. Criptosistema de El Gamal . . . . . . . . . . . . . . . . . . . . 64
2.5. Esquemas de cifrado hbrido DEM -KEM . . . . . . . . . . . . . . . . 68
2.5.1. Mecanismo de encapsulacin de clave KEM
. . . . . . . . . . 69
ndice general
xiii
99
129
ndice general
xiv
181
ndice general
xv
. . . . . . . . . . . . . . . . . . . . . . . . . 207
. . . . . . . . . . . . . . . . . . . . . . . 218
243
ndice general
xvi
271
ndice general
xvii
313
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 327
Notacin
331
Glosario
333
Referencias
339
ndice de figuras
1.
. . . . . . . . . . . . . . . . . . . . . . 20
. . . . 22
. . . . . . . . . . . . . . . . . . . . . . . . . 37
ndice de figuras
xx
. . . . . . . . . . . . . . . . . . . . . . 47
. . 118
ndice de figuras
xxi
. . . . . . . . . 215
xxii
ndice de figuras
. . . . . . . . . . . . 238
5.54. Seleccin del fichero con la clave privada del destinatario . . . . . . . 238
5.55. Introduccin de la contrasea para el acceso a la clave privada . . . . 239
5.56. Identificador de la clave privada del destinatario . . . . . . . . . . . . 239
5.57. Seleccin del fichero con el criptograma . . . . . . . . . . . . . . . . . 240
5.58. Identificador del fichero con criptograma . . . . . . . . . . . . . . . . 240
5.59. Seleccin del fichero para el mensaje descifrado
. . . . . . . . . . . . 241
ndice de figuras
xxiii
. . . 284
. . . 286
. . . 287
xxiv
ndice de figuras
ndice de figuras
xxv
ndice de cuadros
1.
2.
3.
xxviii
ndice de cuadros
. . . 284
. . . 285
. . . 287
ndice de cuadros
xxix
ndice de algoritmos
2.1.
2.2.
2.3.
Cifrado RSA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
2.4.
Descifrado RSA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
2.5.
2.6.
2.7.
2.8.
2.9.
4.2.
4.3.
4.4.
4.5.
4.6.
4.7.
4.8.
4.9.
xxxii
ndice de algoritmos
5.2.
5.3.
5.4.
5.5.
Introduccin
Antecedentes
En 1976, Whitfield Diffie y Martin Hellman [61] desarrollaron los conceptos que
permitieron el nacimiento de la criptografa de clave pblica. Desde entonces, numerosos criptosistemas han sido propuestos, aunque slo unos pocos han soportado
con xito el escrutinio de la comunidad cientfica. Entre los elementos analizados
por los expertos destacan principalmente las caractersticas de eficiencia, complejidad y seguridad de los algoritmos, las cuales dependen en gran medida del problema
matemtico en que estn basados. Algunos de los problemas relacionados con los
criptosistemas actuales son:
Factorizacin en enteros (Integer Factorization Problem o IFP), fundamento
del criptosistema RSA [66, 232, 229].
Logaritmo discreto (Discrete Logarithm Problem o DLP), base matemtica
para el algoritmo ElGamal [69].
Logaritmo discreto en curvas elpticas (Elliptic Curve Discrete Logarithm Problem o ECDLP), ncleo de la criptografa basada en curvas elpticas.
En 1985, Neal Koblitz [147] y Victor Miller [174] propusieron de forma independiente el uso de curvas elpticas en criptografa (Elliptic Curve Cryptography o
ECC), cuya seguridad depende del ECDLP. Desde entonces, la ECC se ha aplicado
a campos tan diversos como la creacin de criptosistemas para el cifrado y descifrado
de datos [16, 109, 136, 254], la generacin y verificacin de firmas digitales [15, 184],
la factorizacin de enteros [49, 159], las tcnicas de primalidad [23, 49, 95], e incluso
ocup un lugar destacado en la demostracin del ltimo teorema de Fermat por
parte de Andrew Wiles [269].
1
Introduccin
Al igual que en el caso del IFP y del DLP, no se conoce ningn algoritmo que
resuelva de forma eficiente el ECDLP. De hecho, se estima que el ECDLP es el ms
difcil de resolver de los tres problemas mencionados [37, 147, 168], lo que convertira
la criptografa con curvas elpticas en el criptosistema ms resistente.
Gracias a esta mayor resistencia, la longitud de las claves en ECC es sensiblemente inferior que la necesaria en otros algoritmos para conseguir el mismo nivel
de seguridad (medido como la fortaleza proporcionada por un algoritmo de cifrado
simtrico que utilice una clave de bits), tal como se puede observar en el Cuadro 1
y la Figura 1 (cuyos datos han sido obtenidos de [99] y [184]), lo que favorece su
uso en sistemas con recursos limitados como por ejemplo los telfonos mviles y las
tarjetas inteligentes.
Nivel de seguridad Longitud de la
(bits)
clave RSA (bits)
80
1024
112
2048
128
3072
192
7680
256
15360
Longitud de la
clave ECC (bits)
160-223
224-255
256-283
384-511
512-571
Introduccin
Cifrado
Descifrado
Firma
Verificacin
ECC 160 bits RSA 1024 bits (con CRT) DLP 1024 bits
120
17
480
60
384
240
60
384
240
120
17
480
Cuadro 2: Comparacin del rendimiento de ECC, RSA y los esquemas DLP medido en
unidades de tiempo necesarias para cada operacin
Introduccin
necesarias.
RSA 1024
ECC 163
RSA 1024
ECC 163
RSA 3072
ECC 283
RSA 3072
ECC 283
Justificacin
A la vista de la situacin planteada en el apartado anterior, y dada la escasez de
implementaciones software de ECC en general (y en tarjetas inteligentes en particular), se estim la importancia de desarrollar diversas aplicaciones que implementaran
un protocolo de cifrado y descifrado sobre curvas elpticas en entornos PC y tarjetas
inteligentes, siendo Java el lenguaje de programacin elegido debido a su popularidad y presencia en entornos comerciales (ver 3.2 y 3.4). A ttulo informativo, la
cifra de desarrolladores Java supera en la actualidad los 6 millones, existiendo ms
de 4.500 millones de dispositivos habilitados con tecnologa Java (principalmente
ordenadores personales, telfonos mviles y tarjetas inteligentes) [212].
El siguiente paso consisti en analizar los diferentes esquemas de cifrado existentes y seleccionar uno de los candidatos para su implementacin. Los primeros
esquemas basados en curvas elpticas que surgieron fueron el equivalente de los sistemas Massey-Omura [205] y ElGamal [69], ambos presentados por Koblitz en 1985
[147]. Una de las principales desventajas de esos esquemas consiste en que asocian
cada mensaje a cifrar con un punto de la curva elptica. Si bien es cierto que en las
curvas utilizadas habitualmente el nmero de puntos es un valor tan elevado que esta
limitacin es ms terica que prctica, la obligatoriedad de construir tablas donde
se relacionen cada uno de los posibles mensajes (y que stas sean previamente conocidas por todos los usuarios) limita la utilidad de estos criptosistemas a entornos
Introduccin
cerrados donde todos los posibles mensajes estn estipulados (empresas, pequeos
grupos, etc.).
El criptosistema Menezes-Vanstone [169] fue diseado para solventar esa limitacin, puesto que en lugar de hacer corresponder cada mensaje con un punto de la
curva, este esquema representa los mensajes en claro como pares ordenados cuyos
componentes son elementos del cuerpo finito sobre el que se define la curva elptica.
De esta manera, es posible dividir cualquier mensaje en claro en bloques, donde cada
bloque pueda ser codificado como un par ordenado (por ejemplo, convirtiendo una
cadena de caracteres o bytes en su equivalente numrico). Como contrapartida negativa, la longitud del criptograma resultante es variable y depende directamente de la
longitud del mensaje a cifrar (a diferencia de los criptosistemas Massey-Omura y ElGamal para curvas elpticas, donde el criptograma siempre tiene la misma longitud
independientemente del mensaje en claro).
En el esquema Menezes-Vanstone el factor de expansin (que se define como
el cociente entre la longitud del criptograma resultante y la longitud del mensaje
original) es 2, puesto que a partir del mensaje en claro compuesto por dos elementos
del cuerpo finito se obtiene un criptograma formado por cuatro elementos del mismo
cuerpo. En comparacin, la variante de ElGamal con curvas elpticas tiene el mismo
factor de expansin si se considera que el mensaje en claro es un punto de la curva,
mientras que si se interpreta que el nmero total de mensajes posibles es igual
al nmero de puntos de la curva (que es del orden del nmero de elementos del
cuerpo finito), entonces el factor de expansin sera aproximadamente 4 (ver 4.1).
El hecho de tener un factor de expansin igual a 2 4 conlleva que el cifrado de
volmenes de informacin elevados generen criptogramas de tamao mucho mayor
que si se utilizara un algoritmo de clave simtrica como por ejemplo AES (Advanced
Encryption Standard).
Otra desventaja derivada del diseo del criptosistema Menezes-Vanstone consiste en la realizacin de operaciones con los puntos de las curvas elpticas en cada
proceso de cifrado. Al ser necesario dividir los mensajes en claro de gran tamao en
mltiples segmentos, y realizar un operacin de cifrado asimtrico con cada uno de
ellos, la diferencia en tiempo de ejecucin del esquema Menezes-Vanstone respecto
a un algoritmo de cifrado simtrico se incrementa conforme aumenta el nmero de
segmentos a cifrar, puesto que las operaciones con puntos son ms lentas que los
clculos realizados por los algoritmos de clave simtrica.
De manera adicional a las desventajas de carcter prctico sealadas, Klaus Kiefer demostr en 1998 que, bajo ciertas ciertas condiciones, el criptosistema MenezesVanstone es inseguro [146]. Kiefer demostr adems que, en contra de lo estipulado
en su especificacin, este criptosistema no puede ser considerado un algoritmo de
cifrado probabilstico.
Debido a todas las razones comentadas, con el paso de los aos la comunidad
acadmica ha ido abandonando el estudio de las versiones con curvas elpticas de
Introduccin
Introduccin
Introduccin
3. Desarrollo propio de los algoritmos relacionados con la ECC y de las operaciones aritmticas con los puntos de las curvas elpticas y con los elementos de
los cuerpos finitos.
La primera opcin referida permite un desarrollo rpido, al utilizar paquetes criptogrficos (en la medida de lo posible de cdigo abierto) ya probados y de notable
calidad. Sin embargo, esta opcin limita la utilizacin de parmetros a los contemplados por dichas bibliotecas, que tal como se describir en 3.3 no ofrecen todas
las combinaciones posibles de algoritmos y parmetros que se deseaban analizar en
esta Tesis.
La segunda opcin es, probablemente, la menos recomendable, al crear una dependencia respecto a unas clases no interoperables de otros proveedores, con la
dificultad inherente de una migracin futura que tenga previsto utilizar software de
otro proveedor, manteniendo al mismo tiempo la limitacin sobre las combinaciones
de algoritmos y parmetros incluidas en la distribucin.
La ltima opcin, por el contrario, permite un grado de flexibilidad superior,
al contemplar el desarrollo bajo demanda de las capacidades de la ECC necesarias,
incluyendo en el proceso las combinaciones de parmetros que requiera el proyecto.
El aspecto negativo de esta opcin lo constituye el coste en tiempo y esfuerzo del
desarrollo en comparacin con las soluciones ya existentes, aunque una vez completado el desarrollo de la biblioteca criptogrfica, sta se podra reutilizar en cualquier
desarrollo posterior.
En la presente Tesis Doctoral, se ha optado por el desarrollo propio para implementar una aplicacin de PC que permita realizar las operaciones de cifrado y descifrado empleando una elevada combinacin de parmetros. Adems de las ventajas
enunciadas anteriormente, este mecanismo aporta la flexibilidad adicional necesaria para poder llevar a cabo las comparaciones con la implementacin de ECIES a
realizar en tarjetas Java Card.
En cuanto a la implementacin en tarjetas inteligentes, dadas las limitaciones
tanto en las API estndar de Java Card (ver 6.2) como en las funcionalidades disponibles en tarjetas reales (ver 7.1), nicamente ha sido posible desarrollar algunas
de las posibles combinaciones de parmetros y funciones de ECIES (ver 7.2).
El ltimo paso antes de comenzar la implementacin de ECIES consisti en comprobar que los objetivos de la Tesis no hubieran sido logrados por otros autores. Tras
realizar las bsquedas correspondientes y analizar el contenido de otras tesis, proyectos fin de carrera, artculos de investigacin y ponencias de congresos, fue posible
identificar una serie de trabajos relacionados con implementaciones Java de curvas
elpticas en tarjetas inteligentes o plataformas PC. A continuacin se detallan dichos
trabajos, adjuntando las razones por los que sus objetivos y desarrollos difieren de
los de la presente Tesis.
Introduccin
10
Introduccin
curvas elpticas en tarjetas inteligentes sin utilizar las clases y los mtodos
definidos en las API estndar de Java Card.
La lectura del material referido ofrece datos concluyentes respecto a las limitaciones de las implementaciones que no utilicen las clases y API estndar de Java Card.
Aunque tcnicamente es posible crear clases y mtodos que realicen operaciones
comnmente conocidas como de bajo nivel (por ejemplo, Petr Svenda ha creado
implementaciones del algoritmo AES y de la funcin resumen SHA-512 utilizando
cdigo Java Card [258]), los resultados ofrecidos por implementaciones desarrolladas
sin acceso al coprocesador indican que dichas implementaciones no son de utilidad
para entornos comerciales, donde el tiempo de respuesta de las tarjetas a una operacin no debera superar la cantidad de un segundo (comprese este dato, por
ejemplo, con los 10 minutos utilizados en la suma de dos puntos segn [28], o con
el tiempo medio de 4 segundos al cifrar con AES un nico bloque de datos con la
implementacin descrita en [258]).
Objetivos
El objetivo general de la presente Tesis Doctoral consiste en implementar el
protocolo de cifrado ECIES (Elliptic Curve Integrated Encryption Scheme), tanto
en plataforma PC como en tarjetas inteligentes Java Card, a fin de:
Analizar la viabilidad de diferentes implementaciones para determinadas combinaciones de parmetros.
Comparar el rendimiento de las implementaciones en PC y Java Card, tanto
por separado como de forma conjunta.
Recomendar combinaciones especficas para su utilizacin en distintos tipos de
dispositivos, en funcin de las caractersticas de los dispositivos y del nivel de
seguridad deseado.
Para conseguir este objetivo general, se pretenden alcanzar los siguientes objetivos particulares:
1. Analizar el protocolo de cifrado y descifrado ECIES con el fin de determinar
hasta qu punto las diferentes propuestas hechas para el mismo conforman un
estndar coherente y homogneo.
2. Proponer un conjunto (o conjuntos) de parmetros que sean compatibles con
todos los estndares analizados.
Introduccin
11
3. Desarrollar una implementacin de ECIES utilizando el lenguaje de programacin Java sobre una plataforma PC que permita trabajar con los conjuntos
de parmetros propuestos y curvas definidas sobre cuerpos finitos primos y
binarios.
4. Estudiar la eficiencia en trminos de tiempo de computacin y de factor de
expansin de la implementacin para PC.
5. Implementar el protocolo ECIES en tarjetas inteligentes de tipo Java Card,
segn la oferta y disponibilidad de tarjetas existentes en el mercado, con curvas
definidas tanto sobre cuerpos finitos primos como binarios.
6. Caracterizar en trminos de eficiencia la implementacin realizada en las tarjetas Java Card utilizando curvas definidas sobre los dos cuerpos finitos anteriormente mencionados.
7. Comparar la implementacin de ECIES llevada a cabo sobre la plataforma PC
con la desarrollada en Java Card, teniendo presentes las diferencias existentes
en sus respectivas arquitecturas, as como las caractersticas de programacin
de cada una de las plataformas.
8. Recomendar una configuracin de ECIES que asegure su resistencia a los diferentes tipos de ataques conocidos, comprobando si dicha configuracin es
aplicable tanto a la plataforma PC como a Java Card.
Es importante aclarar que queda fuera del mbito de la presente Tesis el estudio
de la seguridad de las implementaciones ECC en Java Card para evitar ataques de
canal lateral. La existencia de este tipo de ataques es bien conocida en la comunidad
acadmica tanto en sus aspectos ms generales [103, 145, 150, 151, 152], como de
manera especfica para implementaciones de curvas elpticas [30, 92, 142, 181]. Sin
embargo, puesto que la implementacin Java Card desarrollada en esta Tesis utiliza
tarjetas inteligentes comerciales de las que no se ha podido obtener informacin
sobre las soluciones implementadas para evitar este tipo de ataques, y dado que
el equipamiento necesario (equipos lser y de implantacin inica, laboratorio de
tratamientos qumicos, etc.) para realizar este tipo de ataques es extremadamente
costoso, los anlisis de ataques de canal lateral para las tarjetas empleadas quedan
reservados para organismos o instituciones dedicadas de forma preeminente a este
tipo de actividades.
Metodologa
Teniendo en cuenta los objetivos sealados anteriormente, la metodologa empleada a lo largo de este trabajo de investigacin ha consistido en estudiar el sistema
12
Introduccin
Introduccin
13
Clasificacin
El tema principal de la presente Tesis Doctoral, segn la MSC (Mathematics
Subject Classification) 2010 de la AMS (American Mathematical Society) [13] es:
94A60
Cryptography
De acuerdo a la misma clasificacin, a continuacin se enumeran los identificadores de los restantes temas asociados a esta Tesis, junto con la descripcin proporcionada por la AMS.
03D15
11A05
11A07
11A25
11A41
11A51
11G05
11G20
11N05
11N32
11T71
11Y05
11Y11
11Y16
12E20
14G05
14G15
14G50
14H45
14H50
14H52
62B10
68P25
94A05
94A15
94A62
Complexity of computation
Multiplicative structure; Euclidean algorithm; greatest common
divisors
Congruences; primitive roots; residue systems
Arithmetic functions; related numbers; inversion formulas
Primes
Factorization; primality
Elliptic curves over global fields
Curves over finite and local fields
Distribution of primes
Primes represented by polynomials; other multiplicative structure
of polynomial values
Algebraic coding theory; cryptography
Factorization
Primality
Algorithms; complexity
Finite fields
Rational points
Finite ground fields
Applications to coding theory and cryptography
Special curves and curves of low genus
Plane and space curves
Elliptic curves
Information-theoretic topics
Data encryption
Communication theory
Information theory, general
Authentication and secret sharing
14
Introduccin
Estructura
La memoria de esta Tesis Doctoral se ha dividido en ocho captulos, al margen
de la presente introduccin. En los siguientes prrafos se resume el contenido de
cada uno de los captulos.
El Captulo 1 presenta las caractersticas ms destacadas de las tarjetas inteligentes, incluyendo su historia y las circunstancias que motivaron su aparicin, los
diversos tipos de tarjetas inteligentes, sus propiedades fsicas, los principales estndares relacionados, los sistemas operativos en los que un desarrollador puede crear
aplicaciones para tarjetas y, por ltimo, las diferentes arquitecturas software de acceso a las tarjetas as como los mecanismos de comunicacin desarrollados para tal
fin.
En el Captulo 2 se exponen las principales caractersticas de la criptografa de
clave pblica y de la basada en curvas elpticas, comenzando por la presentacin
de conceptos y definiciones de los algoritmos criptogrficos de clave pblica ms
extendidos hasta la fecha. A continuacin, se describen las ecuaciones generales
que definen las curvas elpticas, la particularizacin de la teora de curvas elpticas
para cuerpos finitos, las aplicaciones ms importantes de las curvas elpticas en
criptografa y los estndares relacionados con cada una de estas aplicaciones. Este
captulo concluye con un resumen de las principales patentes existentes en ECC.
El Captulo 3 tiene como objetivo presentar las capacidades criptogrficas del
lenguaje Java, en concreto las disponibles en las ediciones Java Standard Edition
y Java Card, para lo cual se ofrece una introduccin a la programacin orientada
a objetos y al lenguaje Java en general, junto con un resumen de las principales
bibliotecas criptogrficas desarrolladas con este lenguaje de programacin. En el
apartado que hace referencia a Java Card, se ha incluido una descripcin detallada
de las caractersticas generales de este sistema operativo y de las peculiaridades de
su modelo de programacin.
En el Captulo 4 se describen de forma completa las distintas variantes de ECIES
incluidas en los estndares ANSI X9.63, IEEE 1363a, ISO/IEC 18033-2 y SECG
SEC 1, identificando las principales diferencias existentes entre los cuatro estndares
mencionados. De forma adicional, se incluye un anlisis de la seguridad de ECIES
que recoge las indicaciones y recomendaciones sugeridas en los estudios ms recientes
sobre este tema.
El Captulo 5 presenta las decisiones de diseo tomadas con el objetivo de desarrollar la implementacin de ECIES en plataformas PC, as como el diagrama de las
clases Java que componen el desarrollo software. El resto del Captulo 5 se encuentra
dedicado a la descripcin funcional completa de esta versin de la aplicacin ECIES,
finalizando con un ejemplo de cifrado y descifrado que ilustra las posibilidades de
utilizacin de la aplicacin.
Introduccin
15
Notas de estilo
La presente Tesis Doctoral ha sido redactada utilizando el sistema de composicin de textos LATEX, empleando para ello la distribucin MiKTeX 2.8 y el programa
de edicin WinEdt 5.5. Respecto a la configuracin y las decisiones de estilo en LATEX,
se han consultado numerosas fuentes, aunque las principales han sido [153] para los
aspectos generales de composicin, y [203] para las caractersticas tipogrficas asociadas a la notacin matemtica.
En la elaboracin de la bibliografa, se han seguido principalmente los consejos
sugeridos para la redaccin de tesis doctorales de la Universidad Politcnica de
Madrid [263], que se basan principalmente en las normas ISO 690 [110] y 690-2
[111] (sustituidas en 2010 por una nueva edicin de ISO 690 [112]), as como en
el documento equivalente UNE 50-104-94 de AENOR [12]. Para algunos aspectos
puntuales se han consultado las recomendaciones de Juan Antonio Prez Ortiz [217]
(que a su vez recoge algunas de las indicaciones de Ramn Sol [251]).
El objetivo ha sido componer una bibliografa adaptada en lo posible al estndar ISO y que permitiera una correcta legibilidad. Algunas de las caractersticas
principales del estilo utilizado son:
Escritura del nombre de los autores incluyendo en primer lugar el apellido (o
16
Introduccin
apellidos) en mayscula y posteriormente la inicial (o iniciales) del nombre.
En el caso de empresas o instituciones, se ha intentado mantener el mismo
formato mediante la inclusin del nombre completo en maysculas.
Separacin de los nombres de los autores mediante el carcter punto y coma.
En el caso de existencia de cuatro o ms autores, inclusin nicamente del
primer autor junto al trmino et al. que indica la existencia de autores
adicionales.
Utilizacin de letras maysculas en los ttulos de las obras nicamente en la
primera letra y en los casos necesarios, como por ejemplo los nombres propios
(p. ej. Diffie-Hellman), los acrnimos (p. ej. RSA) o los nombres de algoritmos
o funciones que normalmente se redacten en mayscula (p. ej., Triple Data
Encryption o Elliptic Curve Cryptography).
Utilizacin del nombre de ciudades en su variante castellana en caso de existir
(p. ej., Londres o Nueva York).
Utilizacin de las abreviaturas habituales en la descripcin de las caractersticas de las publicaciones peridicas (vol., num., pp., etc.).
Inclusin de la versin del documento en el caso de estndares o de documentos
electrnicos, empleando el trmino ver. como abreviatura.
Utilizacin del trmino indito para los documentos electrnicos elaborados
por su autor que no hayan sido presentados a congresos o incluidos en libros
o revistas especializadas.
Empleo del nombre oficial de las publicaciones peridicas sin abreviar.
En el caso de las pginas web, inclusin del nombre de la compaa, organismo
o individuo responsable del contenido, as como del ttulo de la pgina.
Inclusin del cdigo asociado al estndar en las normas nacionales e internacionales.
En las patentes, inclusin de los inventores tras el nombre de la empresa (o
individuo) responsable y del ttulo de la patente. Utilizacin de las fechas de
solicitud y confirmacin de la patente, as como del cdigo identificador de la
patente y del pas donde ha sido aprobada.
Inclusin del enlace al documento citado en los casos en los que exista una copia
en formato electrnico en internet, utilizando de manera preferente enlaces
compatibles con el sistema DOI (Document Object Identifier). La validez de
los enlaces fue comprobada por ltima vez el 5 de noviembre de 2010.
Introduccin
17
Captulo 1
Tarjetas inteligentes
1.1.
20
1. Tarjetas inteligentes
datos que pudieran ser ledos por los lectores apropiados, lo que inicialmente estaba
al alcance nicamente de los usuarios legtimos del sistema. Sin embargo, con el paso
del tiempo la capacidad de leer y modificar el contenido de la banda magntica se
hizo accesible a colectivos al margen de la ley, lo que provoc una nueva evolucin en
las medidas de seguridad. Esta evolucin tuvo lugar en los aos 70 con la introduccin
de los microprocesadores para tarjetas.
La idea de incorporar un circuito integrado a una tarjeta de plstico fue propuesta de forma independiente por Jrgen Dethloff y Helmut Grtrupp en 1968 en
Alemania [59, 60] y por Kunitaka Arimura en 1970 en Japn (ver [223]), pero no
fue hasta que Roland Moreno registr sus patentes a partir de 1975 [248, 249, 250]
cuando comenz su verdadero desarrollo. A mediados de los aos 80 se empezaron
a utilizar tarjetas inteligentes en cabinas telefnicas, y las pruebas de integracin en
telefona mvil permitieron que, en 1991, se eligiera la tarjeta inteligente como el
elemento fundamental de la seguridad del sistema GSM (Global System for Mobile
Communications). De forma paralela, se comenzaron a utilizar tarjetas bancarias
con chip integrado tanto en Francia como Alemania a partir de mediados de los
aos 80. El xito de esta iniciativa fue tal, que en menos de 10 aos todos los bancos
franceses sustituyeron sus tarjetas con banda magntica por tarjetas inteligentes.
Gracias a sus prestaciones y a su alto nivel de seguridad, el uso de las tarjetas
inteligentes ha proliferado con gran xito en los ltimos aos. Entre los entornos de
utilizacin actuales ms destacados pueden citarse los siguientes:
21
Sistema de telefona mvil digital GSM y UMTS (Universal Mobile Telecommunication System), donde toma el papel de mdulo de identificacin del
usuario con las denominaciones SIM (Subscriber Identity Module) y UICC
(Universal Integrated Circuit Card), respectivamente (Figura 1.4).
22
1. Tarjetas inteligentes
Sanidad, donde funciona como un archivo de los aspectos ms relevantes del
historial mdico de un paciente, realizando la identificacin del mismo ante los
sistemas centrales del sistema de sanidad (por ejemplo, Alemania desde 2006
[246], Figura 1.6).
Control de acceso a edificios, con sistemas avanzados que pueden llegar a incluir
elementos biomtricos. En ellos, la tarjeta inteligente almacena todos los datos
necesarios para autenticar a una determinada persona (por ejemplo, los datos
de la huella digitalizada, como se muestra en la Figura 1.7).
1.2.
23
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 tcnicas electromagnticas que no precisen contacto fsico con la tarjeta. La tecnologa de fabricacin
de estos chips ha ido evolucionando con el paso del tiempo, pasando por tecnologas
CMOS (Complementary Metal-Oxide Semiconductor) de 0.8 m, 0.5 m, 0.35 m y
0.13 m actualmente, lo que permite conseguir una mayor densidad de memoria en
el espacio destinado al chip. A este respecto, la cantidad en micras de la tecnologa
de fabricacin hace referencia a la mnima resolucin de la maquinaria responsable
de integrar sus circuitos mediante tcnicas de litografa, ya que la correspondencia
entre tecnologa de integracin y distancia de integracin dej de verificarse a partir
de la tecnologa de 0.25 m [261]. En cuanto a la arquitectura de los microprocesadores, sta puede variar desde los 8 bits en las tarjetas ms bsicas hasta los 32 bits
utilizados para las aplicaciones ms complejas.
Para la fabricacin de las tarjetas inteligentes se parte de una oblea de silicio que
contiene mltiples ejemplares del chip. Una vez identificados y aislados uno a uno los
chips de la oblea, se pegan y se sueldan sobre los contactos. Se aade entonces una
resina protectora que asla al chip de la humedad, formando el elemento denominado
micromdulo.
El plstico, fabricado de forma independiente, es rebajado en la posicin donde
se alojar el chip, de forma que d cabida al mismo bajo los contactos sin daarse.
Utilizando tcnicas de pegado mediante combinacin de calor y presin, el micromdulo se coloca en el hueco formado en el plstico, quedando por tanto el chip
totalmente encapsulado bajo los contactos, de acuerdo a la Figura 1.10.
1.3.
1.3.1.
25
1.3.2.
1.3.2.1.
26
1. Tarjetas inteligentes
27
En comparacin con las tarjetas del apartado anterior, las tarjetas sin contactos
no necesitan contacto fsico con otro elemento, ya que se comunican con el lector
mediante ondas electromagnticas de manera similar a la utilizada en la tecnologa
RFID (Radio Frequency Identification) [40]. La distancia entre la tarjeta y el lector
depende del tipo de tarjeta, pero en general vara desde unos pocos centmetros
hasta un metro.
La Figura 1.12 muestra el diagrama de una tarjeta sin contactos, as como del
lector necesario para acceder a la informacin de la tarjeta.
28
1. Tarjetas inteligentes
1.3.3.
Las tarjetas inteligentes utilizadas en entornos de seguridad normalmente incluyen un coprocesador de apoyo al procesador principal. Los coprocesadores son
circuitos integrados especializados en los clculos de aritmtica modular y la gestin
de enteros de gran tamao, lo que permite liberar de este trabajo al procesador
principal. El uso de coprocesadores permite que ciertas operaciones criptogrficas,
que en otras tarjetas tardaran varios minutos en realizarse, puedan ser completadas
en pocos segundos.
La inclusin de coprocesadores aumenta el precio final de las tarjetas inteligentes, motivo por el cual en algunos entornos (como el de las telecomunicaciones) su
presencia sea actualmente minoritaria.
1.4.
29
30
1. Tarjetas inteligentes
empleado:
PVC (Policloruro de Vinilo): se presenta como un material blanco que comienza a reblandecerse alrededor de los 80 C y se descompone por encima de
140 C.
ABS (Acrilonitrilo Butadieno Estireno): sus cualidades principales son una
baja temperatura de ablandamiento, baja resistencia ambiental e igualmente
baja resistencia a los agentes qumicos.
PC (Policarbonato): presenta un rango de uso desde -100 C a +135 C, con un
punto de fusin cercano a 250 C.
PET (Polietileno Tereftalato): se trata de un plstico con un alto grado de
cristalinidad muy utilizado en envases de bebidas y textiles como sustituto del
PVC.
En lo relativo a sus caractersticas elctricas, tal como se ha anticipado anteriormente, existen tres voltajes de trabajo estandarizados en ISO/IEC 7816-3 [115]:
Clase A: 5 V 10 % (4.5-5.5 V).
Clase B: 3 V 10 % (2.7-3.3 V).
Clase C: 1.8 V 10 % (1.62-1.98 V).
La Figura 1.17 muestra de manera grfica tanto el voltaje asociado a cada clase
como la frecuencia de la seal externa de reloj aplicable a las tarjetas con contactos,
y que debe situarse entre 1 y 20 MHz en los tres casos (excepto durante el proceso
de inicio, donde hasta que se establezca la frecuencia de trabajo final, sta deber situarse obligatoriamente entre 1 y 5 MHz). Como aclaracin, la frecuencia de
1.5. Estndares
31
trabajo del procesador no siempre coincide con la frecuenta suministrada por el dispositivo lector, ya que las tarjetas pueden implementar divisores o multiplicadores
para ajustar la frecuencia interna [226].
Para ms informacin sobre las caractersticas fsicas y lgicas de las tarjetas
inteligentes, se recomienda consultar el libro de Rankl y Effing [226].
1.5.
1.5.1.
Estndares
La norma ISO/IEC 7816
ISO/IEC 7816 es un estndar internacional relacionado con las tarjetas de identificacin electrnicas, en especial las tarjetas inteligentes, creado conjuntamente por
la Organizacin Internacional de Normalizacin (ISO) y la Comisin Electrotcnica
Internacional (IEC), y que se encuentra gestionado por el Comit Tcnico Conjunto
(JTC) 1/Subcomit (SC) 17 [139].
La norma ISO/IEC 7816, que se desglosa a su vez en varias partes, describe los
parmetros para tarjetas de circuito integrado con contactos y el uso de las mismas.
La norma se ha dividido de tal manera que cada parte recoge un aspecto distinto
de las tarjetas inteligentes. Ms especficamente, las partes que componen la norma
son:
Parte 1 [113]: especifica las caractersticas fsicas de las tarjetas, en cuanto al
tamao del plstico, su grosor, etc.
Parte 2 [114]: engloba todos los elementos que definen las dimensiones y la lo-
32
1. Tarjetas inteligentes
calizacin de los contactos. Igualmente, especifica la funcin que debe cumplir
cada uno de estos contactos.
Parte 3 [115]: define las seales elctricas y los protocolos de transmisin halfduplex de caracteres(denominado T=0) y bloques (T=1) que se utilizan sobre
la interfaz ofrecida a travs de los contactos. As, todos los voltajes, intensidades mximas de corrientes, convenciones de paridad, velocidades de transmisin y otros parmetros relacionados con las seales se definen en esta parte
de la norma.
Parte 4 [116]: especifica los comandos para el intercambio de informacin entre el exterior y el circuito integrado de la tarjeta. Estos comandos deben ser
respetados por los fabricantes de tarjetas para garantizar el correcto funcionamiento de tarjetas de diferentes fabricantes. De manera adicional, esta parte
del estndar tambin define la estructura lgica con la que la memoria se divide
en ficheros y los tipos de datos que pueden ser almacenados en las tarjetas.
Parte 5 [117]: define la estructura de los sistemas de numeracin utilizados en
el entorno de las tarjetas inteligentes, as como el procedimiento de registro
para identificadores de aplicacin.
Parte 6 [118]: especifica los elementos de datos utilizados (nombre, descripcin,
formato, codificacin y diseo), as como los medios de recuperacin de dichos
elementos.
Parte 7 [119]: dado que la tarjeta inteligente puede utilizarse como dispositivo
de almacenamiento de datos, en esta parte de la norma se especifican los
comandos utilizados para la gestin de las estructuras de bases de datos y el
lenguaje SCQL (Structured Card Query Language).
Parte 8 [120]: los comandos relacionados con la seguridad son definidos en esta
parte de la norma (siendo complementarios a los definidos en la parte 7816-4).
Se incluyen protocolos para que la tarjeta preste servicios de seguridad (como
algoritmos de cifrado) y mtodos para proporcionar seguridad en la interfaz
entre la tarjeta y el exterior.
Parte 9 [121]: define los comandos para la gestin de ficheros (por ejemplo,
la creacin y borrado de ficheros). Estos comandos abarcan todo el ciclo de
vida de los ficheros en la tarjeta. En un anexo de esta norma se muestra cmo
controlar la carga segura de datos en las tarjetas.
Parte 10 [122]: este documento especifica las seales elctricas y el ATR (Answer to Reset) de las tarjetas sncronas.
Parte 11 [123]: especifica el uso de los comandos y de los datos relacionados con
la verificacin de la identidad de una persona a travs de mtodos biomtricos.
1.5. Estndares
33
1.5.2.
1.5.3.
La norma TS 11.11, desarrollada inicialmente por ETSI (European Telecommunications Standards Institute) y transferida posteriormente a la organizacin 3GPP
34
1. Tarjetas inteligentes
(3rd Generation Partnership Project) [1, 6], define la interfaz entre la tarjeta SIM
y el telfono mvil durante la fase de operacin en red del sistema GSM, as como
la organizacin interna de la informacin en la tarjeta. Mediante esta especificacin,
se asegura la correcta interoperabilidad entre la tarjeta y el terminal, independientemente de los fabricantes de ambos dispositivos.
Entre otros detalles, la norma TS 11.11 especifica:
Los requisitos fsicos a cumplir por la tarjeta SIM en cuanto a seales elctricas
y protocolos de transmisin.
El modelo lgico a utilizar como base para el diseo de la estructura de ficheros
de la tarjeta SIM.
Las funciones de seguridad, haciendo hincapi en el proceso de autenticacin
del usuario frente a la red.
Los comandos y sus respectivas respuestas a transmitir entre el telfono mvil
y la tarjeta SIM.
Los contenidos en detalle de los ficheros para su utilizacin en redes GSM.
Dentro de las caractersticas fsicas se definen dos formatos, conocidos como ID-1
(tamao tarjeta de crdito) y plug-in o mini-SIM (formato de inferior tamao para
poder utilizar la tarjeta dentro de los telfonos mviles, equivalente al formato ID000 del estndar ISO/IEC 7816). En ambos casos, las caractersticas fsicas deben
cumplir los requisitos expresados en la normas ISO 7816-1 y 7816-2, a menos que se
especifique lo contrario.
A nivel elctrico se mantienen los requisitos de la norma 7816-3, aunque en este
caso el nico protocolo obligatorio es T=0, el protocolo semi-dplex asncrono y
orientado a byte [97].
Por ltimo, respecto a la estructura de ficheros, stos se organizan de forma
jerrquica. Existen tres tipos de ficheros elementales: transparentes (secuencia de
bytes sin organizacin interna), lineales con longitud de registro fija (secuencia de
registros todos con la misma longitud) y cclicos con longitud de registro fija (similares a los lineales, con la diferencia de que los registros se sobrescriben por orden
de antigedad).
Por su parte, la norma TS 11.14, igualmente desarrollada por ETSI y transferida
a 3GPP [2, 7], define la interfaz entre la tarjeta SIM y el terminal mvil para
la comunicacin con aplicaciones SIM Application Toolkit (en adelante STK) y
la realizacin de servicios avanzados. STK proporciona mecanismos que permiten
a las aplicaciones residentes en la tarjeta SIM interactuar y operar con cualquier
telfono mvil que implemente dichos mecanismos y sus comandos asociados. Entre
los distintos procedimientos incluidos pueden destacarse los siguientes:
35
1.5.4.
En relacin con sus actividades como uno de los principales emisores de tarjetas
del mundo, Visa International cre la especificacin Visa Open Platform, la cual
define una interfaz interna para la gestin de mltiples aplicaciones dentro de una
misma tarjeta inteligente. Desde 1999, este trabajo es gestionado por la organizacin GlobalPlatform, por lo que sus documentos pasaron a denominarse simplemente
especificaciones Global Platform. Actualmente existen tres comits dentro de GlobalPlatform encargados especficamente de las tarjetas inteligentes, los dispositivos
de lectura y los sistemas de gestin de la informacin relacionada.
El conjunto de requisitos definidos en los documentos Global Platform son independientes del sistema operativo de la tarjeta, aunque en la prctica se haya
convertido en el estndar por defecto para la carga y gestin de aplicaciones en tarjetas Java Card. La Figura 1.18 muestra la arquitectura bsica y los componentes
de Global Platform.
1.6.
36
1. Tarjetas inteligentes
1.6.1.
Puesto que el lenguaje de programacin Java es objeto de un estudio detallado en el Captulo 3, de momento nicamente se mencionar el hecho de que Java
Card es actualmente el sistema operativo abierto de mayor difusin en los principales entornos comerciales de tarjetas inteligentes [210]. La Figura 1.19 muestra la
arquitectura bsica del sistema Java Card.
37
1.6.2.
Tarjetas MULTOS
1.6.3.
38
1. Tarjetas inteligentes
propias de Microsoft.
1.7.
1.7.1.
El trmino OpenCard Framework (OCF) hace referencia a un estndar desarrollado por un consorcio industrial (entre cuyos miembros figuraban mayoritariamente
fabricantes de tarjetas inteligentes, ver Figura 1.21) que proporciona una arquitectura interoperable para la comunicacin con dispositivos lectores y tarjetas inteligentes
disponible en varias plataformas software y hardware. Se trata, por tanto, de un estndar abierto que incluye un conjunto de API (Application Programming Interface)
para posibilitar el desarrollo de aplicaciones mediante la programacin en el lenguaje
Java.
OCF est diseado para funcionar en cualquier plataforma Java, como por ejemplo ordenadores personales, ATMs (Automated Teller Machine), terminales punto
de venta o set-top boxes. El nico requisito que deben cumplir los dispositivos que
utilicen OCF consiste en ser compatibles con la versin Java 1.1.
La arquitectura OCF [100] se compone principalmente de tres elementos:
La capa CardTerminal: proporciona acceso a las tarjetas y a los lectores fsicos
para los que los fabricantes han creado los controladores apropiados. Tambin
incluye las API para los terminales PS/SC soportados. Este mtodo garantiza
la compatibilidad con lectores existentes y futuros.
39
40
1. Tarjetas inteligentes
para acceder a los servicios del lector de tarjetas. Sin embargo, gracias a estndares
como OCF este problema queda parcialmente solucionado, al disponer de un canal
por el que es posible enviar cualquier APDU independientemente del dispositivo
lector y de la tarjeta inteligente empleados (siempre que el lector sea compatible con
la arquitectura OCF).
El OpenCard Consortium se disolvi tras la publicacin de su versin 1.2, quedando su tecnologa obsoleta tras la aparicin del API Java Smartcard I/O [211],
aunque todava puede encontrarse informacin en forma de proyectos evolucionados
a partir de OCF como Open Smart Card Development Platform (OpenSCDP) [39]
o de repositorios de la informacin original en Sourceforge [252].
1.7.2.
Arquitectura PC/SC
41
1.8.
En las tarjetas Java Card es posible utilizar dos modelos de comunicacin diferentes. Por una parte se encuentra el modelo basado en APDU; por otra, el esquema
que emplea la tecnologa JCRMI (Java Card Remote Method Invocation), que es
un subconjunto del modelo RMI (Remote Method Invocation) presente en Java.
El modelo de comunicacin que se muestra en la Figura 1.24 representa el mecanismo ms extendido para la comunicacin con una tarjeta inteligente. Las APDU,
construidas de acuerdo a las especificaciones ISO/IEC 7816-3 y 7816-4, constituyen
los paquetes de datos que son intercambiados entre la aplicacin externa y la tarjeta. El sistema operativo de la tarjeta se encarga de analizar las APDU recibidas
y de encaminarlas a la aplicacin adecuada a la que van destinadas, recogiendo la
42
1. Tarjetas inteligentes
43
respuesta de la aplicacin para su envo al lector de tarjetas (y con ello, a la aplicacin que se comunica con el propio lector, ya sea un programa en un ordenador, el
sistema operativo de un telfono mvil, etc.).
1.8.1.
44
1. Tarjetas inteligentes
Tipo de instruccin
Instrucciones estndar 7816-4
Reservado
Instrucciones 7816-4 especficas para aplicaciones
Instrucciones especficas de aplicacin o fabricante
Instrucciones especficas de aplicacin o fabricante
Instrucciones especficas de aplicacin o fabricante
Reservado para seleccin de tipo de protocolo
INS (1 byte): este campo obligatorio sirve para indicar una instruccin especfica dentro de la clase representada por el campo CLA. El estndar ISO/IEC
7816-4 especifica las instrucciones bsicas para acceder a los datos de una
tarjeta cuya estructura interna est implementada de acuerdo al estndar. El
Cuadro 1.2 presenta algunas de las instrucciones ISO/IEC 7816 ms tpicas.
P1 (1 byte, obligatorio): este campo define el primer parmetro asociado a la
instruccin. Se puede utilizar para dar ms informacin sobre la instruccin,
o bien como dato de entrada.
P2 (1 byte, obligatorio): este campo define el segundo parmetro asociado a
la instruccin. Al igual que en el caso anterior, se puede utilizar para dar ms
informacin sobre la instruccin, o como dato de entrada.
Lc (1 byte, opcional): este valor representa el nmero de bytes del campo de
datos del comando. Puesto que el valor mximo es 0xFF, la longitud mxima
de los datos es de 255 bytes, aunque algunas tarjetas permiten enviar datos de
256 bytes de longitud utilizando el valor 0x00.
Data (tamao variable, opcional): este campo incluye los datos del comando.
Le (1 byte, opcional): este campo indica el mximo nmero de bytes a incluir
en el campo de datos de la respuesta esperada.
Si se utiliza el protocolo T=0, dependiendo de la presencia de datos en el comando, y de si es necesaria una respuesta, existen cuatro variantes del comando
45
Nombre de la instruccin
Erase Binary
Verify
Manage Channel
External Authenticate
Get Challenge
Internal Authenticate
Select File
Read Binary
Read Record
Get Response
Envelope
Get Data
Write Binary
Write Record
Update Binary
Put Data
Update Record
Append Record
APDU, tal como puede comprobarse en la Figura 1.26. De forma habitual, las aplicaciones utilizan varios comandos APDU con distintas estructuras de datos durante
su ejecucin.
46
1. Tarjetas inteligentes
1.8.2.
Al igual que los comandos, las APDU de tipo respuesta incluyen campos tanto
obligatorios como opcionales:
Datos (longitud variable, dependiente del campo Le del comando APDU, carcter opcional): este campo contiene los datos devueltos por la aplicacin de
la tarjeta.
SW1 (1 byte, obligatorio): este campo constituye el primer byte de estado,
que proporciona informacin general sobre el resultado de la ejecucin del
comando.
SW2 (1 byte, obligatorio): este campo constituye el segundo byte de estado,
que proporciona informacin adicional a la ofrecida por el primer byte de
estado.
Los valores posibles para los bytes de estado estn definidos en la especificacin
ISO 7816-4. La Figura 1.28 muestra de forma grfica la clasificacin de los posibles
bytes de estado.
47
Captulo 2
Criptografa de clave pblica basada
en curvas elpticas
2.1.
Introduccin
50
1 2
forma =
1 2 , donde los valores representan nmeros primos
distintos, cada uno con orden de multiplicidad 1.
Logaritmo discreto (DLP)
Dado el conjunto de los nmeros enteros mdulo un nmero primo , un
generador del grupo multiplicativo y un elemento , el problema del
51
2.2.
Establecimiento de clave
Firma digital
Aplicaciones prcticas
Cifrado/descifrado
2.2.1.
Establecimiento de clave
Establecimiento de clave
Transporte de clave
Acuerdo de clave
52
2.2.2.
Firma digital
La firma digital tiene como objetivo cumplir los objetivos de integridad, autenticacin y no repudio, de manera que una firma electrnica sea equivalente a una
firma manuscrita en cualquier transaccin [78, 172]. Desde el punto de vista tcnico
y de forma simplificada, una firma digital es el resultado de cifrar la salida obtenida mediante una funcin resumen de una determinada informacin, de manera
que cualquier usuario pueda verificar la identidad de la persona que firm los datos
y garantizar que la informacin objeto de la comprobacin no ha sido modificada
desde su firma.
Las firmas digitales pueden dividirse en dos grupos: con anexo y con recuperacin
del mensaje. En las firmas con anexo, es necesario disponer tanto de la firma digital
como del mensaje original a fin de poder realizar la comprobacin de la firma. Por
el contrario, en las firmas digitales con recuperacin del mensaje, el propio mensaje
se extrae del contenido de la firma.
Firma digital
Con anexo
2.2.3.
53
Cifrado/descifrado
54
2.3.
55
56
Como se puede observar en la Figura 2.1, los conceptos IND-ACCA y NMACCA son equivalentes, siendo los ataques de tipo ACCA los que cuentan con
mayor potencial para comprometer cualquier esquema de cifrado de clave pblica.
De manera similar, se puede considerar que los conceptos NM-ACCA y NM-CCA
son equivalentes, as como los conceptos NM-CPA e IND-CCA.
2.4.
57
tan la clave privada y pblica respectivamente del usuario U, el mensaje original sin
cifrar se denotar por la letra , la informacin cifrada ser identificada como , y
el criptograma incluye no solamente el mensaje cifrado sino tambin los elementos
adicionales que el receptor del criptograma necesita para proceder a su descifrado (aunque en algunas ocasiones, ante la falta de dichos elementos adicionales, el
criptograma ser completamente equivalente al mensaje cifrado ).
2.4.1.
2.4.1.1.
Descripcin
En su ya clsico documento de 1976, Whitfield Diffie y Martin Hellman [61] presentaron una manera de resolver las necesidades de seguridad del momento mediante
el novedoso concepto de criptografa de clave pblica. El sistema propuesto, conocido desde entonces como protocolo de establecimiento o acuerdo de clave de DiffieHellman, representa un mecanismo por el que dos usuarios intercambian pequeas
cantidades de informacin a travs de un canal que habitualmente es considerado
inseguro de manera que, al final del procedimiento, nicamente ellos conozcan la
clave secreta compartida [61, 172].
Es importante tener en cuenta que el protocolo de acuerdo de clave DiffieHellman, tal como fue planteado por sus autores, no constituye un criptosistema,
puesto que no lleva a cabo el cifrado y descifrado de informacin, sino que slo
permite el intercambio de pequeas cantidades de informacin a fin de derivar una
clave secreta. En su propuesta, Diffie y Hellman se limitaron a describir de forma
general los conceptos de firma digital, cifrado asimtrico y establecimiento de clave,
aunque s incluyeron indicaciones para la implementacin del esquema de acuerdo
de clave.
El protocolo Diffie-Hellman, recogido en el Algoritmo 2.1, presenta de manera
ordenada los pasos que los usuarios participantes en el intercambio deben dar a fin
de obtener una clave secreta comn con la que poder cifrar toda la comunicacin
posterior [148].
Despus de llevar a cabo los pasos anteriores, U y V conocen y comparten un
elemento comn del grupo y que es desconocido para cualquier otro usuario.
Dicho elemento es el siguiente:
( ) = ( ) = .
Si en el Algoritmo 2.1 los valores y son fijos, y en lugar de generar los
elementos y en cada transmisin dichos valores son obtenidos de un servidor
de claves, nos encontramos ante una versin del protocolo de intercambio Diffie-
58
Ejemplo
59
Seguridad
2.4.2.
Criptosistema RSA
2.4.2.1.
Descripcin
En 1978, Ron Rivest, Adi Shamir y Leonard Adleman [229] propusieron una
implementacin prctica de los conceptos presentados anteriormente por Diffie y
Hellman. Aprovechando la dificultad de factorizar nmeros enteros muy grandes,
describieron los pasos necesarios para cifrar y descifrar mensajes que previamente
hubieran sido convertidos en cadenas numricas. Su propuesta inclua detalles sobre
cmo realizar las operaciones de cifrado y descifrado de forma eficiente, y cmo
60
calcular los parmetros que componen las claves pblicas y privadas. El esquema
de cifrado, tal como est descrito en [229], es independiente del tipo de mensaje,
estando la informacin cifrada directamente con la clave pblica y no por una
clave simtrica temporal. En 1983 les fue concedida la patente que solicitaron en
1977 [164], aunque en el ao 2000 los autores dejaron sin efecto dicha patente para
que el algoritmo RSA pudiera ser utilizado libremente.
El protocolo RSA consta de tres partes [66, 232]:
1. Generacin de las claves.
2. Cifrado del mensaje.
3. Descifrado del mensaje.
En los siguientes apartados se describen en detalle las fases mencionadas.
Generacin de las claves
Cada usuario (lo que representa tanto al usuario U que desea enviar el mensaje
como al usuario V que recibe la informacin cifrada , equivalente en este caso al
criptosistema ) debe elegir su par de claves, pblica y privada. Para ello es necesario
completar los pasos del Algoritmo 2.2, descrito utilizando la notacin del usuario V.
Algoritmo 2.2 Generacin de claves RSA
1. Elegir dos nmeros primos grandes y distintos pero de, aproximadamente, el mismo tamao.
2. Calcular los valores = y () = ( 1) ( 1), donde la funcin
() es el indicador de Euler para el nmero .
3. Elegir de forma aleatoria un entero positivo , con 2 < < (), tal que
mcd(, ()) = 1.
4. Calcular, mediante el algoritmo de Euclides extendido, el nico entero que
verifica 1 < < (), de modo que 1 (mod ()).
5. Asignar como clave pblica del usuario V el par = (, ), siendo su
clave privada correspondiente = . Adems del elemento , tambin deben
permanecer secretos los nmeros , y ().
A los valores y as obtenidos se les denomina exponente de cifrado y exponente
de descifrado, respectivamente. Por su parte, el entero se denomina mdulo del
criptosistema RSA.
61
(mod ),
(mod ) = ( )
(mod ) =
(mod ) = ,
2.4.2.2.
Ejemplo
62
63
7 0, 7 1, 7 2, . . . , 7 24, 7 25.
Este sistema emplea la base 26 para representar cualquier palabra. De este
modo, como se verifica la desigualdad
263 = 17576 < = 199543 < 456976 = 264 ,
cada mensaje parcial puede contener, como mximo, tres letras. En el ejemplo
considerado se utilizarn las letras
7 17, 7 18, 7 0,
con lo que el mensaje es
= RSA 7 = 17 262 + 18 26 + 0 = 11492 + 468 + 0 = 11960.
Antes de proceder al cifrado, U debe comprobar que el mximo comn divisor
de 199543 y 11960 es 1, lo que efectivamente ocurre en este caso.
3. A continuacin, U cifrar el mensaje anterior mediante el siguiente clculo:
Este valor podra escribirse en base hexadecimal para ser enviado a su destinatario, o transformarlo de nuevo a base 26 para convertirlo en letras. En este
ltimo caso:
= 15446 = 22 262 + 22 26 + 2 7 = WWC.
Descifrado del mensaje
Una vez que el usuario V reciba el mensaje cifrado enviado por U, =WWC,
debe realizar los pasos indicados en 2.4.2.1:
1. Recuperar su clave privada; en este caso = = 132427.
2. A continuacin, debe representar el mensaje cifrado en base 26 como un nmero, obteniendo = 15446. Hecho esto, V descifrar el criptograma mediante
las siguientes operaciones:
= (mod ) 15446132427 (mod 199543) = 11960 (mod 199543) ,
= 11960 = 17 262 + 18 26 + 0 7 = RSA.
64
2.4.2.3.
Seguridad
2.4.3.
Criptosistema de El Gamal
2.4.3.1.
Descripcin
En 1985, Taher ElGamal [69] propuso un esquema de firma digital y cifrado que
utilizaba la clave pblica de V para cifrar una clave simtrica , con la que a su vez
se cifraba el mensaje original. La principal novedad de su propuesta consista en unir
para su envo tanto la clave simtrica temporal como la informacin original cifrada
con dicha clave, aprovechando la complejidad del clculo de los logaritmos sobre
cuerpos finitos. En su propuesta, ElGamal aconsejaba no cifrar ms de un mensaje
(o ms de un bloque del mensaje original, si por su longitud el mensaje deba ser
65
dividido en varias partes) con la misma clave , por lo que en la prctica una
nueva clave siempre acompaar al mensaje cifrado en cada envo de informacin
confidencial de U a V.
Como en todo criptosistema de clave pblica, en el de ElGamal se pueden identificar tres fases [179]:
1. Generacin de claves.
2. Cifrado de mensajes.
3. Descifrado de mensajes.
Generacin de claves
Todo usuario V que desee generar claves para el criptosistema de ElGamal debe
seguir el Algoritmo 2.5.
Algoritmo 2.5 Generacin de claves para el criptosistema ElGamal
1. Generar un nmero primo grande (de alrededor de 300-310 dgitos, es
decir, de aproximadamente 1024 bits).
2. Elegir un generador del grupo multiplicativo .
3. Generar un nmero aleatorio , con 2 2, y calcular el valor de
(mod ).
4. Asignar como clave pblica de V el tro = (, , ), siendo su clave
privada el nmero . En caso de que todos los usuarios utilicen los mismos
valores y , la clave pblica del usuario V quedara reducida al elemento
= .
Cifrado de mensajes
Si el usuario U desea enviar un mensaje cifrado al usuario V, U debe seguir
los pasos indicados en el Algoritmo 2.6.
El factor de expansin del algoritmo de ElGamal es igual a 2, debido a que la
longitud del criptograma es el doble de la longitud del mensaje a cifrar, considerando
que tanto el valor numrico del mensaje, , como los elementos y , se codifican
en formato binario utilizando log2 bits.
66
= ( ) (mod ) .
2.4.3.2.
Ejemplo
67
68
Seguridad
2.5.
Los esquemas de cifrado de clave pblica integrados representan modelos hbridos en los cuales se utiliza un sistema de clave pblica para transportar una clave
de sesin que ser posteriormente utilizada por un algoritmo de cifrado simtrico.
Aunque es cierto que durante los aos 90 surgieron algunos esquemas de cifrado que
establecieron las bases de lo que se conoce actualmente como cifrado hbrido [9, 155],
no fue hasta el ao 2001 cuando Shoup [243] estableci formalmente los conceptos
en los que se basan este tipo de esquemas [25].
69
2.5.1.
2.5.2.
70
2.5.3.
2.6.
71
Por su parte, Victor Miller [174] realiz su propuesta desde un punto de vista ms
terico en relacin al modelo general descrito por Diffie y Hellman, pero sin realizar
comparaciones con otras implementaciones existentes.
En los siguientes apartados se presentan los conceptos fundamentales relacionados con las curvas elpticas y con su aplicacin a la criptografa.
2.6.1.
Se considera que dicha curva tiene puntos racionales cuando las coordenadas del
punto pertenecen al cuerpo (no necesariamente ) [244]. La existencia de puntos
racionales en una curva depende del gnero de la propia curva, concepto derivado
del teorema de Riemann [227] y que permite clasificar las curvas planas en funcin
del grado del polinomio que la define y de sus singularidades mediante la expresin
(2.1)
( 1)( 2) ( 1)
,
2
2
72
73
En funcin del gnero de una curva, es posible establecer unas pautas sobre
la posible existencia o no de puntos racionales (y como caso particular, de puntos
enteros donde las coordenadas necesariamente pertenecen a ), tal como se resume
a continuacin [140]:
Una curva de gnero = 0 no tiene puntos racionales o bien tiene infinitos.
Sin embargo, puede no tener puntos enteros, tener una cantidad finita de ellos
o tener infinitos.
Una curva de gnero = 1 no tiene puntos racionales, tiene un nmero finito
de ellos o bien tiene infinitos, pero slo puede tener una cantidad finita de
puntos enteros.
Una curva de gnero 2 slo puede tener una cantidad finita de puntos
racionales.
A partir de las definiciones anteriores, se puede afirmar que una curva elptica
sobre el cuerpo es una curva proyectiva regular de gnero 1 que tiene al menos
un punto racional [140, 149, 245]. Toda curva elptica admite un tipo de ecuacin
cannica llamada forma de Weierstrass, cuya expresin en coordenadas homogneas
es
(2.2)
: 2 + 1 + 3 2 = 3 + 2 2 + 4 3 + 6 6 ,
En la prctica, la ecuacin de Weirstrass se suele expresar en su forma no homognea, donde la relacin entre ambas ecuaciones es (, ) = (, , 1), y alternativamente (, , ) = (/, /) 3 , resultando la siguiente ecuacin afn:
(2.3)
: 2 + 1 + 3 = 3 + 2 2 + 4 + 6 .
Las Figuras 2.4 y 2.5 muestran dos ejemplos de curvas elpticas definidas sobre
el cuerpo de los nmeros reales.
74
75
2.6.2.
Estructura de grupo
Sea una curva elptica sobre un cuerpo definida mediante la ecuacin (2.3),
y sean los puntos de la curva = ( , ), = ( , ) y = ( , ), donde
= [0 : 1 : 0] representa el punto en el infinito en coordenadas homogneas. En
estas condiciones, se define la operacin + de la siguiente manera [50, 148, 245]:
1. Para todo punto de la curva, + = + = .
2. Dado un punto , entonces = ( , 1 3 ), de manera que
+ ( ) = . Es importante resaltar que y son los nicos puntos de
la curva cuya primera coordenada es .
3. Dados dos puntos y tales que = , entonces = + , con
= 2 + 1 2 ,
= ( ) 1 3 ,
76
= 2 + 1 2 ,
= ( ) 1 3 ,
3 2
+ 2 2 + 4 1
.
2 + 1 + 3
77
78
2.6.3.
2.6.3.1.
79
Se define el orden de una curva sobre un cuerpo de caracterstica , denotndose mediante la expresin #( ), como el nmero de puntos de ( ). Si
el cuerpo sobre el que est definido la curva es finito, entonces el orden de la curva
siempre ser finito, y estar formado por los puntos que satisfacen la ecuacin de la
curva ms el punto en el infinito.
El teorema de Hasse [143] determina la siguiente expresin para el orden de una
curva:
#( ) = + 1 ,
2 ,
80
2.6.3.3.
36
216
24
2 = 3 + + ,
(2.4)
cuyo discriminante pasa a ser
= 16 (43 + 272 ).
2. Si la caracterstica de es 2 aparecen dos casos distintos dependiendo del valor
de 1 .
a) Si 1 = 0, entonces el cambio de variables
(
)
3 3
21 4 + 23
2
(, ) 1 + , 1 +
1
31
transforma la curva dada por la ecuacin (2.3) en la curva
(2.5)
2 + = 3 + 2 + .
(2.6)
2 + = 3 + + .
81
= 4 .
3. Si la caracterstica de es 3, de nuevo nos encontramos con dos casos distintos
en funcin del valor de 1 .
a) Si 21 = 2 , entonces el cambio de variables
)
(
24 + 1 3
24 + 1 3
, + 1 + 1 2
+ 3
(, ) + 2
1 + 42
1 + 42
transforma la curva dada por la ecuacin (2.3) en la curva
(2.7)
2 = 3 + 2 + .
(2.8)
2 = 3 + + .
82
Car. de
Ecuacin
2
= 2, 3
= 3 + +
2
2 + = 3 + 2 +
2
2 + = 3 + +
3
2 = 3 + 2 +
3
2 = 3 + +
Supersingular
No
No
S
No
S
Condicin
1 = 0
1 = 0
2
1 = 2
21 = 2
2.6.3.4.
= 2 ,
= ( ) ,
= 2 2 ,
= ( ) ,
3 2 +
.
2
83
mientras que para obtener 2 a partir del punto es necesario realizar 1 inversin,
2 multiplicaciones y 2 elevaciones al cuadrado en . Las operaciones de suma y
diferencia de elementos del cuerpo finito no se suelen contabilizar debido a que, en
comparacin con las otras operaciones mencionadas, son las que requieren menor
tiempo de computacin.
Las siguientes figuras muestran de forma grfica las siguientes operaciones realizadas en la curva 2 = 3 + 11 + 3 definida sobre 17 : suma de los puntos = (4, 3)
y = (9, 7), con resultado = (6, 9) (Figura 2.10); suma de = (7, 7) con
= (7, 7), siendo el resultado = 2 = (2, 13) (Figura 2.11) y suma de = (7, 7)
con 2 = (2, 13), siendo el resultado = 3 = (4, 3) (Figura 2.12).
84
85
= 2 + + + + ,
= ( + ) + + ,
.
=
= 2 + + ,
= ( + ) + + ,
= +
.
Con las frmulas anteriores, tanto la suma de dos puntos y como la obtencin
de 2 a partir del punto necesitan 1 inversin, 2 multiplicaciones y 1 elevacin al
cuadrado en 2 . Al igual que en el caso de los cuerpos primos, las operaciones de
suma y diferencia de elementos del cuerpo binario no se han contabilizado debido a
su menor tiempo de ejecucin respecto al de las otras operaciones referidas, por lo
que su aportacin al tiempo de procesamiento total puede considerarse despreciable.
2.6.3.5.
86
2.6.4.
#( )
.
= (0 , 1 , . . . , 1 ),
donde {0, 1} ,
=0
Bases polinmicas
87
Bases normales
2 ,
donde {0, 1} .
=0
En el caso de las bases normales, a los elementos 2 se les suele representar como la cadena de bits (0 1 . . . 1 ) de longitud (ntese el cambio en el
orden de los subndices respecto a las bases polinmicas), donde {0, 1}. Empleando esta tcnica, el elemento unitario se representa mediante la cadena de bits
(1 1 . . . 1 1 1), mientras que el elemento neutro queda representado mediante la cadena (0 0 . . . 0 0 0). Al igual que en las bases polinmicas, la suma de dos elementos
de 2 se realiza mediante la operacin XOR aplicada sobre los bits de las cadenas
que los representan.
88
La ventaja de las bases normales consiste en que la operacin de elevar al cuadrado un elemento se realiza de forma muy rpida, puesto que si = (0 1 . . . 1 ),
entonces su cuadrado resulta ser 2 = (1 0 1 . . . 2 ). Multiplicar dos elementos distintos es, sin embargo, mucho ms complicado, por lo que en la prctica
se utilizan bases normales gaussianas.
Las bases normales gaussianas constituyen un subconjunto de las bases normales,
estando caracterizadas por el hecho de que el valor no debe ser divisible por 8
[15]. Se denomina tipo de la base normal gaussiana (y se representa mediante la
letra ) al nmero entero positivo que indica la complejidad de la operacin de
multiplicacin con respecto a la base, de manera que cuando ms pequeo sea ese
nmero, ms eficiente ser la multiplicacin. Para unos valores determinados de
y , el cuerpo 2 puede tener como mucho una base normal gaussiana de tipo ,
siendo las bases normales gaussianas de tipo 1 y 2 las que poseen las operaciones de
multiplicacin ms eficientes, por lo que se las denomina bases normales ptimas.
Aunque las bases normales permiten obtener implementaciones ms eficientes
de la aritmtica de puntos en curvas definidas sobre cuerpos binarios, su utilizacin
se encuentra controlada por las patentes descritas en 2.6.9, motivo por el cual las
implementaciones de software libre de curvas elpticas utilizan en su lugar las bases
polinmicas.
2.6.5.
89
90
2.6.6.
91
2.6.7.
Seguridad
2.6.7.1.
Curvas supersingulares
Las curvas definidas sobre el cuerpo con caracterstica se denominan supersingulares si cumplen la condicin #( ) 1 (mod ) [265]. En curvas sobre ,
por ejemplo, una curva supersingular contendr exactamente + 1 elementos.
El ataque de Frey y Rck [76], que es una generalizacin del trabajo de Menezes,
Okamoto y Vanstone [170] (conocido habitualmente como el ataque MOV), reduce
el ECDLP en una curva definida supersingular sobre ( ) al DLP definido en un
cuerpo finito
para algn 1, el cual es ms sencillo de resolver.
92
Curvas anmalas
Descenso de Weil
En 2002, Gaudry, Hess y Smart [91] adaptaron una idea de Frey [77] para resolver
el ECDLP utilizando el descenso de Weil para convertir el ECDLP en un problema de
curvas hiperelpticas. Tanto Jacobson, Menezes y Stein [141] como Maurer, Menezes
y Teske [167] encontraron varias curvas definidas sobre cuerpo 2 , siendo un
nmero compuesto, donde el mtodo era viable.
Por otra parte, Menezes y Qu [173] demostraron que este mtodo no es aplicable
a cuerpos finitos 2 cuando es un nmero primo, por lo que los estndares y
recomendaciones ms recientes nicamente incluyen (en los apartados que tratan
sobre cuerpos binarios) curvas elpticas donde es un nmero primo.
2.6.8.
Estndares relacionados
93
ISO
La Organizacin Internacional para la Estandarizacin (International Organization for Standardization o ISO) es el organismo encargado de promover
el desarrollo de las normas internacionales de fabricacin, comercio y comunicacin para todas las ramas industriales (a excepcin de la elctrica y la
electrnica), especialmente en los temas relacionados con las normas de productos y seguridad para las empresas y organizaciones a nivel internacional.
IEC
La Comisin Electrotcnica Internacional (International Electrotechnical Commission o IEC) es un organismo de estandarizacin en los campos elctrico,
electrnico y de otras tecnologas relacionadas. Numerosas normas se desarrollan conjuntamente con ISO, siendo entonces denominadas normas ISO/IEC.
IEEE
El Instituto de Ingenieros Elctricos y Electrnicos (Institute of Electrical and
Electronics Engineers o IEEE) es una asociacin tcnico-profesional mundial
dedicada a la estandarizacin de tecnologas derivadas de la electricidad: ingeniera computacional, tecnologas biomdica y aeroespacial, energa elctrica,
control, telecomunicaciones, electrnica de consumo, etc.
IETF
El Grupo de Trabajo en Ingeniera de Internet (Internet Engineering Task
Force o IETF) es una organizacin internacional de estandarizacin que tiene
como objetivo velar para que la arquitectura de la red y los protocolos tcnicos de Internet funcionen correctamente, actuando en reas como transporte,
seguridad, etc.
ANSI
El Instituto Nacional Estadounidense de Estndares (American National Standards Institute o ANSI) es una organizacin sin nimo de lucro que supervisa
el desarrollo de estndares para productos, servicios, procesos y sistemas en
los Estados Unidos, siendo miembro de ISO y de IEC. ANSI tambin se encarga de coordinar estndares estadounidenses con estndares internacionales,
de modo que los productos de Estados Unidos puedan utilizarse en todo el
mundo.
NIST
El Instituto Nacional de Estndares y Tecnologa (National Institute of Standards and Technology o NIST) es una agencia de la Administracin de Tecnologa del Departamento de Comercio de los Estados Unidos. La misin de este
instituto es promover la innovacin y la competencia industrial en Estados
Unidos mediante avances en las normas aplicadas y en la propia tecnologa.
94
La norma FIPS 186-2 [184] incluye los algoritmos y esquemas de firma digital que
pueden ser empleados por las distintas agencias del gobierno de los EE.UU. Dichos
algoritmos son DSA, RSA y ECDSA (Elliptic Curve Digital Signature Algorithm).
ECDSA es el equivalente al algoritmo DSA empleando curvas elpticas [257].
En los apndices de FIPS 186-2 [184] y en el estndar ANSI X9.62 [15] se presenta
el esquema ECDSA y se describen distintas curvas que pueden ser utilizadas en los
procedimientos de firma. Aunque el documento [184] slo tiene mbito de aplicacin
interna en los EE.UU., al ser informacin de dominio pblico, en la prctica se utiliza
tambin fuera de ese mbito.
El esquema ECDSA tambin se encuentra recogido en el estndar IEEE 1363
[108] y en el documento SEC 1 [254]. Por ltimo, ECDSA es el algoritmo seleccionado
por la NSA en la Suite B [194].
95
Protocolos de cifrado
Los primeros esquemas de cifrado basados en curvas elpticas que surgieron fueron el equivalente de los sistemas Massey-Omura [205] y ElGamal [69], ambos presentados por Koblitz en 1985 (y publicados en 1987) [147] y el Menezes-Vanstone
Elliptic Curve Cryptosystem [169], de los que se proporcionan detalles adicionales
en 4.1.
El esquema de cifrado y descifrado ms extendido en la actualidad que emplea
curvas elpticas es conocido de forma genrica como ECIES (Elliptic Curve Integrated Encryption Scheme), y se basa en el modelo propuesto por Bellare y Rogaway
en 1997 [26] y refinado posteriormente por Abdalla, Bellare y Rogaway en 1998 [8]
y 2001 [9, 10], constituyendo una variante del esquema ElGamal.
ECIES puede encontrarse en el estndar ANSI X9.63 [16], en el anexo IEEE
1363a [109] al documento IEEE 1363 [108] y en el estndar ISO/IEC 18033-2 [136].
Asimismo, puede encontrarse una amplia descripcin de ECIES, as como numerosos
detalles tcnicos para su implementacin, en el documento SEC 1 [254] realizado por
el consorcio industrial SECG.
2.6.9.
Patentes
96
97
US 6.704.870 - Digital signatures on a smartcard [46]: describe una implementacin del algoritmo ECDSA con ciertas modificaciones que tiene en consideracin las limitaciones de las tarjetas inteligentes.
US 6.782.100 - Accelerated finite field operations on an elliptic curve [47]:
recoge una optimizacin para la multiplicacin en cuerpos 2 de un punto de
la curva cuya caracterstica principal consiste en no emplear en ciertos pasos
la segunda coordenada, recuperando el valor de la segunda coordenada del
producto al final de la operacin.
EP 1 496 644 A2 - Method for signature and session key generation [41]: describe el protocolo de acuerdo de clave MQV, representando una continuacin
de la patente EP 0 739 105 A1 (no incluida en este listado por ese motivo).
Captulo 3
Capacidades criptogrficas en Java
3.1.
100
3.1.1.
Encapsulacin
3.1.2.
Herencia
La herencia es un concepto que relaciona clases de manera jerrquica. Esto permite que los descendientes de una clase hereden todas las variables y mtodos de sus
ascendientes, adems de crear los suyos propios. A estos descendientes se les llama
subclases. Al padre inmediato de una clase se le denomina superclase. Una subclase
es una versin especializada de su superclase correspondiente que hereda todos sus
mtodos y variables de instancia.
3.1.3.
Polimorfismo
A los mtodos que actan sobre los objetos se les pasa informacin en forma
de parmetros en la llamada al mtodo. Estos parmetros representan los valores
de entrada a cada funcin implementada por la aplicacin. Para completar dos
tareas diferentes en la mayora de los lenguajes de programacin es necesario tener
dos funciones independientes con nombres diferentes. El polimorfismo (un objeto y
muchas formas) es un concepto simple que permite que un mtodo tenga mltiples
implementaciones que se seleccionan en base al tipo de objeto que se le pasa en la
llamada al mtodo, lo que se conoce como sobrecarga del mtodo.
3.2.
3.2.1.
El lenguaje Java
Introduccin al lenguaje Java
Los orgenes de Java se remontan al ao 1990, cuando un equipo de la compaa Sun Microsystems investigaba, bajo la direccin de James Gosling, el diseo y
101
102
103
Java Enterprise Edition (Java EE): esta edicin constituye un conjunto ampliado respecto de la versin Standard, estando orientada a entornos empresariales.
Java Micro Edition (Java ME): esta versin define un subconjunto extendido
de la edicin Standard, especialmente diseada para su utilizacin en telfonos
mviles y PDAs (Personal Digital Assistant).
Java Card (JC): es la versin especfica del lenguaje Java para el mercado de
tarjetas inteligentes.
La Figura 3.1 muestra de manera grfica las distintas ediciones del lenguaje Java.
3.2.2.
El Java Runtime Environment (JRE) es el software necesario para ejecutar cualquier aplicacin desarrollada para la plataforma Java. El usuario final utiliza el JRE
como parte del entorno Java instalado o como conectores (plugins) en sus navegadores web [57].
El JRE est constituido por una Java Virtual Machine (JVM), que es el programa
que interpreta el cdigo Java, y por las libreras de clases estndar que implementan
las diferentes API de Java. Ambos elementos, JVM y API, deben ser consistentes
entre s, de ah que sean distribuidas de forma conjunta.
La mquina virtual Java se inicia automticamente cuando se lanza el proceso
que se desea ejecutar y se detiene cuando ste finaliza. Su objetivo es el de proporcionar un entorno de ejecucin independiente de la plataforma hardware y del
104
105
3.2.3.
106
107
108
Adems, se definieron los nombres estndar que podan ser utilizados en las
llamadas a las clases, tal como se indica a continuacin:
Cipher: ECIES.
KeyPairGenerator: EC.
KeyFactory: EC.
KeyAgreement: ECDH, ECMQV.
Signature: NONEwithECDSA, SHA1withECDSA, SHA256withECDSA, SHA384withECDSA y SHA512withECDSA.
Con estos elementos, aunque los motores criptogrficos de Sun no incluyan implementaciones de ECC, las aplicaciones que deseen utilizar funcionalidades de criptografa de curva elptica al menos pueden hacer uso de bibliotecas criptogrficas
interoperables y adaptadas a la arquitectura JCA/JCE que hayan sido desarrolladas por terceras empresas.
3.3.
Bibliotecas criptogrficas
3.3.1.
109
Cryptix
Cryptix [56] fue la primera biblioteca criptogrfica de cdigo libre para el desarrollo de aplicaciones Java. Entre los subproyectos gestionados en el mbito de Cryptix
destacan un proveedor JCE para JDK 1.1.x, 1.2, 1.3 y 1.4 (Cryptix JCE), una implementacin Java del estndar OpenPGP (Cryptix OpenPGP) y un paquete para
la utilizacin de criptografa de curva elptica (Cryptix Elliptix).
Sin actividad desde 2005, en su propia pgina web se indica que el proyecto se
encuentra abandonado. Sin embargo, a efectos comparativos con otras distribuciones
resulta interesante conocer el grado de desarrollo del paquete Cryptix Elliptix. Su
objetivo era poder proporcionar una implementacin Java de los estndares IEEE
1363 [108], ANSI X9.62 [15] y X9.63 [16]. En la ltima versin proporcionada, el
paquete inclua soporte para aritmtica tanto sobre (con coordenadas proyectivas)
como sobre 2 (con coordenadas afines sobre base polinmica). Sin embargo, no
proporcionaba soporte para la generacin de los parmetros de la curva. Asimismo,
las operaciones de alto nivel (por ejemplo, la firma digital y la verificacin de dichas
firmas) tampoco estaban disponibles en dicha versin.
3.3.2.
Bouncy Castle
110
3.3.3.
IAIK
El Institut fr Angewandte Informationsverarbeitung und Kommunikationstechnologie (Institute for Applied Information Processing and Communications) de la
Universidad de Graz [260] ha desarrollado un conjunto de herramientas criptogrficas escritas en Java, cuyos principales exponentes son IAIK-JCE (mdulo principal
con los algoritmos RSA, DES, AES, Blowfish, etc., y cuya versin ms reciente es la
3.18, lanzada en agosto de 2009), IAIK-iSaSiLk (implementacin Java de TLS 1.0 y
SSL 3.0, cuya versin 4.4 est disponible desde febrero de 2010) e IAIK-ECC (cuya
versin 2.19 fue lanzada en agosto de 2009).
111
112
3.3.4.
FlexiProvider
Curvas sobre de ANSI X9.62: prime192v1, prime192v2, prime192v3, prime239v1, prime239v2, prime239v3 y prime256v1.
Curvas sobre 2 de ANSI X9.62: c2pnb163v1, c2pnb163v2, c2pnb163v3, c2tnb191v1, c2tnb191v2, c2tnb191v3, c2pnb208w1, c2tnb239v1, c2tnb239v2, c2tnb239v3, c2pnb272w1, c2tnb359v1, c2pnb368w1 y c2tnb431r1.
Curvas sobre de SEC 2: secp112r1, secp112r2, secp128r1, secp128r2, secp160k1, secp160r1, secp160r2, secp192k1, secp224k1, secp224r1, secp256k1, secp384r1 y secp521r1.
Curvas sobre del Grupo Brainpool: brainpoolP160r1, brainpoolP192r1,
brainpoolP224r1, brainpoolP256r1, brainpoolP320r1, brainpoolP384r1 y brainpoolP512r1.
Curvas sobre del Grupo CDC: desde la curva primeCurve 1 a la curva
primeCurve 38.
La versin del algoritmo ECIES del paquete ECProvider es notablemente flexible, permitiendo un elevado nmero de combinaciones de parmetros. Adems
del cdigo binario y la documentacin, su pgina web incluye ejemplos y tutoriales
sobre cmo utilizar los paquetes comentados. Por todos estos motivos, los paquetes del proyecto FlexiProvider constituyen una alternativa muy interesante para el
desarrollo de aplicaciones que utilicen funcionalidades ECC.
3.4.
3.4.1.
113
Java Card
Introduccin al lenguaje Java Card
La tecnologa Java Card combina un subconjunto del lenguaje Java con un entorno de ejecucin optimizado para las tarjetas inteligentes [48, 100], que se caracterizan por ser dispositivos con capacidades limitadas.
Las API Java Card fueron presentadas en noviembre de 1996 por un grupo de
ingenieros de Schlumberger (empresa francesa denominada as debido al apellido de
sus fundadores, Conrad y Marcel Schlumberger) que intentaban aunar la facilidad
de desarrollo del lenguaje Java con las caractersticas de seguridad de las tarjetas
inteligentes. Poco despus de presentar el primer borrador de las API Java Card, a
Schlumberger se le unieron Gemplus y Bull pasando a crear el Java Card Forum, un
consorcio creado para identificar y resolver los problemas asociados a la tecnologa
Java Card.
Tras la presentacin de Java Card 1.0, Sun comenz a colaborar activamente
con los fabricantes de tarjetas y el resultado fue el anuncio en noviembre de 1997
de Java Card 2.0. Esta nueva versin era bastante diferente de la inicial, ya que
proporcionaba un mecanismo de programacin orientado a objetos y mejoraba el
nivel de detalle de la especificacin del entorno de ejecucin de aplicaciones, aunque
por contra no inclua la especificacin del formato de los applet (aplicaciones Java
Card) para su descarga.
Debido a la necesidad de adaptar las capacidades del lenguaje Java a las limitaciones fsicas de las tarjetas inteligentes, desde su inicio se hizo evidente la
imposibilidad de implementar algunas de sus caractersticas, tal como se describe
en detalle en 3.4.5. Ello no ha impedido, sin embargo, su masiva utilizacin en
industrias como la de la telefona mvil.
La versin Java Card 2.1 fue lanzada en marzo de 1999 y consista en tres
especificaciones: Java Card API, Java Card Runtime Environment y Java Card
Virtual Machine.
Java Card API: define los paquetes Java tanto del ncleo como de las extensiones disponibles para las tarjetas inteligentes.
Java Card Runtime Environment (Java Card RE): define el comportamiento
en tiempo de ejecucin de los applets.
Java Card Virtual Machine (JCVM): define un subconjunto del lenguaje Java
y una mquina virtual para las tarjetas inteligentes.
Aparte de mejorar las API existentes, la versin 2.1 defini explcitamente la
mquina virtual y el formato de applets de forma que su descarga fuera interoperable.
114
3.4.2.
115
java.lang
Este paquete representa el pilar fundamental del lenguaje Java, con soporte para algunas de sus clases bsicas. En Java Card, este paquete constituye
un subconjunto del paquete java.lang de Java Standard Edition, donde slo
estn permitidas algunas clases como Object (la raz de todas las clases Java) o Throwable (la clase base para todas las excepciones), y dentro de ellas
nicamente se encuentran disponibles algunos mtodos.
java.io
Se trata de un subconjunto del paquete java.io de la edicin Standard que
contiene como nica clase java.io.IOException, la cual es la superclase de
java.rmi.RemoteException. Su presencia es necesaria para mantener una
jerarqua de excepciones idntica a la de la versin Standard.
java.rmi
Incluye las clases bsicas para la funcionalidad JCRMI.
javacard.framework
Representa el conjunto de clases e interfaces que conforman el ncleo de la
funcionalidad de un applet Java Card. Por ejemplo, incluye la clase Applet
que es bsica para la ejecucin e interaccin de un applet con el JCRE, o
la clase APDU utilizada para la comunicacin con la tarjeta inteligente con
independencia del protocolo fsico empleado.
javacard.framework.service
Proporciona un entorno de clases e interfaces que permiten a los applet Java
Card ser incluidos en un registro de manera que posteriormente se puedan reenviar las APDU entrantes a las aplicaciones registradas. Tambin incluye una
interfaz que incluye mtodos para procesar los comandos APDU de mltiples
servicios.
javacard.security
Su diseo se basa en el paquete java.security de Java SE e incluye las clases
e interfaces que dan soporte a algunas de las funcionalidades criptogrficas de
las tarjetas Java Card, por ejemplo las relacionadas con generacin de nmeros
aleatorios, resmenes y firmas digitales.
javacardx.apdu
Se trata del primer paquete de extensin del API Java Card. Los paquetes de
extensin son fcilmente identificables por comenzar siempre por el trmino
javacardx. En concreto, este API permite la comunicacin con la tarjeta
mediante APDU segn el formato definido en las normas ISO/IEC 7816.
116
javacardx.biometry
Esta interfaz contiene la funcionalidad necesaria para implementar capacidades
biomtricas en Java Card.
javacardx.crypto
Se trata de un paquete de extensin que incluye las funcionalidades criptogrficas para el cifrado y descifrado de datos, funcionalidades que pueden estar sujetas a controles de exportacin. Tanto este paquete como el
javacard.security definen las interfaces que los applet utilizarn, pero no
proporcionan ninguna implementacin, que debe ser desarrollada por el proveedor de la JCRE (quien, habitualmente es el propio fabricante de la tarjeta).
Los elementos fundamentales de este paquete son la clase Cipher, que proporciona mtodos para cifrar y descifrar mensajes, y la interfaz KeyEncryption
que define los mtodos para permitir el acceso a la implementacin de una
clave determinada.
javacardx.external
Este paquete permite el acceso a subsistemas de memoria que no son directamente gestionables por el entorno de ejecucin de las tarjetas Java Card. Se
compone principalmente de la clase Memory y la interfaz MemoryAccess.
javacardx.framework
Este paquete opcional incluye las clases e interfaces para la implementacin
eficiente de applets Java. Si el paquete est presente, tambin deben estarlo
los subpaquetes math, tlv y util.
javacardx.framework.math
Este paquete contiene funcionalidad comn para la utilizacin de aritmtica
BCD (Binary-Coded Decimal) y el clculo de paridades.
javacardx.framework.tlv
Paquete para la gestin de datos con formato BER TLV basados en las reglas
de codificacin ASN.1 BER del estndar ISO/IEC 8825-1 [127], incluyendo la
edicin y procesamiento de objetos BER TLV en los buffers de entrada/salida.
javacardx.framework.util
Se trata de una API que contiene utilidades para la gestin de arrays de
componentes de tipo byte, short o int.
javacardx.framework.util.intx
Este paquete incluye la clase JCint, equivalente en su definicin a la clase
javacard.framework.Util, pero con el objetivo de utilizar datos de tipo int.
3.4.3.
117
3.4.3.1.
118
Cada applet que pueda residir en una tarjeta Java Card queda unvocamente
identificado por su Application ID (AID). Tal como queda definido en la norma
ISO/IEC 7816-5 [117], un AID es una secuencia de entre 5 y 16 bytes que sirve para
la seleccin directa de aplicaciones.
Para adaptarse a las especificaciones Java Card, todos los applets deben extender la clase abstracta Applet, que define los mtodos utilizados por el JCRE para
controlar el ciclo de vida de un applet, tal como puede apreciarse en la Figura 3.4.
Figura 3.4: Mtodos para la gestin del ciclo de vida de un applet Java Card
119
3.4.3.3.
Java Card utiliza el concepto de canal lgico para permitir varias sesiones simultneas, con un lmite fijo de una sesin por canal lgico. Puesto que el procesamiento
de una APDU no puede ser interrumpido, y cada APDU contiene en su byte CLA
una referencia al canal lgico a utilizar, sucesivas APDU pueden comunicarse con
un nmero distinto de applets, permitiendo la ilusin de la ejecucin simultnea de
distintos applets, cuando en realidad en un momento dado slo un applet est siendo
ejecutado.
El nmero de canales lgicos soportados en Java Card ha aumentado con el paso
del tiempo. Mientras que en las versiones Java Card 2.1.x los comandos slo podan
ser procesados por un nico applet, Java Card 2.2 y 2.2.1 permitan utilizar un
mximo de cuatro canales lgicos, nmero que se ha incrementado hasta veinte en
Java Card 2.2.2 y se ha mantenido en Java Card 3.0.
Algunas tarjetas Java Card permiten que exista un applet que sea seleccionado
de forma automtica a travs del canal 0 cada vez que la tarjeta recibe alimentacin.
ste es el caso de las tarjetas Java Card utilizadas en telefona mvil, donde la aplicacin SIM es seleccionada automticamente, de manera que los telfonos mviles
no necesitan realizar la seleccin de dicha aplicacin. La documentacin, sin embargo, no detalla cmo especificar estos applets por defecto, por lo que los mecanismos
utilizados hasta el momento se basan en procedimientos propietarios dependientes
de cada fabricante.
120
3.4.3.4.
121
3.4.4.
Java Card VM
122
3.4.5.
3.4.6.
123
javacard.security
El paquete javacard.security contiene varias interfaces para implementar claves simtricas y asimtricas, la clase generadora de claves (key builder ), las clases
para realizar autenticaciones de resmenes de mensajes y firmas digitales, as como la clase utilizada en la generacin de datos aleatorios (los cuales son producidos en la forma de arrays de tipo byte de longitud variable y definible en la
llamada al mtodo). El Cuadro 3.1 detalla todas las clases e interfaces del paquete
javacard.security disponibles en Java Card 3.0 Classic Edition.
Clase o interfaz
AESKey
Checksum
CryptoException
DESKey
DSAKey
DSAPrivateKey
DSAPublicKey
Descripcin
Representa una clave AES de 128, 192 256 bits
Clase abstracta base para algoritmos de checksum
Excepcin de tipo criptogrfico
Representa una clave DES simple de 64 bits, una
clave para TDES de 128 bits con dos claves simples o una clave TDES de 192 bits con tres claves
simples
Interfaz base para implementaciones de claves pblicas y privadas utilizadas por el algoritmo DSA
Utilizada para firmar datos con el algoritmo DSA
Utilizada para verificar firmas digitales empleando
el algoritmo DSA
124
Descripcin
ECKey
Interfaz base para implementaciones de claves pblicas y privadas para curvas elpticas definidas sobre cuerpos primos y binarios
ECPrivateKey
Utilizada para firmar datos con ECDSA y generar
secretos compartidos con ECDH
ECPublicKey
Utilizada para verificar firmas digitales mediante
el algoritmo ECDSA y para generar secretos compartidos con ECDH
HMACKey
Interfaz que define una clave para operaciones
HMAC
InitializedMessageDigest Genera un resumen a partir de un mensaje, pero
permitiendo definir un valor de resumen inicial que
se correspondera con una parte del mensaje de la
que ya se hubiera obtenido previamente su valor
Key
Interfaz base para todas las claves
KeyAgreement
Clase abstracta base para la implementacin de algoritmos de acuerdo de clave como Diffie-Hellman
y ECDH
KeyBuilder
Clase utilizada para generar un objeto de tipo clave
KeyPair
Contenedor para un par de claves (una pblica y
otra privada)
KoreanSEEDKey
Clave de 128 bits para operaciones con el algoritmo
Korean Seed
MessageDigest
Clase abstracta base para algoritmos resumen
PrivateKey
Interfaz base para claves privadas de algoritmos
asimtricos
PublicKey
Interfaz base para claves pblicas de algoritmos
asimtricos
RandomData
Clase abstracta base para la generacin de datos
aleatorios
RSAPrivateCrtKey
Interfaz de una clave privada RSA con el formato
CRT (Chinese Remainder Theorem)
RSAPrivateKey
Interfaz de una clave privada RSA con el formato
mdulo/exponente
RSAPublicKey
Interfaz de una clave pblica RSA
SecretKey
Interfaz base para todas las claves de algoritmos
simtricos
Signature
Clase abstracta base para algoritmos de firma digital
125
Clase o interfaz
Descripcin
SignatureMessageRecovery Interfaz para operaciones de firma con recuperacin de mensaje
Cuadro 3.1: Clases e interfaces del paquete javacard.security
3.4.6.2.
javacardx.crypto
Descripcin
Clase abstracta base que proporciona la funcionalidad
para cifrado y descifrado de datos
Permite implementar claves para acceder a datos cifrados
3.4.6.3.
Java Card 2.2 fue la primera versin en incluir soporte para criptografa de curva
elptica. En concreto, en dicha versin se definieron los siguientes elementos:
Nuevas clases ECKey, ECPrivateKey y ECPublicKey para la creacin y gestin
de claves ECC pblicas y privadas sobre cuerpos primos y binarios.
Extensin de la clase KeyPair para permitir la manipulacin de pares de claves
sobre cuerpos y 2 .
Extensin de la clase KeyAgreement con las funciones de acuerdo de clave DH
(Diffie-Hellman) y DHC (Diffie-Hellman with Cofactor), con la peculiaridad
de que la salida de esas funciones no es la primera coordenada del elemento
secreto compartido, sino el resultado de pasar este dato a travs de la funcin
SHA-1.
Extensin de la clase KeyBuilder, que define las longitudes de clave permitidas
para ECC y otros criptosistemas. En el caso de curvas elpticas sobre cuerpos
primos, las longitudes vlidas en Java Card 2.2 son 112, 128, 160 y 192 bits,
mientras que en el caso de curvas sobre cuerpos binarios, las longitudes posibles
son 113, 131, 163 y 193 bits.
126
3.5.
127
exportacin con extensin .exp que contiene informacin sobre la interfaz pblica
de todas las clases del paquete.
La Figura 3.8 muestra de forma grfica el proceso completo de desarrollo de un
applet Java Card.
Captulo 4
Estudio y anlisis del esquema de
cifrado ECIES
4.1.
Los primeros esquemas de cifrado basados en curvas elpticas que surgieron fueron el equivalente de los sistemas Massey-Omura [205] (que a su vez es una mejora
del three-pass protocol de Shamir, que nunca fue publicado debido a que no era seguro) y ElGamal [69], ambos presentados por Koblitz en 1985 (y publicados en 1987)
[147], y el Menezes-Vanstone Elliptic Curve Cryptosystem [169].
El Algoritmo 4.1 describe el protocolo de Massey-Omura por el que el usuario U
procede al envo de un cierto mensaje al usuario V, donde es una curva elptica
definida sobre el cuerpo finito de elementos y existe una relacin pblicamente
conocida de mensajes en claro y puntos de la curva .
129
130
131
132
133
=
=ENC 1 ()
= KDF (132 )
tag=MAC2 ()
=ENC 1 ()
=(, ,tag)
tag=MAC2 ()
=(, , ,tag)
ACE
[1, 1]
=
=
=
= ( , )
= ( )
= (mod )
= +
=KDF ( )
= 1 2
=ENC 1 ()
tag=MAC2 ()
=(, , , ,tag)
134
Como puede apreciarse en el Cuadro 4.1, las principales diferencias entre los
esquemas ECIES, PSEC y ACE son las siguientes:
Tanto en ECIES como en PSEC, la clave pblica del receptor del criptograma
es el punto de la curva = , mientras que en ACE la clave pblica est
formada por cuatro puntos, de manera que = (, , , ).
PSEC utiliza dos veces la funcin KDF, mientras que ECIES y ACE slo la
utilizan una vez.
ECIES y ACE utilizan la primera coordenada de un punto de la curva generado durante los clculos intermedios (en lugar de las dos coordenadas) como
parmetro de entrada de la funcin KDF, mientras que en PSEC es obligatorio
utilizar las dos coordenadas.
PSEC es el nico esquema que utiliza la funcin XOR durante el proceso
de generacin de claves (independientemente de su posible utilizacin como
funcin de cifrado simtrico).
Los criptogramas de ECIES estn formados por tres elementos (el punto , el
mensaje cifrado y la etiqueta tag), mientras que los criptogramas de PSEC
aaden adems el elemento y los de ACE incluyen dos puntos de la curva
elptica ( y ).
Una vez presentado el esquema general del proceso de cifrado de los tres esquemas, y con el fin de seleccionar el ms adecuado, es necesario evaluar tres aspectos
fundamentales: eficiencia, seguridad y adaptabilidad a las plataformas hardware de
trabajo.
Respecto al anlisis de su eficiencia, los siguientes cuadros muestran datos tomados de [196]. En concreto, el Cuadro 4.2 muestra una comparativa del nmero de
operaciones necesarias para llevar a cabo el proceso de cifrado en los tres esquemas.
En l se puede comprobar que ECIES es el esquema que, de forma global, utiliza
menos operaciones.
Producto escalar
Suma de puntos
Generacin de nmeros aleatorios
Llamadas a funcin KDF
Llamadas a funcin H
Llamadas a funcin MAC
Llamadas a funcin resumen
ECIES
2
0
1
1
0
1
1
PSEC
2
0
1
2
1
1
1
ACE
5
1
1
1
1
1
1
135
ECIES
2500
5
PSEC
2500
5
ACE
6250
12.5
Otro de los aspectos a tener en cuenta para evaluar la eficiencia de los tres esquemas de cifrado es su factor de expansin. El Cuadro 4.4 muestra las longitudes
en bytes de las claves pblicas y privadas, as como del criptograma generado, considerando que la longitud de los elementos del cuerpo, del mensaje a cifrar y de la
salida de la funcin resumen son, respectivamente, 20, 16 y 20 bytes, y habiendo
sido utilizada la tcnica de compresin de puntos en la representacin binaria de los
puntos de la curva.
Clave privada
Clave pblica
Criptograma
ECIES
20
20
36
PSEC
20
20
52
ACE
80
80
76
136
El ltimo aspecto que es necesario tener presente en la evaluacin de los candidatos consiste en el grupo de funcionalidades disponibles en los dispositivos sobre
los que se implementar el esquema de cifrado. Aunque ciertamente en la versin PC
no existen limitaciones a este respecto, puesto que cualquier funcin criptogrfica
puede ser codificada utilizando las API de Java SE, en cambio en Java Card existen
importantes limitaciones, puesto que por ejemplo en sus API no existen mtodos
para realizar directamente operaciones de suma de puntos o productos escalares,
existiendo en cambio la posibilidad de utilizar la funcin Diffie-Hellman con curvas
elpticas, lo que se puede considerar equivalente al producto escalar pero con la particularidad de que el API de Java Card define como resultado de dicha funcin la
primera coordenada del punto de la curva que representa la multiplicacin o bien la
salida de una funcin resumen que tome como entrada dicha coordenada.
Tras evaluar los tres criterios mencionados (rendimiento, seguridad y funcionalidad disponible en las plataformas PC y Java Card), en vista de sus caractersticas,
y considerando como elemento positivo adicional su mayor difusin, el esquema seleccionado para su implementacin en esta Tesis Doctoral fue ECIES. Las restantes
secciones de este captulo describen con todo detalle el esquema ECIES, incluyendo
la comparacin de las versiones aparecidas en los distintos estndares existentes y
el anlisis de su seguridad.
4.2.
En 1997, Mihir Bellare y Philip Rogaway [26] presentaron un esquema de cifrado denominado DLAES (Discrete Logarithm Augmented Encryption Scheme), el
cual fue mejorado posteriormente por los mismos autores junto con Michel Abdalla, renombrndolo primero como DHAES (Diffie-Hellman Augmented Encryption
Scheme) en 1998 [8] y posteriormente como DHIES (Diffie-Hellman Integrated Encryption Scheme) en 2001 [9, 10], a fin de evitar confusiones con el algoritmo AES.
De forma simplificada, se puede afirmar que DHIES representa una extensin
mejorada del algoritmo ElGamal. La principal aportacin de DHIES respecto a la
versin original de ElGamal [69], o a la implementacin que hizo Koblitz de ese
mismo algoritmo [147], consiste en reunir bajo un nico esquema operaciones de
clave pblica, cifrado simtrico, autenticacin mediante cdigos MAC y clculo de
resmenes. En comparacin, tanto ElGamal como Koblitz se limitaban a generar
una clave simtrica con la que se cifraba el mensaje original, sin incluir los dems
elementos propios de un esquema integrado. Debido precisamente a este nivel de
integracin, DHIES proporciona seguridad contra ataques de texto cifrado elegido, ante los cuales el algoritmo de ElGamal era vulnerable [10], sin necesidad de
aumentar el nmero de operaciones o la longitud de las claves.
La Figura 4.1 muestra grficamente el funcionamiento del esquema de cifrado
137
138
4.3.
En los siguientes apartados se presentan los elementos que ambos usuarios deben
acordar de manera previa, utilizando canales de informacin donde la privacidad no
es un factor importante, ya que la informacin a intercambiar no es crtica.
139
La notacin empleada en la descripcin de los elementos ser utilizada posteriormente en los apartados dedicados a las implementaciones de ECIES recogidas
en los estndares analizados.
4.3.1.
Parmetros de la curva
140
4.3.2.
Funciones resumen
4.3.3.
Las funciones de generacin del secreto compartido utilizadas en ECIES, denominadas de manera genrica funciones KA (Key Agreement), tienen como objetivo
generar un valor secreto compartido entre dos usuarios, utilizando para ello una
clave privada del usuario U y una clave pblica del usuario V. Las principales
funciones KA utilizadas en las implementaciones analizadas son:
141
4.3.4.
142
143
144
4.3.5.
145
4.3.6.
De forma genrica, las funciones MAC toman como entrada una cadena de bytes
y un nmero entero positivo que representa una longitud, y producen como salida
una cadena de bytes (distinta de la inicial y de la longitud indicada) denominada
comnmente tag o etiqueta. Por su parte, las funciones HMAC (Hashed Message
Authentication Code) representan un tipo especial de funciones MAC, siendo su
caracterstica principal la utilizacin de una funcin resumen.
El Algoritmo 4.8 muestra el funcionamiento de las funciones HMAC que utilizan
una clave para autenticar una cadena binaria .
Las funciones MAC cuyo uso est ms extendido son:
HMAC-SHA-1-80 y HMAC-SHA-1-160 con claves de 160 bits [154, 186].
HMAC-SHA-224-112 y HMAC-SHA-224-224 con claves de 224 bits [186].
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
opad )||H ((
ipad )||)).
4.4.
147
Versiones de ECIES
4.4.1.
Aunque los borradores del estndar ANSI X9.63 incluan dos esquemas de cifrado (Elliptic Curve Encryption Scheme y Elliptic Curve Augmented Encryption
Scheme), cuya diferencia consista en que el segundo esquema utilizaba una funcin MAC para generar una etiqueta (mientras que el primero no la utilizaba), en la
versin final del estndar [16] se describe una nica versin con el nombre de ECIES.
4.4.1.1.
Los datos que emisor y receptor necesitan acordar antes de comenzar el proceso
de cifrado son, utilizando la notacin empleada por ANSI X9.63, los siguientes:
Parmetros de dominio , junto con una indicacin de la base utilizada y un
polinomio reductor () de grado y con coeficientes en 2 , en caso de elegir
curvas del tipo (2 ).
148
149
150
4.4.1.2.
Proceso de cifrado
Opciones disponibles
Funcin HASH :
Cualquier funcin resumen aprobada por ANSI. El catlogo de estndares de
ANSI de 2010 [17] indica que dichas funciones son las siguientes:
SHA-1.
SHA-224.
SHA-256.
SHA-384.
SHA-512.
Funcin KA:
DH.
DHC.
Funcin KDF :
ANSI-X9.63-KDF.
Funcin ENC :
Funcin MAC :
Est permitida cualquier funcin MAC aprobada por ANSI que utilice claves
de al menos 80 bits y que genere salidas cuya longitud mnima sea igualmente
de 80 bits, citando el propio estndar como ejemplo la familia de funciones
HMAC, por lo que junto con la lista de funciones resumen permitidas por
ANSI se obtienen las siguientes opciones:
HMAC-SHA-1.
HMAC-SHA-224.
HMAC-SHA-256.
HMAC-SHA-384.
151
HMAC-SHA-512.
Como aclaracin, aunque el documento X9.63 data del ao 2001, en la lista de
funciones permitidas se han incluido algoritmos estandarizados en fecha posterior
(SHA-224, HMAC-SHA-224, etc.) puesto que, en lugar de citar especficamente en
algunos apartados los nombres de los algoritmos permitidos, el documento X9.63 se
limita a indicar que las funciones permitidas son aquellas aprobadas por ANSI, lo
que permite hbilmente la actualizacin del estndar sin que sea necesario publicar
nuevas versiones.
4.4.2.
152
En IEEE 1363a, las funciones KDF y MAC son fijas y estn descritas en el propio
documento. Aunque en su notacin denominan a la funcin de derivacin de claves
KDF2, en realidad se trata de la funcin ANSI-X9.63-KDF descrita en 4.3.4, y para
evitar confusiones con la funcin KDF2 del estndar ISO/IEC 18033-2, se utilizar
en este apartado el trmino ANSI-X9.63-KDF para referirse a ella. En cuanto a la
funcin MAC1 del documento, se trata de la construccin HMAC-Hash-x [154].
La notacin empleada en [109] incluye los siguientes elementos:
: mensaje que el emisor desea enviar al receptor, representado como una
cadena de l bits.
: el resultado de cifrar el mensaje .
: clave privada temporal del emisor, componente del par de claves (, ).
: clave pblica temporal del emisor, componente del par de claves (, ).
: clave pblica del receptor.
1 : cadena de bytes con informacin compartida por emisor y receptor, y que
ser utilizada en la funcin KDF.
2 : cadena de bytes con informacin compartida por emisor y receptor, y que
ser utilizada por la funcin MAC.
: elemento del cuerpo finito que representa el secreto compartido que se
utilizar en el proceso de derivacin de claves.
: representacin como cadena de bytes del secreto compartido .
1 : clave de cifrado a utilizar por la funcin de cifrado simtrico ENC.
2 : clave a utilizar por la funcin MAC.
: cadena de bits obtenida como salida de la funcin MAC.
: longitud en bits de la salida de la funcin MAC.
1 : longitud en bits de la clave de cifrado.
2 : longitud en bits de la clave para la funcin MAC.
En este estndar, tanto la cadena 1 como 2 pueden estar vacas, por lo que
realmente su uso es opcional.
153
154
4.4.2.2.
Proceso de cifrado
Opciones disponibles
Funcin HASH :
SHA-1.
SHA-256.
SHA-384.
SHA-512.
RIPEMD-160.
Funcin KA:
DH (denominada ECSVDP-DH en la norma).
Funcin KDF :
ANSI-X9.63-KDF (denominada en el estndar KDF2, no confundir con
la funcin del mismo nombre descrita en 4.3.4).
Funcin ENC :
XOR (el estndar recomienda cifrar mensajes de reducido tamao y, si
se utiliza el modo no-DHAES, que su longitud sea constante para una
misma clave pblica del receptor a emplear).
TDES en modo CBC y relleno PKCS#5 con bloques de 64 bits y claves
de 128 192 bits.
AES en modo CBC y relleno PKCS#5 con bloques de 128 bits y claves
de 128, 192 256 bits
155
Funcin MAC :
El estndar define la funcin MAC1, equivalente a las funciones de tipo HMAC,
donde las funciones resumen permitidas son las del propio documento [109],
obteniendo por tanto como lista de funciones MAC permitidas las siguientes:
HMAC-SHA-1.
HMAC-SHA-256.
HMAC-SHA-384.
HMAC-SHA-512.
HMAC-RIPEMD-160.
4.4.3.
4.4.3.1.
Los datos que los usuarios emisor y receptor necesitan acordar antes de comenzar
el proceso de cifrado son los siguientes, donde se ha mantenido la notacin utilizada
por ISO/IEC 18033-2 [136]:
Conjunto de parmetros (, , , , ), donde es el cuerpo primo o binario
de trabajo, representa el elemento generador del grupo cclico , es
el orden del elemento y es el cofactor de la curva.
Funcin de derivacin de claves KDF (pudiendo optar entre las funciones
KDF1 y KDF2).
Funcin resumen Hash, donde Hash.len representa la longitud en bytes de
los resmenes calculados y Hash.MaxInputLen indica la longitud mxima, en
bytes, de los mensajes que pueden ser utilizados como entrada para la funcin
resumen.
Funcin MAC denominada de forma abreviada MA, donde la longitud en
bytes de la clave se denotar mediante el trmino MA.KeyLen, mientras que
la longitud en bytes de la etiqueta producida por la funcin se representar
como MA.MACLen.
Funcin ENC, donde la longitud en bytes de la clave se denotar mediante el
trmino SC.KeyLen.
Utilizacin del modo OldCofactorMode, que implica el uso del cofactor tanto
en la fase de cifrado como de descifrado.
156
Utilizacin del modo CofactorMode, que requiere del uso del cofactor nicamente en el proceso de descifrado.
Utilizacin del modo CheckMode, que obliga a la comprobacin durante el proceso de descifrado de la pertenencia de la clave pblica temporal del emisor a .
nicamente uno de los modos OldCofactorMode, CofactorMode y CheckMode
puede ser utilizado en un mismo proceso de cifrado.
Utilizacin o no del modo SingleHashMode, que permite elegir que la entrada
a la funcin KDF sea nicamente la primera coordenada del dato secreto
compartido o de manera adicional la clave pblica temporal generada por el
emisor.
Formato de codificacin de los puntos (comprimido o sin comprimir).
La notacin empleada en ISO/IEC 18033-2 incluye adems los siguientes elementos:
: mensaje que el emisor desea enviar al receptor.
: el resultado de cifrar el mensaje .
(, ): par formado por las claves privada y pblica del receptor.
(, ): par formado por una clave privada y una clave pblica temporales generadas por el emisor.
: cadena de bytes con informacin compartida por emisor y receptor, y que
ser utilizada en la funcin MAC.
: elemento del cuerpo finito que representa el secreto compartido que se
utilizar en el proceso de derivacin de claves.
: representacin como cadena de bytes de la clave pblica temporal del emisor.
: valor obtenido como salida de la funcin KDF.
: clave de cifrado a utilizar por el esquema de cifrado simtrico ENC.
: clave a utilizar por la funcin MAC.
: valor obtenido como salida de la funcin MAC.
PEH : primera coordenada del punto que acta como valor secreto compartido.
157
Proceso de cifrado
Opciones disponibles
158
Algoritmo 4.12 Funcin DEM1 de la fase DEM del cifrado ECIES en ISO/IEC
18033-2
1. El emisor debe comenzar dividiendo el elemento en , donde actuar
como clave para el algoritmo de cifrado simtrico, con longitud SC.KeyLen,
y ser la clave de la funcin MAC, con longitud MA.KeyLen.
2. A continuacin el emisor cifrar el mensaje original con la clave , generando el mensaje cifrado .
3. Tras el ltimo paso, obtendr la etiqueta correspondiente a la salida
de la funcin MAC, tomando como entrada la cadena de bytes concatenada
., donde representa los datos compartidos entre emisor y receptor
y . la longitud codificada en 8 bytes de la longitud en bits de .
4. Por ltimo, el emisor concatenar el texto cifrado y la etiqueta, enviando al
receptor el elemento 1 = TG junto con la clave pblica temporal 0 .
Algoritmo 4.13 Funcin DEM2 de la fase DEM del cifrado ECIES en ISO/IEC
18033-2
1. El emisor debe interpretar el elemento como , donde actuar como
clave para el algoritmo de cifrado simtrico, con longitud SC.KeyLen, y
ser la clave de la funcin MAC, con longitud MA.KeyLen.
2. El emisor cifrar el mensaje original con la clave , generando el mensaje
cifrado .
3. Tras el ltimo paso, obtendr la etiqueta correspondiente a la salida
de la funcin MAC, tomando como entrada la cadena de bytes concatenada
, donde 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 1 = TG junto con la clave pblica temporal 0 .
159
Algoritmo 4.14 Funcin DEM3 de la fase DEM del cifrado ECIES en ISO/IEC
18033-2
1. El emisor debe dividir el elemento en , donde actuar como clave
para el algoritmo de cifrado de flujo (y por lo tanto su longitud debe coincidir
con la longitud del mensaje a cifrar), y ser la clave de la funcin MAC,
con longitud MA.KeyLen.
2. El emisor
cifrar el mensaje original con la clave mediante la operacin
= .
3. Tras el ltimo paso, obtendr la etiqueta correspondiente a la salida
de la funcin MAC, tomando como entrada la cadena de bytes concatenada
, donde 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 1 = TG junto con la clave pblica temporal 0 .
Funcin HASH :
Cualquiera de las las funciones resumen definidas en ISO/IEC 10118-2 [130]
que utilizan internamente una funcin de cifrado de bloques con la condicin
de que el nmero de bytes ofrecidos como salida de la funcin sea mltiplo de
8. Los nombres asignado por [130] a las funciones son los siguientes:
Hash-function one.
Hash-function two.
Hash-function three.
Hash-function four.
SHA-256.
SHA-384.
SHA-512.
RIPEMD-128.
RIPEMD-160.
WHIRLPOOL.
160
Funcin KA:
DH.
DHC.
Funcin KDF :
KDF1.
KDF2.
Funcin ENC :
XOR con una longitud de mensaje en claro definida y constante para
todos los procesos de cifrado.
XOR diseado para el cifrado de mensajes de longitud variable, donde en
lugar de utilizar directamente la clave de cifrado generada por la funcin
KDF, sta se utiliza como semilla para la generacin de la clave XOR
definitiva adaptada a la longitud del mensaje en claro mediante una nueva
ejecucin de la funcin KDF.
Cualquier algoritmo incluido en ISO/IEC 18033-3 [137] con la condicin de que
la longitud de los mensajes medida en bits sea mltiplo de 8. Los algoritmos
descritos en [137] son los siguientes:
TDES en modo CBC y relleno PKCS#5 con bloques de 64 bits y claves
de 128 192 bits.
AES en modo CBC y relleno PKCS#5 con bloques de 128 bits y claves
de 128, 192 256 bits.
MISTY1 en modo CBC y relleno PKCS#5 con bloques de 64 bits y claves
de 128 bits.
CAST-128 en modo CBC y relleno PKCS#5 con bloques de 64 bits y
claves de 128 bits.
Camellia en modo CBC y relleno PKCS#5 con bloques de 128 bits y
claves de 128, 192 256 bits.
SEED en modo CBC y relleno PKCS#5 con bloques de 128 bits y claves
de 128 bits.
Funcin MAC :
Cualquiera de las cuatro variantes CBC-MAC incluidas en ISO/IEC 9797-1
[128] que utilizan internamente una funcin de cifrado de bloques, denominadas
en [128] de la siguiente manera:
161
MAC Algorithm 1.
MAC Algorithm 2.
MAC Algorithm 3.
MAC Algorithm 4.
Cualquiera de las tres variantes incluidas en ISO/IEC 9797-2 [129] que utilizan
internamente una de las funciones resumen referidas en ISO/IEC 10118-3 [131]:
MAC Algorithm 1 (MDx-MAC).
MAC Algorithm 2 (HMAC).
4.4.4.
Los datos que los usuarios, identificados como emisor y receptor, necesitan acordar antes de comenzar el proceso de cifrado son los siguientes, donde se ha mantenido
la notacin utilizada por SEC 1:
Conjunto de parmetros = (, , , , , ) en caso de utilizar curvas definidas sobre cuerpos finitos , o parmetros = (, (), , , , , ) si se
utilizan curvas del tipo (2 ), donde en ambos casos representa el orden
del generador y es el cofactor de la curva.
Funcin de derivacin de clave KDF, que genera una cadena de bytes de longitud enckeylen+mackeylen.
Funcin resumen H, donde hashlen representa la longitud en bytes de los resmenes calculados y hashmaxlen indica la longitud mxima en bytes de los
mensajes que pueden ser utilizados como entrada para la funcin resumen.
Funcin MAC, donde la longitud en bytes de la clave se denotar mediante el
trmino mackeylen, mientras que la longitud en bytes de la etiqueta producida
por la funcin se representar como maclen.
162
4.4.4.2.
Proceso de cifrado
163
164
4.4.4.3.
Opciones disponibles
SHA-224.
SHA-256.
SHA-384.
SHA-512.
Funcin KA:
DH.
DHC.
Funcin KDF :
ANSI-X9.63-KDF [16].
NIST-800-56-Concatenation-KDF [189].
Funcin ENC :
TDES con tres claves en modo CBC [190] (SEC 1 no especifica el mtodo
de relleno).
AES en modo CBC y claves de 128, 192 256 bits [185, 187] (sin especificar el mtodo de relleno).
AES en modo CTR y claves de 128, 192 256 bits [185, 187] (SEC 1 no
define el mtodo de relleno).
Funcin MAC :
HMAC-SHA-1-80 (clave de 160 bits y salida truncada a 80 bits).
HMAC-SHA-1-160 (clave de 160 bits y salida de 160 bits).
165
4.5.
En los siguientes apartados se presenta una comparacin entre pares de estndares, donde la eleccin de los estndares a comparar se ha realizado en base a su
fecha de publicacin, de manera que las comparaciones se han efectuado entre cada
par de estndares ms cercanos en el tiempo. El motivo de esta decisin es que,
aunque cada nuevo estndar se apoya en los anteriores, suele tomar como referencia
el estndar de ms reciente publicacin.
En resumen, los documentos considerados y sus fechas de publicacin son: DHIES
(1997-2001), ANSI X9.63 (2001), ISO/IEC 18033-2 (2006) y SECG SEC 1 (2009).
4.5.1.
166
4.5.2.
La siguiente lista refleja las principales diferencias existentes entre las implementaciones de ECIES incluidas en ANSI X9.63 [16] e IEEE 1363a [109], que por
simplicidad en los siguientes prrafos sern referidos simplemente como X9.63 y
1363a.
X9.63 permite utilizar parmetros opcionales como entrada en la funcin KDF,
aunque no menciona el contenido de dichos parmetros. En comparacin, el
modo DHAES de 1363a obliga a utilizar la representacin binaria de la clave
temporal pblica del emisor como parmetro.
En cualquier caso, aunque X9.63 utilizara la clave pblica temporal como
parmetro en la funcin KDF, este dato se concatenara en tercera posicin en
la cadena binaria que representa el argumento de la funcin resumen utilizada
internamente dentro de la funcin KDF (es decir, en las iteraciones de la
funcin sera necesario calcular ( counter )), mientras que en IEEE
1363a la clave pblica temporal ocupara el primer lugar en la concatenacin
(siendo necesario por tanto calcular el valor ( counter ))
1363a interpreta los bits iniciales de la salida de la funcin KDF como la clave
MAC, y los bits posteriores como la clave ENC, cuando utiliza cifrado en flujo,
mientras que la interpretacin es la opuesta cuando 1363a utiliza cifrado en
bloque. En comparacin, X9.63 interpreta siempre la salida de la funcin KDF
como .
4.5.3.
167
1363a establece como longitud mnima del orden del elemento generador 160
bits, mientras que 18033-2 no hace referencia a longitudes mnimas.
Es interesante comentar que, entre el estndar IEEE 1363a y los primeros borradores de ISO/IEC 18033-2, existan ms diferencias, como se puede apreciar en el
documento de Shoup [243], que denotaremos por Shoup01, y que sirvi como punto
de partida para el estndar ISO/IEC 18033-2. Esas diferencias, que posteriormente
desaparecieron en la versin final del estndar con el fin de asegurar una mayor
compatibilidad con otros estndares, son las siguientes:
Mientras que en Shoup01 se utiliza de manera obligatoria la clave pblica
temporal del remitente como entrada de la funcin resumen (junto con el dato
secreto compartido), 18033-2 permite la posibilidad de no incluir dicha clave
pblica temporal. Para completar la comparacin entre los tres documentos,
se recuerda que 1363a permite una opcin (el modo no-DHAES) en la que no
se utiliza la clave pblica del destinatario.
Shoup01 obliga a incluir como entrada de la funcin MAC un campo que
representa la longitud de la etiqueta que se anexa al mensaje cifrado. Por el
contrario, en la versin final de 18033-2 aparecen dos modos (DEM2 y DEM3)
que permiten no incluir esta informacin. En comparacin, en 1363a aadir la
longitud es opcional y en el modo no-DHAES no se emplea.
18033-2 permite la utilizacin de la funcin XOR como algoritmo de cifrado de
flujo en el modo DEM3, algo que sin embargo estaba explcitamente prohibido
en Shoup01. Por su parte, 1363a permite utilizar tanto un cifrado de flujo
como un algoritmo de cifrado simtrico de bloques.
4.5.4.
168
Mientras que 18033-2 no hace referencia a longitudes mnimas, SEC 1 establece que la eleccin de los cuerpos finitos debe estar guiada por los siguientes
requisitos:
Cuerpos : el valor debe ser tal que
4.6.
SECG SEC 1
SHA-1
SHA-224
SHA-256
SHA-384
SHA-512
IEEE 1363a
DH
DHC
ISO/IEC 18033-2
DH
DHC
169
SECG SEC 1
DH
DHC
y KDF2 son las funciones especificadas en ISO/IEC 18033-2 [136] y el trmino NIST800-56 representa la funcin definida en el documento NIST SP800-56A [189]. Es
importante indicar que, si la funcin X9.63-KDF no incluye el elemento SharedInfo,
entonces es equivalente a la funcin KDF2.
ANSI X9.63
X9.63-KDF
IEEE 1363a
X9.63-KDF
ISO/IEC 18033-2
KDF1
KDF2
SECG SEC 1
X9.63-KDF
NIST-800-56
De manera equivalente, el Cuadro 4.8 muestra los algoritmos de cifrado simtrico utilizados por las distintas versiones de ECIES, donde XOR es la funcin OR
exclusiva, el trmino XOR constituye la variante de ISO/IEC 18033-2 que emplea
la funcin XOR junto con la funcin KDF, TDES representa el algoritmo Triple
DES [190], AES es el algoritmo definido en [185] para su utilizacin con claves de
128, 192 y 256 bits, y los algoritmos MISTY1, CAST-128, Camellia y SEED se encuentran especificados en los documentos [165], [11], [18] y [157], respectivamente.
Los trminos CBC y CTR hacen referencia al modo de utilizacin del algoritmo, la
cadena PKCS5 indica que el mtodo de relleno padding a emplear debe ser PKCS#5
[234], y por ltimo el sufijo * implica que el estndar referido no ha impuesto ningn
mtodo de relleno de forma especfica.
ANSI X9.63
XOR
IEEE 1363a
XOR
TDES/CBC/PKCS5
AES/CBC/PKCS5
ISO/IEC 18033-2
SECG SEC 1
XOR
XOR
XOR
TDES/CBC/*
TDES/CBC/PKCS5
AES/CBC/*
AES/CBC/PKCS5
AES/CTR/*
MISTY1/CBC/PKCS5
CAST-128/CBC/PKCS5
Camellia/CBC/PKCS5
SEED/CBC/PKCS5
Por ltimo, el Cuadro 4.9 presenta las funciones MAC permitidas en los diferentes estndares, donde con el objetivo de optimizar el tamao del cuadro resultante se ha sustituido el prefijo HMAC por H. Las funciones HMAC-SHA-1 y
170
HMAC-RIPEMD se encuentran especificadas en [154], las variantes HMAC-SHA224, HMAC-SHA-256, HMAC-SHA-384 y HMAC-SHA-512 surgen de la combinacin de [186] y [191], y finalmente CMAC-AES es el conjunto de funciones HMAC
incluidas en [188] con claves de 128, 192 y 256 bits. Respecto al estndar ISO/IEC
18033-2, se han incluido en el cuadro nicamente las funciones de tipo HMAC, puesto que el resto de funciones definidas en [128] y [129] constituyen tipos de funciones
MAC no presentes en los dems estndares analizados y por lo tanto no son comparables a efectos prcticos.
ANSI X9.63
H-SHA-1
H-SHA-224
H-SHA-256
H-SHA-384
H-SHA-512
IEEE 1363a
ISO/IEC 18033-2
H-SHA-1
H-SHA-1
H-SHA-256
H-SHA-256
H-SHA-384
H-SHA-384
H-SHA-512
H-SHA-512
H-RIPEMD-160 H-RIPEMD-128
H-RIPEMD-160
H-WHIRLPOOL
SECG SEC 1
H-SHA-1-80/160
H-SHA-224-112/224
H-SHA-256-128/256
H-SHA-384-192/384
H-SHA-512-256/512
CMAC-AES-128/192/256
Como resumen final, el Cuadro 4.10 muestra las funciones permitidas simultneamente por los cuatro estndares revisados.
HASH
SHA-1
SHA-256
SHA-384
SHA-512
KA
DH
DHC
KDF
KDF2
ENC
XOR
MAC
HMAC-SHA-1
HMAC-SHA-256
HMAC-SHA-384
HMAC-SHA-512
4.7.
Id. de configuracin
C01
C02
C03
C04
C05
C06
C07
C08
C09
C10
C11
Arg. KDF
, Param 1
, Param 1
, Param 1
Opciones de configuracin
Interp. K
Alg. simtrico
Flujo
Flujo
Flujo
Flujo
Bloque
Bloque
Bloque
Bloque
Bloque
Bloque
Bloque
Arg. MAC
, Param 2
, Param 2
, Param 2
, Param 2
, Param 2
, Param 2
Una vez presentadas las personalizaciones de ECIES que son aceptadas al menos
en un estndar, el Cuadro 4.12 muestra el resumen de los estndares que permiten
cada una de las configuraciones.
172
X9.63
1363a
18033-2
SEC 1
Identificador de personalizacin
C01 C02 C03 C04 C05 C06 C07 C08 C09 C10 C11
4.8.
Tras revisar la lista de funciones permitidas por cada estndar en 4.6 y analizar
las configuraciones permitidas por cada uno de ellos en 4.7, se puede concluir que
existen dos configuraciones vlidas en las ltimas versiones de ANSI X9.63, IEEE
1363a, ISO/IEC 18033-2 y SECG SEC 1, caracterizadas ambas por utiliza la funcin
XOR como algoritmo de cifrado simtrico.
A la vista de este hecho, y teniendo en cuenta el elevado nmero de funciones
que los estndares utilizan de forma comn, es posible construir distintas versiones
de ECIES compatibles con los cuatro estndares y con las configuraciones C01 y
C02, diferencindose entre ellas en la funcin resumen, la funcin MAC, el uso de
parmetros opcionales en la funcin MAC, o una combinacin de esos elementos.
Por simplicidad, el Algoritmo 4.16 muestra nicamente un ejemplo de los muchos posibles, denominado ECIES-4, que emplea un subconjunto de las opciones
disponibles de manera comn en los cuatro estndares.
4.9.
Seguridad de ECIES
4.9.1.
Resistencia a la maleabilidad
El concepto de maleabilidad puede ser definido como la capacidad de un atacante de generar un criptograma vlido asociado al mensaje en claro a partir del
conocimiento del criptograma derivado del mensaje , cuando entre los mensajes
173
Algoritmo 4.16 Cifrado ECIES compatible con los cuatro estndares (ECIES-4)
1. Elegir un valor aleatorio {1, 2, . . . , 1} como clave privada temporal
de U, y generar la clave pblica = .
2. Calcular un punto = ( , ) de la curva mediante la operacin = ,
donde es la clave pblica del usuario receptor.
3. Generar el elemento del que se obtendrn las clave de cifrado y autenticacin mediante la operacin =KDF ( ), siendo la funcin KDF elegida
ANSI-X9.63-KDF (sin parmetros opcionales) y la funcin HASH empleada
SHA-1.
4. Interpretar como , donde la longitud en bits de es igual
a la longitud en bits del mensaje en claro , y la longitud de es 160
bits.
4.9.1.1.
Maleabilidad benigna
174
Una posible forma de resolver este problema fue propuesta por el propio Shoup,
y consiste en aadir la clave pblica temporal como entrada de la funcin KDF,
con lo que el criptograma ( , , ) ya no sera vlido, dado que la salida de la
funcin KDF sera diferente en ambos casos.
Otra posible solucin consiste en utilizar el punto generado mediante la funcin
KA en lugar de nicamente su primera coordenada como entrada de la funcin
KDF, con lo que de nuevo dejara de ser vlido un criptograma que contuviera
en lugar de . Respecto a la solucin mencionada anteriormente, algunos autores
como Jacques Stern [256] indican la validez y equivalencia desde el punto de vista
de seguridad de ambas opciones. Sin embargo, a pesar de estar recogida esta opcin
en algunas obras [30], en los cuatro estndares estudiados la segunda opcin no es
utilizada.
Independientemente de la vulnerabilidad reseada, Shoup indic que, en caso de
utilizar la funcin Diffie-Hellman con cofactor, es igualmente posible crear un ataque
que afecte a la maleabilidad del esquema, puesto que si al punto se le aade un
elemento distinto de cuyo orden divida el cofactor , entonces de nuevo a partir
de un criptograma vlido sera posible generar otro criptograma igualmente vlido.
La solucin ms sencilla para este problema consiste en utilizar la funcin DH sin
emplear el cofactor.
Shoup caracteriz estos problemas como maleabilidad benigna, dando a entender
que no representan un peligro demasiado importante, ya que hasta la fecha no se
ha demostrado que este ataque sirva para obtener ningn resultado prctico. Sin
embargo, desde el punto de vista formal, si se desea que el esquema ECIES sea no
maleable, es necesario solucionar estos problemas.
4.9.1.2.
175
( , , tag)
tambin vlido para los siguientes datos:
1. La representacin binaria de la clave pblica temporal del emisor.
2. Una cadena con longitud 1 y contenido indiferente para el resultado final.
= 1 de longitud 1 .
3. El mensaje en claro
4. La salida de la funcin KDF, = 1 2 = 1 2 , donde la cadena 1 = 1
tiene longitud 1 y la cadena 2 = 2 tiene longitud 2 .
176
4.9.2.
177
Este tipo de ataques [99] se producen cuando un atacante proporciona deliberadamente una clave pblica invlida. Si el usuario que desea enviar el mensaje cifrado
no comprueba la validez de la clave pblica del destinatario, ste podra haber proporcionado como clave un elemento de orden pequeo, con el objetivo de limitar el
rango posible para el dato secreto compartido o incluso tratar de obtener alguna
informacin sobre la clave privada del remitente.
Las opciones disponibles para evitar este tipo de ataques son la siguientes:
Calcular el orden de la clave pblica del destinatario, comprobando que es
igual a .
Utilizar la primitiva DHC en lugar de la funcin DH, comprobando que el
elemento = .
Reemplazar el dato secreto compartido por su resumen (por ejemplo, mediante
la funcin SHA-1) antes de utilizar ese dato como entrada de la funcin KDF.
Utilizar la clave pblica temporal del emisor como entrada de la funcin KDF.
En un escenario tpico, la validez de la clave pblica del destinatario ser realizada por un organismo de certificacin, por lo que esta solucin no tendra impacto
en una solucin comercial.
Por otra parte, la utilizacin de la funcin DHC conlleva otras desventajas, tal
como se menciona en 4.9.1.1, siendo una de las razones por las que los vectores de
test de [130, 253] nicamente utilizan la funcin DH.
Respecto a la utilizacin del resumen del dato secreto compartido en lugar de su
valor completo, aunque se menciona en [109] y fue implementado en Java Card 2.2,
en la prctica ninguno de los vectores de tests de [130] y [253] lo utilizan, y en la
ltima versin de Java Card se ha aadido un nuevo modo de operacin en el que
no se aplica ninguna funcin resumen a la salida de la funcin KA.
Finalmente, la opcin ms extendida en los estndares analizados consiste en
utilizar la clave pblica temporal del emisor como entrada de la funcin KDF, de
modo que en el diseo de la propia funcin KDF se incluye una funcin resumen
de tal manera que a partir de la salida de la funcin KDF no sea posible obtener
ninguna informacin til que pudiera llevar a determinar el valor utilizado.
Como consideracin adicional, si el par de claves temporal se genera aleatoriamente y se utiliza en un nico proceso de cifrado, aunque el atacante consiguiera
obtener alguna informacin relativa a este par de claves, dicha informacin no sera
til para posteriores procesos de cifrado.
178
4.9.3.
Aunque algunos autores como Shoup [243] consideran que es fundamental para
la seguridad de ECIES mantener las mismas funciones KDF, ENC y MAC durante
el ciclo de vida de un par de claves determinado, y en algunos estndares como IEEE
1363a est recomendada esta forma de proceder, en la prctica no existe consenso
[224] sobre el riesgo real que implicara el cambio de parmetros y funciones durante
el ciclo de vida de unas claves dadas.
Por otra parte, puesto que seguir la recomendacin de Shoup no parece tener
ningn efecto negativo, la prudencia sugiere en este caso imponer como requisito
que ni las funciones ni los parmetros puedan ser modificados durante el ciclo de
vida de un par de claves. Esto significa que, en la fase inicial de acuerdo de opciones
de los usuarios legtimos, stos deben realizar las comprobaciones adecuadas para
asegurar que, para un par de claves especfico, solamente se utilizar un conjunto de
parmetros a lo largo del ciclo de vida de esas claves.
4.10.
Una vez analizada la seguridad de ECIES en 4.9, es necesario revisar las caractersticas de la versin ECIES-4 definida en 4.8. Puesto que dicha versin (y
sus posibles variantes que empleen otras funciones resumen y MAC ) emplean la
funcin XOR, que puede ser utilizada por un atacante para generar problemas de
maleabilidad maligna, es necesario reconsiderar las decisiones tomadas respecto a la
versin de ECIES compatible con todos los estndares.
De las tres soluciones al problema de maleabilidad maligna descritas en 4.9.1.2,
la nica que es posible de implementar manteniendo la compatibilidad de la versin
ECIES-4 con los cuatro estndares consiste en fijar la longitud de los mensajes a
cifrar, lo que de hecho ya era recomendado en IEEE 1363a, donde adems se sugiere
que los nicos mensajes a cifrar mediante la funcin XOR sean claves de otros
algoritmos de cifrado simtrico.
Puesto que con la nica solucin compatible con todos los estndares la funcionalidad de ECIES queda seriamente limitada, se hace necesario seleccionar otra
configuracin como punto de partida para cualquier implementacin de ECIES. Dado que exceptuando C01 y C02 no existen ms configuraciones compatibles con los
cuatro estndares, los candidatos lgicos son aquellas configuraciones permitidas en
tres estndares, que resultan ser C05 y C06. Al igual que sucedi en 4.8, es posible
definir a partir de las configuraciones C05 y C06 mltiples versiones compatibles con
dichas configuraciones, y que se diferencien en la funcin HASH, la funcin MAC o
el uso de argumentos opcionales en la funcin de autenticacin.
Las versin ECIES-3 definida por el Algoritmo 4.17 constituye una de las po-
179
sibles variantes compatibles con las configuraciones C05 y C06 definidas por IEEE
1363a, ISO/IEC 18033-2 y SECG SEC 1. ECIES-3 incluye los elementos necesarios
para resistir cualquiera de los ataques contra ECIES conocidos y descritos en 4.9,
utilizando funciones que aseguren una correcta eficiencia y estn disponibles en las
libreras criptogrfica actuales.
Algoritmo 4.17 Cifrado ECIES compatible con los cuatro estndares (ECIES-3)
1. Elegir un valor aleatorio {1, 2, . . . , 1} como clave privada temporal
de U, y generar la clave pblica = .
2. Calcular un punto = ( , ) de la curva mediante la operacin = ,
donde es la clave pblica del usuario receptor.
3. Generar el elemento del que se obtendrn las clave de cifrado y autenticacin mediante la operacin =KDF ( ), siendo la funcin KDF elegida
KDF2 (equivalente a ANSI-X9.63-KDF sin parmetros opcionales) y la funcin HASH empleada SHA-256.
4. Interpretar como , donde las longitudes en bits de y
son 256 bits.
5. Producir el mensaje cifrado = ENC (), donde la funcin de cifrado simtrico ENC es el algoritmo AES en modo CBC y relleno PKCS#5 utilizando
claves de 256 bits.
6. Calcular la etiqueta tag utilizando el mtodo tag = MAC (||Param 2 ), donde
la funcin MAC elegida es HMAC-SHA-256 con salida de 256 bits y el
elemento Param 2 representa la concatenacin de una cadena binaria (que
representa un dato conocido por usuario y emisor) junto con la longitud en
bits de dicho dato empleando para su codificacin 8 bytes.
7. Enviar la tripleta = ( , ,tag) como criptograma concatenando los tres
elementos, de manera que la cadena binaria recibida por el usuario receptor
sea tag.
Captulo 5
Implementacin de ECIES en
entorno PC
5.1.
182
5.1.1.
Cifrado
183
5.1.2.
Descifrado
5.1.3.
En todo desarrollo software de ECC es necesario implementar dos tipos de operaciones: las referidas a los puntos de la curva, y las que operan con elementos del
cuerpo finito.
184
185
186
5.2.
Diagrama de clases
187
188
ElementoCuerpoF2m
La clase ElementoCuerpoF2m incluye la implementacin adaptada a los cuerpos finitos binarios de los mtodos definidos por la clase ElementoCuerpo.
ElementoCuerpoFp
La clase ElementoCuerpoFp incluye la implementacin adaptada a los cuerpos
finitos primos de los mtodos definidos por la clase abstracta ElementoCuerpo.
FicheroPubPri
La clase FicheroPubPri define los iconos azul y rojo utilizados por la aplicacin en las ventanas de seleccin de ficheros para identificar los archivos con
claves pblicas y privadas, respectivamente.
FiltroDocumentos
La clase FiltroDocumentos incluye los elementos que permiten limitar el tipo
de datos de entrada (dgitos, caracteres hexadecimales o alfabeto ASCII) de
las cajas de texto utilizadas por la aplicacin.
FiltroFicheros
La clase FiltroFicheros permite crear los filtros necesarios con el objetivo de
de mostrar nicamente los ficheros con extensin .pri y .pub en las ventanas
de seleccin de ficheros de claves pblicas y privadas respectivamente.
IntArray
La clase IntArray implementa la lgica de soporte para la realizacin de operaciones relacionadas con bases polinmicas en cuerpos binarios.
JDialogAcerca
La clase JDialogAcerca es utilizada para mostrar informacin sobre la versin
de la aplicacin ECIES y sobre los autores del desarrollo.
JDialogAyuda
La clase JDialogAyuda incluye los elementos grficos de la ventana emergente
utilizada por ECIES para presentar al usuario la pgina HTML con informacin sobre la aplicacin.
JDialogClave
La clase JDialogClave es utilizada por la aplicacin ECIES durante la interpretacin de los contenidos de un fichero que contenga una clave privada, a fin
de permitir al usuario introducir su cdigo de acceso a dicha clave.
189
JDialogDescompresin
La clase JDialogDescompresin implementa la funcionalidad ofrecida por la
ventana emergente del submen Descompresin de puntos, descrito en 5.3.7.3.
JDialogFicheros
La clase JDialogFicheros representa la ventana emergente utilizada por el
submen Crear ficheros con claves, cuya funcionalidad est descrita en 5.3.7.1.
JDialogGenerarClave
La clase JDialogGenerarClave implementa la lgica utilizada por la ventana
emergente del submen Clave aleatoria, descrito en 5.3.7.2.
Punto
La clase abstracta Punto define los mtodos que sern implementados por las
clases PuntoFp y PuntoF2m, y que contienen la lgica para crear puntos de una
curva elptica definida sobre un cuerpo finito y operar con ellos.
PuntoF2m
La clase PuntoF2m incluye la implementacin adaptada a los cuerpos finitos
binarios de los mtodos definidos por la clase abstracta Punto.
PuntoFp
La clase PuntoFp incluye la implementacin adaptada a los cuerpos finitos
primos de los mtodos definidos por la clase abstracta Punto.
Utilidades
La clase Utilidades incluye los mtodos para realizar conversiones entre elementos de tipo array de bytes, BigInteger y las cadenas de texto que representan un contenido hexadecimal o decimal. De manera adicional, esta clase
incluye las funciones para generar y convertir texto en los formatos ASCII y
Base64.
La implementacin de la aritmtica de puntos de la curva y de elementos de los
cuerpos finitos se ha realizado utilizando la clase estndar BigInteger [209] de Java
SE, que permite operar con valores enteros de longitud variable, e incluye funciones
como la suma con otro elemento BigInteger (mtodo add), el clculo de la longitud
en bits del valor entero (biLength), la obtencin del inverso mdulo otro elemento
del mismo tipo (modInverse), el resultado de la operacin XOR con otra variable
BigInteger (xor) o la exponenciacin modular (modPow), entre otras funciones.
190
5.3.
En este apartado se describen de manera detallada las funcionalidades de la aplicacin ECIES para entorno PC, mostrando las diferentes pantallas que la conforman,
as como las opciones que se ofrecen al usuario. De esta manera se proporciona una
visin prctica de lo expuesto en los captulos anteriores, representando un ejemplo
de las posibilidades de las aplicaciones para entorno PC que implementen capacidades de criptografa de curva elptica.
Esta aplicacin para PC se ha desarrollado utilizando el entorno de desarrollo
NetBeans 6.7 y Java SE 6. La Figura 5.2 muestra la ventana principal de NetBeans
con el proyecto del programa de cifrado ECIES seleccionado.
5.3.1.
Ventana principal
191
tal como muestra la Figura 5.3. En ella pueden observarse las tres zonas principales
en que se divide la pantalla, y que se corresponden con las reas delimitadas mediante
un recuadro rojo, azul y verde respectivamente en la Figura 5.3.
Barra del men principal: proporciona acceso a todos los mens y opciones
del programa. Los elementos que se encuentran disponibles en el modo sencillo
cuando se inicia la ejecucin son Programa, Modo, Curvas, Utilidades y Cuerpo
GF(), mientras que si se utiliza el modo avanzado entonces tambin estarn
disponibles los elementos Perfiles y Test.
Barra de pestaas: permite seleccionar la pestaa activa mediante una presentacin tabular. En el modo sencillo las pestaas disponibles son Parmetros,
Cifrado y Descifrado, a las que se aade la pestaa Configuracin en el modo
avanzado.
Pestaa activa: rea de presentacin donde se sitan los elementos pertenecientes la pestaa en uso.
5.3.2.
Men Programa
Submen Aspecto
La opcin Aspecto (ver Figura 5.4) permite adaptar las caractersticas de todos
los elementos de la aplicacin (textos, iconos, colores, etc.) a las de los temas grficos disponibles en Java. Las posibilidades existentes en la versin Java SE 6 para
plataformas PC son:
Metal: apariencia Java multiplataforma presente desde las primeras versiones
del JDK.
Nimbus: nueva apariencia Java multiplataforma disponible desde la revisin
10 de Java SE 6.
Motif: aspecto Unix.
Windows: apariencia nativa de las aplicaciones Windows.
Windows Clsico: tema grfico muy similar al anterior pero con un aspecto
ms clsico.
192
193
5.3.2.2.
Submen Ayuda
La opcin Ayuda (ver Figura 5.4) permite acceder a una ventana en la que se
presenta la ayuda del programa en formato HTML, tal como puede apreciarse en la
Figura 5.7.
194
5.3.2.3.
Submen Acerca de
La opcin Acerca de (ver Figura 5.4) muestra informacin general sobre la versin
del programa y los responsables del desarrollo, tal como aparece en la Figura 5.8.
5.3.2.4.
Submen Salir
La opcin Salir (ver Figura 5.4), al igual que el icono situado en la esquina superior derecha en todas las aplicaciones Windows, permite abandonar la aplicacin.
Sin embargo, en previsin de la activacin accidental de esta opcin, antes de
abandonar el programa se mostrar al usuario una pantalla de confirmacin, tal
como queda reflejado en la Figura 5.9.
5.3.3.
Men Modo
El men Modo permite seleccionar el modo de uso sencillo o avanzado, tal como
se detalla en los siguientes apartados.
195
196
5.3.3.1.
El modo sencillo (Figura 5.10) utiliza una parametrizacin fija del esquema
ECIES, correspondiente a la versin ECIES-3, que consiste en los siguientes elementos:
Funcin resumen HASH : SHA-256.
Funcin KDF : KDF2.
Funcin MAC : HMAC-SHA-256-256.
Funcin de cifrado ENC : AES en modo CBC con relleno PKCS#5.
Longitud de la clave MAC : 32 bytes.
Longitud de la clave de cifrado: 32 bytes.
Inclusin de la clave temporal del emisor como parmetro de KDF : activado.
Interpretacin de la salida de la funcin KDF : ENC ||MAC.
Representacin binaria: comprimida.
Junto a la utilizacin de los parmetros anteriores, el modo sencillo oculta los
mens Perfiles y Test de la barra de mens, as como la pestaa Configuracin, ya
que estos elementos slo tienen utilidad en el modo avanzado.
5.3.3.2.
Opcin Avanzado
El modo avanzado (Figura 5.11) permite, en comparacin con el modo sencillo, especificar todos los parmetros para los que el esquema ECIES puede utilizar
distintas opciones. En concreto, los elementos que es posible parametrizar son los
siguientes:
197
5.3.4.
El men Perfiles (Figura 5.12) permite, en el modo avanzado, definir los valores
de los elementos de la pestaa Configuracin relacionados con un mismo modo
de operacin. Las opciones que el usuario puede elegir estn relacionadas con las
configuraciones M1, M2, P1, P2 y P3 descritas en 7.2 y utilizadas en las pruebas
del Captulo 7.
198
5.3.4.1.
Opcin Configuracin M1
Opcin Configuracin M2
199
Opcin Configuracin P1
200
Opcin Configuracin P2
Opcin Configuracin P3
201
5.3.5.
El men Test es similar al men Perfiles, puesto que permite configurar los parmetros de ECIES de la pestaa Configuracin en el modo avanzado, pero adems
aade los valores necesarios de la pestaa Parmetros de acuerdo a los documentos
de prueba relacionados en cada caso.
5.3.5.1.
Submen ISO/IEC
El submen ISO/IEC (Figura 5.13) incluye los tests C.2.2 y C.2.3 recogidos en
ISO/IEC 18033-2 [136].
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.3.6.
Men Curvas
El men Curvas permite cargar en la pestaa Parmetros informacin correspondiente a la curva seleccionada en funcin de su proveedor y del identificador
asignado a la curva.
5.3.6.1.
Submen ANSI
El submen ANSI (Figura 5.15) incluye las siguientes curvas definidas sobre
cuerpos primos y binarios en el documento ANSI X9.62 [15]:
Curvas sobre : ansix9p192r1, ansix9p192k1, ansix9p224r1, ansix9p224k1, ansix9p256r1, ansix9p256k1, ansix9p384r1 y ansix9p521r1.
Curvas sobre 2 : ansix9t163r2, ansix9t163k1, ansix9t193r1, ansix9t193r2, ansix9t233r1, ansix9t233k1, ansix9t239k1, ansix9t283r1, ansix9t283k1, ansix9t409r1,
ansix9t409k1, ansix9t571r1 y ansix9t571k1.
El significado de los elementos utilizados en los identificadores de las curvas
ANSI se explica a continuacin:
ansix9 : identifica las curvas definidas por ANSI en [15].
p: indica que se trata de una curva sobre cuerpos primos.
t: identifica las curvas sobre cuerpos binarios.
Primera cadena de dgitos: expresa el tamao en bits del cuerpo sobre el que
est definida la curva.
r : informa que los coeficientes de la curva se han generado de forma aleatoria
mediante una semilla y una funcin resumen de acuerdo al procedimiento
descrito en [15].
203
k : identifica las curvas de Koblitz (tambin conocidas como curvas anmalas binarias) que facilitan la realizacin de operaciones con los puntos de la
curva. En curvas sobre cuerpos binarios, las curvas de Koblitz estn definidas
mediante la ecuacin 2 + = 3 + 2 + 1, con {0, 1}. ANSI X9.62
tambin utiliza el trmino k para referirse a curvas definidas sobre cuerpos
primos, dadas por la ecuacin 2 = 3 + + , donde = 0 y el valor de es
muy pequeo en comparacin con (3, 5, 7, etc.).
Dgito final: permite diferenciar curvas donde el resto de los parmetros utilizados por esta notacin coinciden.
Es importante resaltar que las curvas publicadas en la versin de 2005 del estndar X9.62 no coinciden con las incluidas en la edicin de 1998, puesto que tal
como se describe en [15], algunas se eliminaron por no ser consideradas seguras a
la vista de los ltimos avanzas en criptoanlisis (c2pnb176w1, c2pnb163v3, etc.).
De manera adicional, la edicin de 2005 cambi los identificadores de las restantes
curvas (por ejemplo, la curva ansix9p192r1 de la edicin de 2005 es la misma que la
curva prime192v1 de la edicin de 1998).
204
5.3.6.2.
El submen Brainpool (Figura 5.16) incluye las siguientes curvas definidas sobre
cuerpos primos, tal como aparecen recogidas en la pgina web del grupo de trabajo
Brainpool [33]:
Curvas sobre : P160r1, P192r1, P224r1, P256r1, P320r1, P384r1 y P512r1.
Es necesario indicar que Brainpool no dispone de curvas sobre cuerpos binarios
2 . El significado de los elementos utilizados en los identificadores de las curvas
Brainpool se muestra a continuacin:
P : identifica las curvas sobre cuerpos primos.
Primera cadena de dgitos: expresa el tamao en bits del cuerpo sobre el que
est definida la curva.
r : informa que los coeficientes de la curva se han generado aleatoriamente
segn el procedimiento descrito en [34].
Dgito final: permite identificar diferentes curvas donde el resto de los parmetros utilizados por esta notacin coinciden.
5.3.6.3.
Submen NIST
El submen NIST (Figura 5.17) incluye las siguientes curvas definidas sobre
cuerpos primos y binarios en el documento FIPS 186-3 [184]:
Curvas sobre : P-192, P-224, P-256, P-384 y P-521.
Curvas sobre 2 : K-163, B-163, K-233, B-233, K-283, B-283, K-409, B-409,
K-571 y B-571.
205
Submen SECG
El submen SECG (Figura 5.18) incluye las siguientes curvas definidas sobre
cuerpos primos y binarios en el documento SEC 2 [255]:
Curvas sobre : secp112r1, secp112r2, secp128r1, secp128r2, secp160k1, secp160r1, secp160r2, secp192k1, secp224k1, secp224r1, secp256k1, secp384r1 y
secp521r1.
206
Curvas sobre 2 : sect113r1, sect113r2, sect131r1, sect131r2, sect163k1, sect163r1, sect163r2, sect193r1, sect193r2, sect233k1, sect233r1, sect239k1, sect283k1, sect283r1, sect409k1, sect409r1, sect571k1 y sect571r1.
El significado de los elementos utilizados como parte de los identificadores de las
curvas del consorcio SECG se detalla a continuacin:
secp: identifica las curvas sobre cuerpos primos.
sect: indica que se trata de una curva sobre cuerpos binarios.
Primera cadena de dgitos: expresa el tamao en bits del cuerpo sobre el que
est definida la curva.
207
5.3.7.
Men Utilidades
La opcin Crear ficheros con claves (ver Figura 5.19) permite generar un par de
claves utilizando la informacin de las curvas estndares referidas en 5.3.6, almacenando la informacin resultante en un fichero con extensin .pri que contiene la
clave privada y un fichero con extensin .pub que alberga la clave pblica.
208
209
deseado.
Informacin adicional (opcional): texto que, en caso de ser incluido en los
ficheros de claves, ser utilizado por el programa como identificador de la
clave.
Algoritmo 5.5 Generacin de una semilla aleatoria
Ejecutar el siguiente bucle seis veces:
1. Obtener el tiempo en milisegundos mediante la funcin estndar del lenguaje
Java SE System.currentTimeMillis().
2. Multiplicar el valor obtenido por el nmero de iteracin.
3. Identificar los ltimos tres dgitos del resultado de la multiplicacin.
4. Concatenar esos tres dgitos con los obtenidos en las anteriores iteraciones,
formando una cadena final de dieciocho dgitos.
Los ficheros de claves generados contienen toda la informacin necesaria para
poder identificar las claves y realizar las operaciones de cifrado y descifrado, utilizando internamente una estructura XML para almacenar los distintos datos. A
continuacin se muestra un ejemplo del contenido de un fichero .pub que alberga la
clave pblica de un usuario:
<?xml version=1.0 encoding=ISO-8859-1 standalone=yes?>
<!--Creado por el Programa de Cifrado ECIES-->
<parmetros>
<param id=1>
<notacin>HEXA</notacin>
<cuerpo>Fp</cuerpo>
<clave>
<tipo>Pblica</tipo>
<proveedor>SEC</proveedor>
<identificador>secp112r1</identificador>
</clave>
<info>Clave de Vctor</info>
<p>DB7C2ABF62E35E668076BEAD208B</p>
<a>DB7C2ABF62E35E668076BEAD2088</a>
<b>659EF8BA043916EEDE8911702B22</b>
<Gx>09487239995A5EE76B55F9C2F098</Gx>
<Gy>A89CE5AF8724C0A23E0E0FF77500</Gy>
<n>DB7C2ABF62E35E7628DFAC6561C5</n>
<Vx>CBB0C998897515D8AF9E474ADEF0</Vx>
210
<Vy>7B492D22D7872C4CCAB5B58620CC</Vy>
</param>
</parmetros>
Continuando con el mismo ejemplo, el fichero .pri que contiene la clave privada
del usuario anterior tendra el siguiente contenido:
<?xml version=1.0 encoding=ISO-8859-1 standalone=yes?>
<!--Creado por el Programa de Cifrado ECIES-->
<parmetros>
<param id=1>
<notacin>HEXA</notacin>
<cuerpo>Fp</cuerpo>
<clave>
<tipo>Privada</tipo>
<proveedor>SEC</proveedor>
<identificador>secp112r1</identificador>
</clave>
<info>Clave de Vctor</info>
<p>DB7C2ABF62E35E668076BEAD208B</p>
<a>DB7C2ABF62E35E668076BEAD2088</a>
<b>659EF8BA043916EEDE8911702B22</b>
<Gx>09487239995A5EE76B55F9C2F098</Gx>
<Gy>A89CE5AF8724C0A23E0E0FF77500</Gy>
<n>DB7C2ABF62E35E7628DFAC6561C5</n>
<uC>7D1C0CF1FC2B741B960A7AE0093B7485</uC>
</param>
</parmetros>
A continuacin se muestra otro ejemplo de ficheros .pub y .pri, en esta ocasin
representando un par de claves definidas sobre un cuerpo binario:
<?xml version=1.0 encoding=ISO-8859-1 standalone=yes?>
<!--Creado por el Programa de Cifrado ECIES-->
<parmetros>
<param id=1>
<notacin>HEXA</notacin>
<cuerpo>F2m</cuerpo>
<clave>
<tipo>Pblica</tipo>
<proveedor>SEC</proveedor>
<identificador>sect113r1</identificador>
211
</clave>
<info>Clave de Luis</info>
<m>71</m>
<k3></k3>
<k2></k2>
<k1>09</k1>
<a>3088250CA6E7C7FE649CE85820F7</a>
<b>E8BEE4D3E2260744188BE0E9C723</b>
<Gx>9D73616F35F4AB1407D73562C10F</Gx>
<Gy>A52830277958EE84D1315ED31886</Gy>
<n>0100000000000000D9CCEC8A39E56F</n>
<Vx>5AC878E613A8C0EB857D2C007453</Vx>
<Vy>5F9964C68A87793F17F13669DB44</Vy>
</param>
</parmetros>
<?xml version=1.0 encoding=ISO-8859-1 standalone=yes?>
<!--Creado por el Programa de Cifrado ECIES-->
<parmetros>
<param id=1>
<notacin>HEXA</notacin>
<cuerpo>F2m</cuerpo>
<clave>
<tipo>Privada</tipo>
<proveedor>SEC</proveedor>
<identificador>sect113r1</identificador>
</clave>
<info>Clave de Luis</info>
<m>71</m>
<k3></k3>
<k2></k2>
<k1>09</k1>
<a>3088250CA6E7C7FE649CE85820F7</a>
<b>E8BEE4D3E2260744188BE0E9C723</b>
<Gx>9D73616F35F4AB1407D73562C10F</Gx>
<Gy>A52830277958EE84D1315ED31886</Gy>
<n>0100000000000000D9CCEC8A39E56F</n>
<uC>9442D1ACEE5F3C384AA8060424A3CCEA</uC>
</param>
</parmetros>
212
<param id =1>: nmero de clave (ya sea pblica o privada) relativo al fichero, dado que los ficheros .pri y .pub permiten ser utilizados como agendas
de claves y almacenar ms de una clave.
<notacin>: indicacin relativa a la notacin empleada para representar los
datos. El nico valor utilizado en la generacin de los ficheros es HEXA, lo que
implica que los datos se encuentran definidos en formato hexadecimal. Esta
decisin de diseo no afecta al proceso de lectura de los ficheros de claves
como parte de las operativas de cifrado y descifrado, donde adems del valor
HEXA tambin es posible utilizar el valor DECIMAL, indicando que los datos se
encuentran representados como nmeros en esta base.
<cuerpo>: cuerpo de la curva elptica utilizada en la generacin de las claves.
En funcin del cuerpo seleccionado, los posibles textos para esta opcin son
Fp y F2m.
<clave>: cadena informativa que incluye los elementos <tipo> (que puede
tener los valores Privada y Pblica), <proveedor> (cuyos valores posibles
son ANSI, Brainpool, NIST y SEC) y por ltimo <identificador>, el nombre
especfico que cada proveedor otorga a sus curvas.
<info>: informacin adicional utilizada por el programa para presentarla por
pantalla, de manera que el usuario pueda seleccionar la clave adecuada durante
los procesos de cifrado y descifrado.
<a>, <b>, <Gx>, <Gy>, <n>: parmetros comunes para curvas definidas tanto
sobre un cuerpo primo como binario.
<p>: parmetro asociado a las curvas definidas sobre un cuerpo primo.
<m>, <k3>, <k2>, <k1>: parmetros de la curvas definidas sobre un cuerpo
binario.
<Vx>, <Vy>: coordenadas del punto que representa la clave pblica creada.
<uC>: clave privada del usuario cifrada con el algoritmo AES mediante el cdigo
de acceso.
5.3.7.2.
La opcin Clave aleatoria (ver Figura 5.19) ofrece la posibilidad de generar una
clave privada pseudoaleatoria a partir de los datos de entrada, que dependiendo del
cuerpo de trabajo son:
Cuerpos : nmero primo y semilla de aleatoriedad.
213
214
5.3.7.3.
La opcin Descompresin de puntos (ver Figura 5.19) permite, tras introducir los
datos asociados a una curva elptica y a un punto de la curva en formato comprimido,
obtener ambas coordenadas de dicho punto.
Dependiendo del cuerpo de trabajo, la ventana del men Descompresin de puntos es diferente, tal como puede comprobarse en las Figuras 5.23 y 5.24.
5.3.8.
215
5.3.9.
216
SHA-256.
SHA-384.
SHA-512.
HMAC-SHA-256-256.
HMAC-SHA-384-384.
HMAC-SHA-512-512.
217
5.3.10.
Pestaa Parmetros
218
219
220
221
5.3.11.
Pestaa Cifrado
La pestaa Cifrado muestra todos los elementos necesarios para generar un criptograma a partir de un mensaje en claro utilizando ECIES. La ventana est divida
en tres secciones, delimitadas por recuadros de color verde, azul y rojo que se corresponden, respectivamente, con las zonas de gestin de opciones, las cajas de texto y
los botones de operacin, tal como puede apreciarse en la Figura 5.30.
La primera seccin est formada por los siguientes elementos:
222
Clave pblica receptor : clave pblica permanente del destinatario del criptograma. Si el usuario pulsa la opcin Texto, la pestaa Parmetros pasar a ser
la pestaa en uso, de manera que el usuario pueda introducir manualmente los
datos asociados a la clave pblica del receptor. En cambio, si el usuario elige la
opcin Fichero, el programa permitir seleccionar el fichero donde se encuentra
la clave pblica, tal como puede apreciarse en la Figura 5.31. Si el procesamiento del fichero con la clave pblica es correcto, en la pestaa Parmetros
aparecern los datos obtenidos del fichero con extensin .pub seleccionado.
Mensaje a cifrar : mensaje en claro que el emisor desea enviar al receptor. Si
el usuario pulsa la opcin Texto (opcin por defecto), deber introducir el
mensaje manualmente, sin que exista ningn lmite en la longitud del mensaje
generado por el usuario. Por el contrario, si el usuario elige la opcin Fichero, el
programa permitir seleccionar el fichero cuyo contenido binario ser utilizado
como mensaje en claro, tal como puede observarse en la Figura 5.32. Si el
procesamiento del fichero que representa el mensaje es correcto y su tamao
223
224
225
donde i tendr como valor la posicin de la clave. Por ltimo, si el fichero contuviera
solamente una clave, y el elemento <info> no fuera vlido o no estuviera presente, el
programa utilizar como identificador el nombre del fichero. La Figura 5.34 muestra
las diversas variantes existentes en la representacin del identificador de la clave
pblica.
La segunda seccin de la pestaa Cifrado est compuesta por las siguientes cajas
de texto:
Mensaje a cifrar : contenido del mensaje en claro a cifrar (o sus primeros 1024
bytes en caso de que el mensaje se haya obtenido de un fichero y su longitud
sea mayor que ese lmite).
Etiqueta: elemento de uso opcional a utilizar por la funcin MAC.
Criptograma: mensaje cifrado empaquetado (constituyendo una tripleta de
elementos) obtenido mediante el esquema ECIES (o sus primeros 1024 bytes
en caso de que el usuario haya decidido almacenar el criptograma en un fichero
y su longitud sea mayor que ese valor).
Resultado: campo con informacin acerca del resultado de la ejecucin.
Las cajas de texto del mensaje en claro y de la etiqueta permiten mostrar su contenido interpretado como texto o en formato hexadecimal. En caso de que el mensaje
226
a cifrar no sea interpretable como texto ASCII, al seleccionar el formato Texto aparecer en una fuente de color rojo la leyenda El contenido no es interpretable
como texto, tal como muestra la Figura 5.35.
Asimismo, el programa permite visualizar el criptograma en formato hexadecimal
y Base64, permitiendo que pueda ser enviado de forma cmoda por correo electrnico
utilizando esta ltima codificacin.
La tercera seccin de la pestaa Cifrado est formada por los siguientes elementos:
Cifrar : botn que desencadena la generacin de un criptograma ECIES a partir
del mensaje en claro, la etiqueta y los parmetros asociados.
Borrar : botn que permite borrar el contenido de las cajas de texto de esta
pantalla y devolver las opciones de configuracin de la primera seccin a su
estado inicial.
La Figura 5.36 muestra un ejemplo del proceso de cifrado, en el que se ha seleccionado la clave pblica del receptor de un fichero que contiene un elemento <info>
vlido (y que por tanto es el utilizado como identificador de la clave pblica), el fichero Inicio de Don Quijote.txt contiene el mensaje en claro y el fichero Quijote
cifrado.out se emplear para almacenar el resultado de la operacin.
Si la operacin efectuada es correcta, los posibles mensajes de xito que puede
mostrar el elemento Resultado son:
Clave pblica recuperada correctamente.
Proceso finalizado correctamente.
Por el contrario, algunos de los posibles mensajes de error que puede mostrar el
elemento Resultado son:
Falta seleccionar la funcin resumen en Configuracin.
Falta seleccionar la funcin KDF en Configuracin.
Falta seleccionar la funcin MAC en Configuracin.
227
5.3.12.
Pestaa Descifrado
228
azul y rojo, y que se corresponden con el rea de gestin de opciones, las cajas de
texto y los botones de operacin.
229
230
231
232
233
La Figura 5.45 muestra un ejemplo de proceso de descifrado, en el que se ha seleccionado la clave de un fichero que contiene un elemento <info> vlido (y que por
tanto es el representado como identificador de la clave privada), el fichero Quijote
cifrado.out contiene el criptograma y el fichero Quijote descifrado.txt se utilizar para almacenar el mensaje en claro resultante de la operacin.
234
5.4.
Ejemplos de utilizacin
5.4.1.
Ejemplo de cifrado
Figura 5.46: Seleccin del fichero con la clave pblica del destinatario
235
236
237
238
5.4.2.
Ejemplo de descifrado
239
Figura 5.54: Seleccin del fichero con la clave privada del destinatario
240
241
242
correctamente junto al elemento Resultado, y la caja de texto del elemento Mensaje descifrado mostrar los primero 1024 bytes del mensaje original
en color azul (Figura 5.62), indicando que el mensaje descifrado completo se
encuentra almacenado en el fichero Quijote descifrado.txt.
Captulo 6
Implementacin de ECIES en Java
Card
6.1.
244
6.1.1.
6.1.2.
6.1.3.
Java Card 2.2 fue la primera versin en incluir soporte para ECC, que junto con
el resto de las novedades conforman la siguiente lista de caractersticas criptogrficas
relacionadas con ECIES:
Funcin HASH : SHA-1.
Funcin KA: DH y DHC, aunque con la particularidad de que el resultado
obtenido consiste en la salida de la primera coordenada del elemento secreto
compartido tras pasar por la funcin SHA-1.
Funcin ENC : AES con bloques de 128 bits utilizando los modos CBC y ECB,
en ambos casos sin relleno, y longitudes de claves 128, 192 y 256 bits.
Claves ECC: soporte para claves de 113, 131, 163 y 193 bits en cuerpos binarios
y claves de 112, 128, 160 y 192 bits en cuerpos primos.
6.1.4.
6.1.5.
245
6.1.6.
246
6.2.
El Cuadro 6.1 recoge de forma resumida la informacin presentada en los anteriores apartados, donde DH y DHC son las funciones de acuerdo de clave Diffie-Hellman
con y sin cofactor, mientras que DH y DHC representan las mismas funciones con
la particularidad de que la salida de la funcin es el resumen de la primera coordenada del elemento secreto compartido proporcionado por las funciones DH y DHC.
JC 2.2
SHA-1
HASH
KA
ENC
MAC
JC 2.2.1
SHA-1
JC 2.2.2
SHA-1
SHA-256
SHA-384
SHA-512
JC 3.0
SHA-1
SHA-224
SHA-256
SHA-384
SHA-512
DH
DH
DH
DH
DHC
DHC
DHC
DHC
DH
DHC
DES
DES
DES
DES
TDES
TDES
TDES
TDES
AES-128
AES-128
AES-128
AES-128
AES-192
AES-256
HMAC-SHA-1
HMAC-SHA-1
HMAC-SHA-256 HMAC-SHA-256
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,
224,256,384
113,131,163,193 113,131,163,193 113,131,163,193 113,131,163,193
Cuadro 6.1: Funcionalidades ECC en Java Card
6.3.
Entorno de desarrollo
6.3.1.
247
NetBeans
6.3.2.
La segunda opcin para el desarrollo de applets Java Card fue utilizar directamente los ejecutables mediante lnea de comandos proporcionados por Sun. Para
ello, fue necesario configurar el PC de trabajo de la siguiente manera:
1. Instalacin de JDK 1.5 en la carpeta C:\Java\jdk1.5.0_21.
2. Configuracin de la variable del sistema JAVA_HOME con la localizacin del
directorio C:\Java\jdk1.5.0_21.
3. Instalacin del paquete Java Card 2.2.2 en C:\java_card_kit-2_2_2.
4. Configuracin de la variable del sistema JC_HOME con el valor de la carpeta
C:\java_card_kit-2_2_2.
5. Instalacin de la versin 1.6.2 del software Ant en C:\apache-ant-1.6.2.
6. Configuracin de la variable del sistema ANT_HOME con el valor del directorio C:\apache-ant-1.6.2.
7. Modificacin de la variable PATH del sistema para que incluya la cadena
%JAVA_HOME %\bin; %JC_HOME %\bin; %ANT_HOME %\bin.
La generacin del applet se efecta en dos pasos: en el primero, se realiza la
compilacin del fichero con extensin .java, generando un fichero .class; en el segundo
paso, se obtiene el fichero con extensin .cap que ser posteriormente descargado en
la tarjeta (para ms informacin sobre el proceso de compilacin de los applets en
Java Card, ver 3.5).
Para realizar la compilacin del fichero JCECIES.java, es necesario seguir los
siguientes pasos:
1. Guardar el fichero JCECIES.java en C:\JCECIES\src\victor\tesis\.
248
6.3.3.
Eclipse
Tras recibir las tarjetas JCOP 41 y JCOP J3A utilizadas en la Tesis (ver 6.6 y
7.1), el entorno de desarrollo seleccionado para completar el desarrollo de los applets
fue Eclipse 3.2, puesto que primero IBM y ms tarde NXP han desarrollado sucesivas
versiones de los complementos (plug-ins) para Eclipse que permiten programar y
descargar applets de manera sencilla en tarjetas de prueba JCOP.
La Figura 6.1 muestra la ventana principal de la aplicacin Eclipse 3.2 con los
complementos de NXP instalados.
6.4.
Esquema de la aplicacin
Antes de iniciar la fase de trabajo con tarjetas reales, en previsin de que no fuera
posible conseguir tarjetas que implementaran curvas definidas tanto sobre cuerpos
primos como binarios, se disearon dos versiones de la aplicacin Java Card cuya
249
nica diferencia fuera precisamente el tipo de curvas empleadas. Estas dos versiones
fueron desarrolladas y depuradas utilizando las herramientas de consola descritas
en 6.3.2, de manera independiente respecto al modelo de tarjetas sobre el que se
descargaran los applets.
El Listado 6.1 muestra el esquema general de la aplicacin Java Card diseada
para curvas elpticas definidas sobre cuerpos binarios. En el caso de curvas elpticas
sobre cuerpos primos la aplicacin es equivalente, representando los valores 01, 02,
03 y 04 del parmetro P1 en ese caso las curvas de 112, 128, 160 y 192 bits de
longitud.
1
package v i c t o r . t e s i s ;
2
3
4
5
import j a v a c a r d . framework . ;
import j a v a c a r d . s e c u r i t y . ;
import j a v a c a r d x . c r y p t o . ;
6
7
8
9
10
11
12
13
14
15
250
16
17
18
19
20
21
22
23
public boolean s e l e c t ( )
{
return true ;
}
24
25
26
27
28
29
byte [ ] b u f f e r = apdu . g e t B u f f e r ( ) ;
30
31
32
33
34
if ( selectingApplet () )
{
return ;
}
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
251
{
//
//
//
//
//
//
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
252
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
6.5.
253
Las herramientas de desarrollo para Java Card de Sun incluyen el fichero ejecutable cref.exe, que es una implementacin en el lenguaje de programacin C
del JCRE. Utilizando este programa junto con apdutool.exe, es posible simular el
comportamiento de una tarjeta Java Card, cargar aplicaciones y enviarles comandos
para realizar pruebas bsicas mediante ficheros de instrucciones (scripts).
La implementacin que hace el programa cref.exe de la plataforma Java Card
no es completa, y adems vara en cada edicin de Java Card. Mientras que el
soporte de las capacidades criptogrficas en la versin de cref.exe que se incluye
con el paquete de desarrollo para Java Card 2.2.2 es bastante completo, la versin
para Java Card 3.0 proporcionada por Sun hasta el momento no implementa ninguna
funcionalidad criptogrfica.
A ttulo informativo, a continuacin se detallan las caractersticas criptogrficas
implementadas en la versin de cref.exe para Java Card 2.2.2:
Funcin HASH : ejecuta correctamente las funciones ALG_SHA y ALG_SHA_256.
Las otras dos variantes, ALG_SHA_384 y ALG_SHA_512, producen una excepcin
de tipo CardRuntime.
Funcin ENC : el modo ALG_AES_BLOCK_128_CBC_NOPAD se ejecuta correctamente, pero el modo ALG_AES_BLOCK_128_ECB_NOPAD, aunque no produce
errores en la compilacin, genera una excepcin CardRuntime.
Funcin MAC : no soporta ninguno de los mtodos HMAC definidos en las
API de Java Card (ALG_HMAC_SHA1, ALG_HMAC_SHA_256, ALG_HMAC_SHA_384
y ALG_HMAC_SHA_512).
A continuacin se muestran los pasos necesarios para generar un fichero de instrucciones con los datos necesarios para cargar e instalar la aplicacin en una tarjeta
virtual, donde como se puede observar es necesario aadir el elemento 0x7F al final
de cada comando.
1. Acceder al directorio C:\JCECIES\src.
2. Ejecutar el comando
scriptgen -o JCECIES.scr .\victor\tesis\javacard\tesis.cap.
Tras realizar este paso, se generar el el fichero JCECIES.scr en el directorio
C:\JCECIES\src.
3. Editar el fichero JCECIES.scr, aadindole las siguientes lneas al principio
del fichero:
254
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 fichero de instrucciones es necesario realizar las
siguientes acciones:
1. Abrir una consola de MS-DOS y ejecutar el comando cref.exe.
2. Abrir en paralelo otra consola de MS-DOS, acceder al directorio donde se
encuentre el fichero de instrucciones JCECIES.scr y ejecutar el comando
apdutool.exe -o APDU.txt JCECIES.scr
Mediante el ltimo comando, el resultado de la ejecucin de las instrucciones se
almacenar en el fichero APDU.txt.
6.6.
256
applet en lugar de las dos previstas inicialmente. Dichas versiones son las correspondientes a las configuraciones de prueba M2, P2 y P3 descritas en 7.2, y para
diferenciar en lo sucesivo los tres applets Java Card, las tres versiones del applet se
han denominado JCOP-M2, JCOP-P2 y JCOP-P3.
La instalacin de los applets en las tarjetas JCOP se realiz mediante el entorno
de desarrollo Eclipse 3.2 junto con los complementos JCOP Tools 3.2.8 y SmartMX
Target-Pack for JCOP Tools 1.2.9 proporcionados por NXP, que permiten realizar
la descarga de la aplicacin desde el entorno Eclipse utilizando las claves que por
defecto incluyen todas las tarjetas JCOP de desarrollo.
En cuanto al tamao de los applets, tal como puede apreciarse en la Figura 6.2
(compuesta por imgenes obtenidas del entorno de desarrollo Eclipse), la versin
JCOP-M2 (AID A00000000501) ocupa 5031 bytes, el tamao de la versin JCOPP2 (AID A00000000601) es 4328 bytes, y por ltimo la versin JCOP-P3 (AID
A00000000701) ocupa 4404 bytes. Dichas cantidades no incluyen ni las variables
que se alojarn en RAM (de tipo transient en Java Card) ni las que residirn en
memoria EEPROM (de tipo persistent), aunque s incluye las matrices formadas
por elementos constantes (es decir, las matrices de tipo final static).
La versin JCOP-M2 tiene un tamao superior a las otras dos puesto que las
tarjetas JCOP 41 implementan 4 tipos de curvas, mientras que las tarjetas JCOP
J3A permiten utilizar nicamente 3 curvas, por lo que la gestin de las curvas es
ms compleja en la versin JCOP-M2.
Por otra parte, el tamao de la versin JCOP-P3 es ligeramente superior al de
la versin JCOP-P2 debido a que las funciones MAC y HMAC (SHA-256 y HMACSHA-256) utilizadas en dicha versin generan unos datos de salida de mayor longitud
que las funciones correspondientes de la versin JCOP-P2 (SHA-1 y HMAC-SHA-1),
siendo necesario aumentar el tamao de los arrays con los que se trabaja de forma
interna.
Una vez realizada la descarga de la aplicacin en las tarjetas JCOP mediante
el entorno Eclipse y los complementos de NXP, las pruebas de comunicacin con el
applet Java se han realizado utilizando dos aplicaciones diferentes: el propio entorno
Eclipse, utilizado principalmente para depurar los diferentes applets mediante la
realizacin de pruebas individuales, y una aplicacin Java SE con interfaz grfica,
desarrollada por el autor de esta Tesis y presentada en detalle en 6.7.
6.7.
Aplicacin JCOPECIES
257
258
Pestaa Configuracin (Figura 6.3): incluye los elementos que permiten seleccionar el lector (Figura 6.4), el tipo de tarjeta (JCOP 41 o J3A) y la curva
(que depende de la tarjeta elegida, ver Figura 6.5). De forma adicional, esta
pestaa permite generar nuevos pares de claves para una tarjeta y curva dada, as como recuperar el valor de la clave pblica seleccionada, mostrando la
Figura 6.6 el resultado final de ambos procesos. Por ltimo, esta pantalla incluye una caja de texto donde se pueden visualizar las APDU intercambiadas
con la tarjeta inteligente en cualquiera de las operativas implementadas por
la aplicacin (cifrado, descifrado, generacin de pares de claves y recuperacin
de la clave pblica).
Pestaa Cifrado (Figura 6.7): permite aadir la curva pblica del destinatario
del criptograma, el mensaje en claro a cifrar y la etiqueta a utilizar de manera
opcional por la funcin MAC. El resultado del proceso de cifrado se muestra
en la caja de texto asociada al criptograma.
Pestaa Descifrado (Figura 6.8): permite incluir el criptograma a descifrar y
la etiqueta opcional para la funcin MAC, mostrando el mensaje original en
su caja de texto.
259
Pestaa Acerca (Figura 6.9): muestra informacin sobre la versin del programa JCOPECIES y sus autores.
Como parte de las distintas funciones implementadas, la aplicacin muestra de
forma grfica los errores debidos a las siguientes causas (Figura 6.10):
Falta de seleccin de un lector de tarjetas.
Seleccin de un lector donde no se ha introducido ninguna tarjeta.
Falta de seleccin de la curva de trabajo.
Utilizacin de una tarjeta que no tiene instalado el applet adecuado para los
modelos JCOP 41 y JCOP J3A.
Respecto a la longitud del mensaje a cifrar, se ha implementado una variante del
esquema de padding o relleno PKCS#5 [234] que tiene las siguientes caractersticas:
260
Al mensaje original se le aaden tantos bytes como sea necesario hasta que la
longitud en bytes del mensaje as modificado sea mltiplo de 8 (en las tarjetas
JCOP 41, ya que implementa el algoritmo TDES) o mltiplo de 16 (en las
tarjetas JCOP J3A, puesto que el applet para esas tarjetas utiliza AES).
El contenido de cada uno de los bytes adicionales es la codificacin en formato
hexadecimal del nmero de bytes que es necesario aadir.
A diferencia del esquema de relleno PKCS#5 habitual, si la longitud en bytes
del mensaje original en bytes ya es mltiplo de 8 (JCOP 41) o de 16 (JCOP
J3A), no se aade ningn byte adicional.
El motivo de incluir esa modificacin al esquema PKCS#5 se debe a las limitaciones en la longitud del mensaje original que impone la implementacin en Java
Card, y que por diseo del applet utiliza una nica APDU tanto para transmitir
el mensaje original a la tarjeta como para recuperar el criptograma. Proporcionalmente, en el mbito de la centena de bytes, la prdida de 8 16 bytes (segn la
tarjeta) para relleno es elevada, por lo que en esta implementacin se ha suprimido
la necesidad de aadir un nuevo bloque en tales casos.
261
Debido a ello, existira un caso en el que podra producirse prdida de informacin al descifrar un mensaje, en concreto cuando la longitud del mensaje original
es mltiplo de 8 (JCOP 41) o 16 (JCOP J3A), y el valor de los ltimos bytes
es precisamente la codificacin hexadecimal del nmero (es decir, los ltimos bytes del mensaje se ajustan a los esquemas . . . 01, . . . 0202, . . . 030303, etc.). Para
evitar este problema, el propio programa comprueba que el mensaje a cifrar no
da lugar a esta situacin, y en caso de que sea as muestra por pantalla el mensaje Proceso cancelado: el contenido del mensaje provocara prdida de
informacin.
6.8.
Ejemplos de utilizacin
262
263
Tal como se puede apreciar en todas las figuras incluidas en el resto del presente
captulo, el primer comando en todos los casos es el de seleccin del applet. Esta
seleccin no es necesaria para el correcto funcionamiento de la aplicacin, pero se
ha incluido a fin de demostrar que no es necesario completar la secuencia de todos
los comandos en una nica sesin.
6.8.1.
El ejemplo incluido en este apartado muestra el proceso cifrado de un mensaje realizado por el usuario U y el posterior descifrado por parte del usuario V
empleando tarjetas JCOP 41 y los complementos de NXP para Eclipse.
Antes de realizar las operaciones del cifrado y descifrado, es necesario que los
usuarios U y V obtengan un par de tarjetas que contengan la aplicacin Java Card
de cifrado y descifrado. Aunque en la instalacin del applet se genera un par de
claves para cada longitud permitida por el fabricante, como medida de precaucin
los usuarios pueden solicitar a la tarjeta la generacin de nuevos pares de claves en
cualquier momento, por ejemplo cuando reciban sus tarjetas. En el caso del producto
JCOP 41, las longitudes disponibles para curvas definidas sobre cuerpos 2 son 113,
131, 163 y 193 bits.
La Figura 6.11 muestra los comandos que tanto el usuario U como V necesitaran
enviar para la generacin de dichas claves, y que son:
Seleccin del applet: A00000000501.
Generacin de un par de claves de 113 bits: 0061010000.
Generacin de un par de claves de 131 bits: 0061020000.
Generacin de un par de claves de 163 bits: 0061030000.
Generacin de un par de claves de 193 bits: 0061040000.
La Figura 6.12 muestra todos los parmetros asociados a las claves del usuario U.
El ltimo comando enviado permite obtener la clave privada de U, por lo que dicho
comando slo est disponible en la versin de pruebas del applet, siendo eliminada
de la versin definitiva de la aplicacin que sera utilizada por usuarios reales. Por
su parte, la Figura 6.13 muestra de manera equivalente los parmetros asociados a
las claves del usuario V.
Tal y como se puede apreciar en las Figuras 6.12 y 6.13, todos los parmetros
coinciden a excepcin de las claves privadas y pblicas, ya que las tarjetas JCOP
264
41 utilizan una nica curva para cada una de las longitudes posibles, cambiando en
cada generacin aleatoria de claves nicamente los valores y para un usuario U.
Dada la curva 2 + = 3 + 2 + caracterizada por el conjunto de parmetros =(, (), , , , , ), los comandos empleados en la Figura 6.12 para la
obtencin de los parmetros de las claves asociadas al usuario U son los presentados
a continuacin:
Seleccin del applet: A00000000501.
Parmetro : 0062040100.
Parmetro : 0062040200.
Polinomio reductor (): 0062040300.
Punto de la curva que acta como el generador : 0062040400.
Cofactor : 0062040500.
Orden del punto : 0062040600.
265
266
267
268
que U deber enviar a V. Una vez recibido este criptograma, la secuencia de comandos que V necesita enviar a la tarjeta a fin de obtener el mensaje descifrado
estn incluidos en la Figura 6.15 y listados a continuacin:
Seleccin del applet: A00000000501.
Envo de la etiqueta para el clculo del cdigo MAC : 006600000454657374.
Envo del criptograma:
00680100670401BC9A5BE00DB6F5FDDEA249434FED1665A07492361
60C6223017368B704A497646EBD7D87249647B4F6C900E3978BB88788
7A40F0FFE036B8E9364F525E107ED6B3BD6E00D651E689F3F70F813
B30AC66FD7BECC931E850D19FE644F1886656C43E91FAE913.
Solicitud de descifrado del criptograma: 0069040000.
A la solicitud de descifrado, la tarjeta responde con la cadena hexadecimal
1112131415161718212223242526272831323334353637384142434445464748,
la cual coincide con el contenido del mensaje original que U deseaba enviar a V.
269
6.8.2.
270
Captulo 7
Resultados empricos
7.1.
Material utilizado
271
272
7. Resultados empricos
Mdulo hardware: P5CT072.
273
274
7. Resultados empricos
Puesto que las tarjetas JCOP 41 permiten utilizar tanto la interfaz con contactos
como la interfaz sin contactos, las pruebas de cifrado y descifrado realizadas con las
tarjeas JCOP 41 han sido duplicadas a fin de obtener resultados mediante ambas
interfaces. Tal como se puede apreciar en la Figura 7.3, que muestra la informacin proporcionada por una herramienta de Omnikey relativa a la tarjeta JCOP 41
utilizando el protocolo T=0 (con contactos) y T=CL (sin contactos), la frecuencia
utilizada en la interfaz con contactos es de 4.80 MHz, mientras si se utiliza la interfaz
sin contactos la frecuencia es 13.56 MHz.
Es importante sealar que, a pesar de conocer la frecuencia de la seal externa
de reloj proporcionada a la tarjeta, no es posible sin embargo conocer la frecuencia
interna a la que las tarjetas realmente estn trabajando. La nica informacin que
ha sido posible obtener es la asociada a las caractersticas tcnicas de los dos modelos
de tarjetas, la cual indica que la frecuencia interna de trabajo tiene un valor mximo
de 30 MHz para ambos modelos.
275
7.2.
Configuraciones de prueba
276
7. Resultados empricos
Longitud de la clave MAC : 32 bytes.
Configuracin M2:
Cuerpo sobre el que se define la curva elptica: 2 .
Configuracin P1:
Cuerpo sobre el que se define la curva elptica: .
277
Configuracin P3:
Cuerpo sobre el que se define la curva elptica: .
278
7. Resultados empricos
M1
M2
P1
P2
P3
sect113r1
sect113r1
secp112r1 secp128r1 secp128r1
sect131r1
sect131r1
secp128r1 secp160r1 secp160r1
sect163r1 c2pnb163v1 secp160r1
P-192
P-192
sect193r1
sect193r1
secp192k1
sect233r1
secp224r1
sect239k1
secp256k1
sect283r1
secp384r1
sect409r1
secp521r1
sect571r1
Cuadro 7.1: Curvas elpticas empleadas en las configuraciones
7.3.
279
Factor de expansin
Este apartado presenta las pruebas en las que se ha calculado el factor de expansin, interpretado en esta Tesis como la relacin entre la longitud del criptograma
(tripleta formado por la clave pblica temporal, el mensaje cifrado y el cdigo
MAC ) y la longitud del mensaje original, obteniendo de esta manera una medida
de la eficiencia en cuanto a ancho de banda de ECIES.
Debido a la naturaleza de ECIES, existen diversos elementos que contribuyen al
tamao final de los criptogramas. La siguiente lista describe dichos elementos:
1. El cuerpo finito , que determina la longitud en bytes de la representacin
binaria asociada a los elementos del cuerpo (y que conforman las coordenadas
de los puntos de la curva elptica).
2. La representacin binaria de la clave pblica temporal del emisor (ya sea comprimida o sin comprimir).
3. La funcin de cifrado simtrico (TDES, AES, etc.), su modo de utilizacin
(ECB, CBC, etc.) y el mtodo de relleno (PKCS#5, sin relleno, etc.).
4. La longitud del cdigo MAC generado.
En el caso particular de las implementaciones Java Card, puesto que la longitud mxima de un comando APDU es 255 bytes, el conjunto de longitudes de los
mensajes a cifrar utilizados en estas pruebas se ha seleccionado de manera que la respuesta a una peticin de cifrado o descifrado est contenida en una nica APDU de
respuesta. La utilizacin de peticiones con mensajes y criptogramas cuya respuesta
excediera 255 bytes tendra las siguientes consecuencias:
1. El tiempo de la operacin aumentara al ser necesaria la transmisin de APDU
adicionales por el canal de transmisin.
2. Dado que tanto los mensajes a cifrar como los criptogramas a descifrar deben
ser almacenados temporalmente en la memoria de las tarjetas inteligentes para
su procesado, y puesto que la cantidad de RAM en las tarjetas es muy limitada,
la utilizacin de mensajes de excesivo tamao provocara que los elementos
de tipo array que albergan los datos a cifrar o descifrar tuvieran que ser
almacenados en memoria EEPROM en lugar de en memoria RAM, con el
consiguiente deterioro del rendimiento general.
En todas las pruebas referidas a continuacin, el factor de expansin puede ser
calculado como
280
(7.1)
7. Resultados empricos
FE =
+
=
,
7.3.1.
Las pruebas llevadas a cabo con la configuracin M1 tienen las siguientes propiedades:
+ 16 + 32 =
+ 49,
donde el byte inicial es el prefijo que indica la compresin del punto que representa
la clave pblica temporal , /8 representa el nmero de bytes necesarios para
representar un elemento del cuerpo 2 , el relleno PKCS#5 aade 16 bytes durante
el proceso de cifrado simtrico y, por ltimo, el cdigo MAC ocupa 32 bytes.
El Cuadro 7.2 y la Figura 7.4 muestran el factor de expansin calculado a partir
de la ecuacin (7.1) al cifrar mensajes de distinta longitud (16, 32, 64, 128, 256,
512 y 1024 bytes) utilizando las diferentes longitudes de clave consideradas en la
configuracin M1.
Curva elptica
sect113r1
sect131r1
sect163r1
sect193r1
sect233r1
sect239k1
sect283r1
sect409r1
sect571r1
281
16
5
5.13
5.38
5.63
5.94
5.94
6.31
7.31
8.56
282
7. Resultados empricos
7.3.2.
+ 20 = 2
+ 21,
8
8
donde el byte inicial es el prefijo aadido para indicar que el punto de la curva que
representa la clave pblica temporal no est comprimido, el valor /8 aparece
duplicado puesto que al no utilizarse compresin de puntos es necesario incluir las
dos coordenadas del punto, y finalmente el cdigo MAC ocupa 20 bytes.
Curva
sect113r1
sect131r1
c2pnb163v1
sect193r1
16
4.19
4.44
4.94
5.44
32
2.59
2.72
2.97
3.22
144
1.35
1.38
1.44
1.49
160
1.32
1.34
1.39
1.44
7.3.3.
Las pruebas realizadas en este apartado tienen las siguientes caractersticas especficas:
283
La longitud de los mensajes en claro es, en todos los casos, mltiplo de 16 (lo
que genera un bloque de 16 bytes adicional al utilizar el algoritmo AES en
modo CBC con relleno PKCS#5).
Los puntos de la curva elptica se representan de forma comprimida.
El cdigo MAC tiene una longitud de 32 bytes.
Con ello, la diferencia 1 entre la longitud del criptograma y la longitud del
mensaje original cuando se utilizan curvas definidas sobre para cifrar mensajes
cuya longitud en bytes es mltiplo de 16 viene dada por la frmula
log
log
2
2
+ 16 + 32 =
+ 49,
1 = 1 +
8
8
donde el byte inicial es el prefijo aadido por el algoritmo de compresin de puntos
(y cuyos posibles valores son 0x02 0x03), (log2 )/8 representa el nmero de
bytes necesarios para representar un elemento del cuerpo , el relleno PKCS#5
aade 16 bytes durante el proceso de cifrado simtrico y, por ltimo, el cdigo MAC
ocupa 32 bytes.
El Cuadro 7.4 y la Figura 7.6 muestran el factor de expansin calculado mediante
la ecuacin (7.1) al cifrar mensajes de distinta longitud (16, 32, 64, 128, 256, 512 y
284
7. Resultados empricos
Curva elptica
secp112r1
secp128r1
secp160r1
secp192k1
secp224r1
secp256k1
secp384r1
secp521r1
16
4.94
5.06
5.31
5.56
5.81
6.06
7.06
8.19
7.3.4.
Las pruebas realizadas en este apartado tienen las siguientes caractersticas especficas:
285
Curva
secp128r1
secp160r1
P-192
7.3.5.
286
7. Resultados empricos
log
log
2
2
+ 32 = 2
+ 33,
=1+2
8
8
donde el byte inicial es el prefijo aadido para indicar que el punto de la curva
que representa la clave pblica temporal no est comprimido, el valor (log2 )/8
aparece duplicado puesto que representa la longitud en bytes de dos elementos del
cuerpo finito , y por ltimo el cdigo MAC ocupa 32 bytes.
El Cuadro 7.6 y la Figura 7.8 muestran el factor de expansin calculado mediante
la ecuacin (7.1) al cifrar mensajes de distinta longitud (16, 32, 48, 64, 80, 96, 112,
128, 144 y 160 bytes) utilizando la configuracin P3 con diferentes claves.
Curva
secp128r1
secp160r1
P-192
287
288
7.4.
7. Resultados empricos
Tiempo de cifrado
7.4.1.
289
16
32
48
64
80
96
112
128
144
160
176
113
28.82
27.91
27.52
27.80
27.64
27.71
27.62
27.53
27.55
28.14
28.34
131
35.61
36.02
36.34
36.71
36.62
36.50
36.42
36.40
36.63
36.21
36.26
finito 2 (bits)
239
283
106.52 131.56
106.24 133.21
106.12 132.31
105.46 132.04
105.44 132.62
105.32 131.77
105.52 132.34
105.42 131.73
105.30 130.62
105.33 129.72
105.54 129.96
409
220.78
220.52
219.85
220.66
221.53
220.30
220.43
222.71
225.65
224.45
225.53
571
370.40
370.97
369.78
368.64
368.81
370.62
370.36
368.68
369.73
368.42
368.50
7.4.2.
7.4.3.
290
7. Resultados empricos
16
32
48
64
80
96
112
128
144
160
176
finito 2 (bits)
163
193
53.56
77.99
55.49
78.13
55.49
78.28
54.27
78.17
54.31
77.97
53.94
77.66
53.36
77.12
53.18
77.93
53.59
79.32
53.69
79.24
53.71
79.50
291
16
32
48
64
80
96
112
128
144
160
176
finito 2 (bits)
163
193
332.71
367.64
333.82
368.88
342.34
384.44
349.65
384.58
349.94
384.98
351.54
386.45
360.50
401.76
367.11
401.81
367.57
403.46
368.74
403.70
384.40
418.98
Cuadro 7.9: Tiempo de cifrado con curvas sobre 2 en JCOP 41 e interfaz sin contactos (configuracin M2)
292
7. Resultados empricos
Figura 7.11: Tiempo de cifrado con curvas sobre 2 en JCOP 41 e interfaz sin contactos (configuracin M2)
16
32
48
64
80
96
112
128
144
160
176
finito 2 (bits)
163
193
407.35
446.56
423.00
461.89
441.77
481.21
457.30
496.31
472.47
511.39
487.81
526.91
506.62
545.77
522.03
561.14
537.20
576.33
552.31
591.55
571.23
610.54
Cuadro 7.10: Tiempo de cifrado con curvas sobre 2 en JCOP 41 e interfaz con
contactos (configuracin M2)
293
Figura 7.12: Tiempo de cifrado con curvas sobre 2 en JCOP 41 e interfaz con contactos (configuracin M2)
16
32
48
64
80
96
112
128
144
160
176
112
23.53
23.48
23.72
24.43
23.31
23.28
24.08
23.86
23.9
24.33
23.55
Longitud
128
160
23.94 39.01
23.94 39.28
23.88 40.03
24.64 40.12
24.51 40.05
24.39 39.99
24.57 40.20
24.51 41.49
24.65 40.64
24.83 40.45
24.12 39.77
521
226.02
225.91
225.44
226.55
226.63
225.67
226.64
227.53
228.13
229.36
228.08
294
7. Resultados empricos
7.4.4.
7.4.5.
16
32
48
64
80
96
112
128
144
160
295
(bits)
192
57.59
57.37
57.29
57.23
56.77
56.70
56.61
56.67
56.99
57.04
7. Resultados empricos
296
16
32
48
64
80
96
112
128
144
160
176
(bits)
192
587.76
589.71
597.61
603.90
605.29
606.50
620.53
621.59
623.32
623.73
636.95
Cuadro 7.13: Tiempo de cifrado con curvas sobre en JCOP J3A e interfaz sin
contactos (configuracin P2)
Figura 7.15: Tiempo de cifrado con curvas sobre en JCOP J3A e interfaz sin contactos (configuracin P2)
16
32
48
64
80
96
112
128
144
160
297
(bits)
192
57.96
58.32
58.12
58.21
57.91
58.13
58.06
58.03
58.11
58.31
7. Resultados empricos
298
16
32
48
64
80
96
112
128
144
160
(bits)
192
613.50
615.51
634.21
635.42
637.21
639.29
657.83
658.56
660.66
668.73
Cuadro 7.15: Tiempo de cifrado con curvas sobre en JCOP J3A e interfaz sin
contactos (configuracin P3)
Figura 7.17: Tiempo de cifrado con curvas sobre en JCOP J3A e interfaz sin contactos (configuracin P3)
7.5.
299
Tiempo de descifrado
7.5.1.
16
32
48
64
80
96
112
128
144
160
176
113
28.9
29.0
28.7
28.9
29.3
29.3
29.4
29.3
29.5
29.4
29.7
131
38.5
38.3
38.1
38.1
37.9
38.5
37.9
38.3
38.3
38.4
38.9
Longitud del
163 193
62.6 91.8
61.9 90.8
66.4 90.2
66.3 90.0
66.3 89.0
66.1 87.9
65.6 87.7
65.8 88.0
66.2 88.9
66.4 89.4
66.5 89.8
cuerpo
233
103.4
103.6
103.7
103.2
103.8
103.0
103.7
103.8
104.4
104.1
104.5
finito 2 (bits)
239
283
409
112.1 132.8 226.1
111.7 132.9 226.4
112.1 132.9 228.9
113.4 132.8 227.9
110.8 132.8 227.2
110.7 132.7 228.2
110.5 132.6 228.7
110.3 132.6 227.8
111.0 132.6 227.7
111.8 132.7 228.2
111.6 132.8 228.2
571
356.7
361.2
361.5
359.5
358.0
358.7
358.7
366.4
363.8
364.5
364.6
7.5.2.
300
7. Resultados empricos
7.5.3.
7.5.4.
16
32
48
64
80
96
112
128
144
160
176
301
finito 2 (bits)
163
193
52.64
76.79
52.85
76.98
52.95
77.74
52.71
77.65
52.97
77.56
52.81
77.82
53.04
77.36
52.97
77.16
53.03
76.71
53.35
76.84
53.93
76.76
7. Resultados empricos
302
16
32
48
64
80
96
112
128
144
160
176
finito 2 (bits)
163
193
212.04
222.08
213.33
223.20
222.49
232.61
229.37
239.37
229.50
239.59
230.89
241.15
239.70
249.49
246.80
256.74
247.46
257.38
248.60
258.62
258.53
268.34
Cuadro 7.18: Tiempo de descifrado con curvas sobre 2 en JCOP 41 e interfaz sin
contactos (configuracin M2)
Figura 7.20: Tiempo de descifrado con curvas sobre 2 en JCOP 41 e interfaz sin
contactos (configuracin M2)
16
32
48
64
80
96
112
128
144
160
176
303
finito 2 (bits)
163
193
236.18
245.19
251.47
260.57
270.15
279.39
285.54
294.63
300.84
310.06
316.22
325.14
335.59
344.07
350.69
359.56
366.12
374.88
381.45
390.04
400.50
408.76
Cuadro 7.19: Tiempo de descifrado con curvas sobre 2 en JCOP 41 e interfaz con
contactos (configuracin M2)
Figura 7.21: Tiempo de descifrado con curvas sobre 2 en JCOP 41 e interfaz con
contactos (configuracin M2)
7. Resultados empricos
304
16
32
48
64
80
96
112
128
144
160
176
112
24.99
25.79
25.73
25.80
25.82
25.66
25.69
25.97
25.66
25.95
25.93
Longitud
128
160
25.57 42.37
25.93 41.95
26.14 41.37
26.08 40.97
26.28 40.67
26.26 38.96
26.26 69.43
26.12 39.59
26.21 39.83
26.40 40.34
26.66 40.11
521
230.38
231.94
229.00
228.36
227.93
228.80
227.63
227.62
228.39
230.85
228.95
16
32
48
64
80
96
112
128
144
160
176
305
(bits)
192
56.08
56.36
56.16
56.34
56.49
55.56
56.19
57.34
56.87
56.91
57.22
7. Resultados empricos
306
16
32
48
64
80
96
112
128
144
160
176
(bits)
192
233.71
234.92
242.35
249.42
250.15
251.97
258.24
266.07
266.63
268.55
275.85
Cuadro 7.22: Tiempo de descifrado con curvas sobre en JCOP J3A e interfaz sin
contactos (configuracin P2)
Figura 7.24: Tiempo de descifrado con curvas sobre en JCOP J3A e interfaz sin
contactos (configuracin P2)
7.5.5.
307
16
32
48
64
80
96
112
128
144
160
(bits)
192
56.05
56.83
57.18
56.97
57.04
57.16
57.4
58.21
58.85
58.73
16
32
48
64
80
96
112
128
144
160
(bits)
192
258.30
260.24
273.56
280.97
282.28
284.02
296.59
304.60
305.52
307.45
Cuadro 7.24: Tiempo de descifrado con curvas sobre en JCOP J3A e interfaz sin
contactos (configuracin P3)
308
7. Resultados empricos
Figura 7.26: Tiempo de descifrado con curvas sobre en JCOP J3A e interfaz sin
contactos (configuracin P3)
7.6.
309
Rendimiento comparado
El objetivo de este apartado es presentar algunas comparaciones de especial inters, tomando como partida los datos obtenidos en las pruebas de cifrado y descifrado
expuestas en los apartados anteriores.
A fin de analizar el rendimiento general de las curvas sobre cuerpos primos y
binarios en una misma implementacin, la Figura 7.27 muestra el tiempo medio de
cifrado y descifrado de un mismo mensaje de 160 bytes de longitud para cada una
de las curvas incluidas en las configuraciones M1 y P1, aplicables exclusivamente a
la versin de ECIES para PC.
A continuacin se presenta una comparativa del tiempo medio de cifrado y descifrado (en las versiones PC y Java Card) de un mismo mensaje de 160 bytes de
longitud para cada una de las curvas incluidas en las configuraciones M2 (Figura 7.28), P2 (Figura 7.29) y P3 (Figura 7.30). Es importante tener en cuenta que,
dada la escala utilizada en las figuras, para poder mostrar en el mismo grfico los
resultados de las implementaciones en PC y Java Card, los tiempos de cifrado y
descifrado en PC se encuentran superpuestos en gran parte de su trazado.
La Figura 7.31 muestra la comparacin del tiempo de cifrado y descifrado empleado por las tarjetas JCOP 41 (con la configuracin M2) y JCOP J3A (con la
configuracin P2) al gestionar un mensaje en claro de 64 bytes. De manera similar,
la Figura 7.32 muestra la misma comparacin utilizando un mensaje de 160 bytes.
310
7. Resultados empricos
Figura 7.28: Comparacin del tiempo de ejecucin entre las versiones PC y Java Card
(configuracin M2)
Figura 7.29: Comparacin del tiempo de ejecucin entre las versiones PC y Java Card
(configuracin P2)
311
Figura 7.30: Comparacin del tiempo de ejecucin entre las versiones PC y Java Card
(configuracin P3)
312
7. Resultados empricos
Figura 7.31: Comparacin del tiempo de ejecucin en las tarjetas JCOP 41 (configuracin M2) y JCOP J3A (configuracin P2) al cifrar un mensaje de 64 bytes
Captulo 8
Conclusiones, aportaciones y trabajo
futuro
8.1.
Conclusiones
Tal como se ha comentado en diversos apartados, ECIES es un esquema de cifrado que dispone de mltiples opciones de implementacin. En la presente Tesis
Doctoral se ha estudiado en profundidad el protocolo de cifrado ECIES y se han
desarrollado varias aplicaciones (para PC y tarjetas JCOP 41 y JCOP J3A) con el
objetivo de realizar pruebas en estas tres plataformas hardware con cinco configuraciones diferentes (M1, M2, P1, P2 y P3).
Como resultado del estudio previo realizado y de las pruebas efectuadas es posible
presentar las conclusiones detalladas en los siguientes apartados, las cuales estn
agrupadas en funcin de los objetivos descritos en la Introduccin.
313
314
8.1.1.
A continuacin se detallan las conclusiones a las que ha sido posible llegar respecto a la consideracin del esquema ECIES como estndar:
1. El esquema de cifrado y descifrado ECIES se encuentra especificado en los
estndares ANSI X9.63 [16], IEEE 1363a [109], ISO/IEC 18033-2 [136] y SECG
SEC 1 [254]. Las caractersticas concretas de cada una de dichas versiones estn
descritas en 4.4 y 4.5.
Aunque las implementaciones de los cuatro estndares mencionados se basan,
en ltima instancia, en el esquema de cifrado DHIES [9, 10], existe una gran
variedad en lo relativo a las funciones HASH, KA, KDF, ENC y MAC permitidas en cada estndar, as como en las caractersticas particulares (p. ej.,
el uso de parmetros opcionales, la interpretacin de algunos elementos, etc.)
incluidas en esas versiones de ECIES.
2. A partir de las caractersticas particulares de cada estndar, hemos construido
11 configuraciones genricas (es decir, independientes de las funciones HASH,
KA, KDF, ENC y MAC especficas utilizadas), de manera que cada una de
ellas sea vlida al menos en un estndar. Dichas configuraciones se encuentran
descritas en 4.7.
3. De la revisin de las 11 configuraciones y de su aplicabilidad a cada estndar, se
puede afirmar que existen dos configuraciones (C01 y C02) compatibles con las
ltimas versiones de los cuatro estndares mencionados. Dichas configuraciones
tienen como elemento caracterstico la utilizacin de la funcin XOR como
algoritmo de cifrado simtrico.
Como consecuencia de la existencia de esas configuraciones y de al menos una
funcin especfica permitida de forma comn para cada una de las funciones
HASH, KA, KDF, ENC y MAC, se puede concluir que ECIES es un esquema
de cifrado que, a pesar de sus muchas opciones, permite ser implementado de
manera compatible con los cuatro estndares analizados.
8.1.2.
8.1. Conclusiones
315
8.1.3.
316
8.1.4.
8.1. Conclusiones
317
Curva
Long. 2
sect113r1
113
sect131r1
131
sect163r1
163
sect193r1
193
sect233r1
233
sect239k1
239
sect283r1
383
sect409r1
409
sect571r1
571
Ratio 1
1.00
1.16
1.44
1.71
2.06
2.11
3.39
3.62
5.05
Cifrado
28.34
36.26
59.67
82.53
102.31
105.54
129.96
225.53
368.50
Ratio 2
1.00
1.28
2.11
2.91
3.61
3.72
4.59
7.96
13.00
Descifrado Ratio 3
29.7
1.00
38.9
1.31
66.5
2.24
89.8
3.02
104.5
3.52
111.6
3.75
132.8
4.47
228.2
7.68
364.6
12.28
318
Ratio 1
1.00
1.14
1.43
1.71
2.00
2.29
3.43
4.65
Cifrado Ratio 2
23.55
1.00
24.12
1.02
39.77
1.69
53.96
2.29
69.88
2.97
79.33
3.37
143.07
6.07
228.08
9.68
Descifrado
25.93
26.66
40.11
56.07
74.42
85.41
149.38
228.95
Ratio 3
1.00
1.03
1.55
2.16
2.87
3.29
5.76
8.83
8.1.5.
Las conclusiones que se pueden extraer del proceso de desarrollo de los applets
Java Card que implementan ECIES, denominados JCOP-M2, JCOP-P2 y JCOP-P3,
son las siguientes:
1. El soporte actual a la criptografa de curva elptica por parte de los grandes
fabricantes de tarjetas inteligentes (Gemalto, Oberthur, G&D, etc.) es todava
escaso.
2. En el mercado existe una amplia gama de tarjetas JCOP (desarrolladas inicialmente por IBM, y en la actualidad por NXP) compatibles con distintas
versiones de Java Card. De entre las tarjetas JCOP que implementan funcionalidades de la ECC, fueron seleccionados para su uso en esta Tesis los modelos
JCOP 41 y JCOP J3A, debido principalmente a su disponibilidad. Para dichas tarjetas se han desarrollado tres versiones del applet ECIES, denominadas
JCOP-M2, JCOP-P2 y JCOP-P3, tal como se menciona en 6.6.
3. Para poder realizar comparaciones ms fiables, sera deseable que los fabricantes de tarjetas inteligentes desarrollaran modelos que permitieran utilizar
indistintamente curvas sobre cuerpos finitos tanto primos como binarios. En
el caso de los modelos utilizados en la Tesis, las tarjetas JCOP 41 nicamente
implementan curvas definidas sobre cuerpos binarios, mientras que las tarjetas
JCOP J3A slo incluyen curvas construidas sobre cuerpos binarios.
4. Los fabricantes deben esforzarse en el futuro en implementar todas las curvas
sobre cuerpos finitos incluidas en Java Card 3.0, especialmente aquellas de
longitud 224, 256 y 384 bits definidas sobre cuerpos binarios. Estas longitudes sern paulatinamente ms importantes segn aumenten los requisitos de
seguridad de las aplicaciones con el paso del tiempo.
8.1. Conclusiones
319
5. A pesar de estar definida en las API de Java Card, la funcin HMAC no est
incluida en las tarjetas JCOP probadas. Aunque el desarrollo de la funcin
HMAC apropiada no ha sido complejo, el rendimiento global mejorara si
dicha funcin fuera ejecutada a travs de la llamada estndar al API Java
Card.
6. Igualmente sera deseable que el API Java Card aadiera en el futuro la funcin
KDF2, puesto que de hecho actualmente dicha API no incluye ninguna funcin
KDF.
7. De manera equivalente sera recomendable que las tarjetas comerciales incorporaran en el futuro prximo las modalidades con relleno del algoritmo AES
definidas en Java Card 3.0, lo que evitara la codificacin de sistemas alternativos de relleno por parte de las aplicaciones que se comunican con la tarjeta
inteligente.
8.1.6.
La siguiente lista recoge las conclusiones obtenidas gracias a las pruebas realizadas en tarjetas JCOP 41 con la configuracin M2 y en tarjetas JCOP J3A con las
configuraciones P2 y P3.
1. Los tiempos de cifrado y descifrado incluyen tanto el tiempo de transmisin
(del lector a la tarjeta con la APDU de tipo comando, y de la tarjeta al lector
con la APDU de tipo respuesta) como el tiempo de procesamiento realizado
por la tarjeta, por lo que es necesario tener en cuenta este hecho al realizar
comparaciones.
2. Las tarjetas JCOP 41, que permiten el envo de comandos mediante dos interfaces (con contactos y sin contactos) presentan un rendimiento diferente
en funcin de la interfaz empleada. Aunque la falta de detalles tcnicos sobre
las tarjetas slo permiten realizar suposiciones sobre este hecho, el motivo ms
probable podra ser la diferente frecuencia de la seal externa de reloj utilizada
en ambas interfaces (4.8 MHz frente a 13.56 MHz), lo que genera que la utilizacin de la interfaz sin contactos ofrezca mejores resultados en las pruebas
de cifrado y descifrado.
3. Adems de las diferencias respecto al tiempo de cifrado y descifrado, la utilizacin de distintas interfaces produce comportamientos marcadamente distintos
en la misma tarjeta. Si se observan los tiempos de cifrado para las tarjetas
JCOP 41 en ambos casos (Figuras 7.11 y 7.12), se puede comprobar que en
la interfaz con contactos el comportamiento es prcticamente lineal, mientras
que en la interfaz sin contactos el aumento del tiempo de cifrado se produce
por escalones.
320
Ratio 1
1.00
1.16
1.44
1.70
Cifrado Ratio 2
341.52
1.00
358.64
1.05
384.40
1.13
418.98
1.23
Descifrado
244.41
249.53
258.53
267.34
Ratio 3
1.00
1.02
1.06
1.09
Cuadro 8.3: Crecimiento del tiempo de cifrado y descifrado en JCOP 41 e interfaz sin
contactos (configuracin M2)
8.1. Conclusiones
Curva
Long. 2
sect113r1
113
sect131r1
131
c2pnb163v1
163
sect193r1
193
321
Ratio 1
1.00
1.16
1.44
1.70
Cifrado Ratio 2
528.36
1.00
548.35
1.04
571.23
1.08
640.54
1.21
Descifrado
387.98
392.21
400.50
408.76
Ratio 3
1.00
1.01
1.03
1.05
Cuadro 8.4: Crecimiento del tiempo de cifrado y descifrado en JCOP 41 e interfaz con
contactos (configuracin M2)
Curva
Long.
secp128r1
128
secp160r1
160
P-192
192
Ratio 1
1.00
1.25
1.5
Cifrado
529.22
561.74
636.95
Ratio 2
1.00
1.06
1.20
Descifrado Ratio 3
256.57
1.00
261.46
1.02
275.85
1.08
Cuadro 8.5: Crecimiento del tiempo de cifrado y descifrado en JCOP J3A e interfaz
sin contactos (configuracin P2)
utilizar directamente la CPU del PC (aunque el rendimiento global del criptoprocesador de la tarjeta inteligente sea peor que el de la CPU). Es decir, el
criptoprocesador de las tarjetas JCOP, a pesar de las limitaciones tecnolgicas propias de arquitecturas de 8 bits, comparativamente est ms optimizado
para la aritmtica de puntos de la curva y de elementos del cuerpo finito que
la CPU del PC.
6. El tiempo de descifrado en las tarjetas Java Card es sensiblemente inferior al
tiempo de cifrado. Esto podra deberse, a falta de ms datos sobre el funcionamiento de las tarjetas y sus coprocesadores, a que en la operacin de cifrado se
ejecuta un paso adicional relacionado con la aritmtica de puntos de la curva
y elementos del cuerpo finito (la generacin pseudoaleatoria del par de claves
temporal) que no es necesario durante el descifrado.
7. Mientras que el tiempo de descifrado para longitudes de clave equivalentes
es similar en las tarjetas JCOP 41 y JCOP J3A cuando ambas utilizan la
interfaz sin contactos, en cambio el tiempo de cifrado es claramente superior
en las tarjetas JCOP J3A en condiciones similares. Puesto que los tiempos de
Curva
Long.
secp128r1
128
secp160r1
160
P-192
192
Ratio 1
1.00
1.25
1.5
Cifrado
560.78
591.69
668.73
Ratio 2
1.00
1.06
1.19
Descifrado Ratio 3
287.92
1.00
293.33
1.02
307.45
1.07
Cuadro 8.6: Crecimiento del tiempo de cifrado y descifrado en JCOP J3A e interfaz
sin contactos (configuracin P3)
322
8.1. Conclusiones
323
Curva
sect113r1
sect131r1
c2pnb163v1
sect193r1
Cif. 16
296.74
314.65
332.71
367.64
Cif. 160
331.82
350.70
368.74
403.70
Ratio 1
1.12
1.11
1.11
1.10
Descif. 16
197.74
203.12
212.04
222.08
Descif. 160
234.46
239.58
248.60
258.62
Ratio 2
1.20
1.18
1.17
1.16
Curva
Cuadro 8.7: Incremento relativo del tiempo de ejecucin en JCOP 41 e interfaz sin
contactos (configuracin M2)
sect113r1
sect131r1
c2pnb163v1
sect193r1
Cif. 16
363.51
384.52
407.35
446.56
Cif. 160
509.34
529.41
552.31
591.55
Ratio 1
1.40
1.38
1.35
1.32
Descif. 16
223.78
228.21
236.18
245.19
Descif. 160
368.92
373.29
381.45
390.04
Ratio 2
1.65
1.64
1.62
1.59
Curva
Cuadro 8.8: Incremento relativo del tiempo de ejecucin en JCOP 41 e interfaz con
contactos (configuracin M2)
secp128r1
secp160r1
P-192
Cif. 16
481.55
518.24
587.76
Cif. 160
522.50
554.08
623.73
Ratio 1
1.08
1.07
1.06
Des. 16
213.84
219.32
233.71
Des. 160
249.00
254.06
268.55
Ratio 2
1.16
1.16
1.15
Cuadro 8.9: Incremento relativo del tiempo de ejecucin en JCOP J3A e interfaz sin
contactos (configuracin P2)
Curva
324
secp128r1
secp160r1
P-192
Cif. 16
512.54
543.31
613.50
Cif. 160
560.78
591.69
668.73
Ratio 1
1.09
1.09
1.09
Descif. 16
237.17
243.94
253.16
Descif. 160
287.92
293.33
307.46
Ratio 2
1.21
1.20
1.21
Cuadro 8.10: Incremento relativo del tiempo de ejecucin en JCOP J3A e interfaz sin
contactos (configuracin P3)
8.1.7.
8.1.8.
Una vez analizada la seguridad de ECIES en 4.9, las conclusiones que se pueden
obtener sobre la resistencia a ataques de las distintas versiones de ECIES son las
siguientes:
8.2. Aportaciones
325
1. Las configuraciones C01 y C02 compatibles con los cuatro estndares son susceptibles de sufrir ataques debido a la utilizacin de la funcin XOR como
algoritmo de cifrado simtrico.
2. De las tres soluciones al problema de la maleabilidad descritas en 4.9.1.2,
la nica que es posible implementar manteniendo la compatibilidad con los
cuatro estndares consiste en fijar la longitud de los mensajes a cifrar, tal
como se ha comentado en 8.1.1.
3. Puesto que con la nica solucin compatible con todos los estndares la funcionalidad de ECIES queda seriamente limitada, se hace necesario seleccionar
otra configuracin como punto de partida para cualquier implementacin segura de ECIES. Dado que exceptuando C01 y C02 no existen ms configuraciones
compatibles con los cuatro estndares, las candidatas lgicas son aquellas configuraciones recogidas en los tres estndares ms recientes, que resultan ser
C05 y C06. Al igual que sucedi en 4.8, es posible definir a partir de las
configuraciones C05 y C06 mltiples versiones compatibles con dichas configuraciones, y que se diferencien en la funcin HASH, la funcin MAC, el uso
de argumentos opcionales en la funcin de autenticacin o una combinacin
de esos tres elementos.
4. El Algoritmo 4.17 define una versin del esquema de cifrado, denominada
ECIES-3, que constituye una de las posibles variantes compatibles con las configuraciones C05 y C06 definidas por IEEE 1363a, ISO/IEC 18033-2 y SECG
SEC 1. ECIES-3 incluye los elementos necesarios para resistir cualquiera de los
ataques contra ECIES conocidos y descritos en 4.9, utilizando el algoritmo
de cifrado AES en modo CBC con relleno PKCS#5 y claves de 256 bytes,
la funcin resumen SHA-256, la funcin de derivacin de claves KDF2 y la
funcin de autenticacin HMAC-SHA-256.
8.2.
Aportaciones
La presente Tesis doctoral incluye la especificacin y desarrollo de una implementacin software de ECIES, para lo cual se ha creado una versin utilizando Java
SE para entornos PC, y otra versin (con tres variantes) para tarjetas Java Card.
Hasta donde el autor de esta Tesis conoce, se trata de la primera implementacin
del protocolo ECIES en ambas plataformas, permitiendo adems en la versin para
PC la seleccin de manera dinmica de la configuracin especfica a utilizar por el
usuario.
Como era predecible, durante el desarrollo el autor ha encontrado diversas dificultades y obstculos. En primer lugar, los estndares que incluyen ECIES como
algoritmo de cifrado presentan un nmero de opciones muy elevado, estando en
326
327
8.3.
Trabajo futuro
328
329
Notacin
0x
A2 ()
Mensaje cifrado
Criptograma
Curva elptica
()
EK
Clave de cifrado
()
Cofactor de la curva
332
Notacin
MK
Clave MAC
Punto en el infinito
P2 ()
Funcin techo
Glosario
3FF
3GPP
ABS
ACCA
ACE
ACPA
AES
AMS
ANSI
APDU
API
ASCII
ASN.1
ATM
ATR
Answer to Reset
AWT
BCD
Binary-Coded Decimal
BER
BSI
334
Glosario
CAP
Converted Applet
CBC
Cipher-Block Chaining
CCA
CER
CLA
Class
CLK
Clock
CMOS
CMS
COA
Ciphertext-Only Attack
CPA
CPU
CRL
CRT
CTR
Counter
DEM
DER
DES
DHAES
DH
Diffie-Hellman
DHC
DHIES
DHP
Diffie-Hellman Problem
DLAES
DLP
DOI
DSA
ECC
ECDH
ECDLP
Glosario
335
ECDSA
ECIES
ECMQV
EEPROM
EPROM
ETSI
FRAM
GDLP
GND
Ground
GNU
GPL
GSM
HMAC
IAIK
Institut fr Angewandte Informationsverarbeitung und Kommunikationstechnologie (Institute for Applied Information Processing and Communications)
ICC
ID
Identifier
IEC
IEEE
IETF
IFP
INS
Instruction
I/O
Input/Output
KA
Key Agreement
KEM
J2SE
J2EE
JAAS
336
Glosario
JCA
JCE
JCP
JCRE
JCRMI
JCVM
JDK
JIT
Just in Time
JLS
JRE
JSE
JSSE
JSR
JTC
JVM
KDF
KEM
KPA
LNCS
MAC
ME
Mobile Equipment
MIME
MSC
NESSIE
NFC
NGICC
NIST
NSA
OCF
OpenCard Framework
Glosario
337
OCSP
OID
Object Identifier
P1
Parameter 1
P2
Parameter 2
P3
Parameter 3
PC
Personal Computer
PC
Policarbonato
PC/SC
PDA
PET
Polyethylene Terephthalate
PGP
PKCS
PSEC
PVC
Polyvinyl Chloride
RAM
RFC
RFID
RFU
RMI
RNG
ROM
RSA
Algoritmo Rivest-Shamir-Adleman
RST
Reset
SAT
SCQL
SECG
SHA
SIM
STK
338
Glosario
STS
Station-To-Station
SW1
Status Word 1
SW2
Status Word 2
TDE
TDES
Triple DES
TDEA
TLS
TLV
Tag-Length-Value
TSP
Time-Stamp Protocol
UICC
UMTS
USAT
USB
USIM
UTF-8
WAP
WIM
WSC
Referencias
[1] 3RD GENERATION PARTNERSHIP PROJECT (3GPP). Specification of
the Subscriber Identity Module - Mobile Equipment (SIM-ME) interface. Ver.
8.14.0 (Release 99). TS 11.11. 2007.
http://www.3gpp.org/ftp/specs/html-info/1111.htm
[2] 3RD GENERATION PARTNERSHIP PROJECT (3GPP). Specification 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 (Release 6). TS 31.102. 2008.
http://www.3gpp.org/ftp/specs/html-info/31102.htm
[5] 3RD GENERATION PARTNERSHIP PROJECT (3GPP). Universal Subscriber 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). Specification 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). Specification 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
Referencias
341
[17] AMERICAN NATIONAL STANDARDS INSTITUTE (ANSI). Catalog of finantial industry american national standards, draft standards for trial use,
technical reports and technical guides. Marzo 2010.
http://www.x9.org/standards/catalog/X9_Standards_Catalog.pdf
[18] AOKI K. et al. Camellia: A 128-bit block cipher suitable for multiple platforms - Design and analysis. Lecture Notes in Computer Science, 2001, vol.
2012, pp. 39-56. ISBN 3-540-42069-X.
http://dx.doi.org/10.1007/3-540-44983-3_4
[19] ATENIESE, G. et al. A practical and provably secure coalition-resistant group
signature scheme . Lecture Notes in Computer Science. 2000, vol. 1880, pp.
255270. ISBN 978-3-540-67907-3.
http://dx.doi.org/10.1007/3-540-44598-6_16
[20] ATENIESE, G. y DE MEDEIROS, B. Efficient group signatures without
trapdoors. Lecture Notes in Computer Science. 2003, vol. 2894, pp. 246268.
ISBN 978-3-540-20592-0.
http://dx.doi.org/10.1007/978-3-540-40061-5_15
[21] APPLE INC. How to identify a micro-SIM. Pgina web.
http://support.apple.com/kb/HT4192
[22] ATKIN, A. O. L. The number of points on an elliptic curve modulo a prime.
Correos enviados al Number Theory Mailing List, 1988-1992.
[23] ATKIN, A. O. L. y MORAIN, F. Elliptic curves and primality proving.
Mathematics of Computation. Julio 1993, vol. 61, num. 203, pp. 2968. ISSN
0025-5718.
http://dx.doi.org/10.1090/S0025-5718-1993-1199989-X
[24] BACH, E. y SHALLIT, J. Algorithmic number theory. Cambridge (Massachusetts): MIT Press, 1996. ISBN 0-262-02405-5.
[25] BARRN VIDALES, J. Diseo e implementacin de un esquema de cifrado
hbrido basado en DHIES. Director: Debrup Chakraborty. Centro de Investigacin y de Estudios Avanzados del Instituto Politcnico Nacional, Mjico,
2008.
http://www.cs.cinvestav.mx/Estudiantes/TesisGraduados/2008/
tesisJesusBarron.pdf
[26] BELLARE, M. y ROGAWAY, P. Minimizing the use of random oracles in
authenticated encryption schemes. Lecture Notes in Computer Science. 1997,
vol. 1334, pp. 116. ISBN 978-3-540-63696-0.
342
Referencias
http://dx.doi.org/10.1007/BFb0028457
[27] BELLARE, M. et al. Relations among notions of security for public-key encryption schemes. Lecture Notes in Computer Science. 1998, vol. 1462, pp.
549570. ISSN 3-540-64892-5.
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. 4773. ISSN 0324-6000.
http://www.pp.bme.hu/ee/2002_1/pdf/ee2002_1_04.pdf
[29] BLAKE, I.; SEROUSSI, G. y SMART, N. Elliptic curves in cryptography.
Cambridge: Cambridge University Press, 1999. ISBN 0-521-65374-6.
[30] BLAKE, I.; SEROUSSI, G. y SMART, N. Advances in Elliptic Curve Cryptography. Cambridge: Cambridge University Press, 2005. ISBN 0-521-60415-X.
[31] BONEH, D. Twenty years of attacks on the RSA cryptosystem. Notices of the
American Mathematical Society. Febrero 1999, vol. 46, num. 2, pp. 203213.
ISSN 0002-9920.
http://www.ams.org/notices/199902/boneh.pdf
[32] BOUNCE CASTLE. The legion of the Bouncy Castle. Pgina web.
http://www.bouncycastle.org
[33] BRAINPOOL. ECC Brainpool. Pgina web.
http://www.ecc-brainpool.org
[34] BRAINPOOL. ECC Brainpool standard curves and curve generation. Ver. 1.0.
2005.
www.ecc-brainpool.org/download/Domain-parameters.pdf
[35] BRESSOUD, D. M. Factorization and primality testing. Nueva York: SpringerVerlag, 1989. ISBN 0-387-97040-1.
[36] BUCHMANN, J. A. Introduction to cryptography. 2a ed. Nueva York: Springer,
2004. ISBN 0-387-21156-X.
[37] BUNDESAMT FR SICHERHEIT IN DER INFORMATIONSTECHNIK
(BSI). Elliptic Curve Cryptography. Ver. 1.11. TR-03111. 2009.
https://www.bsi.bund.de/cae/servlet/contentblob/471398/
publicationFile/30615/BSI-TR-03111_pdf.pdf
Referencias
343
344
Referencias
[46] CERTICOM CORP. Digital signatures on a smartcard. Inventores: S. A. Vanstone, A. J. Menezes. Fecha de solicitud: 2001-08-29. Estados Unidos, patente
de invencin, 6.704.870 B2. 2004-03-09.
http://www.google.com/patents/about?id=rZ0SAAAAEBAJ&dq=6704870
[47] CERTICOM CORP. Accelerated finite field operations on an elliptic curve. Inventores: S. A. Vanstone, R. Mullin, A. Antipa, R. Gallant. Fecha de solicitud:
2000-10-02. Estados Unidos, patente de invencin, 6.782.100. 2004-08-24.
http://www.google.com/patents/about?id=XGESAAAAEBAJ&dq=6782100
[48] CHEN, Z. Java Card technology for smart cards: Architecture and programmers guide. Boston: Addison-Wesley, 2000. ISBN 0-201-70329-7.
[49] COHEN, H. A course in computational algebraic number theory. Berln:
Springer-Verlag, 1993. ISBN 3-540-55640-0.
[50] COHEN, H. et al. Handbook of elliptic and hyperelliptic curve cryptography.
Florida: Chapman & Hall/CRC, 2006. ISBN 1-58488-518-1.
[51] CONNELL, I. Elliptic Curve Handbook. Indito, 1999.
http://www.math.mcgill.ca/connell/
[52] CONSEJO SUPERIOR DE INVESTIGACIONES CIENTFICAS. Procedimiento y dispositivo de encriptacin mediante un criptosistema tipo RSA. Inventores: L. Hernndez, J. Muoz, A. Queiruga. Fecha de solicitud: 2003-02-14.
Espaa, patente de invencin, 2.217.959. 2006-02-01.
http://dx.doi.org/10261/4968
[53] COPPERSMITH, D. et al. Low-exponent RSA with related messages. Lecture Notes in Computer Science. 1996, vol. 1070, pp. 19. ISBN 978-3-54061186-8.
http://dx.doi.org/10.1007/3-540-68339-9_1
[54] CORON, J. S. y MAY, A. Deterministic polynomial-time equivalence of computing the RSA secret key and factoring. Journal of Cryptology. Enero 2007,
vol. 20, num. 1, pp. 3950. ISSN 0933-2790.
http://dx.doi.org/10.1007/s00145-006-0433-6
[55] CRAMER, R. y SHOUP, V. Design and analysis of practical public-key encryption schemes secure against adaptive chosen ciphertext attack. SIAM
Journal on Computing. Diciembre 2003, vol. 33, num. 1, pp. 167226. ISSN
0097-5397.
http://dx.doi.org/10.1137/S0097539702403773
Referencias
345
346
Referencias
Referencias
347
348
Referencias
http://dx.doi.org/10261/21232
[85] GAYOSO MARTNEZ, V.; HERNNDEZ ENCINAS, L. y SNCHEZ VILA, C. A Java implementation of the Elliptic Curve Integrated Encryption
Scheme. En: Proceedings of the 2010 International Conference on Security
& Management - SAM10, vol.n II, pp. 495501. Las Vegas, 2010. ISBN: 160132-162-7.
[86] GAYOSO MARTNEZ, V.; HERNNDEZ ENCINAS, L. y SNCHEZ VILA, C. A comparison of the standardized versions of ECIES. En: Proceedings
of the 6th International Conference on Information Assurance and Security
(IAS 2010)m pp. 14. Atlanta, 2010. ISBN: 978-1-4244-7408-0.
http://dx.doi.org/10.1109/ISIAS.2010.5604194
[87] GAYOSO MARTNEZ, V.; HERNNDEZ ENCINAS, L. y SNCHEZ VILA, C. Security and practical considerations when implementing the Elliptic
Curve Integrated Encryption Scheme. Enviado a: Journal of Systems and
Software. 2010. ISSN 0164-1212.
[88] GAYOSO MARTNEZ, V.; HERNNDEZ ENCINAS, L. y SNCHEZ VILA, C. Performance evaluation of the Elliptic Curve Integrated Encryption
Scheme implemented in PC and Java Card. Enviado a: Computers & Mathematics with Applications. 2010. ISSN 0898-1221.
[89] GAYOSO MARTNEZ, V.; HERNNDEZ ENCINAS, L. y SNCHEZ VILA, C. Java Card implementation of the Elliptic Curve Integrated Encryption
Scheme using prime and binary finite fields. Enviado a: International Journal
of Information Security. 2010. ISSN 1615-5262.
[90] GAYOSO MARTNEZ, V.; HERNNDEZ ENCINAS, L. y SNCHEZ VILA, C. A survey of the elliptic curve integrated encryption scheme. Journal
of Computer Science and Engineering. Agosto 2010, vol. 2, num. 2, pp. 713.
ISSN 2043-9091.
http://sites.google.com/site/jcseuk/volumes/V2-I2-P7-13.pdf
[91] GAUDRY, P.; HESS, F. y SMART, N. Constructive and destructive facets
of Weil descent on elliptic curves. Journal of Cryptology. Marzo 2002, vol. 15,
num. 1, pp. 1946. ISSN 0933-2790.
http://dx.doi.org/10.1007/s00145-001-0011-x
[92] GEISELMANN, W. y STEINWANDT, R. Power attacks on a side-channel
resistant elliptic curve implementation. Information Processing Letters. Julio
2004, vol. 91, num. 1, pp. 2932. ISSN 0020-0190.
http://dx.doi.org/10.1016/j.ipl.2003.12.009
Referencias
349
350
Referencias
[103] HESS, E. et al. Information leakage attacks against smart card implementations of cryptographic algorithms and countermeasures - A survey. En:
Proceedings of the EUROSMART Security Conference, pp. 5564. Marsella,
2000.
http://www.torsten-schuetze.de/reports/leakage.pdf
[104] HEWLETT-PACKARD COMPANY. Compression and decompression of
elliptic curve data points. Inventor: G. Seroussi. Fecha de solicitud: 1998-08-04.
Estados Unidos, patente de invencin, 6.252.960. 2001-06-26.
http://www.google.com/patents/about?id=mcIIAAAAEBAJ&dq=6252960
[105] HID GLOBAL. HID Products OMNIKEY 5321 CL USB Reader. Pgina web.
http://www.hidglobal.com/prod_detail.php?prod_id=331
[106] HOOK, D. Beginning cryptography with Java. Indianapolis: Wiley Publishing,
2005. ISBN 0-7645-9633-0.
[107] HORTON, I. Beginning Java 2. Birmingham (Reino Unido): Wrox Press, 1999.
ISBN 1-86100-223-8.
[108] INSTITUTE OF ELECTRICAL AND ELECTRONICS ENGINEERS
(IEEE). Standard specifications for public key cryptography. IEEE Std 1363.
2000.
http://grouper.ieee.org/groups/1363/P1363/index.html
[109] INSTITUTE OF ELECTRICAL AND ELECTRONICS ENGINEERS
(IEEE). Standard specifications for public key cryptography - Amendment 1:
Additional techniques. IEEE Std 1363a. 2004.
http://grouper.ieee.org/groups/1363/P1363a/index.html
[110] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION (ISO).
Documentation Bibliographic references Content, form and structure. 2a
ed. ISO 690. 1987.
http://www.iso.org/iso/iso_catalogue/catalogue_ics/catalogue_
detail_ics.htm?csnumber=4888
[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
352
Referencias
Referencias
353
354
Referencias
Referencias
355
356
Referencias
Referencias
357
358
Referencias
[174] MILLER, V. S. Use of elliptic curves in cryptography. Lecture Notes in Computer Science. 1986, vol. 218, pp. 417426. ISBN 3-540-16463-4.
http://dx.doi.org/10.1007/3-540-39799-X_31
[175] MILNE, J. S. Elliptic curves. Charleston (Carolina del Sur): BookSurge, 2006.
ISBN 1-4196-5257-5.
[176] MINISTERIO DEL INTERIOR. DNI electrnico. Pgina web.
http://www.dnielectronico.es/oficina_prensa/noticias/noticia12.
html
[177] MINISTERIO DEL INTERIOR. Pasaporte electrnico (pasaporte-e). Pgina
web.
http://www.mir.es/SGACAVT/pasaport/concepto.html
[178] MOHAMMED, E.; EMARAH, A. E. y EL-SHENNAWY, K. Elliptic curve
cryptosystems on smart cards. En: Proceedings of the 35th IEEE International Carnahan Conference on Security Technology (ICCST 2001), pp 213222.
Londres, 2001. ISBN 0-7803-6636-0 .
http://dx.doi.org/10.1109/.2001.962835
[179] MOLLIN, R. A. An introduction to cryptography. 2a ed. Boca Ratn (Florida):
Chapman & Hall/CRC, 2007. ISBN 1-58488-618-8.
[180] Mordell, L. J. On the rational solutions of the indeterminate equations of the
third and fourth degrees. Proceedings of the Cambridge Philosophical Society.
1922, vol. 21, pp. 179192. ISSN 0305-0041.
[181] MULDER, E. et al. Differential power and electromagnetic attacks on a FPGA implementation of elliptic curve cryptosystems. Computers and Electrical
Engineering. Septiembre 2007, vol. 33, num. 56, pp. 367382. ISSN 0045-7906.
http://dx.doi.org/10.1016/j.compeleceng.2007.05.009
[182] NAGELL, T. Sur les proprits arithmtiques des cubiques planes du premier
genre. Acta Mathematica. 1929, vol. 52, pp. 93126. ISSN 0001-5962.
http://dx.doi.org/10.1007/BF02592681
[183] NATIONAL INSTITUTE OF STANDARDS AND TECHNOLOGY (NIST).
Secure hash standard. FIPS 180-3. 2008.
http://csrc.nist.gov/publications/fips/fips180-3/fips180-3_
final.pdf
Referencias
359
360
Referencias
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. Massey, J. K. Omura. Fecha de solicitud: 1982-09-14. Estados Unidos, patente de
invencin, 4.567.600. 1986-01-28.
http://www.google.com/patents/about?id=i-M5AAAAEBAJ&dq=4567600
[206] OMNET ASSOCIATES. Computational method and apparatus for finite field
arithmetic. Inventores: J. K. Omura, J. L. Massey. Fecha de solicitud: 198209-14. Estados Unidos, patente de invencin, 4.587.627. 1986-05-06.
http://www.google.com/patents/about?id=lNsyAAAAEBAJ&dq=4587627
[207] OMNISEC A.G. Public key cryptographic system using elliptic curves over
rings. Inventor: U. Maurer. Fecha de solicitud: 1991-03-22. Estados Unidos,
patente de invencin, 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 finite field multiplication. Inventores: I. M. Onyszchuk, R. C. Mullin, S. A. Vanstone. Fecha de solicitud: 1985-05-30. Estados
Unidos, patente de invencin, 4.745.568. 1988-05-17.
http://www.google.com/patents/about?id=OJc2AAAAEBAJ&dq=4745568
[209] ORACLE CORP. BigInteger (Java Platform SE 6). Pgina web.
http://download.oracle.com/javase/6/docs/api/java/math/
BigInteger.html
[210] ORACLE CORP. Java Card Technology. Pgina web.
http://www.oracle.com/technetwork/java/javacard/overview/index.
html
362
Referencias
[211] ORACLE CORP. Java smart card I/O API. Pgina web.
http://jcp.org/en/jsr/detail?id=268
[212] ORACLE CORP. Java technology. Pgina web.
http://java.com/en/about
[213] ORACLE CORP. OpenJDK. Pgina web.
http://openjdk.java.net
[214] ORACLE CORP. Oracle completes acquisition of Sun. Pgina web.
http://www.oracle.com/us/corporate/press/044428
[215] ORTEGA JUANCAS, S. Algunas aplicaciones de las curvas elpticas a la criptografa. Director: Juan Gabriel Tena Ayuso. Secretariado de Publicaciones e
Intercambio Cientfico de la Universidad de Valladolid, 1997.
http://dialnet.unirioja.es/servlet/tesis?codigo=11638
[216] PC/SC WORKGROUP. The PC/SC workgroup. Pgina web.
http://www.pcscworkgroup.com
[217] PREZ ORTIZ, J. A. Diccionario urgente de estilo cientfico del espaol. Indito, 1999.
http://www.dlsi.ua.es/~japerez/pub/pdf/duece1999.pdf
[218] PIETILINEN, H. Elliptic curve cryptography on smart cards. Director: Eljas Soisalon-Soininen. Faculty of Information Technology, Helsinki University
of Technology, Finlandia, 2000.
http://henna.laurikari.net/Dippa/di.pdf
[219] POHLIG, S. C. y HELLMAN, M. E. An improved algorithm for computing
logarithms over () and its cryptographic significance. IEEE Transactions
on Information Theory. Enero 1978, vol. 24, num. 1, pp. 644654. ISSN 00189448.
http://dx.doi.org/10.1109/TIT.1978.1055817
[220] POLLARD, J. M. Theorems on factorization and primality testing. Mathematical Proceedings of the Cambridge Philosophical Society. Noviembre 1974,
vol. 76, num. 3, pp. 521528. ISSN 0305-0041.
http://dx.doi.org/10.1017/S0305004100049252
[221] POLLARD, J. M. A Monte Carlo method for factorization. BIT Numerical
Mathematics. Septiembre 1975, vol. 15, num. 3, pp. 331334. ISSN 0006-3835.
http://dx.doi.org/10.1007/BF01933667
Referencias
363
364
Referencias
[232] RSA LABORATORIES. RSA cryptography standard. Ver. 2.1. PKCS #1.
2002.
ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-1/pkcs-1v2-1.pdf
[233] RSA LABORATORIES. Overview of Elliptic Curve Cryptosystems. RSA Laboratories Technical Note. 1997.
http://www.rsa.com/rsalabs/node.asp?id=2013
[234] RSA LABORATORIES. Password-based cryptography standard. Ver. 2.1.
PKCS#5. 2006.
ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-5v2/pkcs5v2_1.pdf
[235] SATOH, T. y ARAKI, K. Fermat quotients and the polynomial time discrete log algorithm for anomalous elliptic curves. Commentarii Mathematici
Universitatis Sancti Pauli. Enero 1998, vol. 47, num. 1, pp. 8192.
http://mathpc-satoh.math.titech.ac.jp/en/A1998.html
[236] SATOH, T. The canonical lift of an ordinary elliptic curve over a finite field
and its point counting. Journal of the Ramanujan Mathematical Society. 2000,
vol. 15, num. 4, pp. 247270.
http://mathpc-satoh.math.titech.ac.jp/en/A2000.html
[237] SCHNEIER, B. Applied cryptography. 2a ed. Nueva York: John Willey & Sons,
1996. ISBN 0-471-11709-9.
[238] SCHOOF, R. Elliptic curves over finite fields and the computation of square
roots mod . Mathematics of Computation. Abril 1985, vol. 44, num. 170, pp.
483494.
http://dx.doi.org/10.1090/S0025-5718-1985-0777280-6
[239] SCHOOF, R. Counting points on elliptic curves over finite fields. Journal de
Thorie de Nombres de Bordeaux. 1995, vol. 7, pp. 219254.
http://www.mat.uniroma2.it/~schoof/ctg.pdf
[240] SEMAEV, I. A. Evaluation of discrete logarithms in a group of -torsion
points of an elliptic curve in characteristic . Mathematics of Computation.
Enero 1998, vol. 67, num. 221, pp. 353356.
http://dx.doi.org/10.1090/S0025-5718-98-00887-4
[241] SHANKS, D. Class number, a theory of factorization, and genera. En: Proceedings of 1969 Number Theory Institute. Stony Brook (Nueva York), 1969.
pp 415440. ISBN 0-82181-420-6.
http://www.ams.org/mathscinet-getitem?mr=47:4932
Referencias
365
366
Referencias
Referencias
367
368
Referencias