Criminal IT: Should you trust the internet?

COMMENT In his debut silicon.com column, Criminal IT, Neil Barrett examines whether internet users can rely on a system built on so many unknowns.

Do you trust the internet? It's a silly, meaningless question: of course you trust the internet, under certain circumstances; and under other circumstances, of course you do not - or at least, you should not.

The internet can be relied upon to route data between any two connected computers, finding its way automatically around any failed or damaged elements; that was, after all, what it was designed to achieve. Unfortunately, that is all it can be relied upon to manage. It provides no intrinsic guarantees of confidentiality, either of the existence or the contents of transmitted packets of data; and equally it provides no intrinsic guarantees of the transactional integrity of the messages it transmits.

There is no guarantee of delivery time, for example, simply what might be thought of as 'best effort' delivery for those messages which might form streaming media or voice over IP traffic - and for every other form of data, from email to web pages, the packets all simply have to take their chance.

You can't trust the internet to preserve confidentiality, you can't trust it to ensure integrity - other than the internal, checksum integrity of individual messages - and you have only the lowest level of assurances about availability, since the internet comes with no 'quality of service' rating.

This means that, in fairness, you shouldn't really trust the internet - any more than you would trust, say, notices pinned on a public board somewhere. But of course, the internet isn't the element being trusted in activities such as ecommerce; instead, it is the medium over which the trustworthy services are being delivered. It is the medium that supports SSL, secure email and reliable credit card processing; it is the medium which provides access to web servers, electronic mail and the reliable delivery of voice and data traffic. It is these services which we should be deciding whether or not to trust - along with the computers, or rather the operating systems and applications, which communicate over the internet's wires and radio frequencies.

So can you trust those things? That is after all the most fundamental question for information security: can you and should you trust that the confidentiality, integrity and availability of information will be maintained by those components which claim to do precisely that? Should you trust products such as encryption, firewalls and the security components intrinsic to operating systems?

Perhaps the most insightful comment on the issues of trusting services is now nearly 21 years old, devised by one of the founding fathers of the Unix operating system, Ken Thompson. Called Reflections On Trusting Trust, it was the acceptance speech delivered by Thompson when he collected an ACM award in 1984. Published in the August 1984 Communications of the ACM, it paints a scary picture of how much we should not trust components about which we have no knowledge.

Thompson's speech described the way in which it would have been possible for the creators of Unix - Thompson and Dennis Ritchie - to have modified the login program so as to allow them unconstrained access to every Unix machine - and incidentally to every computer derived from their first operating systems. A simple modification to the login program would allow a default password to have been used whenever the program encountered Ritchie's or Thompson's login names: instead of checking the passwords in the standard 'passwd' file, the program would have instead used a built-in password. Ritchie and Thompson would have been able to log in to any computer.

Of course, a simple check of the source code of the login program would have shown the rogue lines of C, containing the check and the default password to apply. Thompson's trick would have been busted the first time anyone was curious to examine the source, which was distributed along with the operating system in the halcyon, innocent days of the early 1980s. To avoid this problem, though, Thompson said they would also have modified the C compiler. If the compiler detected it was compiling the source code for the login program, it would automatically include the Trojan code to allow them access; the lines didn't have to appear in the login program because they would be automatically included there by the compiler.

The problem then shifts, however, to the compiler: an examination of the compiler source code would have shown the rogue lines of code to create the login Trojan. To avoid this, Thompson also proposed that the C compiler include its own Trojan. The C compiler is itself written in C - in developing new programming languages, it is common for the compiler to be written so that it can compile itself, the ultimate test of the compiler and of the complexity of the language. Thompson proposed that their first compiler could have been modified to include a Trojan which detected whether or not the compiler was in fact compiling a C compiler. If it was, the Trojan would include the modifications to allow it to infect the login program.

Follow the logic of this. Every C compiler written in C needs to be compiled by a C compiler. The first C compiler was infected with the Trojan, so every version of the operating system compiled with that first compiler would be infected. If anyone created an alternative C compiler, again written in C, they would have to compile it - and would therefore have to use that first compiler. Because of this, the alternative compiler would be infected, as would then any further operating system compiled using this alternative.

If Thompson had indeed produced the Trojan, avoiding its effects would have been enormously hard work. Fortunately, neither he nor Ritchie actually introduced the Trojan which he described but it does illuminate the dependencies which trust places on a wide variety of 'invisible' components, such as the compiler and the standard libraries.

To fully trust any component, you would need to know how it was produced - not merely at the level of the source code but for the entire development and production. The so-called 'A1' secure systems feature comprehensive checks on the design, development, compilation, deliver, roll-out and operation of the trusted component but these are as rare as chicken teeth. For most of us, we have to make do with systems which are, at best, only C2-rated systems in which some minimal security function is provided but not guaranteed.

So again, ask yourself quite how much you trust the internet, a system built on invisible, unknown components, performing unknown functions in an unknown manner... still happy to shop, bank and flirt online?