This past semester I conducted an extensive literature review on the subjects of trusted computing and anonymous networking. The following summarizes my findings.

Can Trusted Computing Save You from Big Brother?

An Olin Self-Study by DJ Gallagher

Can Trusted Computing save us from Big Brother? The short answer is no, not just yet; but be patient. The state of the art in Trusted Computing is insufficient to keep data confidential against a knowledgeable opponent; for all intents and purposes it is “security through obscurity”, albeit with some of the obscurity moved into hardware, where many users will lack the tools to break it. In the long term, however, by following a rigorous definition of the Trusted Computing Base that echoes United States government security manuals, this technology will continue to improve, eventually making good on its promise of unbreakable confidentiality that anyone can wield. What that will mean in practice depends largely on who steps forward to develop and deploy it.

Introduction:

Trusted Computing (TC) is a new take on an old solution to an even older problem. The problem is mandatory access control–how to render a machine provably incapable of “cheating” on some task even when it has been programmed to do so. Historically, computer hardware has been designed with efficiency (not wasting humans’ time) and generality (being able to perform any calculation for which a method is known), not security, as primary concerns. Security became a part of Operating System design, and even there, generality dictated the existence of an all-powerful user (the administrator or root) capable of pulling all strings and opening all doors. Unless a way could be found to forge protections even the root user cannot bypass, computers would forever be only as trustworthy as the people in charge. Advances in grid computing and a need to remotely store confidential information have made this an undesirable state of things.

Access Control Lists (ACL’s; e.g. Security Enhanced Linux) are the classical solution, but by themselves lack the needed security hardening for cases where an attacker has physical access to the device. As it turns out, such additional protection is impossible to get without considerable support in hardware. Hence, multiple alliances of hardware, software and media companies and research institutions have formed around the goal of making cryptographically enforced access control a standard feature of computing. This is what is meant by Trusted Computing, and has been since the government published TC evaluation criteria in the mid-1980s: the code that is accessing a particular piece of data is trusted to be using it as the owner of that data intended. If it weren’t the right code for the job, it would never have succeeded in deciphering the data.

There is some confusion about what Trusted Computing will mean in practice–confidentiality assurance, enhanced protection against malicious software and remote attacks, a backdoor for after-the-fact court-imposed remote censorship, or the means for content providers to obtain an unethical degree of surveillance and control over their customers’ use of media. Most important, I think, is the technology’s ability to keep diaries private, data service providers honest to their clients, and customer information confidential on corporate servers. That a customer’s machine should take orders from the server, and not the other way around, merely reflects the true interest of those currently driving the development of the technology. I have argued in the past that their efforts will fail–mainly because of the exorbitant server-side processing needed to encipher large media files with a unique key for each customer.

One of the above uses–keeping data service providers honest–has attracted the attention of several people who were otherwise in the anti-TC camp. They want to use Trusted Computing to strengthen their anonymity, using a proper client-server model in which middlemen can be trusted to pass clients’ information along while keeping sender identity a secret.

My initial idea was to create a business plan for establishing a high-speed commercial anonymous network based on TC. Unfortunately, historical literature [6] is clear on the point that commercial anonymous networks fall into disuse unless they offer a compelling advantage at low cost. Moreover, they run dangerously close to being classifiable as an Internet Service Provider, and thus subject to a recent FCC ruling requiring assistance for wiretaps. What I discovered in the process of researching my idea, though, taught me a lot about what’s required to set up a “bulletproof” anonymous network. One has to work from within an existing backbone network–absent a change of heart on behalf of both the Fed and major telecoms, this means moving the work into academia. The technology can still reach users eventually, but only if we as a nation choose to embrace it.

Trusted Computing Base

The Trusted Computing Base is the set of hardware and software components needed to ensure protection of data confidentiality and integrity on a computer without having to trust the owner or administrator. Together they constitute a “root of trust”, a gatekeeper/watchdog entity whose veracity is tied, at time of manufacture, to a cryptographic certificate of authenticity. In theory, the Trusted Computing Base begins with hardware that implements five basic features:

1. Measurement, which tracks the overall configuration of the system including device configuration, operating system and processes. All this information is condensed and stored in such a fashion that it can serve as a credential for what the system is currently capable of.
2. Curtained Memory, in which the hardware blocks attempts to read/write memory that has been marked privileged, except by the process that resides in that memory.
3. Secure Input and Output (I/O), in which data traveling to and from non-disk devices such as video card, keyboard, etc. is protected.
4. Sealed Storage, in which a key specific to a given measurement is generated and used to encrypt data before writing it to the hard disk.
5. Attestation, in which a program on the local machine must “dial home” to the owner of a piece of data and make certain guarantees about the system state to obtain a cryptographic key to that data. This can be done anonymously, in the sense that a proof of authorization can be constructed without naming the particular authorized device; however the device’s Internet address is revealed.

In fact, most of this is still just theory. The Trusted Platform Module (TPM), a hardware component currently working its way into consumer PCs, can handle the work of compiling measurements and creating the keys for sealed storage and attestation; it does nothing to protect data in memory, or while traveling along the wires that connect the TPM, processor, disk, memory and other components. The day nears when Intel’s next generation of processors (with sophisticated memory curtaining and virtualization features) will be available for public scrutiny but, as they do not provide secure memory I/O, it is uncertain what good they will do.

One thing that’s abundantly clear is that the TPM does relatively little good by itself. It can be used to boot a strongly access-controlled operating system, thereby thwarting the memory issues, but the I/O problem remains. An opponent sophisticated enough to measure the wires can defeat this system; that’s a risk certain types of people will and won’t accept, depending on the nature of their imagined opponents. Alternative systems with stronger security guarantees exist, but none has processing power comparable to the combination of a TPM and mainstream processor. With these and future variants, and with sufficiently lightweight code, we may have the basis for an Internet router that provides “pretty good” anonymity, provably.

History of Anonymity

Since the mid 1990s, the erosion of online privacy has been a steadily growing concern among computer professionals. Merely encrypting the contents of messages has not been enough to protect users; traffic analysis and lawsuits [5] are now being used widely to target users’ identities and track their activities. As a result, more volunteers than ever before are involved in the design and operation of sundry anonymous Internet services: Freenet (a distributed censor-resistant storage network), Tor (a network for anonymous real-time Internet traffic) and Mixminion (an anonymous e-mail forwarder) are popular examples.

There is enough redundancy that the deployed networks must compete for users. A few remain on top, in part because, as anonymity researchers like to quip, “anonymity loves company” [3]. A few individuals cannot be very anonymous together, but a network of thousands can achieve significant anonymity. If a network can’t get up to the right size quickly, it probably never will. Another reason for the rich-get-richer pattern in usage is that there are relatively few groups prepared to throw serious dollars and man-hours at the problem, relatively few basic architectures and algorithms to choose from, and plenty of time for the winners to absorb ideas from the losers in their category.

Here’s (an approximation of) how anonymizing networks function. Suppose Steve Jobs wants to anonymously send a prank letter to Bill Gates. Both are fairly well-connected in the world of IT, and for our purposes we assume their friends are similarly connected and have no particular interest in spying on them, nor in keeping secrets for them.

Steve prepares the following stamped envelopes, each one slightly smaller than the last:

FROM Steve Jobs / Apple Computer, Inc. / Cupertino, CA
TO Scott McNealy / Sun Microsystems, Inc. / Santa Clara, CA

FROM Scott McNealy / Sun Microsystems, Inc. / Santa Clara, CA USA
TO Linus Torvalds / Helsinki University / Helsinki, Finland

FROM Linus Torvalds / Helsinki University / Helsinki, Finland
TO Bill Gates / Microsoft Corporation / Redmond, WA USA

In the letter marked to Bill he deposits his prank message. He then puts each envelope inside the next larger one, and drops the biggest envelope into the mail. McNealy soon receives it, opens it, finds the envelope to Linus Torvalds, shrugs, and drops it back in the mail. Linus forwards his letter with similar ambivalence. At the end of this chain of events, Bill Gates in Redmond is fairly miffed. He rings up Linus and demands an explanation for the letter. Linus shrugs, and maybe is able to recall receiving an envelope within an envelope from McNealy. But McNealy, who for whatever reason is frequently being used as a vehicle for such practical jokes, can’t remember whose letter he sent to Linus; the number of possible suspects balloons; and the investigation grinds to a halt.

While this is a drastic oversimplification, the general points hold. In reality, the parcels are more like lightweight safes than envelopes, the intermediaries each possess a unique key and are all volunteering to forward mail, and senders are able to choose any path through the interconnected web of friends. In a more complex variation, return paths can also be provided by enclosing another set of different-sized envelopes along with the payload. But in all cases, the degree of anonymity is determined by 1) the number of friends involved, 2) the evenness of traffic and 3) the percentage of friends who can be trusted to be naive/forgetful.

Uneven traffic propagates statistically traceable anomalies in the number and size of envelopes passing through various points in a network. Too few friends results in a limited number of suspects, making it rather easy to sniff out the guilty party. Finally, not all the friends will be trustworthy; some may be working together with Bill to deduce the culprit by sharing their records of sent and received mail. As long as one friend in the chain of letters is forgetful, this is okay, but the odds of choosing a safe pathway decrease as the proportion of spies increases.

Of these three factors, the easiest one to improve is the number of friends passing letters, which is why in networks like Tor the clients are encouraged to double as servers. Similarly authentication and access control may help improve the degree of trust; it is the evenness of traffic that’s the real sticking point.

The reason for this is an enemy with enough resources could spy on the incoming and outgoing mail of all the friends simultaneously (Hepting v. AT&T and ACLU v. NSA changed a lot of minds regarding the likelihood of such a feat). And it’s not economical to be sending empty envelopes at all times just to prevent correlation attacks. Some anonymous networks discount this, and hope that the wide spread of network nodes will make it impossible; others use rigid timing schemes to impose evenness on their traffic, at the cost of long delay times and severely limited bandwidth.

A much better option is to build anonymous routing features directly into a network. Network engineers call such features traffic flow security. At the physical layer, a modem could be designed to insert random noise into the gaps between actual traffic, and then encrypt the whole mess to obscure where in the continuous stream of 1s and 0s the actual messages lie [1]. At a higher level, variants on an existing technology called Internet Protocol Security (IPsec) allow for less stringent traffic flow security that is sufficient if all routers are friendly (as cannot be assumed when links traverse the Internet) [2]. However, most anonymous networks don’t use IPsec, they use encryption that is still further removed from the physical hardware, and so gives even less direct control over timing.

Anonymity–How Much Do I Need?

An important part of any problem in information security is the threat model. For example, Trusted Computing assumes a very simple threat model for data access. Anyone who is not the owner, or an authorized agent of the owner, of a piece of data, or whose system is not configured securely, is a threat; the root of trust will respond accordingly. For anonymous networking the answer is not so clear. There are many kinds of adversaries with many kinds of capabilities, but they can generally be lumped into the following four categories for general-purpose Internet traffic:

• A local adversary, tapping the Local Area Network for outgoing transactions, can be thwarted by the use of a secure Internet proxy–a remote server that receives a client–s Internet traffic over an encrypted connection, and then forwards the unencrypted messages to their destinations.
• An adversary spying through one or more Internet Service Providers (either surreptitiously or through the use of legal coercion), or able to hack into the proxy server, requires either a more distant/secure proxy, or the use of a standard-issue anonymizing network, to render the connection too hard to trace.
• An adversary with near-unlimited ability to spy on the Internet, as is often ascribed to the information ministries of some nations, requires a network more sturdily built than any of the existing ones. This is probably doable using IPsec traffic shaping. Some crypto geeks also ascribe to the above agencies an ability to break IPsec encryption, but there is no evidence for that. On the other hand, an adversary who can spy on the Internet wholesale is also likely to be…
• An adversary who will craftily insert a large number of moles into an anonymizing network, in what is known as the Sybil attack. The moles then collaborate to destroy anonymity throughout the network. At this point, there are only two options: switch to a network in which only trusted acquaintances communicate (a friend-to-friend network), or construct a hardware basis for trust. The latter forms the impetus for combining Trusted Computing (to thwart moles) with efficient physical-layer encryption (to thwart external spies) in a single network technology.

OpenTrustNet: Anonymity the Hard Way

OpenTrustNet is a model for a fast, scalable, private Wide Area Network with strongly assured anonymity. It was developed after considering the state of the art and making some assumptions about future advances. It is a killer app for Trusted Computing: routing traffic in much the same way as the public Internet, it allows application-specific optimizations for commonplace uses (the Web, BitTorrent, e-mail, etc.) while preventing surveillance and traffic analysis. Here’s how it works:

It is built out of dedicated fiber-optic lines and specialized routers that encrypt data in regular chunks of 1s and 0s, just before they are converted to on-off pulses of laser light and sent careening across the network. Proper encryption of messages, and insertion of random noise into the spaces between, makes it impossible for an eavesdropper to determine the network’s true usage patterns. Maintaining the illusion of constant use has important consequences for total energy dissipation; however at this time the slowness of encrypting and decrypting data is a more likely limiting factor for network speed than the capacity of the laser transceivers.

At network startup, each pair of linked routers will establish an unsecured channel, which they use to exchange their public keys. This is the same thing as Linus and Steve trading unlocked safes to which they own the respective keys. They use this rather inefficient mode of communication only long enough to mathematically prove their identities, attest that they are running the right software, and pick a shared private key. With that done, they can terminate the public key channel and start a faster one using the shared key.

The code measurements of trusted router software are prominently displayed on the web, along with public keys to access the network gateways and source code for the recommended client software. Clients demand an attestation as part of establishing a secure path into the network. As a result, routers are privileged with such sensitive information as endpoint addresses and request headers, eliminating the need for indirect routing and allowing for built-in web caching and distributed file storage.

Interface with the public Internet is carefully regulated, as it will always expose some potential vulnerabilities. Where such an exchange exists, the local administrator is able to collect usage statistics and make selective refusals of service (to block spam, for instance), but can neither identify the origins of messages coming from the network nor decipher the contents of messages directed into the network.

Law enforcement would in all likelihood eventually try to compromise the confidentiality of the system, as it would (like any convenient and secure medium) attract some criminal activity. However, OpenTrustNet has no server logs; the routing tables are encrypted; the distributed filesystem is encrypted; and they cannot impersonate a valid router unless they succeed in violating the physical integrity of the Trusted Platform Module in ways no materials scientist has yet succeeded in doing–and secretly, under the nose of OpenTrustNet facilities surveillance.

So What Really Happens?

Regrettably, OpenTrustNet is subject to the drawbacks mentioned in the introduction. There are subtler ones too–particularly in creating the root of trust. As Ken Thompson famously demonstrated [7], trusting a man-made system without trusting its creator is a chicken-and-egg problem, and so it is with manufacturers’ authenticity keys. If leaked, they would allow untrusted devices to emulate trusted ones.

In the end, there are many reasons why the imagined bonanza of file-sharers, political bloggers, federal and corporate agents, whistleblowers, and other persons browsing discreetly was simply not to be. Among the most important is that an Internet already exists, and to build another one right next to it would be universally seen as a waste. Research networks abound, yes, but they’re for development purposes. And Hollywood has already made it abundantly clear, in a recent wave of lawsuits against students of Internet2 consortium schools, that they are listening even on supposedly private networks, anywhere someone might antagonize them.

The fight appears lost; but really it’s not as simple as that.

When faced with the threat of exposure, anonymity first turns inward. Though impractical for general-purpose use, friend-to-friend network models are gaining in popularity; they are well suited to file-sharing, collaborative editing and message exchange. The current generation of anonymizing networks will similarly continue to remain popular for the discreet browsing and mailing needs of some, though moderate in strength and too slow to support the exchange of anything larger than compressed images. And on the ample fibers of National LambdaRail- and Internet2-run networks, the stage is set for even more interesting things to begin trickling down to the masses.

Current-generation Trusted Computing hardware, while it should not be taken as secure, is a sufficient proof-of-concept that it may be used to evaluate a new breed of secure routers. For simplicity’s sake, they will probably begin with existing implementations of IPsec traffic-shaping, on top of which protocols for authentication and attestation can be layered. Implementations of physical-layer traffic flow confidentiality over wired interfaces (e.g. serial, Cat6 Ethernet) between programmable logic devices will probably come next, and if that works out well, eventual fabrication of the entire router on a silicon chip may not be far off. There’s very little question whether someone would be able to find a use for the technology.

Adoption for public use is a hairier question. Academic networks are under unusually high scrutiny as a result of the I2Hub file-sharing lawsuits; as a result it will be difficult for their directors to make such services available to anyone not explicitly authorized to do research. But there is nothing to stop the router hardware itself from proliferating, and it may see scattered use in Local Area Networks where the operator is particularly zealous or security conscious. Privacy activists would probably be within their rights to string Ethernet cables between adjacent homes. The list of possibilities runs on.

Further into the future, however, there may be some chafing at the bit for an opportunity to make the technology more widespread for greater good (or ill, as it were; the technology supports either). To do that, it is necessary to either clean house in Washington or set up a home base for the technology outside this country. It would not be the first or last time such a data haven was proposed by the security conscious; IT professionals and other would-be early adapters will be skeptical, unless they have trust in the people as well as the machines.

Conclusion

In answer to the skepticism of the relative many, the fears of the few and the general confusion of the larger public, I would simply add that there is only one way I’d want to run a trusted network–with informed participation of all sides. Anything less is prone to falling apart, either from a lack of cohesive oversight within or from aggression without. Matthew Barrett [4] pointed out that trust in Trusted Computing is worthless if it comes from a point source, be that hackers or police or politicians or businessmen or priests. To be accepted by all, it must be governed by a coalition whose best interest is in keeping the technology neutral. Right now that may be impossible, but times will change.

And this is something I’d like to see for more reasons than just privacy. There is an inherent elegance to open-ended infrastructural support for Trusted Computing, and what it enables–electronic voting that you can really believe; massive parallel computer banks on deserted isles, folding virtual proteins for researchers as they watch comfortably from their offices across the globe; third-party compilers that certifiably migrate Trusted code from one system to another, saving users the trouble; an Internet in which code truly is law, and the niceties of the legal system of this and other countries need never be invoked; and yes, a world in which we could once again dance like nobody’s watching.

Works Cited

White Papers

1. Raju Ramaswamy: “Traffic Flow Confidentiality Security Service in OSI Computer Network Architecture”. Proceedings of IEEE TELCON 1990. http://ieeexplore.ieee.org/iel5/498/3989/00152690.pdf
2. Simone Teofili et al: “Traffic Flow Security Enhancements in IPsec: Design and Preliminary Implementation”. Poster presentation, 2006 IEEE International Conference on Network Protocols. http://www.ieee-icnp.org/2006/posters/icnp06-posters-teofili.pdf
3. Roger Dingledine and Nick Matheson: “Anonymity Loves Company: Usability and the Network Effect”. Proceedings of WEIS 2006. http://freehaven.net/doc/wupss04/usability.pdf
4. Matthew Frederick Barrett: Towards an Open Trusted Computing Framework. Master of Science Thesis, Department of Computer Science, University of Auckland. http://www.cs.auckland.ac.nz/~cthombor/Students/mbarrett/mbarrettThesis.htm
5. Peter Biddle et al for Microsoft Corporation: “The Darknet and the Future of Content Distribution.” Proceedings of the 2002 ACM Workshop on Digital Rights Management. http://msl1.mit.edu/ESD10/docs/darknet5.pdf
6. Ian Goldberg: “Privacy-enhancing technologies for the Internet, II: 5 years later”. Proceedings of the 2002 PET Workshop. http://freehaven.net/anonbib/papers/petfive.pdf
7. Kenneth Thompson: “Reflections on Trusting Trust”. ACM Turing Award speech, printed in Communication of the ACM, Vol. 27, No. 8, August 1984, pp. 761-763. http://www.acm.org/classics/sep95/

Relevant Open Source Projects

Tor: http://tor.eff.org/
Tor is one of the most widely studied real-time anonymous networks. It is used to host hidden and/or firewalled web services, and as a general Internet proxy. Tor was initiated by the US Navy and is currently managed by the Free Haven Project.

The Freenet Project: http://freenetproject.org/
Freenet (not related to Free Haven) is a storage network using distributed hash tables designed to allow high-availability anonymous entry and retrieval of documents over the Internet, in defense of free speech. Ian Clarke is its creator.

TrouSerS & Trusted Java: http://trousers.sourceforge.net/, http://trustedjava.sourceforge.net/
TSS and the Trusted Java API are a general-purpose, open-source reference implementation of the trusted software stack by OpenTC consortium.