Cómo cumplir (¡y superar!) la norma IEEE 1735

El mes pasado recibí un correo electrónico de reclutamiento de alguien que decía ser un reclutador sénior en Workday.

Impecable. Personalizado. Sin errores tipográficos. Mi nombre en el asunto, evitando todos los filtros de correo electrónico.

No respondí. Comprobé el dominio del remitente:hiring-workday.co`.

Nojornada laboral.com`. Los registros DNS mostraron el enrutamiento del correo a través de `emx.mail.ru`. Encabezados SMTP sin procesar que confirman el origen en `send35.i.mail.ru [89.221.237.130]`, un repetidor ruso, a la 1:23 AM hora de Moscú. Selector DKIM: `mailru`. Política DMARC: `p=NONE`. Proxy de Cloudflare, TTL cero en cada registro. Infraestructura diseñada específicamente para entregar y desaparecer.

Lo más probable es que el texto fuera generado por IA. Lo sé porque un reclutador que leyera mi perfil habría mencionado algo relevante. En cambio, cuatro datos de LinkedIn (nombre, cargo, sector y ubicación) se introdujeron en una plantilla de solicitud y se procesaron simultáneamente para miles de destinatarios. La personalización es la superficie de ataque. La infraestructura es la clave.

Con demasiada frecuencia, los sistemas no se diseñan teniendo en cuenta al atacante real. El perfil de LinkedIn se creó para ser leído por un reclutador humano que realizaba un contacto manual. Ahora, los atacantes ejecutan procesos automatizados a gran escala, utilizando IA para convertir datos públicos en información que se utiliza como arma. Esta brecha entre el atacante que el sistema presupone y el atacante que realmente explota la vulnerabilidad no es exclusiva de las plataformas sociales. Es el principal fallo de los sistemas de seguridad en todos los ámbitos.

Esto me hizo pensar en el precedente establecido por IEEE P1735 – Práctica recomendada para el cifrado y la gestión de la propiedad intelectual del diseño electrónico – un estándar desarrollado para proteger la propiedad intelectual del diseño de hardware, como el código HDL para Verilog/VHDL en la cadena de suministro de semiconductores.

En 2017, Chotaray, Nahiyan, Shrimpton, Forte y Tehranpoor publicaron "Standardizing Bad Cryptographic Practice", desmantelando la norma IEEE 1735-2014. Un artículo de 2021 de Speith, Schweins, Ender, Fyrbiack, May y Paar demostró la recuperación completa de la clave privada a partir de implementaciones de producción en Intel, Cadence, Siemens, Lattice y otras empresas.

El estándar utilizado era AES-CBC con transporte de clave RSA. La criptografía no era el punto débil, pero podría decirse que el modelo de amenaza sí lo era. P1735 designó la herramienta EDA como de confianza. Modeló al adversario como un usuario IP pasivo que intentaba leer un archivo protegido en reposo. No modeló a un adversario que controlara el entorno de ejecución y que pudiera introducir texto cifrado manipulado en la herramienta y leer sistemáticamente sus mensajes de error.

Debido a que el estándar exigía AES-CBC sin autenticación en el bloque de datos, y porque alentaba explícitamente a las herramientas EDA a devolver errores de sintaxis descriptivos durante el procesamiento, la propia herramienta se convirtió en el oráculo de descifrado. La propia guía de usabilidad del estándar, «los mensajes de error de calidad reflejan la calidad de la propiedad intelectual protegida», fue el vector de ataque. (Cabe señalar que las recomendaciones no consideraban CWE 209: Exposición de información a través de un mensaje de error). El documento de 2021 fue más allá: encontró esquemas de criptografía de caja blanca basados ​​en RSA ya implementados en herramientas EDA, evidencia de que la industria había reconocido de forma independiente la amenaza Man-At-The-End (MATE) y había recurrido a WBC como solución, pero sin la capa de integridad en tiempo de ejecución necesaria para defender la implementación contra un atacante ya dentro del entorno de ejecución.

La conclusión de los investigadores fue inequívoca: las debilidades del estándar IEEE 1735 no pueden solucionarse únicamente con soluciones criptográficas, dado el proceso de diseño de hardware actual. Cualquier protección que parta de otra premisa falla en el límite que no ha modelado.

El correo electrónico de reclutamiento de IA y la norma IEEE 1735 comparten una causa común: la protección se evaluó frente al atacante equivocado en el entorno equivocado. La norma IEEE 1735 partía de la base de un lector pasivo, pero el atacante real manipuló el entorno de ejecución. 

 Los perfiles de LinkedIn presuponen que un lector humano realiza un contacto manual, pero el atacante real ejecuta un proceso automatizado: extraer, clasificar, generar y distribuir a gran escala. El LLM es la herramienta EDA, la bandeja de entrada humana es el oráculo y el texto plano extraído es la confianza, no el HDL.

Este es el modo de fallo predominante en la adquisición de sistemas de seguridad para aplicaciones en la actualidad.

Qué significa esto para la selección de soluciones de seguridad.

Cuando los desarrolladores evalúan productos de seguridad para software distribuido públicamente, verifican la cobertura de cumplimiento, la complejidad de la integración y la sobrecarga de rendimiento. Las preguntas que suelen pasar por alto son las siguientes:  
(1) ¿Qué supone esta protección que el atacante no puede hacer, y  
(2) ¿Siguen siendo válidas las suposiciones cuando el atacante dispone de herramientas asistidas por IA, acceso completo al entorno de ejecución y presupuesto de consultas ilimitado? 
 
Una arquitectura de protección que no tiene en cuenta el modelo de amenaza correcto, es decir, Man-At-The-End o Man-In-The-Client, donde el atacante controla el de dispositivos El software se ejecuta en ponerse en la misma posición que IEEE 1735. La criptografía puede ser sonido. La suposición del límite no lo es. Un atacante que ya se encuentra dentro del entorno de ejecución no interactúa con el Postulaciónla forma en que se diseñó la protección preveía y generalmente conducía a problemas graves.  
 
La respuesta en la que convergió la industria de semiconductores es, sin embargo, la criptografía de caja blanca para proteger las claves dentro de un entorno de ejecución hostil, combinada con la verificación de integridad en tiempo de ejecución para detectar y responder a la instrumentación activa. Esta es la misma arquitectura que pertenece at La capa de la aplicación móvil. No como una casilla de verificación de cumplimiento. Como una respuesta directa a una amenaza. modelo No se alcanzó el estándar. 
 
En 1993, Ross Anderson argumentó en “¿Por qué fallan los criptosistemas?”" que los fallos de seguridad rara vez son criptográficos. demostrado que las matemáticas se sostienen, pero el modelo de amenazas y Las suposiciones sobre el atacante, su acceso y su entorno son erróneas. La trayectoria de Anderson demostró que estas suposiciones dan lugar a sistemas técnicamente conformes, pero operativamente defectuosos. IEEE La aplicación 1735 y el sistema de reclutamiento mediante IA dirigido a perfiles de LinkedIn son ejemplos de ello. 
 
Antes de aprobar una solución de seguridad para cualquier aplicación distribuida públicamente, hágase una pregunta: ¿Existen protecciones de software que contemplen todo aquello que el atacante no pueda hacer? 
 
Si la respuesta no está escrita, el modelo de amenazas no se ha elaborado. 
 
Si yoTe gustaría hablar sobre tu IEEE 1735 o otras criptomonedas de caja blancanecesidades de fotografía con undrei, Contáctenos aquí: https://digital.ai/why-digital-ai/contact/

Referencias

Anderson, RJ (1994). ¿Por qué fallan los criptosistemas?  
https://doi.org/10.1145/188280.188291 
 
Chhotaray et al., “Estandarización de las malas prácticas criptográficas” https://doi.org/10.1145/3133956.3134040 
 
Speith y otros, “Cómo no proteger su propiedad intelectual”  
https://doi.org/10.1109/SP46214.2022.9833605 
 
https://cwe.mitre.org/data/definitions/209.html