Note that there are tests that would catch this, but Intel specifically chooses not to test the hardware RNG using them, according to the paper. (This is ostens

Note that there are tests that would catch this, but Intel specifically chooses not to test the hardware RNG using them, according to the paper. (This is ostensibly to guard against attacks on the RNG using scan mode. That could very well be true; I don't have enough domain knowledge in designing secure hardware to know whether this is a common practice or not.) Detecting stuck-at faults is one of the main applications of scan testing[1]. Generally coverage isn't perfect, but by spending more time and making particular implementation decisions one can make coverage pretty close to arbitrarily good. Moreover, I can always choose to randomize my scan chains if I think this is a threat, and then an attacker will have to assume that he's only allowed to modify gates that can't be covered by any possible scan chain. Remember, the attacker has to modify the mask, so that means I'm making a large number of chips that all have the same flaw. So if I detect stuck-at faults using randomized scan chains on any wafer in a lot and I'm paranoid, I can re-run the failing scan chain on other chips from the same lot to determine whether it's systematic or random failure. Lest you think this is an inconvenient test to perform, almost all digital chips are scanned because it's one of the fastest ways to detect manufacturing defects. Unlike rewiring a chip, generating stuck-at faults is a really bad way of being sneaky if the target circuit is being scanned, because as I said above that's a type of error against which scan is quite good. [1] http://en.wikipedia.org/wiki/Scan_chain http://en.wikipedia.org/wiki/Scan_chain