Stealthy Dopant-Level Hardware Trojans
DoctorBit writes "A team of researchers funded in part by the NSF has just published a paper in which they demonstrate a way to introduce hardware Trojans into a chip by altering only the dopant masks of a few of the chip's transistors. From the paper: 'Instead of adding additional circuitry to the target design, we insert our hardware Trojans by changing the dopant polarity of existing transistors. Since the modified circuit appears legitimate on all wiring layers (including all metal and polysilicon), our family of Trojans is resistant to most detection techniques, including fine-grain optical inspection and checking against "golden chips."' In a test of their technique against Intel's Ivy Bridge Random Number Generator (RNG) the researchers found that by setting selected flip-flop outputs to zero or one, 'Our Trojan is capable of reducing the security of the produced random number from 128 bits to n bits, where n can be chosen.' They conclude that 'Since the Trojan RNG has an entropy of n bits and [the original circuitry] uses a very good digital post-processing, namely AES, the Trojan easily passes the NIST random number test suite if n is chosen sufficiently high by the attacker. We tested the Trojan for n = 32 with the NIST random number test suite and it passed for all tests. The higher the value n that the attacker chooses, the harder it will be for an evaluator to detect that the random numbers have been compromised.'"
So all the NSA needs to do is kidnap your chip, microscopically re-dope it, and shove it back in your computer without you noticing!
Phew... I'm glad there are absolutely no other simpler ways for the NSA to spy on us other than re-doping chips! I'll just superglue mine into the socket so I know I'm safe.
AntiFA: An abbreviation for Anti First Amendment.
Can an entire three-letter-agency get a corporate hard-on? 'Cause if they can, this gave our favorite one the biggest boner in the known universe.
Is it just my observation, or are there way too many stupid people in the world?
I would guess that an intelligence agency figured this out a few years ago. One that can plant moles at Intel. That's why they also want to remove rdrand from Linux.
http://linux.slashdot.org/story/13/09/10/1311247/linus-responds-to-rdrand-petition-with-scorn
Yes. A device that contains something concealed and malevolent? That's a hardware trojan right there.
You brought it inside the walls on the advertisement that it was a big wooden horse, but it has the enemy inside. Yep.
What else would you call physical access to your dopant masks? /sarcasm
Repeat after me: physical access to <insert item here> allows for a much greater security risk.
"Heck what about random generator devices?"
The whole point of TFA is about a technique for (mostly undetectably) modifying a good hardware RNG and turning it into a really lousy one.
Getting your entropy from multiple places probably helps (if they don't know what 6 RNGs you chose it's harder to dope them all, and even if they do, they still have to slog through the entropy from multiple crippled sources rather than only a single one (and, while it is possible to cripple the RNG entirely, that will show up on tests, so plausible real-world implementations would still provide some entropy, just less than advertised).
This should still be detectable. It just requires more time. One could also reduce the time by looking at the combined output of an entire batch of chips. If they all have the same mask, they will all produce the same reduced set of random numbers. So one additional meta-test of data from a lot could show they have been compromised.
I wonder if they also considered that the NIST random number test suite might also be compromised by the NSA...
"When information is power, privacy is freedom" - Jah-Wren Ryel
Well yeah it's worth being aware of the possibility. But frankly there are very much bigger risks to worry about first
Since the Ivy-bridge random number generator is supposedly "unauditable" how are these researchers able to prove anything about re-doping a black box design? Shouldn't they just look at it and spot the massive array of transistors that spells out "NSA BACKDOOR UNIT" instead of having to worry about all this subterfuge?
AntiFA: An abbreviation for Anti First Amendment.
1. Changing the dopant in a transistor is undetectable by visual inspection - clearly;
2. Randomness isn't the same as predictability.
I skimmed through the paper thinking that the innovation was that they'd actually been able to modify an Intel chip. But they appear to be saying little more than that you can manufacture a chip "wrongly" (after a LOT of waffle - you'd never get away with this writing math papers!).
There are easy numeric methods for determining how random data is.
Actually, no. Technically speaking, there is no such thing as random data, only a random process. You can certainly test how random a data stream seems, but if the data source is a black box, you never really know.
From TFS:
Since the Trojan RNG has an entropy of n bits and [the original circuitry] uses a very good digital post-processing, namely AES, the Trojan easily passes the NIST random number test suite if n is chosen sufficiently high by the attacker. We tested the Trojan for n = 32 with the NIST random number test suite and it passed for all tests.
What if your black box is just feeding you encrypted bits of pi? You would never know, but the black box's maker could trivially reproduce your "random" numbers.
The "discoveries" in this paper are:
1) A chemical change is undetectable by visual inspection;
2) Reducing the number of bits used for randomisation may be undetectable.
That's not worth a multi-page paper, is it?
We tested the Trojan for n = 32 with the NIST random number test suite and it passed for all tests.
While your assessment is true, the scope needed to identify the difference between 32 bits of entropy and 128 bits is inconvenient. Also, each bit of entropy added doubles the time to confirm (just as each bit doubles the time to break) so my main take from this article is that RNG testers do not do enough tests to confirm half the level of chaos that people are attempting to use.
Oh, you mean like RSA tokens and the seed files? :P
If I were a disgruntled member of the intelligence industrial complex and knew that this was actually being done by a government agency, and I did not relish the thought of a Russian sabbatical, couldn't I surface the news by telling researcher friends of mine how to do it?
I wonder if it's possible for an attacker to mess with microcode in such a way as to trojan things like random number generation, without having any other effects that would be more easily noticed. It doesn't seem likely.
Of course, true RNG depends on things like timing keystrokes, mouse clicks, network packets, etc. The LSBs of such times probably aren't used for anything else, and could thus be tampered with more easily.
It's pretty hard to get reliable crypto when your adversaries are the SIGINT arms of some of the most powerful nations in history; they're not constrained by law, ethics, or budget; and the one in your own nation can coerce cooperation and silence. Bad deal, all around.
Edward Snowden should be canonized.
Linux uses the Ivy Bridge random number generator in the kernel, along with other sources of randomness.
That makes it OK, because as everyone knows, mixing the other sources with a predictable string makes the output even more random!
Didn't Linus completely settle this issue?
Why? Is one necessarily better or worse than the other? Because the Bible said so? Or something else said so?
These parts would not pass the standard verification process and would be rejected from being assembled into devices.
Standard testing of ICs for functional faults includes a scan process. Per the design specification that the part was supposed to buildt a number of scan vectors are passed through the devices. These scan vectors check as much of the device as possible. The goal is to check every flop and every logic path between flops. The tests are to detect manufacturing errors. And can find single faults in devices.
Typical errors are stuck at 1 or stuck at 0, also shorts and would easily expose modifications of this sort, especially of such a scale as to radically change things.
Yes, yes it is.
In security, you're trying to change the behavior of corporate drones, idiots, and people who are invested in the status quo. People use these papers as ammunition for that.
The drones will call your attack "theoretical" and "impractical" unless you spell out exactly how to do it, step by step. If they hadn't detailed exactly how to do it, the attitude would basically have been that nobody could possibly figure out the impossible complexity of weakening a REAL RNG. I mean, look at the self tests! Nobody could get around that! In fact, even people who weren't complete idiots might have guessed, at first glance, that the self tests would be hard to defeat, or that you couldn't do this hack without screwing up the chip.
Even with a detailed paper, they will probably be ignored until somebody actually does it in the field. If you wrote a one-pager that said "Warning! Somebody could alter the behavior of gates by tweaking the dopants", they would 1000 percent ignore it.
As for the verbose background information, it's standard in the field (although they went a bit heavy on it). It has zero cost, and readers in the field who don't need it simply skip it. So I don't know why you're getting so upset about it.
Please don't trash people's work in fields you don't even slightly understand.
I doubt that an altered chip would pass BIST testing.
much of left-wing thought is a kind of playing with fire by people who don't even know that fire is hot - George Orwell
Digital ICs are treated production with scan tests guaranteed to cover around 95 to 99% of possible faults.
Given Hanlon's razor, an accidental, rather than malicious, error in doping would be even more likely. If the chip were inadvertently doped incorrectly, it would pass visual inspections and even software tests without awareness of the defect. How many defective dice, not merely with RNGs but also with other circuits, are already in service due to inspection failures?
Although this paper shows how insidious a threat from a well-funded adversary might be, even more it shows the need for more comprehensive inspection mechanisms to discover misdoping which might go undetected by existing standard procedures.
BTW, the paper includes a well written and readable introduction to the context of the problem. Good job.
Are tinfoil hats on special this week? It's not very likely to happen to anybody who isn't a very big target because to make such a modification have to completely understand your chip design, know how you're going to use it and judge that compromising YOUR chip design is sufficiently valuable to reap rewards.
If you consider very widely used device, there's greater likelihood of being compromised, and it would more likely be done with the cooperation of the chip designers than otherwise, in which case it is probably visible in the regular metal masks, etc. because the only people who have access to the design are complicit. When is the last time you took equipment you bought apart decapped the chips, imaged them with high resolution 3D x-rays or lapped them down layer by layer to examine whether it they had hidden features? Hell, most users never see their BOARDS.
Comment removed based on user account deletion
Then we can buy them from fabs that we trust, and they will have to more explicitly compete on the issue of trust.
There is also some possibility that buyers could inspect the manufacturing processes.
Anomalies in other computational functions are less of a concern, IMHO, because any environment with a mix of CPUs and chipsets should reveal tainted chips at least occassionally. Random number generation is an exception here.
The NIST 800-22 test has bit length parameters. The article doesn't indicate if it passed the 128 bit NIST test after they reduced the entropy to 32 bits, only that it passed *some* NIST test. From another poster it seems the standard NIST parameters used for the NIST test may not be sufficient to test that the prng exhibits the level of entropy that people are relying on it to exhibit. The lavarnd folks pass a billion bit NIST test, so it is possible to run longer versions of the test. If the reduced entropy source is still passing a higher entropy test, we have a problem with our testing method.
Your other (very valid) point is that just because data is random, doesn't mean you are secure. The data stream has to be both random and unknown to your attacker, which PI would not be. In this case they do not have a way to set the seed, or all inputs to the prng, only to limit the prng's bit length, so the attacker will not know the random sequence or even its statistics. It simply makes a brute force attack much less time consuming.
It still concerns me that a 32 bit prng might have passed a 128 bit 800-22 test. Does anyone know more about that aspect of it?
refactor the law, its bloated, confusing and unmaintainable.
This is not my field by a long stretch. After reading the pdf this morning, what I got from the paper was a method to undetectably make relatively easily-done changes to various transistors such that those changes offer an entry point for external reading and possibly manipulation to potentially useful effect within real-world manufacturing methods. Do this, pwn chips. Profit.
What these guys have done strikes me as impressive - and wonderfully, elegantly sneaky. I know there are some design and fab people here - what say you?
Sure, it's obscure, except all our chips are being made in a country that is actively in an electroni
THE PEOPLE'S GLORIOUS REPUBLIC DENIES THESE CLAIMS.
---
ECHELON is a government program to find words like bomb, jihad, plutonium, assassinate, and anarchy.
As a person who has worked in semiconductors since the first SSI 7400 , I can say for certain that many things have been done and there are some really talented people who can do things that -almost- defy reason. I know that engineers put their own little signatures in ASICs and that some engineers are far more competent than can be understood by most. I have seen many circuits that were situationally controlled or externally controlled by means that would not be obvious without an understanding of the physics, electromagnetic conditions, and software. It can even be done at the layout level. Early CMOS was notoriously susceptible to EM induction. I have seen a board that used an unconnected trace to an input pin used as an RC circuit.
The greatest problem that I see in this type of behavior is that it assumes perfect security and there is no such thing. If you put a means to invade or disable systems in all products, you are hurting every individual and business. If you also create a system where people cannot verify your identity as a secret police without committing a crime, you have created a back door in the social engineering realm. If I am party to a security request, I then know what documents, methods and verifications are being used and thus it can be used as a spoof attack on anybody else with little chance of discovery.
I would not be the least bit surprised if it was discovered that IBM, INTEL, Motorola, and others were subjected to this same security theater. The problem with hardware is that once the flaw becomes exposed and if it is bad enough, the entire system must be replaced. It is rational to have different circuitry for military applications, but when it creeps into consumer and business products it is wrong in many ways and though the intent may be for the military to do what it thinks will solve -their- problem, without oversight it becomes paradoxical and if they destroy the means to do business and make profit through their tampering, then it is full circle and the funds and efforts that support the government and military are damaged.
The problem is in oversight, defence must be limited in its scope of action. Isn't this what all the fuss is about with Syria and Iraq? The convential military action is assumed to have overstepped the boundaries into what is consired socially acceptable and this NSA condition is no different. It is a failure in leadership and oversight that offends the sensibilities. Nazi Germany had a very effective military and it would have been a non-issue if they had been guided by people with empathy and reason.
Say what!? Optical inspection at 14 nanometers? Did I miss a memo or something?
You can still generate an arbitrary amount of entropy with a compromised RNG if you know it's compromised. Let's say you have a ridiculously compromised RNG with only 1-bit of entropy and 32-bit output, such an RNG could trivially fail statistical tests, if it used simple combinatorials to mix the nth output with the n-1th output, or it could be almost undetectable, if it uses complex combinatorials, such as the AES method used in the Intel RDRAND. In either case, each word will contain some entropy, even if it is much less than stated "on the box".
Let's say it outputs a 32-bit word (the RDRAND32 instruction does), and each word is supposed to contain 32-bits of entropy (I dunno), but only contains 8-bits of entropy. If I mix 4 words of output to produce an output of 32-bits, I have reliably produced 32-bits of entropy.
The danger here is that a software implementation takes the manufacturers word on the entropy content of the output, since we can't distinguish between genuine entropy and the output of a strong cipher with a hidden state (as is the case in RDRAND), rather than mixing the RNG output down to a smaller number of bits (for example by chain-ciphering N consecutive words of RNG output together to form one word of output).
One potential mitigation to most of these compromised RNG scares is to have the user initialise an S-box or cipher key manually (flip coins, roll dice), and feed all RNG output through a strong cipher in feedback mode. The predictability of the RNG is no longer usable for cryptanalysis as the output of the cipher is not predictable without breaking the cipher and discovering the key. The key can't be discovered by cryptanalysis, because it's only ever used to cipher "random" (though partially compromised) input, and cryptanalysis of users of the RNG is thwarted because there is no longer identifiable correspondence between the RNG output and the random values used. Even if the key for the random post-processing is known, the correspondence between random-system output and RNG output is non-trivial, and there is no way to know the internal state of the ciphers feedback register, as it is constantly accumulating partial entropy from the RNG, which is never revealed.
Most of this doesn't apply to fake RNGs (PRNGs) which have been compromised to generate no entropy after initialisation, as eventually sufficient state will percolate through the cipher to regenerate the seed value and a sliding window attack will recover the offset. Unfortunately a PRNG can be designed to be statistically indistinguishable from an RNG for computationally impractical long runs of output 2**96 bits or longer if the internal state of the PRNG can't be obtained (many existing block ciphers fulfill this requirement).
The descibed attack seems to describe weakening the entropy of the RNG rather than reducing it's entropy to an initial constant, and so while less than ideal, would not compromise a prudently designed random number system.
I've considered this as well (I will be using the NIST random number test suite in the near future). However, what can they accomplish with this? I see two approaches they could have taken: 1. Flag a non-random generator as "random". However, just because I use the NIST test suite does not mean that I don't use any other test suites, that would presumably catch this. This seems high-risk from the NSA's point of view - just one publicly available test that proves NIST is gamed shows their hand. 2. Flag something that is random as "non-random". This gets truly random generators disqualified. However, if my TRNG was disqualified, I would look into why, and that would likely reveal the NSA's hand as well. Are there scenarios that I am missing?
Sometimes I doubt your committment to SparkleMotion!
This can only be used for attacks on things that can be compromised in a way such that they do not need to perform their original function perfectly anymore. A CPRNG is an ideal target, as it does not need to produce good _and_ bad number after the attack, it is sufficient if it produced bad numbers that look good. The AES whitener in the CPRNGs this was demonstrated on make this very easy and while it looks convenient, it may have been inserted in there exactly to make compromised versions of this CPRNG hard to detect. On the other hand, if you attacked, say, a hash function or a block cipher in this way, it would start producing wrong outputs, potentially for a large number of cases and not only would it fail at its original function, this would also be pretty obvious.
Still, this is a significant attack and underlines why a single source of entropy should never be fully trusted and that CPRNGs should always be open software and use multiple entropy sources that get mixed.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
Sabotage would be to make something stop working. The mentioned chips will work just fine, but their RNGs will be predictable. Only the ones who caused it know and will take advantage of it. Looks like a trojan to me.
Yes, I know this. However, this would not require them to compromise the NIST Random number test suite - No reasonalbe test suite would be able to detect this sort of scenario anyway.
So, back to the original question: Is the NIST Random number test suite compromised? What could they gain by doing this?
Sometimes I doubt your committment to SparkleMotion!
Oh, noting requires that the RNG be on-die (and, as you say, there are all kinds of options that aren't, the universe is a very noisy place). However, unless your computer is actually configured to use whatever access to the noise of the universe it has (nasty little webcams are another good source), and dump that entropy in whatever pool(s) your software environment specifies, it doesn't help you much.
The on-die ones are valued mostly because they are really, really, fast and a whole lot cheaper than the earlier generations of purpose-built crypto coprocessors, which were very much priced for a niche market.
If you can't trust them, though, you have options.
Sabotage would be to make something stop working. The mentioned chips will work just fine, but their RNGs will be predictable. Only the ones who caused it know and will take advantage of it. Looks like a trojan to me.
If the RNGs aren't producing numbers as "random" as claimed, then it's not working. It's sabotage.
A trojan horse requires stuffing something malevolent into something you want so you're enticed to bring it in the gates.
If the RNGs aren't producing numbers as "random" as claimed, then it's not working. It's sabotage.
No, it's not. Saboteurs break machines and bring them to a halt. Check the etymology.
Actually, no. Technically speaking, there is no such thing as random data, only a random process.
Actually, there is random data. That is, data generated by a random process.
Unsurprisingly, there are quite a few different tests which can determine, or perhaps "preditct the chance" if some data is produced by a random process i.e. is random, or not. The easiest for a layman is to try to compress it. Random data of sufficient size won't compress with unbelievably huge probability.
(Sorry for screwing the quote ... not the first time ... apparently my brain is a random process)
I'm talking about government surveillance.
Is it better to have open, known surveillance, or secret, unknown, surveillance?
If the RNGs aren't producing numbers as "random" as claimed, then it's not working. It's sabotage.
No, it's not. Saboteurs break machines and bring them to a halt. Check the etymology.
Actually, you should check the etymology. There's no evidence for the old story about people throwing their shoes into the machines.
Even if it was, there's no requirement for there to be a stoppage of production, there's just the requirement of the actors maliciously disrupting the process.
An RNG that doesn't output "random" numbers to spec is BROKEN. Anyone intentionally causing that is engaging in SABOTAGE.
Actually, there is random data. That is, data generated by a random process.
I build 2 boxes
The first produces its data stream by a random process.
The 2nd box, as its process, copies the data from the first box.
Any test that would grade the first data stream as random would grade the 2nd data stream as random.
The 2nd data stream is not random, as the owner of the first box can tell you, in advance, what every output of the 2nd box will be.
This is most stupid semantics argument ive ever read.
Well, there goes the mod I plopped in, but...
1) Intel's high-end chip fabs are in Oregon, Arizona, California... not exactly close to Beijing. (They're still building some rather massive additions to their Ronler Acres fab up here in Oregon).
2) ARM chips, on the other hand (e.g. tablets and smartphone bits)? In that case I hereby petition Slashdot to introduce the "scary as fuck" mod.
Quo usque tandem abutere, Nimbus, patientia nostra?
I doubt they have diagnostic coverage of every single flop in the entire processor.
If the RNGs aren't producing numbers as "random" as claimed, then it's not working.
Unless you have access to the AES key in the RNG chip, the numbers are effectively random. Even if an attacker knows that the numbers only jump around in for example a 32-bit subspace of the N-bit key space, they don't know which subspace, unless they break AES. On the other hand, if you do have the key, as you probably would if you are the one who tampered with the chip, then you're in a whole new position.
I guess that's the "nice" thing about the attack -- only the one who planted it can exploit it. Useful if you for instance want to spy on your countrymen, without at the same time exposing them to a foreign adversary.
Without the ability to verify anything, all trust is destroyed.. Only the mystics will prevail
“He’s not deformed, he’s just drunk!”
It is not a defense against an attacker. It is a defense against manufacturing defects.
It is not news that if you re-wire a circuit, it changes.
I should use this sig to advertise my book ISBN-13 : 978-1501515132.
doomed?
Well, I prefer an over-driven triode, but those are harder to get than they used to be. Nothing wrong with a mic as a source. In fact, many computers come with them built-in. Chop and hash that source a few times, compress it lightly, and fold with an xor and you've got a pretty random signal. The problem comes if you want your random numbers to follow some standardized distribution. And you usually do. Uniform random distribution and Normal random distribution are the ones usually needed, but sometimes Gaussian.
OTOH, if we're talking about something built into the system (like /dev/random) then the fancy manipulation can be handled by someone else. But that someone probably won't be able to depend on a user supplied external source of randomness.
I think we've pushed this "anyone can grow up to be president" thing too far.
I don't believe the authors attacked the Ivy Bridge RNG in the way described. They described a way, they didn't do it.
Why?
1) They show a plot of a DFFR_X1. This is a normal D type flip flop you would find in synopsis libraries and many other libraries you would use in an SoC process. These are not the flops used in the Ivy Bridge DRNG. Also the plot was from a layout program, not a micrograph.
2) The proposed attack required an average of 2.1 billion attacks (fixing k and v until you hit the right CRC). I don't think we sold 2 billion Ivy Bridges to these guys. The alternative they propose is to try it in simulation first. Running 2 billion simulations of full BIST would take a while and they don't have the code. If they had the RTL code they would be proposing other attacks.
3) They don't identify the site of the attack on the chip. They don't know where the site is.
4) They don't show RdRand output of a compromised chip. This would be trivial.
The main message of the article is sound. There are physical attacks that are hard to see optically. But the attack they describe against Ivy Bridge is hypothetical, based on the information in the CRI audit paper here: http://www.cryptography.com/public/pdf/Intel_TRNG_Report_20120312.pdf
I should use this sig to advertise my book ISBN-13 : 978-1501515132.
Trojan dopes YOU!!!
This sig is not paradoxical or ironic.
Some physical processes are random, and hardware random number generators based on them can be constructed. Does this report create a larger market opportunity for manufacturers of this type of device? And, competing such devices can be compared, assayed, validated, and combined, all apart from and much more cheaply than CPUs.
No, it's not. Saboteurs break machines and bring them to a halt. Check the etymology.
How about using the modern definition instead? Sabotage: "the act of destroying or damaging something deliberately so that it does not work correctly"
I mean, the NSA sabotaged an encryption standard, so it seems like this would be similarly sabotaging a batch of CPUs.
Why do you think I don't even understand the field? Everything I've said is accurate, everything they've said is accurate, and all I'm saying is that I don't get what the deal is with writing a big paper about it. You've suggested that it's about socially engineering the PHBs rather than informing academia, which is fair enough... but that's not a "paper" in the way I think of it, then.
Sounds to me like they're sabotaging the security by breaking the underlying mechanism (with a trojan).
Similar to if you were to cut sensors for somebody's alarm without tripping any sensors or backups, etc.
to create a verifiable fast RNG. There may be other parts of the kernel that can be optimized with some HW acceleration.
nosig today
If that cool horse the Greeks gave you destroys your town instead of just sitting there looking pretty then it's not working, it's sabotage. Definitely not a Trojan horse.
Rampant carbon sequestration destroyed the Dinosaurs' tropical paradise. I'm here to help repair the damage.
Are you really claiming, that exactly same data can be mathematically speaking both random and non-random?
I am claiming that the same data can be produced by a random process or a non-random process.
Therefore one cannot merely examine the data to determine if its truly random. One MUST examine the process.
In that case we get to the philosophical question: is there anything "truly" random. No process describable by mathematics certainly is not.
We could but we don't have to.
Box 1 is random to the best of our ability. Sure we can discuss the philisophical question of free will vs determinism and absolute cause and effect, and whether or not something can be truly random.
But we can agree that rigth now, nobody has the faintest idea what's going to come out of box 1 next.
Box 2 isn't random at all. It runs in lock step to box 1. Anyone with access to box 1 knows what's going to come out of box 2.
But we are not talking about history here but about computer engineering and in our world a trojan is not something meant to destroy anything but a means of easing access to a system so that a malevolent user can take control of it without the knowledge of the legitimate user. The etymology is irrelevant and only anecdotal in this case.
The mentioned artefact is called "hardware trojan" by analogy to a software trojan an not because it has anything to do with wooden horses or warriors of the bronze age.
-- 29A the number of the Beast
Yes, I just realized this. A properly written OS can periodically test the hardware RNG for reduced entropy. Let us suppose we can detect if the entropy has fallen below 32 bits. Then, whenever we are using the hardware RNG, we pessimistically assume that there are only 16 bits of entropy available per sample. Grab a bunch, run it through a good hash function, repeat, concatenate. You end up with as many bits of good random data as you need, and you XOR it with the random bits you got from other sources.