From Black October to Verifiable Digital Trust
As European Cybersecurity Month draws to a close, Black October has emerged as a label for a concentration of serious vulnerability disclosures and security incidents. It brings together distinct problems, some originating months earlier, affecting shared components and relationships of trust [1]. The response requires more than resolving individual incidents. We need digital infrastructure with security assurances that can be measured, verified and demonstrated. That transformation also begins with cryptographic foundations.
A private key with the value 4
On 17 October, a researcher reported that eight private keys belonging to eMudhra intermediate certificate authorities were easily recoverable. One had the value 4; others were 56 or 115. All eight values fitted into a single byte. The risk was that these keys could be used to issue fraudulent certificates that some systems would accept as legitimate. Google and Mozilla responded by blocking the affected certificates and initiating trust removals. [2] [4]
eMudhra attributed the incident to a script error during a key ceremony involving certified hardware security modules. The publicly available information does not establish a failure of the random number generator. It does show that sound algorithms and certified components are not enough to ensure that the keys ultimately used have been generated and managed correctly. [3]
The lesson extends beyond the algorithm: we must verify the entire cryptographic process, from the origin of randomness to key selection, protection and use.
Entropy needs evidence too
Entropy provides a way to quantify the unpredictability of the material used to generate keys. Deterministic generators can produce large volumes of bits from a seed, but that seed must contain sufficient entropy. If an attacker can narrow the possibilities to a handful of values, the algorithm’s strength no longer provides the expected protection.
A sequence that looks random does not prove that its source is unpredictable. Nor is passing statistical tests on the output enough. Evaluating a source requires understanding how it works, substantiating its entropy contribution and checking during operation that the conditions supporting those assurances still hold. [5] [6]
Verification must extend to integration. A suitable entropy source cannot fix a script that selects the wrong key. Equally, a correct implementation cannot compensate for predictable initialisation. Security depends on how these elements work together.
From standards to verifiable trust
Standards and evaluation methodologies make these assurances testable. NIST SP 800-90B sets requirements for entropy sources; AIS-31, from Germany’s BSI, addresses the evaluation of physical random number generators; and FIPS 140-3 defines security requirements for cryptographic modules. [5] [6] [7]
In Spain, CCN-MEMeC, the Cryptographic Mechanisms Evaluation Methodology, and CCN-MEGA, the Random Generators Evaluation Methodology, connect these layers. MEGA supports MEMeC: evaluating cryptographic mechanisms also requires examining the generators on which they depend. [8]
These frameworks address complementary aspects of security; they are not interchangeable. Their value lies in independently assessing compliance with defined requirements under specified operating conditions. A component’s certification does not automatically cover the entire system or replace integration and operational controls. In processes such as eMudhra’s, key traceability, code review and independent checks before activating a certificate authority can reduce the risk of errors reaching production.
At Quside, we work on one of these foundations: generating entropy through quantum processes and providing evidence of its quality during operation. Our approach, LOVE (Locally Verified Entropy), combines generation and metrology. The aim is to make entropy an observable, manageable resource within cryptographic infrastructure, complementing independent evaluation with ongoing operational insight. [9] [10]
Building tomorrow’s infrastructure
Cloud computing, AI agents and autonomous systems multiply the identities and trust relationships connecting services and devices. In increasingly distributed infrastructure, generating, protecting, rotating and revoking keys must be part of the architecture. [9]
The transition to post-quantum cryptography introduces new algorithms and integration requirements, but it does not remove these responsibilities. Resistance to future quantum attacks still depends on sufficient entropy, correct implementations and rigorous key management. Changing the algorithm does not fix flawed key generation. [10]
The lessons of this October should inform architectural decisions: understand where randomness comes from, verify how it is integrated and maintain visibility throughout operation.
Digital trust cannot rest solely on a system appearing to work. We must be able to explain the assurances it provides, the evidence supporting them and how we detect when they no longer hold.
Fuentes y enlaces / Sources and links
[1] SecurityToday – Black October: Many attacks had been running for months https://www.securitytoday.de/en/2026/10/22/black-october-many-attacks-had-been-running-for-months/
[2] Scott Helme – Eight Bits of Trust; eMudhra’s CA keys cracked in milliseconds https://scotthelme.co.uk/eight-bits-of-trust-emudhras-ca-keys-cracked-in-milliseconds/
[3] eMudhra – Statement on distrust of select Global TLS Intermediate and one Root CA https://emudhra.com/en/press-release/emudhra-statement-distrust-global-tls-intermediate-root-ca
[4] Google – Protecting Chrome and Android Users from Compromised eMudhra Intermediate CA Certificates https://blog.google/security/protecting-chrome-and-android-users-from-compromised-emudhra-intermediate-ca-certificates/
[5] NIST IR 8446 – Bridging the Gap Between Standards on Random Number Generation (NIST / BSI) https://nvlpubs.nist.gov/nistpubs/ir/2026/NIST.IR.8446.pdf
[6] NIST SP 800-90B – Recommendation for the Entropy Sources Used for Random Bit Generation https://csrc.nist.gov/pubs/sp/800/90/b/final
[7] FIPS 140-3 – Security Requirements for Cryptographic Modules https://csrc.nist.gov/pubs/fips/140-3/final
[8] CCN-STIC-2110 – Random Generators Evaluation Methodology (MEGA). Relationship to CCN-MEMeC: p. 8 https://www.ccn-cert.cni.es/es/series-ccn-stic/guias/series-ccn-stic/2000-organismo-de-certificacion/7339-ccn-stic-2110-mega-metodologia-de-evaluacion-de-generadores-aleatorios/file.html
[9] Quside – The opportunity to do more: Reflections from Our Keynote at The Entropy Nexus https://quside.com/the-entropy-nexus-keynote/
[10] Quside – Why Entropy Is the Real Foundation of Cryptographic Security, and How to Get It Right https://quside.com/why-entropy-is-the-real-foundation-of-cryptographic-security-and-how-to-get-it-right/
