Protocolocrip PDF

INSTITUTO POLITECNICO NACIONAL
CENTRO DE INNOVACIÓN Y DESARROLLO

TECNOLÓGICO EN CÓMPUTO
DEPARTAMENTO DE POSGRADO
PROTOCOLO CRIPTOGRÁFICO PARA LA AUTENTICACIÓN

DE NODOS BASADO EN EL ESQUEMA PKI PARA
REDES INALÁMBRICAS DE SENSORES
Tesis que para obtener el grado de

Maestro en Tecnología de Cómputo presenta el
Ing. Miguel Alfredo Acedo Arias
Directores:
M. en C. María Aurora Molina Vilchis
Dr. Ramón Silva Ortigoza
México, D.F., Agosto de 2009.

Resumen
La seguridad en las Wireless Sensor Networks (WSN) es una de las razones que
están limitando su desarrollo e implementación práctica. Si bien los Mobile Transmission
Elements (MOTE), núcleo de las WSN, han avanzado en capacidades de procesamiento
y consumo de energía; las redes inalámbricas sin infraestructura que los soportan, hasta
hoy, sólo han atendido aspectos básicos sobre los protocolos de ruteo requeridos, pero no
así los protocolos de seguridad necesarios en el umbral entre las capas física y de enlace de
datos. Los ataques a los que pueden estar sujetas estas redes no son diferentes a los que se
presentan en redes como Internet, no obstante los objetivos que persiguen los adversarios
pudieran causar mucho más daño directo, dadas las aplicaciones que tienen las WSN
sobre todo en el aspecto militar, automatización del hogar o domótica, salud y ecología.
Es por ello que este trabajo tiene como objetivo el modelar, simular e implementar un
protocolo de autenticación de nodos basado en el esquema de infraestructura de llave
pública o PKI para redes WSN experimentales con topología de estrella.
Abstract
Security in Wireless Sensor Networks (WSN) is one of the main factors for it’s under
development on practical applications. Even thought, the Mobile Transmission Elements
(MOTE), main element in this kind of nets, have developed better processing capacities
and reduced their energy consumptions, but there are only basic schemes for security on
the WSN. It is required to WSN to have security schemes on the physical and linking
layer, related to the OSI model. Attacks on WSN are not different to those on any
network, but they could be more harmful because of the kind of duties that they handle.
This is the main reason to research on security for WSN, focusing on node authentication.
The main objective on this work is developing, modeling and simulate an authentication
protocol for experimental WSN based on Public Key Infraestructure in a star topology.
Dedicatoria
A Dios, y por tanto a mi fe. De dónde vengo y con quién voy.
A mi esposa e hijas, por su contribución a mi felicidad. Por el orgullo que me dan y

por el amor que me profesan.
A mi madre, como fuente inquebrantable de esfuerzo y tesón, el verdadero origen de

mis logros.
A mi familia, por su infinita paciencia y tolerancia en los largos tiempos de abstrac-

ción vertidos en las actividades de estos trabajos.
A los amigos, siempre prestos en la palabra o en el acto de apoyo. Todos ellos reivin-
dican y dan sentido a la palabra.
A los olvidados, todos aquellos que con su interacción diaria facilitan las labores y
los éxitos de los que intentamos ver lejos. Estamos sin duda sentados en hombros de
gigantes.
Agradecimientos
A mi directora de tesis, la M. en C. María Aurora Molina Vilchis, por su entendimien-

to y comprensión en la forma de guiarme en esta aventura del conocimiento. Por su con-
fianza, apoyo, enseñanzas y bondad al compartir su experiencia y el rigor que requieren
este tipo de actividades. En resumen, por ser un gran modelo a seguir.
A mi segundo director de tesis, el Dr. Ramón Silva Ortigoza, por compartir su visión
de la ciencia y la tecnología. Por sus posiciones contrastadas y el respeto a toda prueba
ofrecido siempre generosamente.
A mis revisores, la Dra. Magdalena Marciano Melchor, el Dr. Edgar Alfredo Portilla
Flores, el Dr. Víctor Manuel Silva García y el M. en C. Juan Carlos Herrera Lozada por
el tiempo dedicado a la lectura, análisis y aportaciones a este trabajo.
Al Dr. Miguel Lindig Bos, por su apoyo y confianza como amigo y jefe.
Al CIDETEC-IPN, por la oportunidad de atrevernos a soñar y contribuir a la reali-

zación de los sueños.
A Javier Apud Gómez, tú no sólo mereces mi dedicatoria general.
A Nanoretec, S.A. de C.V., por la facilidades brindadas al proporcionar sus equipos

para el desarrollo de los trabajos de esta tesis.
A todos mis amigos, compañeros y alguna vez subordinados. A los seis que decidieron
emprender esta aventura conjuntamente.
A mis maestros, por mostrarnos día a día el compromiso que requiere la digna labor
de enseñar, mi agradecimiento y reconocimiento por ello.
Índice general
1. Introducción 1
1.1. Origen y evolución . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2. Wireless Sensor Networks . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3. Estado del arte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.4. Objetivo del trabajo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.5. Metodología . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.6. Recursos empleados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.7. Organización del trabajo . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2. Autenticación en la WSN 19
2.1. Arquitectura de la WSN . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.2. Redes de un solo salto versus redes de múltiples saltos . . . . . . . . . . . 20
2.3. Movilidad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.4. Seguridad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.4.1. Metas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.4.2. Modelo de seguridad por capas en la WSN . . . . . . . . . . . . . 25
2.4.3. Autenticación de nodos . . . . . . . . . . . . . . . . . . . . . . . . 27
2.4.4. Primitivas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.4.5. Métodos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.4.6. Evaluación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.5. Infraestructura de clave pública (PKI) . . . . . . . . . . . . . . . . . . . 29
2.5.1. El problema de la factorización de números grandes . . . . . . . . 30
2.5.2. Cálculo de logaritmos discretos en un campo finito grande. . . . . 31
2.5.3. La desaparición de la criptografía simétrica . . . . . . . . . . . . . 32
2.5.4. Estructura de PKI . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.5.5. Consideraciones sobre PKI . . . . . . . . . . . . . . . . . . . . . . 33
2.5.6. Esquemas criptográficos de clave pública . . . . . . . . . . . . . . 34
2.5.7. Métodos de generación de claves . . . . . . . . . . . . . . . . . . . 35
2.5.8. Problemas de distribución de claves . . . . . . . . . . . . . . . . . 37
2.5.9. Ataques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
2.5.10. Requisitos para la implementación en los MOTE . . . . . . . . . . 41
ix
x ÍNDICE GENERAL
3. Protocolo de autenticación de nodos 43

3.1. Requisitos de diseño . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.2. Entidades participantes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
3.3. Necesidades de autenticación . . . . . . . . . . . . . . . . . . . . . . . . . 49
3.4. Diseño del protocolo de acuerdo de la llave . . . . . . . . . . . . . . . . 52
3.4.1. Protocolo Diffie-Hellman de acuerdo de la llave . . . . . . . . . . 52
3.4.2. Protocolo Matsumoto, Takashima, e Imai (MTI) de acuerdo de la
llave . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
3.5. Generación de las llaves pública y privada . . . . . . . . . . . . . . . . . 56
3.6. Algoritmo de encripción RSA . . . . . . . . . . . . . . . . . . . . . . . . 57
3.7. Definiciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
3.8. Algoritmo RSA de encripción con llave pública . . . . . . . . . . . . . . . 58
3.9. Prueba de que la decripción funciona . . . . . . . . . . . . . . . . . . . . 58
3.10. Uso del RSA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
3.11. Seguridad de RSA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
3.11.1. Correcta elección del tamaño del módulo. . . . . . . . . . . . . . . 59
3.11.2. Selección de los números primos. . . . . . . . . . . . . . . . . . . 59
3.11.3. Exponentes pequeños de encripción. . . . . . . . . . . . . . . . . . 60
3.12. Estándar Avanzado de Encripción (AES) . . . . . . . . . . . . . . . . . . 60
3.13. Algoritmo AES de encripción . . . . . . . . . . . . . . . . . . . . . . . . 62
3.14. Algoritmo AES de expansión de la llave . . . . . . . . . . . . . . . . . . . 62
3.15. Algoritmo AES de decripción . . . . . . . . . . . . . . . . . . . . . . . . 63
3.16. Certificados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
3.16.1. Formato del certificado . . . . . . . . . . . . . . . . . . . . . . . . 64
3.16.2. Extensiones en el certificado . . . . . . . . . . . . . . . . . . . . . 65
3.16.3. Indicadores críticos . . . . . . . . . . . . . . . . . . . . . . . . . . 65
3.16.4. Tipos de extensiones . . . . . . . . . . . . . . . . . . . . . . . . . 65
3.17. Diseño de la CA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
4. Implementación del protocolo propuesto 69

4.1. Protocolo de establecimiento de la llave secreta . . . . . . . . . . . . . . 69
4.1.1. Algoritmo para  . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
4.1.2. Algoritmo para  . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
4.1.3. Algoritmo de comprobación de llaves secretas . . . . . . . . . . . 71
4.2. Protocolo para la generación de llaves públicas/privadas ( ) . . . . . . 71
4.2.1. Algoritmo para generar las llaves ( ) . . . . . . . . . . . . . . . 72
4.3. Definiciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
4.4. Generación y administración de certificados . . . . . . . . . . . . . . . . 73
4.5. Programación de los dispositivos . . . . . . . . . . . . . . . . . . . . . . . 75
4.6. Ejecución del protocolo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
ÍNDICE GENERAL xi
5. Conclusiones 83
5.1. Recomendaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
5.2. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
5.3. Trabajos futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
Referencias 85
A. Matemático 93
A.1. Número primo fuerte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
A.2. Algoritmo de Gordon para la generación de primos fuertes [1] . . . . . . 93
A.2.1. Justificación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
A.3. Algoritmo extendido de Euclides [1] . . . . . . . . . . . . . . . . . . . . . 94
A.4. Teorema de Fermat [1] . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
A.5. Exponenciación modular [1] . . . . . . . . . . . . . . . . . . . . . . . . . 95
A.5.1. Documentos de soporte . . . . . . . . . . . . . . . . . . . . . . . . 96
B. Estándar avanzado de encripción (AES) 97

B.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
B.2. Sistemas de encripción con llaves simétricas . . . . . . . . . . . . . . . . 97
B.2.1. Elementos de un encriptador de bloques . . . . . . . . . . . . . . 98
B.3. Vulnerabilidad de un criptosistema . . . . . . . . . . . . . . . . . . . . . 100
B.4. Algoritmo Rijndael . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
B.4.1. El estado y la llave . . . . . . . . . . . . . . . . . . . . . . . . . . 101
B.4.2. Las transformaciones en un ciclo . . . . . . . . . . . . . . . . . . . 101
B.4.3. Key Schedule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
B.4.4. El encriptador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
B.4.5. Documentos de soporte . . . . . . . . . . . . . . . . . . . . . . . . 112
C. Características de los MOTE 113
D. Instalación de la red 115

D.1. Instalación física de la red . . . . . . . . . . . . . . . . . . . . . . . . . . 116
D.2. Configuración de la red . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
D.2.1. Preparación inicial del ambiente operativo . . . . . . . . . . . . . 116
D.2.2. Pruebas de transmisión . . . . . . . . . . . . . . . . . . . . . . . . 118
D.2.3. Programación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
E. Base de datos de los nodos 125

E.1. Estructura de la base de datos relacional . . . . . . . . . . . . . . . . . . 125
E.2. Primera Forma Normal (1FN) . . . . . . . . . . . . . . . . . . . . . . . . 125
E.2.1. Ejemplo 1: Dominios y valores . . . . . . . . . . . . . . . . . . . . 126
E.2.2. Ejemplo 2: Grupos repetidos a través de columnas . . . . . . . . . 126
E.2.3. Ejemplo 3: Repetición de grupos dentro de columnas . . . . . . . 127
E.2.4. Un diseño conforme con 1FN . . . . . . . . . . . . . . . . . . . . 128
xii ÍNDICE GENERAL
E.3. Segunda Forma Normal (2FN) . . . . . . . . . . . . . . . . . . . . . . . . 128

E.3.1. Dependencia funcional . . . . . . . . . . . . . . . . . . . . . . . . 128
E.4. Tercera Forma Normal (3FN) . . . . . . . . . . . . . . . . . . . . . . . . 129
E.4.1. Documentos de soporte . . . . . . . . . . . . . . . . . . . . . . . . 134
F. Programas 135
F.1. MTI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
F.1.1. Algoritmo de acuerdo de la llave MTI1 . . . . . . . . . . . . . . . 135
F.2. RSA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
F.2.1. Código de encripción/decripción . . . . . . . . . . . . . . . . . . . 138
F.2.2. Firma HASH basada en SHA-1 . . . . . . . . . . . . . . . . . . . 144
F.3. Forma . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
F.3.1. Código base de la forma . . . . . . . . . . . . . . . . . . . . . . . 145
1
Se han eliminado todos los acentos en el código presentado, aunque en Visual Basic son soportados,
la herramienta de edición usada para el trabajo tiene limitantes con los caracteres a desplegar.
Índice de figuras
1.1. Rango de alcance de diversas señales de radiofrecuencia. . . . . . . . . . 4

1.2. Topologías de red. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3. Una red WSN con un nodo como compuerta habilitando el acceso a
clientes remotos vía Internet. . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1. Tres tipos de sumideros en una red de sensores de un solo salto. . . . . . 20

2.2. Redes multisalto: Cuando la comunicación directa es imposible, debido a
la distancia y/o obstáculos, la comunicación multisalto es una forma de
resolver el problema. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.3. Múltiples fuentes y/o múltiples sumideros. Note cómo, en el escenario
de la mitad baja, ambos sumideros y fuentes activas son utilizados para
enrutar datos a ambos extremos de la red. . . . . . . . . . . . . . . . . . 22
2.4. Área de nodos sensores detectando un evento (elefante) que se mueve a
través de la red. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.5. Pila del protocolo en las WSN y las defensas de su seguridad. . . . . . . 25
2.6. Objetivos del protocolo de autenticación. . . . . . . . . . . . . . . . . . . 28
2.7. Proceso transaccional con PKI. . . . . . . . . . . . . . . . . . . . . . . . 34
2.8. Llaves públicas y privadas. . . . . . . . . . . . . . . . . . . . . . . . . . . 35
2.9. Envío de mensajes con PKI. . . . . . . . . . . . . . . . . . . . . . . . . . 36
2.10. Encripción asimétrica. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
2.11. El número de distribuciones de llaves secretas está directamente relaciona-
do a los patrones de comunicación de los nodos. . . . . . . . . . . . . . . 39
2.12. Un esquema centralizado de distribución de llaves. . . . . . . . . . . . . . 40
2.13. Características generales de algunos MOTE. . . . . . . . . . . . . . . . . 41
3.1. Arquitectura de un MOTE. . . . . . . . . . . . . . . . . . . . . . . . . . 43

3.2. Arquitectura del CC2430/31. . . . . . . . . . . . . . . . . . . . . . . . . 44
3.3. Comparación de tecnologías inalámbricas. . . . . . . . . . . . . . . . . . 46
3.4. Trama de datos ZigBee. . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
3.5. Trama de reconocimiento ZigBee. . . . . . . . . . . . . . . . . . . . . . . 47
3.6. Trama de comando MAC ZigBee. . . . . . . . . . . . . . . . . . . . . . . 47
3.7. Trama de comando MAC ZigBee (continuación). . . . . . . . . . . . . . . 48
3.8. Diagrama básico del sistema de autenticación. . . . . . . . . . . . . . . . 49
3.9. Frecuencias asignadas al protocolo ZigBee. . . . . . . . . . . . . . . . . . 50
xiii
xiv ÍNDICE DE FIGURAS
3.10. Gráfica de la relación señal-ruido para diferentes protocolos inalámbricos. 51

3.11. Aplicación del FDMA y DS-CDMA en el protocolo ZigBee. . . . . . . . . 51
3.12. Mensajes del protocolo de acuerdo de la llave MTI. . . . . . . . . . . . . 55
3.13. Escenario de ataque de “hombre en el medio” para el protocolo MTI. . . 56
3.14. Versiones oficiales de AES. . . . . . . . . . . . . . . . . . . . . . . . . . . 61
3.15. Diagrama de AES. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
3.16. Formato general del certificado X.509. . . . . . . . . . . . . . . . . . . . 66
4.1. Diagrama general de la distribución de las fases y responsabilidades en el

protocolo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
4.2. Forma para el cálculo de valores válidos para el acuerdo de la llave MTI. 72
4.3. Valores validados obtenidos mediante el uso de la forma MTI. . . . . . . 73
4.4. Certificado X.509 propuesto. . . . . . . . . . . . . . . . . . . . . . . . . . 74
4.5. Visualización de la aleatoriedad de un archivo sin encripción. . . . . . . . 75
4.6. Visualización de la aleatoriedad de un archivo encriptado. . . . . . . . . . 76
4.7. Programa para el uso de RSA, SHA1 y DH. . . . . . . . . . . . . . . . . 77
4.8. Generación de llaves. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
4.9. Proceso de encripción. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
4.10. Proceso de decripción. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
4.11. Grabación exitosa en memoria del dispositivo. . . . . . . . . . . . . . . . 81
4.12. Recuperación del dato de la memoria. . . . . . . . . . . . . . . . . . . . . 82
A.1. Ejemplo del algoritmo extendido de Euclides. . . . . . . . . . . . . . . . 95
B.1. Ejemplo: Estado con  = 6 y  = 4 . . . . . . . . . . . . . . . . . . . 101

B.2. Valores de ciclos  en función de  y   . . . . . . . . . . . . . . . . 102
B.3. Ejemplo de S-Box  = 8 . . . . . . . . . . . . . . . . . . . . . . . . . . 103
B.4. Proceso general de SubBytes. . . . . . . . . . . . . . . . . . . . . . . . . 104
B.5. Valores de 1  2  3 en función de   . . . . . . . . . . . . . . . . . . . . 104
B.6. Ejemplo de ShiftRow  = 4 . . . . . . . . . . . . . . . . . . . . . . . . 105
B.7. Proceso general de ShiftRows. . . . . . . . . . . . . . . . . . . . . . . . . 105
B.8. Proceso general de MixColumns. . . . . . . . . . . . . . . . . . . . . . . . 106
B.9. Proceso general de AddRoundKey. . . . . . . . . . . . . . . . . . . . . . 107
B.10.Ejemplo:  = 6  = 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
B.11.Diagrama general de los procesos de AES. . . . . . . . . . . . . . . . . . 108
B.12.Complejidad en el criptoanálisis de Rijndael. . . . . . . . . . . . . . . . . 109
C.1. Comparación de características básicas. . . . . . . . . . . . . . . . . . . . 113

C.2. Datos de la gráfica Kiviat. . . . . . . . . . . . . . . . . . . . . . . . . . . 114
C.3. Características generales de MOTE. . . . . . . . . . . . . . . . . . . . . . 114
D.1. Tarjeta de demostración CC2430DB. . . . . . . . . . . . . . . . . . . . . 116

D.2. Instalación física de la red. . . . . . . . . . . . . . . . . . . . . . . . . . . 116
D.3. Selección de las instrucciones. . . . . . . . . . . . . . . . . . . . . . . . . 119
D.4. Petición de la dirección IEEE. . . . . . . . . . . . . . . . . . . . . . . . . 120
ÍNDICE DE FIGURAS xv
D.5. Respuesta de la petición IEEE. . . . . . . . . . . . . . . . . . . . . . . . 121

D.6. Respuesta de la solicitud de la información general del dispositivo. . . . . 122
D.7. Configuración de los parámetros de comunicación serial. . . . . . . . . . . 122
D.8. Transmisión por el puerto serial. . . . . . . . . . . . . . . . . . . . . . . . 123
D.9. Transmisión de datos en el código binario. . . . . . . . . . . . . . . . . . 123
D.10.Respuesta a la solicitud de la dirección extendida. . . . . . . . . . . . . . 124
D.11.Aplicación de VB que solicita la versión del Firmware del dispositivo. . . 124
E.1. Base de datos incial. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126

E.2. Múltiples teléfonos para un cliente. . . . . . . . . . . . . . . . . . . . . . 126
E.3. Expansión de la tabla mediante la definición de más campos. . . . . . . . 127
E.4. Ampliación del tamaño del campo para albergar múltiples teléfonos. . . . 127
E.5. Primera tabla 1FN. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
E.6. Segunda tabla 1FN. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
E.7. Tabla incial para la 2FN. . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
E.8. Separación de los datos tabla 1, 2FN. . . . . . . . . . . . . . . . . . . . . 130
E.9. Separación de los datos tabla 2, 2FN. . . . . . . . . . . . . . . . . . . . . 130
E.10.Tabla inicial 3FN. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
E.11.Separación de los datos tabla 1, 3FN. . . . . . . . . . . . . . . . . . . . . 131
E.12.Separación de los datos tabla 2, 3FN. . . . . . . . . . . . . . . . . . . . . 131
E.13.Estructura de tablas propuesta para el proyecto. . . . . . . . . . . . . . . 132
E.14.Catálogo de algoritmos para firmar el certificado. . . . . . . . . . . . . . 132
E.15.Catálogo de tipos de dispositivos. . . . . . . . . . . . . . . . . . . . . . . 132
E.16.Datos para los certificados. . . . . . . . . . . . . . . . . . . . . . . . . . . 133
E.17.Datos para la Estación Base. . . . . . . . . . . . . . . . . . . . . . . . . . 133
E.18.Datos para los MOTE. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
E.19.Vista de los datos del certificado. . . . . . . . . . . . . . . . . . . . . . . 134
F.1. Forma para el acuerdo de la llave MTI. . . . . . . . . . . . . . . . . . . . 135

F.2. Forma base para RSA, SHA1 y DH. . . . . . . . . . . . . . . . . . . . . . 145
Capítulo 1
Introducción
Si bien la revolución de la computación estaba basada en la digitalización de la infor-

mación para que ésta pudiera ser más fácilmente manipulada, la revolución inalámbrica
que viene [1], se fundamenta en proporcionar información digital sobre todo aquello
disponible, en cualquier lugar y a costos reducidos.
Los beneficios del mundo de la computación como la innovación en microcircuitos,
ciclos cortos de desarrollo y bajo costo, han sido extendidos a las comunicaciones inalám-
bricas. Como resultado, cada vez más objetos se están conectando a todo tipo de redes,
desde televisores y automóviles hasta maquinaria industrial o granjas completas [2]. Con
cerca de 10 mil millones de procesadores vendidos en el 2007 como parte de computa-
doras o dispositivos domésticos, la mayoría de estos dispositivos tienen la posibilidad de
“pensar”, pero aún no pueden “hablar”, es decir, pueden realizar tareas específicas pero
no comunicarse, sin embargo, esto está cambiando rápidamente. De acuerdo con el Dr.
David Clark, investigador del Massachusetts Institute of Technology (MIT) y uno de los
creadores del concepto Internet, dentro de 15 ó 20 años la Internet albergará alrededor
de 1 billón de dispositivos; la mayor parte con tecnología inalámbrica de algún tipo.
Lo cierto es que de esa cantidad, sólo el 10 % estará relacionado con el concepto actual
de computadora, el restante 90 % se referirá a pequeños dispositivos independientes o
incorporados a objetos de uso cotidiano que establecerán el puente entre el mundo físico
y el digital.
En un sentido amplio, la revolución que viene, proveerá de sentidos a lo que alguna
vez solamente tuvo cerebro. Este será el papel que jugarán los sensores inalámbricos
cooperando en redes de corto alcance con topologías dinámicas.
1.1. Origen y evolución

Describir la importancia de una tecnología reciente es complicado debido a que éstas
generalmente no evolucionan como los especialistas esperan o la gente cree [3]. Sin em-
bargo es factible hablar de sus orígenes y de las características que les dan este carácter
de promesa. Las primeras aplicaciones del concepto de Redes Inalámbricas de Sensores
(Wireless Sensor Networks) fueron de carácter militar. El proyecto Sound Survelliance
1
2 CAPÍTULO 1. INTRODUCCIÓN
System (SOSUS) [4] iniciado en 1950, provee a la armada americana la capacidad de

detección de submarinos en aguas profundas y a gran distancia. Fue eficiente durante la
guerra fría, y adicionalmente fue una de las primeras aplicaciones de sensores ultrasóni-
cos colocados en boyas que se comunicaban de manera inalámbrica. Probada la eficiencia
del concepto, la Defense Advanced Research Projects Agency (DARPA) en 1978 auspi-
cia en la universidad Carnegie-Mellon, de Pennsylvania, el proyecto Distributed Sensor
Nets Workshop [5], el cual consistía en el establecimiento de una red de sensores expe-
rimental. En 1998 éste evoluciona al proyecto SensIT, generando al menos 29 proyectos
de investigación en 25 diferentes universidades e institutos, todos ellos encaminados a
resolver las limitantes o ampliar las capacidades del concepto de redes de sensores. Den-
tro de estos trabajos, podemos mencionar al proyecto PicoRadio de la Universidad de
California en Berkeley, que estaba encaminado al desarrollo de una red sin infraestruc-
tura1 de mesoescala2 auto contenida, con sensores y nodos monitores de bajo costo y
bajo consumo de energía. En la misma universidad, se genera el proyecto SmartDust
consistente de Elementos de Transmisión Móviles conocidos como (MOTE) basados en
Sistemas MicroElectroMecánicos (MEMS) con transmisión óptica. En Berkeley se inicia-
ron adicionalmente los desarrollos en sistemas operativos para este tipo de dispositivos,
bases de datos y protocolos 3 que permitían el envío de información entre ellos, pero que
al mismo tiempo pudieran irse a estado inactivo o "dormido"tanto como fuera necesario
para ahorrar en el gasto de energía de las baterías [9]. En el MIT, se inicia el proyecto
Adaptive Multi-domain Power aware Sensors (AMPS), enfocado en el desarrollo de
un sistema completo de WSN con énfasis en el bajo consumo de energía de operación
y posteriormente al proyecto Low Energy Adaptive Clustering Hierarchy (LEACH) que
dio origen a un protocolo de propósito específico para este tipo de tecnologías.
De acuerdo con [5], provenientes del grupo de trabajo de la Internet Engineering
Task Force (IETF) se derivan dos proyectos, Terminodes y Mobile Ad hoc Networks
(MANET), ambas redes sin infraestructura con sensores de bajo consumo de energía
y que principalmente se enfocaron en la resolución de problemas de ruteo al manejar
nodos móviles.
Características básicas como el bajo consumo de energía y de ancho de banda, la
posibilidad de tener un largo alcance a través de la cooperación de los nodos y la alta
tolerancia en la latencia de los mensajes hace ideales a las WSN para ser aplicadas en
un sin número de campos. Las WSN pueden ser usadas en ambientes tan hostiles, quizá
los más demandantes serían los océanos y el espacio profundo, pero también son usadas
para controlar cultivos, en zonas sísmicas, bosques, procesos industriales, etc., por lo que
no sería raro encontrarlas incluso en nuestra vestimenta.
Toda esta revolución propuesta parece ser ciencia ficción, sin embargo, puede ser más
1
Una red sin infraestructura es aquella que no requiere de puntos de acceso a la misma [6].
2
Mesoescala en Meteorología se refiere al estudio de sistemas del tiempo atmosférico cuyas dimen-
siones horizontales generalmente oscilan de cerca de 9 km a varios centenares de km. Ejemplos de
sistemas de mesoescala meteorológica son las brisas de mar, complejos mesoescalas convectivos, etc. [7].
3
Conjunto de reglas que especifican el intercambio de datos u órdenes durante la comunicación entre
sistemas [8].
1.2. WIRELESS SENSOR NETWORKS 3
clara al analizar hechos de la historia reciente que al parecer pasaron desapercibidos por
estar rodeados de cotidianidad. En 1973, algunas compañías retiran los cables telefónicos
terrestres y los reemplazan por torres de transmisión, dando origen al concepto de células
de comunicación y como resultado de ello las redes de telefonía celular [10], con más de
2.8 mil millones de celulares en uso y más de 1.6 millones introducidos cada día [2]. Para
1997, retirar los cables a las computadoras de escritorio dio paso a los equipos portátiles o
“laptops”, dispositivos que al ejercer esta “libertad” impulsaron de manera significativa
el desarrollo y uso de las redes inalámbricas. Solamente dos años después, en 1999 se
comenzó con la administración de tareas y el monitoreo de fenómenos de manera remota;
la representación del mundo físico llevada hacia el mundo digital. Pero el futuro no sólo
es brillante, también contiene oscuros. Lidiar con tantos dispositivos inalámbricos, de
acuerdo con [3], resultaría impráctico. Además, la seguridad y privacidad es todavía un
tema mayor no atendido del todo. Quizá el espectro radio eléctrico no será suficiente
para atender la demanda [11], y en el mediano plazo pueden aparecer sistemas que al
converger e interconectarse, crearán nuevos paradigmas con sus problemáticas asociadas.
1.2. Wireless Sensor Networks

Las redes inalámbricas de sensores o Wireless Sensor Networks están compuestas por
un número grande de dispositivos sensores autónomos de bajo costo, que están en comu-
nicación vía una red inalámbrica de corto alcance. Los sensores al tener la capacidad de
procesamiento y comunicación pueden ser introducidos en diferentes ambientes para que
de forma cooperativa monitoreen variables físicas como temperatura, sonido, vibración,
presión, movimiento o contaminantes [12, 13, 14].
En [15] se describe una serie de funciones y características básicas de estas redes
como la capacidad de auto organización. Siendo las más importantes la comunicación
en difusión de corto alcance con ruteo multisalto. Alta densidad de nodos y esfuerzo
cooperativo entre ellos. Cambios frecuentes de topología debido a las atenuaciones, fallas,
retiro o adición de nodos. Limitaciones de energía, potencia de transmisión, memoria y
poder de cómputo. De éstas, las últimas tres establecen la diferencia con las redes Ad
hoc o la redes de malla.
Las tecnologías inalámbricas se pueden clasificar con respecto a la distancia que la
señal puede alcanzar [16]. Las señales que más viajan son las pertenecientes a los Global
Positioning Systems (GPS) utilizadas por los sistemas satelitales, aunque son unidirec-
cionales. Las señales de Worldwide Interoperability for Microwave Access (WiMax) con
5 Km de alcance y 15 Mbps ancho de banda; los celulares de tercera generación High
Speed Downlink Packet Access (HSDPA) con 10 Km y 14 Mbps; los celulares de segunda
generación Global System for Mobile (GSM) y Code Division Multiple Access (CDMA)
con 35 Km y 400 Kbps, son las que siguen en alcance, además de utilizar enlaces bidi-
reccionales. En tercer lugar tenemos las señales de corto alcance bidireccionales como
Wireless Fidelity (WiFi) con 50-100 m y 54 Mbps y ZigBee con 30-100 m y 250 Kbps,
este es el rango de las WSN. Un avance reciente en este rango, es la Ultra Wide Band
(UWB) con un alcance de 5-10 m y 400 Mbps que usa frecuencias muy altas con un
alcance de transmisión muy corto para transmitir grandes cantidades de información,

como la transmisión de video de corto alcance. El cuarto tipo lo constituyen las Per-
sonal Area Network (PAN), el ejemplo típico es Bluetooth con 10 m y 700 Kbps. Por
último, está la Near Field Communication (NFC) dónde el contacto debe ser próximo.
Una variante la representa la Radio Frequency Identification (RFID) con 0.01-10 m y
1-200 Kbps. Por lo que en este panorama, lo anterior se ve resumido en la Figura 1.1.
Principales Tecnologías de Dos Vías*

Tasa de intercambio Costo
Rango
por segundo USD**
WiMax móvil 15 Mb 5 Km 8
Red Celular 3G 14 Mb 10 Km 6
(HSDPA/LTE)
Red Celular 2G 400 Kb 35 Km 5
(GSM/CDMA)
Wi-Fi 54 Mb 50-100 m 4
Bluetooth 700 Kb 10 m 1
ZigBee 250 Kb 30 m 4
UWB 400 Mb 5-10 m 5
RFID 1-200 Kb 0.01-10 m 0.04
* Rendimiento típico, los datos actuales pueden variar

** Costo aproximado de los componentes en alto volumen
Fuentes: William Webb; Cambridge Consultants; OECD; Pyramid Research;

Nokia; TI; CSR; Ember; Hitachi.
Figura 1.1: Rango de alcance de diversas señales de radiofrecuencia.
En una red de sensores existen diferentes tipos de dispositivos, los cuales son identifi-
cados de acuerdo con las funciones que realizan dentro del sistema. Los estándares rela-
cionados, como el estándar del Institute of Electrical and Electronics Engineers (IEEE)
802.15.4, distinguen los dispositivos basándose en la complejidad de su hardware y en sus
capacidades [17]. Dicho estándar define dos clases de dispositivos físicos: el Full Function
Device (FFD) y el Reduced Function Device (RFD). La diferencia principal entre ambos
es la cantidad de componentes que contiene cada uno de ellos y cuánta funcionalidad
del estándar puede ser implementada. Por lo que el FFD tendrá la cantidad de memoria
y recursos necesarios para ejecutar todas las funciones y funcionalidades establecidas en
el estándar. Incluso podrá asumir responsabilidades adicionales en el esquema de red,
llegando a comunicarse con otro tipo de redes. Un RFD es un dispositivo de capacidades
reducidas, para abatir costos y complejidad en los dispositivos. Típicamente contiene
su interfaz física hacia el modem inalámbrico y ejecuta el protocolo de acceso al medio.
Más aún, generalmente sólo se puede asociar con un FFD. Basados en los FFD y RFD
se pueden definir una serie de dispositivos lógicos. Los dispositivos lógicos se conforman
de acuerdo con la combinación de las capacidades físicas y las responsabilidades que se
les asigna en la red. En este sentido, se pueden definir tres categorías de dispositivos
lógicos: el coordinador de red, el nodo ruteador y los dispositivos terminales o de térmi-

no. El coordinador de red debe ser un FDD el cual tiene la responsabilidad de elegir los
parámetros clave de la configuración de la red y el inicio de la misma. Al mismo tiempo
puede almacenar información de la red y actuar como repositorio de llaves de seguridad.
El nodo ruteador debe ser un FDD que soporte la funcionalidad del ruteo de datos,
incluyendo su actuación como interfase para la interacción de diferentes componentes de
la red y el paso de mensajes entre dispositivos remotos a través de caminos multisalto.
Un nodo ruteador, puede comunicarse con otros ruteadores y con nodos terminales. Un
dispositivo terminal es un RFD el cual contiene la funcionalidad justa para comunicarse
con un nodo asignado, ya sea ruteador o coordinador. El dispositivo terminal no tiene
capacidad de repetir mensajes.
Estos dispositivos lógicos pueden ser organizados de diferentes formas, originando
tres tipos principales de topologías: estrella, malla o cúmulo en árbol, como se muestra
en la Figura 1.2.
Coordinador
Full Function Device (FFD)
Reduced Function Device (RFD)
a) Estrella b) Malla c) Cúmulo en árbol
Figura 1.2: Topologías de red.
La topología de estrella soporta un solo coordinador como se ve en la Fig. 1.2(a),

que para la IEEE 802.15.4 logra conectar hasta 65,536 dispositivos terminales. Todos los
demás dispositivos son considerados como terminales o de término. El coordinador tiene
la responsabilidad de iniciar y mantener en la red a los dispositivos terminales. Una vez
inicializados, los dispositivos terminales solamente pueden establecer comunicación con
el nodo coordinador. Una topología de malla, ver Fig. 1.2(b), permite establecer caminos
para la información desde cualquier dispositivo fuente a cualquier dispositivo destino,
usando algoritmos de ruteo basados en tablas o árboles de ruteo. En la topología de malla
se requiere que los radios de los nodos coordinadores y ruteadores estén encendidos todo
el tiempo. Una red de cúmulo en árbol, Fig. 1.2(c), permite que se establezca una red
punto a punto con un mínimo de proceso de ruteo, ya que usa el ruteo multisalto. Esta
topología es ideal para aplicaciones con alta tolerancia a la latencia4 en los mensajes.
Otra de sus características es que se auto organiza y soporta la redundancia en la red,
lo que permite un alto grado de resistencia a las fallas y adicionalmente se auto reparan.
El cúmulo puede ser significativamente grande, comprendiendo hasta 255 subcúmulos
con hasta 254 nodos terminales en cada uno de ellos, para un total de 64770 nodos en la
IEEE 802.15.4. Este tipo de topología puede abarcar áreas muy amplias. Cualquier FFD
puede ser coordinador y solamente existe uno. El coordinador forma el primer cúmulo y
le asigna un identificador o Cluster ID (CID) con valor cero. Los cúmulos subsecuentes
son formados con una cabeza de cúmulo designada para cada uno. Generalmente, ca-
da red utiliza identificadores de 16 bits. En esta topología el nodo coordinador asume
responsabilidades que incluyen el administrar la lista de dispositivos asociados; el inter-
cambio de tramas o paquetes de datos entre dispositivos de la red; la asignación de las
direcciones de 16 bits, también conocida como dirección corta, a cada dispositivo de la
red; generación de señales periódicamente para identificar el estado de la red así como
los parámetros de los dispositivos asociados.
De acuerdo con [19] para cualquier uso práctico de las WSN la comunicación entre
nodos no es suficiente. La red tiene que tener la capacidad de interactuar con otros
dispositivos, por ejemplo aquellos conectados a Internet. Un escenario se muestra en la
Figura 1.3.
Internet
Usuarios
remotos
Nodo
Compuerta
Red Inalámbrica de Sensores
Figura 1.3: Una red WSN con un nodo como compuerta habilitando el acceso a clientes
remotos vía Internet.
Desde este punto de vista, la WSN tiene la capacidad de intercambiar datos con
un algún otro dispositivo móvil o con alguna clase de compuerta que le provea de la
conexión física hacia Internet. Lo anterior tiene que ver con la capa física y la de enlace5 .
Independientemente de la topología utilizada en una WSN se requiere de una serie
4
En redes informáticas de datos se denomina latencia a la suma de retardos temporales dentro de
una red. Un retardo es producido por la demora en la propagación y transmisión de paquetes dentro
de la red.[18]
5
Se refieren a las capas manejadas en el modelo de referencia OSI.
de servicios, como por ejemplo el acceso a otro tipo de redes. Pero la acumulación y
el análisis de los datos no pueden ser realizados por los nodos sensores, sin importar
el tipo físico al que correspondan, por lo que se requiere de una estación base que
contenga las aplicaciones para tal propósito. La estación base también es utilizada para
la configuración de la red y en algunos casos incluso de los nodos.
La función de la compuerta, por otro lado, sí puede ser realizada por un FFD que
contenga los programas necesarios. La asignación del nodo que tendrá esta función se
puede identificar también de la Fig. 1.2. Para el caso de la topología en estrella Fig.
1.2(a), es obvio que será el nodo coordinador. Lo cual amplía las responsabilidades del
mismo y le añade procesamiento, sin mencionar que hace a la red más vulnerable al tener
un solo elemento con todas las responsabilidades; la pérdida del mismo haría colapsar la
red. Para la topología de malla Fig. 1.2(b), la compuerta puede ser asignada a cualquiera
de los nodos coordinadores, la selección final de su asignación pudiera estar relacionada
con criterios de cercanía hacia la estación base o bien la fortaleza de la señal de un
nodo coordinador con respecto de la red a la cual se quiere enlazar la WSN. En algunos
casos, la responsabilidad podría ser dinámicamente asignada a los nodos coordinadores
aludiendo a los criterios ya mencionados. Para una red en malla la pérdida de un nodo
coordinador no significa el colapso de la red e incluso la función de compuerta puede
ser relevada a otro nodo coordinador para mantener todas las funciones. Para el caso de
una red en clúster en árbol Fig. 1.2(c) la elección de la compuerta se basa también en la
selección del nodo coordinador que llevará esta responsabilidad, una vez más se puede
utilizar el criterio de cercanía hacia la estación base o la red alterna, sin embargo se
debe tener en cuenta la jerarquía de los nodos coordinadores, por lo que sería preferible
asignarla al nivel más alto de la jerarquía, es decir, el nodo coordinador con el CID más
bajo. Al igual que en la red de malla, la pérdida de un nodo coordinador no significa el
colapso de la red, a lo más una reorganización de la misma.
Con toda esta flexibilidad, características y funciones asociadas a las redes sin in-
fraestructura y por herencia a las WSN, se podría pensar que no existen puntos débiles
en ellas, situación que está muy lejos de la realidad. En [20] se identifican algunos de los
retos y debilidades que deberán superar las WSN para convertirse realmente en ubicuas6 .
Algunas de las limitaciones de las WSN, sin circunscribirse a ellas, son los problemas
de tamaño y capacidad de los nodos, factores de energía, costo de los nodos, factores
ambientales, factores en los canales de transmisión, la administración de la topología,
su complejidad y la distribución de nodos, la implementación bajo estándares en lugar
de soluciones propietarias, los problemas relacionados con la escalabilidad y problemas
de seguridad. Sin duda todos estos retos y debilidades son relevantes y deberán de ser
superados, sin embargo no todos tienen el mismo peso o influencia para la adopción
masiva de las WSN. Dependiendo de la aplicación, los aspectos de seguridad pueden ser
los críticos [22]. Las WSN deben habilitar la detección de intrusos y al mismo tiempo
ser tolerantes a las fallas para proveer una operación confiable, aunque es común que los
nodos sensores no estén protegidos en contra de manipulaciones o ataques.
6
La ubicuidad de las tecnologías está dada por la disponibilidad de servicios, procesos e información
vinculada a ellas en cualquier lugar y en todo momento [21].
En términos generales, de acuerdo con [23], la seguridad se define como la condición

o cualidad de estar libre de preocupación, aprensión o ansiedad. Al ampliar el concep-
to hacia una red de comunicación, podemos establecer que una red segura es aquella
en dónde sus usuarios no sienten algún tipo de aprensión o ansiedad mientras la usan.
Nótese como el significado de una red segura depende de cómo es utilizada. Por ejem-
plo, mientras la Internet fue del dominio de ingenieros y científicos, los usuarios no se
preocuparon por la seguridad. Si el usuario era lo suficientemente diestro para acceder a
ella, entonces podía usarla de la manera en que mejor le pareciera. Con el advenimiento
del uso comercial de la Internet, la seguridad se convirtió en todo un tema y al mismo
tiempo en un campo de oportunidades. En esta línea de pensamiento, se considera que
una red de comunicación segura debe de otorgar facilidades como la confidencialidad,
integridad, autenticación, no repudio y confiabilidad en el servicio. Es crucial determinar
que todas estas facilidades o requerimientos son estrictamente independientes, por lo que
la presencia o ausencia de uno u otro(s) no garantiza la presencia o ausencia de otro(s).
De esta forma, podemos establecer que un primer nivel de defensa en contra de algunas
amenazas lo representan los mecanismos de autenticación en las WSN, tema pretendido
por la tesis.
1.3. Estado del arte

Estudios e investigaciones recientes sobre las WSN coinciden en que los aspectos de
seguridad son una prioridad en el desarrollo de esta tecnología [24, 25, 26, 27, 28, 29, 30,
31, 32, 33, 34, 35, 36]. Al situarnos en el contexto histórico del desarrollo de las redes
de comunicación, podemos identificar claramente el impacto e influencia que ha tenido
el concepto Internet a nivel mundial. Sin embargo, como ya se ha mencionado, Internet
estaba pensada para un contexto académico y de investigación; por lo que la seguridad
pasaba a un segundo o tercer término, en el mejor de los casos. En una red que hoy día
maneja alrededor de mil millones de dispositivos, sin duda la seguridad es una de las
prioridades más importantes.
En 1992 El Dr. David Clark del MIT dio una conferencia sobre temas técnicos rela-
cionados con la denominación de dominios y su escalabilidad [37]. En dicha conferencia
mostró algunas diapositivas relacionadas con el lado obscuro de la Internet: su falta de
seguridad inter construida, hizo referencia sobre la predisposición humana a ignorar los
problemas, mencionando que los grandes desastres rara vez son causa de eventos súbitos
y fortuitos; generalmente están asociados a procesos lentos e incrementales. “Las cosas se
ponen peores lentamente. La gente se habitúa” señalaba en la presentación, “El proble-
ma es asignar el grado correcto de miedo a los elefantes a la distancia,” mostró en otra.
En una entrevista a finales del 2005 [37] el Dr. Clark establece su creencia de que los
elefantes están sobre nosotros, si bien la red ha traído consigo una serie de beneficios y
maravillas tecnológicas, al mismo tiempo ha visto detenida su evolución como resultado
de sus fallas en seguridad y en su habilidad reducida para acomodar nuevas tecnologías.
El esquema actual de identificación de fallas, generación de remedios o parches y una
vez más la identificación de fallas en un ciclo sin fin, es un esquema que no puede ser
1.3. ESTADO DEL ARTE 9
sostenido por más tiempo. Por lo que el Dr. Clark ha propuesto una nueva arquitec-
tura para la Internet y redes colaborativas que contemplen desde un inicio otro tipo
de elementos adicionales, como son: seguridad, protocolos, movilidad e instrumentación.
Con respecto a la seguridad la Internet debe autenticar a los equipos y personas que
se comunican. Los nuevos protocolos deberán integrar mejores acuerdos de ruteo entre
proveedores de servicios de Internet les permitirían colaborar en servicios avanzados sin
comprometer sus negocios. Con respecto de la movilidad, el asignar direcciones del pro-
tocolo de Internet a dispositivos pequeños como sensores, teléfonos y procesadores inter
construidos en automóviles les permitiría conectarse a la Internet de manera segura. Por
último, la instrumentación permitirá que todos los elementos activos de la red tengan
la posibilidad y habilidad de detectar y reportar problemas emergentes a los adminis-
tradores de las redes. Se puede deducir que el Dr. Clark identifica en sus trabajos, de
manera indirecta, que dispositivos tan básicos como los sensores pueden contribuir de
manera importante al caos existente en la red, más aún cuando él estima que en veinte
años la cantidad de dispositivos en la red será de un billón. De los cuales, la mayoría
serán dispositivos de capacidades reducidas como los sensores que conforman los nodos
de las WSN.
La propuesta de mejoras en la arquitectura y la consideración de elementos de seguri-
dad en nodos sensores o MOTES corresponde inicialmente a un grupo de investigación de
la Universidad de California en Berkeley [38]. En este trabajo no solamente se establece
la propuesta de una arquitectura genérica para MOTES, al mismo tiempo presentan
un prototipo y un sistema operativo basado en eventos que reside y funciona en el dis-
positivo. El sistema operativo denominado TinyOS, de un tamaño de 178 bytes, podía
propagar eventos en el tiempo que le tomaba copiar 1.25 bytes a su memoria. Otro punto
a resaltar, es que el documento es previo a las consideraciones del Dr. Clark y que en
si mismo se constituye como el primer documento de uso público sobre los desarrollos y
tecnologías de las WSN. Al igual que el Dr. Clark, el documento mencionado, conside-
raba en el 2005 que una de las limitantes de la evolución de la Internet era su falta de
seguridad, [30] coincide en que los aspectos de seguridad son también una de las causas
por las que las aplicaciones prácticas de las WSN no se han dado a la fecha. Relacionado
con los aspectos de seguridad en vehículos utilizando un esquema de autenticación con
preservación de la identidad, este trabajo utiliza técnicas de firma ciega que permiten
a los vehículos interactuar con infraestructura vial de manera anónima. Manifiestan al
mismo tiempo que existen pocos trabajos que atiendan aspectos de seguridad como la
privacidad y la autenticación en redes sin infraestructura. Este trabajo está fechado a
principios de 2008. El campo de la criptografía es el que se ocupa de dar solución a estas
necesidades, lo cual nos da pie para poder establecer una clasificación de los artículos
consultados. En una búsqueda exhaustiva y para fines de esta propuesta de protocolo
de tesis, se identificaron los siguientes trabajos relacionados con aspectos de autenti-
cación en WSN, redes Ad hoc y Mobile Ad hoc Networks (MANET). De los cuales,
6 están relacionados con autenticación de llave pública [27, 29, 31, 32, 39, 40], 4 con
autenticación de secreto compartido [24, 34, 41, 42], 2 con funciones hash [34, 43], 2 con
criptografía de umbral [33, 44], 2 en esquemas de confianza [26, 45] y los 3 restantes con
esquemas mixtos [28, 30, 38]. En número total de referencias recuperadas para temas
de seguridad en WSN, MANET y Ad hoc fueron 85 y para temas relacionados con los
mismos tópicos, pero no necesariamente relacionados con seguridad, fueron un total de
529 referencias. De acuerdo con los datos estadísticos presentados, se coincide en que
son pocos los trabajos relacionados con aspectos de autenticación para las WSN. En
los párrafos siguientes se profundizará en lo expuesto en los trabajos seleccionados para
establecer el estudio del estado del arte.
Debido a que este trabajo se centra en la autenticación, sería conveniente definir
qué es y algunos conceptos relacionados. De acuerdo con [46] la palabra autentico se
refiere a algo que no es falso o una imitación, pero también es ampliamente aceptada
la acepción relacionada con la veracidad de un hecho. La autenticación consiste de dos
actos: primero, el acto de proporcionar pruebas de la autenticidad de la información que
es enviada o almacenada, y segundo, el acto de verificar las pruebas de autenticidad de
la información recibida o recuperada. La autenticación de un cliente significa que un
cliente deseando obtener acceso a una red presenta su identidad con un conjunto de cre-
denciales, como prueba de la autenticidad de la identidad presentada. Las credenciales
son entonces usadas por la red para verificar que la identidad realmente pertenece a ese
cliente. Intencionalmente se ha utilizado la palabra cliente, ya que la misma se puede
interpretar como un dispositivo o un ser humano. Por esta razón, la autenticación de
clientes debe ser dividida en dos categorías: autenticación de dispositivos y autenticación
de usuarios. Mientras que la autenticación de usuarios y dispositivos se encarga de ase-
gurar que los actores en el proceso de comunicación son legítimos y quiénes dicen ser. La
autenticación de los mensajes, por otra parte, se asegura de verificar la integridad de los
datos. Es decir, la protección de la integridad de los datos tiene por finalidad prevenir
el intento malicioso de corromper o modificar los datos de un mensaje. La autenticación
es un mecanismo mediante el cual también se puede proveer o determinar privilegios, a
esto se le llama autorización. El privilegio puede otorgar accesos a un recurso, como por
ejemplo el acceso a un medio de comunicación, a una base de datos, a una computadora
o a muchos otros servicios provistos por una red.
La eficiencia de una WSN depende de que los datos sensados sean correctos. Al mis-
mo tiempo, la seguridad es importante para prevenir que agentes externos (personas o
dispositivos) puedan recuperar información correcta de ella. Se proponen los mecanismos
de autenticación como contramedida de ataques internos y externos. La colaboración vo-
luntaria entre nodos asume el acceso al medio, el descubrimiento de rutas y el reenvío de
paquetes entre otros servicios. Cuando los nodos son autónomos, no quieren compartir
información o son maliciosos en una red de gran escala, la suposición inicial deberá cam-
biar necesariamente. Por lo cual también es requerida la autenticación de los nodos. En
[24] se proponen dos protocolos para la autenticación entre sensores, uno directo y otro
cooperativo. El directo utiliza un esquema estático y el cooperativo uno adaptivo. Ambos
protocolos garantizan implícita y probabilísticamente la autenticación sin proceso signi-
ficativo en los nodos con o sin la presencia de una estación base. El esquema de seguridad
utiliza una técnica de generación pseudoaleatoria de llaves basada en el identificador de
sensor como semilla. En [42] se presenta la problemática del uso de llaves de acuerdo
para la autenticación en grupos dinámicos de pares. Se muestran cuatro propuestas de

protocolos en fase inicial, por lo que las conclusiones se relacionan con la necesidad de
llevar los protocolos a sistemas reales que provean de retroalimentación y experiencia
para un mejor entendimiento de las necesidades y servicios de seguridad requeridos por
grupos dinámicos de nodos. El protocolo de [41] satisface tanto la autenticación como la
confiabilidad de las comunicaciones en redes Ad hoc. El esquema de seguridad incluye el
manejo de identidad anónimo, la imposibilidad del rastreo de la localización del nodo,
llaves periódicas de una sola sesión, identidad pseudónima con autenticación implícita,
entrada y salida dinámica de la red, inventario de sesiones en progreso y la encripción
de los datos. La confiabilidad del protocolo incluye la tolerancia eficiente a ataques de
negación de servicio o Denial of Service (DoS), tolerancia a fallas para recuperar men-
sajes perdidos y cambio de llave sin alterar las transmisiones de salida. En [24, 41, 42] el
común denominador es el uso de la tecnología de secreto compartido en los protocolos
propuestos.
Una aproximación diferente de autenticación la encontramos en [25] que establece de
manera categórica, en el 2001, que solamente puede usarse criptografía de llave simétrica
en los nodos, debido a las limitantes de recursos en los mismos. Por lo que se propone un
esquema de actualización periódica de llaves. Si bien el esquema propuesto, a decir de los
autores, cumple con los requerimientos de seguridad y bajo procesamiento; la realidad es
que la capacidad de los nodos aún es limitada, pero sin duda ha avanzado enormemente,
sobre todo en el aspecto de procesamiento, por lo que el uso de criptografía asimétrica
para esquemas de autenticación es viable actualmente.
Otra forma de atender la autenticación es mediante el establecimiento de mecanismos
de confianza y reputación [26]. El esquema habilita a cada nodo para asignar un valor
de confianza a cada entidad con la que interactúa, el cual puede ser revocado. El proceso
no requiere de mucho trabajo de cómputo y consume poca energía de transmisión por
lo que lo hace ideal para las WSN. En esta misma aproximación, el trabajo de [45]
innova al presentar un esquema de confianza evolutivo basado en la noción humana de la
confianza; con interacciones iniciales de bajo riesgo y evolucionando hacia otras de mayor
riesgo conforme el nivel de confianza aumenta. A diferencia del primero, éste último
está pensado para reemplazar la intervención explícita de los humanos en escenarios
aplicativos.
Las funciones Hash forman parte de los procedimientos de autenticación en las redes
y no es extraño que en [34, 43] se plantee el uso de funciones Hash es una aproximación de
poco procesamiento computacional que no genera sobre proceso en los microprocesadores
o microcontroladores de los nodos. En [43] se considera que las funciones Hash promueven
la cooperación entre pares para todos los procesos de la red. En tanto que en [34] las
funciones Hash proveen la primera capa de seguridad de un esquema mixto, la cual
es usada para la verificación del grupo y la rápida verificación de los mensajes. En la
segunda capa, se utiliza tecnología de secreto compartido, para una identificación segura
de los nodos. Este esquema puede prevenir ataques internos y externos. Mientras que la
primera capa provee seguridad limitada de baja complejidad, la segunda capa provee de
seguridad moderada de complejidad media.
Las autoridades de certificación en los esquemas de clave pública y la criptografía

de umbral son otra forma de proveer los servicios de autenticación requeridos por las
WSN. En [28] se propone utilizar autoridades de certificación distribuidas basadas en
criptografía de umbral usando una arquitectura de clúster en árbol. Para el uso de este
método, existen dos problemáticas principales: la localización de las Certificate Autori-
ties (CA) y el cómo hacer la actualización de los certificados. El trabajo propone como
solución utilizar el Clúster Head (CH) o nodo coordinador como CA, a manera de que los
nodos entrantes a la red tengan servicio y que el secreto compartido pueda ser actualiza-
do de manera eficiente a través de la red. Debido a que el control centralizado de grupos
en redes Ad hoc conlleva inseguridades inherentes y al mismo tiempo es vulnerable a
ataques internos y externos de la red. Descentralizar el control de acceso es un servicio
de seguridad requerido en una red Ad hoc. No sólo para prevenir accesos no autorizados,
también para el manejo de otros servicios como el manejo de llaves de seguridad y el
ruteo seguro. Por lo anterior, [44] propone un mecanismo de control de acceso basado
en criptografía de umbral y más específicamente, con el uso de firmas electrónicas. En
[33] la característica sobresaliente del método propuesto es que se establece un número
de llaves de umbral para las sesiones simultáneas entre el usuario y los nodos sensores,
durante el proceso único de autenticación y sin el uso de llave pública criptográfica. El
esquema reduce la complejidad computacional y al mismo tiempo refuerza los aspectos
de seguridad. El trabajo hace dos contribuciones; un autómata y una autenticación de
umbral con el manejo de llaves para defensa contra ataques externos.
Las WSN tienen problemas detectando y previniendo nodos maliciosos, los que usual-
mente acarrean amenazas y comprometen a los sensores a su alrededor. Como ya se ha
mencionado, los nodos deben de soportar un servicio de autenticación para la identifi-
cación de los sensores y la transmisión de datos. La detección de intrusos permite también
esquemas de prevención que amplían los mecanismos de seguridad para descubrir nodos
maliciosos o comprometidos. En [36] se propone un modelo de seguridad adaptivo para
asegurar redes en topología de clúster en árbol. El esquema permite que los nodos exis-
tentes en la red autentiquen a los nuevos, establecen canales seguros y un esquema de
autenticación tipo broadcast entre los nodos vecinos. Se previene la intrusión de nodos
maliciosos usando los esquemas de autenticación. El esquema de seguridad es modular y
el módulo de autenticación puede excluir nodos internos comprometidos, mediante el uso
de alarmas, evaluación de la confianza y esquemas de listas blancas/negras. También en
[36] se argumentan y prueban la eficiencia en el protocolo con respecto de la seguridad,
el consumo de energía, la cantidad de procesamiento y los procesos de comunicación.
En oposición a [25], más recientemente [27, 29, 31, 32, 39, 40] han demostrado que
la incorporación de criptografía de llave asimétrica es posible en las actuales condiciones
de los nodos de las WSN. El esquema utilizado es el de llave pública con algunas varia-
ciones. El trabajo en [39] propone una solución para emular de una manera dinámica y
distribuida el papel de una Private Key Generator (PKG) en una WSN, de tal manera
que los nodos que se unan puedan compartir la llave maestra de un esquema basado en
identidad. La PKG se esparce de manera dinámica conforme la red crece. El principal
reto de una PKG en una red MANET o WSN es que no todos los nodos tendrían acceso
a la misma de forma directa; ya que puede fallar durante el tiempo de vida del protocolo
o incluso puede ser atacada, comprometiendo todo el sistema. Se propone el distribuir
en una serie de nodos alternos el papel de PKG, de esta manera no habría un solo PKG
en la red. Incluso nuevos elementos podrían serlo bajo ciertas circunstancias de arquitec-
tura, permisos y requerimientos de hardware satisfechos. Adicionalmente, proponen un
acuerdo de llaves en las contrapartes de manera no interactiva. Para [27], es más viable
un sistema de autenticación multiusuario mediante broadcast7 el cual permite a muchos
usuarios autenticarse y unirse a la WSN dinámicamente. Objeta que los mecanismos
de llave pública proveen estos servicios pero no cumplen con la seguridad, escalabilidad
y eficiencia simultáneamente. Presenta un esquema de autenticación llamado Identity-
based Multi-user Broadcast Authentication Scheme (IMBAS), basado en la identidad
y un broadcast multiusuario. El broadcast lo dividen en dos categorías que emplean
dos primitivas criptográficas diferentes. Los usuarios del broadcast se aseguran con una
firma basada en identidad sin la necesidad de par (pairing-free); el emisor del broadcast
es asegurado mediante una firma Schnorr8 con recuperación parcial de mensaje para op-
timizar la eficiencia. La llave privada de los usuarios es protegida mediante contraseña
para resistir posibles ataques.
Como se ha descrito, para asegurar la interoperabilidad con redes actuales, se ha
reutilizado mucha de la interacción entre cliente-servidor de las tecnologías de Internet
con pequeños cambios para propiciar la comunicación entre pares que se da en la redes
Ad hoc. Se desarrollaron métodos para el descubrimiento de servicios, manejo de se-
siones y seguridad que puedan ser utilizados en redes sin infraestructura. El marco de la
arquitectura propuesto en [29] habilita el uso seguro y dinámico de los servicios en redes
Ad hoc. Se basa en tres piedras fundamentales: administración local de los dispositivos
así como de la autorización y autenticación de los mismos, descubrimiento seguro de
servicios y administración segura de las sesiones. Los cuales están presentes en el uso se-
guro de cualquier servicio y son tradicionalmente utilizados en las arquitecturas basadas
en servidores. El marco utiliza un esquema de llave pública para la autenticación. Una
de la ventajas que se aprecian es que usuarios que se conocieron previamente se pueden
autenticar entre ellos, aún si no hay una aplicación específica de por medio y toda la
criptografía relacionada a la autenticación es realizada localmente. Un usuario o nodo
debe tener la tabla de certificados de los demás usuarios o en su caso obtenerla de la red
para luego verificarla de manera local.
Asegurar una red sin infraestructura de una manera completamente auto organizada
es efectivo y requiere de poco procesamiento, pero falla cumpliendo con la iniciación de
la confianza, es decir, en la autenticación. La propuesta de [32] defiende que es nece-
sario construir una relación de confianza bien establecida sin asumir nada y propone un
7
Broadcast, en castellano difusión, es un modo de transmisión de información donde un nodo emisor
envía información a una multitud de nodos receptores de manera simultánea, sin necesidad de reproducir
la misma transmisión nodo por nodo [47].
8
En criptografía, una firma Schnorr es una firma basada en la intratabilidad de ciertos problemas de
logaritmos discretos. Esta considerada como el esquema de seguridad más simple que pueda considerarse
segura entre los modelos aleatorios, es eficiente y genera firmas cortas [48].
modelo de confianza distribuida basado en una solución probabilística. Un negociador

de "secreto", secreto compartido, es utilizado solamente en la conformación inicial de
la red, la cual evoluciona hacia relaciones con cadenas de confianza más robustas. Es
entonces cuando un esquema de confianza auto organizado es adoptado como respuesta
al cambio dinámico de miembros. El esquema está basado en criptografía de llave públi-
ca y su propuesta modular supone que el esquema puede ser extendido a protocolos de
capas superiores.
El estudio de las redes Ad hoc se está enfocando principalmente en retos específicos
de la radiofrecuencia y en el ruteo de paquetes. Para que estas redes sean posibles y
prácticas, también se tiene que considerar cómo es que interactúan los protocolos de
Internet y cómo soportar sus aplicaciones en las redes Ad hoc o WSN. Por lo que [40]
se enfoca en el descubrimiento de servicios, manejo de sesiones y seguridad para estas
redes. Se propone un módulo de autenticación y autorización (AA) que construye una
estructura jerárquica de certificación que provee de derechos de acceso y niveles de
seguridad a los usuarios. El esquema de control de acceso es de dos vías, los usuarios
pueden definir diferentes derechos de accesos dependiendo de los servicios que los mismos
proveen a los demás nodos, por lo que cada nodo de la red debe tener su módulo de AA.
La mayor parte de los protocolos de seguridad propuestos para WSN están diseñados
para proveer un nivel uniforme de seguridad a lo largo de la red. Cuando un nodo se
comunica, puede requerir de diferentes niveles de seguridad, basado en su rol o papel en
la red. La propuesta de [31] es establecer un esquema de acceso basado en roles o pape-
les, llamado Role Based Access Sensor Network (RBASN) el cual provee de seguridad
multinivel en la red. Cada grupo en la red es organizado de tal manera que se pueda
implementar el esquema de roles. La seguridad multinivel está basada en la asignación de
llaves individuales para cada nodo de los diferentes niveles. La red se organiza mediante
un diagrama Hasse9 para calcular la llave de cada elemento y extenderla de manera que
se pueda construir la llave de grupo. Se considera un protocolo óptimo en consumo de
energía y velocidad de procesamiento. Se usa un modelo de certificación jerárquica con
el manejo de llaves. Para lo cual se sugiere el uso de llaves (públicas, privadas) en cada
nodo, en lugar de sólo proveer una llave con un certificado adjunto a la llave para veri-
ficación en el control de acceso a la red. En este modelo, se sugiere que la estación base
cree las firmas digitales y las envíe al grupo de nodos que actuarán como autoridades de
certificación y que generarán los certificados para los nodos terminales. Sugieren que el
certificado sea creado con base en la localización del nodo y su jerarquía en la red.
Una aproximación aparentemente simplista se realiza en [35], ya que debido a las
características de las WSN el trabajo se basó en localizar los esquemas de seguridad
en la estación base. La aplicación implementa la mitigación contra el análisis de tráfico
basada en la transmisión de paquetes encriptados. El rango de alcance de la red se ex-
tiende utilizando los nodos adyacentes como intermediarios y el modelo corrige algunos
9
En matemáticas, un diagrama de Hasse es una representación gráfica simplificada de un conjunto
parcialmente ordenado finito. Esto se consigue eliminando información redundante. Para ello se dibuja
una arista ascendente entre dos elementos solo si uno sigue a otro sin haber otros elementos intermedios
[49].
1.4. OBJETIVO DEL TRABAJO 15
comportamientos irregulares de los nodos. En este caso, el procesamiento se realiza total-

mente en la estación base y la participación de los nodos se limita al mínimo necesario.
Este tipo de solución puede ser útil para redes de muy pocos elementos y con poco al-
cance, pero en definitiva es poco flexible, comparada con todos los esquemas propuestos
con anterioridad.
1.4. Objetivo del trabajo

Modelar, simular e implementar un protocolo de autenticación de nodos basado en
el esquema Public Key Infrastructure (PKI) para una red WSN experimental del tipo
clúster con topología en estrella. El protocolo se utilizará con fines didácticos y en tra-
bajos posteriores de investigación.
1.5. Metodología
Para alcanzar el objetivo, se propone la siguiente metodología u objetivos particu-
lares:
1. Modelar matemáticamente las funciones y algoritmos del protocolo, en la genera-

ción de claves y mecanismos de autenticación.
2. Escribir los algoritmos en pseudocódigo.
3. Escribir los programas de los algoritmos y funciones mencionadas.
4. Integrar las funciones en el protocolo.
5. En el simulador escribir el programa del protocolo para una red hipotética.
6. Simular los ataques de identidad en dicha red.
7. Simular cambios de topología y de roles en los nodos.
8. Implementar el protocolo en una red experimental en el laboratorio.
9. Análisis, discusión, ponderación y presentación de los resultados obtenidos.
10. Publicación de los resultados de esta investigación en artículos de revistas y con-

gresos.
1.6. Recursos empleados

La selección de la tecnología y de los componentes se realizó con base en un estudio
previo del estado del arte de los MOTE. Trabajo que nos permitió identificar la viabilidad
de la implementación física del resultado esperado en este trabajo, así como identificar
proyectos adicionales que nos ayuden a consolidar esta línea de investigación. Se ha
optado por utilizar una tecnología reciente de dispositivos todo en uno o System on
Chip (SoC), los cuales integran los bloques principales requeridos por un MOTE en un
solo dispositivo, de la compañía Texas Instruments. La familia de dispositivos es conocida
por la tecnología de radio que utiliza que es ZigBee, una alianza de varias empresas cuyo
objetivo es poner a la disposición de desarrolladores y usuarios dispositivos que cumplan
con la norma 802.15.4, así como un conjunto de funciones inter construidas y mecanismos
de acceso a ellas mediante la conformación de un grupo de instrucciones e interfaces de
programación. En términos generales, la tecnología seleccionada provee un ambiente
inicial propicio para el desarrollo. Este ambiente debe ser estudiado a profundidad para
identificar sus bondades, pero más aún sus limitaciones. El chip utilizado es el CC2431,
el cual cuenta adicionalmente con un módulo de localización y un motor de encripción
basado en Advanced Encryption Standard (AES).
El número de los MOTE a nuestra disposición limitó de manera significativa las
pruebas en infraestructura física, por lo que problemas asociados a redes de amplia
envergadura no serán analizados, sin embargo es factible la simulación mediante NS2
y posiblemente con un módulo desarrollado sobre NS2 con el propósito de atender las
necesidades particulares de las redes de sensores denominado Sensor-Sim, que en la
actualidad está en fase beta de desarrollo, por lo que habrá que esperar para hacer las
adecuaciones a la simulación de NS2 y extender el modelo con Sensor-Sim, para trabajos
futuros.
Se tuvieron a nuestra disposición dos tarjetas de desarrollo y dos computadoras
portátiles para las pruebas de comunicación, además de una serie de programas que son
mencionados durante el desarrollo de este trabajo y en sus apéndices.
1.7. Organización del trabajo

Este trabajo está dividido en cinco capítulos y seis apéndices como sigue: Capítulo
1. Introducción, Capítulo 2. Autenticación en la WSN, Capítulo 3. Protocolo de au-
tenticación de nodos, Capítulo 4. Implementación del protocolo propuesto y Capítulo
5. Conclusiones. Los apéndices son: Apéndice A. Matemático, Apéndice B. Estándar
Avanzado de Encripción (AES), Apéndice C. Características de los MOTE, Apéndice
D. Instalación de la red, Apéndice E. Base de Datos de los Nodos y Apéndice F. Pro-
gramas.
En el Capítulo 2 se abordan los aspectos básicos de la conformación de las redes WSN
así como los aspectos de seguridad básicos, los métodos existentes y las problemáticas
que presentan para su implementación.
En el Capítulo 3 se abordan los aspectos tecnológicos de la implementación de un
1.7. ORGANIZACIÓN DEL TRABAJO 17
protocolo de autenticación en la infraestructura seleccionada para este trabajo y se

establecen los algoritmos básicos sobre los cuales se desarrolló la propuesta.
El Capítulo 4 tiene que ver con la implementación de la propuesta desarrollada sobre
los dispositivos físicos seleccionados, algunos aspectos de diseño que debieron ser tomados
en cuenta y que en apariencia no tienen impacto en el protocolo, pero sí en la operación
segura del mismo.
Finalmente, el Capítulo 5 presenta las conclusiones, en dónde adicionalmente se men-
cionan una serie de trabajos a futuro.
En la parte final del trabajo se presentan seis apéndices. En el Apéndice A se pre-
senta el soporte matemático de los protocolos y algoritmos utilizados. El Apéndice B
está dedicado a explicar a detalle el protocolo de encripción AES incorporado en los
dispositivos seleccionados. El Apéndice C presenta un breve resumen del estudio de los
Elementos de Transmisión Móviles conocidos como MOTE, realizado para fundamen-
tar la selección del dispositivo y para obtener la aprobación del protocolo previo a este
trabajo. El Apéndice D constituye una guía para todos aquellos que decidan continuar
con trabajos relacionados por esta línea, allí se detallan una serie de problemáticas re-
sueltas que pueden reducir considerablemente sus tiempos de desarrollo. El Apéndice E
establece los fundamentos del uso de un esquema formal de bases de datos relacionales
para su aplicación en la conformación de una entidad certificadora, si bien no está dentro
de los alcances del trabajo la AC. La selección de este tipo de tecnologías aporta una
serie de beneficios que son discutidos en el trabajo. Finalmente, el Apéndice F presenta
parte de los códigos utilizados para la implantación del protocolo en los dispositivos.
Capítulo 2
Autenticación en la WSN
En este capítulo se presentan los aspectos teóricos y definiciones sobre los aspectos
físicos y lógicos de las redes WSN, así como de los aspectos de seguridad involucrados en
el trabajo; en dónde se establece el concepto de seguridad, sus metas, alcances, métodos,
etc. Por último, se trata la definición y composición de la infraestructura de llave pública
(PKI), fundamento del protocolo propuesto en el capítulo 4, el cual es una combinación
de una serie de protocolos presentados durante el capítulo 3.
Cuando los MOTE son introducidos a un contexto de red inalámbrica, se pueden
presentar diversos escenarios de aplicación a alto nivel. Escenarios concretos con obje-
tivos de optimización y de organización dan origen a su vez a arquitecturas o arreglos
funcionales de los MOTE denominadas arquitecturas de las WSN. En ellas se involucran
los mecanismos de los protocolos y principios que constituyen la diferencia de las WSN
con respecto de otro tipo de redes. Para que las capacidades de las WSN puedan ser
aprovechadas es necesaria una interfaz de servicio adecuada, así como su integración en
redes de amplio contexto.
2.1. Arquitectura de la WSN

La arquitectura de las WSN se conforma desde varias fuentes de influencia [19].
Históricamente, las tres líneas que más han aportado a su desarrollo son las redes móviles,
las auto-organizadas y las Ad-hoc. Aunque todas ellas tienen propósitos diferentes, todas
comparten la necesidad de una organización descentralizada y distribuida. En contextos
diferentes, las WSN están fuertemente relacionadas con el cómputo en "tiempo-real", in-
cluso a conceptos del cómputo entre pares o "peer-to-peer". De igual manera, se les puede
encontrar puntos comunes con las redes activas, de agentes móviles o de inteligencia de
enjambre. Consecuentemente, el número de ideas y publicaciones sobre la arquitectu-
ra de las WSN es vasto, lo que dificulta el dilucidar quién aportó qué, o quién lo hizo
primero.
Sin importar la organización de la red o la clasificación de los dispositivos por sus
capacidades, las funciones de todos los dispositivos en una WSN se pueden clasificar en
dos grandes rubros, fuentes y pilas o sumideros. Una fuente es cualquier nodo en la red
19
20 CAPÍTULO 2. AUTENTICACIÓN EN LA WSN
que puede proveer información. Esto es, típicamente un nodo sensor; incluso puede ser
un nodo actuador que suministra retroalimentación de su operación, esto es, un RFD.
Una pila o sumidero, por otra parte, es el nodo en dónde se requiere la información,
generalmente un FFD. Y esta a su vez puede ser clasificada en tres opciones: 1) puede
pertenecer a la red sensores como un nodo sensor/actuador cualquiera. 2) puede tratarse
de un dispositivo externo utilizado para interactuar con la red, como una computadora
portátil o un dispositivo de mano. 3) puede ser un dispositivo externo que permite la
comunicación con otro tipo de redes haciendo las veces de compuerta. Las solicitudes de
información pueden provenir de cualquier dispositivo que tenga acceso a la red de origen
del dispositivo. Esta clasificación se puede observar de manera gráfica en la Figura 2.1.
Figura 2.1: Tres tipos de sumideros en una red de sensores de un solo salto.
2.2. Redes de un solo salto versus redes de múltiples

saltos
Como una parte de las limitantes físicas inherentes a los sistemas de radio comuni-
cación tenemos el alcance del enlace o distancia máxima entre emisor y receptor. Debido
a ello, muchas veces la comunicación directa entre ellos no es factible, más aún para las
WSN, las cuales han sido pensadas para atender grandes coberturas en algunas de sus
posibles aplicaciones, (monitoreo de bosques o plantaciones) o bien operar en ambientes
difíciles para la radio comunicación al presentar atenuaciones importantes de las señales
como en las edificaciones actuales.
Para salvar la limitación de la distancia, resulta obvio el uso de estaciones repetidoras,
con lo cual los paquetes de datos pueden tomar múltiples saltos desde la fuente hacia el
2.2. REDES DE UN SOLO SALTO VERSUS REDES DE MÚLTIPLES SALTOS 21
sumidero, como una solución ante el problema de la faltante de línea de vista. Este con-
cepto se ilustra en la Figura 2.2 y es particularmente útil en las WSN ya que los nodos
sensores pueden actuar como estaciones repetidoras sin la necesidad de equipamiento
adicional. Dependiendo de la aplicación, resulta altamente probable el encontrar una
estación repetidora intermedia entre una fuente y un sumidero, sin embargo, y sin im-
portar lo corto de una ruta entre ambos, no existe ninguna garantía de que ésta exista.
Fuente Obstáculo Sumidero
Figura 2.2: Redes multisalto: Cuando la comunicación directa es imposible, debido a la

distancia y/o obstáculos, la comunicación multisalto es una forma de resolver el proble-
ma.
Mientras que el uso de la técnica de multisalto resulta evidente para resolver los
problemas de alcance, no resulta tan obvio que aporte mejoras sustanciales en el uso
eficiente de la energía utilizada en la comunicación. El razonamiento detrás de esta
afirmación está relacionado con el hecho de que la atenuación de las señales de radio
es al menos cuadrática, en la mayoría de los ambientes (usualmente es mayor), por lo
que utilizar repetidores consume menos energía que la que requeriría una comunicación
directa.
Debe señalarse que las WSN operan en el paradigma de store and forward (almacena
y reexpide)1 . En este modelo, un nodo debe recibir correctamente un paquete de datos
antes de poder retransmitirlo. Alternativamente, aproximaciones novedosas incluso in-
tentan aprovechar la recepción de paquetes con error, en dónde múltiples nodos envían
el mismo paquete y cada transmisión individual no puede ser recibida, pero colectiva-
mente, un nodo puede reconstruir el paquete original con partes de las transmisiones.
1
Es una técnica en telecomunicaciones en la cual información es enviada a una estación intermedia
dónde es retenida para ser reenviada con posterioridad a la estación final o a otra estación intermedia.
La estación intermedia o nodo, en un contexto de red, verifica la integridad del mensaje antes de hacer
su reenvío. En general, esta técnica es utilizada en redes con intermitencia en la conexión, es especial
en sitios agrestes o bien con alta movilidad. También es preferida en situaciones en dónde se presentan
grandes retrasos en la transmisión, dónde la transmisión es variable, tiene alta tasa de errors o bien si
una conexión punto a punto no es viable [50].
Estas técnicas de repetición cooperativa no son aún consideradas en los esquemas de

operación de las WSN y son tema de investigación futura.
Si bien se ha hablado de redes con una sola fuente y sumidero, la realidad es que
en muchos casos prácticos se requiere de más de uno de ellos, este es el escenario más
complicado para una WSN, ya que la información muchas veces debe alcanzar un sumi-
dero o todos al mismo tiempo, y las fuentes pueden ser una o todas al mismo tiempo.
Algunas de estas combinaciones se muestran en la Figura 2.3.
Figura 2.3: Múltiples fuentes y/o múltiples sumideros. Note cómo, en el escenario de
la mitad baja, ambos sumideros y fuentes activas son utilizados para enrutar datos a
ambos extremos de la red.
2.3. Movilidad
En los escenarios mencionados todos los participantes son estacionarios. Pero una de
las virtudes de la comunicación inalámbrica es su habilidad para soportar participantes
móviles. En las WSN dicha movilidad puede aparecer de tres formas:
2.4. SEGURIDAD 23
1. Movilidad del nodo. La movilidad del nodo depende de la aplicación, por ejemplo,
en control ambiental la movilidad es nula; pero en la observación de fauna silvestre
es la regla común.
2. Movilidad del sumidero. Aunque esto puede ser considerado como un caso especial
de movilidad de nodo, el aspecto importante a tomar en cuenta es que el sumidero
puede no ser parte de la red de sensores, por ejemplo, la solicitud de una per-
sona con un dispositivo de mano caminando por un edificio inteligente. En el caso
más simple, el solicitante puede interactuar con la WSN en un punto y completar
su interacción antes de moverse. En muchos casos, las interacciones consecutivas
pueden tratarse por separado, como peticiones sin relación. Dónde el solicitante
de información puede tener interacción con todos los nodos y no solamente con
algunos de ellos, lo cual constituye una selección de diseño en las capas de los
protocolos de comunicación. Un sumidero móvil resulta particularmente intere-
sante, sin embargo, si la información solicitada no se encuentra de manera local
debe ser recuperada de alguna estación remota de la red. Si el solicitante tiene la
limitante de únicamente comunicarse con los nodos a su alcance, quizá se tendría
que desplazar a otro punto para tener acceso a los datos solicitados. Una red en-
tonces podría ser diseñada para ofrecer asistencia a los solicitantes móviles de tal
manera que sus solicitudes de datos los siguieran y alcanzaran sin importar sus
movimientos.
3. Movilidad de los eventos. En aplicaciones de detección de eventos y en particular

en aplicaciones de rastreo, la causa de los eventos o el rastreo es móvil. En estos
escenarios, es importante que el evento sea monitoreado por un número suficiente
de sensores todo el tiempo. Dado que los sensores “despertarán” con el evento,
entrarán en una fase de alta actividad durante el mismo y luego regresarán a su
letargo. Conforme el evento se desplaza en la red, este es acompañado por un área
de actividad. Esto ha sido llamado modelo frisbee y se muestra en la Figura 2.4. En
esta figura, la línea indica la trayectoria del elefante; las elipses el área de actividad
que sigue o precede al elefante.
El diseño de una WSN y por ende su arquitectura debe brindar soporte apropiado
para la aplicación específica en la cual será utilizada ya que está determinará la forma o
formas de movilidad que pueden darse. Si bien la movilidad de eventos es menos común,
no resulta ajena a muchas aplicaciones básica como los sistemas físicos de detección de
intrusos o de presencia.
2.4. Seguridad
2.4.1. Metas
Dado que las WSN pueden ser instaladas en diferentes ambientes, la seguridad es
un asunto importante que debe ser atendido; para que éstas funcionen adecuadamente,
Figura 2.4: Área de nodos sensores detectando un evento (elefante) que se mueve a través
de la red.
sobre todo en ambientes hostiles como campos de batalla o incluso en aplicaciones del
hogar [51]. Sin importar la aplicación, cuando se habla de seguridad, usualmente se
tienen que cumplir las siguientes metas u objetivos:
Confidencialidad o privacidad. Asegurar que solamente nodos autorizados puedan

tener acceso a datos o a la red. Esto es, mantener la información fuera del alcance
de personas o equipos no autorizados.
Integridad. Asegurar que solamente nodos autorizados pueden modificar datos y

que los mismos no son alterados durante su transmisión.
Autenticación. Asegurar que los datos son enviados realmente por el que reclama
ser el autor.
Disponibilidad. Asegurar la entrega confiable de datos en contra de ataques o

ambientes de negación del servicio.
Actualización. Asegurar que los datos son actualizados y válidos, y no inyectados

por un adversario.
2.4. SEGURIDAD 25
2.4.2. Modelo de seguridad por capas en la WSN

Las metas de la seguridad en las WSN son puestas a prueba en la vida real, ya
que no son fáciles de implementar, dadas las características limitadas de los MOTE, de
dónde son tomadas algunas de sus vulnerabilidades para establecer ataques contra ellos.
Por ejemplo, los “escuchas”, que son ataques pasivos2 , son más fáciles de implementar
en ambientes inalámbricos que en sus pares alámbricos. En las WSN, un adversario
puede obtener información monitoreando las transmisiones entre sensores. Aunque en
este ataque solamente la confidencialidad de los datos es comprometida y se puede
resolver mediante algún esquema de encripción, las soluciones para ataques activos no
son tan fáciles de implementar en las WSN. Los nodos de la WSN pueden comprometerse
ya que pueden ser fácilmente capturados por algún adversario, por lo que la WSN debe
estar preparada para excluir los nodos comprometidos y actualizar su arquitectura de
acuerdo con los cambios.
Así como el retiro de un nodo es viable, aún lo es más la incorporación de nodos
maliciosos. En este caso la autenticación puede ser utilizada contra este tipo de ataques,
pero no en todos los casos. En resumen, al explotar las vulnerabilidades en las diferen-
tes capas del protocolo de red, un adversario puede ejecutar una serie de ataques que
permiten, desde disminuir las funciones y capacidades de las WSN, hasta eliminarlas
por completo. Así como existen vulnerabilidades en cada capa del protocolo, también se
puede implementar una estrategia de contramedidas que constituyen las defensas de la
seguridad. Estas pueden ser presentadas en el modelo de seguridad relativa a las WSN
que se muestra en la Figura 2.5.
Pila del protocolo

Contramedidas
de las WSN
Autenticación
Detección de Intrusos
Capa de
Aplicaciones Agregación segura
Capa de Red Ruteo seguro
Localización segura de la información,

LLC sincronización de tiempos
MAC Manejo y establecimiento de llaves
Capa Física Espectro disperso
Figura 2.5: Pila del protocolo en las WSN y las defensas de su seguridad.
La columna izquierda de la Figura 2.5 está organizada de acuerdo con la estructura

2
Un ataque pasivo lo constituye el escuchar o monitorear una transmisión. El objetivo del adversario
es obtener información que es transmitida. Existen dos tipos: enfocados al mensaje y centrados en el
análisis de tráfico [52].
del modelo de referencia OSI3 , en ella se establecen las diferentes capas o niveles que
intervienen en la comunicación de las WSN. En la columna derecha se presentan las
contramedidas que se pueden establecer para evitar ataques en cada una de las capas.
Todo ello relacionado con dos objetivos principales, preservar la autenticación y detectar
intrusiones.
Independientemente de los ataques que se puedan realizar al protocolo criptográfico,
se pueden ejecutar ataques a la infraestructura, como se puede observar en la Figura 2.5,
por ejemplo, en la capa física se puede efectuar el jamming (boqueo o interferencias),
el atacante simplemente distorsiona la comunicación de radiofrecuencia. Una forma de
hacerlo es colocando nodos sensores cerca de los nodos de la red que transmitirán con-
tinuamente señales de radio en la frecuencia de radio de la red. Especialmente cerca
del nodo llamado sink o sumidero, afectando la comunicación con los nodos sensores de
la red. Para evitar esto es posible usar esquemas de modulación robustos a las interfe-
rencias, por ejemplo técnicas de frequency hopping o direct-sequence spread spectrum
[54, 55, 56].
En la capa MAC (Medium Access Control), un ataque puede tomar conocimiento de
la cantidad de energía para perturbar los protocolos de la capa de enlace, especialmente
los protocolos MAC, sobre todo en los basados en paquetes RTS/CTS tales como los
protocolos PAMAS y S-MAC. Siempre que el nodo reciba un RTS proveniente de un nodo
, puede responder el atacante con una señal para interferir cualquier CTS que pueda
enviar el nodo . Como consecuencia  no tiene oportunidad de transmitir. En general
no hay una medida efectiva contra este tipo de ataques. El atacante puede explorar los
protocolos MAC para preservar la energía [57, 58].
La capa de red no es ajena a ataques, existen diversos tipos que se describen a
continuación [59, 60]: 1) Ataque a un nodo de salida. Se presenta cuando un nodo, que
sirve como intermediario o como punto de colección o agregación, deja de funcionar
por causa de un ataque malicioso. 2) Corrupción de mensajes. Los ataques contra la
integridad de un mensaje ocurren cuando un intruso se inserta entre el origen y el
destino para modificar el contenido de un mensaje. 3) Negación de servicio. Este tipo
de ataque puede presentar las siguientes formas: ataque por interferencia en el enlace de
radio o puede tratar de agotar los recursos para que el nodo pierda la ruta de los datos.
En [61] se identifica algunos ataques DoS que incluyen los ataques denominados “el hoyo
negro”, “agotamiento de recursos”, “hoyos sumidero”, “introducción de loops de ruteo”,
“hoyos de gusano”, e “inundación de mensajes HELLO” que son utilizados para atacar
los protocolos de ruteo. 4) Análisis de tráfico. Aunque las comunicaciones pueden ser
encriptadas, en un análisis de causa y efecto, los patrones de tráfico y la actividad de
los sensores pueden revelar información útil para el adversario o para destruir la misión
de la red. La transmisión de direccionamiento y ruteo en claro puede ayudar al análisis
de tráfico. El análisis de tráfico es el término que se refiere a las capturas y análisis del
3
El modelo de referencia de Interconexión de Sistemas Abiertos (Open System Interconnection, OSI)
lanzado en 1984 fue el modelo de red descriptivo creado por la International Standard Organization;
esto es, un marco de referencia para la definición de arquitecturas de interconexión de sistemas de
comunicaciones [53].
2.4. SEGURIDAD 27
tráfico encriptado transmitido en la red.
2.4.3. Autenticación de nodos

El término autenticación se ha definido y tratado de manera extensa en el primer
capítulo de este trabajo, pero no el cómo proveerla. Las técnicas de autenticación tienen
el propósito de permitirle a la primera parte de sistema (el verificador, un FFD) asegurar
que la identidad de la contraparte (el demandante o RFD) es la declarada, lo que evitaría
la falsificación de la identidad. La técnica más utilizada por el verificador es checar que
un mensaje sea correcto (probablemente en respuesta de un mensaje previo) con lo cual
se demuestra que el demandante estaría en posesión de un secreto asociado a un nodo
legal. Esta técnica es conocida con nombres como identificación, autenticación de nodos,
y menos frecuentemente, verificación de identidad.
Los elementos básicos en un protocolo de autenticación involucran al demandante,
emisor o remitente (A) y al verificador o destinatario (B). El verificador es presentado o
conoce de antemano, la supuesta identidad del demandante. El objetivo es el corroborar
que la identidad del demandante está asociada a A, para poder proveer la autenticación
del nodo. En este sentido, la definición de la autenticación de nodo es la del proceso
mediante el cual una parte del sistema se asegura (a través de la adquisición de evidencia
corroborativa) de la identidad de la contraparte participante en el protocolo , y de
que la contraparte realmente ha participado en él. Es importante mencionar que la
identificación y la autenticación de un nodo son usadas como sinónimos.
2.4.4. Primitivas
Desde el punto de vista del verificador, la salida de un protocolo4 de autenticación
es la aceptación de la identidad del demandante, o bien la terminación sin aceptación
(repudio). Más específicamente, los objetivos de un protocolo de identificación incluyen:
1) En caso de contrapartes honestas A y B; A es capaz de autenticarse exitosamente
ante B, B completará en protocolo aceptando la identidad de A. 2) B no puede reutilizar
un intercambio de identificación con A para tratar de identificar a un tercero C, esto
1
es llamado transferibilidad. 3) La probabilidad es mínima, como máximo 280 cuando se
trabaja con la función Hash-SHA, de que una contraparte C distinta de A, ejecutando el
protocolo y tomando el papel de A pueda causar que B complete y acepte la identidad
de A, esto es llamado falsificación de identidad. Sin importar el número de procesos de
autenticación llevados a cabo, los puntos previos deben conservarse como verdaderos en
todo momento. Esto puede observarse en la Figura 2.6.
4
Conjunto de reglas que especifican el intercambio de datos u órdenes durante la comunicación entre
sistemas [8].
A B A B C B
A A A
Llave de A Llave de C Llave de A
Caso 1 Caso 2 Caso 3
Figura 2.6: Objetivos del protocolo de autenticación.
2.4.5. Métodos
Los mecanismos o métodos de autenticación utilizados pudieran ser considerados co-
mo inadecuados desde el punto de vista de la seguridad informática en la actualidad.
Sin embargo, son necesarios para poder entender métodos de autenticación más sofistica-
dos como el protocolo de autenticación extensible (Extensible Authentication Protocol,
EAP), especialmente porque éste fue originalmente diseñado como una extensión de los
métodos básicos.
De acuerdo con [51] por mucho tiempo los usuarios han obtenido acceso a redes
mediante conexiones alámbricas dónde se utilizan servicios de marcado hacia los mo-
duladores demoduladores (modem) de los proveedores de servicio. La mayor parte de
estos servicios utilizan un Point-to-Point Protocol (PPP) que fue diseñado para proveer
una serie de funcionalidades en la capa de enlace del modelo de referencia OSI. En
este protocolo se aceptan varios métodos de autenticación, principalmente el Password
Authentication Protocol (PAP) y el Challenge Handshake Protocol (CHAP).
Un método de autenticación muy popular surgido del mundo de la telefonía celular
(GSM) es el Subscriber Identity Module (SIM). El SIM es una tarjeta inteligente de
hardware que es configurada para la identidad específica de un subscriptor y la cual es
insertada en el aparato celular.
Más recientemente, se ha compensado a utilizar la infraestructura de llave pública
(Public Key Infraestructure), la cual puede autenticar tanto mensajes como usuarios.
Dentro de los métodos criptográficos, también encontramos a las firmas digitales, los
certificados y las funciones Hash.
2.4.6. Evaluación
Los métodos mencionados evalúan las credenciales presentadas de diversas formas
antes de autenticar usuarios, mensajes o dispositivos. En el PAP, un demandante pro-
porciona sus credenciales (usuario y palabra clave) hacia el verificador. El verificador
genera una solicitud de autenticación encapsulando las credenciales del usuario en un
marco del protocolo que tendrá como respuesta cualquiera de los estados ya mencionados
con anterioridad. Es importante mencionar que aunque las credenciales son encapsuladas,
la información esté en texto claro, es decir, sin protección alguna. Por ello algunos proto-
2.5. INFRAESTRUCTURA DE CLAVE PÚBLICA (PKI) 29
colos más recientes como Remote Access Dial-In User Service (RADIUS) protegen estos
datos ocultándolos. Para evitar el enviar información sensible sin protección, el protocolo
CHAP fue una respuesta inicial. En lugar de directamente preguntar por una palabra
clave, el servidor genera un valor aleatorio (el reto) y espera que el usuario provea una
respuesta al reto basado en su conocimiento de un secreto que ambos comparten. El
usuario toma el reto y usando la clave compartida calcula la respuesta. El verificador
realiza los mismos cálculos y compara los resultados, si ambos resultados concuerdan, el
usuario es autenticado. Ambos protocolos, PAP y CHAP, contrario a la creencia general,
son únicamente de autenticación y no contienen componente alguno de encripción.
Debido a la poca flexibilidad de PPP en los mecanismos de autenticación, se optó
por desarrollar el EAP. EAP da la posibilidad de elegir uno de los dos métodos de
autenticación (PAP o CHAP) así como los parámetros de autenticación, como la función
hash a utilizar, durante la fase de negociación del protocolo. Cuando EAP es utilizada,
esto se hace en la fase de autenticación del protocolo por lo que la autenticación real se
hace en sus fases posteriores.
Otro procedimiento es la autenticación basada en SIM, la cual está basada esen-
cialmente en mecanismos de reto/respuesta, la tarjeta SIM es presentada con un reto
aleatorio llamado RAND (128 Bits) por la parte verificadora. El procesador criptográfico
del SIM genera una respuesta denominada (SRES) basada en un algoritmo específico
y una llave  que está grabada en su memoria. El servidor de la parte verificadora
conserva una copia de la llave  y realiza la misma operación del , compara los
resultados con los de la  recibida del SIM para realizar la autenticación. Además
de la , la tarjeta produce una llave de encripción () que es utilizada para la
encripción del tráfico en el enlace inalámbrico, lo cual se puede expresar de la manera
siguiente:
[ ] =  ( ) (2.1)
La tripleta (  ) nos permite un método de autenticación que no sólo
sirve para el propósito inicial, sino que además provee de mecanismos de encriptación
y aunque es considerado como un método de autenticación de usuarios, en realidad es
un método de autenticación de dispositivos. Ya que la tarjeta SIM puede ser removida
del teléfono y ser usada por un usuario diferente, con las ventajas y desventajas que ello
pueda acarrear. La realidad en estos dispositivos es que aún contando con la posibilidad
de trabajar con una clave de usuario programada por el usuario para accesar los servi-
cios contratados, esta posibilidad es pocas veces utilizada. Se sustituye por mecanismos
dependientes del aparato telefónico que son fácilmente franqueables o simplemente no
se usan por considerarlos poco prácticos. En dispositivos limitados como los MOTE su
implantación es inviable, al menos en la actualidad.
2.5. Infraestructura de clave pública (PKI)

En criptografía, una PKI o infraestructura de clave pública, es una combinación de
hardware, software, políticas y procedimientos de seguridad que permiten la ejecución
de operaciones criptográficas como el cifrado, la firma digital o el no repudio de transac-

ciones electrónicas [62].
En [63], se menciona que la criptografía de llave pública surgió a mediados de la
década de 1970 con el trabajo publicado por Whitfield Diffie y Martin Hellman [64] y
separadamente por Ralph Merkle [65]. El concepto es simple y elegante, pero ha tenido
efectos profundos en la ciencia de la criptografía y en sus aplicaciones. La criptografía de
llave pública está basada en la noción de que las llaves de encripción vienen relacionadas
en pares, una pública otra privada. La llave privada se mantiene con el dueño de la
misma, mientras que la pública puede ser diseminada. La premisa en juego es que el
cálculo de la llave privada conociendo la llave pública no sea posible, de tal manera que
los mensajes encriptados con la llave pública únicamente puedan ser desencriptados con
la llave privada.
2.5.1. El problema de la factorización de números grandes

El principio de las funciones de una vía (one-way functions) está basado en la facilidad
de la multiplicación de dos números primos5 grandes; el proceso inverso, la factorización
de un número muy grande, es mucho más complejo. La factorización6 de números mayores
a 1024 bits es un problema cuya complejidad computacional es muy alta y que no puede
resolverse con los equipos y técnicas computacionales actuales. Con aritmética modular,
la multiplicación de este tipo de números se simplifica. Aunque existen varios métodos
para la generación de llaves públicas, en este trabajo nos centramos en el algoritmo
Rivest-Shamir-Adleman, conocido como RSA [66].
Si aleatoriamente elegimos dos números primos grandes  y  (de 100 a 200 dígitos
decimales). Calculamos el producto  = ×. Si ahora elegimos un número  que es primo
relativo con el producto de (−1)×( −1); por ejemplo, el máximo común divisor de  y
(−1)×( −1) es igual a 1. Calculamos () = (−1)×( −1) = +1−−. Podemos
usar el algoritmo extendido de Euclides [67] para calcular el inverso multiplicativo  de
  (). Los números  y  define la llave pública son conocidos como el exponente
y el módulo, respectivamente, mientras que  se convierte en la llave privada. Ambas
la encripción y la función inversa consisten simplemente de operaciones modulares de
reducción que mapean un elemento de  a otro elemento de , dónde 
es el conjunto de enteros módulo . Para cada bloque de texto claro  , las siguientes
ecuaciones aplican:
 = ( ) =   mod  (2.2)

 =  −1 () =   mod  (2.3)
El cálculo de ( ) y su inversa es optimizado al utilizar las técnicas de reducción mo-

dular, como la exponenciación por el método cuadrático repetido. Por ejemplo, en lugar
5
Un número primo es aquel que tiene solamente dos factores irreductibles, el mismo y 1 [63].
6
La factorización de un entero  significa encontrar una serie de factores primos cuyo producto sea
igual al valor de  [63].
de realizar siete multiplicaciones de una reducción modular grande, realizamos tres mul-
tiplicaciones más pequeñas y tres reducciones modulares simples, como se aprecia a
continuación:
8 mod  = ((2 mod )2 mod )2 mod  (2.4)
De lo anterior se deduce que “romper” el algoritmo RSA es equivalente a factorizar el

producto de dos números primos grandes.
2.5.2. Cálculo de logaritmos discretos en un campo finito grande.

La segunda facilidad que podemos encontrar en la teoría de números es la de calcular
una función  que consiste en elevar un número a una potencia en un campo7 finito
grande, sabiendo que la función  − 1, que implica el cálculo del logaritmo discreto en
ese campo, es mucho más difícil de calcular. Un campo finito, también conocido como
campo de Galois, con notación  (), es el campo de enteros módulo un número primo ,
en el que cada elemento del campo tiene garantizadamente un inverso multiplicativo que
está dentro del mismo. La complejidad en tiempo requerida para el cálculo de  () = 
en  es polinomial en  . Y calcular  =  −1 () =  (), dada , es un problema
más difícil de resolver al tratarse de logaritmos discretos. En este caso, ambas  e , están
condicionadas a ser elementos del conjunto discreto  en oposición a un problema
mucho más fácil de resolver en el conjunto continuo de los números reales. Un buen
número de algoritmos criptográficos de llave pública modernos están basados en estas
facilidades y propiedades. Como por ejemplo, y aún con su simplicidad, podemos ver
que en el algoritmo de El Gamal [69], el texto cifrado es muchas veces del doble del
tamaño del texto claro. Aquí la llave privada para decifrar, , es un número aleatorio
en un campo finito grande  () tal que 0     − 1. Similarmente, un segundo
número, , es seleccionado aleatoriamente en  (). La llave pública se obtiene de 
que tiene que estar en  (). Por lo que encriptar un texto claro  consiste entonces de
seleccionar un tercer número aleatorio  que es primo relativo a  − 1 y además calcular
el par: (1  2 ) = (    ). El proceso de desencripción de (1  2 ), es el cálculo de
 = 2 1 mod .
Hasta hace poco no era conocida otra fuente de funciones de una sola vía, pero
actualmente, las curvas elípticas sobre campos finitos han sido propuestas para su uso
en sistemas criptográficos de llave pública. Estas curvas proveen de una fuente natural
de componentes para el cálculo de llaves públicas o privadas que pueden ser utilizadas
en dichos sistemas [62].
7
Un campo consiste de un conjunto  y de dos operaciones suma:  + →  y producto:  × → 
tales que cumplen con las propiedades conmutativas, asociativas, inversos para la suma y el producto;
así como con el nulo aditivo y multiplicativo y adicionalmente con la distributividad del producto sobre
la suma [68].
2.5.3. La desaparición de la criptografía simétrica

La llegada de la criptografía de llave pública no significa el fin de la criptografía
de llave secreta o también llamada criptografía simétrica. Por el contrario, un método
criptográfico complementa al otro. Tanto la criptografía de llave pública como la de
llave secreta conforman muchos de los protocolos criptográficos en uso. Estos sistemas
criptográficos son denominados híbridos [70] Un sistema de llave pública puede ser uti-
lizado para la distribución de llaves secretas, las cuales pueden ser de largo término o
bien específicas para una sesión de comunicación. Con esta acción, la llave distribuida
de manera segura puede ser utilizada para encriptar y desencriptar la comunicación en
ambos extremos del protocolo de seguridad. La velocidad de procesamiento de la crip-
tografía de llave secreta con respecto de la de llave pública es aprovechada para este
proceso, mientras que la facilidad de distribución de llaves inherentes a la criptografía
de llave pública son algunas de las razones para la adopción de esquemas híbridos. Uno
de los más notables y elegantes de estos sistemas lo constituye el algoritmo de inter-
cambio de llaves de Diffie-Hellman [71], utilizado para el intercambio de llaves sobre
canales inseguros. Recientemente, la Internet Engineering Task Force (IETF) [72], ha
propuesto un algoritmo que provee prueba de la posesión de llaves privadas a los nodos
que utilizan el protocolo de acuerdo de Diffie-Hellman [73], lo cual refuerza el esquema
de autenticación durante los pasos del protocolo.
2.5.4. Estructura de PKI

En una operación criptográfica que use infraestructura PKI, intervienen conceptual-
mente como mínimo las siguientes partes:
Un usuario iniciador de la operación
La Certificate Authority (CA) o autoridad de certificación: es la encargada de

emitir y revocar certificados. Es la entidad de confianza que da legitimidad a la
relación de una clave pública con la identidad de un usuario o servicio.
La Registration Authority (RA) o autoridad de registro: es la responsable de ve-

rificar el enlace entre los certificados (concretamente, entre la clave pública del
certificado) y la identidad de sus titulares.
Los repositorios: son las estructuras encargadas de almacenar la información relati-

va a la PKI. Los dos repositorios más importantes son el repositorio de certificados
y el repositorio de listas de revocación de certificados. En una Certificate Revo-
cation List (CRL) o lista de revocación de certificados se incluyen todos aquellos
certificados que por algún motivo han dejado de ser válidos antes de la fecha es-
tablecida dentro del mismo certificado.
La Validation Authority (VA) o autoridad de validación: es la encargada de com-

probar la validez de los certificados digitales.
La TimeStamp Authority (TSA) o autoridad de sellado de tiempo: es la encar-

gada de firmar documentos con la finalidad de probar que existían antes de un
determinado instante de tiempo.
Los usuarios y entidades finales son aquellos que poseen un par de claves (pública
y privada) y un certificado asociado a su clave pública. Utilizan un conjunto de
aplicaciones que hacen uso de la tecnología PKI para validar firmar digitales, cifrar
documentos para otros usuarios, etc. [62].
Las operaciones criptográficas de clave pública, son procesos en los que se utilizan
algoritmos de cifrado que son conocidos y están accesibles para todos. Por este motivo la
seguridad que puede aportar la tecnología PKI está fuertemente ligada a la privacidad
de la llamada clave privada y los procedimientos operacionales o Políticas de seguridad
aplicados, ya que ni los algoritmos de cifrado más fuertes sirven de nada, si por ejemplo
una copia de la clave privada protegida por una tarjeta criptográfica (smart card) se
guarda en un disco duro convencional de una computadora conectada a Internet.
2.5.5. Consideraciones sobre PKI

Todo certificado válido, ha de ser emitido por una Autoridad de certificación re-
conocida, que garantiza la validez de la asociación entre el tenedor del certificado y
el certificado en sí. El poseedor de un certificado es responsable de la conservación y
custodia de la clave privada asociada al certificado para evitar el conocimiento de la
misma por terceros. Las entidades de registro se encargan de la verificación de la validez
y veracidad de los datos del que pide un certificado, y gestionan el ciclo de vida de las
peticiones hacia las AC. El poseedor de un certificado válido puede usar dicho certificado
para los usos que dieron origen a su creación, de acuerdo con las políticas de seguridad.
Toda operación que realice el poseedor de un certificado ha de realizarse de forma pre-
sencial por parte del poseedor del certificado y dentro del hardware de cliente ya sea la
tarjeta criptográfica u otro dispositivo seguro. Las comunicaciones con seguridad PKI
no requieren del intercambio de ningún tipo de clave secreta para su establecimiento,
por lo que se consideran muy seguras si se siguen las políticas de seguridad pertinentes.
Los elementos que intervienen en una PKI y sus interacciones e muestran en la Figura
2.7.
En la Figura 2.7, un usuario solicita un certificado con su llave pública a la autoridad
de registro (RA). Esta confirma la identidad del usuario con la autoridad de certificación
(CA) y ésta última después de validar los datos expide un certificado. El usuario ahora
está en la posibilidad de firmar contratos usando su nuevo certificado. En el momento
en que establece una transacción, su identidad es verificada por la contraparte con la
autoridad de validación (VA), la cual recibe información sobre los certificados de la
autoridad certificadora.
Figura 2.7: Proceso transaccional con PKI.
2.5.6. Esquemas criptográficos de clave pública

Para propósitos de este trabajo nos ocuparemos de la autenticación que emplea
métodos criptográficos, especialmente los de llave pública.
El desarrollo de la criptografía de llave pública es una verdadera aportación a la
revolución que ha tenido la criptografía, desde sus inicios a la fecha actual. Antes de
ella, todos los sistemas criptográficos se basaban en herramientas simples de sustitución,
permutación y XOR. La criptografía de llave pública también se basa en la teoría de
números y de la información, pero es asimétrica; lo que significa que se usan dos llaves
o claves por separado.
Los algoritmos asimétricos se basan en el uso de dos llaves, una para encriptar y otra
diferente, pero relacionada, para decriptar. Tienen la particularidad de que no se puede
determinar computacionalmente la llave de desencripción aún teniendo conocimiento del
algoritmo de encripción y de la llave de encripción. En algunos casos, las llaves pueden
ser usadas de manera alternada para encripción y decripción.
Todo esquema de llave pública o asimétrico tiene seis elementos esenciales [52]: Texto
plano, que es el mensaje en formato legible o bien los datos que serán alimentados al
algoritmo de encripción como entrada. El algoritmo de encripción, que es quién hace
las transformaciones del texto plano. Las llaves públicas y privadas, que son el par de
llaves que han sido seleccionadas, una para la encripción y otra para la desencripción. La
Llave pública Llave privada
Entrada Texto Cifrado Salida

Texto Claro Texto Claro
Llave privada Llave pública

Llave pública Llave pública

Llave privada Llave privada

Figura 2.8: Llaves públicas y privadas.
transformación exacta de los datos alimentados dependerá de la llave utilizada. El texto

cifrado, es el mensaje producido como salida después de la transformación, depende de la
llave y del texto plano. Finalmente, El algoritmo de desencripción, este algoritmo acepta
el texto cifrado y con la llave alterna a la usada al proceso de encripción reproduce el texto
plano original. Las posibles combinaciones y los resultados del proceso son mostrados en
la Figura 2.8
El proceso en detalle del envío de mensajes con el uso de una PKI se puede observar
en la Figura 2.9, en dónde se puede observar la intervención de las autoridades que
forman parte de la infraestructura básica de PKI.
2.5.7. Métodos de generación de claves

Los métodos de generación de claves son utilizados para establecer las llaves que
usarán los pares en su comunicación. Se generan llaves para el transporte8 , acuerdo9 y
se pueden también crear llaves de manera manual [51].
Durante la distribución de las llaves, éstas deben ser protegidas durante el proceso,
lo cual significa que las claves deben viajar encriptadas para proteger la integridad
y la confidencialidad. La integridad de las llaves puede ser obtenida mediante el uso
8
La llave de transporte es aquella utilizada en el proceso de distribución de la o las llaves de un nodo
a otra mediante el uso de algún protocolo de comunicación [51].
9
En las llaves de acuerdo, el material asociado y las mismas son generados en ambos extremos
(remitente—destinatario) y transportados de manera segura [51].
1 2 3 4 5 6
A crea un mensaje A encripta el A envía el mensaje B recupera el mensaje B desencripta el mensaje B lee el mensaje
para B mensaje con la (SMTP, X.400,etc.) (SMTP, X.400,etc.) de A con su propia llave
llave pública de B privada
n S
o h u e
J
ll
Bi
RED
Para: B Para: B
Paso 2: PROCEDIMIENTO TRANSPARENTE Paso 5: PROCEDIMIENTO TRANSPARENTE
A B C D A B C Llave pública
Sellado del A firma el Se comprime el Encripción del Decompresión Se examina el sello B verifica la firma
mensaje mensaje con su mensaje mensaje con una del mensaje para verificar la de A con la llave
(MD5,SHA1) llave privada (Zip, Rar) llave de sesión (Unzip) integridad del pública de A
(RSA,DSA) aleatoria (IDEA, CAST, mensaje (RSA,DSA)
Triple DES) y la llave (MD5,SHA1) Llave privada
pública de B
(RSA, Diffie-Hellman)
Figura 2.9: Envío de mensajes con PKI.
de firmas digitales, o bien los métodos de encripción simétricos y asimétricos pueden

ser utilizados para la encripción de las llaves: En el caso de los métodos simétricos,
estos son denominados métodos de empaquetamiento, los cuales utilizan una llave de
encripción que debe ser conocida por ambas partes. Si se usan métodos asimétricos,
el transmisor encripta la llave con el uso de la llave pública recibida, mientras que el
receptor hace el proceso contrario, pero con la llave privada asociada. Otro método para
proveer confidencialidad a las llaves es dividirla en varios componentes y manipular cada
uno de ellos de manera independiente. Algunos componentes pueden ser transportados
sin encripción y otros deben ser transportados encriptados, dependiendo de su valor
criptográfico. Las llaves son derivadas de cada elemento combinando los componentes
transportados con otra información secreta que cada elemento mantiene (usualmente
un secreto pre-compartido). De esta manera los materiales más sensibles nunca son
transportados por medio alguno, mientras que el resto del material clave puede ser
transportado por ambientes menos seguros sin esquemas de encripción muy fuertes.
El método de llave de acuerdo permite a ambas partes, remitente y destinatario,
participar en la creación del material clave compartido en un esquema punto-a-punto.
Quizá el método más famoso que usa esta técnica es el de Diffie-Hellman (DH) [64],
otro es el Internet Key Exchange (IKE)10 que está basado en los conceptos de DH. Sin
10
Internet key exchange (IKE) es un protocolo usado para establecer una Asociación de Seguridad
(SA) en el protocolo IPsec. Supone una alternativa al intercambio manual de claves. Su objetivo es la
negociación de una Asociación de Seguridad para IPsec. Permite, además, especificar el tiempo de vida
de la sesión IPsec, autenticación dinámica de otras máquinas, etc. [74].
importar el método utilizado, alguna forma de etiquetado de las llaves es necesaria para
guiar a las partes involucradas en el uso de las claves establecidas. Diferentes aplicaciones
podrían requerir diferentes etiquetas para el mismo tipo de llave.
Aunque los dos métodos previos usan métodos electrónicos de comunicación ya sea
para el transporte o el acuerdo de las llaves, no se puede garantizar que no existirá
la intervención manual de un administrador. Por ejemplo: Cuando se usa el método
de empaquetamiento de la llave, las partes deben de haber establecido un esquema de
confianza, ya que ambas comparten la llave del empaquetado. Esta llave de empaquetado
pudo haber sido establecida y almacenada en ambas máquinas por el administrador.
Cuando partes de las llaves son transportadas para que puedan ser combinadas con otros
secretos para generara las claves de sesión, esos “otros secretos” pueden ser secretos de
largo término establecidos por los administradores. Cuando los métodos DH e IKE son
usados alguna clase de autenticación es requerida entre las dos partes para asegurar
que ambas partes son quien dicen ser, de tal manera que las llaves se establezcan entre
pares legítimos. Esta autenticación es frecuentemente realizada sobre las bases de un
conocimiento previo pre establecido, esto se llama secreto pre compartido y algunas veces
es establecido por un administrador. La única forma de evitar cualquier establecimiento
manual de llaves es mediante el uso de llave pública en el método de llave de transporte.
El método más reconocido de distribución manual de llaves es la configuración de
palabras clave usadas para la autenticación de señales. Un usuario puede presentar su
palabra clave para su uso en PAP, o bien utilizar la palabra clave para generar la res-
puesta a un reto en CHAP.
La Figura 2.10 muestra la forma en que opera un sistema de encripción asimétri-
co con una administración de llaves centralizada o nodo certificador. En este caso, la
Figura 2.10(a) representa el modelo de encripción y la Figura 2.10(b) el proceso de
desencripción, orientado a la autenticación de la información.
2.5.8. Problemas de distribución de claves

Muchos de los mecanismos de encripción e incluso algunos de intercambio de llaves
se basan en secretos simétricos pre-compartidos [51]. El uso de llaves simétricas para el
establecimiento de relaciones de confianza introduce problemas serios de escalabilidad,
dado que se requiere que cada par en el sistema comparta un secreto único. En una
red consistente de  nodos, podríamos potencialmente estar manejando un orden 2 de
llaves [(2 )]. En redes numerosas, tal cantidad de llaves puede crear problemas serios
de administración. Por otra parte, el uso de pares de llaves pública-privada resuelve
muchos de los problemas de escalabilidad relacionados con la distribución manual de
secretos, pero no resuelven directamente otros problemas como la autenticidad de la
llave, la validez de la misma, etc.
De acuerdo con [63], si asumimos que un grupo de  personas decide establecer
comunicación a través de canales criptográficos basados en cifrado simétrico, se pueden
establecer diferentes escenarios para la distribución de llaves. En un primer escenario,
todos los miembros del grupo deciden compartir un solo secreto o llave, y usarla para
Llavero E
de B
D
Llave pública Llave privada

de A de A
Transmisión
cifrada
Entrada Salida
Texto Claro Algoritmo de Algoritmo de Texto Claro
encripción desencripción
a) Encripción
Llavero E
de A
D
Llave privada Llave pública

de B de B
Transmisión
cifrada
Entrada Salida
Algoritmo de Algoritmo de
encripción desencripción
b) Autenticación
Figura 2.10: Encripción asimétrica.
encriptar y decriptar todos los mensajes intercambiados. En este escenario básico, la

llave requiere ser distribuida  veces, y cada usuario requiere manejar una sola llave. El
problema se presenta cuando una falla en la secrecía de la llave se da, ya que todas las
comunicaciones entre el grupo están comprometidas.
En un segundo escenario, cada miembro del grupo decide mantener una llave secreta
por separado, pero necesita comunicarla a cada miembro del grupo para que sea útil.
Aquí, se requieren de ( − 1) distribuciones de la llave, y  llaves necesitan ser almace-
nadas y administradas por cada usuario. En este caso comprometer una llave, solamente
afectará las comunicaciones del dueño de dicha llave. En este escenario, un usuario po-
dría tomar la identidad de otro usuario, al contar con las llaves de todos los miembros del
grupo, lo cual genera un problema de seguridad. Para resolver este problema, cada par
de usuarios debe utilizar una llave diferente para comunicarse entre sí. En un escenario
en dónde cada par de miembros de la comunidad requieren de un canal de comunicación,
el grupo debe de distribuir (−1)2 llaves y cada miembro deberá de administrar −1
llaves. La Figura 2.11 ilustra tres variaciones en los patrones de comunicación que pueden
presentarse en un grupo de siete usuarios. Cada miembro del grupo está representado
por un nodo, mientras que las líneas representan la comunicación bidireccional entre los
miembros del grupo. Asumiendo que cada par de usuarios comparte una llave secreta
diferente, el número total de distribuciones de llaves en cada escenario es igual al número
de líneas en cada gráfica. Esto es, para la Fig. 2.11(a) se requiere la distribución de 7
llaves; en la Fig. 2.11(b) dónde los usuarios fueron seccionados en dos partes, se requiere
la distribución de 12 llaves; para el caso de un sistema máximo véase la Fig. 2.11(c), en
donde cada miembro del grupo requiere comunicación con todos los demás miembros, se
requiere la distribución de 21 llaves.
a b c
Figura 2.11: El número de distribuciones de llaves secretas está directamente relacionado

a los patrones de comunicación de los nodos.
Estos escenarios apuntan al hecho de que el número de distribuciones de llaves se-

cretas entre la población de usuarios de un grupo es incrementalmente proporcional
al número de líneas de comunicación entre los miembros. Adicionalmente, en el caso
de una renovación de llaves, el proceso de distribución debe ser replicado por comple-
to. Evidentemente, entre más frecuentemente se distribuya un secreto, esté se ve más
comprometido. Lo cual puede ocurrir durante la transmisión o cuando es almacenado
en algún medio. La distribución de llaves de larga duración o término va en contra de
las premisas manejadas en la criptografía de llave simétrica, por lo que la fortaleza del
sistema reside en la secrecía de la llave.
Los avances en los sistemas de software han mitigado el problema presentado por la
distribución de llaves secretas y su administración mediante la adopción de un reposito-
rio central de llaves, manejado por un solo servidor central, el Key Distribution Center
(KDC). Cada uno de los nodos divulga su llave secreta únicamente al KDC, resultando
en  distribuciones, dónde  es el tamaño de la comunidad involucrada. Sin embargo, la
sola presencia de la KDC no es suficiente para diseminar las llaves secretas entre la comu-
nidad de usuarios. Se requiere adicionalmente un protocolo de seguridad para establecer
la comunicación entre miembros. En este sentido, el esquema Needham-Schroeder [75]
presenta un método que resuelve esta problemática. La autenticidad y confidencialidad
de la comunicación se alcanza mediante el uso de una llave secreta temporal, generada
por el KDC. Esta llave aplica únicamente a la sesión activa y es compartida por los nodos
en comunicación. Algunos avances al esquema básico de Needham-Schroeder se presen-
tan en el esquema conocido como protocolo Kerberos [76], el cual ha probado ser uno de
los mejores protocolos de autenticación de terceros que se hayan desarrollado a la fecha.
La Figura 2.12 ilustra el concepto de un KDC confiable; el número de distribuciones de
llaves secretas es necesariamente igual al tamaño de la comunidad.
El problema de la distribución de llaves secretas no se circunscribe únicamente al
número de distribuciones de propagación; también requiere del uso de canales seguros
KDC
Figura 2.12: Un esquema centralizado de distribución de llaves.
para la distribución. Debido a la naturaleza recursiva del problema, los sistemas crip-
tográficos de llave secreta no pueden resolver este problema solos. Por lo que fue desa-
rrollada la PKI para atender esta problemática y otras adicionales.
2.5.9. Ataques
Al igual que en la encripción simétrica, la encripción de llave pública es vulnerable
a los ataques11 de fuerza bruta. La contramedida utilizada es la misma en ambos casos,
el uso de llaves grandes. Sin embargo, los sistemas de llave pública dependen del uso de
ciertas funciones matemáticas inversibles. La complejidad de cálculo de esas funciones no
debe escalar linealmente con respecto del número de bits de la llave sino más rápido. Por
lo que el tamaño de la llave debe ser lo suficientemente grande para hacer que un ataque
de fuerza bruta sea impráctico pero lo suficientemente pequeño para que la encripción
y decripción sea práctica. Otra forma de ataque es tratar de encontrar alguna forma de
calcular la llave privada una vez obtenida la llave pública. A la fecha, no ha sido probado
matemáticamente que esta forma de ataque no sea factible para algún algoritmo de llave
pública, por lo que todos ellos pueden ser objeto de intentos. La historia del criptoanálisis
ha mostrado que un problema que parece irresoluble desde una perspectiva, puede tener
una solución si se ve de una manera totalmente diferente. Finalmente, existe una forma
de ataque particular de los sistemas de llave pública, el cual, en esencia, es un ataque de
mensaje probable. Supóngase que un mensaje que debe ser enviado consiste de una llave
de 56 bits. Un adversario podría encriptar todas las posibles llaves de 56 bits usando
la llave pública y con ello poder descubrir la llave encriptada al cotejar el texto cifrado
transmitido. En este caso, sin importar lo largo de la llave del esquema de llave pública,
el ataque se reduce a un ataque de fuerza bruta sobre una llave de 56 bits.
11
Un ataque es un asalto a la seguridad de un sistema que se deriva de una amenaza inteligente, la
cual es un intento deliberado (especialmente en el sentido de método o técnica) para evadir los servicios
de seguridad y/o violar las políticas de seguridad de un sistema [77].
2.5.10. Requisitos para la implementación en los MOTE

Para incluir las seguridad PKI en la WSN, es conveniente resaltar que existen limita-
ciones importantes en los MOTE debido al tipo de hardware y arquitectura de cómputo
que manejan. En general, este tipo de dispositivos no cuentan con grandes cantidades
de recursos como los equipos que accesan a ellos mediante compuertas o puentes entre
redes. Información detallada de las características de estos dispositivos se puede obtener
en el Apéndice A de este trabajo. Una muestra de esta información, con los dispositivos
más relevantes, para los objetivos de este trabajo, se muestra en la Figura 2.13.
Nombre CPU Memoria I/O Sensores Radio

Tmote 8Mhz Texas 10 K RAM y 49 K Humedad, temperatura y luz 250 kbps 2.4 GHzIEEE Chipcon
Instruments Flash 802.15.4
MSP430
microcontrolador
Btnode Atmel 64+180 K SRAM, UART, SPI, I2C, GPIO, ADC, Clock, Chipcon CC1000 en banda ISM
ATmega128L(AVR 128 K Flash ROM, Timer, LEDs Standard Molex 433‐915 MHz
RISC 8 MHz @ 8 4 K EEPROM 1.25mm Wire‐to‐Board and
MIPS) Hirose DF17 Board‐to‐Board
connectors
Mica2 Atmel Atmega 128L 4K RAM y 128K Conector de expansión 315, 433 ó 868/916Mhz
Flash transciever multicanal con 38
Kbps
MicaZ Atmel Atmega 128 4K RAM y 128K Conector de expansión Transciever 802.15.4/ZigBee
Flash de RF
Mica2Dot Atmel Atmega 128 4K RAM y 128K Conector de expansión Transciever 802.15.4/ZigBee
Flash de RF
Telos Motorola HCS08 4K RAM USB and Etherner 250Kbps 2.4 GHz para IEEE
802.15.4 y ZigBee
Ember node Atmel ATmega128L‐ 1 Inyector de corriente sobre EM2420 radio transciever
EM2420DK 8MI MCU Ethernet ZigBee e IEEE 802.15.4
compatible basado en CC2420
CC2430DB Texas Instruments 8K RAM y 128K Sensor de Luz CC2420 para IEEE 802.15.4 y

SoC CC2430 Flash Acelerómetro de dos ejes ZigBee 2.4 Ghz, 250 Kbps
Sensor de temperatura
Monitor de batería
Potenciómetro
Botón de presión y joystick
LEDs
Arduino Atmel Atmega 128 4K RAM y 128K Conector de expansión EM2420 radio transciever
Flash ZigBee e IEEE 802.15.4
compatible
Figura 2.13: Características generales de algunos MOTE.
Las condicionantes que determinan la selección del hardware son varias. El tipo de
aplicación, por ejemplo, determina el consumo de energía que tendrá el dispositivo, así
como su tiempo de procesamiento de información. Otro punto determinante en extremo,
es la disponibilidad del dispositivo, es decir, la posibilidad de poder contar con él. Algunos
de los dispositivos relacionados en la tabla o en el Apéndice C, están a nivel de prototipo
o bien son propiedad de instituciones, por lo que no son de carácter comercial. Aún
en los de carácter comercial se tienen limitantes para su adquisición, desde problemas
de localidad, pasando por problemáticas de precio o bien de regulaciones en diferentes
países.
Estableciendo la diferencia entre dispositivos FFD y RFD, la selección de un hard-
ware debe ir encaminada hacia una familia de dispositivos que compartan no sólo su
arquitectura, si no que adicionalmente permitan esta flexibilidad de agregar o retirar
componentes, o al menos tener la posibilidad de inhabilitarlos para que no consuman
recursos de ella.
La complejidad del cálculo de las llaves utilizadas en los esquemas de llave pública y
la necesidad de una distribución eficiente de las llaves, así como su resguardo son tareas
que podrían estar al alcance de las capacidades actuales de los dispositivos mostrados
en la Tabla 2. Sin embargo, el tiempo de cálculo y el consume de recursos de energía que
son dos bienes preciados para funciones operativas se verían afectados, para descargar
el trabajo de cálculo de los MOTE, las WSN basadas en EB resuelven muchas de las
limitaciones que pudiera presentar el cálculo de las claves y la generación y distribución
de los certificados. La EB puede verse entonces como una AC.
Capítulo 3
Protocolo de autenticación de nodos
El presente capítulo tiene por objetivo presentar los componentes que serán utilizados
para la construcción de la propuesta de protocolo discutida en el capítulo siguiente.
Durante el desarrollo del capítulo 3 se presentan los algoritmos que serán utilizados, así
como la arquitectura de los dispositivos seleccionados y algunas de las interacciones que
se establecerán entre ellos.
3.1. Requisitos de diseño

Con base en un estudio previo de los dispositivos MOTE disponibles en el mercado, el
cual se realizó para fundamentar el protocolo de tesis, y de acuerdo con las características
técnicas reportadas en el mismo, se decidió que para el desarrollo del presente trabajo
se utilizarían los dispositivos de la marca Texas Instruments, específicamente los de la
familia CC2430 y CC2431.
Los dispositivos CC2430 y CC2431 son del tipo System on a Chip (SoC), es decir,
tienen todos los elementos requeridos integrados en él. Los elementos de la arquitectura
básica de un MOTE se pueden observar en la Figura 3.1.
Sistema de Sistema de
localización movilización
MOTE
Memoria
CPU
FLASH
Comunicación Transmisor/
de datos Receptor
Sensor
Dispositivo Unidad de potencia

CA/D
sensor
Fuente de energía
Figura 3.1: Arquitectura de un MOTE.
43
44 CAPÍTULO 3. PROTOCOLO DE AUTENTICACIÓN DE NODOS
La estructura del CC2430 y CC2431 se puede ver en la Figura 3.2.
WATCHDOG ON-CHIP VOLTAGE VDD (2.0-3.6 V)

DIGITAL RESET REGULATOR
TIMER DCOUPL
ANALOG
MIXED 32 Mhz HIGH SPEED RC- POWER ON RESET

CRYSTAL OSC OSC BROWN OUT
RESET_N 32.768 kHz 32 kHz RC-OSC SLEEP TIMER

CRYSTAL OSC
XOSC_Q2
XOSC_Q1 DEBUG CLOCK MUX & SLEEP MODE CONTROLLER
INTERFACE CALIBRATION
P2_4
P2_3
P2_2 32/64/128 KB
FLASH
P2_1
8051 CPU MEMORY
P2_0 DMA CORE ARBITRATOR
8 KB
P1_7 SRAM
P1_6
I/O CONTROLLER
P1_5
IRQ FLASH
P1_4 CTRL WRITE
P1_3
ADC AES
P1_2 AUDIO/DC ENCRIPTION RADIO REGITERS
8 CHANNELS &
P1_1 DECRIPTION
P1_0
CSMA/CA STROBE
PROCESSOR
P0_7
P0_6 USART 1 RADIO DATA INTERFACE
FIFO AND FRAME CONTROL

P0_5
P0_4
USART 2
P0_3 DEMODULADOR AGC MODULADOR
P0_2
P0_1 TIMER 1 (16-bit)
P0_0
TIMER 2
(IEEE 802.15.4 MAC TIMER)
SYNTHESIZER
FREQUENCY
RECEIVE TRANSMIT
CHAIN CHAIN
TIMER 3 (8-bit)
TIMER 4 (8-bit)
RF_P RF_N
Figura 3.2: Arquitectura del CC2430/31.
Con referencia al diagrama básico de un MOTE, en primera instancia, el diagrama

del dispositivo CC2430/31 [78] puede parecer mucho más complicado. Sin embargo, un
análisis rápido sobre el diagrama de la Fig.3.2 nos muestra que contiene los elementos
básicos fácilmente identificables. El núcleo del mismo es el micro controlador 8051 de ba-
jo consumo de energía, el cual tiene acceso a un controlador y un arbitrador de memoria
que le permiten a la unidad central de proceso el acceso a tres niveles de memoria: Flash,
SRAM y Flash Write. La memoria Flash, que es la que se utiliza para la programación
del dispositivo, puede ser de 32, 64 ó 128 KB dependiendo del modelo del dispositivo.
La SRAM es de 8 KB y tiene una serie de sectores que suman 4 KB, ésta es la memoria
Flash Write, los cuales retienen información en cualquier estado del dispositivo. Existe
un controlador de estados; activo, transición y dormido con su propio temporizador.
En el rubro de comunicaciones, el dispositivo contiene varios bloques; el Universal Syn-
3.1. REQUISITOS DE DISEÑO 45
chronous Asynchronous Receiver/Transmitter (transmisor/receptor universal síncrono

y asíncrono o USART) para comunicación serial, el Carrier Sense Multiple Access with
Collision Avoidance (acceso múltiple por detección de portadora con evasión de colisiones
o CSMA/CA) para comunicaciones en red. Unido a este último, se localiza la sección de
radio frecuencia con el modulador/demodulador, el sintetizador de frecuencia, el trans-
misor y el receptor, todos trabajando en una frecuencia de 2.4 GHz. Adicionalmente,
el dispositivo contiene integrado un convertidor analógico digital de 12 bits y un co-
procesador de encripción/decripción que trabaja con el Advanced Encription Standard
(estándar avanzado de encripción o AES). Este dispositivo requiere una alimentación
de 2 a 3.6 V y contiene 21 puertos de entrada y salida programables, además de 3 adi-
cionales ya asignadas a procesos internos. Es un dispositivo de 16 bits que trabaja con
un oscilador de 32 MHz y transmite a una velocidad de 250 Kbps.
El dispositivo CC2430/31 tiene un bajo consumo de energía, lo cual es una carac-
terística deseada y buscada para los MOTE. Para el caso de la transmisión o recepción,
el dispositivo consume 27 , funcionando a su máxima frecuencia y potencia. Cuando
está en transición hacia o desde apagado, usa solamente 0.5  En modo de espera o
dormido consume 0.3 .
En el terreno lógico del dispositivo, el CC2430/31 tiene un conjunto de instruccio-
nes para el manejo del estándar IEEE 802.15.4 conocido como ZigBee. Este conjunto
de instrucciones permite implementar funciones relacionadas con redes de área perso-
nal con y sin infraestructura. El conjunto de instrucciones contiene funciones de ruteo,
diferenciación de dispositivos, etc. En términos generales, el conjunto de instrucciones
provisto, contiene todos los elementos requeridos para la implementación de redes bajo
el estándar ZigBee.
De acuerdo con [79] el estándar ZigBee puede ser localizado entre los protocolos de
comunicación inalámbrica como se muestra en la Figura 3.3.
El rango entre dispositivos ZigBee, de acuerdo con la definición en el estándar, está
en 100m, sin embargo, las redes pueden alcanzar grandes distancias debido al relevo que
se hace de dispositivo a dispositivo hasta alcanzar un nodo ruteador o coordinador. El
protocolo es considerado como económico en su implementación, puede manejar muy
poca energía, es relativamente seguro y es un estándar abierto, cuya limitación principal
es la baja velocidad de transmisión. Esta última apreciación, relacionada más con el
mundo de la informática, no es del todo válida al analizar que el protocolo fue definido
para un mundo diferente de necesidades, en dónde tener 250 Kbps disponibles puede
ser más que suficiente si se administran de manera inteligente. Por ejemplo, en [80] se
menciona que para el envío de voz sobre Protocolo de Internet (IP), éstas deben ser
codificadas, de acuerdo con los estándares del Sector de Normalización de las Teleco-
municaciones de la Unión Internacional de Telecomunicaciones (UIT-T). Para el caso
del G.722, el más demandante de la gama, la transferencia requerida es de 64 Kbps.
La cuarta parte de lo disponible en el protocolo ZigBee. Incluso, el envío de imágenes
optimizadas con la tasa de transferencia del protocolo es posible. Estas facilidades han
hecho que la industria electrónica de control y automatización esté muy interesada en
los desarrollos sobre este protocolo, y sobre el cual manejan que es “Control Inalámbrico
Rápido
Video
Datos
Transferencia máxima de datos

USB
inalámbrico
WiFi Voz
802.11
a/b/g/n
Celular
Bluetooth
802.15.1
ZigBee
802.15.4
Lento
Cerca Lejos
Rango
Figura 3.3: Comparación de tecnologías inalámbricas.
que Realmente Funciona”.

La trama de datos de Zigbee de acuerdo con [81] está conformada por diferentes
elementos que se pueden apreciar en la Fig. 3.4.
Octetos: 2 1 4 a 20 n 2
Número
Información de la
Subcapa Control
de marco
de
Secuencia dirección Carga de paga FCS
MAC de datos
MHR MSDU MFR

Octetos: 4 1 1 5 + (4 a 20) + n
Capa Secuencia
Delimitador
Longitud
Preámbulo
Inicio de
del marco MPDU
Física Marco
SHR PHR PSDU

11 + (4 a 20) + n
PPDU
Figura 3.4: Trama de datos ZigBee.
Está trama puede albergar hasta 104 bytes de información de datos, su tamaño
máximo es de 127 bytes. Tiene un número de secuencia para permitir el re ensamblado
y la retransmisión. Adicionalmente incluye una Frame Check Sequence (Secuencia de
Verificación de la Trama o FCS) la cual establece una estructura robusta para prevenir
errores en la transmisión. Para el caso de la trama de reconocimiento o aceptación de
3.1. REQUISITOS DE DISEÑO 47
datos, la Figura 3.5 muestra sus elementos básicos.
Octetos: 2 1 2
Número de
Control de
Subcapa marco
Secuencia FCS
de datos
MAC
MHR MFR
Octetos: 4 1 1 5
Capa Delimitador
Secuencia Longitud
Inicio de MPDU
Física Preámbulo del marco
Marco
SHR PHR PSDU
11
PPDU
Figura 3.5: Trama de reconocimiento ZigBee.
Esta trama tiene la posibilidad de retroalimentar información sobre la correcta re-

cepción de los datos, mediante el envío de un paquete pequeño de datos después de la
recepción y aprovechando el periodo de silencio especificado en la norma tras el evento
de transmisión.
Estas dos tramas básicas ZigBee son complementadas con una trama de comando
MAC y otra trama piloto. La trama MAC tiene por objetivo el control y la configuración
de los nodos, así como la formación de la red. Mientras que la trama piloto tiene por
objetivos direccionar a varios dispositivos para que envíen información, mantener a los
nodos sincronizados sin tener que “escuchar” permanente el canal y permitir la búsqueda
activa y pasiva de redes. La Figura 3.6 muestra la estructura de estas tramas.
Octetos: 2 1 4 a 20 1 n 2
Número
Información de la
Subcapa Control
de marco
de
Secuencia dirección
Tipo de
comando Carga de paga FCS
MAC de datos
MHR MSDU MFR

Octetos: 4 1 1 6 + (4 a 20) + n
Capa Secuencia
Delimitador
Longitud
Preámbulo
Inicio de
del marco MPDU
Física Marco
SHR PHR PSDU

12 + (4 a 20) + n
PPDU
Figura 3.6: Trama de comando MAC ZigBee.
Para poder establecer comunicación con el dispositivo físico y accesar el conjunto

de instrucciones se puede realizar de dos formas. Una de ella es mediante peticiones
Octetos: 2 1 4 a 10 2 k m n 2
Número Número
Información de la
Subcapa Control
de marco
de
Secuencia dirección
Control
de marco
de
Secuencia
Tipo de
comando Carga de paga FCS
MAC de datos de datos
MHR MSDU MFR
Octetos: 4 1 1 7 + (4 ó 10) + k + m + n
Capa Secuencia
Delimitador
Longitud
Preámbulo
Inicio de
del marco PSDU
Física Marco
SHR PHR MPDU

13 + (4 ó 10) + k + m + n
PPDU
Figura 3.7: Trama de comando MAC ZigBee (continuación).
entre dispositivos afines, es decir, un nodo solicita información o que se ejecute algún
comando y que los resultados le sean comunicados, aunque sea solo el acuse de recibido.
La segunda forma, es estableciendo una comunicación entre un dispositivo y un equipo
de cómputo, con lo cual, adicionalmente, se puede establecer comunicación con otros
nodos en la red.
3.2. Entidades participantes

En la Figura 3.8 se muestra el diagrama básico del sistema de autenticación de nodos
basado en la generación de certificados digitales. En este sistema interviene una EB, que
es la entidad cuya responsabilidad es cumplir varias funciones en el modelo. En primera
instancia, es la responsable de la generación de las llaves  y  de cada nodo y de su
resguardo. Como se puede observar, también almacena su propia dupla de llaves. Como
segunda función, la EB genera, revoca y administra en general los certificados requeridos,
cuya finalidad es garantizar a los nodos la autenticidad de las llaves públicas. Por último,
la EB tiene también la responsabilidad de firmar los certificados que genera, del tal forma
que éstos puedan cumplir con los esquemas de no repudio, en este caso, usará la firma
 para tal propósito.
Unida a la EB mediante conexiones seriales, se encuentra la compuerta o “gateway”
representado por la tarjeta de desarrollo (TD). La TD permite la programación y el
acceso a las funciones interconstruidas en el microcircuito seleccionado que es el CC2431.
Las características de este System on Chip (SoC) pueden ser consultadas a detalle en
el Apéndice C. Dado que la EB no cuenta con los componentes de hardware necesarios
para establecer la comunicación de manera directa con los nodos de la red, es por ello
que se requiere una compuerta.
Los nodos utilizados, cuentan con dos tarjetas interconectadas; una que provee de
energía y que al mismo tiempo permite la entrada de datos; la segunda tarjeta es de-
nominada módulo de evaluación, la cual contiene el SoC, la conexión para la antena y
3.3. NECESIDADES DE AUTENTICACIÓN 49

Llaves Nodos
(en1, dn1)
(en2, dn2)
(en3, dn3)
Certificados ... (en1, dn1)
Genera
Administra
Firmas Revoca n1
SEB Tarjeta de desarrollo (en2, dn2)
Certificados n2
(en3, d n3)
n3
(en4, d n4)
Estación Base
(eEB, d EB ) n4
(en5, d n5)
n5
Figura 3.8: Diagrama básico del sistema de autenticación.
los conectores que le permiten a la tarjeta su acoplamiento a la TD o bien al módulo de

evaluación, y en su caso, a desarrollos propios. Los nodos contendrán cada uno su dupla
de llaves, éstas estarán contenidas en la memoria del SoC en una zona de la memoria
que tiene la particularidad de no ser volátil en todos los estados del MOTE.
El protocolo de acuerdo o establecimiento de llave se seleccionará de acuerdo a la
complejidad computacional y a las limitaciones de hardware dónde será procesado. Los
protocolos disponibles se evaluarán de manera teórica, para posteriormente hacer la
selección de acuerdo con su implementación física en los MOTE y en la EB.
Dado el número y el tipo de funciones que son albergadas en la EB está en realidad
fungirá como autoridad certificadora para realizar las funciones de emisión, revocación
y administración de certificados y llaves.
Para propósitos de este trabajo la comunicación se establecerá siempre entre el nodo y
la EB o viceversa. Siendo no permitida la comunicación entre nodos, esto en el contexto
de una WSN celular. Lo cual generará un efecto ping-pong entre la EB y nodos en
comunicación. Por lo que la comunicación directa entre nodos queda fuera del alcance
de este trabajo.
3.3. Necesidades de autenticación

Una WSN, como toda red inalámbrica, es susceptible de ataques. Algunos de ellos
pueden ser minimizados en sus efectos con contramedidas adecuadas. Entre los ataques
que pueden presentarse en estas redes, uno de los más comunes es el de fuerza bruta,
en éste se intenta romper el esquema criptográfico intentando identificar la o las llaves
utilizadas por el mismo. Para evitar que el ataque tenga éxito, la defensa es el uso de
llaves criptográficas grandes. Sin embargo, como ya se explicó en el capítulo anterior,

esto representa una complicación para los esquemas criptográficos asimétricos, como el
que vamos a usar. Un conjunto de llaves criptográficas grande implica el uso de mayores
recursos de cómputo, los cuales no necesariamente están disponibles en los MOTE.
Dada esta circunstancia, es necesario realizar la mayor parte del trabajo en la EB y
luego comunicar los elementos necesarios a los MOTE de manera segura. Otro ataque es
la captura de nodo, en este caso, los MOTE son dispositivos que pueden ser fácilmente
retirados del contexto de la red, la captura de un nodo puede comprometer toda la
seguridad. Asegurar físicamente cada nodo de la red puede ser una tarea imposible, sobre
todo cuando una aplicación requiere de las cualidades móviles de los MOTE. Lo que si
puede hacerse es asegurar la información que manejan y los canales de transmisión,
a manera de que no proporcionen ninguna información o que aquella que pueda ser
obtenida no sea útil para identificar los protocolos utilizados y el modo en que han
sido integrados a la infraestructura de la red. Los ataques de negación de servicio son
también comunes en las redes inalámbricas. En [82] se menciona que la interferencia
entre señales de radio pueden originar suspensión del servicio de la red, aunque no de
manera intencional, es cierto que ambientes con mucha interferencia provocan este efecto
indeseado, las frecuencias asignadas al protocolo IEEE 802.15.4 se muestran en la Fig.
3.9.
# de Rx
Frecuencia Banda Cobertura Datos Canales Sensitividad Modulación
2.4 Ghz ISM Mundial 250kbps 16 -85dBm O-QPSK
868 Mhz Europa 20kbps 1 -92dBm BPSK
915 Mhz ISM América 40kbps 10 -92dBm BPSK
Figura 3.9: Frecuencias asignadas al protocolo ZigBee.
Los 16 canales de la banda ISM en 2.4 GHz, que es la banda más utilizada ac-
tualmente, están separados por 5 MHz entre cada uno de ellos y todos son altamente
tolerantes al ruido electromagnético, de hecho, el protocolo tiene el mejor comportamien-
to en entornos con baja Signal-Noise Ratio (Relación Señal-Ruido o SNR) como se puede
ver en la Figura 3.10.
Para evitar los ataques involuntarios de negación de servicio, el protocolo ZigBee,
como otras tecnologías inalámbricas debe dividir el ancho de banda disponible para ser
compartido entre todos los usuarios y señales, para lo cual se utilizan varios métodos
para la división de recursos: el Frequency Division Multiple Access (Acceso Múltiple por
División de Frecuencia o FDMA), el Time Division Multiple Access (Acceso Mútliple
3.3. NECESIDADES DE AUTENTICACIÓN 51
1E-0
Bluetooth
Tasa de bit de error (BER)

FSK
WiFi B
ZigBee
1E-9
-10 0 +15
Relación Señal-Ruido (SNR)
Figura 3.10: Gráfica de la relación señal-ruido para diferentes protocolos inalámbricos.
por División de Tiempo o TDMA), o el Code Division Multiple Access (Acceso Múltiple
por División de Código o CDMA) y dentro de este último una variación denominada
Direct Sequence Code Division Multiple Access (Acceso Múltiple por División de Código
de Secuencia Directa o DS-CDMA). Todos estos métodos de acceso múltiple tienen
ventajas y desventajas, por ello, el protocolo ZigBee utiliza la combinación de dos de
ellos, FDMA y DS-CDMA, obteniendo como consecuencia una mayor robustez ante el
ruido o interferencias como se puede ver en la Figura 3.11.
Interferencia Señal deseada
En el aire Después de la correlación DS
2.4 GHz Canales 11-26 5 MHz

Físico
2.4 GHz 2.4835 GHz
Canales 0-10 2 MHz
900 MHz
Físico
868.0 MHz 928.0 MHz
Figura 3.11: Aplicación del FDMA y DS-CDMA en el protocolo ZigBee.
Mediante estas definiciones, el protocolo es más resistente a ataques de negación

de servicio involuntarios. Sin embargo, un ataque premeditado puede inundar el canal
con señales que pueden evitar el envío o recepción de los mensajes de los nodos. Como
contramedida, se puede utilizar un canal alto de la especificación, ya que generalmente
las aplicaciones utilizan los canales bajos. En el mejor de los casos, se pueden programar
los dispositivos para hacer migraciones dinámicas de canal con confirmación hacia los
miembros autenticados de la red. De esta manera, ante la saturación de uno de los
canales, la red completa se movería de frecuencia y podría contrarrestar el ataque.
Como se puede observar, los beneficios de los esquemas de seguridad en las WSN
son amplios, en especial aquellos relacionado con la autenticación de los nodos. Una
infraestructura para la autenticación basada en PKI conlleva múltiples beneficios que
pueden ser utilizados para contrarrestar ataques como los mencionados y otros más.
3.4. Diseño del protocolo de acuerdo de la llave

Si no queremos, o no podemos, utilizar un servidor de llaves en línea, entonces estamos
forzados a utilizar un protocolo para el acuerdo o intercambio de llaves. En este trabajo,
para el diseño del protocolo de acuerdo de la llave nos basaremos en uno de los proto-
colos más utilizados y ampliamente difundidos, el Diffie-Hellman. Aunque existen varios
más como son ElGamal, el MTI (Matsumoto, Takashima, e Imai) con sus variaciones
A0/B0/C0/C1 y el protocolo estación a estación (STS), todos ellos son variaciones del
Diffie-Hellman e implican una mayor complejidad en su cálculo, por lo que requerirían
de mayor poder de cómputo y en consecuencia energía El protocolo no reside en una
sola entidad, pues las entidades (EB y los nodos) son responsables de su ejecución para
calcular la llave secreta. Esta llave secreta servirá para cifrar la llave privada que será
almacenada en los nodos, una vez que la EB la calcule. Los nodos deberán descifrar
con la llave secreta dicha llave cuando necesiten utilizarla para el proceso primario de
autenticación. En [83] se muestra que el protocolo de acuerdo de la llave está basado en
el denominado problema de Diffie-Helman, y que éste a su vez está relacionado con el
denominado problema del logaritmo discreto, los cuales son presentados en el Apéndice
A de este trabajo.
3.4.1. Protocolo Diffie-Hellman de acuerdo de la llave

Protocolo Diffie-Hellman de acuerdo de la llave (versión básica)
Resumen:  y  envían mensajes entre sí en un canal abierto.

Resultado: El secreto compartido  conocido por ambas partes  y .
1. Proceso único. Un número primo apropiado  y un generador  de

Z∗ (2 ≤  ≤  − 2) son seleccionados y publicados.
2. Se utilizan los mensajes del protocolo.
 →  :  mod  (3.1)
 ←  :  mod  (3.2)
3.4. DISEÑO DEL PROTOCOLO DE ACUERDO DE LA LLAVE 53
3. Acciones del protocolo. Realizar los siguientes pasos cada vez que una llave com-
partida es requerida.
a)  elige un secreto aleatorio , 1 ≤  ≤  − 2, y envía un mensaje a  con (3.1).
b)  elige un secreto aleatorio , 1 ≤  ≤  − 2, y envía un mensaje a  con (3.2).
c)  recibe  y calcula la llave compartida con  = ( ) mod .
d)  recibe  y calcula la llave compartida con  = ( ) mod .
Desafortunadamente para el protocolo, de acuerdo con [84], y aún siendo el más

simple de calcular, éste es vulnerable a ataques activos de “hombre en el medio” o
suplantación. Para hacerlo resistente a ataques se han integrado variaciones sobre el
mismo, como STS o MTI. El protocolo STS es denominado de 3 pasos, debido a que
requiere de cálculo y envío de al menos tres mensajes; mientras que MTI es un protocolo
de dos pasos; envía un mensaje de  a  y otro de  a .
Si asumimos que son conocidos el primo  y el generador o elemento primitivo .
Cada usuario  tiene una cadena identificadora (), un exponente secreto
 ; 0 ≤  ≤  − 2 y un valor público correspondiente:
 =  mod  (3.3)

La autoridad de confianza (Trusted Authority o TA) tiene un esquema de firma con
un algoritmo de verificación público   y un algoritmo de firma secreto   
Cada usuario  tendrá un certificado
( ) = (()     (( )  )) (3.4)

dónde  es calculado como se muestra en la ec. 3.3.
El protocolo MTI para el acuerdo de la llave es mostrado a continuación. Al final del
protocolo,  y  habrán calculado la misma llave.
 =   +  mod  (3.5)
3.4.2. Protocolo Matsumoto, Takashima, e Imai (MTI) de acuer-

do de la llave
Protocolo MTI de acuerdo de la llave
Resumen:  y  envían mensajes entre sí en un canal abierto.

Resultado: El secreto compartido  conocido por ambas partes  y  .
1. Proceso único. Un número primo apropiado  y un generador  de

Z∗ (2 ≤  ≤  − 2) son seleccionados y publicados. Se asigna a  un identificador
(),
se selecciona un exponente secreto  ; 0 ≤  ≤  − 2 y se publica  
2.  elige un número aleatorio  y calcula
 =  mod  (3.6)
3.  envía ( ) y  a  .
4.  elige un número aleatorio  y calcula
 =  mod  (3.7)
5.  envía ( ) y  a 
6.  calcula
 =   (  + ( )) mod  (3.8)

 calcula
 =   (  + ()) mod  (3.9)
Para ilustrar el funcionamiento del protocolo, suponga que  = 27803 y  = 5 los

cuales son públicos y conocidos. Asuma que  elige  = 21131; con lo que se puede
calcular
 = 521131 mod 27803 = 21420 (3.10)

información que será incorporada al certificado de . De la misma forma,  elige
 = 17555 con lo que se calcula
 = 517555 mod 27803 = 17100 (3.11)

esta información, también es incorporada al certificado de 
Si ahora suponemos que  elige  = 169; entonces podrá enviar el valor
 = 5169 mod 27803 = 6268 (3.12)

hacia  Suponga que  , elige por su parte  = 23456; con lo cual podrá enviar el
valor
3.4. DISEÑO DEL PROTOCOLO DE ACUERDO DE LA LLAVE 55
 = 523456 mod 27803 = 26759 (3.13)

hacia 
Ahora  puede calcular la llave
 =     mod  (3.14)

= 2675921131 17100169 mod 27803 (3.15)
= 21600 (3.16)
y  hará lo mismo
 =     mod  (3.17)

= 626817555 2142023456 mod 27803 (3.18)
= 21600 (3.19)
con lo que  y  han calculado la misma llave.

La información transmitida durante el protocolo se puede observar en la Figura 3.12.
U V
Figura 3.12: Mensajes del protocolo de acuerdo de la llave MTI.
Como podrá intuirse, el protocolo MTI tiene el mismo problema contra ataques
pasivos que el protocolo Diffie-Hellman. La problemática real para ambos protocolos es
la presencia de adversarios activos. Podemos considerar entonces la siguiente amenaza:
Sin el uso de firmas durante el protocolo, podría parecer que no existe protección contra
ataques de “hombre en el medio”. Por lo que sería factible que  pudiera alterar los
valores que se envían  y  Un escenario típico se muestra en la Figura 3.13.
En esta situación,  y  calcularán diferentes llaves:  calculará
0 
 =   + ´ 
mod  (3.20)
U W V
Figura 3.13: Escenario de ataque de “hombre en el medio” para el protocolo MTI.
mientras que  calculará

0
 = ´  +  
mod  (3.21)
Sin embargo, ninguno de los cálculos de las llaves de  y  puede ser ejecutado
por  , dado que se requiere del conocimiento de los exponentes secretos  y  ,
respectivamente. Aunque  y  hayan calculado llaves diferentes (las cuales les serán
inútiles), ninguna de ellas pueden ser calculadas por  (asumiendo la intratabilidad del
problema de los logaritmos discretos). En otras palabras, ambos  y  están asumiendo
que solamente hay un usuario en la red con la capacidad de calcular la misma llave. Esta
propiedad algunas veces es denominada autenticación implícita de la llave.
3.5. Generación de las llaves pública y privada

Para autenticar a los nodos con la estación base se empleará el algoritmo de R.
Rivest, A. Shamir, and L. Adleman (RSA), el cual deberá ejecutarse en la EB debido a
la complejidad computacional. Los nodos, aún teniendo procesadores de nueva genera-
ción, que tienen mayor capacidad de cómputo, emplearían demasiada energía en estos
procesos. Aún optimizando su programación, podríamos agotar la memoria que tienen.
Adicionalmente, si bien la programación de los dispositivos se realiza en lenguaje ANSI
C, muchas de las funciones complejas, requeridas para la implementación de los algo-
ritmos, deberían de ser desarrolladas y coexistir con las funciones del protocolo ZigBee,
abonando al problema del agotamiento de la memoria.
En [83] se menciona que el criptosistema RSA usa un módulo de la forma  = ,
donde  y  son números primos distintos. Los números primos  y  deben ser lo sufi-
cientemente grandes para que la factorización de su producto esté más allá de los límites
computacionales actuales, es decir, su orden computacional debe hacer impráctico el
intento de cálculo. Más aún, deben ser números primos aleatorios en el sentido de que
3.6. ALGORITMO DE ENCRIPCIÓN RSA 57
deben ser elegidos de una función con una entrada aleatoria a un proceso definido de
un conjunto de candidatos con cardinalidad suficiente tal que un ataque exhaustivo no
tenga éxito. En la práctica, los primos resultantes deben también ser de una longitud
determinada, para cumplir con especificaciones en los sistemas. La invención del cripto-
sistema RSA también añadió nuevas consideraciones y restricciones para la elección de
 y  para asegurar que RSA sea seguro ataques de criptoanálisis, de tal forma que la
noción de número primo fuerte fue definida. Es sabido que actualmente los números pri-
mos fuertes ofrecen un poco más de protección, comparada con la que ofrece la selección
aleatoria de números primos en la longitud requerida para su uso en RSA, los cuales
satisfacerán las restricciones con una alta probabilidad. Por otra parte, no son menos
seguros, y requieren de muy poco tiempo de cómputo adicional para su cálculo, por lo
que su uso implica muy poco esfuerzo adicional. La definición de número primo fuerte
se puede consultar en el Apéndice A de este trabajo.
3.6. Algoritmo de encripción RSA

Algoritmo para la generación de la llave pública de encripción RSA
Resumen: cada entidad crea una llave pública RSA y su correspondiente llave privada.
Cada entidad  debe realizar lo siguiente:
1. Generar dos números primos  y , cada uno del mismo tamaño. Preferentemente
grandes.
2. Calcular  =  y  = ( − 1)( − 1)
3. Seleccionar un número entero aleatorio , 1    , tal que ( ) = 1
4. Usar el algoritmo extendido de Euclides (ver Apéndice A) para calcular el entero

único , 1    , tal que  ≡ 1(mod )
5. La llave pública de  es ( ); y su llave privada es .
3.7. Definiciones
Los enteros  y  en la generación de llaves RSA son llamados exponente de encripción
y exponente de decripción, respectivamente; mientras que  es denominado módulo.
3.8. Algoritmo RSA de encripción con llave pública

Algoritmo RSA de encripción con llave pública
Resumen:  encripta un mensaje  de , el cual decriptará .

1. Encripción.  debe realizar lo siguiente:
a) Obtener la llave pública autentica de , ( )

b) Representar el mensaje como un entero  en el intervalo [0  − 1] 
c) Calcular  =  mod 
d) Enviar el texto cifrado  hacia 
2. Decripción. Para recuperar el texto plano  de ,  debe realizar lo siguiente:
a) Usar la llave privada  para recuperar  =  mod .
3.9. Prueba de que la decripción funciona

Dado que  ≡ 1(mod ), existe un entero , tal que  = 1+. Si el ( ) = 1,
entonces por el teorema de Fermat (ver Apéndice A);
−1 ≡ 1(mod ) (3.22)

Elevando ambos lados de la congruencia a la potencia ( − 1) y luego multiplicando
ambos lados por  resulta
1+(−1)(−1) ≡ (mod ) (3.23)

Por otra parte, si el ( ) = , esta última congruencia continúa válida dado
que cada lado es congruente con 0 módulo . Para todos los casos tenemos:
 ≡ (mod ) (3.24)

Por el mismo argumento:
 ≡ (mod ) (3.25)

Finalmente, dado que  y  son número primos distintos, se deduce que
 ≡ (mod ) (3.26)

por lo tanto
 ≡ ( ) ≡ (mod ) (3.27)

3.10. USO DEL RSA 59
3.10. Uso del RSA

Para la generación de la clave consideramos que  elige los números primos  = 2357
y  = 2551, y calcula el módulo  =  = 6012707 y  = ( − 1)( − 1) = 6007800.
 selecciona una  = 3674911 y usa el algoritmo extendido de Euclides para encontrar
 = 422191 tal que  ≡ 1(mod ). La llave pública de  es el par ( = 6012707
 = 3674911), mientras que la llave privada de  es  = 422191.
Para encriptar el mensaje  = 5234673,  usa el algoritmo de exponenciación mo-
dular para calcular
 =  mod  = 52346733674911 mod 6012707 = 3650502 (3.28)

y envía este resultado a .
Para decriptar ,  calcula
 mod  = 3650502422191 mod 6012707 = 5234673 (3.29)
3.11. Seguridad de RSA

La seguridad de RSA, como para cualquier otro protocolo criptográfico, es constan-
temente puesto a prueba con algunos ataques y criptoanálisis conocidos como los son:
la relación a la factorización, el exponente  de encripción pequeño, la búsqueda adelan-
tada, el exponente  de decripción pequeño, las propiedades multiplicativas, el módulo
común, los ataques cíclicos o la conciliación de mensajes. Una forma de fortalecer las
características del criptosistema y acelerar su cálculo es mediante el empleo de una serie
de prácticas comunes como lo son: la correcta elección del tamaño del módulo, la correcta
selección de los números primos, el uso de exponentes pequeños de encripción.
3.11.1. Correcta elección del tamaño del módulo.

Dados los avances en la factorización de enteros, un módulo  de 512 bits provee una
seguridad marginal para ataques. Para poder evitar el poder de los filtros cuadráticos o la
factorización algorítmica de un filtro en un campo numérico, técnicas disponibles desde
1996, es necesario utilizar al menos 768 bits en un módulo  para asegurar un esquema
con una seguridad más duradera contra ataques, la recomendación general es que a partir
de 1024 bits se garantiza una seguridad de largo término, dadas las condiciones de la
informática actual.
3.11.2. Selección de los números primos.

Los números primos  y  deben ser seleccionados para que la factorización de  =
 no sea posible. La mayor restricción para que  y  puedan evitar el algoritmo de
factorización de curva elíptica es que tanto  como  deben tener la misma longitud y
deben ser suficientemente grandes. Por ejemplo, si se utilizará un módulo  de 1024 bits,
 y  tienen que tener una longitud de 512 bits.
Otra de las restricciones para los números primos  y  es que la diferencia √−  no
debe ser muy pequeña. Si  −  es pequeña, entonces  ≈  y por lo tanto  ≈ . Ya
que,  podría ser factorizada eficientemente con una simple división de enteros nones
cercanos a la raíz . Si  y  son cercanas y aleatorias, entonces  −  tendrá la longitud
apropiada para evitar lo anterior.
Adicional a las restricciones ya mencionadas, algunos autores recomiendan que  y
 sean primos fuertes. Cada una de las condiciones expresadas tiene el propósito de
evitar el poder de métodos matemáticos desarrollados que pueden localizar los valores
utilizados, como lo son la factorización algorítmica de Pollard, la simple factorización
algorítmica o los ataques cíclicos. Como ya se ha mencionado, este tipo de números
agrega seguridad al sistema y solamente requiere de poco cálculo adicional.
3.11.3. Exponentes pequeños de encripción.

Aunque esto no añade complejidad, en realidad abona al acelerar el algoritmo, el cual
es considerado lento. Un número  pequeño y que además contenga la menor cantidad de
 en su representación binaria es la combinación ideal para acelerar el proceso. En la
práctica, un exponente de  = 3 es comúnmente utilizado, en este caso, es necesario que
 − 1 ó  − 1 no sean divisibles por 3. El resultado es encripción acelerada que requiere
de solo una multiplicación modular y una raíz cuadrada modular. Otro exponente 
utilizado comúnmente es  = 216 + 1 = 65537. Este número contiene solamente dos 1
en su representación binaria, y la encripción, usando el proceso repetitivo del algoritmo,
requiere de 16 raíces modulares y una multiplicación modular. Adicionalmente, este
exponente es más resistente a ataques que el anterior.
Para los nodos y la estación base se empleará el procedimiento RSA con el cual se
generarán las llaves públicas que servirán para cifrar los mensajes enviados en la red y la
llaves privadas que se usarán para descifrar dichos mensajes. Describir matemáticamente
el procedimiento (usar un diagrama general para ilustrar la base de datos de la EB y su
interacción con la red).
3.12. Estándar Avanzado de Encripción (AES)

De acuerdo con [85] los requerimientos especificados por el Intituto Nacional de Es-
tándares y Tecnología (National Institute of Standards and Technology o NIST) para la
sustitución del protocolo Estándar de Encripción de Datos (Data Encryption Standard
o DES) como estándar, dio origen a un cifrador de bloques denominado Estándar Avan-
zado de Encripción (Advanced Encription Standard o AES); del cual, se han manejado
diferentes versiones de acuerdo con la longitud del bloque que se utiliza, 128, 192 ó 256
bits. Estos son referidos como AES-128, AES-192 ó AES-256. En la Figura 3.14 se re-
sumen las características de las tres versiones oficiales de AES. En esta figura,  se
refiere a la longitud del bloque (total de palabras de 32 bits),  longitud de la llave
3.12. ESTÁNDAR AVANZADO DE ENCRIPCIÓN (AES) 61
(total en palabras de 32 bits) y  es el número de rondas. Note que en la versión oficial

de AES, todas las versiones trabajan con bloques de  · 32 = 4 · 32 = 128 
Nb Nk N
AES-128 4 4 10
AES-196 4 6 12
AES-256 4 8 14
Figura 3.14: Versiones oficiales de AES.
El diagrama general del protocolo para encripción y decripción se muestra en la

Figura 3.15.
Proceso de encripción Proceso de decripción
Clave de cifrado
Texto claro
ronda
inicial Texto claro
AddRoundKey
AddRoundKey
ronda
SubBytes InvSubBytes
final
Subclave de ronda
9 ShiftRows InvShiftRows
rondas
principales
MixColumns
InvMixColumns
AddRoundKey
AddRoundKey
9
rondas
InvSubBytes principales
SubBytes
ronda Subclave de ronda 10

InvShiftRows
ShiftRows
final
AddRoundKey AddRoundKey
Texto encriptado Texto encriptado
Figura 3.15: Diagrama de AES.
Al igual que DES, AES conlleva una serie de transformaciones, funciones, expan-
siones y utiliza cajas para asegurar la confusión y difusión de la información. Tiene tres
algortimos básicos: encripción, expansión de la llave y decripción.
3.13. Algoritmo AES de encripción

Algoritmo AES de encripción
Resumen: Se encripta un mensaje  dividido en bloques. Se obtiene el mensaje

cifrado.
1. Encripción. La entrada de datos es asignada a 
2. Se agrega la llave de la ronda a , mediante la función (  [0  − 1])
3. Para la ronda  = 1 y hasta ( − 1) se realiza:
a) Se hace la sustitución de bytes mediante la función ()

b) Se hace el intercambio de filas con la función  ()
c) Se ejecuta el mezclado de columnas con la función ns()
d) Agregar la llave de la ronda (  [  ( + 1) − 1])
4. Se hace la sustitución de bytes mediante la función ()
5. Se hace el intercambio de filas con la función ()
6. Agregar la llave de la ronda (  [   ( + 1) − 1])
7. Se asigna  a la salida , texto encriptado
3.14. Algoritmo AES de expansión de la llave

Algoritmo AES de expansión de la llave
1. Se inicia con un valor  de la llave
2. Asignar valores 001000000 a  [1]
3. 002000000 a  [2]
4. 004000000 a  [3]
5. 008000000 a  [4]
6. 010000000 a  [5]
7. 020000000 a  [6]

3.15. ALGORITMO AES DE DECRIPCIÓN 63
8. 040000000 a  [7]
9. 080000000 a  [8]
10. 01000000 a  [9]
11. 036000000 a  [10]
12. Para  = 0 hasta ( − 1) se realiza:
a)  [] = [4  4+1  4+2  4+3 ]
13. Para  =  hasta ( ( + 1) − 1) se realiza:
a)  =  [ − 1]
b) Si ( mod  = 0)
h i

 =  ( ()) ⊕  
De lo contrario si (  6 y  mod  = 4)

 =  ()
c)  [] =  [ −  ] ⊕ 
14. Se obtiene la expansión de la llave 
3.15. Algoritmo AES de decripción

Algoritmo AES de decripción
1. Se asigna el bloque de entrada a 
2. Se asigna el valor  = (  [   ( + 1) − 1])
3. Para  =  − 1 decrementando hasta 1 se realiza:
a)  = ()
b)  = ()
c)  = (  [  ( + 1) − 1])
d)  = ns()
4.  =  ()
5.  = ()
6.  = (  [0  − 1])
7. Se asigna  a  como mensaje decriptado
En términos generales, estos son los procesos que realiza AES para encriptar y decrip-
tar. Los detalles del protocolo se pueden consultar en el Apéndice B de este trabajo. La
referencia hacia AES se debe principalmente a qué, como parte del protocolo propuesto
se utilizará el módulo de encripción incorporado en el microcomponente CC2430/31 que
está basado en AES-128. Este algoritmo se usará para encriptar y decriptar los mensajes
en los datos sensados por los nodos.
3.16. Certificados
En [86] se menciona que existen dos tipos principales de certificados: los de entidad
final y los de autoridad certificadora (Certificate Authority o CA). Los certificados de
entidad final son expedidos por una CA a una entidad o nodo que no expide certificados
a otras entidades. Mientras que los certificados de CA, se expiden a nodos que tam-
bién serán entidades certificadoras con el mismo tipo de certificado o incluso diferente.
Cualquiera que sea el caso, el certificado de una CA es distinguido por la presencia de
las denominadas restricciones básicas, un conjunto explícito de información que indica
que CA ha expedido dicho certificado. Los certificados pueden presentar a su vez varios
casos: los auto expedidos, los auto firmados y los certificados cruzados. Los certifica-
dos auto expedidos tienen en su sujeto y en el expedidor a la misma CA. Este tipo de
certificado puede ser utilizado para permitir operaciones especiales como la validación
de un nuevo par de llaves públicas cuando es solicitado por un nodo en la red. En este
caso, la nueva llave es contenida en el nuevo certificado, y la llave vieja es utilizada para
firmar el certificado, permitiendo confiar en la nueva llave. Un certificado auto firmado
es un caso especial del auto expedido. En este caso, la llave pública certificada por el
certificado corresponde a la llave privada usada para firmar el certificado. Por último, en
un certificado cruzado, el sujeto y el expedidor son diferentes. Los certificados cruzados
son utilizados por una CA para certificar la identidad de otra CA.
3.16.1. Formato del certificado

La CA crea un certificado firmando un conjunto de información de la entidad o nodo.
Esta información incluye la llave pública y el nombre distintivo de la entidad, incluso
puede utilizar un identificador único que contenga información adicional de la entidad.
El estándar X.509 define la forma de cómo debe ser un certificado expedido por una
CA. En general, aparece el nombre de la CA para el sujeto con un nombre distintivo A
usando el siguiente formato simbólico:
3.16. CERTIFICADOS 65
   = {          }

En este caso:
 Es el número de versión del certificado
 El número de serie
 Es el algoritmo utilizado para firmar el certificado
 Es el nombre distintivo de la CA
  Un identificador único para la CA (opcional)
 Nombre distintivo del sujeto identificado por el certificado
 Identificador único del sujeto (opcional)
 Llave pública del sujeto 
 El periodo de validez del certificado descrito por su fecha de inicio y la
fecha hasta la cual será válido.
La forma general del certificado X.509 se muestra gráficamente en la Figura 3.16.
3.16.2. Extensiones en el certificado

Las extensiones del certificado permiten agregar información adicional que es especi-
ficada por las necesidades del mismo. Las extensiones en el certificado pueden ser críticas
y no críticas
3.16.3. Indicadores críticos

Las extensiones consideradas críticas tienen una bandera que lo indica. La manera
general, una bandera puesta en verdadero, indica que la extensión deber ser procesada
de alguna manera. Si el usuario de un certificado no reconoce o no puede procesar un
certificado conteniendo una extensión crítica, el certificado debe ser considerado como
inválido. Las extensiones marcadas como no críticas, pueden ser ignoradas. Esto permite
que las extensiones definidas en una comunidad puedan ser utilizadas en otra, incluso si
el tipo de extensiones no son reconocidas.
3.16.4. Tipos de extensiones

Las extensiones en el certificado pueden pertenecer a los siguientes tipos básicos:
1. Extensiones de la llave. Esta clase de extensiones incluyen información sobre las

llaves utilizadas por las CA y las entidades finales. Incluso pueden agregar restric-
ciones sobre el cómo pueden ser utilizadas las llaves.
2. Extensiones de políticas. Permiten la especificación y restricciones de las políticas
usadas para definir la aplicación de los certificados.
3. Extensiones de información del sujeto y el expedidor. Estas extensiones permiten
el uso de nombres alternativos para la CA y el sujeto.
Número de versión
Número de serie
Firma
Llave privada
de la CA
Expedidor
Periodo de validez
Sujeto
Hash
Generación
de firma
Información pública
del Sujeto
Identificador único
del Expedidor
Identificado único
del Sujeto
Uso de las llaves/certificado
Extensiones
Firma digital
de la CA
Figura 3.16: Formato general del certificado X.509.
4. Extensiones de restricción de la ruta de certificación. Son usadas cuando se procesa

la ruta del certificado, como un elemento de verificación.
Para este trabajo, la entidad certificadora será la estación base, que es quién suscribirá
los certificados. Por lo que la información de la CA se construirá con los datos de la EB.
El sujeto será el nodo, sus datos serán incorporados al certificado, entre ellos, la llave
pública y su firma digital.
Para el diseño del formato del certificado se utilizarán las especificaciones del están-
dar X.509; considerando el que no puede ser un mensaje demasiado largo, de preferencia
debe ocupar la longitud útil de una trama a transmitir. El uso de las extensiones de-
penderá del espacio disponible en la trama y de si se incorporarán las funciones para la
administración, revocación, etc. de la CA.
3.17. DISEÑO DE LA CA 67
3.17. Diseño de la CA
En [86] se establece que una CA es la autoridad responsable de crear los certificados
de la entidades. Lo cual es mucho más que generar los certificados para que sirvan como
identificaciones electrónicas. Esto es comparable a la diferencia que existe entre una
oficina de expedición de pasaportes y un servicio de fotocopiado a color que puede ser
utilizado para reproducirlo. Solo porque los certificados puedan ser creados, no significa
que puedan ser utilizados o confiar en ellos. La CA implementa procedimientos para
verificar la identidad de un solicitante y para el registro de los certificados, los que
son usados para propósitos de identificación. La identidad es expedida por periodos
determinados de tiempo, y la CA tiene la posibilidad de revocar los certificados, avisando
a los usuarios de este hecho.
Tanto las llaves como los certificados tienen un periodo de vida y cumplen ciclos. La
administración de las llaves tienen relacionados procesos como: la creación, distribución,
protección, archivado y recuperación. Mientras que los certificados requieren de procesos
como: el registro, renovación y revocación.
Al utilizar la EB como CA esta deberá contener una base de datos en dónde se
almacenen, protejan y puedan ser recuperadas las llaves; ya sea para su distribución
o, en una fase inicial, para su creación. Los certificados también deberán de ser crea-
dos y responder a las solicitudes de comprobación y en su caso revocación. Por lo que
los aspectos operativos para el proyecto deben ser determinados con cuidado; dada la
complejidad de los procesos involucrados en todas estas funciones.
Capítulo 4
Implementación del protocolo
propuesto
El protocolo propuesto está dividido en cinco fases:

1. Establecimiento de la llave basado en sistemas simétricos. Con la llave generada
se identifican los nodos individuales con la EB.
2. Generación de llaves públicas. Se usan para cifrar y descifrar los mensajes trans-
mitidos entre los nodos sensores.
3. Firma digital. Se usa un esquema asimétrico para que la EB genere su firma y
pueda utilizarla en los certificados digitales que emita.
4. Cifrado de bloques. Se usa para cifrar y descifrar las llaves criptográficas almace-
nadas en los nodos sensores y en la EB.
5. Administración de certificados. Se encarga de generar, revocar, controlar y alma-
cenar los certificados.
En la Fig 4.1 se muestra la relación entre las fases descritas. Cabe destacar que la EB
para propósitos del protocolo propuesto realizó las funciones de Autoridad Certificadora
(AC) con funciones mínimas para la generación, administración y revocación de certi-
ficados, ya que su implementación se realizó en una computadora portátil, que además
de fungió como AC también realizó las funciones de configuración remota de los nodos,
además de adquirir las funciones típicas de nodo maestro, en el contexto de las redes Ad
hoc.
4.1. Protocolo de establecimiento de la llave secreta

Este protocolo se divide en las entidades  (EB) y  para los nodos. El sistema en
dónde se desarrolló este trabajo es el que se muestra en la Figura 4.1.
Para la implementación del protocolo se seleccionó un número primo apropiado  y
un generador  de Z∗ (2 ≤  ≤  − 2) los cuales son públicos.
69
70 CAPÍTULO 4. IMPLEMENTACIÓN DEL PROTOCOLO PROPUESTO
U V
Nodos
Tarjeta de desarrollo
Fase 4. Cifrado de bloques
Programación y claves
de pre acuerdo
Monitoreo y puente de
las comunicaciones n1
entre nodos
n2
n3
Estación Base
Autoridad Certificadora
n4
Fase 1. Establecimiento de la llave
Fase 2. Generación de llaves públicas n5
Fase 3. Firma digital
Fase 5. Administración de certificados
Figura 4.1: Diagrama general de la distribución de las fases y responsabilidades en el

protocolo.
4.1.1. Algoritmo para 

1. Se asignó a  un identificador () y se seleccionó un exponente secreto
 ; 0 ≤  ≤  − 2 y se publicó  calculado mediante la ec. 4.1.
 =  mod  (4.1)
2.  eligió un número aleatorio  y calculó
 =  mod  (4.2)
3.  envió ( ) y  a  .
4.1.2. Algoritmo para 

1. Se asignó a  un identificador ( ) y se seleccionó un exponente secreto
 ; 0 ≤  ≤  − 2 y se publicó  calculado mediante la ec. 4.3.
 =  mod  (4.3)
2.  eligió un número aleatorio  y calculó

4.2. PROTOCOLO PARA LA GENERACIÓN DE LLAVES PÚBLICAS/PRIVADAS ( )71
 =  mod  (4.4)
3.  envió ( ) y  a  .
4.1.3. Algoritmo de comprobación de llaves secretas

La EB calculó (4.6)
 =   (  + ( )) mod  (4.5)

que es equivalente a:
 =     mod  (4.6)
Los nodos a su vez calcularon (4.8)
 =   (  + ()) mod  (4.7)

que es equivalente a:
 =     mod  (4.8)
Si  =  entonces fueron usadas como llaves secretas para cifrar las llaves públicas
y privadas en la EB y en los nodos respectivamente. Para reducir el consumo de energía
con el cálculo de las llaves y su verificación, los dispositivos al ser programados también
les fueron transferidos a la memoria no volátil, en una posición diferente para cada
dispositivo, valores que generaron llaves válidas y que fueron verificados mediante el uso
del algoritmo, arriba descrito, en la EB. El algoritmo fue implementado mediante un
código de Visual Basic el cual hizo todos los cálculos y los verificó, de tal manera que los
valores arrojados por el mismo fueron almacenados en la estructura de la base de datos
para su posterior asignación a los nodos. La forma utilizada se muestra en la Figura 4.2
y el resultado de una de sus corridas se aprecia en la Figura 4.3.
Los valores y las relaciones con los nodos fueron mantenidos en una base de datos
encriptada, la cual constituye el primer paso hacia la conformación de una entidad
certificadora formal, la cual está fuera de los alcances de este trabajo. La estructura,
relaciones, consultas y demás elementos de la base de datos están especificados en el
Apéndice E. Mientras que el código utilizado para la implementación de protocolo MTI
y su verificación se encuentran en el Apéndice F.
4.2. Protocolo para la generación de llaves públi-

cas/privadas ( )
Este proceso corresponde a la EB, y el algoritmo que se usó es el RSA por ser el
estándar de facto en la criptografía de llave pública.
Figura 4.2: Forma para el cálculo de valores válidos para el acuerdo de la llave MTI.
4.2.1. Algoritmo para generar las llaves ( )

De acuerdo con el algoritmo ya descrito para la generación de la llave pública de
encripción RSA en el capítulo 3. El primer paso es la selección de dos números primos 
y  del mismo tamaño y preferentemente grandes. Por las limitaciones en la capacidad
de cómputo de los MOTE, se limitó el tamaño de los números primos a un máximo
de cuatro cifras y el valor de los mismos fue aleatorio, con un límite inferior fijado
arbitrariamente en 3,3331 , por lo que el valor máximo de un primo sería menor a 9,999.
Esto en conjunto con un límite inferior de longitud de la llave en 10,000,000 nos aseguró
que la llave tendría como mínimo una longitud de 24 bits, ya que el valor propuesto
tiene una representación binaria igual a: 100110001001011010000000.
Siguiendo la lógica del algoritmo, se calculó  =  para obtener Z , el cual fijó el
tamaño del campo dentro del cual trabajamos. Con  y  definidos, se pudo calcular
 = ( − 1)( − 1). Posteriormente se seleccionó un número aleatorio , que se usaría
como llave pública, tal que (  ) = 1 y con el algoritmo de Euclides se obtuvo ,
que se usaría como llave privada, con lo cual se completó el algoritmo.
Para cumplir con estos parámetros de diseño se implementaron una serie de funciones
en Visual Basic para la generación de las llaves (keyGen), la generación aleatoria de los
números primos y su verificación (EsPrimo), así como para el cálculo de  (mcd) y por
último de  (Euclides). Adicionalmente se implementó una función general para encriptar
y decriptar (Mult), una función para sustituir la función modular por omisión en el
sistema (nMod), el algoritmo de encripción (enc), el algoritmo de decripción (dec) y una
función para la creación de la firma Hash basada en el algoritmo SHA1 (CreateHash). Los
1
Se tomó la tercera parte del valor máximo definido.
4.3. DEFINICIONES 73
Figura 4.3: Valores validados obtenidos mediante el uso de la forma MTI.
detalles de la programación del módulo denominado RSAv1.vb pueden ser consultados

en el Apéndice F de este trabajo.
4.3. Definiciones
Las llaves  y  en la generación de llaves RSA son llamados exponente de encripción
y exponente de decripción, respectivamente; mientras que  es denominado módulo.
4.4. Generación y administración de certificados

Como se explicó en el capítulo 3 en la sección de los requisitos de diseño; los cer-
tificados pueden construirse de diferentes maneras, sin embargo, los más utilizados a
nivel mundial están basados en el estándar X.509. Para este trabajo, se ha adecuado
el certificado para que cumpla con los requisitos del estándar y atienda las limitaciones
del protocolo de transmisión. El protocolo tiene una trama de longitud máxima de 127
bytes, pero solamente 104 de ellos pueden ser asignados como “carga” útil. Esta limi-
tante se tomó en cuenta debido a qué, si pretendíamos ahorrar energía en el dispositivo,
debíamos de limitar el procesamiento y transmisión de datos innecesarios. Al limitar el
certificado a una cadena de longitud máxima de 104 bytes, aseguraríamos que el mismo
pudiera ser transmitido en una sola trama del protocolo ZigBee. Para ello se presenta
una distribución de los datos en el certificado y sus correspondientes valores en la Figura
4.4.
Un certificado siguiendo esta estructura se mostraría como sigue:
Campo Tamaño Descripción Código

Version 2 Un número y una letra para identificar la versión V
Id_certificado Por la capacidad de tener hasta 65,000 dispositivos. Este es el Serial Number o
5 SN SN
AI Una letra, unida al catálogo de algoritmos de encripción usados en el
1 protocolo AI
CA 1 Una letra, unida al catálogo de tipos de entidades en la red CA
UCA 5 Por la capacidad de tener hasta 65,000 dispositivos UCA
Id_mote 5 Por la capacidad de tener hasta 65,000 dispositivos A
IEEE 16 Los 8 bytes en formato hexdecimal de la dirección IEEE del dispositivo UA
ke 8 Llave pública del dispositivo AP
Fecha_inicio 10 Formato corto de fecha 00/00/0000 diez campos, en formato largo 24 TA
Fecha_fin 10 Formato corto de fecha 00/00/0000 diez campos, en formato largo 24 TA
Firma Firma Hash del certificado generado con el motor SHA‐1 desde el servicio de
28 encripción de VB 2008, se puede usar MD5 con una long de 24 Hash
Caracteres de separación 10 Caracteres de separación entre campos, se usan comas
Total 101
Figura 4.4: Certificado X.509 propuesto.
1 12345 1 1 12345 12345 0123456789 12345678 99999999

99999999 0123456789012345678901234567
Esta cadena representa el caso extremo, en el cual se han utilizado todos los campos
y las capacidades de los mismos. Para el caso de las fechas, el estándar X.509 utiliza
formato extendido, el cual requeriría de 14 caracteres adicionales por campo, es decir,
28 caracteres, por lo que el objetivo de limitar el certificado a la capacidad de una trama
de protocolo no podría ser alcanzado. En este caso se tomaron las cero horas del día en
que se generó el certificado como hora de inicio de vigencia y la misma hora pero un
año después para el vencimiento del mismo. Para el caso de la firma Hash, fue factible
utilizar otros protocolos disponibles en las bibliotecas de encripción de la herramienta
de desarrollo, sin embargo, la reducción en el uso de caracteres es marginal, por lo que se
decidió utilizar SHA-1 sobre MD5, ya que la diferencia entre ambos es de 4 caracteres.
Dado que la administración de los certificados representan operaciones comunes a las
de la administración de bases de datos, se decidió utilizar las facilidades de un motor de
Bases de Datos Relacionales para construir el conjunto de tablas y relaciones que permi-
tieran la administración de los elementos y al mismo tiempo cumplieran con los requisitos
de diseño planteados por el proyecto. Si bien esta decisión aumenta la complejidad de la
propuesta, al no utilizar archivos de texto en ASCII puro, se consideró que se ganaba en
seguridad al tener la posibilidad de encriptar toda la estructura y los datos, además fue
el primer paso para el establecimiento de una entidad certificadora formal, objetivo que
se busca en la línea de investigación de Telemática. La posibilidad de encriptar la base
de datos nos permitió dispersar los conjuntos de datos que pudieran establecer patrones,
que a su vez dieran oportunidad a algún adversario para utilizar el análisis estadístico de
4.5. PROGRAMACIÓN DE LOS DISPOSITIVOS 75
datos y con ello atacar el protocolo. Aún tratándose de bases datos, la diferencia entre
manejarla encriptada o sin encripción es aparentemente una decisión simple, a la luz de
un analizador de aleatoriedad con visualización tridimensional (Cryptool), esta decisión
toma relevancia, sobre todo al tratarse de seguridad informática. Las imágenes de la
base de datos propuesta con y sin encripción a través del analizador de aleatoriedad se
muestran en las Figuras 4.5 y 4.6.
Figura 4.5: Visualización de la aleatoriedad de un archivo sin encripción.
4.5. Programación de los dispositivos

Mediante el uso de la forma RSA—DH, explicada en el Apéndice F, es factible la
programación de los parámetros básicos que contendría un nodo. Durante el proceso
de programación se hizo la transferencia del número primo seleccionado, ,  ,  y  ,
de tal manera que el nodo pudiera calcular la llave secreta mediante el uso local del
algoritmo MTI, adicionalmente se le asignó el papel que tendría en la red, para el caso
de este trabajo y dado que no se estaban analizando mecanismos de ruteo, todos los
dispositivos fueron programados como dispositivos finales. De esta forma se estableció
un mecanismo de secreto pre compartido. El mensaje de notificación con el valor de la
llave secreta calculada por el nodo, fue enviado a la EB mediante el uso del protocolo
ZigBee, para ello se activó el motor de encripción del dispositivo que está basado en
Figura 4.6: Visualización de la aleatoriedad de un archivo encriptado.
AES, la respuesta desde la EB que confirmaba la entrada del dispositivo a la red, así
como toda la comunicación entre dispositivos, utilizó la encripción del motor de AES.
4.6. Ejecución del protocolo

El programa para el cálculo de las llaves públicas y privadas basado en los protocolos
criptográficos RSA y Diffie-Hellman se muestra en la Figura 4.7.
El primer paso es la generación de las llaves, esto se realizó seleccionando el botón
de comando “Generar llaves”, Figura 4.8. En este paso se ejecuta el cálculo de la llaves
con el protocolo RSA, ya explicado en capítulos anteriores. El botón de generación de
llaves permite la generación de éstas cada vez que es seleccionado, de tal forma que el
procedimiento ejecutará el algoritmo y generará llaves nuevas cada vez. Si encriptarámos
una cadena de texto y posteriormente seleccionáramos el botón de generación de llaves,
el resultado sería que las llaves generadas no podrían decriptar el texto, debido a que las
llaves no corresponderían, aún y cuando el protocolo y procedimiento sean los adecuados.
Por esta razón, el botón de generación de llaves es deshabilitado cuando se activa el de
encripción, de esta manera impedimos el cambio de llaves y con ello aseguramos el poder
decriptar los mensajes. En las aplicaciones cotidianas, se requiere de algún mecanismo o
medio por el cual se puedan recuperar las llaves, sobre todo aquella que es privada, esa
4.6. EJECUCIÓN DEL PROTOCOLO 77
Figura 4.7: Programa para el uso de RSA, SHA1 y DH.
es la razón de la existencia de una entidad certificadora.

En el caso mostrado,  = 8761 y  = 9533 con los cuales obtuvimos las llaves
 = 93145027 y  = 51700363. Con las llaves generadas se activaron los botones para
encriptar, decriptar y el de generación de la firma Hash. El campo de texto claro se
encontraba vacío, por lo que el resultado de un proceso de encripción sería nulo, para
mostrar el funcionamiento del algoritmo sobre datos provenientes del dispositivo, se
solicitó la dirección IEEE del mismo, esta dirección es un identificador único compuesto
de una cadena de 8 bytes de longitud, mediante el botón correspondiente, y se obtuvo
00124000006098 en la caja de texto claro. Con estos datos se pudo proceder a su
encripción, Figura 4.9, obteniendo:
76509288 + 76509288 + 13574831 + 43190322 + 48650271 + 57249130 + 76509288 +

76509288 + 76509288 + 76509288 + 76509288 + 34739365 + 76509288 + 54488247 +
23061169 + 63252294+
En dónde el símbolo + se utiliza como delimitador de los bloques. Nótese que el
Figura 4.8: Generación de llaves.
botón de generación de llaves se ha desactivado para tener la oportunidad de decriptar.

En este caso, al solicitar el proceso de decripción se obtuvo la cadena inicial como se ve
en la Figura 4.10.
La firma del texto encriptado se obtuvo mediante el botón de comando “Firma
HASH” cuyo resultado para este caso fue:
 5 +   5  74   =
Como prueba del acceso a la memoria del dispositivo, se adicionaron un par de

botones para grabar y recuperar un valor desde una posición de memoria específica. Los
valores utilizados para este caso se muestran en la Figura 4.11, en dónde el texto claro
indicó “Grabación exitosa”. Este texto indica que la posición inicial en la memoria fue
corrido una unidad y el valor a ser grabado en esa posición es de 11, en hexadecimal
0B. Este valor es retenido en la memoria gracias a las características del dispositivo
seleccionado, el cual mantiene energizado este segmento de la memoria en todo estado
del MOTE, aún sin tratarse de una memoria permanente.
Figura 4.9: Proceso de encripción.
Para recuperar el valor de la memoria, se utiliza el botón correspondiente y el dispos-

itivo devuelve el valor en hexadecimal grabado en la dirección de memoria especificada,
Figura 4.12.
Con esto se comprobó el acceso al dispositivo y la funcionalidad básica del protoco-
lo. Elementos adicionales del protocolo y detalles técnicos de la implementación de la
red se pueden observar en el Apéndice D. Instalación de la red. El cual está diseñado
para atender los requerimientos de futuras investigaciones basadas en esta selección de
tecnologías, aunque no estén relacionadas con aspectos de seguridad.
Figura 4.10: Proceso de decripción.

Figura 4.11: Grabación exitosa en memoria del dispositivo.

Figura 4.12: Recuperación del dato de la memoria.

Capítulo 5
Conclusiones
5.1. Recomendaciones
Para poder llevar a cabo la instalación del protocolo en los dispositivos CC2430/31
se tuvieron que configurar al menos dos equipos completos para la parte de diseño del
mismo. Sin embargo, se considera que para su implementación, a partir de los elementos
aportados por este trabajo, el uso de un solo equipo dedicado para ello es suficiente. Como
método alternativo, por demás recomendable, se encuentra el uso de máquinas virtuales.
En caso de conocer sobre la tecnología y contar con los medios para implementarla, ésta
aporta no solamente la posibilidad de la contención del desarrollo, adicionalmente se
puede “clonar” rápidamente, con lo cual se pueden hacer pruebas, y en caso de fallas
críticas, se puede volver al punto de inicio con la máquina original. La penalidad en este
caso, es que se requieren recursos de altas prestaciones, tanto de procesamiento, memoria
y almacenamiento de datos.
Para la instalación de la red de sensores y demás componentes, se recomienda aten-
der las indicaciones del Apéndice D. Las cuales paso a paso aclaran muchas de las dudas
que surgieron como problemas en esta fase de diseño inicial. La configuración del pro-
tocolo en los dispositivos puede ser llevada a cabo mediante el uso de las tarjetas de
demostración CC2430DB, sin embargo, el proceso de programación del dispositivo cam-
bia de manera significativa. En este trabajo nos circunscribimos a realizar todos estos
procesos mediante el uso de las tarjetas de desarrollo SmartRF04EB. De hecho, por
economía de tiempo y eliminación de limitantes de desarrollo, se recomienda el uso de
las tarjetas SmartRF04EB sobre la opción económica de las tarjetas CC2430DB.
5.2. Conclusiones
Dado que los métodos de autenticación en las redes WSN son prácticamente inexis-
tentes y que ello ha limitado de manera significativa su uso en aplicaciones de manera
general; la propuesta de un protocolo que atienda esta necesidad resulta pertinente. Si
bien, el protocolo teórico desarrollado se ha probado en una serie de dispositivos de una
83
84 CAPÍTULO 5. CONCLUSIONES
marca en particular, los estudios previos de los MOTE disponibles nos indican que el
protocolo puede ser implementado en su fase primaria, representada por los algoritmos
de la EB y la programación de los dispositivos, en muchos de ellos. La fase secundaria,
representada por la comunicación inalámbrica entre MOTE, puede contar o no con las
facilidades de la encripción de los mensajes mediante AES, esto dependerá de las carac-
terísticas de los dispositivos seleccionados, lo cual reduce la fortaleza del protocolo, pero
no lo elimina, debido a contención de los datos clave, ya que éstos nunca se revelan o
transmiten por medios no seguros.
El protocolo propuesto aporta una combinación de protocolos existentes con su res-
pectiva adecuación a las realidades tecnológicas de la época, con la adición de un poco
de ingenio para el “acomodo” de los mismos en sus interacciones. Todo ello como resul-
tado de un análisis cuidadoso y la experimentación, elementos pretendidos y deseados
para este tipo de trabajos. Su implementación ha sido viable en los dispositivos físicos
seleccionados.
Con respecto de los objetivos particulares, la modelación matemática y su imple-
mentación para la generación de claves resultaron exitosas. Los pseudocódigos son pre-
sentados en su totalidad, como base para su posterior implementación en el cualquier
lenguaje de programación. Igualmente, las funciones y programas fueron completados
exitosamente; y se integran al trabajo en el Apéndice correspondiente. La simulación
del protocolo fue dejada de lado para ser sustituida por la implementación física, la cual
resultó de acuerdo con las expectativas planteadas en un inicio. Los resultados de los tra-
bajos previos y lo de este trabajo han proporcionado material para la participación en el
décimo tercer congreso internacional de la Sociedad Mexicana de Instrumentación, A.C.
(SOMI) y en el congreso internacional APPLIEDMATH III, de matemáticas aplicadas de
la Escuela Superior de Ingeniería Mecánica y Eléctrica Unidad Azcapotzalco. En cuanto
a publicaciones internacionales, se han aceptado las propuestas enviadas a la revista
TELEMATIQUE revista electrónica de estudios telemáticos de la Universidad Rafael
Belloso Chacín, del estado Zulia en Venezuela y el trabajo enviado a la revista CIEN-
CIA E INGENIERIA NEOGRANADINA de la Universidad Militar de Nueva Granada
en Colombia.
5.3. Trabajos futuros

Si bien los alcances del trabajo fueron establecidos en la frontera del desarrollo teórico
del protocolo, lo cual se cumplió. Fue necesario el llevarlos un poco más adelante, como
prueba de su posible implementación en redes físicas de WSN. La disponibilidad de los
dispositivos para realizarlo, evidentemente facilitó esta decisión y al mismo tiempo nos
planteó una serie de problemáticas y objetivos secundarios no contemplados de inicio.
Sin embargo, las problemáticas iniciales fueron resueltas y aportaron significativamente
al componente tecnológico de la línea de investigación a la que pertenece este trabajo.
Los objetivos secundarios por su parte, se presentan ahora como una serie de trabajos
a futuro como son: la prueba del protocolo ante una serie de ataques diversos, unitarios
o combinados; la generación de una entidad certificadora formal que pueda generar
5.3. TRABAJOS FUTUROS 85
certificados con base en el estándar X.509 y que utilicen una sola trama del protocolo
ZigBee o bien la posibilidad de coordinar la migración automática de toda la red WSN
de una frecuencia a otra, dentro de la gama asignada al protocolo, como mecanismo
de auto reparación (Auto Healing) en caso de ataques o de grandes interferencias en el
medio electromagnético.
Este es sólo el primero de una serie de trabajos que contribuirán a una tecnología
que cambiará de manera radical nuestra interacción con el mundo físico. El tiempo y las
leyes que rigen el mercado y los aspectos tecnológicos en él, darán cuenta de la utilidad
de nuestras aportaciones, con ello contamos; y a ello nos atenemos.
Bibliografía
[1] T. Economist, “The coming wireless revolution. when everything connects.” [En
línea]. http://www.economist.com/opinion/displaystory.cfm?story_id=9080024.
[2] T. Economist, “A world of connections.” [En línea]. http://www.economist.com
/specialreports/displaystory.cfm?story_id=9032088.
[3] T. Economist, “The hidden revolution.” [En línea]. http://www.economist.com
/specialreports/displaystory.cfm?story_id=9031982.
[4] FAS, “The sound surveillance system (sosus).” [En línea]. http://www.fas.org
/irp/program/collect/sosus.htm.
[5] E. H. Callaway, Wireless Sensor Networks: Architectures and Protocols. Florida
Atlantic University, Boca Raton, FL: CRC Press, 2004.
[6] Wikipedia, “Ad hoc.” [En línea]. http://es.wikipedia.org/wiki/Ad_hoc.
[7] Wikipedia, “Mesoescala.” [En línea]. http://es.wikipedia.org/wiki/Mesoescala.
[8] Wikipedia, “Protocolo de red.” [En línea]. http://es.wikipedia.org/wiki/Protocolo
_de_red.
[9] T. Economist, “A sense of things to come.” [En línea]. http://www.economist.com
/specialreports/displaystory.cfm?story _id=9032026.
[10] I. F. Akyildiz, W. Su, Y. Sankarasubramaniam, and E. Cayirci, “Wireless sensor
networks: A survey,” Computer Networks, vol. 38, pp. 393—422, 2002.
[11] T. Economist, “Marconi’s brainwave.” [En línea]. http://www.economist.com /spe-
cialreports/displaystory.cfm?story_id=9032066.
[12] J. Portilla, “Wireless sensor networks.” [En línea]. El Centro Electrónica industrial
Web site http://www.upmdie.upm.es/ jportill/Wireless_Sensor_Networks.html.
[13] A. Swami, Wireless sensor networks: Signal processing and communications pers-
pectives. England: John Wiley Sons, 2007.
[14] Wikipedia, “Wireless sensor network.” [En línea]. http://en.wikipedia.org /wi-
ki/Wireless_sensor_network.
87
88 BIBLIOGRAFÍA
[15] M. I, Handbook of Sensor Networks: Compact Wireless and Wired Sensing Systems.
United States of America: CRC Press, 2005.
[16] T. Economist, “On the radio.” [En línea]. http://www.economist.com/specialreports

/displaystory.cfm?story_id=9032078.
[17] K. Sohraby, D. Minoli, and T. Znati, Wireless sensor networks: Technology, proto-
cols, and applications. New Jersey: John Wiley Sons, Inc., 2007.
[18] Wikipedia, “Latencia.” [En línea]. http://es.wikipedia.org/wiki/Latencia.
[19] K. Holger, Protocols and architectures for wireless sensor networks. England: John
Wiley Sons, Inc., 2005.
[20] S. Kazem, Wireless sensor networks: technology, protocols, and applications. Eng-
land: John Wiley Sons, Inc., 2007.
[21] Microsoft, “Tecnologías ubicuas, la u-sociedad. administración de la tecnología.” [En

línea]. http://www.microsoft.com/mexico/pymes/issues/technology/performance/
usociedad.mspx.
[22] M. Ilyas, Handbook of sensor networks : compact wireless and wired sensing systems.
United States of America: CRC Press, 2004.
[23] P. Chandra, Bulletproof Wireless Security: GSM, UMTS, 802.11 and Ad Hoc Secu-
rity. England: Elsevier Inc., 2005.
[24] R. Di Pietro, L. V. Mancini, and A. Mei, “Random key-assignment for secure wire-
less sensor networks,” in SASN ’03: Proceedings of the 1st ACM workshop on Se-
curity of ad hoc and sensor networks, (New York, NY, USA), pp. 62—71, ACM,
2003.
[25] S. Basagni, K. Herrin, D. Bruschi, and E. Rosti, “Secure pebblenets,” in Mobi-

Hoc ’01: Proceedings of the 2nd ACM international symposium on Mobile ad hoc
networking & computing, (New York, NY, USA), pp. 156—163, ACM, 2001.
[26] A. Boukerch, L. Xu, and K. EL-Khatib, “Trust-based security for wireless ad hoc
and sensor networks,” Comput. Commun., vol. 30, no. 11-12, pp. 2413—2427, 2007.
[27] X. Cao, W. Kou, L. Dang, and B. Zhao, “Imbas: Identity-based multi-user broad-
cast authentication in wireless sensor networks,” Comput. Commun., vol. 31, no. 4,
pp. 659—667, 2008.
[28] Y. Dong, A.-F. Sui, S. M. Yiu, V. O. K. Li, and L. C. K. Hui, “Providing distributed
certificate authority service in cluster-based mobile ad hoc networks,” Comput.
Commun., vol. 30, no. 11-12, pp. 2442—2452, 2007.
BIBLIOGRAFÍA 89
[29] L. Kallstrom, S. Leggio, J. Manner, T. Mikkonen, K. Raatikainen, J. Saarinen,

S. Suoranta, and A. Yla-Jaaski, “A framework for seamless service interworking
in ad-hoc networks,” Computer Communications, vol. 29, pp. 3277—3294, October
2006.
[30] C.-T. Li, M.-S. Hwang, and Y.-P. Chu, “A secure and efficient communication
scheme with authenticated key establishment and privacy preserving for vehicular
ad hoc networks,” Comput. Commun., vol. 31, no. 12, pp. 2803—2814, 2008.
[31] B. Panja, S. K. Madria, and B. Bhargava, “A role-based access in a hierarchical sen-

sor network architecture to provide multilevel security,” Comput. Commun., vol. 31,
no. 4, pp. 793—806, 2008.
[32] K. Ren, T. Li, Z. Wan, F. Bao, R. H. Deng, and K. Kim, “Highly reliable trust
establishment scheme in ad hoc networks,” Comput. Netw., vol. 45, pp. 687—699,
2004.
[33] S. Tripathy and S.Ñandi, “Defense against outside attacks in wireless sensor net-
works,” Comput. Commun., vol. 31, no. 4, pp. 818—826, 2008.
[34] Y.-R. Tsai and S.-J. Wang, “Two-tier authentication for cluster and individual sets
in mobile ad hoc networks,” Comput. Netw., vol. 51, no. 3, pp. 883—900, 2007.
[35] S. Avancha, J. Undercoffer, A. Joshi, and J. Pinkston, “Secure sensor networks for
perimeter protection,” Comput. Netw., vol. 43, no. 4, pp. 421—435, 2003.
[36] M.-Y. Hsieh, Y.-M. Huang, and H.-C. Chao, “Adaptive security design with mali-
cious node detection in cluster-based sensor networks,” Comput. Commun., vol. 30,
no. 11-12, pp. 2385—2400, 2007.
[37] D. Talbot and T. R. MIT, “Technology review the internet is broken.” [En línea].
http://www.technologyreview.com/Infotech/16051/?a=f.
[38] J. Hill, R. Szewczyk, A. Woo, S. Hollar, D. Culler, and K. Pister, “System architec-
ture directions for networked sensors,” SIGPLAN Not., vol. 35, no. 11, pp. 93—104,
2000.
[39] V. Daza, P. Morillo, and C. Ràfols, “On dynamic distribution of private keys over
manets,” Electron. Notes Theor. Comput. Sci., vol. 171, no. 1, pp. 33—41, 2007.
[40] J. Manner, S. Leggio, T. Mikkonen, J. Saarinen, P. Vuorela, and A. Ylä-Jääski,

“Seamless service interworking of ad-hoc networks and the internet,” Comput. Com-
mun., vol. 31, no. 10, pp. 2293—2307, 2008.
[41] Y. Jiang, C. Lin, M. Shi, X. S. Shen, and X. Chu, “A dos and fault-tolerant authenti-
cation protocol for group communications in ad hoc networks,” Comput. Commun.,
vol. 30, no. 11-12, pp. 2428—2441, 2007.
90 BIBLIOGRAFÍA
[42] M. S. G. Ateniese and G. Tsudik, “New multi-party authentication services and key
agreement protocols,” IEEE Journal on Selected Areas in Communications, vol. 18,
pp. 628—639, 2000.
[43] J. Pan, L. Cai, X. S. Shen, and J. W. Mark, “Identity-based secure collaboration

in wireless ad hoc networks,” Comput. Netw., vol. 51, no. 3, pp. 853—865, 2007.
[44] N. Saxena, G. Tsudik, and J. H. Yi, “Threshold cryptography in p2p and manets:
The case of access control,” Comput. Netw., vol. 51, no. 12, pp. 3632—3649, 2007.
[45] E. Gray, C. D. Jensen, P. O. Connell, S. Weber, J. Seigneur, and Y. Chen, “Trust

evolution policies for security in collaborative ad hoc applications,” Electronic Notes
in Theoretical Computer Science, vol. 157, no. 3, pp. 95—111, 2006. Journal publi-
cation of STM 2005 paper.
[46] M.Ñakhjiri and M.Ñakhjiri, AAA and network security for mobile access: radius,
diameter, EAP, PKI, and IP mobility. England: John Wiley Sons, Inc., 2007.
[47] Wikipedia, “Broadcast (sobre ip).” [En línea]. http://es.wikipedia.org/wiki /Broad-

cast_Sobre_IP.
[48] Wikipedia, “Schnorr signature.” [En línea]. http://en.wikipedia.org/wiki/Schnorr

_signature.
[49] Wikipedia, “Diagrama de hasse.” [En línea]. http://es.wikipedia.org/wiki/Diagrama

_de_Hasse.
[50] Wikipedia, “Store-and-forward.” [En línea]. http://en.wikipedia.org/wiki/Store-

and-forward.
[51] A. Molina and M. Acedo, Esta es la cita de las copias del libro. England: John
Wiley Sons, Inc., 2007.
[52] W. Stallings, Cryptography and Network Security Principles and Practices, Fourth
Edition. Upper Saddle River, NJ 07458: Pearson Education, Inc., 2006.
[53] Wikipedia, “Modelo osi.” [En línea]. http://es.wikipedia.org/wiki/Modelo_OSI.
[54] J. Cavers, Mobile Chanel Characteristics. Boston: Kluwer Academic Publishers,

2000.
[55] H. Hashemi, “The indoor radio propagation channel,” Proceedings of the IEEE,
vol. 81, no. 7, pp. 943—968, 1993.
[56] J. Parsons, The indoor radio propagation channel. England: Pentech Press, 1992.
[57] V. Garg, K. Smolik, and J. Wilkes, Applications of CDMA in Wireless/Personal

Communications. EUA: Prentice Hall, 1998.
BIBLIOGRAFÍA 91
[58] V. Gupta, S. Krishnamurthy, and M. Faloutsos, “Denial of service attacks at the

mac layer in wireless ad hoc networks,” in In Proc. of Milcom, 2002.
[59] H. Deng, W. Li, and D. Agrawal, “Routing security in wireless ad hoc networks,”
in IEEE Communications Magazine, vol. 40, pp. 70—75, 2002.
[60] H. Luo, P. Zefros, J. Kong, S. Lu, and L. Zhang, “Self-securing ad hoc wireless
networks,” in 7th IEEE Symposium on Computers and Communications (ISCC
’02, 2002.
[61] C. Karlof and D. Wagner, “Secure routing in wireless sensor networks: attacks and
countermeasures,” Elsevier AdHoc Networks, no. 1, 2003.
[62] Wikipedia, “Infraestructura de clave pública.” [En línea]. http://es.wikipedia.org

/wiki/Certificación_Electrónica.
[63] M. Benantar, “The internet public key infrastructure,” IBM Syst. J., vol. 40, no. 3,
pp. 648—665, 2001.
[64] W. Diffie and M. E. Hellman, “Multiuser cryptographic techniques,” in AFIPS ’76:

Proceedings of the June 7-10, 1976, national computer conference and exposition,
(New York, NY, USA), pp. 109—112, ACM, 1976.
[65] R. C. Merkle, “Secure communications over insecure channels,” Commun. ACM,

vol. 21, no. 4, pp. 294—299, 1978.
[66] R. L. Rivest, A. Shamir, and L. Adleman, “A method for obtaining digital signatures
and public-key cryptosystems,” Commun. ACM, vol. 21, no. 2, pp. 120—126, 1978.
[67] N. Koblitz, A Course in Number Theory and Cryptography. New York: Springer-
Verlag, 1994.
[68] R. Gómez Aíza, “Campo.” [En línea]. http://calli.matem.unam.mx/˜

rgomez/algebra/seccion_1.html.
[69] T. El Gamal, “A public key cryptosystem and a signature scheme based on discrete
logarithms,” in Proceedings of CRYPTO 84 on Advances in cryptology, (New York,
NY, USA), pp. 10—18, Springer-Verlag New York, Inc., 1985.
[70] B. Schneir, Applied Cryptography. New York: John Wiley Sons, Inc., 1996.
[71] W. Diffie and M. E. Hellman, “New directions in cryptography,” IEEE Transactions

on Information Theory, vol. IT-22, no. 6, pp. 644—654, 1976.
[72] IETF, “The internet engineering task force.” [En línea]. http://www.ietf.org.
[73] H. Prafullchandra and J. Schaad, Diffie-Hellman Proof-of-Possession Algorithms.

United States: RFC Editor, 2000.
92 BIBLIOGRAFÍA
[74] Wikipedia, “Internet key exchange.” [En línea]. http://es.wikipedia.org/wiki /In-

ternet_key_exchange.
[75] R. M. Needham and M. D. Schroeder, “Using encryption for authentication in large

networks of computers,” Commun. ACM, vol. 21, no. 12, pp. 993—999, 1978.
[76] J. Kohl and B.Ñeuman, “The kerberos network authentication service.” [En línea].
http://www.ietf.org/rfc/rfc1510.txt.
[77] R. Shirey, Internet Security Glossary. United States: RFC Editor, 2000.
[78] T. I. Chipcon Products, “A true system-on-chip solution for 2.4 ghz IEEE
802.15.4/ZigBee.” [En línea]. http://focus.ti.com/lit/ds/symlink/cc2430.pdf.
[79] D. Gislason, Zigbee Wireless Networking. United States: Newnes, 2008.
[80] Wikipedia, “Voz sobre ip.” [En línea]. http://es.wikipedia.org/wiki/Voz_sobre_IP.
[81] S. Farahani, ZigBee Wireless Networks and Transceivers. United States: Elsevier,
2008.
[82] J. Adams, “Ieee standard 802.15.4.” [En línea]. http://www.embedded-

computing.com/departments/zigbee/fall_04/.
[83] A. Menezes, P. Van Oorschot, and S. Vanstone, Handbook of Applied Cryptography.

United States: MIT Press, 1996.
[84] D. Stinson, Cryptography: Theory and Practice. United States: CRC Press, 1995.
[85] R. Oppliger, Contemporary Cryptography. Norwood, MA: ARTECH HOUSE, INC.,

2005.
[86] A.Ñash, W. Duane, C. Joseph, and D. Brink, PKI: Implementing and Managing
E-Security. United States: McGraw-Hill, 2001.
Apéndice A
Matemático
A.1. Número primo fuerte

Se dice que número primo  es fuerte si los enteros , y  existen, tales que satisfagan
las siguientes condiciones:
 − 1 tiene un factor primo grande, denotado por ;
 + 1 tiene un factor primo grande, denotado como ; y
 − 1 tiene un factor primo grande, denotado como .
En esta definición, una calificación precisa de “grande” depende del tipo de ataque
para el cual se está preparando el criptosistema.
Una forma de generar un número primo fuerte es el algoritmo de Gordon.
A.2. Algoritmo de Gordon para la generación de pri-

mos fuertes [1]
Algoritmo de Gordon para la generación de primos fuertes
Resumen: se generará un número primo fuerte .

1. Generar dos números primos largos  y , cada uno del mismo tamaño en bits.
2. Seleccionar un entero 0 . Encontrar el primer primo en la secuencia 2 + 1, para
 = 0  0 + 1 0 + 2  0 +  Denotar a este primo como  = 2 + 1
3. Calcular 0 = 2(−2 mod ) − 1
4. Selecionar un entero 0 . Encontrar el primer primo en la secuencia 0 + 2 para
 = 0 0 + 1 0 + 2  0 +  Denotar a este primo como  = 0 − 2
5. Regresar 
93
94 APÉNDICE A. MATEMÁTICO
A.2.1. Justificación
Para verificar que el primo  obtenido con el algoritmo de Gordon es un primo fuerte,
observemos primero (asumiendo  6= ) que −1 ≡ 1(mod ); que es derivado del teorema
de Fermat en donde: 0 ≡ 1(mod ) y 0 ≡ −1(mod ). Finalmente por la definición de
primo fuerte tenemos que:
1.  − 1 = 0 + 2 − 1 ≡ 0(mod ) por lo que  − 1 tiene un factor primo ;
2.  + 1 = 0 + 2 + 1 ≡ 0(mod ) por lo que  + 1 tiene un factor primo ;
3.  − 1 = 2 ≡ 0(mod )por lo que  − 1 tiene un factor primo .
A.3. Algoritmo extendido de Euclides [1]

Algoritmo extendido de Euclides
Entrada: dos enteros positivos  y  con  ≥ 

Salida:  = ( ) y los enteros   que satisfacen la ecuación  +  = 
1. Si  = 0, entonces  ←   ← 1  ← 0 regresar (  )
2. Asignar 2 ← 1 1 ← 0 2 ← 0 1 ← 1
3. Mientras   0 realizar lo siguiente:
a)  ← bc  ←  −   ← 2 − 1   ← 2 − 1 

b)  ←   ←  2 ← 1  1 ←  2 ← 1 , y 1 ← 
4. Asignar  ←   ← 2   ← 2 
5. Regresar (  )
El algoritmo extendido de Euclides tiene un tiempo de cálculo o de complejidad

computacional de ((log )2 ) operaciones binarias.
Ejemplo.
Si asumimos  = 4864 y  = 3458. Entonces (4864 3458) = 38 y (4864)(32) +
(3458)(−45) = 38
A.4. TEOREMA DE FERMAT [1] 95
q r x y a b x2 x1 y2 y1
− − − − 4864 3458 1 0 0 1
1 1406 1 −1 3458 1406 0 1 1 −1
2 646 −2 3 1406 646 1 −2 −1 3
2 114 5 −7 646 114 −2 5 3 −7
5 76 −27 38 114 76 5 −27 −7 38
1 38 32 −45 76 38 −27 32 38 −45
2 0 −91 128 38 0 32 −91 −45 128
Figura A.1: Ejemplo del algoritmo extendido de Euclides.
A.4. Teorema de Fermat [1]

El teorema de Fermat es un caso especial del teorema de Euler.
Si asumimos que  es un número primo:
1. Si el ( ) − 1 entonces −1 ≡ 1(mod )
2. Si  ≡ (mod  − 1) entonces  ≡  (mod ) para todos los enteros  En otras

palabras, trabajando en un módulo de un primo , los exponentes pueden ser
reducidos al módulo  − 1
3. En particular,  ≡ (mod ) para todos los enteros de 
A.5. Exponenciación modular [1]

Algoritmo repetido de raíz-multiplicación para la exponenciación en Z
P
Entrada:  ∈ Z  un entero 0 ≤  ≤  cuya representación binaria es  = =0  2 
Salida:  mod 
1. Asignar  ← 1 Si  = 0 entonces regresar 
2. Asignar  ← 
3. Si 0 = 1 entonces asignar  ← 
4. Para  = 1 hasta  realizar lo siguiente:
a) Asignar  ← 2 mod 
96 APÉNDICE A. MATEMÁTICO
b) Si  = 1 entonces asignar  ←  ·  mod 
5. Regresar ()
A.5.1. Documentos de soporte

[1] A. Menezes, P. Van Oorschot, and S. Vanstone, Handbook of Applied Cryptography.
United States: MIT Press, 1996.
Apéndice B
Estándar avanzado de encripción

(AES)
B.1. Introducción
En este apéndice se explicará el algoritmo adoptado por la NIST como el nuevo
estándar avanzado de encripción AES (Advanced Encription Standard), después de una
selección entre varios algoritmos, utilizando criterios de evaluación especificados en [1].
AES remplazó a DES (Data Encription Standard), publicado en 1977 por la NIST, el cual
fue roto por RSA Laboratorys en 1997, con 70,000 computadoras conectados a Internet,
usando como técnica la "Fuerza bruta", aproximadamente en 96 días [2], el algoritmo
ganador Rijndael, fue desarrollado por los científicos Búlgaros, Dr. Joan Daemen y Dr.
Vincent Rijmen, cuyo diseño se basó en la resistencia contra todos los ataques conocidos,
velocidad, código simplificado en gran variedad de plataformas y simplicidad en el diseño.
Su diseño tiene en cuenta la estrategia publicada en el Wide Trail Strategy [3],
la que tiene tres transformaciones invertibles llamadas capas, las que dan resistencia
al criptoanálisis lineal y diferencial, estas son : La capa de mezcla lineal, garantiza
alta difusión en varios ciclos. La capa no-lineal que da propiedades de no linealidad al
criptograma, y la capa de adición de llave que actúa como un XOR entre la “RoundKey”
y el estado intermedio, las cuales serán expuestas en el transcurso del documento.
B.2. Sistemas de encripción con llaves simétricas

Los criptosistemas de bloques son sistemas que encriptan un texto en bloques de 
bits y como resultado tendremos bloques encriptados de  bits. Algunos encriptadores
utilizan tamaños de bloques variables, otros utilizan tamaños de bloques fijos. Existen
otros encriptadores llamados encriptadores en flujo, los cuales encriptan un caracter del
texto al tiempo. AES es un encriptador de bloques variables.
97
98 APÉNDICE B. ESTÁNDAR AVANZADO DE ENCRIPCIÓN (AES)
B.2.1. Elementos de un encriptador de bloques

Tamaño de la llave
La llave, es una frase secreta, El tamaño de la llave está dado en bits, juega un papel
importante en la seguridad del sistema, debido a la facilidad existente de realizar ataques
de “Fuerza bruta” si el tamaño de la llave es muy pequeño, por ejemplo en 1998 DES
(Data Encription Standard) utilizando una llave de 56 bits fue roto en menos de tres
días con una máquina que ejecutaba cerca de 2 × 1011 instrucciones por segundo.
NIST estipuló que el candidato para el nuevo Standard de encripción debería usar
como mínimo un tamaño de 128 bits, teniendo en cuenta el siguiente análisis: Asumien-
do que fuera posible construir una computadora un millón de veces más rápido que
el usado para romper DES en 1998. Esta computadora debería ser capaz de ejecutar
aproximadamente 2 × 1017 operaciones por segundo, ¿Cuánto tiempo le tomaría a un
millón de esos computadores completar una búsqueda exhaustiva de la llave (“Fuerza
bruta”) de un encriptador de bloques con tamaño de llave de 128 bit?, Si éste es simétri-
co requerirá aproximadamente (2128 )2 = 2127 aproximadamente 17 × 1038 operaciones.
Un millón de estas super computadoras trabajando en paralelo podrían ejecutar cer-
ca de 106 × (2 × 1017 ) = 2 × 1023 operaciones por segundo, entonces esto le tomaría
aproximadamente (17 × 1038 )(2 × 1023) = 1015 segundos, aproximadamente 31 623153
años.
Tamaño del bloque

Los bloques son tomados en orden del texto que se desea encriptar, se toman los
primeros -bits del texto, siendo este el primer bloque, donde  corresponde al tamaño
del bloque. En general, la seguridad de un encriptador se incrementa, proporcionalmente
con el tamaño del bloque, es más difícil aplicar criptoanálisis a un bloque grande, ya que
se tienen más posibilidades de textos, sin embargo existe una desventaja al usar tamaños
grandes de bloque, que es el tiempo de encripción, por consiguiente es importante encon-
trar un balance entre velocidad y seguridad, determinando el tamaño de bloque óptimo,
el recomendado es 128.
Función Key Schedule

Esta función es usada para distribuir los bits de la llave al encriptador cuando las
necesite. En la mayoría de los encriptadores esta función expande la llave, y se denomina
“RoundKey”, de la cual de seleccionan sub llaves, que son utilizadas en diferentes ciclos
del sistema. Un mal diseño de esta función puede ayudar a romper la encripción con
criptoanálisis; por ejemplo cuando diferentes llaves producen un texto encriptado igual.
Número de Ciclos
En un ciclo se aplican las transformaciones que permiten encriptar el texto, cada ciclo
adicional que el encriptador use puede dar más seguridad, sin embargo la velocidad para
B.2. SISTEMAS DE ENCRIPCIÓN CON LLAVES SIMÉTRICAS 99
generar el texto encriptado disminuye. El número apropiado de vueltas es determinado

por el diseñador del encriptador mediante pruebas empíricas.
Formas de Operación
Un encriptador de bloques puede operar de cuatro diferentes formas:
Notación:
 = 1  2    , donde  es un texto y  el bloque  del texto.
 ( ) es el resultado de aplicar las transformaciones con llave  al bloque  .
 es vector inicial que se genera aleatoriamente o muchas veces se especifica.
 es el texto encriptado.
Electronic code Block (ECB) Mode: En este modo se aplica las transformaciones
a cada bloque y se concatenan los resultados en el mismo orden para obtener el texto
cifrado.
 =  ( )
 = 1 + 2 +  + 
Cipher Block Chaining (CBC) Mode: En este modo se obtiene el primer bloque
cifrado 1 de la siguiente forma:
1 =  ( ⊕  )
para los siguientes:
 =  ( ⊕ −1 )
el texto cifrado será :
 = 1 + 2 +  + 
Cipher FeedBack (CFB) Mode: En este modo se obtiene el primer bloque cifrado
1 de la siguiente forma:
1 =  ( )
1 = 1 ⊕ 1
 =  (−1 )
 =  ⊕ 
El texto cifrado será :
 = 1 + 2 +  + 
Output FeedBack (OFB) Mode: En este modo se obtiene el primer bloque cifrado
1 de la siguiente forma:
1 =  ( )
1 = 1 ⊕ 1
 =  (−1 )
 =  ⊕ 
El texto cifrado será :
 = 1 + 2 +  + 
B.3. Vulnerabilidad de un criptosistema

Existen ataques que pueden hacer vulnerable la seguridad de un texto cifrado.
1. Fuerza bruta. Como ya se mencionó, consiste en realizar una búsqueda exhaustiva

de la llave.
2. Criptoanálisis Estadístico. Usa información estadística para romper el texto en-
criptado, analizándolo y usando la probabilidad de ocurrencia de cada letra en un
idioma.
3. Criptoanálisis. Es el estudio de las técnicas para romper criptosistemas, existen
dos técnicas relativamente nuevas que pueden ser usadas para atacar los criptosis-
temas modernos; estas técnicas son bastante complejas e incorporan procedimien-
tos matemáticos.
4. Criptoanálisis diferencial. Es la técnica que permite reducir el número de llaves
posibles, el análisis consiste en cifrar con la misma llave varios textos y analizar
cada estado intermedio viendo la propagación del texto [4].
5. Criptoanálisis Lineal. Es la técnica que intenta encontrar las aproximaciones li-
neales basadas en las transformaciones que un criptosistema ejecuta en un texto.
MATSUI publicó un artículo en 1993 donde exponía como esta técnica podía ser
utilizada para romper DES [5].
B.4. ALGORITMO RIJNDAEL 101
Las técnicas diferencial y lineal son conocidas como explotación de texto claro
conocido “know plaintext exploit”, ya que utilizan un texto conocido para ejecutar
los ataques.
Como principio general se dice que la magnitud del esfuerzo requerido para tener
éxito en un criptoanálisis debe ser mayor que la requerida para romperlo con el
ataque de “Fuerza bruta”.
B.4. Algoritmo Rijndael

Rijndael es un encriptador de bloques de varios ciclos con tamaño de bloque y llave
variable, estos tamaños pueden ser independientemente especificados como 128,192 ó
256 bits.
B.4.1. El estado y la llave

El resultado intermedio del encriptador es llamado estado, las diferentes transforma-
ciones operan sobre él. El estado puede ser graficado como un arreglo rectangular de
bytes. Este arreglo tendrá 4 filas, el número de columnas esta denotado por  y es igual
al tamaño del bloque dividido entre 32.
La llave del encriptador puede ser similarmente dibujada como un arreglo rectangular
de 4 filas. El número de columnas de la llave del encriptador esta denotado por  y es
igual al tamaño de la llave divido entre 32.
a0,0 a0,1 a0,2 a0,3 a0,4 a0,5 k0,0 k0,1 k0,2 k0,3
a1,0 a1,1 a1,2 a1,3 a1,4 a1,5 k1,0 k1,1 k1,2 k1,3
a2,0 a2,1 a 2,2 a2,3 a2,4 a2,5 k2,0 k2,1 k2,2 k2,3
a3,0 a3,1 a3,2 a3,3 a3,4 a3,5 k3,0 k3,1 k3,2 k3,3
Figura B.1: Ejemplo: Estado con  = 6 y  = 4
El numero de ciclos esta notado por  y depende de los valores de  y  , según

la tabla:
Este número de ciclos fue seleccionado por los diseñadores del algoritmo, para ello
tuvieron en cuenta el número máximo de ciclos en los que un ataque de “atajos” encon-
traba la solución, y adicionando un margen considerable de seguridad.
B.4.2. Las transformaciones en un ciclo

Un ciclo está compuesto por cuatro transformaciones aplicadas en siguiente orden :
Nr Nb  4 Nb  6 Nb  8
Nk  4 10 12 14
Nk  6 12 12 14
Nk  8 14 14 14
Figura B.2: Valores de ciclos  en función de  y  
SubBytes(Estado)
ShiftRow(Estado)
MixColumn(Estado)
AddRoundKey(Estado, RoundKey)
El último ciclo se diferencia un poco y está dado por :
SubBytes(Estado)
ShiftRow(Estado)
AddRoundKey(Estado, RoundKey)
La transformación SubByte
Esta es una transformación de substitución de bytes no linear, operando en cada
estado independientemente, la tabla de substitución (S-box), es inversible y es equivalente
a realizar la siguiente multiplicación donde  es un byte en el estado y  su nueva posición
en un nuevo estado:
La aplicación a un estado esta denotada por SubBytes(Estado)
⎡ ⎤ ⎡ ⎤⎡ ⎤ ⎡ ⎤
0 1 0 0 0 1 1 1 1 0 1
⎢ 1 ⎥ ⎢ 1 1 0 0 0 1 1 1 ⎥ ⎢ 1 ⎥ ⎢ 1 ⎥
⎢ ⎥ ⎢ ⎥⎢ ⎥ ⎢ ⎥
⎢ 2 ⎥ ⎢ 1 1 1 0 0 0 1 1 ⎥ ⎢ 2 ⎥ ⎢ 0 ⎥
⎢ ⎥ ⎢ ⎥⎢ ⎥ ⎢ ⎥
⎢ 3 ⎥ ⎢ 1 1 1 1 0 0 0 1 ⎥ ⎢ 3 ⎥ ⎢ 0 ⎥
⎢ ⎥ ⎢ ⎥⎢ ⎥ ⎢ ⎥
⎢ 4 ⎥ = ⎢ 1 1 1 1 1 0 0 0 ⎥ ⎢ 4 ⎥ + ⎢ 0 ⎥
⎢ ⎥ ⎢ ⎥⎢ ⎥ ⎢ ⎥
⎢ 5 ⎥ ⎢ 0 1 1 1 1 1 0 0 ⎥ ⎢ 5 ⎥ ⎢ 1 ⎥
⎢ ⎥ ⎢ ⎥⎢ ⎥ ⎢ ⎥
⎣ 6 ⎦ ⎣ 0 0 1 1 1 1 1 0 ⎦ ⎣ 6 ⎦ ⎣ 1 ⎦
7 0 0 0 1 1 1 1 1 7 0
El diseño se basó en un trabajo de K. Nyberg [6] el cual da tres criterios mínimos que
hay que tener en cuenta, estos son: inversibilidad de la función, la correlación máxima
entre entrada/salida es de 2−3 y el máximo valor en la tabla XOR debe ser 4.
El diagrama general del proceso se puede ver en la Figura B.4.
Figura B.3: Ejemplo de S-Box  = 8
La transformación ShiftRows
En esta transformación las filas del estado son cíclicamente corridas diferentes dis-
tancias, la fila 0 no se mueve, la fila 1 es corrida 1 , la fila 2 es corrida 2 , la fila 3 es
corrida 3 bytes. Los valores de 1  2  3 dependen del tamaño del bloque  y están
dados en la siguiente tabla:
De modo que la fila uno no se corre, la segunda fila se corre una columna, la tercera
dos, la cuarta tres.
En la transformación inversa son movidas a la posición ( +  −  ) mod  donde
 es la fila y  el byte.
La transformación MixColumns
En esta transformación el estado es considerado como un polinomio en  (28 ) y

multiplicado con un polinomio constante ():
() = ‘03’3 + ‘01’2 + ‘01’ + ‘02’
La multiplicación de la columna () por () será:

a0,0 a0,1 a0,2 a0,3 b0,0 b0,1 b0,2 b0,3

SubBytes
a1,0 a1,1 a1,2 a1,3 b1,0 b1,1 b1,2 b1,3
a2,0 a2,1 a2,2 a2,3 b2,0 b2,1 b2,2 b2,3
a3,0 a3,1 a3,2 a3,3 b3,0 b3,1 b3,2 b3,3
Figura B.4: Proceso general de SubBytes.
N b c1 c2 c3
4 1 2 3
6 1 2 3
8 1 3 3
Figura B.5: Valores de 1  2  3 en función de  
⎡ ⎤ ⎡ ⎤⎡ ⎤
0 02 03 01 01 0
⎢ 1 ⎥ ⎢ 01 02 03 ⎥ ⎢
01 ⎥ ⎢ 1 ⎥
⎢ ⎥ ⎢ ⎥
⎣ 2 ⎦ = ⎣ 01 01 02 03 ⎦ ⎣ 2 ⎦
3 03 01 01 02 3
La transformación inversa será :
(‘03’3 + ‘01’2 + ‘01’ + ‘02’) ⊗ () = ‘01’

Donde :
() = ‘0’3 + ‘0’2 + ‘09’ + ‘0’

Los criterios para el diseño de esta transformación fueron, inversibilidad, linealidad
en  (28 ), velocidad en procesadores de 8-Bits, simetría.
La transformación AddRoundKey
La operación que se realiza es un XOR entre el estado y la RoundKey, que es derivada
de la llave del encriptador, y la función KeySchedule. El tamaño de la RoundKey es igual
al del bloque  .
1 5 9 13 1 5 9 13
2 6 10 14 6 10 14 2
3 7 11 15 11 15 3 7
4 8 12 16 16 4 8 12
Figura B.6: Ejemplo de ShiftRow  = 4
Sin
cambio
a0,0 a0,1 a0,2 a0,3 a0,0 a0,1 a0,2 a0,3
ShiftRows
Shift 1 a1,0 a1,1 a1,2 a1,3 a1,1 a1,2 a1,3 a1,0
Shift 2 a2,0 a2,1 a2,2 a2,3 a2,2 a2,3 a2,0 a2,1
Shift 3 a3,0 a3,1 a3,2 a3,3 a3,3 a3,0 a3,1 a3,2
Figura B.7: Proceso general de ShiftRows.
B.4.3. Key Schedule

Está compuesta por dos funciones: expansión de la llave y selección de la llave. El
número total de bits en la llave expandida es igual al tamaño del bloque multiplicado
por el número de ciclos más 1, por ejemplo si el tamaño del bloque es de 128 bits y 10
ciclos, entonces el tamaño de la RoundKey será de 1408 bits. La llave del encritador es
expandida por medio de la función de expansión de la llave, y luego se seleccionará la
sub llave para el primer ciclo, tomando las primeras  palabras, para el segundo ciclo
las siguientes  palabras de la llave expandida, etc.
Expansión de la Llave:
La llave expandida esta denotada por  [ × ( + 1)]. Las primeras  palabras
son la llave del encriptador, Esta función depende del valor de  , para  ≤ 6, está
dado según:
KeyExpansion(byte Key[4*Nk], word W[Nb*(Nr+1)])

{
for(i = 0; i < Nk; i++)
W[i] = (Key[4*i],Key[4*i+1],Key[4*i+2],Key[4*i+3]);
for(i = Nk; i < Nb * (Nr + 1); i++)
{
temp = W[i - 1];
a0,1 b0,1
a0,0 a0,2 a0,3 b0,0 b0,2 b0,3
a1,1 MixColumns b1,1
a1,0 a1,2 a1,3 b1,0 b1,2 b1,3
a2,0 a2,1 a2,2 a2,3 b2,0 b2,1 b2,2 b2,3
a3,0 a3,2 a3,3 b3,0 b3,2 b3,3

a3,1 b3,1
Figura B.8: Proceso general de MixColumns.
if (i % Nk == 0)
temp = SubByte(RotByte(temp)) ^Rcon[i / Nk];
W[i] = W[i - Nk] ^temp;
}
}
En esta descripción SubByte(W) es la función que regresa una palabra de 4-byte

después de aplicarle (S-Box) o la transformación ByteSub a la correspondiente posición
en la palabra, la función RotByte(w), regresa un palabra de tal forma que si la palabra
de entrada es (a,b,c,d) la salida será (d,c,b,a). En general se puede decir que los primeras
 palabras corresponden a la llave del encriptador y la siguiente palabra  [] es igual
a un XOR con la palabra anterior  [ − 1], para palabras con posiciones múltiplos de
 la transformación descrita es aplicada.
para valores de   6 es :
KeyExpansion(byte Key[4*Nk] word W[Nb*(Nr+1)])

{
for(i = 0; i < Nk; i++)
W[i] = (key[4*i],key[4*i+1],key[4*i+2],key[4*i+3]);
for(i = Nk; i < Nb * (Nr + 1); i++)
{
temp = W[i - 1];
if (i % Nk == 0)
temp = SubByte(RotByte(temp)) ^Rcon[i / Nk];
else if (i % Nk == 4)
temp = SubByte(temp);
W[i] = W[i - Nk] ^temp;
}
a0,0 a0,1 a0,2 a0,3 b0,0 b0,1 b0,2 b0,3

AddRoundKey
a1,0 a1,1 a1,2 a1,3 b1,0 b1,1 b1,2 b1,3
a2,0 a2,1 a2,2 a2,3 b2,0 b2,1 b2,2 b2,3
a3,0 a3,1 a3,2 a3,3 b3,0 b3,1 b3,2 b3,3
k0,0 k0,1 k0,2 k0,3
k1,0 k1,1 k1,2 k1,3
k2,0 k2,1 k2,2 k2,3
k3,0 k3,1 k3,2 k3,3
Figura B.9: Proceso general de AddRoundKey.
La diferencia con el esquema para  ≤ 6 es que si  − 4 es múltiplo de  , SubByte

es aplicada a  [ − 1] antes de XOR
Las constantes son independientes de  y están definidas por :
[] donde [1] = 001 [2] = 001 [3] = 004 [4] = 008
[5] = 010 [6] = 020 [7] = 040 [8] = 080
Selección de la llave:
La selección de la llave para el ciclo , será tomada de la llave expandida desde

 [  ∗ ] hasta  [ ∗ ( + 1)] ilustrada en la Figura B.10.
W0 W1 W2 W3 W4 W5 W6 W7 W8 W9 W10 W11 W12 W13 W14 ...
Llave de la ronda 0 Llave de la ronda 1
Figura B.10: Ejemplo:  = 6  = 4

B.4.4. El encriptador
El encriptador de Rijndael consiste en :
La expansión de la llave,  − 1 ciclos y un ciclo final. En pseudo C sería :
Rijndael(State,CipherKey)
{
KeyExpansion(CipherKey,ExpandedKey) ;
AddRoundKey(State,ExpandedKey);
For( i=1 ; i<Nr ; i++ )
Round(State,ExpandedKey +Nb*i) ;
FinalRound(State,ExpandedKey + Nb*Nr);
}
El diagrama general del proceso de encripción y decripción de AES se puede observar

en la Figura B.11.
Proceso de encripción Proceso de decripción
Clave de cifrado
Texto claro
ronda
inicial Texto claro
AddRoundKey
AddRoundKey
ronda
SubBytes InvSubBytes
final
Subclave de ronda
9 ShiftRows InvShiftRows
rondas
principales
MixColumns
InvMixColumns
AddRoundKey
AddRoundKey
9
rondas
InvSubBytes principales
SubBytes
ronda Subclave de ronda 10

InvShiftRows
ShiftRows
final
AddRoundKey AddRoundKey
Texto encriptado Texto encriptado
Figura B.11: Diagrama general de los procesos de AES.
Criptoanálisis a Rijndael
Los primeros ataques conocidos para este algoritmo de Encripción fueron publicados
en 1998 [7], el primer ataque únicamente logra romper la seguridad teóricamente de el
encriptador para 6 ciclos, más tarde Gilbert y Miner [8] en el año 2000 publicaron un
ataque para el encriptador cuando usa 7 ciclos. Recordemos que Rijndael usa 10, 12 ó
14 ciclos.
Otras técnicas usadas, como, la técnica de la suma parcial redujo considerablemente
la complejidad del ataque a los 6 ciclos, técnica que es posible usar también con 7 y 8
ciclos. En algunos casos donde se puede usar textos conocidos el factor de trabajo se ve
reducido. Todos estos ataques se han basado en los trabajos y en las técnicas del ataque
cuadrado, explicadas y publicadas en [9], y únicamente se han trabajado con tamaño de
bloque de 128-bits.
La técnica del ataque cuadrado puede ser usada en ataques contra el algoritmo de
Rijndael con 6, 7 y 8 ciclos y pretende encontrar la llave, utilizando 256 textos encripta-
dos, que solamente se diferencien en un byte, después aplicar MixColumn en el primer
ciclo y luego intercambiar el orden de las transformaciones MixColumn y AddRound-
Key en el último ciclo, con este cambio y un análisis empírico los investigadores Niels
Ferguson, John Kelsey, Stefan Lucks, Bruce Schneier, Mike Stay, David Wagner y Doug
Whiting, se dieron cuenta que el texto encriptado depende de cuatro bytes de la Round-
Key del último ciclo, y de esta manera reducir el número considerable de llaves posibles
para un texto encriptado. Sin embargo en esta técnica se puede ver que es necesaria una
gran cantidad de textos encriptados y un gran procesamiento para su análisis. Además
a pesar de que se tiene la misma estructura para tamaños de bloques mayores de 128,
su criptoanálisis debe ser tratado de diferente manera.
Encriptador Tamaño Complejidad

de la llave memoria Tiempo
Rijndael-6 (all) 2 32 CP 2 72
Rijndael-6 (all) 6  2 32 CP 2 44
Rijndael-7 (192) 19  2 32 CP 2 155
Rijndael-7 (256) 21  2 32 CP 2 172
Rijndael-7 (all) 2 128 − 2 119 CP 2 120
Rijndael-8 (192) 2 128 − 2 119 CP 2 188
Rijndael-8 (256) 2 128 − 2 119 CP 2 204
Rijndael-9 (256) 2 85 RK − CP 2 224
Figura B.12: Complejidad en el criptoanálisis de Rijndael.
Esta tabla tomada de [10] nos muestra la poca factibilidad actual de lograr un ataque
exitoso contra el algoritmo de Rijndael, por ejemplo para el algoritmo con 6 ciclos el
ataque tiene una demora de 272 segundos esto es 149 745 258 842 898 años.
Ejemplo de Rijndael con diferentes tamaños de llave :

 : Texto Cifrado en el ciclo .
TAMANO_LLAVE=128
LLAVE = 000102030405060708090A0B0C0D0E0F
Encripcion :
TEXTO=000102030405060708090A0B0C0D0E0F
CT1=B5C9179EB1CC1199B9C51B92B5C8159D
CT2=2B65F6374C427C5B2FE3A9256896755B
CT3=D1015FCBB4EF65679688462076B9D6AD
CT4=8E17064A2A35A183729FE59FF3A591F1
CT5=D7557DD55999DB3259E2183D558DCDD2
CT6=73A96A5D7799A5F3111D2B63684B1F7F
CT7=1B6B853069EEFC749AFEFD7B57A04CD1
CT8=107EEADFB6F77933B5457A6F08F046B2
CT9=8EC166481A677AA96A14FF6ECE88C010
CT=0A940BB5416EF045F1C39458C653EA5A
Descripcion :
CT =0A940BB5416EF045F1C39458C653EA5A
PT1=CA68DA374E6E5A9ED58C87C330F3B6A8
PT2=AF28543EF9BB2904B8E097925B7FB021
PT3=8FEEF1D2F5A4C04C82B3020D45D306FB
PT4=0EEEADB5CB98BD03CB5DFF23FCFCB927
PT5=1996D9A1E5DB81D640066FEC0DF032DB
PT6=3EDF5A958DC4F61F9056CF85387C4DB7
PT7=F12CD33929119D9A15904239454D103F
PT8=D54BAF5EC8A6590B56E8F0EED5DD824F
PT9=63636363636363636363636363636363
PT=000102030405060708090A0B0C0D0E0F
========================================
TAMANO_LLAVE =192
LLAVE =000102030405060708090A0B0C0D0E0F1011121314151617
Encripcion :
TEXTO =000102030405060708090A0B0C0D0E0F
CT1=73727170777675743B25919A3F20979D
CT2=C673B27A311EC2EB64AD47FF53B233D7
CT3=0B5CC6BA34C807E6496D79B46826A1E8
CT4=005B53A5B660E280307883487E4D1A4D
CT5=88A105F0DDD45F3674DBC3DE1A211B03
CT6=EB5CD8B5FD8A3F33F03A70FB5C620C06
CT7=909913B09BD2CC5A70B6C647931F0A1F
CT8=6EB6CA10E395AFD646B02C5E9E745A9F
CT9=2CFD2FC41AF82B8DFB80E9BD1C989ECE
CT10=31C5D5E27EAF073E5C21ADAAEAA969D4
CT11=1DB94956A7268B0DE963D27E55868580
CT=0060BFFE46834BB8DA5CF9A61FF220AE
Decripcion :
CT =0060BFFE46834BB8DA5CF9A61FF220AE
PT1=C7799548F3FDF9984AD303B287A6C5AC
PT2=71411E8BA2CD0B1C0F46155D9C54F17A
PT3=9F2A71DB11E7BECA5A9274F60B4E7958
PT4=60B5B4C0144E67E751C07DBEDCEE4BA0
PT5=E97E516F5480FED58CAA61C34A4A750F
PT6=C4482E7BC1B9AF8C92FD6B05A232CF1D
PT7=63D0ECE34EBCA20604E3EDCDF3399852
PT8=2BE8B69B183C32F43BF7B48E454AC58D
PT9=B472A00EC795C3DA433737E9ED8F2516
PT10=8F38815EF53F8851E2B7A39275409DB8
PT11=63636363636363636363636363636363
PT=000102030405060708090A0B0C0D0E0F
========================================
TAMANO_LLAVE =256
LLAVE=000102030405060708090A0B0C0D0E0F101112131415161718191A1B1C1D1E1F
Encripcion :
TEXTO =000102030405060708090A0B0C0D0E0F
CT1=73727170777675747B7A79787F7E7D7C
CT2=4E5D32BB8B67FD1BD4CFEC9FFB20AC4F
CT3=96A212E486341549C4AAF7C843F0277A
CT4=0F45F284CDD0CB16E3EA81ECC891A4E1
CT5=E59BFC458A89063E0137BBE6DB63A058
CT6=1D958D960EA3143383C17D5CD87BA327
CT7=43843EF40D9219481935B77A586DB5DE
CT8=5AA5ABADBC40230CBA6124E9FAEEEFB5
CT9=DAD61937BDFD582927F14C990C5FC761
CT10=E8A48C5DEE5C0792AB6DFFF5B038529D
CT11=4B71E5A8BFB4E9A5312A18119E68E829
CT12=DCBA75CEE6589DDC0D289A172E8415B5
CT13=8A0E856B2074C1093104131D0628BFE8
CT=5A6E045708FB7196F02E553D02C3A692
Decripcion :
CT=5A6E045708FB7196F02E553D02C3A692
PT1=866AB8D58E34598BD75F9D8631F45EF0
PT2=B38DADA508E59BC2C745D9060BA31E82
PT3=9B4A165E283C004C6207644FE749C5E6
PT4=575429EF7AA1C69ACCCFD4A5FEF66AEE
PT5=BE0936D565EFDF95F42862FE2D06261E
PT6=1A4FA91DD796D5BFD43CB2526A5FD4DA
PT7=A40AFFCCAB780A90EC215DC3612AFA4A
PT8=D9A7EA6A7E9AE06E7CFBB0B2B9146F8E
PT9=76700CF8BD87495F11818947E86E1FCE
PT10=901868DA44ACCC691C8CC93B1A3A59E8
PT11=2F85CE843D8A91EA48B723AF0F4C54DB
PT12=8F38B610F5DAFF5121F3A392D2409DBC
PT13=63636363636363636363636363636363
PT=000102030405060708090A0B0C0D0E0F
B.4.5. Documentos de soporte

[1] “Request for Comments on Candidate Algorithms for the Advanced Encryption
Standard (AES)”, Federal Register, Volume 63, Number 177, pp. 49091-49093,
Sept 14, 1998.
[2] RSA97 Data Security Inc., “Goverment Encription Standard Takes a Fall.” RSA
Data Press Relace, Junio 17 1997.
[3] J. Daemen, “Cipher and Hash Function Design Strategies Based on Linear and
Diferential Cryptanalysis,” Doctoral Dissertartion, Marzo 1995, K.U.Leuven.
[4] Murphy, S., “The Cryptoanalisys of FEAL-4 whit 20 Choosen Plaintext,” journal
of criptology, No 3, 1990.
[5] Matsui, M., “Linear Criptoanlisys Method of DES Cipher,” proceedings, EURO-
CRYPT’93, 1993.
[6] Nyberg, K., “Differentially uniform mappings for cryptography,”Advances in Cryp-

tology,Proceedings EUROCRYPT’93, LNCS 795,Helleseth, Ed, Springer-Verlag,
1994, pp 55-64.
[7] Joan Daemen and Vincent Rijmen. “AES proposal: Rijndael” AES Round 1 Tech-
nical Evaluation, Documentation. NIST, Agosto 1998. http://www.esat.kuleuven.
ac.be/~rijmen/rijndael/
[8] Henri Gilbert y Marine Minier. “A collision attack on 7 rounds of Rijndael”. In

The third Advanced Encryption Standard Candidate Conference, páginas 230—241.
NIST, Abril 2000. http://www.nist.gov/aes.
[9] J. Daemen, L. Knudsen, y V. Rijmen, “The block cipher Square”, Fast Software
Encryption ’97, páginas 149—165. 1997.
[10] Niels Ferguson, John Kelsey, Stefan Lucks, Bruce Schneier, Mike Stay, David Wag-
ner, and Doug Whiting, “Improved Cryptanalysis of Rijndael”, 2001.
Apéndice C
Características de los MOTE
En la Figura C.1 se muestra la comparación de las características de estos MOTES

mediante un diagrama Kiviat. Una mayor área en la gráfica significa mejores carac-
terísticas sobre los demás miembros comparados.
Figura C.1: Comparación de características básicas.
113
114 APÉNDICE C. CARACTERÍSTICAS DE LOS MOTE
Memoria de Memoria de Sensores

Arquitectura Velocidad Almacenamiento I/O externas Tamaño
programas datos integrados
16 8 49 10 1024 16 5 2700
8 8 128 64 180 40 1 1800
8 8 128 4 512 50 2 1800
8 8 128 4 512 50 2 2200
8 4 128 4 512 18 2 500
16 8 48 10 1024 40 3 2580
16 12 128 5 512 17 1 4318
16 32 128 8 32768 20 5 5000
8 8 128 4 512 20 0 5000
Figura C.2: Datos de la gráfica Kiviat.
Nombre CPU Memoria I/O Sensores Radio

Tmote 8Mhz Texas 10 K RAM y 49 K Humedad, temperatura y luz 250 kbps 2.4 GHzIEEE Chipcon
Instruments Flash 802.15.4
MSP430
microcontrolador
Btnode Atmel 64+180 K SRAM, UART, SPI, I2C, GPIO, ADC, Clock, Chipcon CC1000 en banda ISM
128 K Flash ROM, Timer, LEDs Standard Molex
ATmega128L(AVR 433‐915 MHz
4 K EEPROM
RISC 8 MHz @ 8 1.25mm Wire‐to‐Board and
MIPS) Hirose DF17 Board‐to‐Board
connectors
Mica2 Atmel Atmega 128L 4K RAM y 128K Conector de expansión 315, 433 ó 868/916Mhz
Flash transciever multicanal con 38
Kbps
MicaZ Atmel Atmega 128 4K RAM y 128K Conector de expansión Transciever 802.15.4/ZigBee
Flash de RF
Mica2Dot Atmel Atmega 128 4K RAM y 128K Conector de expansión Transciever 802.15.4/ZigBee
Flash de RF
Telos Motorola HCS08 4K RAM USB and Etherner 250Kbps 2.4 GHz para IEEE
802.15.4 y ZigBee
Ember node Atmel ATmega128L‐ 1 Inyector de corriente sobre EM2420 radio transciever
EM2420DK 8MI MCU Ethernet ZigBee e IEEE 802.15.4
compatible basado en CC2420
CC2430DB Texas Instruments 8K RAM y 128K Sensor de Luz CC2420 para IEEE 802.15.4 y

SoC CC2430 Flash Acelerómetro de dos ejes ZigBee 2.4 Ghz, 250 Kbps
Sensor de temperatura
Monitor de batería
Potenciómetro
Botón de presión y joystick
LEDs
Arduino Atmel Atmega 128 4K RAM y 128K Conector de expansión EM2420 radio transciever
Flash ZigBee e IEEE 802.15.4
compatible
Figura C.3: Características generales de MOTE.

Apéndice D
Instalación de la red
La WSN está formada por nodos sensores, una compuerta (Gateway) y una estación
base. Para ello se utilizaron las tarjetas 5 tarjetas Texas Instruments, ver Fig. 1, de las
cuales 4 tarjetas CC2431EM para los sensores con sus respectivas tarjetas de baterías,
1 tarjeta de desarrollo SmartRF04EB para la compuerta. Para la estación base se usó
una computadora de escritorio de uso genérico.
Componente Descripción
CC2430/31 EM
SmartRF04EB
Computadora portátil
115
116 APÉNDICE D. INSTALACIÓN DE LA RED
Figura D.1: Tarjeta de demostración CC2430DB.
D.1. Instalación física de la red

Las tarjetas de los sensores cuentan con switches o jumpers, como se ve en la Fig.
D.1 , con los que se configuran para realizar las funciones.
La instalación física de la red quedó como se muestra en la Fig. D.2, los enlaces de
los nodos sensores hacia la EB se realizaron por medio de la compuerta.
Nodos
n1
Tarjeta de desarrollo
n2
n3
Estación Base
n4
n5
Figura D.2: Instalación física de la red.
D.2. Configuración de la red

D.2.1. Preparación inicial del ambiente operativo
Instalación de la máquina virtual en la EB. Con el objetivo de aislar el desarrollo de
otros elementos en la computadora y para evitar que las configuraciones y aplicaciones
de la instalación principal del equipo no interfirieran el proceso de desarrollo y al mismo
D.2. CONFIGURACIÓN DE LA RED 117
tiempo para proveer un ambiente portable a otros equipos, en caso de falla o para
desarrollos futuros, se instala una máquina virtual basada en productos de VMWare.
La versión de sistema operativo que se seleccionó fue Windows XP en una ver-
sión “Performance” o bien de alto rendimiento, lo cual implica retirar todos aquellos
manejadores y bibliotecas que no son requeridos, esto asegura que sea más rápida la
inicialización y el funcionamiento del sistema operativo.
Instalación de los controladores. Al intentar instalar los controladores para las tarje-
tas de los nodos y de la compuerta, se identificó que esta versión no contiene la biblioteca
del sistema operativo que permite activar el asistente que busca los controladores en las
bases de Internet. Aún localizando dichos controladores e iniciando la instalación de los
mismos a mano, el proceso no puede ser finalizado de manera correcta. La afectación
principal de esta limitante se refiere a la incapacidad de poder programar o establecer
comunicación entre los dispositivos y la computadora. Por lo que se decidió abandonar
esta versión de la máquina virtual ya que rompe con el objetivo principal del proyecto.
La configuración finalmente se realizó en la versión profesional de Windows XP con
todos sus componentes. En esta versión, se hace la instalación del paquete de servicio más
reciente, así como los boletines de seguridad y actualizaciones necesarios, dejando esta
versión a punto. La máquina virtual configurada con el sistema operativo es respaldada
en este punto, de tal forma que las copias que se puedan realizar de la misma sirvan
como un punto de partida en dónde no se requiera iniciar desde cero.
Instalación de las aplicaciones. A continuación se hizo la descarga e instalación de
las aplicaciones del fabricante de las tarjetas, la pila del protocolo ZigBee, el analizador
de protocolos1 , el grabador de datos hacia las tarjetas de desarrollo, un monitor de las
tarjetas y la herramienta de desarrollo IAR2 que cuenta con una licencia de 30 días.
SampleApp tiene por objetivo el envío un mensaje en difusión hacia todos los nodos
conectados a la red ZigBee para que enciendan y apaguen uno de los diodos emisores
que contienen las tarjetas de desarrollo y demostración.
Se identifica que la estructura de la herramienta de desarrollo establece un perfil para
la aplicación y al mismo tiempo para el tipo de dispositivo que intervendrá en él, que
define su papel en la red y para el tipo de tarjeta o dispositivo que se empleará. Es decir,
existe una versión del desarrollo para un nodo Coordinador en una tarjeta de desarrollo
y su equivalente para la tarjeta de demostración. Lo anterior se repite para los nodos
ruteadores o terminales.
Explorando los ejemplos provistos, se identifica que existe otro dispositivo adicional
denominado tarjeta de baterías. Los cuales son los dispositivos adicionales del kit de de-
sarrollo y que sólo se pueden activar para ciertos ejemplos, como la demo de localización
y seguimiento de nodos.
A continuación se compiló la aplicación SampleApp y se descargó a las tarjetas
en dos versiones, coordinador y dispositivo final. Al reiniciar las tarjetas se estableció
entre ellas la conexión e identificación para formar la red. Al accionar los interruptores
programados, se verificó que los dispositivos enviaran los mensajes y las repuestas de
1
Packet Sniffer de Texas Instruments.
2
Descargado del sitio www.iar.com y correspondiente a la tarjeta de desarrollo ya mencionada.
recepción afirmativas, esto se verifico con el encendido intermitente de los diodos emisores
de luz (LED) en ambos dispositivos, confirmando la comunicación en dos vías.
Activación del nodo coordinador. El siguiente paso fue la activación del nodo coordi-
nador. La verificación de la existencia del nodo coordinador en la red se realizó cuando
todos los dispositivos se identificaron con éste y pasaron sus emisores a estado fijo. En
este punto, el nodo coordinador funge como compuerta estableciendo la comunicación
entre los nodos y la EB.
D.2.2. Pruebas de transmisión

Para efectuar las pruebas de transmisión se recurrió a ejecutar los ejemplos de
demostración del fabricante. El primero es invocado con la aplicación GeneralApp, que
envía la cadena de caracteres “Hello World” y la despliega en la pantalla de los disposi-
tivos, así como los mensajes de confirmación de recepción.
En la programación original de los dispositivos se recupera la dirección IEEE o MAC
del dispositivo durante el proceso de inicialización la cual se despliega en pantalla del
dispositivo. Esto confirma la posibilidad de identificación única del dispositivo y se asocia
a que el envío de una cadena de caracteres con esta información es posible.
La segunda prueba se ejecuta con la aplicación SimpleApp, que permite activar la
función de envío de mensajes “AF_DataRequest”, de tal forma que cualquier cadena de
longitud n pueda ser enviada. Esta función ya programada puede ser reutilizada para
los procesos del proyecto.
La prueba con la aplicación SerialApp facilita el manejo de los dispositivos como
puentes de comunicación entre computadoras u otros dispositivos que envíen y reciban
información vía un puerto de comunicación serial (RS232). Este es el primer paso hacia
el establecimiento de una interfaz entre computadoras y dispositivos. El propósito único
del programa es ser el reemplazo del cable serial de puerto a puerto entre dispositivos,
con la ventaja de la comunicación inalámbrica entre ambos a 38.4 Kbps ó 115.2 Kbps.
Después de haber establecido la comunicación alámbrica por medio de los puertos
serie, se procedió a configurar la conexión inalámbrica por medio de la activación del
protocolo ZigBee, para ello se decidió utilizar la herramienta Ztool desarrollada por
el fabricante. Para lograr la comunicación se decide encender los dispositivos al mismo
tiempo que se activa la herramienta Ztool para forzar que los mensajes de inicio culminen
con la detección del dispositivo. Esta herramienta muestra al dispositivo y el conjunto
de instrucciones del “stack” que están disponibles, de acuerdo con la programación del
dispositivo.
Se identificó que las pilas de instrucciones son activadas vía la configuración de op-
ciones del dispositivo en la herramienta de programación de IAR. Información obtenida
del manual de la herramienta IDE. Por lo que se decidió cambiar algunas de las con-
figuraciones para verificar la activación de diferentes pilas de instrucciones. Véase Fig.
D.3.
Se repite la prueba pero ahora para la petición de la dirección IEEE extendida del
dispositivo. Ver Figuras D.4 y D.5.
Figura D.3: Selección de las instrucciones.
Por último se solicita la información general del dispositivo. Ver figura D.6.
Se identificó que la herramienta Ztool se comunica mediante la interfaz del puerto

serial desarrollada para la pila del protocolo. En la documentación se refiere con el
número de documento F8W-2003-0001. La estructura básica de un mensaje incluye el
inicio de mensaje con un byte de longitud y de valor constante en 0x02. Esta notación
es la estándar para el formato hexadecimal en lenguaje C, pero se decide verificar que
el significado sea el mismo con la ejecución de comandos.
Dado que la herramienta Ztool arrojó un resultado de Versión 1.10 a la solicitud de
versión del dispositivo. Se decide utilizar esta respuesta como parámetro de control en
las pruebas de activación del protocolo serial. De acuerdo con la documentación, pág.
6, la instrucción SYS_VERSION presenta un número 0x0008 y una longitud de 0x00.
Por lo que el mensaje se construyó con el byte de inicio de secuencia y estos valores,
quedando como, 02 00 08 00.
Con la herramienta Putty se puede enviar la secuencia mediante el código ASCII
estándar. No obstante, si se desea transmitir datos en hexadecimal entonces se emplea
Advanced Serial Port Terminal, que adicionalmente permite la comunicación en binario.
En la Fig. D.7 se muestra la configuración de los parámetros de comunicación y en la
Fig. D.8 se muestra la transmisión de datos por el puerto serial.
Dentro del formato o estructura del protocolo serial se especifica que la longitud
mínima de un mensaje válido es de 5 bytes. El byte faltante lo constituye la secuencia
Figura D.4: Petición de la dirección IEEE.
de verificación del marco (FCS). La cual se construye con la operación XOR de todos
los bytes con excepción del byte de inicio de paquete (SOP). Para este caso, el XOR de
00 con 08 y su resultado con 00, por lo que el FCS tendrá un valor de 08. Ver Fig. D.9.
Al enviar otra secuencia, esta vez solicitando la dirección extendida del dispositivo,
para lo cual se construye la cadena: 02 00 11 00 11, el dispositivo respondió. Ver Fig.D.10.
Con este último experimento se concluyeron las pruebas de transmisión. Por lo que
se decidió integrar las peticiones a un programa en Visual Estudio, a fin de controlar el
envío y recepción de mensajes desde una aplicación propia.
D.2.3. Programación
Se optó por la programación en Visual Basic por las facilidades que presenta el
manejo de puerto serial. Para establecer una aplicación básica, se declaró una aplicación
con tres elementos básicos; un botón de acción, una caja de texto y un objeto de puerto.
El botón de acción envió la secuencia de bytes que solicita la versión del dispositivo. La
caja de texto se usó para el despliegue de la respuesta del dispositivo; y el objeto de
puerto se usó para activar el puerto de comunicación y los procesos asociados. Ver Fig.
D.11.
En el botón de acción se declaró la secuencia utilizando una variable tipo byte con
un arreglo que represente la secuencia antes probada: 02 00 08 00 08. Para transferir el
Figura D.5: Respuesta de la petición IEEE.
valor, se puede realizar de manera decimal con la función CByte, en caso de requerir
notación hexadecimal se puede utilizar la secuencia &H2, equivalente a CByte(2).
Dim data(4) As Byte

data(0) = CByte(2)
data(1) = CByte(0)
data(2) = CByte(8)
data(3) = CByte(0)
data(4) = CByte(8)
Con el puerto activado, la secuencia para enviar los datos de la variable es: Serial-
Port1.Write(data, 0, data.Length). Para dar tiempo a que el dispositivo responda y la
memoria de entrada tenga datos, se debe hacer una pausa, un segundo aproximadamente
para lograrlo se envía System.Threading.Thread.Sleep(1000).
Al activarse el evento de lectura de datos en el puerto, se hace el vaciado del buffer
en una variable. La cual debe ser ahora utilizada para el despliegue en la caja de texto.
Se identifica que no es factible el paso directo de la información del buffer hacia la caja
de texto, por violar las reglas de programación.
Al ajustar los valores y programación se obtiene la respuesta deseada, la cual confirma
el envío y recepción de datos correctos hacia el dispositivo.
Se decide interrumpir el proceso de programación del dispositivo para enfocar los
esfuerzos en la programación de los algoritmos de encripción del trabajo.
Figura D.6: Respuesta de la solicitud de la información general del dispositivo.
Figura D.7: Configuración de los parámetros de comunicación serial.

Figura D.8: Transmisión por el puerto serial.
Figura D.9: Transmisión de datos en el código binario.

Figura D.10: Respuesta a la solicitud de la dirección extendida.
Figura D.11: Aplicación de VB que solicita la versión del Firmware del dispositivo.
Apéndice E
Base de datos de los nodos
E.1. Estructura de la base de datos relacional

La base de datos relacional está conformada por cinco tablas que contienen la infor-
mación de los dispositivos, la estación base, sus identificadores únicos, certificados, etc.
Cada una de las tablas ha sido llevada a la tercera forma normal que se aplica para bases
de datos, por lo que la base de encuentra en la forma normal 3.
De acuerdo con [1], las formas normales son aplicadas a las tablas de una base de
datos. Decir que una base de datos está en la forma normal N es decir que todas sus
tablas están en la forma normal N.
En general, las primeras tres formas normales son suficientes para cubrir las necesi-
dades de la mayoría de las bases de datos y para el caso de este proyecto no resulta
diferente. El creador de las 3 primeras formas normales (o reglas) fue Edgar F. Codd [2].
E.2. Primera Forma Normal (1FN)

Una tabla está en Primera Forma Normal si y sólo si:
Todos los atributos son atómicos. Un atributo es atómico si los elementos del
dominio son indivisibles, es decir, mínimos.
La tabla contiene una clave primaria.
La tabla no contiene atributos nulos.
Si no posee ciclos repetitivos.
Una columna no puede tener múltiples valores ya que los datos son atómicos. (Si a
cada valor de X le pertenece un valor de Y, entonces a cada valor de Y le pertenece un
valor de X)
Esta forma normal elimina los valores repetidos dentro de una base de datos y les
asigna un identificador único.
125
126 APÉNDICE E. BASE DE DATOS DE LOS NODOS
E.2.1. Ejemplo 1: Dominios y valores

Suponga que un diseñador principiante desea guardar los nombres y los números
telefónicos de los clientes. Procede a definir una tabla de cliente como la que se ve en la
Figura E.1.
Cliente
ID Cliente Nombre Apellido Teléfono
123 Rachel Ingram 555‐861‐2025
456 James Wright 555‐403‐1659
789 Maria Fernandez 555‐808‐9633
Figura E.1: Base de datos incial.
En este punto, el diseñador se da cuenta de un requisito debe guardar múltiples

números telefónicos para algunos clientes. Razona que la manera más simple de hacer
esto es permitir que el campo “Teléfono” contenga más de un valor en cualquier registro
dado, como se muestra en la Figura E.2:
Cliente
555‐403‐1659
456 James Wright 555‐776‐4100
Figura E.2: Múltiples teléfonos para un cliente.
Asumiendo, sin embargo, que la columna “Teléfono” está definida en algún tipo de
dominio de número telefónico (por ejemplo, el dominio de cadenas de 12 caracteres de
longitud), la representación de arriba no está en 1FN. La 1FN prohíbe a un campo
contener más de un valor de su dominio de columna.
E.2.2. Ejemplo 2: Grupos repetidos a través de columnas

El diseñador puede evitar esta restricción definiendo múltiples columnas del número
telefónico, Figura E.3.
Sin embargo, esta representación hace uso de columnas que permiten valores nulos,
y por lo tanto no se conforman con la definición de la 1NF. Incluso si se contempla la
posibilidad de columnas con valores nulos, el diseño no está en armonía con el espíritu de
1NF. Teléfono 1, Teléfono 2, y Teléfono 3, comparten exactamente el mismo dominio y
E.2. PRIMERA FORMA NORMAL (1FN) 127
Cliente
ID Cliente Nombre Apellido Teléfono 1 Teléfono 2 Teléfono 3
123 Osvaldo Ingram 555‐861‐2025
456 James Wright 555‐403‐1659 555‐776‐4100
Figura E.3: Expansión de la tabla mediante la definición de más campos.
exactamente el mismo significado; el dividir del número de teléfono en tres encabezados

es artificial y causa problemas lógicos. Estos problemas incluyen:
Dificultad en hacer consultas a la tabla. Es difícil contestar preguntas tales como,

¿Qué clientes tienen el teléfono X? y ¿Qué pares de clientes comparten un número
de teléfono?
La imposibilidad de hacer cumplir la unicidad los enlaces Cliente-a-Teléfono por

medio del Relational Data Base Management System (Sistema de Manejo de Bases
de Datos Relacionales o RDBMS). Al cliente “789 ” se le puede dar equivocada-
mente un valor para el Teléfono 2 que es exactamente igual que el valor de su
Teléfono 1.
La restricción de los números de teléfono por cliente a tres. Si viene un cliente con
cuatro números de teléfono, estamos obligados a guardar solamente tres y dejar el
cuarto sin guardar. Esto significa que el diseño de la base de datos está imponiendo
restricciones al proceso del negocio, en vez de (como idealmente debe ser el caso)
al revés.
E.2.3. Ejemplo 3: Repetición de grupos dentro de columnas

El diseñador puede, alternativamente, conservar una sola columna de número de
teléfono, pero alterando su dominio, haciendo una cadena de suficiente longitud para
acomodar múltiples números telefónicos, Figura E.4.
Cliente
456 James Wright 555‐403‐1659, 555‐776‐4100
Figura E.4: Ampliación del tamaño del campo para albergar múltiples teléfonos.
Éste es defendiblemente el peor diseño de todos, y otra vez no mantiene el espíritu

de la 1NF. El encabezado “Teléfono” llega a ser semánticamente difuso, ya que ahora
puede representar, o un número de teléfono, o una lista de números de teléfono, o de
hecho cualquier cosa. Una consulta como, ¿Qué pares de clientes comparten un número
telefónico?, es virtualmente imposible de formular, dada la necesidad de proveerse de
listas de números telefónicos así como números telefónicos individuales. Con este diseño
en la RDBMS, son también imposibles de definir significativas restricciones en números
telefónicos.
E.2.4. Un diseño conforme con 1FN

Un diseño que está inequívocamente en 1FN hace uso de dos tablas: una tabla de
cliente y una tabla de teléfono del cliente, Figuras E.5 y E.6.
Cliente
ID Cliente Nombre Apellido
123 Rachel Ingram
456 James Wright
789 Maria Fernandez
Figura E.5: Primera tabla 1FN.
Teléfono del cliente
ID Cliente Teléfono
123 555‐861‐2025
456 555‐403‐1659
456 555‐776‐4100
789 555‐808‐9633
Figura E.6: Segunda tabla 1FN.
En este diseño no ocurren grupos repetidos de números telefónicos. En lugar de eso,

cada enlace Cliente-a-Teléfono aparece en su propio registro.
E.3. Segunda Forma Normal (2FN)

E.3.1. Dependencia funcional
Una relación está en 2FN [3] si está en 1FN y si los atributos que no forman parte
de ninguna clave dependen de forma completa de la clave principal. Es decir, que no
E.4. TERCERA FORMA NORMAL (3FN) 129
existen dependencias parciales.

En otras palabras podríamos decir que la segunda forma normal está basada en el
concepto de dependencia completamente funcional. Una dependencia funcional  → 
es completamente funcional si al eliminar los atributos  de  significa que la depen-
dencia no es mantenida, esto es que  ∈  ( − {}) −  →  . Una dependencia
funcional  →  es una dependencia parcial si hay algunos atributos que pueden ser
removidos de  y la dependencia todavía se mantiene, esto es  ∈  ( − {}) →  .
Por ejemplo, considere una tabla describiendo las habilidades de los empleados [3],
Figura E.7.
Habilidades de los empleados
Empleado Habilidad Lugar actual de trabajo
Jones Mecanografía 114 Main Street
Jones Taquigrafía 114 Main Street
Jones Tallado 114 Main Street
Bravo Limpieza ligera 73 Industrial Way
Ellis Alquimia 73 Industrial Way
Ellis Malabarismo 73 Industrial Way
Harrison Limpieza ligera 73 Industrial Way
Figura E.7: Tabla incial para la 2FN.
La única clave candidata de la tabla es {Empleado, Habilidad}.

El atributo restante, Lugar actual de trabajo, es dependiente solo en parte de la
clave candidata, llamada Empleado. Por lo tanto la tabla no está en 2NF. Observe la
redundancia de la manera en que son representados los “Lugares actuales de trabajo”:
nos dicen tres veces que Jones trabaja en la 114 Main Street, y dos veces que Ellis
trabaja en 73 Industrial Way. Esta redundancia hace a la tabla vulnerable a anomalías
de actualización: por ejemplo, es posible actualizar el lugar del trabajo de Jones en
sus registros “Mecanografía” y “Taquigrafía” y no actualizar su registro “Tallado”. Los
datos resultantes implicarían respuestas contradictorias a la pregunta, ¿Cuál es el lugar
actual de trabajo de Jones?
Un alternativa 2NF a este diseño representaría la misma información en dos tablas,
Figuras E.8 y E.9.
Las anomalías de actualización no pueden ocurrir en estas tablas, las cuales están en
2NF.
E.4. Tercera Forma Normal (3FN)

La tabla se encuentra en 3FN si es 2FN y cada atributo que no forma parte de
ninguna clave, depende directamente y no transitivamente, de la clave primaria.
Empleados
Empleado Lugar actual de trabajo
Jones 114 Main Street
Bravo 73 Industrial Way
Ellis 73 Industrial Way
Harrison 73 Industrial Way
Figura E.8: Separación de los datos tabla 1, 2FN.
Habilidades de los empleados
Empleado Habilidad
Jones Mecanografía
Jones Taquigrafía
Jones Tallado
Bravo Limpieza ligera
Ellis Alquimia
Ellis Malabarismo
Harrison Limpieza ligera
Un ejemplo de este concepto sería que, una dependencia funcional  →  en un

esquema de relación  es una dependencia transitiva si hay un conjunto de atributos 
que no es un subconjunto de alguna clave de , donde se mantiene  →  y  →  .
Un ejemplo de una tabla 2NF que falla en satisfacer los requerimientos de la 3NF
[4], Figura E.10.
La única clave candidato es {Torneo, Año}.
La violación de la 3NF ocurre porque el atributo no primario Fecha de nacimiento del
ganador es dependiente transitivamente de {Torneo, Año} vía el atributo no primario
Ganador. El hecho de que la Fecha de nacimiento del ganador es funcionalmente de-
pendiente en el Ganador hace la tabla vulnerable a inconsistencias lógicas, pues no hay
nada que impida a la misma persona ser mostrada con diferentes fechas de nacimiento
en diversos registros.
Para expresar los mismos hechos sin violar la 3NF, es necesario dividir la tabla en
dos, Figuras E.11 y E.12.
Ganadores del torneo
Torneo Año Ganador Fecha de nacimiento del ganador
Indiana Invitational 1998 Al Fredrickson 21 de julio de 1975
Cleveland Open 1999 Bob Albertson 28 de septiembre de 1968
Des Moines Masters 1999 Al Fredrickson 21 de julio de 1975
Indiana Invitational 1999 Chip Masterson 14 de marzo de 1977
Figura E.10: Tabla inicial 3FN.
Ganadores del torneo
Torneo Año Ganador
Indiana Invitational 1998 Al Fredrickson
Cleveland Open 1999 Bob Albertson
Des Moines Masters 1999 Al Fredrickson
Indiana Invitational 1999 Chip Masterson
Fecha de nacimiento del jugador
Jugador Fecha de nacimiento
Chip Masterson 14 de marzo de 1977
Al Fredrickson 21 julio de 1975
Bob Albertson 28 septiembre de 1968
Las anomalías de actualización no pueden ocurrir en estas tablas, las cuales están en
3NF.
La mayoría de las tablas 3NF están libres anomalías de actualización, inserción,
y borrado. Ciertos tipos de tablas 3NF, que en la práctica raramente se encuentran,
son afectadas por tales anomalías; éstas son tablas que no satisfacen la forma normal
de Boyce-Codd (BCNF) o, si satisfacen la BCNF, son insuficientes para satisfacer las
formas normales más altas 4NF ó 5NF.
El diagrama normalizado de las tablas propuestas para el manejo de los datos del
sistema se muestra en la Figura E.13.
Figura E.13: Estructura de tablas propuesta para el proyecto.
Dado que la trasmisión de datos numéricos o cadenas de caracteres vía puerto serial
no tiene diferencia alguna, ya que se transmiten cadenas de 8 bits para conformar uno
de ellos. Las tablas de la base de datos se han construido en general con campos tipo
texto. Todas estas definiciones se pueden observar con detalle en las Figuras E.14, E.15,
E.16, E.17 y E.18.
Nombre Tipo Tamaño

Id_AI Texto 1
Nombre Texto 50
Figura E.14: Catálogo de algoritmos para firmar el certificado.
Nombre Tipo Tamaño

Id_CA Texto 1
Tipo Texto 50
Figura E.15: Catálogo de tipos de dispositivos.

Nombre Tipo Tamaño

Id_certificado Texto 5
Version Texto 2
Id_AI Texto 1
Id_CA Texto 1
UCA Texto 5
Id_mote Texto 5
Fecha_inicio Fecha/Hora 8
Fecha_fin Fecha/Hora 8
Firma Texto 28
Figura E.16: Datos para los certificados.
Nombre Tipo Tamaño

Id_DatoEB Texto 5
au Texto 3
ru Texto 3
Ke Texto 8
Id_Mote Texto 5
Figura E.17: Datos para la Estación Base.
Nombre Tipo Tamaño

Id_mote Texto 5
IEEE Texto 16
Memoria Texto 4
ke Texto 8
av Texto 3
rv Texto 3
Figura E.18: Datos para los MOTE.

Una vista, de un conjunto de datos de ejemplo, del sistema de bases de datos puede
construir la descripción de los certificados de los dispositivos en la EB, Figura E.19. Estos
datos son utilizados para construir la cadena de caracteres que viajarán en la parte útil
de la trama de ZigBee.
Figura E.19: Vista de los datos del certificado.
E.4.1. Documentos de soporte

[1] Wikipedia, “Normalización de Bases de Datos.” [En línea]. http://es.wikipedia.org/
wiki/Normalizaci %C3 %B3n_de_bases_de_datos
[2] Codd, E. F., “A Relational Model of Data for Large Shared Data Banks Commu-
nications of the ACM,” Vol. 13, No. 6, June 1970, pp. 377-387
[3] Wikipedia, “"2NF.” [En línea]. http://es.wikipedia.org/wiki/2NF
[4] Wikipedia, “"3NF.” [En línea].(http://es.wikipedia.org/wiki/3NF

Apéndice F
Programas
F.1. MTI
F.1.1. Algoritmo de acuerdo de la llave MTI1
Figura F.1: Forma para el acuerdo de la llave MTI.
Public Class Form1

Public p1, au As Double
’Titulo: Algoritmo de acuerdo del la llave MTI
’Version: 1.0
1
Se han eliminado todos los acentos en el código presentado, aunque en Visual Basic son soportados,
la herramienta de edición usada para el trabajo tiene limitantes con los caracteres a desplegar.
135
136 APÉNDICE F. PROGRAMAS
’Autor: Miguel Alfredo Acedo Arias

’Lugar: MEXICO - IPN - CIDETEC
’Tesis: PROTOCOLO CRIPTOGRAFICO PARA LA AUTENTICACION DE NODOS
’ BASADO EN EL ESQUEMA PKI PARA REDES INALAMBRICAS DE
’ SENSORES
Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As _

System.EventArgs) Handles Button1.Click
’Ejecuta el algoritmo de MTI y verifica que ku y kv sean iguales
Dim contador#, alfa#, av#, bu#, bv#, ru#, rv#, su#, sv#, k1#, k2#
contador = 1
p = 29
alfa = 7
Do Until k1 = k2 And k1 > 0 And k2 > 0

contador += 1
If contador >= 50000 Then
Exit Sub
End If
TextBox7.Text = p
TextBox13.Text = alfa
p1 = Val(TextBox7.Text)
Gen()
TextBox8.Text = au1
TextBox9.Text = av1
TextBox10.Text = ru1
TextBox11.Text = rv1
au = Val(TextBox8.Text)
av = Val(TextBox9.Text)
ru = Val(TextBox10.Text)
rv = Val(TextBox11.Text)
bu = nMod((alfa âu), p1)

bv = nMod((alfa âv), p1)
su = nMod((alfa ^ru), p1)

sv = nMod((alfa ^rv), p1)
F.1. MTI 137
k1 = nMod(((sv âu) * (bv ^ru)), p1)

k2 = nMod(((su âv) * (bu ^rv)), p1)
Loop
TextBox1.Text = bu
TextBox2.Text = bv
TextBox3.Text = su
TextBox4.Text = sv
TextBox5.Text = k1
TextBox6.Text = k2
End Sub
Private Function nMod(ByVal x As Double, ByVal y As Double) As Double

’Reemplaza la funcion modular de z = x Mod y
’a z = nMod(x,y)
On Error Resume Next
Dim z#
z = x - (Int(x / y) * y)
nMod = z
End Function
End Class
F.2. RSA
F.2.1. Código de encripción/decripción

Imports System.Math
Imports System.Security.Cryptography
Imports System.Text
Module RSAv1
’Titulo: Algoritmo de encripcion y decripcion basado en RSA

’Version: 1.0
’Autor: Miguel Alfredo Acedo Arias
’Lugar: MEXICO - IPN - CIDETEC
’Tesis: PROTOCOLO CRIPTOGRAFICO PARA LA AUTENTICACION DE NODOS
’ BASADO EN EL ESQUEMA PKI PARA REDES INALAMBRICAS DE
’ SENSORES
Public key(0 To 2) As Double

Public p As Double, q As Double
Public PHI As Double
Public Sub keyGen()

’Genera las llaves para e,d y n
Dim E#, D#, N#

’fija el limite superior del numero aleatorio
Const PQ_UP As Double = 9999
’fija el limite inferior del numero aleatorio

Const PQ_LW As Double = 3333
’valor fijo para una llave de 24 bits minimo

Const KEY_LOWER_LIMIT As Long = 10000000
p = 0 : q = 0
Randomize()
’Nos aseguramos de que la llave sea de 24 bits minimo

Do Until D > KEY_LOWER_LIMIT
’Nos aseguramos que p y q sean primos

F.2. RSA 139
Do Until EsPrimo(p) And EsPrimo(q)

p = Int((PQ_UP - PQ_LW + 1) * Rnd() + PQ_LW)
q = Int((PQ_UP - PQ_LW + 1) * Rnd() + PQ_LW)
Loop
N = p * q
PHI = (p - 1) * (q - 1)
E = mcd(PHI)
D = Euclides(E, PHI)
Loop
key(0) = E
key(1) = D
key(2) = N
End Sub
Private Function Euclides(ByVal E3 As Double, ByVal PHI3 As Double) _

As Double
’Generamos d mediante (e y phi) usando el algoritmo de Euclides
Dim u1#, u2#, u3#, v1#, v2#, v3#, q#

Dim t1#, t2#, t3#, z#, uu#, vv#, inverse#
u1 = 1
u2 = 0
u3 = PHI3
v1 = 0
v2 = 1
v3 = E3
Do Until (v3 = 0)
q = Int(u3 / v3)
t1 = u1 - q * v1
t2 = u2 - q * v2
t3 = u3 - q * v3
u1 = v1
u2 = v2
u3 = v3
v1 = t1
v2 = t2
v3 = t3
z = 1
Loop
uu = u1
vv = u2
If (vv < 0) Then

inverse = vv + PHI3
Else
inverse = vv
End If
Euclides = inverse
End Function
Private Function mcd(ByVal nPHI As Double) As Double

’Genera un numero aleatorio que es primo relativo a phi
Dim nE#, y#
’fija el limite superior para el numero E

Const N_UP = 99999999
’fija el limite inferior para el numero E

Const N_LW = 10000000
Randomize()
nE = Int((N_UP - N_LW + 1) * Rnd() + N_LW)
top:
Dim x As Long
x = nPHI Mod nE
y = x Mod nE
If y <> 0 And EsPrimo(nE) Then
mcd = nE
Exit Function
F.2. RSA 141
Else
nE = nE + 1
End If
GoTo top
End Function
Private Function EsPrimo(ByVal lngNumber As Double) As Boolean

’Regresa el valor logico ’True’ si el numero es primo
Dim lngCount#
Dim lngSqr#
Dim x#
’Se obtiene el valor entero de la raiz cuadrada

lngSqr = Int(Sqrt(lngNumber))
If lngNumber < 2 Then

EsPrimo = False
Exit Function
End If
lngCount = 2
EsPrimo = True
If lngNumber Mod lngCount = 0 Then

EsPrimo = False
Exit Function
End If
lngCount = 3
For x = lngCount To lngSqr Step 2
If lngNumber Mod x = 0 Then

EsPrimo = False
Exit Function
End If
Next
End Function
Public Function Mult(ByVal x As Double, ByVal p As Double, _

ByVal m As Double) As Double
’Funcion de multiples operaciones: encripta y decripta los
’parametros pasados a la funcion por ejemplo:
’Mult = MÊ mod N (encrypt) donde M = x , E = p, N = m
’Mult = M^D mod N (decrypt) donde M = x , D = p, N = m
On Error GoTo error1
Dim y As Integer
y = 1
Do While p > 0
Do While (p / 2) = Int((p / 2))

x = nMod((x * x), m)
p = p / 2
Loop
y = nMod((x * y), m)
p = p - 1
Loop
Mult = y
Exit Function
error1:
y = 0
End Function
Private Function nMod(ByVal x As Double, ByVal y As Double) As Double

’Esta funcion sustituye el comando Mod por omision.
’En lugar de usar z = x Mod y
’Ahora se usa z = nMod(x,y)
Dim z#
F.2. RSA 143
z = x - (Int(x / y) * y)
nMod = z
End Function
Public Function enc(ByVal tIp As String, ByVal eE As Double, ByVal eN _

As Double) As String
’Regresa el valor de la cadena de caracteres con un signo +
’como delimitador
’Por ejemplo 12345678+23456789+ etc..
’Se ha extraido este paso del algoritmo de encripcion para
’simplificacion del mismo
Dim encSt As String

Dim e2st As String
encSt = ""
e2st = ""
If tIp = "" Then Exit Function

For i = 1 To Len(tIp)
encSt = encSt & Mult(CLng(Asc(Mid(tIp, i, 1))), eE, eN) & "+"
Next i
’En este punto se puede agrerar el algoritmo de encripcion
enc = encSt
End Function
Public Function dec(ByVal tIp As String, ByVal dD As Double, _

ByVal dN As Double) As String
’Regresa una cadena de caracteres
’por ejemplo A = 12345678, B = 23456789 etc..
’Se ha extraido este paso del algoritmo de decripcion para
’simplificaci\U{f3}n del mismo
Dim decSt As String

Dim ptr As String
Dim tok As String

decSt = ""
’’En este punto se puede agrerar el algoritmo de decripcion
For z = 1 To Len(tIp)
ptr = InStr(z, tIp, "+")
tok = Val(Mid(tIp, z, ptr))
decSt = decSt + Chr(Mult(tok, dD, dN))
z = ptr
Next z
dec = decSt
End Function
F.2.2. Firma HASH basada en SHA-1
Function CreateHash(ByVal inCadena As String) As String
Dim UE As New UnicodeEncoding

Dim bHash As Byte()
’Almacena la cadena ingresada en una matriz de bytes

Dim bCadena() As Byte = UE.GetBytes(inCadena)
Dim s1Service As New SHA1CryptoServiceProvider ’28 de longitud
’Dim s1Service As New MD5CryptoServiceProvider ’24 de longitud
’Crea el hash
bHash = s1Service.ComputeHash(bCadena)
’regresa como una cadena codificada en base64

Dim Resumen As String
Resumen = Convert.ToBase64String(bHash)
Return Resumen
End Function
End Module
F.3. FORMA 145
F.3. Forma
F.3.1. Código base de la forma
Figura F.2: Forma base para RSA, SHA1 y DH.
Imports System
Imports System.IO.Ports
Imports System.Text
Imports System.Security
Imports System.Security.Cryptography
Public Class Form1

Dim E, D, N As Double
Dim strRecepcion As String
Dim strWeight As String
Dim valor As String

Dim bytes As Integer
Dim bufferIn() As Byte
Dim boton As Integer
Dim longitud As Integer
Dim dirMemoria As Integer = 65300
Function Asc2hex(ByVal SAscii)

’Conversion de ASCII a Hexadecimal
Dim i As Integer, VHex As String
VHex = ""
For i = 1 To Len(SAscii)
VHex = VHex & Microsoft.VisualBasic.Right("0" & Hex((Asc(Mid_
(SAscii, i, 2)))), 2) & " "
Next i
Asc2hex = VHex
End Function
Function Asc2bin(ByVal SAscii)

’Conversion de ASCII a Binario
Dim i As Integer, VBin As String

VBin = ""
For i = 1 To Len(SAscii)
VBin = VBin & Hex2Bin(Microsoft.VisualBasic.Left(Hex((Asc(Mid _
(SAscii, i, 2)))), 1)) & Hex2Bin(Microsoft.VisualBasic.Right_
(Hex((Asc(Mid(SAscii, i, 2)))), 1)) & " "
Next i
Asc2bin = VBin
End Function
Private Function Hex2Bin(ByVal DatoHex As String) As String

’Conversion de Hexadecimal a Binario
Select Case LCase(DatoHex)

Case "0"
Hex2Bin = "0000"
Case "1"
F.3. FORMA 147
Hex2Bin = "0001"
Case "2"
Hex2Bin = "0010"
Case "3"
Hex2Bin = "0011"
Case "4"
Hex2Bin = "0100"
Case "5"
Hex2Bin = "0101"
Case "6"
Hex2Bin = "0110"
Case "7"
Hex2Bin = "0111"
Case "8"
Hex2Bin = "1000"
Case "9"
Hex2Bin = "1001"
Case "a"
Hex2Bin = "1010"
Case "b"
Hex2Bin = "1011"
Case "c"
Hex2Bin = "1100"
Case "d"
Hex2Bin = "1101"
Case "e"
Hex2Bin = "1110"
Case "f"
Hex2Bin = "1111"
Case Else
MsgBox("Valor no admitido!")
End Select
End Function
Private Sub cmdKeyGen_Click(ByVal sender As System.Object, ByVal e _

As System.EventArgs) Handles cmdKeyGen.Click
’Ejecuta la generacion de llaves y despliega los valores
’calculados en las cajas de texto
keyGen()
txtP.Text = p ’P
txtQ.Text = q ’Q
txtPhi.Text = PHI ’PHI
txtE.Text = key(0) ’E
txtD.Text = key(1) ’D
txtN.Text = key(2) ’N
cmdDecrypt.Enabled = True
cmdEncrypt.Enabled = True
cmdHash.Enabled = True
End Sub
Private Sub cmdEncrypt_Click(ByVal sender As System.Object, ByVal e _

As System.EventArgs) Handles cmdEncrypt.Click
’Activa el proceso de encripcion sobre el valor contenido
’en la caja de Texto Claro
cmdKeyGen.Enabled = False
Text9.Text = enc(Text3.Text, key(0), key(2))
Text1.Text = Asc2hex(Text9.Text)
Text2.Text = Len(Text9.Text)
Text4.Text = Asc2bin(Text9.Text)
Text10.Text = ""
End Sub
Private Sub cmdDecrypt_Click(ByVal sender As System.Object, ByVal e _

As System.EventArgs) Handles cmdDecrypt.Click
’Activa el proceso de decripcion sobre el valor en la
’caja de Texto encriptado
Text10.Text = dec(Text9.Text, key(1), key(2))

End Sub
Private Sub Button1_Click(ByVal sender As System.Object, ByVal e _

As System.EventArgs) Handles Button1.Click
’Envia la solicitud de la direccion IEEE del dispositivo
boton = 1
’Datos para la dir. IEEE

F.3. FORMA 149
Dim data(4) As Byte

data(0) = &H2
data(1) = &H0
data(2) = &H11
data(3) = &H0
data(4) = checkSum(data)
’Datos para leds en intermitencia

’Dim data(7) As Byte
’data(0) = &H2
’data(1) = &H0
’data(2) = &H19
’data(3) = &H2
’data(4) = &HFF
’data(5) = &H3
’data(6) = &HE7
’Envio de datos por el puerto serial

SerialPort1.Write(data, 0, data.Length)
’Pausa para dar tiempo a que ocurra el evento de lectura

’de datos en el buffer de entrada
System.Threading.Thread.Sleep(1000)
’Forma alterna de enviar los datos

’dato = &H40 & &H2 & &H0 & &H11 & &H0 & &H11
limpiar()
’Depliegue en pantalla de los procesos de solicitud y respuesta

RichTextBox1.AppendText("Dato enviado " & ByteArrayToString(data)_
& vbCrLf & "Esperando datos del Chip CC3140" & vbCrLf & "Longitud_
de la respuesta: " & longitud & " bytes")
’Conversion del arreglo de bytes a cadena de datos

TextBox1.Text = ByteArrayToString(bufferIn)
’Salida para la direccion IEEE del dispositivo, elimina los

’primeros 4 bytes cabeza de mensaje y los ultimos
Text3.Text = strWeight.Substring(8, 16)
End Sub
Private Sub SerialPort1_DataReceived(ByVal sender As System.Object,_

ByVal e As System.IO.Ports.SerialDataReceivedEventArgs) Handles _
SerialPort1.DataReceived
’Funcion que captura el evento de datos recibidos en el puerto serial
longitud = SerialPort1.BytesToRead()
Dim buffer1(longitud - 1) As Byte
SerialPort1.Read(buffer1, 0, longitud)
bufferIn = buffer1
valor = SerialPort1.ReadExisting()
bytes = valor.Length
’pausa para recibir los datos

strWeight = ByteArrayToString(bufferIn)
End Sub
Private Sub Form1_Load(ByVal sender As Object, ByVal e As System._

EventArgs) Handles Me.Load
’Se prepara el puerto serial para el envio y recepcion de datos
SerialPort1.Open()
End Sub
Public Function hex2ascii(ByVal hextext As String) As String

’Convierte datos de Hexadecimal a ASCII
Dim num As String

Dim value As String = ""
For y = 1 To Len(hextext)
num = Mid(hextext, y, 2)
value &= Chr(Val("&h" & num))
y = y + 1
Next y
hex2ascii = value
End Function
Public Function BinToHex(ByVal BinStr As String) As String

’Convierte datos de Binario a Hexadecimal
F.3. FORMA 151
Dim HexStr As String

HexStr = ""
Dim i As Integer
For i = 1 To Len(BinStr) Step 4
HexStr = HexStr & DecToHex(BinToDec(Mid(BinStr, i, 4)))
Next i
BinToHex = HexStr
End Function
Public Function DecToHex(ByVal DecNum As Double) As String

’Convierte datos de Decimal a Hexadecimal
Dim remainder As Integer

Dim HexStr As String
HexStr = ""
Do While DecNum <> 0
remainder = DecNum Mod 16 ’Este metodo puede causar sobre flujo
If remainder <= 9 Then
HexStr = Chr(Asc(remainder)) & HexStr
Else
HexStr = Chr(Asc("A") + remainder - 10) & HexStr
End If
DecNum = DecNum \ 16
Loop
If HexStr = "" Then HexStr = "0"
DecToHex = HexStr
End Function
Public Function BinToDec(ByVal BinStr As String) As Double

’Convierte datos de Binario a Decimal
Dim mult As Double

Dim DecNum As Double
mult = 1
DecNum = 0
Dim i As Integer
For i = Len(BinStr) To 1 Step -1
If Mid(BinStr, i, 1) = "1" Then
DecNum = DecNum + mult
End If
mult = mult * 2
Next i
BinToDec = DecNum
End Function

As System.EventArgs) Handles cmdGrabar.Click
’Envia un valor a la memoria no volatil del dispositivo
boton = 2
Dim j As String = dirMote(dirMemoria + Val(TextBox3.Text))

’dirMemoria tiene el valor base de la memoria no volatil
Dim b1 As String = "&H" & j.Substring(0, 2)
’Datos para grabar el valor XX en la direccion XXXX

Dim data(7) As Byte
data(0) = &H2 ’Inicio de mensaje
data(1) = &H0 ’Numero de comando
data(2) = &H2 ’Numero de comando
data(3) = &H3 ’Longitud del mensaje en bytes
data(4) = b1 ’direccion de la memoria
data(5) = b2 ’direccion de la memoria
If Val(TextBox4.Text) >= 0 And Val(TextBox4.Text) <= 255 Then

data(6) = Val(TextBox4.Text) ’valor a guardar en la direccion
End If
data(7) = checkSum(data) ’Funcion ckeckSum, se construye con el

’XOR desde el dato 1 y hasta 6

’Pausa para dar tiempo a que ocurra el evento de lectura de

’datos en el buffer de entrada
limpiar()

RichTextBox1.Text = ("Dato enviado " & ByteArrayToString(data)_
F.3. FORMA 153
& vbCrLf & "Esperando datos del Chip CC3140" & vbCrLf & _
"Longitud de la respuesta: " & longitud & " bytes")

’Salida para la direccion IEEE del dispositivo, elimina los

’primeros 4 bytes cabeza de mensaje y los ultimos
If strWeight.Substring(8, 2) = "00" Then
Text3.Text = "Grabacion existosa"
Else
Text3.Text = "El valor no pudo grabarse"
End If
’TextBox3.Text = b1 & " " & b2
End Sub

As System.EventArgs) Handles cmdLeer.Click
’Funcion para consultar un valor de la memoria del dispositivo
boton = 3
Dim j As String = dirMote(dirMemoria + Val(TextBox3.Text))

’Datos para leer el dato de la direccion XXXX

Dim data(6) As Byte
data(0) = &H2
data(1) = &H0
data(2) = &H1
data(3) = &H2
data(4) = b1
data(5) = b2
data(6) = checkSum(data)

’Pausa para dar tiempo a que ocurra el evento de lectura de

’datos en el buffer de entrada
limpiar()
RichTextBox1.Text = ("Dato enviado " & ByteArrayToString(data) _
& vbCrLf & "Longitud enviada: " & data.Length & vbCrLf & "Esperando_
datos del Chip CC3140" & vbCrLf & "Longitud de la respuesta: " & _
longitud & " bytes")

’Salida para la direccion IEEE del dispositivo, elimina los primeros

’4 bytes cabeza de mensaje y los ultimos
Text3.Text = strWeight.Substring(10, 2)
’TextBox3.Text = b1 & " " & b2
End Sub
Private Sub cmdHash_Click(ByVal sender As System.Object, ByVal e As _

System.EventArgs) Handles cmdHash.Click
’Activa la generacion de la firma Hash con los datos del campo
’de Texto encriptado
txtHash.Text = CreateHash(Text9.Text)
lblHash.Text = Len(txtHash.Text)
End Sub
Function ByteArrayToString(ByVal arrInput() As Byte) As String

’Convierte un arreglo de bytes a una cadena
’Da formato a la salida que se presenta como Hexadecimal
Dim i As Integer
Dim sOutput As New StringBuilder(arrInput.Length)

For i = 0 To arrInput.Length - 1
sOutput.Append(arrInput(i).ToString("X2"))
Next
Return sOutput.ToString()
End Function
Private Sub limpiar()

’Elimina datos de las cajas de texto en ciertos procesos
F.3. FORMA 155
TextBox1.Text = ""
Text3.Text = ""
RichTextBox1.Text = ""
End Sub
Function checkSum(ByVal arrInput() As Byte) As Integer

’Calculo del ultimo byte para el protocolo serial
Dim i As Integer
Dim iOutput As Integer = 0
For i = 1 To arrInput.Length - 1
iOutput = iOutput Xor arrInput(i)
Next
Return iOutput
End Function
Function dirMote(ByVal valor As Integer) As String

’Conversion de la direccion de memoria del mote a cadena
Dim convert As String
convert = DecToHex(valor)
Return convert
End Function
End Class

Protocolocrip PDF

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Protocolocrip PDF

Caricato da

Copyright:

Formati disponibili

INSTITUTO POLITECNICO NACIONAL

CENTRO DE INNOVACIÓN Y DESARROLLO

PROTOCOLO CRIPTOGRÁFICO PARA LA AUTENTICACIÓN

Tesis que para obtener el grado de

México, D.F., Agosto de 2009.

A Dios, y por tanto a mi fe. De dónde vengo y con quién voy.

A mi esposa e hijas, por su contribución a mi felicidad. Por el orgullo que me dan y

A mi madre, como fuente inquebrantable de esfuerzo y tesón, el verdadero origen de

A mi familia, por su infinita paciencia y tolerancia en los largos tiempos de abstrac-

A mi directora de tesis, la M. en C. María Aurora Molina Vilchis, por su entendimien-

Al CIDETEC-IPN, por la oportunidad de atrevernos a soñar y contribuir a la reali-

A Javier Apud Gómez, tú no sólo mereces mi dedicatoria general.

A Nanoretec, S.A. de C.V., por la facilidades brindadas al proporcionar sus equipos

3. Protocolo de autenticación de nodos 43

4. Implementación del protocolo propuesto 69

B. Estándar avanzado de encripción (AES) 97

C. Características de los MOTE 113

D. Instalación de la red 115

E. Base de datos de los nodos 125

E.3. Segunda Forma Normal (2FN) . . . . . . . . . . . . . . . . . . . . . . . . 128

1.1. Rango de alcance de diversas señales de radiofrecuencia. . . . . . . . . . 4

2.1. Tres tipos de sumideros en una red de sensores de un solo salto. . . . . . 20

3.1. Arquitectura de un MOTE. . . . . . . . . . . . . . . . . . . . . . . . . . 43

3.10. Gráfica de la relación señal-ruido para diferentes protocolos inalámbricos. 51

4.1. Diagrama general de la distribución de las fases y responsabilidades en el

A.1. Ejemplo del algoritmo extendido de Euclides. . . . . . . . . . . . . . . . 95

B.1. Ejemplo: Estado con  = 6 y  = 4 . . . . . . . . . . . . . . . . . . . 101

C.1. Comparación de características básicas. . . . . . . . . . . . . . . . . . . . 113

D.1. Tarjeta de demostración CC2430DB. . . . . . . . . . . . . . . . . . . . . 116

D.5. Respuesta de la petición IEEE. . . . . . . . . . . . . . . . . . . . . . . . 121

E.1. Base de datos incial. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126

F.1. Forma para el acuerdo de la llave MTI. . . . . . . . . . . . . . . . . . . . 135

Si bien la revolución de la computación estaba basada en la digitalización de la infor-

1.1. Origen y evolución

System (SOSUS) [4] iniciado en 1950, provee a la armada americana la capacidad de

1.2. Wireless Sensor Networks

alcance de transmisión muy corto para transmitir grandes cantidades de información,

Principales Tecnologías de Dos Vías*

* Rendimiento típico, los datos actuales pueden variar

Fuentes: William Webb; Cambridge Consultants; OECD; Pyramid Research;

Figura 1.1: Rango de alcance de diversas señales de radiofrecuencia.

lógicos: el coordinador de red, el nodo ruteador y los dispositivos terminales o de térmi-

a) Estrella b) Malla c) Cúmulo en árbol

Figura 1.2: Topologías de red.

La topología de estrella soporta un solo coordinador como se ve en la Fig. 1.2(a),

Red Inalámbrica de Sensores

En términos generales, de acuerdo con [23], la seguridad se define como la condición

1.3. Estado del arte

para la autenticación en grupos dinámicos de pares. Se muestran cuatro propuestas de

Las autoridades de certificación en los esquemas de clave pública y la criptografía

modelo de confianza distribuida basado en una solución probabilística. Un negociador

comportamientos irregulares de los nodos. En este caso, el procesamiento se realiza total-

1.4. Objetivo del trabajo

1. Modelar matemáticamente las funciones y algoritmos del protocolo, en la genera-

2. Escribir los algoritmos en pseudocódigo.

3. Escribir los programas de los algoritmos y funciones mencionadas.

4. Integrar las funciones en el protocolo.

5. En el simulador escribir el programa del protocolo para una red hipotética.

6. Simular los ataques de identidad en dicha red.

7. Simular cambios de topología y de roles en los nodos.

8. Implementar el protocolo en una red experimental en el laboratorio.

9. Análisis, discusión, ponderación y presentación de los resultados obtenidos.

10. Publicación de los resultados de esta investigación en artículos de revistas y con-