La seguridad moderna reposa sobre una paradoja raramente formulada de manera explícita: cada capa de protección que usted añade desplaza la confianza hacia un actor que no controla, sin eliminarla. Comprender ese desplazamiento es una condición previa para cualquier razonamiento honesto sobre la confidencialidad.
El mito de la cadena sin eslabón débil
Un ingeniero que diseña un sistema seguro piensa naturalmente en capas: cifrado de extremo a extremo, autenticación fuerte, almacenamiento seguro de claves, integridad del arranque. Cada capa se audita, se documenta, se justifica. El resultado final da una impresión de fortaleza. Es precisamente esa impresión la que es peligrosa.
La confidencialidad absoluta exigiría una propiedad que la informática nunca ha alcanzado: ser dueño de la integridad de la cadena de procesamiento, del silicio a la aplicación. En la práctica, esa cadena incluye al menos un procesador cuyo microcódigo no controla, un compilador cuya integridad no puede verificar en cada build y uno o varios componentes hardware cuyo firmware es propietario. La seguridad real no es la ausencia de terceros de confianza; es una elección razonada sobre la naturaleza y la posición de esos terceros en su modelo de amenaza.
Tres puntos ilustran este desplazamiento de forma concreta y verificable.
El TPM sella sus secretos en una caja negra que usted no puede abrir
El Trusted Platform Module se ha convertido en la piedra angular del almacenamiento seguro de claves en las arquitecturas modernas. Su principio es sólido: un chip dedicado, aislado del procesador principal, capaz de generar claves no extraíbles y de condicionar su uso al estado medido del sistema mediante los PCR (Platform Configuration Registers). Ubuntu Core lo utiliza explícitamente para sellar las claves LUKS2 directamente en el TPM durante el arranque: si las huellas del firmware, del bootloader y del núcleo coinciden con el estado registrado, la clave se restituye automáticamente. Si no, el disco permanece cifrado sin remedio.
Es elegante. También es una delegación total de confianza al fabricante del chip.
En 2017, una vulnerabilidad crítica bautizada ROCA (Return of Coppersmith's Attack, CVE-2017-15361) fue descubierta en los TPM Infineon. La biblioteca de generación de claves RSA embarcada en el firmware producía claves cuyos factores primos seguían un patrón reducible, lo que rebajaba la complejidad de factorización de RSA-2048 a un nivel prácticamente atacable. Millones de chips desplegados en portátiles, tarjetas inteligentes y tokens de autenticación estaban afectados. El fallo residía en código cerrado, no auditable, en un chip certificado Common Criteria EAL4+. La certificación no había detectado el problema.
La corrección exigió una actualización de firmware, distribuida por los fabricantes de portátiles, no directamente por Infineon, con plazos variables según los constructores. Durante esa ventana, todo sistema que reposara sobre la no extraibilidad de las claves RSA generadas por esos TPM tenía una garantía de seguridad que no valía nada.
No es un argumento contra el TPM. Es un argumento contra la ilusión de que el TPM elimina la dependencia de un tercero. La concentra. Usted ha sustituido la debilidad difusa de una contraseña humana por una dependencia precisa de Infineon, STMicroelectronics, Nuvoton o AMD según su hardware, empresas sometidas a jurisdicciones, restricciones legales e imperativos comerciales que usted no domina. AMD fTPM e Intel PTT son implementaciones de firmware integradas directamente en el procesador principal: la frontera entre «chip dedicado aislado» y «código que se ejecuta en la CPU principal» se vuelve difusa.
El proyecto OpenTitan de Google es la respuesta estructuralmente coherente a este problema: un root-of-trust cuyo diseño hardware y firmware son públicos y auditables. Está disponible en algunos Chromebooks recientes. Para el resto del mercado, la situación no ha cambiado fundamentalmente.
El cifrado de extremo a extremo solo cifra lo que la aplicación prefiere no ver
Signal es la implementación de referencia del cifrado de extremo a extremo para la mensajería. El protocolo Signal (Double Ratchet + X3DH) es público, auditado, verificado formalmente por criptógrafos independientes. Las propiedades criptográficas son reales: confidencialidad persistente, autenticación, protección contra la compromisión de claves a largo plazo.
La confusión frecuente consiste en confundir las propiedades del protocolo con las propiedades de la aplicación.
El cifrado de extremo a extremo protege el contenido de los mensajes en tránsito entre dos clientes. No dice nada sobre lo que el cliente hace con el contenido una vez descifrado. En Android, la aplicación Signal se ejecuta en un proceso que puede ser sometido a una extracción de memoria por el sistema operativo si este está comprometido. Las copias de seguridad cifradas de Signal en Google Drive utilizan una clave derivada del PIN del usuario, almacenada en un HSM gestionado por Signal: usted confía en Signal para no tener acceso a ese HSM de forma explotable. Los metadatos (quién contacta a quién, con qué frecuencia) no se cifran de la misma manera que el contenido, y Signal recoge un mínimo, pero recoge algo.
Un ejemplo más directo: WhatsApp implementa el protocolo Signal para el cifrado de los mensajes. Los metadatos de contacto y de frecuencia de uso llegan a Meta. El cifrado es real. La confidencialidad frente a Meta no lo es. No es un fallo técnico, es una elección de diseño deliberada, pero ilustra precisamente el punto: el protocolo criptográfico y la aplicación son dos objetos distintos, con modelos de confianza distintos.
TerminalPhone, el proyecto Bash de comunicación cifrada sobre Tor que mencionábamos en la introducción, lleva este razonamiento hasta su término lógico: sin servidor tercero, sin cuenta, sin metadatos centralizados, dirección .onion como única identidad. El modelo de confianza queda reducido al mínimo: Tor Project, OpenSSL y el sistema operativo subyacente. Es coherente. También es señal de que reducir la superficie de confianza exige compromisos de ergonomía que pocos usuarios están dispuestos a aceptar.
El compilador que usted no auditó compila el código que usted auditó
En 1984, Ken Thompson publica «Reflections on Trusting Trust», un texto que sigue siendo una de las contribuciones más inquietantes de la historia de la informática. La demostración: es posible inyectar un caballo de Troya en un compilador de modo que el binario producido quede comprometido, aunque el código fuente sea perfectamente limpio. El compilador modificado se reinyecta a sí mismo al recompilarse. La lectura del código fuente no revela nada. Solo el análisis del binario producido permite detectar la anomalía.
No es un ejercicio académico anticuado. La cadena de compilación de un sistema moderno implica: un compilador (GCC, Clang/LLVM) del que usted no ha compilado cada versión desde las fuentes originales, bibliotecas de sistema (glibc, OpenSSL) cuyos binarios de distribución son producidos por terceros, un núcleo cuyo proceso de build está controlado por los equipos de la distribución y un firmware UEFI cuyo código fuente solo está parcialmente disponible (EDK2 es open source, los blobs de los fabricantes no lo son).
El ataque SolarWinds de 2020 materializó exactamente esta amenaza a gran escala: la cadena de build de SolarWinds Orion fue comprometida, produciendo binarios firmados con el certificado legítimo de la empresa pero que contenían una puerta trasera. Miles de organizaciones instalaron ese software tras verificar la firma, correcta. La auditoría del código fuente no habría revelado nada, puesto que la modificación tenía lugar durante el build.
La respuesta técnica a este problema se llama build reproducible (reproducible builds): un proceso de compilación determinista tal que, a partir de las mismas fuentes y del mismo entorno, cualquiera obtiene bit a bit el mismo binario. Debian lidera este proyecto desde 2013. Bitcoin Core lo ha adoptado. La cobertura sigue siendo parcial en el conjunto del ecosistema. E incluso con builds reproducibles, la confianza en el compilador de bootstrap sigue siendo necesaria: el Trusting Trust de Thompson no desaparece, se empuja un nivel más arriba.
Lo que este análisis implica para el diseño
La confidencialidad no es una propiedad binaria. Es una función de su modelo de amenaza, de la posición de sus terceros de confianza en la cadena y de la probabilidad de que esos terceros sean comprometidos o coaccionados en su contexto operativo.
Un ingeniero que diseña un sistema realmente sensible debe cartografiar explícitamente sus terceros de confianza: fabricante del TPM, autoridad de certificación, compilador de bootstrap, proveedor de distribución, proveedor cloud si procede. Para cada tercero, la pregunta no es «¿es de confianza?» sino «¿cuál es el coste de una compromisión de ese tercero, y mi modelo de amenaza incluye a un adversario capaz de comprometerlo o coaccionarlo?».
Para un modelo de amenaza estándar (protección contra un atacante oportunista, conformidad regulatoria, protección de los datos de los usuarios), TPM + LUKS2 + protocolo auditado es una elección razonable y defendible. Para un modelo de amenaza estatal o de alto valor, cada tercero de la lista anterior es un vector potencial, y las respuestas apropiadas (OpenTitan, reproducible builds, air gap, passphrase manual en lugar del sellado TPM) representan restricciones operativas significativas que pocos sistemas asumen plenamente.
La confidencialidad absoluta no existe fuera de un sistema cuya integridad de la cadena controla usted, del silicio a la aplicación. Ese control es un horizonte, no un estado alcanzable en condiciones de producción reales. El rigor consiste en saber con precisión dónde ha colocado sus terceros de confianza, por qué, y qué pierde si uno de ellos es comprometido.
Referencias técnicas: CVE-2017-15361 (ROCA, Infineon TPM) ; K. Thompson, «Reflections on Trusting Trust», CACM 1984 ; Reproducible Builds project, reproducible-builds.org ; Google OpenTitan, opentitan.org ; NIST SP 800-155 (BIOS integrity measurement) ; SolarWinds supply chain attack, CISA Advisory AA20-352A.