Capítulo 4 — Replicación de la línea base y piloto | Investigación doctoral Seguridad cuántica y poscuántica

Aprendizaje gratuito y abierto para quienes desean proteger a las personas y la tecnología. No se necesita una cuenta para estudiar ni consultar las respuestas.

Mapa de la lección

Lección 04 publicada. Mapa, ejemplo, EX021.

flowchart TD
  N0["Resultados de aprendizaje y conexión"]
  N1["4.1 Términos"]
  N2["4.2 Diagnóstico de una reproducción fallida: InvBenc"]
  N3["4.3 Verificar el instrumento"]
  N4["4.4 Actividad práctica — Lab 4: verificar el clasifi"]
  N5["4.5 Ajustar sin filtraciones"]
  N6["4.6 Un piloto acotado"]
  N7["Síntesis del capítulo"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Ejemplo resuelto"]
  EX --> Q["Ejercicio EX021"]

Dibujo lógico

flowchart LR
  N0["Resultados de aprendizaje y conexión"]
  N1["4.1 Términos"]
  N2["4.2 Diagnóstico de una reproducción fallida: InvBenc"]
  N3["4.3 Verificar el instrumento"]
  N4["4.4 Actividad práctica — Lab 4: verificar el clasifi"]
  N5["4.5 Ajustar sin filtraciones"]
  N6["4.6 Un piloto acotado"]
  N7["Síntesis del capítulo"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX021"]

[Resultados de aprendizaje y conexión]
    |
    v
[4.1 Términos]
    |
    v
[4.2 Diagnóstico de una reproducción fallida: InvBenc]
    |
    v
[4.3 Verificar el instrumento]
    |
    v
[4.4 Actividad práctica — Lab 4: verificar el clasifi]
    |
    v
[4.5 Ajustar sin filtraciones]
    |
    v
[4.6 Un piloto acotado]
    |
    v
[Síntesis del capítulo]
    |
    v
[Ejemplo resuelto] --> [Ejercicio EX021]

Resultados de aprendizaje y conexión

Al terminar este capítulo usted podrá (1) distinguir repetibilidad, reproducibilidad y replicabilidad; (2) diagnosticar por qué no se reproduce un resultado de inventario publicado; (3) verificar un instrumento con entradas conocidas antes de fiarse de su salida; (4) ajustar parámetros sin filtrar datos de prueba; y (5) ejecutar un piloto acotado que termine en una decisión explícita de seguir o no seguir. Aplica la propuesta del capítulo 3 antes del estudio principal del capítulo 5.

4.1 Términos

Según el vocabulario de revisión y distintivos de artefactos de la ACM: repetibilidad, el mismo equipo obtiene el mismo resultado con la misma configuración; reproducibilidad, un equipo distinto lo obtiene con los artefactos originales; replicabilidad, un equipo distinto lo obtiene con artefactos desarrollados de forma independiente. Una línea base doctoral debería al menos reproducirse, y el registro de la reproducción debería anotar cada desviación, incluidas las versiones de los escáneres, de los analizadores y del registro de grupos de TLS usado para clasificar los codepoints.

En el Estudio Ciphertrail, el trabajo sobre InvBench-22 es una reproducción, porque reutiliza el corpus publicado.

4.2 Diagnóstico de una reproducción fallida: InvBench-22

El artículo sintético InvBench-22 informa de que su escáner encontró «el 97 % de los activos vulnerables a la computación cuántica». El doctorando obtiene el corpus publicado y consigue un 61 %. Surgen tres causas, por orden de descubrimiento. Primera, doble recuento: el artículo contó hallazgos, no usos; el mismo servidor aparecía con un nombre corto, con un nombre completo y con dos direcciones IP, y cada uno se contaba como un acierto frente a un único elemento de la verdad de referencia. Segunda, filtración de la verdad de referencia: la verdad de referencia se construyó en parte a partir de la salida anterior del propio escáner, de modo que los elementos que el escáner no podía ver faltaban en el denominador. Tercera, deriva del registro: el clasificador del artículo era anterior a los codepoints definitivos de ML-KEM y etiquetaba como «desconocido» el codepoint híbrido obsoleto previo a la norma, que los autores después excluyeron. Nada de esto es fraude; cada causa es una decisión de medición que no se declaró. El registro de la reproducción enuncia cada causa, cuantifica su efecto e indica cuáles son inferencias y no hechos confirmados por los autores.

4.3 Verificar el instrumento

Antes de medir HRHN, verifique que el clasificador pasivo asigna correctamente cada codepoint de grupo admitido de TLS. El registro de grupos admitidos de TLS de la IANA enumera los codepoints; RFC 10024 define X25519MLKEM768, SecP256r1MLKEM768 y SecP384r1MLKEM1024. Las pruebas unitarias con entradas conocidas son la evidencia de validez más barata que puede tener una tesis. Importan dos reglas de diseño. Un codepoint desconocido debe clasificarse como desconocido, nunca como seguro. Y la identidad debe canonizarse antes de contar, de modo que un uso sea una fila.

4.4 Actividad práctica — Lab 4: verificar el clasificador y contar usos

# Lab 4 (synthetic): verify the passive classifier and show how duplicate counting inflates recall.
# TLS supported-group codepoints (IANA registry): 0x001D x25519, 0x0017 secp256r1,
# 0x11EC X25519MLKEM768, 0x11EB SecP256r1MLKEM768, 0x11ED SecP384r1MLKEM1024,
# 0x6399 X25519Kyber768Draft00 (obsolete pre-standard codepoint).
GROUPS = {0x001D: "classical", 0x0017: "classical", 0x11EC: "hybrid", 0x11EB: "hybrid",
          0x11ED: "hybrid", 0x6399: "pre-standard hybrid"}
def classify(code):
    return GROUPS.get(code, "unknown")          # never default an unknown codepoint to "safe"
tests = [(0x001D, "classical"), (0x11EC, "hybrid"), (0x6399, "pre-standard hybrid"), (0xFFFF, "unknown")]
assert all(classify(c) == want for c, want in tests), "classifier unit test failed"
print("classifier unit tests: 4/4 pass")
# Synthetic handshake findings: (server pseudonym, port, selected group)
findings = [("srv-014", 443, 0x001D), ("srv-014", 443, 0x001D), ("SRV-014.halden.example", 443, 0x001D),
            ("srv-022", 8443, 0x11EC), ("srv-031", 443, 0x0017), ("srv-031", 443, 0x0017)]
truth_vulnerable = {("srv-014", 443), ("srv-031", 443), ("srv-040", 22)}   # adjudicated uses
def canon(host):
    return host.lower().split(".")[0]
raw_hits = sum(1 for h, p, g in findings if classify(g) == "classical")
uses = {(canon(h), p) for h, p, g in findings if classify(g) == "classical"}
print(f"raw classical findings: {raw_hits}  -> naive 'recall' {raw_hits}/{len(truth_vulnerable)} = {raw_hits/len(truth_vulnerable):.2f}")
print(f"canonical uses found:   {len(uses & truth_vulnerable)}  -> recall {len(uses & truth_vulnerable)/len(truth_vulnerable):.2f}")

Salida esperada:

classifier unit tests: 4/4 pass
raw classical findings: 5  -> naive 'recall' 5/3 = 1.67
canonical uses found:   2  -> recall 0.67

Una «exhaustividad» superior a 1 es la señal más clara posible de un error de unidad, pero una inflación más sutil —por ejemplo, de 0,61 a 0,97— parece plausible y supera la revisión salvo que se declare la unidad de recuento. El uso SSH que falta en srv-040 ilustra además el modelo del observador: el sensor de TLS no puede encontrarlo.

El laboratorio separa dos comprobaciones fáciles de confundir. Las pruebas unitarias muestran que el clasificador asigna correctamente los codepoints conocidos, incluido uno desconocido. El paso de recuento muestra cómo el mismo servidor, registrado repetidas veces y con dos nombres, puede inflar la exhaustividad. Mantenga ambas en el conjunto de pruebas del instrumento y ejecútelas antes de cada recogida, anotando junto a los resultados la fecha de recuperación del registro de la IANA.

4.5 Ajustar sin filtraciones

La regla de fusión tiene parámetros: cuánto tiempo sigue siendo válida una observación pasiva, cómo se emparejan los nombres de host con los repositorios de código y el umbral de confianza para atribuir un grupo negociado a un activo. Ajústelos sobre una partición de desarrollo (en el Estudio Ciphertrail, el hospital 1 de HRHN), congélelos y evalúe sobre los hospitales 2 y 3, reservados. Anote cada ejecución de ajuste, incluidas las abandonadas; un jardín de senderos que se bifurcan que se oculta es indistinguible del p-hacking.

Lleve un registro de ajuste con la fecha, los valores de los parámetros y el resultado en el hospital 1 de cada ejecución. Cuando las reglas queden congeladas, anote el hash de la configuración en ese mismo registro.

4.6 Un piloto acotado

El piloto dura dos semanas en un segmento de HRHN con 140 servicios. Criterios previos de seguir o no seguir: todas las pruebas unitarias del clasificador superadas; seudonimización verificada por una segunda persona en una muestra de 200 registros; ningún incidente operativo atribuible al estudio; concordancia entre adjudicadores (κ de Cohen) de al menos 0,70 en un conjunto de calibración de 60 elementos; y un protocolo que no requiera más de cuatro horas de ingeniero por cada 100 servicios. El piloto sintético cumple cuatro criterios, pero registra κ = 0,62, porque los adjudicadores discreparon sobre si un conjunto de cifrado con intercambio de claves RSA configurado pero nunca negociado es un «uso». La decisión es seguir con enmienda: el libro de códigos define ahora un uso como cualquier algoritmo que un par pueda alcanzar en la negociación, con una marca aparte para «configurado, no observado».

4.7 Errores comunes y límites

Contar hallazgos en lugar de usos; declare siempre la unidad.
Construir la verdad de referencia con la herramienta evaluada.
Usar un registro de codepoints desactualizado; anote su fecha de recuperación.
Ajustar sobre los datos de prueba, aunque sea de manera informal «mirando unos cuantos resultados».
Un piloto sin criterios previos no puede fallar y, por tanto, enseña poco.

Cada error tiene una salvaguarda en este estudio: identificadores canónicos para los usos, adjudicación ciega respecto a la herramienta, un registro fechado, una partición por hospital con reglas congeladas y criterios previos para el piloto. La baja concordancia de 0,62 del piloto es un ejemplo de un criterio que cumple su función: obligó a enmendar el libro de códigos antes del estudio principal y no después.

Ejercicios — capítulo 4

EX021 — Vocabulario. Clasifique tres escenarios como repetibilidad, reproducibilidad o replicabilidad. Rúbrica: 3 = todos correctos, con una justificación de una línea cada uno.
EX022 — Registro de la reproducción. Escriba la entrada del registro para la causa 2 de InvBench-22, separando la observación de la inferencia. Rúbrica: 3 = efecto cuantificado, inferencia etiquetada.
EX023 — Ampliar el clasificador. Añada al Lab 4 pruebas unitarias para SecP384r1MLKEM1024 (0x11ED, ya presente en la tabla) y para un codepoint desconocido 0x0200. Rúbrica: 3 = las pruebas se superan y lo desconocido sigue siendo desconocido.
EX024 — Identidad canónica. Proponga una regla de canonización de un uso que trate las direcciones IP, los alias y los balanceadores de carga. Rúbrica: 3 = aborda al menos un modo de fallo de la regla.
EX025 — Diseño de particiones. Diseñe particiones de desarrollo y prueba para HRHN que eviten filtraciones cuando dos hospitales comparten una PKI. Rúbrica: 3 = identifica la filtración por PKI compartida y la mitiga.
EX026 — Seguir o no seguir. Con κ = 0,62 y todos los demás criterios cumplidos, redacte el memorando de decisión. Rúbrica: 3 = decisión justificada, enmienda específica, criterio de nueva prueba declarado.

Síntesis del capítulo

Las líneas base se reproducen antes de superarlas; los instrumentos se verifican con entradas conocidas; la unidad de recuento se declara; el ajuste se separa de la prueba; y un piloto existe para poder fallar. La exhaustividad inflada de InvBench-22 provenía de tres decisiones de medición no declaradas, no del escáner.

Siga estudiando — capítulo 04 de 08

← Capítulo 03 (borrador) · Índice de capítulos del curso · Capítulo 05 (borrador) →