Teoría de la Información y la Comunicación — Ingeniería en Ciberseguridad y Gestión de TI
Los siguientes ejercicios están diseñados para que el estudiante practique de forma autónoma
los tres mecanismos de detección de errores estudiados en la Clase 6: bit de paridad,
checksum y CRC. Cada ejercicio se desarrolla en un escenario de
ciberseguridad distinto, con el objetivo de reforzar cómo la redundancia controlada permite
verificar la integridad de la información transmitida, en contraste con la redundancia eliminada
durante los procesos de compresión estudiados en semanas anteriores.
Ejercicio 1 — Bit de Paridad
NetShield Consulting administra un clúster de sensores IoT instalados
en una planta industrial para monitorear temperatura y presión. Los sensores envían sus lecturas
codificadas en bloques binarios cortos hacia un controlador central a través de un enlace serial
de bajo ancho de banda. Dado que el protocolo no admite mecanismos sofisticados de verificación,
el equipo de NetShield decide implementar paridad par como primera línea de defensa contra
alteraciones accidentales causadas por interferencia electromagnética en la planta.
Planteamiento
Uno de los sensores debe transmitir la lectura binaria 1110010 al controlador,
utilizando un esquema de paridad par.
Condición de paridad par
$$\text{Número total de unos (datos + bit de paridad)} \equiv 0 \pmod{2}$$
1Identificar los datos originales a transmitir
El sensor genera la siguiente cadena binaria como lectura codificada:
Datos originales: 1 1 1 0 0 1 0
Por qué: antes de aplicar cualquier mecanismo de redundancia,
es indispensable fijar con precisión la secuencia original, ya que cualquier error de transcripción
en este punto invalidaría todo el cálculo posterior.
2Contar la cantidad de unos en los datos
1 1 1 0 0 1 0 → unos en posiciones 1, 2, 3 y 6
Total de unos = 4
Por qué: el bit de paridad par depende exclusivamente de la
paridad (par o impar) de esta cuenta; no se necesita ningún otro dato de la trama para decidir
el valor del bit adicional.
3Determinar si el total de unos es par o impar
4 es un número par.
Por qué: este es el punto de decisión del algoritmo. Si el
conteo ya es par, el bit de paridad debe añadirse como 0 para no alterar la paridad existente.
4Calcular el valor del bit de paridad
Como el total de unos ya es par (4), el bit de paridad par a añadir es 0.
Bit de paridad = 0
Por qué: agregar un 0 mantiene el total de unos en 4, que
sigue siendo par; si en cambio hubiéramos añadido un 1, el total pasaría a 5 (impar), rompiendo
la condición que el esquema de paridad par exige cumplir.
5Construir la trama transmitida
Trama transmitida: 1 1 1 0 0 1 0 0
NetShield Consulting envía la secuencia 11100100 hacia el controlador.
Por qué: el bit de paridad se ubica al final de la trama (en
este esquema simplificado) para que el receptor pueda aplicar exactamente el mismo procedimiento
de verificación sin ambigüedad sobre cuál bit es el de control.
6Simular una alteración durante la transmisión
Debido a un pulso de interferencia electromagnética en la planta, el cuarto bit se invierte
durante el trayecto:
Por qué: simular un error es necesario para comprobar que el
mecanismo realmente cumple su función de detección; sin esta verificación, no se podría afirmar
que el esquema es efectivo.
7Verificar la paridad en el receptor
El controlador cuenta los unos en la trama recibida:
1 1 1 1 0 1 0 0 → unos en posiciones 1, 2, 3, 4 y 6
Total de unos recibidos = 5 (impar)
Por qué: el receptor no conoce el mensaje original; su única
herramienta es recalcular la propiedad de paridad sobre lo que efectivamente llegó y compararla
contra la regla acordada (en este caso, paridad par).
8Comparar contra la regla esperada y emitir el diagnóstico
La regla establece que el total de unos debe ser par. El receptor obtuvo un total impar (5).
Resultado: se detecta un error de transmisión. El controlador descarta
la trama y solicita retransmisión.
Por qué: la discrepancia entre la paridad esperada (par) y la
observada (impar) es la única señal disponible; el bit de paridad no indica cuál bit cambió, solo
que algo cambió.
Distinción conceptual: el bit de paridad reduce la incertidumbre que el
receptor tiene sobre si el mensaje llegó intacto, pero no elimina el error ni indica su posición.
Detectar no es lo mismo que corregir: este esquema solo cumple la primera función.
Conexión con el RDA2: en este ejercicio, NetShield Consulting sacrifica eficiencia
(un bit adicional por cada trama) a cambio de confiabilidad. Esta decisión ilustra el equilibrio
central del reto: mientras la compresión busca eliminar redundancia para optimizar el uso del canal,
la detección de errores la reintroduce deliberadamente para proteger la integridad del dato.
Ejercicio 2 — Checksum
PulseNet SOC opera un centro de operaciones de seguridad que recibe
reportes de telemetría desde varios firewalls distribuidos en distintas sucursales. Para minimizar
la carga de procesamiento en cada sucursal, el equipo de PulseNet decide implementar un mecanismo
de checksum aritmético, suficientemente liviano para enlaces con recursos limitados, que permita
una verificación rápida de integridad antes de procesar los reportes en el SOC central.
Planteamiento
Una sucursal debe transmitir tres bloques de 4 bits que representan métricas de tráfico de red:
1101, 1011 y 0110.
Por qué: el checksum opera sobre bloques de tamaño fijo; antes
de calcular cualquier suma es necesario tener claramente delimitados los bloques, ya que un corte
incorrecto produciría un valor de verificación distinto al esperado.
2Convertir cada bloque binario a su valor decimal
Binario
Decimal
1101
13
1011
11
0110
6
Por qué: trabajar en decimal facilita la suma aritmética y
reduce errores manuales de cálculo; el resultado decimal luego puede reconvertirse a binario si
el protocolo lo exige.
3Sumar los valores decimales de todos los bloques
13 + 11 + 6 = 30
Por qué: esta suma constituye el valor de checksum que viajará
junto con los datos; representa una "huella" numérica de la información original, sensible a
cualquier cambio en los bloques.
4Definir el valor de checksum a transmitir
Checksum = 30
Por qué: este valor se transmite junto con los bloques
originales para que el receptor pueda repetir el cálculo y comparar resultados, sin necesidad de
conocer de antemano cuál era el valor correcto.
Por qué: el checksum siempre se adjunta al final (o en una
posición acordada) del mensaje, de modo que el receptor pueda separar con claridad los datos
originales del valor de control.
6Simular una alteración en uno de los bloques
Durante la transmisión por la red de PulseNet SOC, el segundo bloque sufre una alteración:
Enviado: 1011
Recibido: 1001
Por qué: introducir un error controlado permite comprobar si
el checksum efectivamente detecta la inconsistencia, validando la utilidad del mecanismo en un
escenario realista de corrupción de datos.
7Recalcular el checksum con los datos recibidos
Binario recibido
Decimal
1101
13
1001
9
0110
6
13 + 9 + 6 = 28
Por qué: el receptor no tiene forma de saber qué bloque
cambió; su única herramienta es repetir exactamente el mismo procedimiento aritmético que aplicó
el emisor y comparar el resultado final.
8Comparar el checksum recalculado contra el recibido
Checksum recibido: 30 — Checksum recalculado: 28
Resultado: 28 ≠ 30 → se detecta un error en la transmisión. PulseNet
SOC descarta el reporte de telemetría y solicita su reenvío.
Por qué: la diferencia entre ambos valores es la señal de
alarma; al igual que con la paridad, el checksum indica que ocurrió un error, pero no en qué
bloque ni en qué bit específico.
Distinción conceptual: el ahorro de recursos computacionales que ofrece el
checksum (operaciones aritméticas simples) no debe confundirse con su eficiencia en
detección: precisamente por su simplicidad, el checksum puede no detectar errores compensados,
como una alteración que disminuye un valor mientras otra lo aumenta en igual medida.
Conexión con el RDA2: el checksum representa un punto intermedio entre eficiencia y
seguridad: añade poca redundancia (un solo valor numérico) a cambio de una protección moderada.
Esto permite a PulseNet SOC tomar una decisión informada cuando el ancho de banda es limitado, pero
obliga a evaluar si ese nivel de redundancia es suficiente para el riesgo del sistema.
Ejercicio 3 — CRC (Cyclic Redundancy Check)
VaultSec Bank transmite paquetes de autenticación entre sus servidores
de validación de transacciones y sus terminales de punto de venta. Dado que estos paquetes son
críticos para la seguridad financiera, el equipo de VaultSec Bank decide reforzar la verificación
de integridad mediante CRC, capaz de detectar errores en ráfaga que un simple bit de paridad o un
checksum podrían pasar por alto durante picos de interferencia en la red.
Planteamiento
Un terminal debe transmitir el mensaje binario 1001 utilizando CRC con el polinomio
generador G(x) = 1011 (equivalente a $x^3 + x + 1$).
Representación polinomial y condición de verificación
1Identificar el mensaje original y el polinomio generador
Mensaje: 1001
Generador G(x) = 1011 (grado 3, equivalente a x³ + x + 1)
Por qué: el grado del polinomio generador determina cuántos
bits de redundancia se añadirán; sin fijar primero este valor no es posible saber cuántos ceros
agregar al mensaje en el siguiente paso.
2Representar el mensaje como polinomio binario
Bit
Potencia
1
$x^3$
0
$x^2$
0
$x^1$
1
$x^0$
Por tanto: $1001 \rightarrow x^3 + 1$
Por qué: el CRC se fundamenta en aritmética polinomial sobre
GF(2); visualizar el mensaje como polinomio permite entender que la "división" posterior no es
una división numérica tradicional, sino una operación entre polinomios binarios.
3Añadir ceros al final del mensaje según el grado del generador
Como G(x) tiene grado 3, se añaden 3 ceros al final del mensaje:
1001 → 1001000
Por qué: estos ceros reservan el espacio donde finalmente se
insertará el residuo de la división; sin este espacio, el mensaje no tendría suficiente longitud
para alojar la redundancia controlada que el CRC necesita añadir.
4Dividir el mensaje extendido por el polinomio generador usando XOR
Dividimos 1001000 ÷ 1011. El procedimiento trabaja siempre con una "ventana" de 4 bits
(el mismo número de bits que el generador) y avanza un bit a la vez:
Ventana inicial (primeros 4 bits): 1001
Iteración 1 — bit líder de la ventana = 1 → SÍ se aplica el generador:
1001
1011 (XOR)
----
0010
Se baja el siguiente bit del mensaje extendido (0) → nueva ventana: 0100
Iteración 2 — bit líder de la ventana = 0 → NO se aplica el generador (equivale a XOR con 0000):
0100
0000 (XOR)
----
0100
Se baja el siguiente bit (0) → nueva ventana: 0011
Iteración 3 — bit líder de la ventana = 0 → NO se aplica el generador:
0011
0000 (XOR)
----
0011
Se baja el último bit (0) → nueva ventana: 0110
Ya no quedan más bits por bajar.
Residuo final = los últimos 3 bits de la ventana: 110
Por qué: la ventana siempre conserva 4 bits porque ese es el
tamaño del generador; el generador solo se aplica (XOR) cuando el bit líder de la ventana es 1,
ya que un bit líder 0 equivale a multiplicar el generador por 0. En cualquier caso —se aplique o
no el generador— siempre se descarta el bit líder y se baja el siguiente bit del mensaje para
formar la nueva ventana de 4 bits; así se avanza de a un bit hasta agotar el mensaje extendido.
5Identificar el residuo y construir el mensaje protegido
Por qué: el residuo es precisamente la redundancia controlada
que se añade al mensaje original; a diferencia de la compresión, donde se busca eliminar bits
redundantes, aquí se incorporan deliberadamente para permitir la verificación posterior.
6Transmitir el mensaje protegido y simular una alteración
VaultSec Bank transmite 1001110. Durante un pico de interferencia en la red,
el tercer bit se invierte:
Enviado: 1001110
Recibido: 1011110
Por qué: simular el error en un escenario de alta criticidad
(autenticación bancaria) permite evidenciar por qué VaultSec Bank prioriza un mecanismo más
robusto que la simple paridad o el checksum.
7El receptor repite la división con el mismo polinomio generador
El receptor toma 1011110 y lo divide nuevamente por 1011, usando el mismo procedimiento de
ventana de 4 bits:
Ventana inicial (primeros 4 bits): 1011
Iteración 1 — bit líder = 1 → SÍ se aplica el generador:
1011
1011 (XOR)
----
0000
Se baja el siguiente bit (1) → nueva ventana: 0001
Iteración 2 — bit líder = 0 → NO se aplica el generador:
0001
0000 (XOR)
----
0001
Se baja el siguiente bit (1) → nueva ventana: 0011
Iteración 3 — bit líder = 0 → NO se aplica el generador:
0011
0000 (XOR)
----
0011
Se baja el último bit (0) → nueva ventana: 0110
Ya no quedan más bits por bajar.
Residuo final = los últimos 3 bits de la ventana: 110
Por qué: el receptor sigue exactamente el mismo algoritmo que
el emisor, bit por bit, sin atajos; cualquier diferencia en el mensaje recibido respecto al
enviado se propaga a través de las operaciones XOR y queda reflejada en el residuo final.
8Comparar el residuo obtenido contra el residuo esperado (cero)
Residuo esperado si no hay errores: 000
Residuo obtenido por el receptor: 110
Resultado: el residuo es distinto de cero → se detecta un error en
la transmisión. VaultSec Bank rechaza el paquete de autenticación y exige su retransmisión antes
de validar la transacción.
Por qué: la condición de aceptación del CRC es estricta: solo
un residuo exactamente igual a cero garantiza (con muy alta probabilidad) que no hubo alteración;
cualquier otro resultado, sin importar su magnitud, se interpreta como error.
Distinción conceptual: la mayor robustez del CRC frente a errores en ráfaga no
implica que sea un mecanismo de corrección; sigue siendo, como la paridad y el checksum,
un mecanismo de detección. La diferencia entre ambos esquemas no está en si corrigen, sino
en su capacidad de no pasar por alto patrones de error más complejos.
Conexión con el RDA2: el caso de VaultSec Bank ilustra el extremo del espectro
redundancia-eficiencia: a mayor criticidad del sistema, mayor es la redundancia que se justifica
introducir. El estudiante debe reconocer que la elección entre paridad, checksum o CRC no depende
únicamente de la capacidad técnica del canal, sino del nivel de riesgo que la organización está
dispuesta a asumir.