Q-Audion GEN-1: diseñar el primer headset PQC europeo

La voz sigue siendo el canal de comunicación empresarial más crítico operativamente y más descuidado criptográficamente. Directivos, abogados, equipos de M&A y negociadores gubernamentales mantienen conversaciones cuyo valor estratégico supera ampliamente las protecciones técnicas existentes. El stack dominante, headsets de consumo emparejados por BLE a un smartphone que ejecuta un soft-client, se basa en supuestos que ningún arquitecto de seguridad aceptaría para otro activo de tier-1: claves en software mutable, side-channels a través del sistema operativo anfitrión y una capa de transporte que será vulnerada criptoanalíticamente dentro de la vida laboral de la mayoría de los directivos actuales [1].

Q-Audion GEN-1 se encuentra entre los primeros productos de una categoría deliberadamente reducida: un endpoint de voz hardware-rooted, post-cuántico, que no confía ni en el teléfono, ni en el portátil, ni en el sistema operativo con el que dialoga. Cada operación criptográfica ocurre dentro de un Secure Element resistente a la manipulación. Cada byte de audio en claro existe únicamente dentro de un dominio DSP aislado. El dispositivo anfitrión se trata como una red hostil, no como un par.

Iniciamos el programa GEN-1 con un único compromiso arquitectónico: si el diseño imponía un compromiso entre fuerza criptográfica, resistencia a side-channels y ergonomía operativa, sería la ergonomía la que perdería. El resultado es un dispositivo más pesado que un headset de consumo, que consume más corriente que un true-wireless y que requiere algunos segundos para el primer pairing. Cada uno de esos números es la consecuencia deliberada del modelo de amenazas.

Q-Audion GEN-1 debe proteger la confidencialidad y la integridad de una conversación de voz frente a un adversario que controle el dispositivo anfitrión (portátil, teléfono, gateway del headset), pueda observar y modificar el tráfico de radio, pueda montar ataques side-channel físicos contra el dispositivo durante breves ventanas temporales y pueda disponer de un computador cuántico tolerante a fallos en algún momento durante la vida operativa del dato protegido. Se asume que el adversario no dispone de custodia física continuada de varias horas con instrumentación de laboratorio: ése es el límite en el que el modelo de amenazas delega en la política de seguridad física.

Cada decisión de diseño que sigue es la traducción directa de una o varias cláusulas de este modelo de amenazas en decisiones de hardware, firmware o protocolo. No existe ningún otro principio rector.

Internamente el dispositivo se divide en dos dominios eléctrica y lógicamente aislados. El Application Domain gestiona BLE, la interfaz de usuario, la gestión de la batería y el enlace de radio hacia el host emparejado. Ejecuta un RTOS restringido sobre un MCU de propósito general de clase Cortex suministrado por un fabricante europeo de silicio seguro. Este dominio se trata como semi-confiable: puede averiarse, ser reprogramado o comprometerse sin poner en peligro el estado criptográfico.

El Secure Domain está construido en torno a un Secure Element certificado con acelerador PQC integrado y DSP de audio dedicado. Este dominio conserva la clave de identidad de largo plazo, ejecuta todas las operaciones ML-KEM-1024 [1] y ML-DSA-87 [2] y es el único lugar donde existen muestras de audio descifradas. Los dos dominios se comunican sobre un canal de mando hardware-gated de formato fijo, sin acceso directo a memoria desde el lado Application hacia el lado Secure. No hay bus compartido, no hay ventana DMA, no hay camino de depuración que atraviese el límite en el firmware de producción.

Esta separación es la decisión arquitectónica más costosa del dispositivo, por sí sola. Duplica aproximadamente el coste del silicio frente a un diseño de un solo MCU y vuelve considerablemente más complejas las actualizaciones de firmware. También vuelve irrelevante la clase completa de compromiso del lado anfitrión: incluso con pleno control del Application Domain y del host emparejado, un atacante no puede extraer una clave, descifrar un frame almacenado ni falsificar una firma.

La identidad se establece durante el aprovisionamiento generando un par de claves ML-DSA-87 enteramente dentro del Secure Element [2]. La clave privada nunca abandona el SE y está ligada al identificador unclonable único del dispositivo. La clave pública es firmada por la CA de aprovisionamiento de BCrypto, produciendo un certificado de dispositivo que después se presenta durante el pairing. No existe, ni en el firmware ni en la instrumentación de fábrica, un camino para exportar la clave privada de firma.

El establecimiento de sesión utiliza ML-KEM-1024 híbrido con X25519 [7]. Cuando dos dispositivos Q-Audion establecen una llamada, cada uno genera un par de claves efímeras de ambos esquemas, intercambia las claves públicas sobre un canal autenticado (firmado con la identidad ML-DSA-87 de largo plazo) y deriva una clave de sesión de 256 bits mediante HKDF-SHA384 sobre la concatenación de los dos secretos compartidos, con prefijos de longitud explícitos y separación de dominio. Las componentes clásica y post-cuántica son independientes: el compromiso de una sola, aisladamente, no debilita la clave de sesión resultante.

El transporte de audio utiliza AES-GCM 256 con un nonce de 96 bits construido a partir de un salt por sesión y un contador de frame de 64 bits estrictamente monótono. El tamaño del frame es de 20 ms de Opus a 16 kHz, produciendo ciphertexts de aproximadamente 320 bytes. La protección frente a replay se aplica mediante una ventana deslizante de 1024 frames. Los frames fuera de secuencia dentro de la ventana se aceptan; los que quedan fuera se descartan sin procesamiento adicional. Este diseño tolera el jitter intrínseco de BLE sin debilitar las defensas frente a replay.

La elección del micrófono raramente se trata como una decisión de seguridad, pero para un dispositivo que declara proteger una conversación frente a un adversario remoto es una de las más consecuentes. Q-Audion GEN-1 utiliza un array MEMS de tres elementos con beamforming orientado hacia la boca del usuario, posicionado para maximizar el rechazo de fuentes ambientales más allá de aproximadamente 40 centímetros. El beamformer se ejecuta dentro del DSP del Secure Domain, sobre muestras PDM en bruto que nunca atraviesan el límite de dominio en forma de texto plano.

El objetivo acústico es volver sustancialmente más difícil la interceptación remota mediante micrófono láser, un ataque de beamforming paramétrico desde un dispositivo cercano o un micrófono del host comprometido. Ninguna de estas amenazas puede eliminarse únicamente con el headset, pero cada una puede ver aumentado su coste. El array MEMS reduce en 20-30 dB la señal disponible para un atacante fuera de eje en comparación con un micrófono omnidireccional de un solo elemento, traduciéndose en un cambio significativo del sobre de compromiso de un escenario típico de interceptación.

El mismo camino DSP incluye un mute hardware que interrumpe físicamente el front-end analógico del array de micrófonos. El mute solo por software, esquema dominante en los headsets de consumo, es inaceptable en nuestro modelo de amenazas: un firmware comprometido puede ignorarlo. El mute hardware se expone mediante un botón dedicado cuyo estado es detectado independientemente por ambos dominios; un mismatch dispara un shutdown fail-secure del camino de audio.

Todas las primitivas PQC se implementan dentro del Secure Element usando una biblioteca aritmética constant-time certificada frente a los perfiles de resistencia a side-channels relevantes. En particular, el camino de decapsulamiento ML-KEM está auditado frente a los canales de timing, potencia y emanación electromagnética, y la implementación está enmascarada al primer orden contra el differential power analysis [6]. Confiamos en la certificación del proveedor del Secure Element en lugar de desarrollar una implementación propia: es uno de los pocos puntos del diseño en los que el IP comercial certificado es estrictamente más seguro que un trabajo a medida.

La resistencia física al tampering apunta al nivel EAL 4+, en línea con el perfil de certificación de Secure Elements comerciales comparables [5]. El Secure Domain se encapsula bajo un compuesto de potting tamper-evident y el chasis del dispositivo incluye trazas de intrusion detection que disparan la puesta a cero de todo el material de sesión y de identidad en caso de violación mecánica. La resistencia al cold-boot la proporciona un keystore volátil de pérdida de carga para el material efímero y un almacenamiento cifrado para el material de largo plazo.

El firmware se firma con una clave raíz ML-DSA-87 mantenida offline en BCrypto [2]. Las actualizaciones se entregan over-the-air a través del host emparejado pero se verifican dentro del Secure Domain antes del commit en el boot bank. Un contador de rollback, anclado en fusibles one-time-programmable, impide el downgrade a una versión previa vulnerable. El camino de boot impone un measured boot de ambos dominios, con la medición del Secure Domain que extiende la del Application Domain de modo que un compromiso de uno o de otro sea detectable en el siguiente reinicio. El módulo criptográfico apunta a FIPS 140-3 Level 3 [3].

Ejecutar intercambio de clave ML-KEM-1024 y cifrado AES-GCM 256 continuo dentro del presupuesto de batería de un headset es factible únicamente porque el acelerador PQC dentro del Secure Element ejecuta cada handshake en decenas de milisegundos a potencia media sub-milivatio. Una implementación software ingenua sobre un Cortex-M de propósito general quemaría varios joules por handshake y dominaría el presupuesto de batería. El acelerador hardware es el componente habilitador.

La autonomía realista en conversación con una sola carga es de aproximadamente 8 horas, es decir, unos 14 días de standby en idle con los beacons de paging activos. Estos números fueron objetivos, no restricciones: dimensionamos la batería para alcanzarlos tras caracterizar la carga criptográfica, no reduciendo la seguridad para adaptarnos a una batería elegida a priori. El resultado es un dispositivo más pesado que los headsets de consumo típicos, compromiso que consideramos aceptable dado el modelo de amenazas.

El alcance BLE está intencionadamente limitado a aproximadamente 5 metros con la potencia de transmisión predeterminada, muy por debajo del máximo de BLE 5.x. La razón es que cualquier necesidad de operar a distancias mayores implica un host emparejado que no se encuentra bajo el control físico inmediato del usuario, condición que es de por sí un problema de seguridad que ninguna contramedida a nivel de transporte puede resolver. El diseño empuja al usuario hacia una postura de despliegue en la que el dispositivo anfitrión está sobre la persona, no al otro lado de la habitación.

Q-Audion GEN-1 deliberadamente no incluye biometría vocal, supresión de ruido por IA ni ningún procesamiento del lado del cloud. Cada una de estas opciones fue evaluada y rechazada. La biometría vocal añade una superficie de ataque (extracción de plantillas, replay con audio sintético) que excede el beneficio de seguridad que aporta. La supresión de ruido por IA con la calidad esperada hoy requeriría pesos de modelo que no podemos auditar íntegramente y cómputo que no podemos confinar al Secure Domain. El procesamiento en la nube de cualquier tipo es incompatible con el modelo de amenazas.

Además no entregamos un servicio de directorio, un indicador de presencia ni metadatos out-of-band sobre quién está en línea. El dispositivo ejecuta un pairing point-to-point con confirmación explícita del usuario en ambos lados, y una llamada se conecta o falla sin filtrar siquiera el hecho de que se haya hecho un intento a nadie fuera de los dos endpoints. Es fricción; también es la única respuesta honesta a un modelo en el que la red es el adversario.

GEN-2, actualmente en fase de arquitectura preliminar, revisará algunas de estas decisiones a la luz del silicio NPU on-device dedicado emergido recientemente. Para GEN-1, sin embargo, el diseño es intencionadamente mínimo. Hace una sola cosa: vuelve una llamada de voz entre dos usuarios consintientes algo que un adversario en posesión del ciphertext hoy no podrá leer en la segunda mitad de la década de 2030.

Q-Audion GEN-1 no está posicionado frente a los headsets de consumo y no debería compararse con ellos en las dimensiones que los productos de consumo optimizan. Es una categoría aparte: un endpoint de voz vestible diseñado para el modelo de amenazas de la protección ejecutiva, las comunicaciones soberanas y las negociaciones de alto interés. El comprador adecuado lo evalúa frente al coste de la conversación que protege, no frente al coste de hardware de audio de consumo comparable.

Si su organización tiene tráfico de voz cuyo contenido le causaría daño material si lo leyera un adversario dentro de cinco o diez años, la respuesta convencional (headset de consumo, soft-client, TLS) ya no es adecuada. Q-Audion GEN-1 es una respuesta defendible. Las decisiones arquitectónicas que la sustentan, la separación de dos dominios, el Secure Element certificado, el híbrido PQC [7][8], el mute hardware, son el vocabulario de ingeniería que debería esperarse de cualquier proveedor que haga afirmaciones creíbles en este espacio. El CRA [4] convertirá, a partir de diciembre de 2027, muchas de estas decisiones en un suelo legal en lugar de un diferenciador.