3 ms·

There's a practical (for some value of practical) defense against this attack: "Countering Trusting Trust through Diverse Double Compiling." It's fairly clever.

There's a practical (for some value of practical) defense against this attack: "Countering Trusting Trust through Diverse Double Compiling." It's fairly clever. http://arxiv.org/pdf/1004.5548 http://arxiv.org/pdf/1004.5548 If I recall correctly, here it is in short: 1) Invent a new virtual machine ISA. 2) Write a trusted compiler that targets that ISA. It is totally OK if this compiler is crap as long as it is correct. 3) Build the original compiler with the new compiler. The result is a cross compiler, running on your new VM-ISA and targeting your host architecture (e.g., x86). 4) Build the original compiler again with the output of step 3. The result is an x86-hosted compiler targeting x86. The abstract seems to imply the last step: 5) Diff the output of step 4 with the untrusted compiler. The author, David A. Wheeler, apparently expanded on this paper for his 2009 dissertation: http://www.dwheeler.com/trusting-trust/ http://www.dwheeler.com/trusting-trust/

runningdogx 15y ago
What about trusted hardware? Without that, your somewhat trusted compiler cannot be trusted, even if it's something like tcc whose code you might realistically be able to formally verify by yourself. There are at least two approaches, but neither are really satisfactory... first, using an electron microscope and validating the finished design gate by gate. That won't work if the software and hardware toolchain used to generate the gate design is compromised. So you'd have to validate the gates without the help of the software toolchain used for design and layout. I suppose you could also attempt to validate silicon (sans microcode) by attaching a clever external apparatus and external clock source and current meter (which you trust?), and timing every single instruction that hits the processor, validating the time it takes for the instruction to return results and the power consumed, and comparing that against the design specs. That suffers from the same general problem though: unless you're deriving timing and power consumption from basic principles, the tools used to generate expected timings and power consumption could have been compromised. For processors with few gates, though, it could work. The worst situations are where the malware is so subtle -- one changed gate or instruction for instance, with a specific application in mind that can be subverted through that change -- or where from an external POV the malware is non-deterministic, for instance if a processor randomly and rarely injects malware into a running system, using a hardware rng for randomness, on average once every million years of cpu time. Would chip makers be able to detect those sorts of attacks if they tried?
- pornel 15y ago
  > What about trusted hardware? Anonymously buy commodity hardware from randomly selected source. For added security, you could buy second set from other vendors and compare results from the two. This way you should be safe, unless whole world conspires against you.
  - bch 15y ago
    > This way you should be safe, unless whole world conspires against you. That may be an egocentric way to look at being a victim. Perhaps the target of the malicious hardware is the whole world, and you were just caught in the net.

runningdogx 15y ago

What about trusted hardware? Without that, your somewhat trusted compiler cannot be trusted, even if it's something like tcc whose code you might realistically be able to formally verify by yourself. There are at least two approaches, but neither are really satisfactory... first, using an electron microscope and validating the finished design gate by gate. That won't work if the software and hardware toolchain used to generate the gate design is compromised. So you'd have to validate the gates without the help of the software toolchain used for design and layout. I suppose you could also attempt to validate silicon (sans microcode) by attaching a clever external apparatus and external clock source and current meter (which you trust?), and timing every single instruction that hits the processor, validating the time it takes for the instruction to return results and the power consumed, and comparing that against the design specs. That suffers from the same general problem though: unless you're deriving timing and power consumption from basic principles, the tools used to generate expected timings and power consumption could have been compromised. For processors with few gates, though, it could work. The worst situations are where the malware is so subtle -- one changed gate or instruction for instance, with a specific application in mind that can be subverted through that change -- or where from an external POV the malware is non-deterministic, for instance if a processor randomly and rarely injects malware into a running system, using a hardware rng for randomness, on average once every million years of cpu time. Would chip makers be able to detect those sorts of attacks if they tried?

pornel 15y ago
> What about trusted hardware? Anonymously buy commodity hardware from randomly selected source. For added security, you could buy second set from other vendors and compare results from the two. This way you should be safe, unless whole world conspires against you.
- bch 15y ago
  > This way you should be safe, unless whole world conspires against you. That may be an egocentric way to look at being a victim. Perhaps the target of the malicious hardware is the whole world, and you were just caught in the net.