Capítulo 17 — Conceptos de criptografía
Mapa de la lección
Lección 17 publicada. Mapa, ejemplo, EX049.
flowchart TD
N0["Resultados de aprendizaje"]
N1["17.1 La integridad primero"]
N2["17.2 Reproducción"]
N3["17.3 Leer la ejecución"]
N4["17.4 Costes operativos"]
N5["Síntesis del capítulo"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5
N5 --> EX["Ejemplo resuelto"]
EX --> Q["Ejercicio EX049"]
Dibujo lógico
flowchart LR
N0["Resultados de aprendizaje"]
N1["17.1 La integridad primero"]
N2["17.2 Reproducción"]
N3["17.3 Leer la ejecución"]
N4["17.4 Costes operativos"]
N5["Síntesis del capítulo"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX049"]
[Resultados de aprendizaje]
|
v
[17.1 La integridad primero]
|
v
[17.2 Reproducción]
|
v
[17.3 Leer la ejecución]
|
v
[17.4 Costes operativos]
|
v
[Síntesis del capítulo]
|
v
[Ejemplo resuelto] --> [Ejercicio EX049]
Resultados de aprendizaje
Usted podrá (1) explicar los códigos de autenticación de mensajes y por qué en TO la integridad suele importar más que el secreto; (2) usar hmac y hashlib de la biblioteca estándar; (3) impedir la reproducción con contadores; y (4) enumerar los costes operativos de la criptografía en dispositivos con recursos limitados.
17.1 La integridad primero
La lectura de un contador de calor no es secreta para su propietario, pero una lectura falsificada cambia una factura y una orden de control falsificada cambia un proceso. Un código de autenticación de mensajes (MAC) permite a un receptor que comparte una clave secreta verificar que un mensaje procede de alguien que posee la clave y que no fue alterado. HMAC con SHA-256 es una construcción muy utilizada, normalizada en FIPS 198-1. En LDHP lo que está en juego es una factura y una caldera. Una lectura de contador falsificada reduce la factura de un hogar; una escritura falsificada en el registro 100 de PLC-H cambia el calor suministrado a todos los hogares. El laboratorio de HMAC usa lecturas de contadores porque ahí la cuestión de la integridad es más clara.
17.2 Reproducción
Un mensaje válido capturado ayer sigue siendo criptográficamente válido hoy. Incluir un contador estrictamente creciente (o una marca de tiempo comprobada dentro de una ventana) en los datos autenticados permite al receptor rechazar las repeticiones.
"""Lab 17: HMAC-protected meter readings with a replay counter (synthetic key)."""
import hmac, hashlib
KEY = b"synthetic-lab-key-not-for-use"
def tag(ctr, kwh): return hmac.new(KEY, f"{ctr}|{kwh}".encode(), hashlib.sha256).hexdigest()[:16]
last = 0
msgs = [(1, 120.5, tag(1, 120.5)), (2, 121.0, tag(2, 121.0)), (2, 121.0, tag(2, 121.0)), (3, 99.0, tag(3, 121.4))]
for ctr, kwh, t in msgs:
if not hmac.compare_digest(t, tag(ctr, kwh)): print(ctr, kwh, "REJECT bad tag")
elif ctr <= last: print(ctr, kwh, "REJECT replay")
else: last = ctr; print(ctr, kwh, "accept")
Ejecútelo con python3 lab_hmac.py. Salida verificada:
1 120.5 accept
2 121.0 accept
2 121.0 REJECT replay
3 99.0 REJECT bad tag
En el laboratorio de HMAC, una lectura aceptada una vez con el contador 2 se rechaza cuando los mismos bytes vuelven a llegar, aunque su etiqueta sea correcta; solo cambia el significado del contador. Para los contadores de LDHP, esto impide que un inquilino con equipos de radio reproduzca la lectura más baja del mes pasado, que es el caso de abuso descrito en el capítulo 26.
17.3 Leer la ejecución
El mensaje 2 se acepta una vez y se rechaza la segunda como reproducción, aunque su etiqueta sea correcta. El mensaje 3 lleva una etiqueta calculada para 121,4 kWh pero declara 99,0 kWh, así que la verificación falla. Observe hmac.compare_digest, que compara en tiempo constante y evita filtrar cuántos caracteres iniciales coincidieron. Para LDHP, el segundo rechazo es el escenario del inquilino: una lectura más baja capturada y reproducida para la factura del mes siguiente falla por su contador, aunque cada byte de la etiqueta sea auténtico. El tercer rechazo es la manipulación en tránsito: una pasarela o un atacante que cambie 121,4 kWh por 99,0 kWh sin la clave del contador no puede producir una etiqueta que coincida.
17.4 Costes operativos
Las claves deben aprovisionarse por dispositivo, rotarse y revocarse; un contador sustituido tras una avería necesita una clave nueva, y una clave compartida por toda la flota significa que una sola clave extraída falsifica todos los contadores. Los dispositivos con recursos limitados pueden carecer de hardware para el almacenamiento seguro de claves. La disposición 5.4 de ETSI EN 303 645 pide que los parámetros de seguridad sensibles se almacenen de forma segura y que no se usen parámetros críticos de seguridad codificados de forma fija en el software del dispositivo.
La estimación de tamaño de Maya sitúa el coste de radio en 1,5 MB al día para 4.000 contadores; el proceso de gestión de claves es el coste mayor.
Ejemplo resuelto (LDHP sintética)
Maya calcula la sobrecarga de tamaño: una etiqueta truncada de 16 caracteres hexadecimales (64 bits) más un contador de 8 bytes añaden 16 bytes por lectura. Con una lectura por hora y contador en 4.000 contadores, eso supone 1,5 MB al día: trivial para la red, pero el proceso de gestión de claves es el coste real.
Caso sintético — Lakeside District Heating Plant. La clave del laboratorio es una cadena de relleno; nunca incruste claves en el código.
Errores y límites
Truncar los MAC reduce la resistencia a la falsificación; 64 bits es un mínimo habitual en diseños de este tipo. Un hash por sí solo (sin clave) no proporciona autenticación. El cifrado sin protección de la integridad puede ser maleable.
Ejercicios — capítulo 17
- EX049 — Detectar el reinicio de un contador. Tras una actualización del firmware de un contador, el contador de mensajes vuelve a empezar en 1. ¿Qué hace el receptor del laboratorio y cómo debería tratarlo el diseño? Rúbrica: 3 = lo rechaza como reproducción; cambiar la clave o conservar el contador con un campo de época de clave; 2 = solo el comportamiento; 1 = lo acepta; 0 = nada.
- EX050 — ¿Por qué no SHA-256 sin más? Explique por qué añadir SHA-256(lectura) no impide la falsificación. Rúbrica: 3 = no hay secreto: cualquiera puede recalcular el hash de un valor falsificado; 2 = parcial; 1 = «SHA-256 es débil»; 0 = nada.
- EX051 — Riesgo de una clave común a toda la flota. Describa la consecuencia de que los 4.000 contadores compartan una sola clave HMAC. Rúbrica: 3 = extraerla de un contador permite falsificar lecturas de cualquier contador; las claves por dispositivo limitan el radio de impacto; 2 = parcial; 1 = vago; 0 = nada.
Síntesis del capítulo
Para los datos de TO, la integridad autenticada con protección frente a la reproducción es el principal objetivo criptográfico, y la gestión de claves —no el algoritmo— decide si funciona.
Siga estudiando — capítulo 17 de 40
← Capítulo 16 (borrador) · Índice de capítulos del curso · Capítulo 18 (borrador) →