Trusted Computing Serving an Anonymity Service Alexander Böttcher Bernhard Kauer Hermann Härtig Technische Universität Dresden Department of Computer Science Operating Systems Group {boettcher, kauer, haertig}@os.inf.tu-dresden.de Abstract [15] in the authors’ group, will show. An unknown crim- inal to be investigated was supposed to use an anonymity We leveraged trusted computing technology to service. The police and later on the German Federal Bu- counteract certain insider attacks. Furthermore, we reau of Criminal Investigation (FBCI) required to investi- show with one of the rare server based scenarios that gate a criminal that uses a known URL. In order to enable an anonymity service can profit from trusted comput- criminal prosecution by a given warrant the software was ing. We based our design on the Nizza Architecture extended to log connection data [6, 5]. This function of [14] with its small kernel and minimal multi-server the anonymity software [3] was used only with a warrant OS. We even avoided Nizza’s legacy container and but without directly notifying the users. After the warrant got a much smaller, robust and hopefully more secure was reversed the FBCI showed up with a delivery warrant system, since we believe that minimizing the trusted for a log record (which were later on reversed illegal [4]), computing base is an essential requirement for trust first at the institute and later on at the institute’s directors into software. private home. This incident shows a whole class of attacks on the 1 Introduction anonymity and more general every computing service. Vendor and providers under constraint can reveal the ser- Anonymity while using the Internet is widely considered vice because of insider knowledge and physical access a legitimate and - for many use cases - essential require- to those services. Besides reasons like corruption or hu- ment. A use case encompasses protection of privacy by man social engineering, also external influence such as avoiding traces and by preventing to reveal unnecessary extortion can cause attacks, which under normal situa- private information. On the other hand, the Internet can tions would never happen. be considered a least anonymous technology in wide use. Until now changes undermining the anonymity can- Traces are left while visiting web sites on various levels, not be detected by users relying on the service. Within e.g. connection data on the network level and cookies this paper we investigate how technical solutions can pro- as well as personal data on the application level. To en- vide users of the anonymity service with additional in- able network anonymity, anonymity services have been formation about the used software. On the one hand we devised [8, 11]. They obscure the real source address of a use trusted computing technology to verify the anonymity user by routing lot of users over one or more proxies. software stack and on the other hand we target on strong However, these anonymity services can be compro- decomposition and minimizing the trusted computing mised as the following scenario, based on a real incident base in order to minimize attack points and make trust- Part of this work has been sponsored by the European Research ing the software itself justifiable. The work in this paper Council in the OpenTC and Robin project and by Intel. aims at the server side of the anonymity service and ex- 1 cludes investigation at the client side. This would be a After a user has chosen a cascade, JAP connects to the topic of research on its own. first mix and establishes a channel. It uses a public key The paper is structured as follows. In section 2 we de- of the first mix to negotiate a symmetric key for encryp- scribe the anonymity service and give a short introduc- tion of data. The first mix then establishes a connection to tion into trusted computing. In section 3 we look into the next mix and the JAP client also negotiates a symmet- related work, followed by the design and implementation ric key by using the public key of the second mix. This is of the extended anonymity service in section 4. In section done for all mixes until the last mix. After this setup phase 5 we evaluate the achieved protection against insider at- a JAP client has symmetric keys negotiated with all mixes tacks and the size of the trusted computing base. The last of the selected cascade. The user’s web browser forwards section proposes future work and concludes. requests locally to JAP which encrypts the data multiple times, first with the symmetric key of the last mix, then with the symmetric key of the mix before the last mix and 2 Overview so on. Finally JAP sends the encrypted packet to the first mix of the cascade. The first mix decrypts received pack- 2.1 Anonymizer service ets and forwards them together with packets of other users to the next mix. Every mix of the cascade decrypts with We use the anonymizer service AN.ON [1] which is based the negotiated symmetric keys the received packets and on David Chaum’s mix networks [8]. The general idea is forwards them to the next mix. The last mix obtains after to provide anonymous communication within a network decryption the original web browser request and sends it by transferring and by recoding messages over several in- to the Internet. Relaying and encrypting replies of the In- termediate network nodes called mixes instead of directly ternet to users in the backward direction is done similarly transferring data from the source to the destination. By but in the inverse order. using mix network technologies senders, receivers or both Currently the trust into a mix cascade can be based only sides are able to stay anonymous from each other. Mixes on two things: a written statement of the mix providers, are message mediators similar to proxies, however mixes declaring the intent to do not log any data, and certificates take care that received messages cannot be linked to mes- of the public keys. The later ones are used to avoid man- sages they send forward. Basic methods to achieve this is in-the-middle attacks. to collect messages, to recode the message and to send the message in a different order than they were received. 2.2 Trusted Computing AN.ON, an anonymizer service developed at the Ger- man universities of Regensburg and of TU Dresden, is Trusted Computing [20, 12] is a technology that gives us used by thousands of users today. Figure 1 shows the two mechanisms that are useful for our scenario: Remote general high level structure of the service, which con- Attestation and Sealed Memory. sists of Java based clients called JAP, C++ based mixes, Remote Attestation allows a third party to verify which JAP based InfoServices and cache proxies. Single mix software stack (e.g. BIOS, Bootloader, OS, Applications) nodes are formed to a mix cascade and one mix serves one is running on a remote computer. and only one cascade. InfoServices provide information Sealed Memory allows to seal secrets to a particular about currently available cascades and provide meta infor- software stack, thus preventing the disclosure of private mation about the current number of users and data traffic data from another - potentially untrusted - software stack workload of cascades. All information are visualized by running later on the same machine. JAP clients, where users can select a mix cascade. Web Although other ways were discussed in the literature browsers of users are configured to use JAP as proxies, [13, 17, 7], trusted computing based on a Trusted Plat- however JAP does not only forward messages like typical form Module (TPM) is now widely accepted and TPMs proxies do. JAP encrypts and decrypts all requests and are deployed in the millions. The TPM, as defined by the responses according to the mix protocol, which will be Trusted Computing Group [25], is a smartcard-like low- described in detail below. performance cryptographic coprocessor, that is soldered 2 InfoService JAP Internet User A Proxy JAP User B Mix 1 Mix 2 Mix 3 … Proxy bidirectional TCP/IP-connection JAP User XYZ Figure 1: High level overview of AN.ON (figure source: AN.ON Projekt home page at http://anon.inf.tu-dresden.de) on the motherboard. trusted computing functionality. In addition to cryptographic operations such as signing Another Linux based solution is ProxOS [24] which and hashing, a TPM can store a chain of hashes of the splits the operating system on the system-call level. boot sequence. Using a challenge-response protocol, this System-calls can be redirected to various Linux instances chain of hashes can be signed by the TPM and verified by responsible for appropriate tasks. Within this solution a remote entity. Similarly it can be used to seal data to a multiple specialized and stripped down Linux kernels can particular, not necessarily the currently running, software be used to serve an application. configuration. Unsealing the data is then only possible when this configuration was started. We decided not to use a monolithic operating system A TPM based system has a couple of limitiations. approach for our scenario because of different reasons. The well known cryptographical limits (RSA assumption, First, solutions based on a big monolithic system, for ex- SHA1 collision resistance) will not be targeted in this pa- ample on Linux, will not achieve such a small trusted per. Instead we have to keep in mind that the trusted com- computing base as a decomposed approach promises. puting specification explicitly excluded hardware attacks Second, monolithic systems make it hard to protect and [16].