Rekey Storms: Testing a PQC Gateway Where It Actually Breaks
An ML-DSA signature that takes twice the median time is not a defect on the bench. It becomes one when every ECU on the bus asks for a handshake in the same second after a gateway reboot. Lattice schemes have long-tailed latency, because signing uses rejection sampling and the large keys and ciphertexts put pressure on memory, and those tails only line up badly when the system is saturated. The qualification plan has to create that saturation on purpose and then break something in the middle of it.
Why the bench lies
ML-DSA signing loops until a candidate passes its norm checks, so the number of iterations is random. At the middle security level the average is roughly four to five attempts (an estimate), and that average hides a tail several times longer. On a lightly loaded core the variance vanishes into idle time. Under load it adds up with other pressures. ML-KEM decapsulation buffers push the stack toward its guard region, HSM command queues serialise every request, and the RTOS scheduler now has to arbitrate between the crypto partition and the control loop. Unit tests and throughput benchmarks report means, while the failure lives in the joint p99.9 of several queues that never saturate on their own.
The failure worth hunting
The mode that matters is a cascade. The gateway restarts and every peer re-handshakes at once. The crypto service overruns, its watchdog fires and the HSM partition resets. Peers caught mid-establishment then retry in lockstep and recreate the storm that caused the reset. None of this is a cryptographic weakness, and functional tests never see it because each step is correct on its own. For fault tolerance, the only question is whether control traffic already protected by established session keys keeps flowing while the handshake path is on fire, which it does when microkernel isolation is genuine and does not when the crypto service shares a queue, a lock or a heap with the authenticated fieldbus path.
The storm test
Build a rig where each peer is an emulated node with a controllable start offset. Power-cycle the gateway and release every handshake inside the same scheduling window, while real control traffic keeps running at its nominal cycle. At the peak, inject the fault. Kill the HSM partition, force a watchdog reset of the crypto task, or flood it with ciphertexts of valid length that decapsulate to garbage under implicit rejection, so each one costs full work before the handshake fails. Measure three things: the end-to-end latency of the authenticated cyclic frames, the stack high-water mark of the crypto partition and the retry timing of peers after the reset. Repeat with randomised offsets and signing seeds until the tail stops moving, since a single pass measures luck, and write down the expected degraded mode before the run, because functional safety standards such as ISO 26262 and IEC 61508 accept fault injection as evidence only when both the fault and the resulting safe state trace back to the safety concept.
Decision rule
With the crypto task under a 100 ms watchdog supervision window, require the p99.9 latency of the crypto service during a synchronised storm to stay below half that window, and if it does not, redesign the gateway to shed or defer new handshakes with jittered backoff instead of queueing them, because a queue that grows faster than the HSM drains it turns load into a reset.
Technical FAQ: Why not make signing fully deterministic and remove the tail?
Constant-time code removes data-dependent timing inside an iteration, but it does not fix the iteration count, which ML-DSA exposes by design without harm. Padding every signature to the worst case would make timing deterministic, and the storm test would show the cost as lost throughput. The usual trade is to keep signing variable and put a bound on the queue in front of it.
More Technical Articles on pqcembedded.com
Tempestade de rehandshake: onde o gateway PQC quebra de verdade
Uma assinatura ML-DSA que leva o dobro da mediana não é defeito na bancada. Vira defeito quando todas as ECUs do barramento pedem handshake no mesmo segundo, logo depois que o gateway reinicia. Os esquemas de reticulado têm latência de cauda longa, porque a assinatura usa amostragem por rejeição e as chaves e criptogramas grandes pressionam a memória, e essas caudas só se alinham do jeito ruim com o sistema saturado. O plano de qualificação precisa provocar essa saturação de propósito e quebrar alguma coisa bem no meio dela.
Por que a bancada engana
A assinatura ML-DSA repete o laço até que um candidato passe nas verificações de norma, então o número de iterações é aleatório. No nível de segurança intermediário a média fica em torno de quatro a cinco tentativas (estimativa), e essa média esconde uma cauda várias vezes mais longa. Num núcleo ocioso essa variância some. Sob carga, ela se soma a outras pressões. Os buffers da decapsulação ML-KEM empurram a pilha para perto da região de guarda, a fila de comandos do HSM serializa tudo e o escalonador do RTOS passa a arbitrar entre a partição criptográfica e a malha de controle. Teste unitário e benchmark de vazão mostram médias, mas a falha está no p99.9 conjunto de várias filas que, isoladas, nunca saturam.
A falha que vale caçar
O modo que interessa é a cascata. O gateway reinicia e todos os pares refazem o handshake ao mesmo tempo. O serviço criptográfico estoura o prazo, o watchdog dispara e a partição do HSM reinicia. Os pares que estavam no meio do estabelecimento tentam de novo em sincronia e recriam a tempestade que causou o reset. Nada disso é fraqueza criptográfica, e o teste funcional não enxerga nada porque cada passo, sozinho, está correto. Para a tolerância a falhas, só importa saber se o tráfego de controle já protegido por chaves de sessão estabelecidas continua passando enquanto o caminho de handshake pega fogo, e isso só acontece quando o isolamento do microkernel é real e o serviço criptográfico não divide fila, lock nem heap com o caminho autenticado do fieldbus.
O teste da tempestade
Monte uma bancada em que cada par seja um nó emulado com atraso de partida controlável. Desligue e religue o gateway e solte todos os handshakes dentro da mesma janela de escalonamento, com o tráfego de controle real rodando no ciclo nominal. No pico, injete a falha. Pode ser derrubar a partição do HSM, forçar o reset do watchdog na tarefa criptográfica ou inundá-la com criptogramas de tamanho válido que, por rejeição implícita, decapsulam em lixo, de modo que cada um custa o trabalho inteiro antes de o handshake falhar. Meça três coisas: a latência ponta a ponta dos quadros cíclicos autenticados, o pico de uso da pilha da partição criptográfica e o tempo de nova tentativa dos pares depois do reset. Repita com atrasos e sementes de assinatura aleatórios até a cauda parar de mexer, porque uma rodada só mede sorte, e registre o modo degradado esperado antes de rodar, já que normas de segurança funcional como a ISO 26262 e a IEC 61508 só aceitam injeção de falhas como evidência quando a falha e o estado seguro resultante se rastreiam até o conceito de segurança.
Regra de decisão
Com a tarefa criptográfica supervisionada por uma janela de watchdog de 100 ms, exija que o p99.9 da latência do serviço criptográfico numa tempestade sincronizada fique abaixo da metade dessa janela, e se não ficar, o projeto precisa descartar ou adiar handshakes novos com backoff aleatorizado em vez de enfileirá-los, porque uma fila que cresce mais rápido do que o HSM consegue esvaziar transforma carga em reset.
FAQ Técnica: Por que não deixar a assinatura totalmente determinística e acabar com a cauda?
Código de tempo constante elimina a dependência de dados dentro de cada iteração, mas não fixa quantas iterações acontecem, e o ML-DSA expõe esse número por projeto, sem prejuízo à segurança. Completar toda assinatura até o pior caso deixaria o tempo determinístico, e o teste da tempestade mostraria o custo como perda de vazão. O acordo habitual é manter a assinatura variável e limitar a fila que fica na frente dela.
Mais Artigos Técnicos em pqcembedded.com
Tormenta de renegociación: dónde se rompe de verdad una pasarela PQC
Una firma ML-DSA que tarda el doble que la mediana no es un defecto en el banco de pruebas. Lo es cuando todas las ECU del bus piden handshake en el mismo segundo tras reiniciarse la pasarela. Los esquemas de retículos tienen latencias de cola larga, porque la firma usa muestreo por rechazo y las claves y los cifrados grandes presionan la memoria, y esas colas solo coinciden de la peor manera con el sistema saturado. El plan de cualificación tiene que provocar esa saturación a propósito y romper algo justo en medio.
Por qué el banco engaña
La firma ML-DSA repite el bucle hasta que un candidato supera las comprobaciones de norma, así que el número de iteraciones es aleatorio. En el nivel de seguridad intermedio la media ronda las cuatro o cinco tentativas (estimación), y esa media oculta una cola varias veces más larga. En un núcleo ocioso la varianza desaparece. Con carga, se suma a otras presiones. Los búferes de la desencapsulación ML-KEM acercan la pila a su zona de guarda, la cola de comandos del HSM serializa cada petición y el planificador del RTOS tiene que arbitrar entre la partición criptográfica y el lazo de control. Las pruebas unitarias y los benchmarks de rendimiento dan medias, pero el fallo está en el p99.9 conjunto de varias colas que por separado nunca se saturan.
El fallo que merece la pena buscar
El modo que importa es una cascada. La pasarela se reinicia y todos los pares rehacen el handshake a la vez. El servicio criptográfico se pasa de plazo, salta el watchdog y la partición del HSM se reinicia. Los pares que estaban a medio establecer reintentan al unísono y recrean la tormenta que provocó el reinicio. Nada de esto es una debilidad criptográfica, y las pruebas funcionales no lo ven porque cada paso, por sí solo, es correcto. Para la tolerancia a fallos solo cuenta si el tráfico de control ya protegido por claves de sesión establecidas sigue circulando mientras arde la ruta de handshake, y eso pasa únicamente si el aislamiento del microkernel es real y el servicio criptográfico no comparte cola, cerrojo ni heap con la ruta autenticada del bus de campo.
La prueba de tormenta
Monte un banco en el que cada par sea un nodo emulado con un desfase de arranque controlable. Apague y encienda la pasarela y suelte todos los handshakes dentro de la misma ventana de planificación, con el tráfico de control real en su ciclo nominal. En el pico, inyecte el fallo. Puede tirar la partición del HSM, forzar un reinicio por watchdog de la tarea criptográfica o inundarla con cifrados de longitud válida que, por el rechazo implícito, se desencapsulan en basura, de modo que cada uno cuesta el trabajo completo antes de que falle el handshake. Mida tres cosas: la latencia extremo a extremo de las tramas cíclicas autenticadas, el máximo de uso de pila de la partición criptográfica y el ritmo de reintentos de los pares tras el reinicio. Repita con desfases y semillas de firma aleatorios hasta que la cola deje de moverse, porque una sola pasada mide suerte, y deje escrito el modo degradado esperado antes de ejecutar, ya que las normas de seguridad funcional como ISO 26262 e IEC 61508 solo aceptan la inyección de fallos como evidencia cuando el fallo y el estado seguro resultante se trazan hasta el concepto de seguridad.
Regla de decisión
Si la tarea criptográfica está supervisada por una ventana de watchdog de 100 ms, exija que el p99.9 de latencia del servicio criptográfico durante una tormenta sincronizada quede por debajo de la mitad de esa ventana, y si no lo consigue, el diseño debe descartar o aplazar los handshakes nuevos con backoff aleatorizado en lugar de encolarlos, porque una cola que crece más deprisa de lo que el HSM la vacía convierte la carga en un reinicio.
Preguntas Frecuentes Técnicas: ¿Por qué no hacer la firma totalmente determinista y eliminar la cola?
El código de tiempo constante elimina la dependencia de los datos dentro de cada iteración, pero no fija cuántas iteraciones hay, y ML-DSA expone ese número por diseño sin perjuicio para la seguridad. Rellenar cada firma hasta el peor caso haría el tiempo determinista, y la prueba de tormenta mostraría el coste como rendimiento perdido. Lo habitual es dejar la firma variable y acotar la cola que tiene delante.
Más Artículos Técnicos en pqcembedded.com
Tempête de renégociation : là où une passerelle PQC casse vraiment
Une signature ML-DSA qui prend deux fois le temps médian n’est pas un défaut sur le banc. Elle le devient quand tous les calculateurs du bus réclament un handshake dans la même seconde après le redémarrage de la passerelle. Les schémas à base de réseaux euclidiens ont une latence à queue longue, à cause de l’échantillonnage par rejet à la signature et de la pression mémoire des grosses clés et des gros chiffrés, et ces queues ne se superposent de la pire façon qu’une fois le système saturé. Le plan de qualification doit créer cette saturation volontairement, puis casser quelque chose en plein milieu.
Pourquoi le banc ment
La signature ML-DSA boucle jusqu’à ce qu’un candidat passe les contrôles de norme, si bien que le nombre d’itérations est aléatoire. Au niveau de sécurité intermédiaire, la moyenne tourne autour de quatre à cinq tentatives (estimation), et cette moyenne masque une queue plusieurs fois plus longue. Sur un cœur peu chargé, la variance se perd dans le temps d’inactivité. Sous charge, elle s’ajoute à d’autres pressions. Les tampons de décapsulation ML-KEM poussent la pile vers sa zone de garde, la file de commandes du HSM sérialise chaque requête et l’ordonnanceur du RTOS doit arbitrer entre la partition cryptographique et la boucle de contrôle. Tests unitaires et benchmarks de débit donnent des moyennes, alors que la défaillance se loge dans le p99.9 conjoint de plusieurs files qui, isolément, ne saturent jamais.
La défaillance à traquer
Le mode qui compte est une cascade. La passerelle redémarre et tous les pairs refont leur handshake en même temps. Le service cryptographique dépasse son échéance, le chien de garde se déclenche et la partition HSM redémarre. Les pairs pris en cours d’établissement réessaient au même rythme et recréent la tempête qui a provoqué la réinitialisation. Rien de tout cela n’est une faiblesse cryptographique, et les tests fonctionnels n’y voient rien puisque chaque étape, prise seule, est correcte. Pour la tolérance aux pannes, la seule question est de savoir si le trafic de contrôle déjà protégé par des clés de session établies continue de passer pendant que le chemin de handshake s’effondre, ce qui n’arrive que si l’isolation du micronoyau est réelle et que le service cryptographique ne partage ni file, ni verrou, ni tas avec le chemin authentifié du bus de terrain.
Le test de tempête
Montez un banc où chaque pair est un nœud émulé avec un décalage de démarrage réglable. Coupez puis rallumez la passerelle et lâchez tous les handshakes dans la même fenêtre d’ordonnancement, pendant que le vrai trafic de contrôle tourne à son cycle nominal. Au pic, injectez la faute. Vous pouvez tuer la partition HSM, forcer une réinitialisation de la tâche cryptographique par le chien de garde, ou l’inonder de chiffrés de longueur valide qui, par rejet implicite, se décapsulent en données inutiles, de sorte que chacun coûte un travail complet avant l’échec du handshake. Mesurez trois choses: la latence de bout en bout des trames cycliques authentifiées, le niveau maximal de pile de la partition cryptographique et le rythme des nouvelles tentatives des pairs après la réinitialisation. Répétez avec des décalages et des graines de signature aléatoires jusqu’à ce que la queue ne bouge plus, car une seule passe mesure la chance, et consignez le mode dégradé attendu avant l’essai, puisque les normes de sécurité fonctionnelle comme l’ISO 26262 et l’IEC 61508 n’admettent l’injection de fautes comme preuve que si la faute et l’état sûr qui en résulte se rattachent au concept de sécurité.
Règle de décision
Si la tâche cryptographique est surveillée par une fenêtre de chien de garde de 100 ms, exigez que le p99.9 de latence du service cryptographique pendant une tempête synchronisée reste sous la moitié de cette fenêtre, et à défaut, la conception doit rejeter ou différer les nouveaux handshakes avec un backoff aléatoire plutôt que de les mettre en file, car une file qui grossit plus vite que le HSM ne la vide transforme la charge en réinitialisation.
FAQ Technique: Pourquoi ne pas rendre la signature entièrement déterministe pour supprimer la queue?
Le code à temps constant supprime la dépendance aux données à l’intérieur de chaque itération, mais il ne fixe pas le nombre d’itérations, que ML-DSA expose par construction sans conséquence pour la sécurité. Aligner chaque signature sur le pire cas rendrait le temps déterministe, et le test de tempête montrerait le prix en débit perdu. Le compromis habituel consiste à garder une signature variable et à borner la file placée devant elle.
Plus d'Articles Techniques sur pqcembedded.com
Tempesta di rinegoziazione: dove un gateway PQC si rompe davvero
Una firma ML-DSA che impiega il doppio della mediana non è un difetto al banco. Lo diventa quando tutte le centraline del bus chiedono un handshake nello stesso secondo, dopo il riavvio del gateway. Gli schemi a reticolo hanno latenze a coda lunga, perché la firma usa il campionamento a rifiuto e chiavi e cifrati di grandi dimensioni mettono sotto pressione la memoria, e queste code si sommano nel modo peggiore solo con il sistema saturo. Il piano di qualifica deve creare quella saturazione di proposito e poi rompere qualcosa proprio nel mezzo.
Perché il banco inganna
La firma ML-DSA ripete il ciclo finché un candidato non supera i controlli di norma, quindi il numero di iterazioni è casuale. Al livello di sicurezza intermedio la media si aggira sui quattro o cinque tentativi (stima), e questa media nasconde una coda parecchie volte più lunga. Su un core scarico la varianza sparisce nei tempi morti. Sotto carico si somma ad altre pressioni. I buffer della decapsulazione ML-KEM spingono lo stack verso la zona di guardia, la coda comandi dell’HSM serializza ogni richiesta e lo scheduler dell’RTOS deve scegliere tra la partizione crittografica e l’anello di controllo. Test unitari e benchmark di throughput restituiscono medie, mentre il guasto sta nel p99.9 congiunto di più code che da sole non si saturano mai.
Il guasto da cercare
Il modo che conta è una cascata. Il gateway riparte e tutti i peer rifanno l’handshake insieme. Il servizio crittografico sfora la scadenza, scatta il watchdog e la partizione HSM si riavvia. I peer rimasti a metà dell’instaurazione ritentano in sincronia e ricreano la tempesta che ha causato il reset. Niente di tutto questo è una debolezza crittografica, e i test funzionali non lo vedono perché ogni passo, preso da solo, è corretto. Per la tolleranza ai guasti conta soltanto se il traffico di controllo già protetto da chiavi di sessione stabilite continua a scorrere mentre il percorso di handshake va a fuoco, e questo succede solo se l’isolamento del microkernel è reale e il servizio crittografico non condivide code, lock o heap con il percorso autenticato del bus di campo.
Il test della tempesta
Costruite un banco in cui ogni peer sia un nodo emulato con uno sfasamento di avvio regolabile. Spegnete e riaccendete il gateway e rilasciate tutti gli handshake nella stessa finestra di scheduling, mentre il traffico di controllo reale gira al suo ciclo nominale. Al picco, iniettate il guasto. Potete abbattere la partizione HSM, forzare un reset da watchdog del task crittografico o inondarlo di cifrati di lunghezza valida che, per effetto del rifiuto implicito, si decapsulano in dati inutili, così che ognuno costi il lavoro completo prima che l’handshake fallisca. Misurate tre grandezze: la latenza end-to-end dei frame ciclici autenticati, il picco di occupazione dello stack della partizione crittografica e i tempi di ritentativo dei peer dopo il reset. Ripetete con sfasamenti e semi di firma casuali finché la coda non smette di muoversi, perché un solo passaggio misura la fortuna, e scrivete il modo degradato atteso prima della prova, dato che le norme di sicurezza funzionale come la ISO 26262 e la IEC 61508 accettano l’iniezione di guasti come evidenza solo se il guasto e lo stato sicuro risultante sono tracciabili fino al concetto di sicurezza.
Regola di decisione
Con il task crittografico sotto una finestra di supervisione del watchdog di 100 ms, pretendete che il p99.9 di latenza del servizio crittografico durante una tempesta sincronizzata resti sotto la metà di quella finestra, e se non ci resta, il progetto deve scartare o rimandare i nuovi handshake con backoff randomizzato invece di accodarli, perché una coda che cresce più in fretta di quanto l’HSM la svuoti trasforma il carico in un reset.
FAQ Tecnica: Perché non rendere la firma del tutto deterministica ed eliminare la coda?
Il codice a tempo costante elimina la dipendenza dai dati dentro ogni iterazione, ma non fissa il numero di iterazioni, che ML-DSA espone per progetto senza danni alla sicurezza. Portare ogni firma al caso peggiore renderebbe i tempi deterministici, e il test della tempesta mostrerebbe il prezzo come throughput perso. Il compromesso abituale è lasciare la firma variabile e limitare la coda che le sta davanti.
Altri Articoli Tecnici su pqcembedded.com
Rekey-Sturm: Wo ein PQC-Gateway wirklich bricht
Eine ML-DSA-Signatur, die doppelt so lange wie der Median braucht, ist auf dem Prüfstand kein Fehler. Zum Fehler wird sie, wenn nach einem Gateway-Neustart alle Steuergeräte am Bus in derselben Sekunde einen Handshake verlangen. Gitterbasierte Verfahren haben Latenzen mit langem Ausläufer, weil die Signatur Rejection Sampling nutzt und große Schlüssel und Chiffrate den Speicher belasten, und diese Ausläufer treffen erst im gesättigten System ungünstig aufeinander. Der Qualifikationsplan muss diese Sättigung gezielt herbeiführen und mitten darin etwas kaputt machen.
Warum der Prüfstand täuscht
Die ML-DSA-Signatur wiederholt ihre Schleife, bis ein Kandidat die Normprüfungen besteht, die Zahl der Iterationen ist also zufällig. Auf der mittleren Sicherheitsstufe liegt der Mittelwert bei etwa vier bis fünf Versuchen (Schätzung), und dahinter verbirgt sich ein um ein Mehrfaches längerer Ausläufer. Auf einem kaum ausgelasteten Kern verschwindet die Varianz in der Leerlaufzeit. Unter Last addiert sie sich zu anderen Belastungen. Die Puffer der ML-KEM-Dekapselung treiben den Stack an seinen Schutzbereich, die Befehlswarteschlange des HSM serialisiert jede Anfrage, und der RTOS-Scheduler muss zwischen Kryptopartition und Regelkreis entscheiden. Unit-Tests und Durchsatzbenchmarks liefern Mittelwerte, der Fehler steckt aber im gemeinsamen p99.9 mehrerer Warteschlangen, von denen keine allein je sättigt.
Der Fehler, den es zu jagen gilt
Entscheidend ist eine Kaskade. Das Gateway startet neu, und alle Gegenstellen wiederholen gleichzeitig ihren Handshake. Der Kryptodienst überzieht seine Frist, der Watchdog schlägt an, und die HSM-Partition wird zurückgesetzt. Gegenstellen, die mitten im Verbindungsaufbau steckten, versuchen es im Gleichtakt erneut und erzeugen genau den Sturm, der den Reset ausgelöst hat. Nichts davon ist eine kryptografische Schwäche, und Funktionstests sehen es nicht, weil jeder Schritt für sich korrekt ist. Für die Fehlertoleranz zählt allein, ob der Steuerverkehr, der bereits mit etablierten Sitzungsschlüsseln geschützt ist, weiterläuft, während der Handshake-Pfad brennt, und das gelingt nur, wenn die Mikrokernel-Isolation echt ist und der Kryptodienst weder Warteschlange noch Lock noch Heap mit dem authentifizierten Feldbuspfad teilt.
Der Sturmtest
Baut einen Prüfaufbau, in dem jede Gegenstelle ein emulierter Knoten mit einstellbarem Startversatz ist. Schaltet das Gateway aus und wieder ein und gebt alle Handshakes im selben Scheduling-Fenster frei, während der echte Steuerverkehr im Nennzyklus weiterläuft. Auf dem Höhepunkt injiziert ihr den Fehler. Ihr könnt die HSM-Partition abschießen, einen Watchdog-Reset der Kryptotask erzwingen oder sie mit Chiffraten gültiger Länge fluten, die durch implizite Zurückweisung zu Datenmüll dekapseln, sodass jedes einzelne die volle Rechenarbeit kostet, bevor der Handshake scheitert. Gemessen werden drei Größen: die Ende-zu-Ende-Latenz der authentifizierten zyklischen Frames, der Stack-Höchststand der Kryptopartition und das Wiederholverhalten der Gegenstellen nach dem Reset. Wiederholt den Lauf mit zufälligen Versätzen und Signatur-Seeds, bis sich der Ausläufer nicht mehr bewegt, denn ein einzelner Durchlauf misst nur Glück, und legt den erwarteten degradierten Modus vor dem Lauf schriftlich fest, weil Normen der funktionalen Sicherheit wie ISO 26262 und IEC 61508 Fehlerinjektion nur dann als Nachweis gelten lassen, wenn sich Fehler und resultierender sicherer Zustand auf das Sicherheitskonzept zurückführen lassen.
Entscheidungsregel
Läuft die Kryptotask unter einem Watchdog-Überwachungsfenster von 100 ms, muss das p99.9 der Latenz des Kryptodienstes in einem synchronisierten Sturm unter der Hälfte dieses Fensters bleiben, und gelingt das nicht, muss das Design neue Handshakes mit zufällig gestreutem Backoff abweisen oder verschieben, statt sie einzureihen, denn eine Warteschlange, die schneller wächst, als das HSM sie abarbeitet, macht aus Last einen Reset.
Technische FAQ: Warum die Signatur nicht vollständig deterministisch machen und den Ausläufer beseitigen?
Konstantzeit-Code beseitigt die Datenabhängigkeit innerhalb einer Iteration, legt aber die Zahl der Iterationen nicht fest, die ML-DSA konstruktionsbedingt und ohne Sicherheitsnachteil offenlegt. Jede Signatur auf den schlechtesten Fall aufzufüllen, würde das Zeitverhalten deterministisch machen, und der Sturmtest würde die Kosten als verlorenen Durchsatz zeigen. Der übliche Kompromiss besteht darin, die Signatur variabel zu lassen und die vorgelagerte Warteschlange zu begrenzen.
Weitere Fachartikel auf pqcembedded.com
重协商风暴：PQC网关真正崩溃的地方
一次耗时达到中位数两倍的ML-DSA签名，在台架上算不上缺陷。网关重启后，总线上所有ECU在同一秒内发起握手，它就成了缺陷。格密码方案的时延天生长尾，签名用的是拒绝采样，大尺寸密钥和密文又给内存带来压力，而这些长尾只有在系统饱和时才会以最糟的方式叠在一起。资格验证计划必须主动制造这种饱和，再在饱和的正中间弄坏点什么。
台架为什么会骗人
ML-DSA签名会反复循环，直到某个候选值通过范数检查，所以迭代次数是随机的。在中等安全级别下，平均大约需要四到五次尝试（估计值），而这个平均数背后藏着长出好几倍的尾部。在负载很轻的核上，这点方差会被空闲时间吸收掉。一旦有负载，它就和其他压力叠加起来：ML-KEM解封装的工作缓冲区把栈推向保护区，HSM命令队列把每个请求都串行化，RTOS调度器还得在密码分区和控制回路之间取舍。单元测试和吞吐量基准给出的都是均值，而故障藏在几条队列的联合p99.9里，这些队列单独拿出来，哪一条都不会饱和。
值得追查的失效
真正要关注的是级联。网关重启，所有对端同时重新握手。密码服务超出时限，看门狗触发，HSM分区被复位。正处于会话建立中途的对端随后步调一致地重试，又造出了引发复位的那场风暴。这里没有任何密码学弱点，功能测试也看不到，因为每一步单独看都是对的。对容错来说，唯一的问题是：握手路径着火的时候，已经由现有会话密钥保护的控制流量还能不能继续流动。只有微内核隔离是真实的，而且密码服务没有和经过认证的现场总线路径共用队列、锁或堆，答案才是肯定的。
风暴测试
搭一套台架，每个对端都是启动偏移可控的仿真节点。给网关断电再上电，在同一个调度窗口内放出全部握手，同时让真实控制流量按额定周期运行。在峰值时注入故障，可以直接杀掉HSM分区，可以强制看门狗复位密码任务，也可以用长度合法的密文去淹没它：这些密文在隐式拒绝机制下解封装出无用数据，每一个都要先耗完全部计算量，握手才会失败。只测三样东西：认证周期帧的端到端时延，密码分区的栈高水位，以及复位后对端的重试时序。用随机化的偏移和签名种子反复运行，直到尾部不再变化，因为只跑一遍测到的是运气；预期的降级模式要在运行之前写下来，因为ISO 26262、IEC 61508这类功能安全标准只有在注入的故障和由此进入的安全状态都能追溯到安全概念时，才认可故障注入作为证据。
判定规则
如果密码任务受100 ms的看门狗监控窗口约束，就要求同步风暴下密码服务的p99.9时延低于该窗口的一半，达不到时，设计必须用带随机抖动的退避去丢弃或推迟新握手，而不是把它们排进队列，因为队列增长得比HSM消化得快，负载就会变成复位。
技术常见问题 (FAQ): 为什么不把签名做成完全确定性的，彻底消除尾部？
常数时间实现消除的是单次迭代内部对数据的依赖，迭代次数本身并不固定，ML-DSA按设计会暴露这个次数，但这对安全无害。把每次签名都补齐到最坏情况固然能让时间变得确定，风暴测试也会把代价以吞吐量损失的形式摆出来。通常的折中是保留签名的可变耗时，同时给它前面的队列设上限。
更多技术文章： pqcembedded.com
再鍵交換ストーム：PQCゲートウェイが本当に壊れる場所
中央値の2倍かかるML-DSA署名は、ベンチ上では欠陥とは言えない。ゲートウェイの再起動直後、バス上の全ECUが同じ1秒の中でハンドシェイクを求めてきたときに、初めて欠陥になる。格子暗号のレイテンシは裾が長い。署名が棄却サンプリングを使い、大きな鍵と暗号文がメモリを圧迫するからだ。しかもその裾が最悪の形で重なるのは、システムが飽和したときに限られる。認定計画では、この飽和を意図して作り出し、その真っ只中で何かを壊さなければならない。
ベンチが嘘をつく理由
ML-DSAの署名は、候補がノルム検査を通るまでループを繰り返すので、反復回数はランダムになる。中位のセキュリティレベルでは平均でおよそ4〜5回（推定値）だが、その平均の裏には数倍長い裾が隠れている。負荷の軽いコアなら、このばらつきはアイドル時間に吸収されて見えない。負荷がかかると、ほかの圧力と重なり合う。ML-KEMのデカプセル化用バッファがスタックをガード領域へ押しやり、HSMのコマンドキューはすべての要求を直列化し、RTOSのスケジューラは暗号パーティションと制御ループのどちらを優先するか決めなければならなくなる。単体テストやスループット計測が返すのは平均値であり、障害は、単独では決して飽和しない複数のキューの同時p99.9に潜んでいる。
狙うべき故障モード
問題になるのはカスケードだ。ゲートウェイが再起動し、全ピアが一斉にハンドシェイクをやり直す。暗号サービスが期限を超え、ウォッチドッグが発火して、HSMパーティションがリセットされる。確立途中だったピアは足並みをそろえて再試行し、リセットの原因になったストームをもう一度作り出す。どこにも暗号学的な弱点はなく、各ステップが単体では正しいので、機能テストでは何も見えない。耐障害性の観点で問うべきことは一つで、ハンドシェイク経路が炎上している間も、確立済みのセッション鍵で守られた制御トラフィックが流れ続けるかどうかだ。流れ続けるのは、マイクロカーネルの分離が本物で、暗号サービスが認証付きフィールドバス経路とキューもロックもヒープも共有していない場合に限られる。
ストーム試験
各ピアを、起動オフセットを制御できるエミュレートノードとして用意したリグを組む。ゲートウェイの電源を入れ直し、実際の制御トラフィックを定格周期で流したまま、全ハンドシェイクを同じスケジューリング窓の中で一斉に解き放つ。ピークで故障を注入する。HSMパーティションを落としてもいいし、暗号タスクにウォッチドッグリセットを強制してもいい。長さだけは正しい暗号文を大量に送り込む手もある。暗黙的棄却によってゴミにデカプセル化されるので、1件ごとに計算を丸ごと消費してからハンドシェイクが失敗する。計測するのは三つだけで、認証付き周期フレームのエンドツーエンド遅延、暗号パーティションのスタック最高水位、そしてリセット後のピアの再試行タイミングである。一度きりの実行は運を測っているにすぎないので、オフセットと署名シードを乱数化して裾が動かなくなるまで繰り返し、期待する縮退モードは実行前に書き残しておくこと。ISO 26262やIEC 61508といった機能安全規格は、注入した故障とその結果の安全状態が安全コンセプトまでトレースできる場合に限り、故障注入をエビデンスとして認めるからだ。
判定ルール
暗号タスクを100 msのウォッチドッグ監視窓で監視しているなら、同期ストーム下での暗号サービスのp99.9レイテンシがその窓の半分を下回ることを要求し、下回らない場合は新規ハンドシェイクをキューに積まず、ジッタ付きバックオフで破棄または延期する設計に改めるべきであり、それはHSMの処理より速く伸びるキューが負荷をリセットに変えてしまうからだ。
技術FAQ: 署名を完全に決定的にして、裾をなくしてしまえばよいのでは？
定数時間実装がなくすのは各反復の内部にあるデータ依存性で、反復回数そのものは固定されない。ML-DSAはこの回数を設計上外部に見せているが、安全性への害はない。すべての署名を最悪ケースまで埋め合わせれば時間は決定的になるが、ストーム試験はその代償をスループットの低下として突きつけてくる。署名は可変のまま残し、その手前のキューに上限を設けるのが通常の落としどころだ。
その他の技術記事： pqcembedded.com
재협상 폭주: PQC 게이트웨이가 실제로 무너지는 지점
중앙값의 두 배가 걸리는 ML-DSA 서명은 벤치에서는 결함이 아니다. 게이트웨이가 재부팅된 직후 버스 위의 모든 ECU가 같은 1초 안에 핸드셰이크를 요구할 때 비로소 결함이 된다. 격자 기반 방식은 지연 분포의 꼬리가 길다. 서명이 거부 샘플링을 쓰고, 큰 키와 암호문이 메모리를 압박하기 때문이다. 그리고 이 꼬리들은 시스템이 포화됐을 때만 최악의 방식으로 겹친다. 인증 계획은 이 포화를 일부러 만들어 내고, 그 한가운데서 무언가를 망가뜨려야 한다.
벤치가 속이는 이유
ML-DSA 서명은 후보가 노름 검사를 통과할 때까지 루프를 반복하므로 반복 횟수가 무작위다. 중간 보안 수준에서는 평균이 대략 네다섯 번(추정치)인데, 이 평균 뒤에는 몇 배나 긴 꼬리가 숨어 있다. 부하가 가벼운 코어에서는 이 편차가 유휴 시간에 묻혀 보이지 않는다. 부하가 걸리면 다른 압력과 겹친다. ML-KEM 역캡슐화 작업 버퍼가 스택을 가드 영역 쪽으로 밀어붙이고, HSM 명령 큐는 모든 요청을 직렬화하며, RTOS 스케줄러는 암호 파티션과 제어 루프 사이에서 우선순위를 정해야 한다. 단위 테스트와 처리량 벤치마크는 평균을 보여 줄 뿐이고, 장애는 각자 따로는 결코 포화되지 않는 여러 큐의 결합 p99.9에 숨어 있다.
추적할 가치가 있는 고장
주목해야 할 고장 모드는 연쇄다. 게이트웨이가 재시작하고, 모든 피어가 동시에 핸드셰이크를 다시 시도한다. 암호 서비스가 기한을 넘기고, 워치독이 동작해 HSM 파티션이 리셋된다. 세션을 맺던 도중이던 피어들이 보조를 맞춰 재시도하면서 리셋을 일으킨 바로 그 폭주를 다시 만들어 낸다. 어디에도 암호학적 약점은 없고, 각 단계가 단독으로는 올바르기 때문에 기능 테스트에도 드러나지 않는다. 내결함성 관점에서 따질 것은 하나다. 핸드셰이크 경로에 불이 붙은 동안에도 이미 수립된 세션 키로 보호되는 제어 트래픽이 계속 흐르느냐는 것이다. 그렇게 되려면 마이크로커널 격리가 진짜여야 하고, 암호 서비스가 인증된 필드버스 경로와 큐도, 락도, 힙도 공유하지 않아야 한다.
폭주 시험
각 피어를 시작 오프셋을 조절할 수 있는 에뮬레이션 노드로 둔 리그를 만든다. 게이트웨이 전원을 껐다 켜고, 실제 제어 트래픽을 정격 주기로 돌리면서 모든 핸드셰이크를 같은 스케줄링 윈도 안에 한꺼번에 풀어놓는다. 정점에서 고장을 주입한다. HSM 파티션을 죽이거나, 암호 태스크에 워치독 리셋을 강제하거나, 길이만 유효한 암호문을 쏟아부을 수 있다. 이런 암호문은 암묵적 거부 때문에 쓰레기 값으로 역캡슐화되므로, 하나하나가 연산을 전부 소모한 뒤에야 핸드셰이크가 실패한다. 측정 대상은 세 가지뿐이다. 인증된 주기 프레임의 종단 간 지연, 암호 파티션의 스택 최고 수위, 리셋 이후 피어들의 재시도 타이밍이다. 한 번 돌린 결과는 운을 잰 것에 불과하니 오프셋과 서명 시드를 무작위로 바꿔 가며 꼬리가 더 이상 움직이지 않을 때까지 반복하고, 기대하는 열화 모드는 실행 전에 문서로 남겨 둔다. ISO 26262나 IEC 61508 같은 기능 안전 표준은 주입한 고장과 그 결과로 들어간 안전 상태가 모두 안전 개념까지 추적될 때만 고장 주입을 증거로 인정하기 때문이다.
판정 규칙
암호 태스크가 100 ms 워치독 감시 윈도 아래에서 돈다면 동기화된 폭주 상황에서 암호 서비스의 p99.9 지연이 그 윈도의 절반 아래에 머물도록 요구하고, 그러지 못하면 새 핸드셰이크를 큐에 쌓지 말고 지터를 넣은 백오프로 버리거나 미루도록 설계를 바꿔야 하는데, HSM이 비우는 속도보다 빨리 자라는 큐는 부하를 리셋으로 바꿔 놓기 때문이다.
기술 FAQ: 서명을 완전히 결정적으로 만들어 꼬리를 없애면 되지 않나?
상수 시간 구현은 각 반복 안의 데이터 의존성을 없앨 뿐 반복 횟수 자체를 고정하지는 않는다. ML-DSA는 이 횟수를 설계상 드러내지만 보안에는 해가 없다. 모든 서명을 최악의 경우에 맞춰 채우면 시간은 결정적이 되지만, 폭주 시험은 그 대가를 처리량 손실로 보여 준다. 흔히 택하는 절충은 서명 시간은 가변으로 두고 그 앞에 놓인 큐에 상한을 거는 것이다.