This entry from my colleague Bill Worley is cross posted from Paths2Trust.
This first in a series of posts on Paths2Trust is timely given the recent New York Times story about SSL encryption certificate authorities - an issue Dan Kaminsky of Recursion Ventures has emphasized many times (see "Experts Warn of a Weak Link in the Security of Web Sites"). A chain of trust - like any chain - is only as strong as its weakest link. Unless we look at all elements of Internet security, we will never be secure.
Dan Kaminsky's excellent 28 July 2010 presentation at the Las Vegas Black Hat Conference introduced the concept of a Domain Key Infrastructure (DKI), based upon the DNSSEC chain of trust. He emphasized the crucial importance of DNSSEC for the security of the Internet and outlined the significant progress in its deployment to date. He then proceeded to elaborate innovations, leveraging the scalable DNSSEC chain of trust, that could lead to secure solutions to a broader class of pervasive but presently unsolved problems - such as generic secure email and scalable end-to-end authentication.
It is great to see these creative ideas for strengthening the security of the Internet being pursued and discussed. Establishing and leveraging chains of trust is a fundamental architectural element of the design of secure systems, and building upon the scalable DNSSEC chain of trust promises important opportunities for strengthening the trustworthiness of the Internet.
We must understand, though, that fully achieving the desired levels of Internet trustworthiness eventually also will require complementary chains of trust in participating system components. These will be required, at more fundamental system levels, to ensure the integrity of executable firmware and software on each hardware platform that provides functionality needed for an overall problem solution. Just as a chain of trust is only as strong as its weakest link, the trustworthiness of an overall problem solution is only as good as the trustworthiness of its weakest system component.
If we consider, for example, participating authoritative or caching DNSSEC servers, it is imperative that the integrity of the executing firmware and software on each server platform be ensured. It is essential to know exactly what firmware and software is present and able to execute on each server. It also is essential to guarantee that neither the firmware nor the software can be, nor has been, contaminated or hijacked by attack malware introduced through some other system software or hardware vulnerability. Otherwise, attack malware could compromise the DNSSEC software in order to return poisoned responses rather than correct ones.
Establishing software chains of trust requires consideration of how source code is managed by an engineering organization, how software modules are structured for delivery to a hardware platform, how software modules are transported to a target hardware platform, how software is stored on disk drives, how it is loaded into the hardware platform, and how it is structured and protected by hardware once loaded into the platform memory. Each of these areas is challenging in and of itself. Each will be discussed in future blogs, showing how it is possible to establish these essential software chains of trust.
Bill
Comments