I guess I don't see why this is worth a PhD; has nobody ever bothered to verify whether checking the binary against the results of a trusted compiler works? Did this guy contribute some measure of rigor that was previously missing?
Intuitively, let's say I write a very early version of a (say) gcc, but insert code so that if the compiler detects that it's compiling a login program, it inserts logic into the binary so that "kt" can always login without a password. For this to survive beyond the next rebuild, the compiler also has to detect when it's compiling itself and insert the same logic. This 'Trojan horse' can survive as long as people keep compiling your compiler in itself, but is never detectable from looking at any later version of the source code.
So you need to trust each version of the compiler (assembler, linker, microcode) you are using all the way back in history. The claim of the PhD and the 2005 paper is that you can verify the integrity of a compiler using another compiler that you do trust, all the way back in history.
The apocryphal story is that Ken Thompson actually did this with an early Unix compiler. Here's his very short original paper:
Right. I'm wondering how this was sufficiently non-obvious to warrant a PhD dissertation.
From a security perspective, this is different from a compromised (say) Debian mirror because it's not a question of, "does this binary match the source I downloaded from?" but, rather, "does this binary do the right thing when I use it to compile my system?"
Think of it this way: you and a friend both compile GCC. But the native code which results is not necessarily the same - it depends on details of your machine and your existing compiler tools. So there is no way to say what "the binary for GCC 4.4.x on i686" should look like, so you cannot tell if your friend modified his compiler's source code just before compiling it. This is (sort of) the problem the paper is solving.
I am not an expert, but I hope this is clearer.