Schneier on Security

Clive Robinson • June 29, 2026 4:08 PM

@ Bruce, ALL,

With regards,

“The article doesn’t speculate, but I will.”

We’ve been through this prior to 2013.

With respect to generating certificates on embedded devices such as “network devices”.

It’s very difficult to develop entropy on such devices when they are “first out the box” because they have next to no internal entropy and likewise external entropy[1].

Thus there would be a very high chance that all certificates generated on such devices are very closely related.

Whilst factoring the multiple of two large primes is assumed to be hard… Finding two or more such multiples that share a prime is in comparison trivial, using a simple “Greatest Common Divisor”(GCD) algorithm,

https://www.cryptool.org/en/posts/rsa-sanity-check/

As I noted back when I pointed this out, I assume that part of the NSA budget would go on “buying and testing” all edge of network devices looking for weaknesses in such certificate generating devices”

Not technically a “back door” as the NSA did not design or install it. But certainly a nicely exploitable vulnerability almost as good as the one that caused NIST such embarrassment and much to everyone’s suprise turned up on Jupiter Networks high end systems, when it should not have and was still creating issues half a decade back,

https://checkoway.net/musings/dualec/

There were other issues with RSA certs which nearly all overlap in time. Thus if the NSA knew about them all could have had access to all RSA PubKey reliant traffic this century…

Which begs the question about why the NSA are twitchy about PQC key establishment protocols…

What do they know that we don’t and is it another bit of NOBUS nonsense again.

[1] It’s one of those “Catch 22” problems… Because the devices have no real human interfaces or electromagnetic moving parts, the device / internal entropy is in the order of one or three bits a minute. Then because the embedded device has no certificate yet, it’s probably got no real external entropy coming in across the network either.

So the “Catch” is to get entropy to make a couple of random numbers of the right size to make a new secure RSA certificate… you either need the certificate already, or known entropy, neither of which is secure…

Clive Robinson • June 30, 2026 8:32 PM

@ anonymouse random,

First off apologies for not spotting you sooner, but you might have noticed there is considerable “noise on the line” preceding you.

With regards,

“Some creativity will get you usable entropy in a practical time-frame.”

The problem is –even now more than a decade and a half later– those methods are still considered not a wise thing to do security wise.

Especially if the device is configured by a “web style user interface” with a default password which many still are.

The recommended way security wise is that such devices be set up on a “secure lab network” first. Which back then was a network crossover cable from the network device directly into the “lab network port” on the operators computer or mini-hub.

This environment has very little non deterministic traffic thus few if any bits of true entropy.

Then only when “setup” should the network device be connected to an “internal network” that carries other traffic, let alone external traffic untill tested.

Back a decade and a half ago it was known and demonstrated that if you set up PCs or other devices starting in “factory default” / “out of the box” state. And you did it on a WAN with external connectivity they could be “owned within less than half a minute”… So it was considered unwise to do so, and for many people it still is.

I’ve previously discussed the types of random generator in use and their pros and cons. Our hosts versions used an “entropy file” to safely “re-seed” the entropy pool on reset/startup.

Thus my view was that the manufacturer could easily create and add a unique entropy file in the factory prior to packing and shipping.

Using sources of true entropy on the production line is a technique I developed quite a ways back last century for giving “phones” secure unique ID’s etc quickly and easily as part of “final test” on the production line for a major FMCE manufacturer with factories in several Far Eastern countries.