On trusting software

10Jun10

Reaction to Ken Thompson’s Reflection on Trusting Trust

In his lecture, Thompson basically asked whether there is a software which can be fully trusted. One would usually be quick to answer that one cannot trust a software is free of malicious code, unless he/she wrote the source code himself/herself. But thinking deeper, one would be able to look at the bigger picture, and notice that the source code is not sufficient on its own to create the binary, because it needs a compiler. So then the question goes down to the trustworthiness of the compiler, recursively until the lowest layer of the software architecture, and even further down to the hardware. Essentially, if we would follow the condition that the only software we can trust is our own, then any software we use, as well as the underlying software and hardware platform it runs on, should be something we did ourselves. Which, I couldn’t resist adding, is just insane.

So, any software, even the one you write, cannot be fully trusted, because it depends on other tools that you didn’t write yourself. But it can be trusted to some degree, more so than you trust other programs you did not write yourself. You might believe a code you wrote is more trustworthy than someone else’s, inherently because you wouldn’t intentionally harm your own system, but later you might find out that it is less secure because of a bug you failed to see. Trust on a software, as my previous sentence illustrates, is more based on trust on the author/s. This extends to the tools. Equally important to a reviewed source code of the tools used is whether the authors are known to implement good methodology and have good reputation. This line of questioning extends further down then adds up until one arrives at a decision whether Software A is likely to be more dependable than Software B.

Reputation can be built by tests and certifications. For example, there are tests and certifications of processes and devices on compliance/conformity to standards specified by trusted bodies like ISO, IEEE, etc. Certification, the way I see it, becomes some sort of “association” to these reputable bodies, as though the trustworthiness “rubbed onto” the brand or product. This could lead to associations or alliances of companies with products that are certified. In wireless LAN, for example, there is the Wi-Fi Alliance, with member companies that commit to interoperability among their products. The same is true for software. For one, there is the Trusted Computing Group, which promotes Trusted Computing technology. But does this imply software developed by member companies of the Trusted Computing Group are fool-proof and can be completely trusted?

Apparently not. As Diomidis Spinellis pointed out in his paper “Reflections on Trusting Trust Revisited” with Xbox as a case in point. Reputation worked for the other bodies I mentioned, but not for TCG, at least for me. The difference probably lies in the fact that usually, certifications are done to guarantee that a product has met a certain functionality. Security is a far, far more complex and completely different property. The way I see it, perfect software security is an impossible dream, so a fully-trustworthy software will never exist, simply because there is always somebody smarter than you (if you are the designer) out there. Still, like I said, there are degrees of trustworthiness — Software A may be a tougher nut to crack than Software B — but to be fully certain that a software is impenetrable? Nah.

Advertisement

Filed under: Security, Software   |  Leave a Comment