Reference Architecture for Embedded PQC: Layering ML-KEM, ML-DSA and LMS Across Boot, Session and Fieldbus Domains
There is no single right post-quantum algorithm for an embedded fleet. The architecture choice is where each primitive runs: stateful hash-based signatures (LMS/XMSS, NIST SP 800-208, RFC 8554/RFC 8391) for root-of-trust boot verification, ML-DSA (FIPS 204) for updatable certificates and OTA manifests, and ML-KEM (FIPS 203) in hybrid key exchange (X25519MLKEM768, per the IETF TLS hybrid design work) for TLS 1.3 sessions. The main trade-off is between end-to-end PQC on every ECU and ending PQC at an HSM-backed domain gateway. Message size, RAM, boot-time budget and how much interoperability you need decide which one is viable.
Domain-split decision criteria
Use LMS/XMSS only for boot ROM or first-stage verification when signing is centralized in an HSM that can guarantee one-time state use. Use ML-DSA-44/65 wherever signers are distributed or stateless operation is required. Use hybrid ML-KEM-768 for gateway and backend TLS 1.3. On classic CAN or CAN FD segments with nodes below roughly tens of KB of free RAM, end PQC at the domain gateway and protect the segment with symmetric authentication (for example AUTOSAR SecOC with AES-CMAC) using keys distributed by the gateway.
Pre-specification checklist
For each node, list RAM, flash, worst-case stack, maximum frame payload (CAN FD 64 B, Ethernet MTU 1500 B), boot-time budget, HSM class (SHE vs full EVITA-style HSM), certificate chain depth and device service life compared with your migration deadline (for example the NSA CNSA 2.0 timelines). Fix algorithm identifiers from final FIPS documents and IETF LAMPS/TLS specifications. Require validation against NIST ACVP/CAVP test vectors before integration, and map the requirements to ISO/SAE 21434 and IEC 62443-4-2.
Illustrative scenario with rollout and recovery
This is an analytical example, not a measurement. An ML-DSA-44 signature is 2420 B, so on a 64 B CAN FD payload it needs about 38 frames before transport-protocol overhead. That rules out per-message signing on the bus, so verification belongs at the gateway. Roll out in phases. First ship dual-signed manifests (ECDSA plus ML-DSA, both checked). Then require ML-DSA under a policy flag. Recover through A/B firmware slots, monotonic anti-rollback counters, LMS state reservation backed up in the HSM, and a policy that rejects downgrade to classical-only modes.
Technical FAQ: When should an embedded ECU verify ML-DSA signatures itself instead of relying on a gateway that terminates post-quantum cryptography?
An ECU should verify ML-DSA locally when three conditions all hold: it accepts code or configuration from more than one trust path, its threat model includes a compromised gateway, and it has the RAM, stack and verification time for FIPS 204 verification within its boot or update budget. If any of these fails, end PQC at an HSM-backed gateway and use symmetric authentication on the segment. Write down the assumption that the gateway is a trust anchor and include it in your ISO/SAE 21434 analysis. In either case, confirm conformance with NIST ACVP vectors, test that downgrade attempts are rejected, and keep an A/B rollback path with anti-rollback counters so that a faulty PQC update cannot brick the device.
Arquitetura de Referência para PQC Embarcada: ML-KEM, ML-DSA e LMS nas Camadas de Boot, Sessão e Fieldbus
Não existe um único algoritmo pós-quântico certo para uma frota embarcada. A escolha de arquitetura é onde cada primitiva roda: assinaturas baseadas em hash com estado (LMS/XMSS, NIST SP 800-208, RFC 8554/RFC 8391) para a verificação de boot na raiz de confiança, ML-DSA (FIPS 204) para certificados atualizáveis e manifestos OTA, e ML-KEM (FIPS 203) em troca de chaves híbrida (X25519MLKEM768, conforme o trabalho do IETF TLS sobre o design híbrido) para sessões TLS 1.3. O principal trade-off é entre PQC fim a fim em cada ECU e encerrar a PQC num gateway de domínio apoiado por HSM. Tamanho de mensagem, RAM, orçamento de tempo de boot e o nível de interoperabilidade necessário definem qual opção é viável.
Critérios de divisão por domínio
Use LMS/XMSS apenas na ROM de boot ou na verificação do primeiro estágio, quando a assinatura for centralizada num HSM capaz de garantir o uso único de cada estado. Use ML-DSA-44/65 onde os assinantes forem distribuídos ou a operação sem estado for obrigatória. Use ML-KEM-768 híbrido no TLS 1.3 do gateway e do backend. Em segmentos CAN clássico ou CAN FD com nós de apenas algumas dezenas de KB de RAM livre, encerre a PQC no gateway de domínio e proteja o segmento com autenticação simétrica (por exemplo AUTOSAR SecOC com AES-CMAC), usando chaves distribuídas pelo gateway.
Checklist antes de especificar
Para cada nó, levante RAM, flash, pilha no pior caso, payload máximo do quadro (CAN FD 64 B, MTU Ethernet 1500 B), orçamento de tempo de boot, classe de HSM (SHE ou HSM completo estilo EVITA), profundidade da cadeia de certificados e vida útil do dispositivo comparada ao prazo de migração (por exemplo, os cronogramas NSA CNSA 2.0). Fixe os identificadores de algoritmo a partir dos FIPS finais e das especificações IETF LAMPS/TLS. Exija validação com vetores NIST ACVP/CAVP antes da integração e mapeie os requisitos para a ISO/SAE 21434 e a IEC 62443-4-2.
Cenário ilustrativo com implantação e recuperação
Exemplo analítico, não medição. Uma assinatura ML-DSA-44 tem 2420 B; com payload CAN FD de 64 B, ela ocupa cerca de 38 quadros antes do overhead do protocolo de transporte. Isso inviabiliza assinar cada mensagem no barramento, então a verificação fica no gateway. Implante em fases. Primeiro, manifestos com dupla assinatura (ECDSA mais ML-DSA, ambas verificadas). Depois, torne ML-DSA obrigatório por flag de política. A recuperação usa slots de firmware A/B, contadores monotônicos anti-rollback, reserva de estado LMS com backup no HSM e uma política que rejeita downgrade para modos só clássicos.
FAQ Técnica: Quando uma ECU embarcada deve verificar assinaturas ML-DSA por conta própria, em vez de depender de um gateway que encerra a criptografia pós-quântica?
A ECU deve verificar ML-DSA localmente quando as três condições forem verdadeiras: ela aceita código ou configuração por mais de um caminho de confiança, o modelo de ameaça inclui um gateway comprometido, e ela tem RAM, pilha e tempo para a verificação FIPS 204 dentro do orçamento de boot ou de atualização. Se qualquer uma falhar, encerre a PQC num gateway apoiado por HSM e use autenticação simétrica no segmento. Registre a premissa de que o gateway é âncora de confiança e inclua-a na análise ISO/SAE 21434. Nos dois casos, confirme a conformidade com vetores NIST ACVP, teste se tentativas de downgrade são rejeitadas e mantenha um caminho de rollback A/B com contadores anti-rollback, para que uma atualização PQC defeituosa não inutilize o dispositivo.
Arquitectura de Referencia para PQC Embebida: ML-KEM, ML-DSA y LMS en las Capas de Arranque, Sesión y Bus de Campo
No existe un único algoritmo poscuántico correcto para una flota embebida. La decisión de arquitectura es dónde se ejecuta cada primitiva: firmas basadas en hash con estado (LMS/XMSS, NIST SP 800-208, RFC 8554/RFC 8391) para la verificación de arranque en la raíz de confianza, ML-DSA (FIPS 204) para certificados actualizables y manifiestos OTA, y ML-KEM (FIPS 203) en intercambio de claves híbrido (X25519MLKEM768, según el trabajo del IETF TLS sobre el diseño híbrido) para sesiones TLS 1.3. La principal disyuntiva es entre PQC extremo a extremo en cada ECU y terminar la PQC en un gateway de dominio respaldado por HSM. El tamaño de los mensajes, la RAM, el presupuesto de tiempo de arranque y el nivel de interoperabilidad necesario determinan qué opción es viable.
Criterios de división por dominio
Use LMS/XMSS solo en la ROM de arranque o en la verificación de primera etapa, cuando la firma esté centralizada en un HSM capaz de garantizar el uso único de cada estado. Use ML-DSA-44/65 donde los firmantes estén distribuidos o se requiera operación sin estado. Use ML-KEM-768 híbrido en el TLS 1.3 del gateway y del backend. En segmentos CAN clásico o CAN FD con nodos de apenas unas decenas de KB de RAM libre, termine la PQC en el gateway de dominio y proteja el segmento con autenticación simétrica (por ejemplo AUTOSAR SecOC con AES-CMAC), con claves distribuidas por el gateway.
Lista de verificación previa a la especificación
Para cada nodo, inventaríe RAM, flash, pila en el peor caso, carga útil máxima de trama (CAN FD 64 B, MTU Ethernet 1500 B), presupuesto de tiempo de arranque, clase de HSM (SHE o HSM completo tipo EVITA), profundidad de la cadena de certificados y vida útil del dispositivo frente al plazo de migración (por ejemplo, los calendarios NSA CNSA 2.0). Fije los identificadores de algoritmo a partir de los FIPS finales y de las especificaciones IETF LAMPS/TLS. Exija validación con vectores NIST ACVP/CAVP antes de la integración y asigne los requisitos a ISO/SAE 21434 e IEC 62443-4-2.
Escenario ilustrativo con despliegue y recuperación
Ejemplo analítico, no medición. Una firma ML-DSA-44 ocupa 2420 B; con una carga útil CAN FD de 64 B, necesita unas 38 tramas antes de la sobrecarga del protocolo de transporte. Eso descarta firmar cada mensaje en el bus, así que la verificación va en el gateway. Despliegue por fases. Primero, manifiestos con doble firma (ECDSA más ML-DSA, ambas verificadas). Después, haga ML-DSA obligatorio mediante un flag de política. La recuperación usa slots de firmware A/B, contadores monótonos anti-rollback, reserva de estado LMS respaldada en el HSM y una política que rechaza la degradación a modos solo clásicos.
Preguntas Frecuentes Técnicas: ¿Cuándo debe una ECU embebida verificar firmas ML-DSA por sí misma en lugar de depender de un gateway que termina la criptografía poscuántica?
La ECU debe verificar ML-DSA localmente cuando se cumplen las tres condiciones: acepta código o configuración por más de una ruta de confianza, el modelo de amenazas incluye un gateway comprometido, y dispone de RAM, pila y tiempo para la verificación FIPS 204 dentro de su presupuesto de arranque o actualización. Si alguna falla, termine la PQC en un gateway respaldado por HSM y use autenticación simétrica en el segmento. Documente la suposición de que el gateway es ancla de confianza e inclúyala en el análisis ISO/SAE 21434. En ambos casos, confirme la conformidad con vectores NIST ACVP, pruebe que los intentos de degradación se rechazan y mantenga una ruta de rollback A/B con contadores anti-rollback, para que una actualización PQC defectuosa no inutilice el dispositivo.
Architecture de Référence pour la PQC Embarquée : ML-KEM, ML-DSA et LMS dans les Couches Démarrage, Session et Bus de Terrain
Il n'existe pas un seul bon algorithme post-quantique pour une flotte embarquée. Le choix d'architecture porte sur l'endroit où s'exécute chaque primitive : signatures à base de hachage avec état (LMS/XMSS, NIST SP 800-208, RFC 8554/RFC 8391) pour la vérification du démarrage à la racine de confiance, ML-DSA (FIPS 204) pour les certificats évolutifs et les manifestes OTA, et ML-KEM (FIPS 203) en échange de clés hybride (X25519MLKEM768, selon les travaux de l'IETF TLS sur la conception hybride) pour les sessions TLS 1.3. Le compromis principal oppose une PQC de bout en bout sur chaque ECU à une terminaison de la PQC sur une passerelle de domaine adossée à un HSM. La taille des messages, la RAM, le budget de temps de démarrage et le niveau d'interopérabilité requis déterminent l'option viable.
Critères de découpage par domaine
Utilisez LMS/XMSS uniquement pour la ROM de démarrage ou la vérification de premier étage, lorsque la signature est centralisée dans un HSM capable de garantir l'usage unique de chaque état. Utilisez ML-DSA-44/65 lorsque les signataires sont distribués ou qu'un fonctionnement sans état est exigé. Utilisez ML-KEM-768 hybride pour le TLS 1.3 de la passerelle et du backend. Sur les segments CAN classique ou CAN FD dont les nœuds n'ont que quelques dizaines de Ko de RAM libre, terminez la PQC à la passerelle de domaine et protégez le segment par une authentification symétrique (par exemple AUTOSAR SecOC avec AES-CMAC), avec des clés distribuées par la passerelle.
Liste de contrôle avant spécification
Pour chaque nœud, recensez RAM, flash, pile dans le pire cas, charge utile maximale de trame (CAN FD 64 o, MTU Ethernet 1500 o), budget de temps de démarrage, classe de HSM (SHE ou HSM complet de type EVITA), profondeur de la chaîne de certificats et durée de vie de l'équipement comparée à l'échéance de migration (par exemple les calendriers NSA CNSA 2.0). Figez les identifiants d'algorithme d'après les FIPS définitifs et les spécifications IETF LAMPS/TLS. Exigez une validation avec les vecteurs NIST ACVP/CAVP avant intégration et rattachez les exigences à l'ISO/SAE 21434 et à l'IEC 62443-4-2.
Scénario illustratif avec déploiement et reprise
Exemple analytique, pas une mesure. Une signature ML-DSA-44 fait 2420 o ; avec une charge utile CAN FD de 64 o, elle occupe environ 38 trames avant le surcoût du protocole de transport. Cela exclut la signature de chaque message sur le bus, donc la vérification se fait à la passerelle. Déployez par phases. D'abord des manifestes doublement signés (ECDSA plus ML-DSA, les deux vérifiées). Ensuite, rendez ML-DSA obligatoire via un drapeau de politique. La reprise repose sur des slots de firmware A/B, des compteurs anti-rollback monotones, une réservation d'état LMS sauvegardée dans le HSM et une politique qui refuse toute rétrogradation vers des modes uniquement classiques.
FAQ Technique: Quand un ECU embarqué doit-il vérifier lui-même les signatures ML-DSA plutôt que de s'appuyer sur une passerelle qui termine la cryptographie post-quantique ?
L'ECU doit vérifier ML-DSA localement lorsque les trois conditions sont réunies : il accepte du code ou de la configuration par plus d'un chemin de confiance, le modèle de menace inclut une passerelle compromise, et il dispose de la RAM, de la pile et du temps nécessaires à la vérification FIPS 204 dans son budget de démarrage ou de mise à jour. Si l'une d'elles manque, terminez la PQC sur une passerelle adossée à un HSM et utilisez une authentification symétrique sur le segment. Documentez l'hypothèse selon laquelle la passerelle est une ancre de confiance et intégrez-la à l'analyse ISO/SAE 21434. Dans les deux cas, confirmez la conformité avec les vecteurs NIST ACVP, vérifiez que les tentatives de rétrogradation sont rejetées et conservez un chemin de rollback A/B avec compteurs anti-rollback, afin qu'une mise à jour PQC défectueuse ne rende pas l'équipement inutilisable.
Architettura di Riferimento per la PQC Embedded: ML-KEM, ML-DSA e LMS nei Livelli di Boot, Sessione e Bus di Campo
Non esiste un unico algoritmo post-quantistico giusto per una flotta embedded. La scelta architetturale riguarda dove viene eseguita ogni primitiva: firme basate su hash con stato (LMS/XMSS, NIST SP 800-208, RFC 8554/RFC 8391) per la verifica del boot alla radice di fiducia, ML-DSA (FIPS 204) per certificati aggiornabili e manifest OTA, e ML-KEM (FIPS 203) in scambio di chiavi ibrido (X25519MLKEM768, secondo il lavoro dell'IETF TLS sul design ibrido) per le sessioni TLS 1.3. Il compromesso principale è tra PQC end-to-end su ogni ECU e terminazione della PQC su un gateway di dominio supportato da HSM. Dimensione dei messaggi, RAM, budget del tempo di boot e livello di interoperabilità richiesto determinano quale opzione è praticabile.
Criteri di suddivisione per dominio
Usate LMS/XMSS solo per la ROM di boot o la verifica del primo stadio, quando la firma è centralizzata in un HSM in grado di garantire l'uso unico di ogni stato. Usate ML-DSA-44/65 dove i firmatari sono distribuiti o serve un funzionamento senza stato. Usate ML-KEM-768 ibrido per il TLS 1.3 di gateway e backend. Su segmenti CAN classico o CAN FD con nodi che hanno solo qualche decina di KB di RAM libera, terminate la PQC al gateway di dominio e proteggete il segmento con autenticazione simmetrica (ad esempio AUTOSAR SecOC con AES-CMAC), con chiavi distribuite dal gateway.
Checklist prima della specifica
Per ogni nodo, censite RAM, flash, stack nel caso peggiore, payload massimo del frame (CAN FD 64 B, MTU Ethernet 1500 B), budget del tempo di boot, classe di HSM (SHE o HSM completo tipo EVITA), profondità della catena di certificati e vita utile del dispositivo rispetto alla scadenza di migrazione (ad esempio le tempistiche NSA CNSA 2.0). Fissate gli identificatori di algoritmo in base ai FIPS definitivi e alle specifiche IETF LAMPS/TLS. Richiedete la validazione con i vettori NIST ACVP/CAVP prima dell'integrazione e mappate i requisiti su ISO/SAE 21434 e IEC 62443-4-2.
Scenario illustrativo con rollout e ripristino
Esempio analitico, non una misura. Una firma ML-DSA-44 occupa 2420 B; con un payload CAN FD di 64 B richiede circa 38 frame prima dell'overhead del protocollo di trasporto. Questo esclude la firma di ogni messaggio sul bus, quindi la verifica avviene al gateway. Rilasciate per fasi. Prima manifest a doppia firma (ECDSA più ML-DSA, entrambe verificate). Poi rendete ML-DSA obbligatorio tramite un flag di policy. Il ripristino si basa su slot firmware A/B, contatori anti-rollback monotoni, prenotazione dello stato LMS con backup nell'HSM e una policy che rifiuta il downgrade a modalità solo classiche.
FAQ Tecnica: Quando una ECU embedded deve verificare da sé le firme ML-DSA invece di affidarsi a un gateway che termina la crittografia post-quantistica?
La ECU deve verificare ML-DSA localmente quando valgono tutte e tre le condizioni: accetta codice o configurazione da più di un percorso di fiducia, il modello di minaccia include un gateway compromesso, e ha RAM, stack e tempo sufficienti per la verifica FIPS 204 nel suo budget di boot o di aggiornamento. Se una manca, terminate la PQC su un gateway supportato da HSM e usate autenticazione simmetrica sul segmento. Documentate l'assunzione che il gateway sia un'àncora di fiducia e inseritela nell'analisi ISO/SAE 21434. In entrambi i casi, confermate la conformità con i vettori NIST ACVP, verificate che i tentativi di downgrade vengano rifiutati e mantenete un percorso di rollback A/B con contatori anti-rollback, così che un aggiornamento PQC difettoso non renda inservibile il dispositivo.
Referenzarchitektur für Embedded-PQC: ML-KEM, ML-DSA und LMS in den Ebenen Boot, Sitzung und Feldbus
Es gibt nicht den einen richtigen Post-Quanten-Algorithmus für eine Embedded-Flotte. Die Architekturfrage ist, wo jedes Primitiv läuft: zustandsbehaftete hashbasierte Signaturen (LMS/XMSS, NIST SP 800-208, RFC 8554/RFC 8391) für die Boot-Verifikation am Vertrauensanker, ML-DSA (FIPS 204) für aktualisierbare Zertifikate und OTA-Manifeste und ML-KEM (FIPS 203) im hybriden Schlüsselaustausch (X25519MLKEM768, gemäß der Arbeit der IETF-TLS-Gruppe zum Hybrid-Design) für TLS-1.3-Sitzungen. Der zentrale Zielkonflikt liegt zwischen Ende-zu-Ende-PQC auf jedem Steuergerät und der Terminierung der PQC an einem HSM-gestützten Domänen-Gateway. Nachrichtengröße, RAM, Boot-Zeitbudget und der benötigte Grad an Interoperabilität entscheiden, welche Variante umsetzbar ist.
Kriterien für die Domänenaufteilung
Setzen Sie LMS/XMSS nur im Boot-ROM oder für die Verifikation der ersten Boot-Stufe ein, wenn die Signatur zentral in einem HSM erfolgt, das die einmalige Nutzung jedes Zustands garantieren kann. Setzen Sie ML-DSA-44/65 ein, wo Signierer verteilt sind oder zustandsloser Betrieb gefordert ist. Setzen Sie hybrides ML-KEM-768 für TLS 1.3 an Gateway und Backend ein. Auf klassischen CAN- oder CAN-FD-Segmenten, deren Knoten nur einige zehn KB freien RAM haben, terminieren Sie die PQC am Domänen-Gateway und schützen das Segment mit symmetrischer Authentisierung (etwa AUTOSAR SecOC mit AES-CMAC), mit Schlüsseln, die das Gateway verteilt.
Checkliste vor der Spezifikation
Erfassen Sie je Knoten RAM, Flash, Worst-Case-Stack, maximale Frame-Nutzlast (CAN FD 64 B, Ethernet-MTU 1500 B), Boot-Zeitbudget, HSM-Klasse (SHE oder volles HSM nach EVITA-Art), Tiefe der Zertifikatskette und Lebensdauer des Geräts im Vergleich zur Migrationsfrist (etwa den Zeitplänen von NSA CNSA 2.0). Legen Sie die Algorithmus-Identifikatoren anhand der finalen FIPS und der IETF-LAMPS/TLS-Spezifikationen fest. Fordern Sie vor der Integration eine Validierung mit NIST-ACVP/CAVP-Testvektoren und ordnen Sie die Anforderungen ISO/SAE 21434 und IEC 62443-4-2 zu.
Illustratives Szenario mit Rollout und Wiederherstellung
Analytisches Beispiel, keine Messung. Eine ML-DSA-44-Signatur ist 2420 B groß; bei 64 B CAN-FD-Nutzlast belegt sie rund 38 Frames, noch vor dem Overhead des Transportprotokolls. Damit scheidet das Signieren jeder einzelnen Nachricht auf dem Bus aus, die Verifikation gehört ans Gateway. Führen Sie die Umstellung in Phasen ein. Zuerst doppelt signierte Manifeste (ECDSA plus ML-DSA, beide werden geprüft). Danach machen Sie ML-DSA per Policy-Flag verpflichtend. Die Wiederherstellung stützt sich auf A/B-Firmware-Slots, monotone Anti-Rollback-Zähler, eine im HSM gesicherte LMS-Zustandsreservierung und eine Policy, die jeden Downgrade auf rein klassische Modi ablehnt.
Technische FAQ: Wann sollte ein Embedded-Steuergerät ML-DSA-Signaturen selbst prüfen, statt sich auf ein Gateway zu verlassen, das die Post-Quanten-Kryptografie terminiert?
Das Steuergerät sollte ML-DSA lokal prüfen, wenn alle drei Bedingungen erfüllt sind: Es nimmt Code oder Konfiguration über mehr als einen Vertrauenspfad an, das Bedrohungsmodell umfasst ein kompromittiertes Gateway, und es hat genug RAM, Stack und Zeit für die FIPS-204-Verifikation innerhalb seines Boot- oder Update-Budgets. Fehlt eine davon, terminieren Sie die PQC an einem HSM-gestützten Gateway und nutzen symmetrische Authentisierung im Segment. Dokumentieren Sie die Annahme, dass das Gateway ein Vertrauensanker ist, und nehmen Sie sie in die Analyse nach ISO/SAE 21434 auf. In beiden Fällen bestätigen Sie die Konformität mit NIST-ACVP-Vektoren, testen, dass Downgrade-Versuche abgewiesen werden, und halten einen A/B-Rollback-Pfad mit Anti-Rollback-Zählern bereit, damit ein fehlerhaftes PQC-Update das Gerät nicht unbrauchbar macht.
嵌入式后量子密码参考架构：在启动、会话与现场总线层中分层部署 ML-KEM、ML-DSA 与 LMS
嵌入式设备群并不存在唯一正确的后量子算法，架构上要决定的是每种原语部署在哪一层：有状态哈希签名（LMS/XMSS，NIST SP 800-208，RFC 8554/RFC 8391）用于信任根处的启动验证，ML-DSA（FIPS 204）用于可更新的证书和 OTA 清单，ML-KEM（FIPS 203）以混合密钥交换形式（X25519MLKEM768，依据 IETF TLS 工作组的混合设计）用于 TLS 1.3 会话。核心权衡在于：在每个 ECU 上实现端到端 PQC，还是在由 HSM 支撑的域网关处终结 PQC。消息尺寸、RAM、启动时间预算和所需的互操作程度决定哪种方案可行。
按域划分的决策标准
仅当签名集中在能保证每个状态只使用一次的 HSM 中时，才在启动 ROM 或第一阶段验证中使用 LMS/XMSS。签名方分散或必须无状态运行的场合使用 ML-DSA-44/65。网关与后端的 TLS 1.3 使用混合 ML-KEM-768。在经典 CAN 或 CAN FD 网段上，如果节点只有几十 KB 可用 RAM，应在域网关处终结 PQC，并用对称认证保护该网段（例如采用 AES-CMAC 的 AUTOSAR SecOC），密钥由网关分发。
规格制定前检查清单
逐节点统计 RAM、Flash、最坏情况栈深、最大帧载荷（CAN FD 64 字节，以太网 MTU 1500 字节）、启动时间预算、HSM 等级（SHE 或 EVITA 式完整 HSM）、证书链深度，以及设备使用寿命与迁移期限的对比（例如 NSA CNSA 2.0 时间表）。依据最终版 FIPS 和 IETF LAMPS/TLS 规范确定算法标识符。集成前要求通过 NIST ACVP/CAVP 测试向量验证，并将需求映射到 ISO/SAE 21434 与 IEC 62443-4-2。
示例场景（含上线与恢复）
以下为分析性示例，并非实测。一个 ML-DSA-44 签名为 2420 字节，在 64 字节的 CAN FD 载荷上，未计传输协议开销就需要约 38 帧。因此不宜在总线上对每条报文签名，验证应放在网关。分阶段上线：先发布双签名清单（ECDSA 加 ML-DSA，两者都要验证），再通过策略标志强制要求 ML-DSA。恢复手段包括 A/B 固件槽、单调防回滚计数器、在 HSM 中备份的 LMS 状态预留，以及拒绝降级到纯经典模式的策略。
技术常见问题 (FAQ): 嵌入式 ECU 何时应自行验证 ML-DSA 签名，而不是依赖终结后量子密码的网关？
当以下三个条件同时成立时，ECU 应在本地验证 ML-DSA：它通过不止一条信任路径接收代码或配置；威胁模型包含网关被攻破的情况；它有足够的 RAM、栈空间和时间，在启动或更新预算内完成 FIPS 204 验证。任一条件不满足，就应在由 HSM 支撑的网关处终结 PQC，并在网段内使用对称认证。将“网关是信任锚”这一假设记录下来，并纳入 ISO/SAE 21434 分析。无论采用哪种方式，都要用 NIST ACVP 向量确认一致性，测试降级尝试会被拒绝，并保留带防回滚计数器的 A/B 回滚路径，避免有缺陷的 PQC 更新导致设备变砖。
組込みPQCのリファレンスアーキテクチャ：ブート・セッション・フィールドバス各層へのML-KEM、ML-DSA、LMSの配置
組込み機器群にとって唯一の正しい耐量子アルゴリズムは存在せず、アーキテクチャ上の判断はどの層でどのプリミティブを動かすかにあります。信頼の起点でのブート検証にはステートフルなハッシュベース署名（LMS/XMSS、NIST SP 800-208、RFC 8554/RFC 8391）、更新可能な証明書とOTAマニフェストにはML-DSA（FIPS 204）、TLS 1.3セッションにはハイブリッド鍵交換のML-KEM（FIPS 203、IETF TLSのハイブリッド設計に基づくX25519MLKEM768）を用います。主なトレードオフは、全ECUでエンドツーエンドにPQCを実装するか、HSMを備えたドメインゲートウェイでPQCを終端するかです。メッセージサイズ、RAM、ブート時間の予算、必要な相互運用性の範囲によって、どちらが実現可能かが決まります。
ドメイン分割の判断基準
LMS/XMSSは、各状態の一回限りの使用を保証できるHSMに署名が集約されている場合に限り、ブートROMまたは第1段の検証に使います。署名者が分散している場合やステートレス運用が必須の場合はML-DSA-44/65を使います。ゲートウェイとバックエンドのTLS 1.3にはハイブリッドML-KEM-768を使います。空きRAMが数十KB程度しかないノードが並ぶクラシックCANやCAN FDのセグメントでは、ドメインゲートウェイでPQCを終端し、ゲートウェイが配布する鍵による対称認証（例：AES-CMACを用いたAUTOSAR SecOC）でセグメントを保護します。
仕様策定前のチェックリスト
ノードごとに、RAM、フラッシュ、最悪ケースのスタック、最大フレームペイロード（CAN FD 64バイト、Ethernet MTU 1500バイト）、ブート時間予算、HSMクラス（SHEかEVITA型のフルHSMか）、証明書チェーンの深さ、移行期限に対する製品寿命（例：NSA CNSA 2.0のタイムライン）を洗い出します。アルゴリズム識別子は最終版FIPSとIETF LAMPS/TLS仕様に基づいて確定します。統合前にNIST ACVP/CAVPテストベクタでの検証を必須とし、要件をISO/SAE 21434およびIEC 62443-4-2に対応付けます。
例示シナリオ（展開と復旧）
これは分析上の例であり、実測値ではありません。ML-DSA-44署名は2420バイトあり、64バイトのCAN FDペイロードでは、トランスポートプロトコルのオーバーヘッドを除いても約38フレームが必要です。そのためバス上でメッセージごとに署名するのは現実的でなく、検証はゲートウェイで行います。展開は段階的に進めます。まず二重署名マニフェスト（ECDSAとML-DSAの両方を検証）を配布し、次にポリシーフラグでML-DSAを必須にします。復旧はA/Bファームウェアスロット、単調増加のアンチロールバックカウンタ、HSMにバックアップしたLMS状態予約、そして古典暗号のみのモードへのダウングレードを拒否するポリシーで支えます。
技術FAQ: 組込みECUはどのような場合に、耐量子暗号を終端するゲートウェイに頼らず、自らML-DSA署名を検証すべきですか？
次の3条件がすべて成り立つ場合、ECUはML-DSAをローカルで検証すべきです。複数の信頼経路からコードや設定を受け入れること、脅威モデルにゲートウェイの侵害が含まれること、そしてブートまたは更新の予算内でFIPS 204検証を行えるRAM、スタック、時間があることです。いずれかを満たさない場合は、HSMを備えたゲートウェイでPQCを終端し、セグメント内は対称認証にします。ゲートウェイを信頼アンカーとみなす前提を文書化し、ISO/SAE 21434の分析に含めてください。どちらの方式でも、NIST ACVPベクタで適合性を確認し、ダウングレードの試みが拒否されることを試験し、アンチロールバックカウンタ付きのA/Bロールバック経路を維持して、不具合のあるPQC更新で機器が文鎮化しないようにします。
임베디드 PQC 레퍼런스 아키텍처: 부트·세션·필드버스 계층별 ML-KEM, ML-DSA, LMS 배치
임베디드 기기군에 맞는 단 하나의 양자내성 알고리즘은 없으며, 아키텍처에서 결정할 것은 각 프리미티브를 어느 계층에서 실행하느냐입니다. 신뢰 루트의 부트 검증에는 상태 기반 해시 서명(LMS/XMSS, NIST SP 800-208, RFC 8554/RFC 8391), 갱신 가능한 인증서와 OTA 매니페스트에는 ML-DSA(FIPS 204), TLS 1.3 세션에는 하이브리드 키 교환 방식의 ML-KEM(FIPS 203, IETF TLS 하이브리드 설계에 따른 X25519MLKEM768)을 사용합니다. 핵심 트레이드오프는 모든 ECU에서 종단 간 PQC를 구현할지, HSM 기반 도메인 게이트웨이에서 PQC를 종료할지입니다. 메시지 크기, RAM, 부팅 시간 예산, 필요한 상호운용성 수준에 따라 어느 쪽이 가능한지가 정해집니다.
도메인 분할 판단 기준
LMS/XMSS는 각 상태를 한 번만 사용하도록 보장할 수 있는 HSM에 서명이 집중된 경우에만 부트 ROM 또는 1단계 검증에 사용합니다. 서명 주체가 분산되어 있거나 무상태 운용이 필요한 곳에는 ML-DSA-44/65를 사용합니다. 게이트웨이와 백엔드의 TLS 1.3에는 하이브리드 ML-KEM-768을 사용합니다. 여유 RAM이 수십 KB 정도에 불과한 노드로 구성된 클래식 CAN 또는 CAN FD 세그먼트에서는 도메인 게이트웨이에서 PQC를 종료하고, 게이트웨이가 배포하는 키로 대칭 인증(예: AES-CMAC 기반 AUTOSAR SecOC)을 적용해 세그먼트를 보호합니다.
사양 확정 전 체크리스트
노드별로 RAM, 플래시, 최악 조건 스택, 최대 프레임 페이로드(CAN FD 64바이트, 이더넷 MTU 1500바이트), 부팅 시간 예산, HSM 등급(SHE 또는 EVITA형 풀 HSM), 인증서 체인 깊이, 그리고 마이그레이션 기한 대비 제품 수명(예: NSA CNSA 2.0 일정)을 조사합니다. 알고리즘 식별자는 최종 FIPS와 IETF LAMPS/TLS 사양을 기준으로 확정합니다. 통합 전에 NIST ACVP/CAVP 테스트 벡터로 검증하도록 요구하고, 요구사항을 ISO/SAE 21434 및 IEC 62443-4-2에 매핑합니다.
예시 시나리오(배포와 복구)
분석용 예시이며 실측값이 아닙니다. ML-DSA-44 서명은 2420바이트로, 64바이트 CAN FD 페이로드에서는 전송 프로토콜 오버헤드를 빼고도 약 38프레임이 필요합니다. 따라서 버스에서 메시지마다 서명하는 방식은 부적합하고, 검증은 게이트웨이에서 수행합니다. 배포는 단계적으로 진행합니다. 먼저 이중 서명 매니페스트(ECDSA와 ML-DSA 모두 검증)를 배포하고, 이후 정책 플래그로 ML-DSA를 필수로 전환합니다. 복구는 A/B 펌웨어 슬롯, 단조 증가 안티롤백 카운터, HSM에 백업한 LMS 상태 예약, 그리고 고전 암호 전용 모드로의 다운그레이드를 거부하는 정책으로 뒷받침합니다.
기술 FAQ: 임베디드 ECU는 어떤 경우에 양자내성 암호를 종료하는 게이트웨이에 의존하지 않고 ML-DSA 서명을 직접 검증해야 합니까?
다음 세 조건이 모두 충족되면 ECU가 ML-DSA를 로컬에서 검증해야 합니다. 둘 이상의 신뢰 경로로 코드나 설정을 받아들이고, 위협 모델에 게이트웨이 침해가 포함되며, 부팅 또는 업데이트 예산 안에서 FIPS 204 검증을 수행할 RAM, 스택, 시간이 있어야 합니다. 하나라도 충족되지 않으면 HSM 기반 게이트웨이에서 PQC를 종료하고 세그먼트 내부는 대칭 인증을 사용합니다. 게이트웨이를 신뢰 앵커로 본다는 가정을 문서화하고 ISO/SAE 21434 분석에 포함하십시오. 어느 방식이든 NIST ACVP 벡터로 적합성을 확인하고, 다운그레이드 시도가 거부되는지 시험하며, 안티롤백 카운터가 있는 A/B 롤백 경로를 유지해 결함 있는 PQC 업데이트로 기기가 벽돌이 되지 않도록 합니다.