Technische Universit¨atDarmstadt Department of Computer Science Prof. Dr. Michael Waidner

Virtual Private Networks for Peer-to-Peer Infrastructures

Diploma Thesis

Submitted by Hiro Dudani

on 2012-11-30

Supervisor: Dipl.-Inform. Nicolai Kuntze

In cooperation with: Fraunhofer SIT f¨urPapa

ii Ehrenw¨ortlicheErkl¨arung(Affidavit)

Hiermit versichere ich, die vorliegende Diplomarbeit ohne Hilfe Dritter und nur mit den angegebenen Quellen und Hilfsmitteln angefertigt zu haben. Alle Stellen, die aus den Quellen entnommen wurden, sind als solche kenntlich gemacht worden. Diese Arbeit hat in gleicher oder ¨ahnlicher Form noch keiner Pr¨ufungsbeh¨ordevorgelegen.

Hiro Dudani Neu-Isenburg, am 29.11.2012

iii Abstract

The Nanodatacenters project aims to complement the paradigm of existing centralized server farms with a high number of small storage and communication devices located at the edges of the network. Utilizing previously unused resources like broadband internet access bandwith and idling set-top boxes, these nodes are able to host applications from different content providers offering various kinds of services, such as Video on Demand or online gaming, to end users. This setting does pose particular security challenges. As the devices operate under physical control of the end users, their integrity has be ensured and must be able to be verified by the network. This is achieved through the functionality of Trusted Com- puting. Additionally, the domains of the different content providers have to be isolated in such a way that an attacker cannot use one of them as a foothold to compromise or snoop on the operation of the network or another isolated domain. Another important requirement for datacenters are secure and reliable communica- tions. As the set-top boxes are connected to the internet, cryptography has to be used to make sure that the confidentiality and integrity of transmitted data as well as endpoint authenticity are maintained and no content is delivered to rogue devices. This thesis analyses the properties required for the secure connection of nodes in such a network of livingroom datacenters and introduces a concept for a Virtual Private Network able to fulfill these requirements. Contents

Abstract iv

1 Introduction1 1.1 Nanodatacenters...... 1 1.2 Use Case: Decentralized Video-on-Demand...... 2 1.3 Outline...... 2

2 Related Work and Existing Technologies4 2.1 Trusted Computing...... 4 2.1.1 Protected Capabilities...... 4 2.1.2 Integrity Measurement...... 5 2.1.3 Integrity Reporting...... 5 2.1.4 Problems...... 6 2.2 BitTorrent...... 7 2.3 Virtual Private Networks...... 9 2.3.1 IPsec...... 9 2.3.2 L2TP...... 11 2.3.3 SSL/TLS...... 12 2.4 Convergence...... 15 2.4.1 Trusted Computing and VPNs...... 15 2.4.2 Trusted Computing and Peer-to-Peer...... 15 2.4.3 Peer-to-Peer VPNs...... 17 2.4.4 Peer-to-Peer VPNs using Trusted Computing...... 18

3 Concept 21 3.1 Requirements...... 21 3.1.1 Node Authenticity and Integrity...... 21 3.1.2 Secure Communications...... 21 3.1.3 Customer Isolation...... 21 3.1.4 Encouragement of network-edge connections...... 22 3.1.5 Performance...... 22 3.1.6 Low Maintenance...... 22 3.1.7 Scalability...... 23 3.2 Design Decisions...... 23 3.3 Protocol entities...... 25 3.3.1 Slice...... 25 3.3.2 Node...... 26

v Contents

3.3.3 Privacy CA...... 27 3.3.4 Attestation Ticketing Service...... 27 3.3.5 Tracker...... 28 3.3.6 Region...... 28 3.3.7 Wire...... 28 3.4 Protocol Flow...... 29 3.4.1 AIK Certification...... 29 3.4.2 Attestation and Tracker Ticket Retrieval...... 31 3.4.3 Tracker Ticket...... 33 3.4.4 Tracker Registration...... 35 3.4.5 Querying the Tracker...... 37 3.4.6 Peer Ticket...... 40 3.4.7 Connecting Slices...... 41 3.4.8 Transferring Data...... 43 3.4.9 Deregistration from Tracker...... 45 3.5 Scalability Enhancement...... 46 3.5.1 AIK Certification...... 49 3.5.2 Tracker Ticket...... 49 3.5.3 Slice Registration...... 49 3.5.4 Tracker Query...... 49

4 Implementation details 51 4.1 Data Types...... 51 4.2 Entity Identifiers...... 52 4.3 Algorithm Identifiers...... 54 4.3.1 Encryption...... 55 4.3.2 Integrity and Authenticity Protection...... 56 4.4 Changes...... 57 4.5 Protocol Flow...... 59 4.5.1 AIK Certification...... 60 4.5.2 Attestation and Tracker Ticket Retrieval...... 62 4.5.3 Tracker Ticket...... 63 4.5.4 Tracker Registration...... 65 4.5.5 Querying the Tracker...... 66 4.5.6 Peer Ticket...... 67 4.5.7 Connecting Slices...... 67 4.5.8 Transferring Data...... 69 4.5.9 Deregistration from Tracker...... 70

5 Analysis 71 5.1 Security...... 71 5.2 Performance...... 73 5.3 Privacy...... 74

vi Contents

6 Conclusion and Outlook 76

List of ProtocolsI

List of TablesII

BibliographyIII

vii 1 Introduction

When internet access first became available to home users, the protocols they used (e.g. Gopher, IRC1, HTTP and FTP, SMTP for sending and POP for receiving mail) followed the client/server paradigm. Only after broadband access technologies such as DSL, where the users were not usually billed by online time, had become widespread did Peer-to-Peer [132] (P2P) protocols emerge. Most of the first P2P applications were file sharing programs, even to the point that “peer-to-peer” became synomymous with “file sharing”, and most of the files shared contained unauthorized copies of copyrighted songs and movies. This software became so popular that soon peer-to-peer traffic constituted the largest part of the traffic handled by ISPs at all times of the day [54], taxing the scaling limits of their routing equipment. After this peak however, and probably due to increasing legal persecution of the users of such platforms, this ratio dropped significantly in later years [78]. Together with the short median duration of online sessions, this means that most of the bandwith provided by broadband internet connections lies dormant today. On the other side, the constantly increasing speeds of access technologies place in- creasing demands on the servers delivering content in terms of network bandwidth and processing power. This means they have to be placed in large datacenters located at central points of the internet and housing high numbers of high-performance machines, creating high power densities that in turn cause high costs for energy distribution and cooling [20]. One approach to mitigate some of the problems created by such centrally-located high- performance servers are Content Distribution Networks (CDN) [98]. Instead of serving all users from one central site, CDNs distribute several replica servers across the internet, closer to the network edge, and attempt to route user requests to the replica server that is topologically closest to the requestor. This helps reduce traffic cost and improve access latency. However, as the servers of a CDN are again placed in datacenters, this approach cannot significantly reduce the power and cooling problems raised by these.

1.1 Nanodatacenters

The Nanodatacenters (NaDa) project2 [82–86] takes the CDN concept to the extreme by utilizing peer-to-peer technology. Its nodes –acting as both servers and clients– are low-

1Although it could be argued that the Direct Client-to-Client (DCC) [112] sub-protocol of IRC, offering chat and file transfer, was really the first peer-to-peer protocol widely used by dial-up users. 2http://www.nanodatacenters.eu

1 1 Introduction powered set-top boxes (STBs) located at the extreme edge of the network: in end users’ homes. There, these ISP-provided and ISP-controlled boxes act as residential home gateways or routers. They are also connected to the users’ TV or home entertainment sets, providing access to the services offered by NaDa content providers, such as IPTV, Video on Demand or Online Gaming. Towards the ISP, the content providers are Customers paying for the possibility to offer their services through the NaDa network. Each customer’s software runs in a separate virtual machine called a Slice, isolated from the slices of all other customers and from the NaDa Node Management module controlling the operation of the node. A slice’s communication with slices on other nodes, e.g. to retrieve requested content, is also isolated by restricting connections to be established only with slices of the same customer, and the confidentiality, integrity and authenticity of the communication are protected against attackers. All information regarding the operation of the network, such as number and placement of nodes, network and node performance, placement and resource usage of slices and of course the data transferred between slices and nodes, are considered sensitive business information that must be protected from end users, (other) customers and outside ad- versaries such as competing ISPs. As the nodes are placed under physical control of the end user, their integrity and authenticity need special protection. The mechanisms provided by Trusted Computing are used to this end; modifications of the node can be detected by integrity measurement and its unmodified state proven to other hosts using remote attestation. The goal of this thesis is the design of a Virtual Private Network that allows communi- cation between NaDa nodes and slices while providing the described security properties.

1.2 Use Case: Decentralized Video-on-Demand

An end user wishing to view a movie selects the slice of the content provider offering the desired film on his STB and requests playback to be started. Transparently to the user, the network verifies the authenticity and integrity of the node, then authorizes it to connect to other peers already in possession of at least parts of the requested content. These are download to the node’s own local storage using an encrypted channel. While the transfer is still in progress, playback already starts as quickly as possible to provide the user with a high quality of experience. As soon as the first part of the movie file has arrived, the node also starts sharing it with other authorized peers looking for the same content. After the user has finished watching the film, the file remains stored on the node and continues to be provided to peers until it is evicted because disk space is needed for new content requested by the user.

1.3 Outline

In the following, chapter2 introduces the building blocks used for the design developed in this thesis and lists existing implementations and research on the road to trusted

2 1 Introduction peer-to-peer virtual private networks. Chapter3 investigates the requirements for the VPN to be designed and based on these develops a concept of the required entities and their interactions. This is then extended to accomodate large scale deployments, before chapter4 gives implementation- level specifications. Some interesting and problematic aspects of the design are highlighted in chapter5 and finally, chapter6 concludes and lists some possibilities for further research and development on the concept.

3 2 Related Work and Existing Technologies

Three building blocks form the basis of the concept to be designed: Trusted Computing will be employed to ensure the integrity and authenticity of the nodes, the structure of the BitTorrent Peer-to-Peer network facilitates direct connections between them, and a Virtual Private Network provides confidentiality, integrity and authenticity for these connections. This chapter introduces the mentioned technologies and describes pertinent work in these areas.

2.1 Trusted Computing

While the idea of trusted systems can be traced back into the 1960s [106], today the term Trusted Computing refers to the architecture defined by the Trusted Computing Group1 (TCG; formerly the Trusted Computing Platform Alliance, TCPA)[143], in which a trusted platform is equipped with a security chip called the Trusted Platform Module (TPM) [144–146]. Access to the TPM is facilitated by the TCG Software Stack (TSS) [142], an API that also provides those functions of the TCG architecture that do not require direct use of the TPM.

2.1.1 Protected Capabilities The TPM provides shielded storage locations which can only be accessed using special commands called Protected Capabilies, ensuring that their contents cannot be modified or disclosed without proper authorization, if at all. Among these shielded locations are non-volatile key slots which can contain cryptographic keys, authentication information or even other kinds of data. Before deployment, each TPM is imprinted with an asymmetric key pair called the Endorsement Key (EK). The EK cannot be changed once it is installed and thus makes its TPM uniquely recognizable and thus, by extension, the platform it is embedded in. For this reason, its permissible use is restricted to establishing ownership of the TPM and certification of Attestation Identity Keys (see below). With the exception of the EK, key storage on the TPM is organized hierarchically. The base of this tree is formed by the Storage Root Key (SRK), which is generated anew whenever ownership of the TPM is changed. Keys may be stored below the SRK in a tree structure, such that loading a key into the TPM requires knowledge of the authorization data for its parent key.

1http://www.trustedcomputinggroup.com

4 2 Related Work and Existing Technologies

As storage space on the TPM is limited, all keys with the exception of EK and SRK can be exported to external storage. Keys marked migratable can then be loaded into any TPM, provided the neccessary authorization data is known, while non-migratable keys can only be loaded and used on the TPM that generated them. Other protected functions of the TPM include a secure Random Number Generator and a Key Generation Module. An onboard RSA Engine facilitates cryptographic oper- ations including signatures on data and keys and Binding, the encryption of data using a key belonging to a TPM. Hardware functions for the generation of SHA-1 hashes and HMAC message authentication codes are also provided.

2.1.2 Integrity Measurement In order to ascertain whether a platform is currently in a trustworthy state, its entire history since bootup has to be taken into account. In the TCG architecture, this is achieved by taking an integrity measurement of each component before it is executed. This chain of transitive trust begins at the Root of Trust for Measurement (RTM), which, being the first component that executes after power-up, cannot be measured by any other component and therefore has to be trusted implicitly. In a PC architecture, the RTM will usually be the BIOS start block, which measures the main BIOS before passing control to it. The BIOS in turn measures and extension ROMs, possibly also other hardware components. The chain is continued with the boot loader, the operating system (which also measures drivers and configuration files) and, finally, any applications as they are loaded. To reliably document all states the platform has been in since it was booted, the TPM possesses a set of 160 bit wide Platform Configuration Registers (PCRs). These shielded registers are zeroed upon TPM initialization and cannot be written to directly but only modified through the TPM Extend command. This operation modifies a PCR by concatenating its old value and the integrity measurement to be added and writing the hash of this concatenation back to the PCR. The PCRs are used in conjunction with the Stored Measurement Log (SML), a list of all components measured together with their hash value with which the respective PCR was extended. As the PCRs are shielded locations within the TPM, their values serve as a kind of signature of the SML; its integrity can be verified by calculating the expected PCR values from the SML and comparing them to the actual ones. One application of this mechanism is Sealing: Data encrypted to a private key held in a TPM can be bound to a certain system state represented by its PCR values. The TPM will only decrypt these data if its current PCR values match the prescribed ones.

2.1.3 Integrity Reporting If the current system state needs to be proven to a remote verifier, Remote Attestation (RA) is used. The idea behind RA is to sign the current PCR values with a non- migratable key and present them and the SML to the verifier, so that the TPM vouches

5 2 Related Work and Existing Technologies for the integrity of the SML. However, doing this using a key permanently embedded in the TPM would allow the verifier to ascertain the identity of this TPM and by extension possibly that of the platform, compromising the privacy of its user. Therefore, remote attestation is performed using Attestation Identity Keys (AIKs), which cannot be directly linked to the TPM using them. Instead, a trusted third party, the Privacy Certificate Authority (Privacy CA or PCA), vouches for the AIK belonging to a compliant TPM. The number of AIKs used by a single TPM is not limited. When a PCA is to certify an AIK, it receives an encrypted identity request pack- age. Aside from the public part of the AIK key pair, this package includes three special certificates, the Conformance, Platform and Endorsement Credentials [148]. The Con- formance and Platform Credentials certify that the TPM and the system it is installed in conform to TCG specifications, while the Endorsement Credential is the certificate of the Endorsement Key and confims that the EK is indeed embedded in a conformant TPM. The PCA verifies these credentials and generates an Attestation Identity Credential in the form of a certificate for the AIK. This certificate confirms that the AIK is a non-migratable key residing in a certified TPM, but does not disclose the identity of that TPM. The Attestation Identity Credential is then returned to the requesting TPM, encrypted using the public part of its Endorsement Key pair retrieved from the Endorse- ment Credential. Once an Attestation Identity Credential for a TPM has been obtained in this way, it can be used to prove the state of the platform to a remote challenger. This attestation process starts with the challenger sending a list of requested PCR values and a nonce to the trusted platform. The TPM creates a signature over the current values of the requested PCRs and the nonce with an AIK using the TPM Quote operation, which is then returned to the challenger, together with the PCR values themselves and the SML of the platform. The challenger can now verify the integrity of the returned SML using the signed PCR values, then compare the SML entries against the expected values from its Reference Integrity Metrics (RIM) database. It will deem the platform trustworthy if all its SML entries possess identical RIM counterparts.

2.1.4 Problems Trusted Computing has been the topic of much controversy [4, 42, 52, 91, 115, 129] on the question of whether it will give more control to the user or the hardware and software manufacturers, allow much more secure –and thus consumer-unfriendly– im- plementations of Digital Rights Management (DRM) systems for media and software, allow “fairer” DRM schemes [114] or even aid “pirates” in defending file sharing net- works against the entertainment industry [120]. The position of the TCG [147] on this point is ambiguous, saying that implementations “should support established principles and practices of data ownership”, but also stating that “data ownership practices vary by geography”. It has further been shown that TPM functionality can be exploited by malware authors

6 2 Related Work and Existing Technologies

[31]. By implementing TPM-protected cloaked computations, parts of their software could be hidden, hindering analysis by security experts. The security of the Remote Attestation process has also been the target of criticism. It has been found that the basic RA protocol is not sufficiently protected against Man- in-the-Middle attacks, enabling an attack called Masquerading [136], a version of what is also called the “mafia fraud” [2]. In a Masquerading attack, the attacker forwards attestation requests originally destined for a platform in an untrusted state (e.g. using modified software) to another, unmodified platform and returns its signed PCR values and SML in the same way. The challenger would not be able to distinguish this attack from a normal protocol run and could thus be led to trust the modified platform. Another problem, albeit not one presenting a security vulnerability, is the possible diversity in software installed on a home user’s PC. This would require a very, possibly prohibitively, large RIM database [18, 71] and would probably still exclude bona-fide users running unusual software or owning rare hardware components. Other successful attacks have physically targeted the TPM itself. It has been found possible to the reset the TPM chip in a running PC [64]; as this also resets all PCR values, this attack breaks the integrity measurement mechanism by allowing an attacker to recreate “good” PCR values using the SML of a clean system. A physical attack with even further-reaching consequences has been presented by Christopher Tarnovsky [138] who managed to open the package of (“decapsulate”) a TPM, bypass its tamper protection and extract key data including the private part of the Endorsement Key, which, representing the identity of the platform, is not meant to leave the TPM under any circumstances.

2.2 BitTorrent

BitTorrent2 [21,22,61] ist a peer-to-peer file sharing protocol optimized for the distribu- tion large files. By the classification system used in [36], it is a centralized peer-to-peer network; however, it does differ from others of this kind by building a separate network (or “swarm”) for each file that is being shared. Every file being shared using the BitTorrent protocol is described by a metainfo (or “.torrent”, this being the usual filename extension) file, giving the URL of the tracker responsible for the file, the file’s (suggested) name, and a list of pieces (segments of the file, usually 256 KiB long) with their SHA-1 hash values. The tracker acts as a lookup server, allowing peers interested in (downloaders or “leeches”) or sharing (“seeders”3) a certain file find each other. When a peer wants to download a file (of which it learns by the BitTorrent client software being provided with the corresponding .torrent file), it contacts the responsible tracker and receives a list of 50 peers belonging to the swarm currently sharing that file. The tracker also adds that

2http://www.bittorrent.org 3While all peers share those pieces of a file that they already have, a seeder is defined as a peer offering all pieces of a file.

7 2 Related Work and Existing Technologies peer to its view of this swarm, so other interested peers may receive its IP address and port when they query the tracker. Originally, connections to the tracker were made using TCP. However, this creates a high overhead on the tracker as the TCP/IP stack of its operating system needs to keep track of the state of each TCP connection made. To reduce the load on the trackers, an alternative tracker protocol based on UDP has been proposed [150]. A peer concurrently connects with 20 to 40 other peers and transfers files in the form of pieces using the BitTorrent peer wire protocol. As soon as a peer has received a complete piece and verified its integrity using the hash value from the .torrent file, it offers that piece to other interested peers it is connected to. As the peers select the piece to be downloaded next using a “rarest-first” algorithm, i.e. they request the piece that the fewest of their connected peers already possess, the file is quickly replicated throughout the swarm. Obviously, the tracker presents a single point of failure: If the tracker given in the .torrent file is no longer available4, no new peers will be able to join the swarm. Peers that are already transferring the file will be able to continue, but as they shut down or leave the swarm, it will gradually die out. In an attempt to mitigate this problem, an extension to the protocol was proposed [57] which allows the .torrent file to contain information on more than one tracker. While this provides redundancy, the proposal does not make any provision for synchronizing swarm data between the trackers, and thus may lead to the formation of several unconnected swarms for one torrent, reducing efficiency. Another attempt to solve the reliance on trackers are “trackerless torrents” [77], a protocol extension which turns BitTorrent into a structured peer-to-peer network [36] through the use of a distributed hash table (DHT). Instead of listing one or more trackers, the .torrent file for a trackerless torrent gives the IP address and port number of one or more peers that already are part of the DHT. Peers that were originally introduced by a tracker can also use this protocol to discover more members of the swarm. Since BitTorrent accounts for a high percentage of internet traffic [78], ISPs are in- terested in ways to alleviate load on their networks from this source. While some have resorted to blocking or throttling recognized peer-to-peer traffic [109], other approaches have also been researched [99]. One of these is the facilitation of network-topology aware peer selection, usually through the ISP providing distance information or optimized peer lists to peers. In the context of NaDa research, “trusted BitTorrent” [72] has been developed, a variant of BitTorrent that uses Trusted Computing to ensure the integrity and allow exclusion of manipulated and malicious peers. This development is aimed at making BitTorrent usable and attractive as a means of distributing commercial content.

4For example due to legal action by copyright holders of media illegally shared using that tracker [55].

8 2 Related Work and Existing Technologies

2.3 Virtual Private Networks

A Virtual Private Network (VPN) [37,40,41] is a network infrastructure that allows the components of a private network to communicate securely over a public network such as the internet, while in their view still using their own exclusive network. This includes retaining a private address space for the participants as well as providing confidentiality, integrity and authenticity protection against attackers from the public network for the data transferred inside the VPN. Usually, VPNs are used either to connect several sites or to allow mobile users (“road warriors”) to access their employer’s central network. Three of the most prevalent technologies for the implementation of VPNs are described in this section.

2.3.1 IPsec As its name suggests, IPsec [68] is designed to secure network traffic at the Internet Protocol layer by providing access control, data integrity, data origin authentication, data confidentiality, replay protection and limited traffic flow confidentiality. To this end, IPsec provides two different traffic security protocols, Authentication Header (AH )[66] and Encapsulating Security Payload (ESP)[67], which can be applied by end hosts or by security gateways along the routing path. The Authentication Header provides integrity and authentication for both the payload and the immutable or predictable parts of the header of an IP packet, as well as optional replay protection, by adding a sequence number and an integrity check value (ICV ), which may be either a message authentication code (MAC) or an RSA signature [151], to each packet. Encapsulating Security Payload supports the same security services, with the excep- tion that header data stored outside the ESP is not protected, and can add payload confidentiality and limited traffic flow confidentiality (TFC ). This is achieved by (op- tionally) padding and encrypting the payload and adding any necessary cryptographic synchronization data (such as an initialization vector (IV)). As with AH, a sequence number and an ICV are also added. Both AH and ESP can be used in either Transport Mode or Tunnel Mode. In transport mode, the AH or ESP is placed between the IP header of an IP packet and its payload, leaving the header otherwise unchanged. In tunnel mode on the other hand, a new IP packet with its own (“outer”) header is created, with the entire original packet being encapsulated in this outer packet and located after or inside the IPsec header as the payload. This mode allows the use of different address spaces for the inner and outer header and even the mixing of IP versions 4 and 6. Most VPNs use ESP in tunnel mode, encapsulated in UDP [60] to facilitate traversing any network address translation (NAT). A Security Association (SA) describes a unidirectional logical connection between two IPsec peers. It includes the protocol to be used (ESP or AH), cryptographic algorithms,

9 2 Related Work and Existing Technologies keys and other parameters as well as the source and destination IP addresses and ports of the traffic the protection is to be applied to (traffic selectors). To allow bidirectional communication, SAs are usually created and deleted as pairs. The Security Parameters Index (SPI ) is a number assigned to each SA and transmitted with each IPsec protected packet to allow the receiver to look up the SA it belongs to. While manual configuration and keying of SAs is possible for static setups, automated peer-to-peer mutual authentication, SA and key management for IPsec are handled by the Internet Key Exchange (IKE) protocol [38, 65]. IKE extends the SA concept to its own control channel, which accordingly is called an IKE SA and, like IPsec ESP SAs, uses a total of four keys for encryption and ICV calculation in both directions. Between two peers, an arbitrary number of IKE SAs can exist, with each of them managing one or more AH or ESP SAs, called its child SAs. Communication on an IKE SA is structured using the concept of an exchange consist- ing of two messages, with the sender of the request message for that specific exchange called initiator, and the peer replying to the initiator’s request named responder. Creation of an IKE SA and its first child SA normally requires two exchanges. In the first exchange, the peers transmit nonces, agree on a suite of cryptographic algorithms and create a shared secret using a Diffie-Hellman-Merkle key exchange [27]. This “key seed” is then used to derive the four keys for the IKE SA, with encryption and ICV protection applied to all following exchanges, as well as a new seed value that can be used to construct keys for child SAs. The following second exchange establishes the identities of the peers through the ex- change of certificates (or certificate chains) and signed authenticators and also transmits the traffic selectors and other parameters required for creating the first child SA, whose keys are derived from the new key seed, with additional entropy provided by the nonces from the first exchange. The authenticators in this exchange also provide integrity pro- tection for the messages from the first one. Creation of additional child SAs is achieved in a single exchange that establishes new nonces, the traffic selectors and parameters and optionally also contains a new Diffie- Hellman-Merkle handshake to achieve forward secrecy by adding the created shared secret to the key seed for the new SA. Rekeying of an expiring SA is done by creating a new one with the same traffic selectors while indicating the SA that is to be rekeyed. This also applies to IKE SAs, which inherit the existing child SAs of their predecessor. For environments where a Kerberos [37, 92] infrastructure can act as a trusted third party (TTP), Kerberized Internet Negotiation of Keys (KINK )[116, 139] was created as a protocol for mutual authentication and management of SAs. Here, the session key provided to both peers (acting as client and application server from the Kerberos perspective) by the key distribution center (KDC) can be used as a shared secret, avoid- ing the need to use computationally expensive public-key operations for key agreement and authentication. KINK also moves policy decisions from the individual node to a centralized infrastructure which can be administered more easily and thus avoids incon- sistencies.

10 2 Related Work and Existing Technologies

2.3.2 L2TP The Layer Two Tunneling Protocol (L2TP) [141] was developed from the earlier Layer Two Forwarding Protocol (L2F) [149] by Cisco5 and Point-to-Point Tunneling Protocol (PPTP) [51] by Microsoft. Its original use is the tunnelling of Point-to-Point Protocol (PPP) [125] frames to and from a remote system connected via a PSTN dial-up line between the L2TP Access Concentrator (LAC) to which the remote system is connected and the L2TP Network Server (LNS) for which those frames are actually destined. However, the protocol also allows for LAC Clients which do not use dial-up lines, but are directly connected to the internet and speak the L2TP protocol natively. Towards an LNS, such an LAC Client acts as an LAC on its own behalf and communicates using a virtual PPP connection tunnelled to the LNS. An L2TP Tunnel, of which there may exist one or more between an LAC and an LNS, consists of one Control Channel and one or more L2TP Sessions. Each Session represents one call established between a remote system and the LAC, allowing a tunnelled PPP connection between the remote system and the LNS. The control channel is reliable in that it provides guaranteed delivery and ordering using a sequence number based TCP-like mechanism that also emulates the slow start and congestion avoidance features of TCP. The control messages sent over that channel are constructed as a series of Attribute Value Pairs (AVPs), consisting of an attribute number and the value assigned to that attribute. The data channel may also use sequence numbers, but only to detect packet loss and provide ordering for the encapsulated PPP frames carried over the tunnel. At the LNS, these frames are processed as if they had been received on a local PPP interface. Security between LAC and LNS is mainly based on a shared secret that may be used for a CHAP [126] style authentication and limited confidentiality for control messages through AVPs with “hidden” (encrypted) values. The LAC may also perform LCP proxy authentication of the PPP connection to the remote host on behalf of the LNS. Beyond the initial authentication however, no integrity or authenticity protection for the control or data channels is supported. The same applies to confidentiality, which is only provided for “hidden” AVP values in control messages. If further security services are required, such as encryption of data messages, an additional mechanism must be em- ployed. This can either be done at or above the layer of the encapsulated PPP connection (e.g. by using the PPP Encryption Control Protocol (ECP) [80] or the Microsoft Point- to-Point Encryption Protocol (MPPE) [95]) or at a layer carrying the L2TP messages, which can provide much more comprehensive protection, but only on the leg between the LAC and the LNS. The latter approach is often taken by securing L2TP using IPsec (L2TP/IPsec) as described in [97]. It works by applying ESP in transport or tunnel mode to the UDP/IP datagrams carrying L2TP control and data messages. This provides authentication, integrity and replay protection for control messages, integrity and replay protection for data messages, and optionally confidentiality for both. Additionally, key management

5Actually, L2F is treated as protocol version 1 of L2TP.

11 2 Related Work and Existing Technologies is also provided by IPsec mechanisms, such as IKE or KINK. Apart from organizational and detail changes, version 3 of L2TP [74] adds support for tunnelled layer 2 protocols other than PPP. In can also be carried directly over IP, in addition to UDP, which was used in version 2 and is still preferred where NAT traversal capabilites are required. Both transport modes can be secured by IPsec.

2.3.3 SSL/TLS The Transport Layer Security (TLS) [26] protocol is the IETF-standardized successor to Netscape’s Secure Sockets Layer (SSL) [43] originally intended to provide security to HTTP connections [37]. Today, TLS is employed in combination with a number of Internet protocols to ensure confidentiality and integrity of transmitted data as well as the authenticity of one or both endpoints. TLS consists of two layers. The lower layer is formed by the TLS Record Protocol, which provides encryption, integrity protection, compression, ordering and fragmenta- tion of transferred data and is used atop a reliable transport protocol such as TCP. This is done by splitting or possibly joining messages from an upper-layer protocol, option- ally compressing the data, applying a message authentication code (MAC) containing a sequence number and then encrypting data and MAC. When a new TLS connection is created, the encryption, integrity protection and compression algorithms are set to null, i.e. the transmitted messages are unprotected until the initial handshake has been completed. Above the record layer, the TLS standard defines the Handshake, ChangeCipherSpec, Alert and Application Data protocols; more can be added through the negotiation of TLS extensions. Since all upper layer protocols utilize the record layer for transmission, their messages are subject to the security services it provides as soon as security parameters have been negotiated. The Handshake Protocol is responsible for authentication and the negotiation and establishment of algorithms and keys used by the record protocol through the exchange of several messages. The handshake is initiated by the client6 sending a ClientHello message containing the highest TLS version supported, a timestamp and a nonce, lists of CipherSuites (combinations of authentication, encryption and integrity protection algorithms) and compression algorithms it is prepared to use, and optionally a session identifier and one or more TLS extensions. The server replies with a sequence of messages, beginning with ServerHello. It contains the protocol version, cipher suite, compression method, session identifier and extensions the server wishes to use, as well as an own timestamp and nonce. If the server wishes to authenticate to the client, this is followed by a Certificate message present- ing the server’s certificate chain. If the server did not send a certificate or if the certificate sent does not allow encryption, the ServerKeyExchange message is sent next. It con-

6Note that in a peer-to-peer scenario, the client is defined simply as the host that initiates the connection and the server as the one that accepts it. The roles are not symmetric however.

12 2 Related Work and Existing Technologies tains cryptographic information allowing client and server to establish a common shared secret, usually the server’s public parameters for a Diffie-Hellman-Merkle key exchange. This information is signed if the server provided a signing certificate in the previous message. The next optional message is the CertificateRequest indicating that the server wishes to authenticate the client. Finally, an otherwise empty ServerHelloDone message indicates the end of this sequence. If the server has requested the client to authenticate itself, the first reply message is a Certificate message containing the clients’s certificate chain. Next, the initial shared secret (called the premaster secret as the actual master secret is calculated from it and the exchanged nonces) is established with the ClientKeyExchange message. It contains either the premaster secret randomly generated by the client and encrypted with the server’s public key, or the client’s public Diffie-Hellman-Merkle parameters, unless they were already transmitted as part of the client’s certificate. If the client presented a certificate that allows signing, the Client Key Exchange is followed by a CertificateVerify message containing a signature over all messages exchanged in the handshake so far. The client then indicates that it will now start using the negotiated security parameters by sending the ChangeCipherSpec message, which actually is not part of the Handshake protocol but the only message type in the protocol of the same name. The security parameters consist of the negotiated algorithms and the respective keys (separate for both directions) derived from the common master secret calculated in turn from the established premaster secret and the nonces exchanged in the client and server Hello messages. The first protected message sent is also the client’s final message in the handshake: Finished contains a keyed hash over the master secret and all messages exchanged in the handshake so far. This allows the receiver to verify that the messages have not been tampered with by an attacker acting as man in the middle (MitM). The handshake is then completed with the server sending its own ChangeCipherSpec and Finished messages, after which both sides are using the negotiated security param- eters and are assured that the integrity and authenticity of the exchanged messages was not compromised. The handshake can be repeated during a connection to negotiate new cryptographic parameters; this can be initiated by the client by sending a new ClientHello or by the server with the HelloRequest message. In both cases, the peer can go ahead with the renegotiation or choose to keep the current parameters. A security flaw was found in the original specification for this process – as the content of the rehandshake messages was not in any way bound to the previous connection state, an attacker could prefix a new connection with his own data, then splice the connection attempt from the client into this connection, making it seem like a renegotiation to the server. This attack can be prevented by adding information from the previous handshake to the rehandshake messages [108]. To reduce the amount of bandwidth and computational effort required to establish a new connection, TLS supports the notion of Sessions. While every connection be-

13 2 Related Work and Existing Technologies longs to exactly one session, each session may contain one or more connections. A new connection becomes part of an existing session if the ClientHello message contains a non-empty SessionID referring to a pre-existing session between the two hosts and the server accepts the resumption of this session by replying with the same SessionID in its ServerHello instead of assigning a new one. In the resumption case, both hosts then skip the next handshake messages handling authentication and establishment of a new premaster secret and proceed directly to the ChangeCipherSpec and Finished messages. The master secret for the new connection is calculated from the session’s premaster se- cret and the new nonces exchanged in the Hello messages. This way, new keys can be established without the need for computationally costly public key operations. To the same end, TLS, like IPsec, can also use Kerberos for authentication and key establishment [79]. The third upper layer protocol defined for TLS is the Alert Protocol. It is used to signal regular connection closures as well as error conditions. Alert messages may have a severity of either warning or fatal. A host sends an alert with a severity of fatal and then immediately aborts the connection if the error it has to report makes it impossible or undesirable to continue transmitting data with the currently established parameters. A severity of warning on the other hand indicates that the host is prepared to continue the connection despite the reported problem, however the peer may as a reaction report a fatal error and terminate the connection from its side. Finally, the Application Data Protocol is responsible for the transfer of higher-layer protocol data over the TLS record layer using the negotiated security properties. Datagram Transport Layer Security (DTLS) [107] has been developed to utilize the functionality of TLS for UDP transmissions. Modifications are made neccessary mainly by the lack of ordering, duplication protection and guaranteed delivery in UDP [102] as opposed to TCP. They include the use of explicit sequence numbers, retransmission timers to detect and handle lost messages and the adandonment of stream ciphers that would create cryptographic interdependence between messages. The possibility of denial of service attacks using forged IP addresses is handled by the introduction of a stateless cookie exchange before the commencement of the actual handshake. OpenVPN7 is one well-known implementation of a site-to-site VPN using TLS. Its TLS control channel and Layer 2 or 3 data connection are multiplexed over one UDP or TCP link, providing an own reliability layer to TLS if UDP transport is used. The data packet format for the tunneled payload does not use TLS but is based on the IPsec ESP mode and consists of an HMAC, IV, an encrypted sequence number and the encrypted payload.

7http://openvpn.net/index.php/open-source.html

14 2 Related Work and Existing Technologies

2.4 Convergence

To achieve the goal of developing a Peer-to-Peer VPN secured by Trusted Computing and providing isolation of different customers’ slices, the building blocks described so far now need to be combined. Some examples of the different combinations are listed below.

2.4.1 Trusted Computing and VPNs As Virtual Private Networks utilize cryptography for many different purposes, such as authentication, integrity and confidentiality protection, there are several points where a VPN can benefit from the application of the functions provided by Trusted Computing. One capability that VPNs cannot easily provide without the use of TC is the assurance that the platform on the remote side is in a trustworthy state. To that end, Sadeghi and Schulz [123] extend the IPsec IKE protocol with remote attestation. In their proposal, Attestation Data Payload messages are exchanged after the initial IKE SA establishment and the IKE SA is used only after attestation has suc- ceeded. The provided assurance is bound to the IKE SA by deriving a shared Attestation Key used in the attestation (e.g. as part of the nonce input to the TPM Quote operation) from the shared secret that was used to generate the keys for that SA. In a similar vein, the concept of Trusted Channels is added to TLS in [7, 46], with a trusted channel being defined as a channel that not only allows secure communication across an untrusted medium, but also binds this secure channel to the state of the endpoints and allows the detection of any change to this state. The authors also introduce the notion of compartments, logically isolated software components (created through virtualization) which can use trusted channels to communicate with other compartments on the same or on other machines.

2.4.2 Trusted Computing and Peer-to-Peer By providing a common trust anchor without the need for a centralized trusted third party, Trusted Computing has the potential to greatly benefit the security of peer-to- peer networks. This can range from providing secure key storage to full attestation of remote peers to ensure their trustworthiness. In [10], Balfe et al. introduce a method for using the TCG Direct Anonymous At- testation (DAA) mechanism as a means to provide pseudonymous authentication in peer-to-peer networks without actually invoking its attestation function. They then de- velop this into a securely authenticated method for establishing a shared secret between two TCG-enabled peers and describe ways to integrate that algorithm into the estab- lished TLS and IPsec protocols. Finally, possible benefits and applications of such use of Trusted Computing in both “anarchic” file-sharing and commercial P2P networks are described. The Trusted Reference Monitor (TRM) approach [118, 153] on the other hand is based on a fully TC-enabled operating system using trusted boot, a secure kernel and

15 2 Related Work and Existing Technologies not only maintaining an SML for the system as a whole, but also calculating an integrity value for each application running in an isolated runtime environment. The TRM runs in userspace and utilizes the security functions provided by the secure kernel and the TRM installed in the platform to control object access and communications between applications running on the same or on a remote machine. In the case of interest here –a peer-to-peer application on one node attempting to connect to that on another one– the TRMs involved mediate the connection setup, provide one-way or mutual attestation of both the platform and the application, then monitor and authenticate the transmitted data. Thus, this approach provides not only trust in the remote system, but also content verification. Mobile ad-hoc networks (MANETs) [137] consisting of wireless mobile devices share many of the characteristics of peer-to-peer networks. They lack centralized servers and their nodes, which may join and leave the network at any time, build direct connections to transfer data. This is however complicated by the mobility and limited range of each device, which necessitates the introduction of a dynamic routing scheme to exchange data with nodes with whom no radio contact can be established. TrustMANET [73] is an approach to secure such networks using Trusted Computing. Its goal is to limit membership of the network to nodes in a trustworthy state and protect the exchanged payload and routing data from eavesdropping and forgery. This is achieved by remote attestation of neighbouring nodes during link establishment. Before deployment, each node is supplied with an AIK whose public part either needs to be certified by a CA or distributed to all nodes that are to be part of the network. After deployment, each node regularly broadcasts TrustMANET Call (TMC) messages consisting of routing information in an Originator Message (OGM) encrypted with a node-specific symmetric key R and a Diffie-Hellman-Merkle public value which is also entered into the node’s SML. Upon receiving such a message, a node not yet connected to its sender performs a TPM Quote using the DH public value it received and its own as the external nonce and sends its result as well as the current SML to the originator of the received TMC in a TrustMANET Quote (TMQ) message. Once a node has received both a TMC and a TMQ from a peer, it can verify the Quote and thus ensure that its AIK is known (or certified by a known CA) and it is in a trustworty state and that the DH public values were received as they were sent, providing protection against man-in- the-middle attacks on the key exchange. When both nodes have received and verified the other’s TMQ message, they can calculate a shared secret using the Diffie-Hellman-Merkle algorithm. This shared secret S is then used as a key to encrypt all future TrustMANET Data (TMD) messages. The first TMD sent by each node on a newly established link contains the key R used to encrypt that node’s OGM messages, now allowing the remote to access the routing information contained in the original and all future TMCs. Measurements have shown that this handshake takes approximately 3.5 seconds, of which the TPM Quote operation requires about 1.6 seconds. When joining a network already containing several nodes, network I/O can be handled asynchronously, while the Quote operations present a bottleneck as they can only be performed sequentially in the current version of the protocol.

16 2 Related Work and Existing Technologies

2.4.3 Peer-to-Peer VPNs Numerous concepts and implementations of Virtual Private Networks exist both from the scientific and the open-source communities. While few of them explicitly use the term “Peer-to-Peer”, many fulfill the criteria for P2P set forth in [132]: Equal, autonomous peers, decentralized resource usage (the resource being connectivity in the VPN case) and decentralized self-organization, ideally avoiding a central service for resource location. This includes IPsec using IKE as described above. Given a common trust anchor, IPsec peers can autonomously authenticate to each other, e.g. using certificates, and establish security associations. IP over P2P (IPOP) [45] is an example based on a structured peer-to-peer network, provided here by the BruNet [17] overlay framework. To join a network, an IPOP node needs to know (or find) another node that is already connected. While IPOP is implemented using layer 2 TAP interfaces, it routes only IP packets over the transport provided by BruNet, which can be either UDP or TCP. The latency overhead has been measured at 6 to 10 ms. When a node resides on a virtual machine, IPOP can be installed either inside the VM itself or on the host. Most other solutions deviate from the pure peer-to-peer philosophy in some way, for example by requiring manual configuration of each peer or connection or by using a central server for registration and look-up. Campagnol VPN8 belongs to the latter group by using an external server which maintains the registration of nodes and keeps track of connections. Additionally, it acts as rendezvous server that facilitates connections between nodes behind network address translation (NAT) through NAT hole punching. This is necessary because in holding with the peer-to-peer philosophy, Campagnol nodes create direct connections on demand. These connections carry layer 3 IP packets encapsulated in UDP datagrams. Authen- tication and encryption are done using DTLS, which requires at least a small public key infrastructure (PKI) to supply each node with an asymmetric key pair and associated X.509 certificate signed by a CA which provides a common trust anchor. Another member of this class is N2N (Network to Network)9 [25], which uses one or more supernodes per community. As with Campagnol, these supernodes register edge nodes and facilitate communication between edge nodes that could not otherwise establish a connection. Here, this is achieved by using the supernode as an intermediate hop for routing all traffic between the affected nodes. This technique is also used for forwarding broadcast and multicast messages to all nodes in a community. Once a node has learnt about a peer it wants to connect to, it can also register directly with that peer, thus forming a direct connection over which encrypted Ethernet frames are sent encapsulated within UDP datagrams. One noteworthy feature of N2N are the communities, which represent isolated net- works. An edge node can join an arbitrary number of these, as long as it possesses the shared key and a list of supernodes serving the respective community. Supernodes can

8http://campagnol.sourceforge.net/ 9http://www.ntop.org/products/n2n/

17 2 Related Work and Existing Technologies in turn support several communities, whose shared keys they do not need to know, a design feature meant to protect communities against compromised supernodes. Several security weaknesses have been identified in N2N, which will be addressed in a new version. One planned extension is the integration of a key exchange protocol such as IKE or Kerberos. Several VPN solutions deviate from the peer-to-peer concept by basing authentication on direct trust and requiring the public keys of all peers a node may directly connect to to be included in the node’s configuration. tinc10 is one example. It allows automatic direct routing between nodes that possess each other’s public key and also supports indirect routing –using one intermediate hop node– if a firewall or NAT prevents direct connections. When two nodes connect, they exchange information about other nodes and subnets to facilitate this. tinc supports tunnelling either layer 2 frames or layer 3 packets over UDP, while the control channel (called “meta-connection” here) uses TCP. GNU Virtual Private Ethernet (GVPE)11 also relies on every node being configured will the public RSA keys of all possible peers. If a direct connection between two nodes is not possible due to NAT or firewalling, a third node configured as a router can mediate between them by sending each a connection request on the other’s behalf. It is also possible that two nodes are unable to connect directly because they use different GVPE transport protocols; in this case, a router node speaking both protocols can be used to convert and forward messages. As its name suggests, GVPE provides a virtual (layer 2) Ethernet, whose frames can be encapsulated in raw IP packets, ICMP messages, TCP, UDP or HTTPS transports or in Domain Name System (DNS) queries and responses. Due to the use of 12 bit addresses, the number of nodes in a virtual network is limited to 4095. Virtual Distributed Ethernet (VDE)12 [24] does not exhibit the dynamic self-organization property of an ideal peer-to-peer network. It was also not designed primarily as a VPN, but simulates a physical Ethernet setup through virtual switches and cables, which may be located on different hosts. As in a physical Ethernet, switches have multiple ports which can be connected to virtual network interfaces or virtual machines identified by MAC addresses. Cables are used to connect two switches and consist of two plugs and an interconnection tool, which may be an operating system pipe, but can also take the form of an encrypted and authenticated SSH connection acting as a VPN tunnel be- tween two hosts. Each connection has to be configured manually, but can be severed and reconnected without affecting the operation of the overall network.

2.4.4 Peer-to-Peer VPNs using Trusted Computing An approach for combining trusted computing with SSL in order to bind the identity of a connection endpoint more securely to the trusted state of platform it resides on

10http://www.tinc-vpn.org/ 11http://software.schmorp.de/pkg/gvpe.html 12http://vde.sourceforge.net/

18 2 Related Work and Existing Technologies is presented in [47]. In this approach, masquerading attacks on remote attestation are prevented by adding the SSL certificate of the server to its SML and extending a PCR accordingly. This prevents a malicious server from forwarding an attestation request from a client to another, trusted system and presenting the result to the client, as there would be a mismatch between the SSL certificate used by the server and the SML entry that is part of the attestation reply. The authors also address the problem of compromised private SSL keys in the absence of a working revocation infrastructure that could alert clients of the fact that a certain SSL key is no longer to be trusted. To allow clients to detect a malicious host using a stolen key, they introduce a third “Platform Properties” certificate. This certificate contains endpoint identification data from the SSL certificate such as domain name and organization as well as information from the Attestation Identity Credential, thus providing a binding between the two. It can be signed either by the PCA that issued the AIC, which would allow the client to verify the certificate chain for both simultaneously, or by any other CA.13 To further mitigate the problem of clients having to verify too many certificate chains, the authors propose to make the SSL certificate self-signed. This does not reduce security since its relevant data is also vouched for by the Platform Properties certificate and the SSL key is bound to the platform by inclusion of the SSL certificate in the SML used in remote attestation. This also allows more flexibility for the SSL keys used, such as shorter validity times, because the server can certify keys as they are created without having to resort to an external and potentially costly CA. The authors further illustrate how this approach could be especially useful in situations where the servers are virtual machines hosted on a TPM equipped host and are created and destroyed dynamically. Here, the Platform Properties certificate would refer to the physical host and contain the AIK of the physical TPM. The host would then be responsible for creation of the servers’ SSL certificates as well as their revocation, should monitoring of a VM indicate that it has left its trusted state. To establish a trusted connection to a server hosted in a VM on such a host, a client would first request a remote attestation from the host, verifying its Attestation Identity Credential, then check the host’s Platform Properties certificate binding the AIC to the platform, and finally the SSL certificate of the virtual server, which would have to be included in the SML presented in the first step. Revocation of an SSL certificate would be effected by adding a corresponding entry to the SML, so that a client would be informed of a compromised key without having to resort to additional means. The sVPN architecture presented in [122] is designed to support multiple isolated userspace environments (compartments) virtualized by a trusted hypervisor. In such a trusted environment, the sVPN security service, containing all critical functionality and optimized for low internal complexity to facilitate security auditing, resides in a protected security service layer provided by the hypervisor. It communicates with the

13However, this approach still requires the compromise to be detected –as would have been necessary to revoke the certificate– and a new AIK to be created on the compromised server to prevent a masquerading attack using the stolen key.

19 2 Related Work and Existing Technologies compartments using its service through IPC channels provided by the operating system. The protcol used is a simplified version of IPsec supporting only authenticated ESP encryption in tunnel mode, which still remains compatible with standard IPsec impemen- tations. Key negotiation is likewise done using a reduced IKEv2, handled by a neutral security service responsible for the sVPN connections of all compartments running on a machine. Consequentially, the sVPN service acts as a common endpoint for all secure VPN channels, providing isolation as required. Still, each compartment receives a sep- arate IP address and cryptographic identity to allow connections with remote standard IPsec endpoints. The IPsec authentication key as well as the IPsec Security Policy Database (SPD) are kept in secure storage, sealed to a trusted state of the host system. This provides implicit attestation by ensuring that they can only be accessed by an uncompromised sVPN platform. Use of Trusted Computing functionality is also projected for delegating authentication to remote security services after successful remote attestation and by using trusted user I/O paths to protect login credentials during direct user authentication for protected compartments. A commercially available solution is TURAYA. TrustedVPN [127], which is primarily meant for building site-to-site VPNs (e.g. connecting the networks of different branches of a company), but can also accomodate mobile clients. The protocol used is IPsec, augmented by the use of Trusted Computing while still offering compatibility with other IPsec peers. The system consists of two types of appliances: The TrustedObjects Manager, equipped with a hardware security module, is the central management server and point of configu- ration. For each site’s network, a TrustedVPN appliance acts as the VPN gateway. These gateways use an onboard TPM for secure storage of private keys, integrity measurement and encryption of locally stored data. Before deployment, a gateway only needs to be configured with the IP address of the TrustedObjects Manager. It can then connect to this server, perform mutual au- thentication, prove its own unmodified state by remote attestation and finally receive configuration data allowing it to connect to other sites. The solution allows for the creation of separated logical VPNs (Trusted Virtual Domains); for each of these, the TrustedObjects Manager creates a separate CA to certify the gateways’ IPsec keys. Dif- ferent subnets of a network served by a single gateway can be configured to belong to different logical VPNs. Performance is stated as 80 MBit/s (deemed sufficient for 100 clients) for a Trust- edVPN appliance using a 1.8 GHz VIA C7 processor with a hardware cryptography accelerator and 500 MBit/s (1000 clients) on an Intel Core2Duo CPU running at 3 GHz.

20 3 Concept

In this chapter, a Peer-to-Peer based Virtual Private Network secured by Trusted Com- puting will be developed. Section 3.1 lists the requirements to be fulfilled, followed by design decisions led by these in section 3.2. Section 3.3 introduces the protocol entities involved and section 3.4 shows their interactions and describes the protocols in detail. Finally, section 3.5 offers some enhancements on the basic protocols.

3.1 Requirements

The concept to be developed naturally shares several required properties with the NaDa system as a whole; these are explicitly described in the NaDa documents [82,83]. Others derive directly from the proposed use case.

3.1.1 Node Authenticity and Integrity Each deployed node needs a unique identity that cannot be changed or transferred (In the terms used in [30], it must be persistent (a node must retain its identity over time), distinct (no node can claim more than one identity), unforgeable (a node cannot claim an identity it was not assigned) and unique (no two nodes may possess the same identity).) and must be able to prove its authenticity within the network. As the node is operating under physical control of the end user and is thus prone to tampering, sustaining its platform integrity is another important requirement. To this end, the node must be able to report integrity metrics indicating its current state. Only nodes in an allowed state may become or remain part of the network, and need to be able to prove this fact to remote nodes.

3.1.2 Secure Communications While the security requirements of customers and their applications may vary widely, the network should at least support integrity and confidentiality protection for the data transferred between nodes. Nodes must also check the authenticity of incoming requests and messages, as well as that of their sender, to prevent malicious nodes from attacking the network.

3.1.3 Customer Isolation While isolation of slices from each other is provided by virtualization, customers should also be unable to determine the identity of the node on which a certain slice is running as

21 3 Concept well as what other slices are installed on that node, their resource consumption and traffic patterns. As these data may divulge important operating data of the ISP’s network, their disclosure to possible competitors must be prevented. Customer slices should also be prevented from contacting slices of other customers or ISP-provided application slices whose services they have not purchased.

3.1.4 Encouragement of network-edge connections One of the interests of the ISP is to concentrate the traffic of a node in the network next to it (i.e. at the network edge), thus reducing the load on the ISP’s backbone. The customers however do not share this goal, although they might be interested in achieving high data transfer rates and will certainly wish to minimize the traffic cost billed by the ISP. The concept to be developed must therefore allow to provide incentives to the cus- tomers for reducing traffic across the ISP’s core network (or even competitors’ networks) and preferring connections between slices topologically close to each other.

3.1.5 Performance To provide a high Quality of Experience (QoE) to the end user, the requested function (such as playing a video) should be executed with as little delay as possible, even if it requires connecting to other nodes. But performance is also relevant in non-interactive scenarios. For example, if the P2P Agent on a node using a broadband connection with a goodput of 5 000 kbps (a relatively slow link by today’s standards) were using the BitTorrent protocol [22], it would take approximately 400 ms to download one 256 KiB piece. Since 2048 bit RSA signatures – which are the basis for the TPM Quote operation that is used for remote attestation– alone can take between 150 ms [135] and 3 seconds [113] on a TPM, with speeds of 200 ms being used for advertising [8], performing a new attestation for each data transfer would be infeasible. Even when using optimizations such as multiple hash attestation [44], the TPM would be (at least almost) fully loaded only performing attestations for this protocol, and the commencement of the data transfer would be delayed by about as much as its actual duration. (In practice, the node would make not one, but 10 to 40 concurrent connections [61, 78], however this would still have the same effect of doing 2.5 connection setups per second on average, assuming that each piece is downloaded from a different peer.)

3.1.6 Low Maintenance One of the drawbacks of a system whose components are distributed as widely as NaDa’s set-top boxes are is the fact that they are not easily accessible should an event occur that requires widespread hands-on maintenance. Having to send out technicians to every box or requiring all users to send in their STB would incur extremely high costs not only financially but also in terms of public relations.

22 3 Concept

Therefore, it is necessary to make sure that even in a worst-case scenario, such as compromise of a cryptographic algorithm or a key in the ISP’s CA chain, measures can be taken that will mitigate the problem without the need for physical access to the STBs. (Although it may be acceptable to send out update disks or memory cards to the users, this would probably still result in a high number of nodes not updated.)

3.1.7 Scalability A commercially deployed version of NaDa could possibly grow to include high num- bers of end users and customers, distributed over a large area, and would still have to function and perform satisfactorily. To explore the scalability of the proposed concept, the following scenario will be used, in the hope that it does present the most extreme deployment practically conceivable: Due to the high level of control made possible by the strong guarantees the NaDa platform provides through its use of Trusted Computing, the government of China [19] decides to make it the default way of accessing broadcast media on demand, establishing a NaDa set-top box as the prescribed means of broadband internet access in every home. All of the more than 2 000 television as well as all radio stations in the country (most of them previously local) make their programming available on this national NaDa system. At an average household size of 2.5 and assuming that such a market would also be at- tractive to other content providers, the established network would consist of 500 000 000 nodes in end users’ homes, catered to by 10 000 customers. However, due to resource constraints on the set-top boxes and the fact that many content providers would only be of local, regional or specialty interest, no more than 100 slices would be installed, much less concurrently active, on any single node. Still, a very small number of customers would have their slices present on all or almost all deployed nodes.

3.2 Design Decisions

None of the existing approaches and solutions introduced in chapter2 is able to fulfill all requirements established in the last section. Generic multi-purpose protocols offer superfluous functions that may have unintended consequences and introduce unneces- sary complexity (especially IPsec has been criticised in this area [39]), while simpler and more specialized solutions would require adaptation of an extent comparable to a new development from scratch. Additionally, compatibility with other systems it not a requirement in this context. Therefore, the potential of a solution tailor-made to the needs of the pre-established architecture will be examined in this thesis. The developed concept draws heavily on ideas from BitTorrent [22] for the structure of the peer-to-peer network and from Kerberos [92] and Trusted Kerberos [75,76] for the concept of using tickets to carry authentication and authorization information. To protect the privacy of end users and distribute server load, duties should be sep- arated where desirable and possible. For example, the entity assigning pseudonymous

23 3 Concept identities to nodes or users is able to disclose their identities and thus should be (techno- logically and organizationally) separated from the consumers of the pseudonyms. Also, functionalities that can be expected to put a high load on the server providing them should be separated to allow balancing the load without major changes to protocols or structures. When a cryptographic algorithm (such as an encryption or hash function) is compro- mised, it should be easy to replace it with a still secure alternative (algorithm agility). Therefore, specific algorithms will be dictated only where absolutely unavoidable, such as in the case of the TPM that is only required to support RSA for encryption and sig- natures and SHA-1 for hashing. In all other cases, algorithm identifiers and flexible data structures are used so that, ideally, a compromised algorithm only needs to be removed from a configuration file on a single server to secure the network again. When data are to be transmitted securely, they will usually be encrypted and signed (or protected with a message authentication code (MAC)). This can be done in dif- ferent ways, either by encrypting the data and then appending a signature over the plaintext (Encrypt-and-Authenticate) or the ciphertext (Encrypt-then-Authenticate), or by first creating a signature over and then encrypting it together with the plaintext (Authenticate-then-Encrypt). Abadi and Needham [1] advocated including a signature of the plaintext in the data to be encrypted on the semantic grounds that this order proved that the signer actually knew the data he signed and that it would otherwise possible to replace the signature with one made by someone else. This is also the order used in well-known protocols like Transport Layer Security (TLS) [26], the successor to the Secure Socket Layer pro- tocol (SSL). The Secure Shell protocol (SSH) [152] uses the Encrypt-and-Authenticate paradigm. However, both these approaches have been proven [3, 13, 14, 70] to be secure only under certain assumptions (such as the use of certain encryption modes), while the Authenticate-then-Encrypt paradigm is secure as long as the underlying cryptographic algorithms are secure. Since the designed protocols aim to be algorithm agile and allow the use of as many combinations of algorithms as possible, the approach that will be used here therefore is to first encrypt the data and then append a MAC or signature over the ciphertext (and any data that is transmitted unencrypted). One important characteristic of any Virtual Private Network is the (ISO OSI) layer at which it operates, the most common choices being the Data Link Layer (OSI layer 2, e.g. Ethernet) and the Network Layer (OSI layer 3, e.g. IP) [40]. While intuitively, a layer 2 VPN offers higher flexibility by allowing the use of any or even multiple layer 3 protocols, this is not entirely true, because the VPN implementation cannot be entirely protocol-agnostic if it is to function efficiently. One example is the Address Resolution Protocol (ARP) [100] which provides mapping between layer 3 addresses and layer 2 addresses. It works by broadcasting requests to all reachable stations, with the one whose address is being queried sending a reply to the requestor. Obviously, such frequent broadcasts are highly undesirable in a VPN

24 3 Concept where every link between two nodes needs to be negotiated and encrypted. Therefore, ARP requests would have to be intercepted, the lookup be done on behalf of the slice –to which end some kind of directory would have to be established– and a reply be constructed and sent to the requestor. While this is certainly feasible, other layer 2/3 protocol combinations may have other or additional requirements that could not all be anticipated and thus intercepted. Additionally, each protocol layer also adds its own overhead in the form of protocol headers (and optionally trailers). Ethernet for example adds 18 bytes of address, length and checksum information to each frame [137] –on top of IP, TCP or UDP and applica- tion headers– that would have to be either transmitted over the network or reconstructed at the receiver side. Therefore, the VPN to be developed will work at layer 3.

3.3 Protocol entities

This section introduces the entities and concepts making up the proposed protocol suite. Many of these entities have identifiers (or IDs) associated with them; most of these are part of a shared namespace (the common ID space), allowing a receiver to identify both the entity type and the single entity designated. This allows different but related semantics to be carried by the same message structure.

3.3.1 Slice Hosted on nodes, slices are the raison d’ˆetre of the entire system. Isolated in virtual machines (VMs), they communicate with the outside world using their VM’s virtual network interface bound to the VPN they are part of1. This means that error conditions occurring on the node or on the network are also communicated to a slice through this interface, for example using ICMP messages generated by the node. Slices come in two different kinds: Blank or raw slices (here also called customer slices) provide virtualized resources to customers. The operating system and applications running inside them are controlled by the customer that has rented that slice, although the slice images may be subject to a security review by the ISP before being cleared for deployment on nodes. Being part of the VPN tagged with the Customer ID of the customer renting the slice, it can only communicate with slices also belonging to that VPN. Application slices on the other hand are under control of the ISP and provide services and functionalities (such as peer-to-peer transfer or network anomaly detection) to cus- tomer slices. When a customer purchases access to such an application slice on a node, its network interface is mapped into that customer’s VPN address space, it receives a new network interface bound to that VPN or it is cloned and the clone receives an IP address in the VPN. Which of these alternatives is selected will depend on the function

1And possibly also through an API exposed by the node, but this will not be used here.

25 3 Concept and implementation of the application slice, however, the selection will be transparent on the customer side.2 Slices are identified by a SliceID (APP Slice ID in [83]), part of the common ID space and containing information on the customer it belongs to, the Region it is located in, and an identifier (APP ID) provided by the customer, but not giving the node the slice is installed on.

3.3.2 Node A node is the protocol entity that runs on the set-top box (STB) located in an end user’s home and acting as the residential gateway providing internet access to the user’s home network. It is assumed that the STB contains a modem for the broadband access technology used and therefore is always connected directly to the wall outlet provided by the ISP. This means that the node will never be behind an network address translation (NAT) system, unless the NAT is run by the ISP. Each node is controlled by a NodeManagement module and can host an arbitrary number of slices in virtual machines, theoretically limited only by the available system resources. It uses the integrity reporting functions provided by the TPM installed on the STB to prove its state to the network, thus allowing expulsion of compromised nodes. The public part of the Endorsement Key (EKPUB) stored in the TPM is also used as a serial number uniquely identifying each node and is stored with the end user’s registration data when the STB is shipped. (Since the STB is assumed to remain property of the ISP, this value can also be updated if a defective box is replaced. Consumer protection issues may arise from the fact that the user is bound not just to a certain brand or type of, but even to a particular box; however, this legal question is beyond the scope of this thesis.) Due to the requirement that customers should not learn about the structure of the ISP’s network or the identity of the nodes their slices are hosted on, their access to the network must be mediated by a trusted instance that allows them to communicate with their slices but at the same time does not reveal any sensitive information. This role is played by special nodes installed either on the customer’s or the ISP’s premises, called customer nodes. These customer nodes do not host usual slices but only act as gateways between the customer’s network and his VPN on the NaDa network. The integrity of customer nodes, just as that of regular nodes, is protected by the primitives provided by Trusted Computing, and its communications on the VPN side are encrypted. However an attacker with physical control of a node, be it a customer node or a regular node acquired under the guise of a normal end user, might still be able to learn about the network structure by traffic analysis. This is especially true for a malicious customer who would be able to initiate a connection to a certain slice and then observe the IP address that his node contacts. Decoy traffic or measures at the

2The NaDa API exposed to the customer would probably contain a function with the semantics “I want to rent an application slice providing functionality X on the node hosting slice Y . Its IP address in my VPN should be Z”, but this is beyond the scope of this thesis.

26 3 Concept data link layer could mitigate this problem. Both regular and customer nodes are identified by a NodeID, also containing informa- tion on the Region the node resides in. NodeIDs are not permanent and may be changed at any time for operational or privacy reasons; they will do so on reboot of the node. NodeIDs are part of the common ID space.

3.3.3 Privacy CA As defined by the Trusted Computing Group, the Privacy CA (or PCA for short) cre- ates Attestation Identity Credentials (AICs) certifying that a certain Attestation Identity Key (AIK) belongs to a compliant TPM, while –hence the name– protecting from un- wanted disclosure the association between the Endorsement Key uniquely identifying the platform and the pseudonymous AIK. In this proposal however, the PCA (to be called NaDa PCA or NPCA if and where this distinction is important) also carries the additional duty of performing the first line of admission control for a node wanting to join the network (by verifying that the node’s EKPUB belongs to a validly registered STB), assigning Regions and NodeIDs and then referring the node to the service to be connected next. To fulfill its functions, the PCA needs access to the end user contracts and the ISP’s authentication infrastructure. It also needs information about the ISP’s network topol- ogy in order to be able to assign nodes to a Region based on their IP address. Due to the pseudonymous nature of AIKs and NodeIDs, the PCA is the only entity that is able to link these to the node’s EKPUB and thus reveal the end user’s identity. This mapping may be stored for billing and abuse handling purposes. Other than that, the PCA does not need to keep any state information about individual nodes between certification requests.

3.3.4 Attestation Ticketing Service The Attestation Ticketing Service (ATS) is the second line of admission control on an operational level and is contacted much more regularly by each node. It performs remote attestation of nodes to verify that their system state is trustworthy as defined by the ISP and, if successful, grants a ticket allowing the node to connect to the Tracker and actually join the network. To this end, the ATS needs a list of reference integrity metrics (RIM), giving hash values of all trusted hardware and software components it may encounter when assessing the integrity of a requesting node’s system state. It preferably should also have access the same network topology information as the PCA, to verify that the node has not been moved to another region since AIC was created, which would cause unnecessary traffic in the ISP’s network.

27 3 Concept

3.3.5 Tracker The Tracker serves two related purposes: It is the look-up server with which all nodes and slices are registered, and it acts as an introducer between nodes wanting to communicate. In the former function, it keeps a database of node and slice data, such as IDs, IP addresses and keys, in the latter it mediates the contact by providing keys and credentials certifying that the nodes have been certified by the ATS and currently are approved members of the network. The Tracker is identified by a TrackerID that is part of the common ID space.

3.3.6 Region Important to both the ISP and the customers, a Region is a geographically and network- topologically well-defined grouping of nodes. Towards the customer, it designates the geographical area where a slice is located (cf. the YouTube case study in [82] where the customer orders more resources on Mallorca), while to the ISP it provides routing information. For ISPs employing regional points of presence (PoPs), a Region could encompass all nodes connected to one broadband remote access server (BRAS; e.g. the DSL Access Concentrator (DSLAC) for ISPs providing DSL service). Since the BRAS is the first IP layer hop for connections from the end user, in this case all nodes belonging to a certain Region would be only two hops away from each other. Regions are identified by a RegionID which is part of the common ID space. RegionIDs are assigned in such a way that a distance metric can be calculated giving the (approxi- mate) network distance3 between the Regions they designate. This way Customers can be incentivized to prefer connections between slices with short routes by basing the tariff to be payed for data traffic not only on the volume of data transferred but also on the distance over which it had to be carried. For example, data transferred between slices in the same Region could be free, a low fee could be levied for transfer between slices in neighbouring Regions and a substantially higher one for data that has to be carried across the ISP’s or even through a competitor’s network, reflected by a high distance between the RegionIDs.

3.3.7 Wire A Wire (from the BitTorrent [22] term “Peer Wire Protocol”) is a bidirectional virtual layer 3 network connection or tunnel between two slices or the NodeManagement on two nodes. Wires can supply various security properties, such as confidentiality, integrity and authenticity, but also non-repudiation, replay protection and timestamping, as selected by the entity initiating the connection. Again, due to the different resource requirements, pricing of transferred data may be based on the requested properties.

3This distance need not be based only on the number of hops, but could also incorporate data such as the bandwidth of and the expected load on network links.

28 3 Concept

Every wire has a WireID selected by the participating nodes. WireIDs are transmitted with every packet sent over a Wire, but on the other hand need to be unique only between the two nodes forming the cryptographic endpoints of the wire. Therefore they should and can be relatively short and thus are not part of the common ID space.

3.4 Protocol Flow

In the following, the different protocol steps are described in detail: First the node creates an AIK and has it certified by the PCA, then it contacts the ATS, performs remote attestation and receives a ticket with which it registers itself and its slices with a Tracker. Then it creates a Wire by requesting the address of and cryptographic keys with the destination node from the Tracker and contacting the destination node. Upon shutdown, the node deregisters from the Tracker. In the protocol listings, the symbol ...← refers to the entire message as sent so far, i.e. Sig(...← ) indicates a signature over the preceding message fields. As stated in section 3.2, signatures or message authentication codes (MACs) are calculated over the ciphertext where message fields are sent encrypted. While not always explicitly stated, it is assumed that all signatures and MACs are verified by the receiving party if it is in the possession of the required key. If this verification fails, the message is silently discarded, as the receiver will not be able to discern whether the message was damaged in transit, in which case a request to resend it would be useful, or sent by an attacker that is either trying to guess a key or to just overload the receiver, in both of which cases sending a reply would possibly help the adversary.

3.4.1 AIK Certification Since remote attestation is used to verify the system integrity of the participants, each node requires an Attestation Identity Key pair that is certified with a corresponding credential indicating that the key actually is an AIK and is under control of a compliant Trusted Platform Module. Each node also needs to be assigned a unique NodeID. Both of these tasks are handled by the Privacy CA. The protocol for this is shown as Protocol 3.1:

(1) N → PCA : IdReq

(2) PCA → N: EEKPUB(Hash(AIKPUB), Nonce) (3) N → PCA : Hash(AIKPUB, Nonce) P ubE P ubS (4) PCA → N: EEKPUB(AIC, Cert(KAT S ), Cert(KAT S ))

Protocol 3.1: AIK Certification

Upon bootup or expiry of its previous AIK Credential, the node uses the TSPI TPM - CollateIdentityRequest command from the TCG Software Stack (TSS) to generate a

29 3 Concept new AIK key pair and create a certificate request package (the identity request IdReq) destined for the privacy CA (PCA). The IdReq will automatically be encrypted using the public key of the PCA and contains not only the public part of the AIK pair (AIKPUB), but also the Endorsement, Platform and Conformance Credentials for the hardware the node is running on. The node then sends IdReq to the PCA. (It is assumed that all necessary data –such as the IP address and key of the PCA– are known to the node software at deployment time.) The PCA decrypts the received identity request and first extracts the public part of the endorsement key pair of the node’s TPM (EKPUB). Using the EKPUB to look up the corresponding set-top box (STB) in the respective database, it verifies that the STB is currently registered to an end user with an active contract4. Optionally, the PCA also verifies with the ISP’s authentication infrastructure (such as RADIUS [111]) that the IP address the request was received from equals the IP address currently assigned to that user. Before proceeding, the PCA verifies the identity of the requesting node [49] by sending to it the hash of the AIKPUB to be certified and a random nonce, encrypted under the EKPUB retrieved from the received IdReq. If the node is genuine (i.e. the IdReq was created by its TPM) it is able to decrypt the challenge using the TPM ActivateIdentity command, compare the received AIKPUB hash to that of the one is it requesting certi- fication for and respond by replying with a hash over both the AIKPUB and the nonce. Now assured that it is not wasting its resources on an attacker attempting a denial of service (DoS), the PCA proceeds to verify the credentials and identity proof provided by the node in the IdReq package. If this verification is successful, it selects the Region the node should belong to based on the node’s IP address and generates a NodeID. It then creates the attestation identity credential AIC certifying that the AIKPUB presented does belong to a registered STB with a trusted TPM. The AIC also contains extensions stating the selected NodeID, the fact that the node belongs an end user (as opposed to a customer or the ISP5), and possibly other data such as the end user’s contract type (prepaid or postpaid), STB model or any other information that may be useful as long as it cannot be used to ascertain the user’s identity. It also contains the information that this AIK is intended and must only ever be used to attest to the ATS to retrieve a Tracker Ticket. The PCA then encrypts under the node’s EKPUB the AIC together with certificates for the encryption and signature key of the ISP’s Attestation Ticketing Service (ATS) and sends them to the node, where the information can be decrypted using the Tspi - TPM ActivateIdentity command of the TSS.

4This may include verifying that the user has not been blocked for abuse or non-payment and the STB has not been reported as stolen. In these cases, certification could be refused and a corresponding error message returned. 5It is assumed that such nodes’ AIKs will be created and certified by a different procedure, possibly before deployment. Their AICs may also have much longer validity periods.

30 3 Concept

3.4.2 Attestation and Tracker Ticket Retrieval After its AIK has been certified by the PCA, the node can use it to remotely attest its system state and receive a ticket allowing it to join the network. It does this by contacting the Attestation Ticketing Service (ATS) using protocol 3.2:

(1) N → ATS : EncrAlgo, HashAlgo, E P ubE (KSess), EKSess (Timestamp, AIC, KAT S EncrAlgoList, IA-AlgoList) (= M1)

(2) ATS → N: EKSess (Nonce)

(3) N → ATS : EKSess (Quote(Hash160(Nonce, M1)), SML)

(4) ATS → N: EKSess (TrackerID, TrackerIP, TrackerPort, Timestamp, ExpiryTime, ← EncrAlgo, EncrKey, IA-Algo, IA-Key, CustIDs), TT, Sig P rivS (...) KAT S Protocol 3.2: Tracker Ticket Retrieval

First the node examines the certificate of the ATS’ asymmetric encryption key it received from the PCA, reads from it the symmetric encryption and hash algorithms supported by the ATS and chooses the algorithms it will use. It then generates a session key KSess for the selected encryption algorithm that will be used to encrypt most of the data exchanged with the ATS. This symmetric session key is then encrypted under the asymmetric algorithm and key provided in the certificate, followed by a current timestamp, the AIK credential and lists of the encryption and integrity/authenticity protection algorithms supported by the node’s cryptographic library, all encrypted under KSess. The node then sends this message, preceded by the selected encryption and hash algorithms, to the ATS at the IP address and port also retrieved from the certificate, keeping a copy of the message for later use. Upon receiving this message, the ATS decrypts the asymmetrically encrypted session key, then the symmetrically encrypted data. It first checks that the timestamp is current, then retrieves the NodeID from the AIK credential and verifies that the IP address from which the message was received belongs to the same Region as the NodeID. It also verifies that this AIK is actually certified for use in this protocol. Like the node, the ATS keeps a copy of the message as it was received. The ATS then generates a fresh random nonce, encrypts it under the session key and sends it to the node. The node decrypts the nonce from the ATS and hashes it (using the selected hash function producing a 160 bit output), together with the contents of the first message as it was sent over the network. This value is then used as the “External Data” nonce input to a TPM Quote attestation operation over pre-determined PCR registers, yielding an AIK signature over a data blob containing the current PCR values. The node encrypts this signed data blob containing the PCR values and the provided nonce together with its current stored measurement log (SML) using the session key and sends them to the ATS, where in the first step after decryption of the message, the AIK

31 3 Concept signature is verified. A successful verification not only indicates that the PCR values contained in the signed data blob correctly reflect the node’s system state, but (through the inclusion of a nonce that was derived from a message hash and a fresh challenge from the ATS) also serves as a proof of freshness of these values and as a delayed signature over the first message sent by the node. In the next steps, the ATS verifies that the SML transmitted by the node does indeed lead to the signed PCR values and thus represent the node’s current system state, and that all SML entries are consistent with a trustworthy node configuration and state. To do this, it compares them with a pre-determined list of reference integrity metrics (RIM) listing clean-room measurements of all trusted hardware and software components – in contrast to an open PC scenario, the closed set-top box architecture will lead to such a list being of manageable size. If all SML entries possess a RIM counterpart, the ATS is assured that no untrusted hardware was added and no untrusted process was executed (at least by means over which the trusted operating system running on the node has control). A possible extension would be a list of once-trusted software that has meanwhile been considered obsolete or found to contain bugs. If the ATS found such entries in a node’s SML, it could restrict its access to an update service where the node would retrieve a current version of the operating software and then return to the ATS for a ticket providing full access. Alternatively, such an “update ticket” could be issued to all nodes in an untrusted state, including those that have unknown entries in their SML and those whose TPM Quote signature could not be successfully verified, in order to allow them to return to a trusted state without user or operator intervention. However, this assumes that the software update is not considered to be sensitive to disclosure, as it could be delivered to a potentially compromised node. As an additional precaution, these nodes could be referred to a special “Update Tracker” with no connection to the rest of the network, further reducing the chances for a malicious node to use the limited authorization granted to attack the network. The ATS then collects or computes all other data necessary to create a Tracker Ticket (see next section 3.4.3). It encrypts to following data using the session key: The ID, IP address and port number of the Tracker the node is to contact next, the current timestamp6, the expiry time of the ticket6, the encryption algorithm to be used when communicating with the Tracker6, the encryption key(s) and possibly other algorithm specific data6, the integrity and authenticity protection algorithm to be used6, integrity and authenticity protection key(s) and possibly other algorithm specific data6, and a list of Customer IDs the node may connect to6. This ciphertext is sent to the node, together with the Tracker Ticket and a signature made using the ATS’ signature key. The node now has all the information and credentials –in the form of the Tracker Ticket– required to register with the Tracker.

6These values are identical to their counterparts in the Tracker Ticket and are explained there.

32 3 Concept

3.4.3 Tracker Ticket A Tracker Ticket is issued to a node after it has remotely attested its system state to the ATS. It is symmetrically encrypted with a key shared between ATS and Tracker and serves both authentication and (through the CustIDs field) authorization functions. Its composition is shown in table 3.1.

# Name Description 1 NodeID ID of the node this ticket is issued to 2 TrackerID ID of the tracker that can be accessed with this ticket 3 NodeIP IP address of the node 4 NodePort Port number of the node 5 Timestamp Time this ticket was created 6 ExpiryTime Time when authorizations granted by this ticket expire 7 SuppEncrAlgos List of Encryption algorithms supported by the node (in order of preference) 8 SuppIAAlgos List of integrity/authenticity protection algorithms supported by the node (in order of preference) 9 EncrAlgo Algorithm with which the traffic between node and tracker is to be encrypted Encr 10 EncrKey Key data KNT to be used for encryption 11 IAAlgo Algorithm for integrity and authenticity protection between node and tracker. IA 12 IAKey Key data KNT to be used for integrity and authenticity protection 13 CustIDs List of Customer IDs that may be contacted using this ticket 14 MAC(Ticket) Integrity and Authenticity protection for this ticket (calculated over ciphertext of fields 1 through 13)

Table 3.1: Tracker Ticket. Italicized names indicate encrypted fields.

It contains the IDs of the node it is issued to and of the Tracker it is to be presented to, which could be the regular Tracker or an Update Tracker as described. These are followed by the IP address and port number the node is using. The Timestamp field gives the time at which the attestation of the node took place and the ticket was created. This means that the Tracker should not accept but block until its expiry time a ticket whose timestamp lies in the future. Optionally, policy may also define a maximum delay shorter than the ticket expiry (such as 10 seconds) after which a ticket must have been presented to the Tracker (Ticket Presentation Window, TPW ). This will reduce the time available for replay attacks while not harming normal protocol flow, as in normal operation a node will contact the Tracker immediately after is has received a ticket. Expiry is the point in time after which all authorizations granted by this ticket expire. The validity period of a ticket is a compromise between performance –as a ticket has to be renewed by re-attestation to the ATS before it becomes invalid– and security –

33 3 Concept as a node may be compromised after attestation without the ticket becoming invalid. Another reason not to set this time too long is the fact that the keys for communication between node and Tracker are provided in the ticket and thus key renewal is effected by retrieval of a new ticket. A validity period of 60 to 120 seconds should be a good value. Another use for such a short validity span lies in the fact that a node has to contact the ATS once during that time span, proving that it is powered on and online. This information can be collected and used provide incentives to the end users for keeping their node online and providing its resources to the network. (Although [85] states that the end user’s electricity cost for running the NaDa set-top box would be negligible, it must be assumed that for many users, such incentives will be necessary.) The SuppEncrAlgos field contains a list of encryption algorithms supported by the node, in order of preference. This includes not only information on the algorithm and key length, but also padding and mode of operation for the cipher, such as “AES128, Counter Mode, no padding”. While for performance reasons symmetric encryption is preferred from this point on, there is no real restriction on the algorithms that may be specified here. The same applies to the next field, SuppIAAlgos, which lists the sup- ported integrity and authenticity protection (i.e. MAC or signature) algorithms (such as “HMAC-SHA1”) that the node supports. (However, for reasons of readability and without loss of generality, starting with section 3.4.4, only symmetric encryption and in- tegrity/authenticity protection (Message Authentication Codes, MAC) will be assumed.) To keep the ticket to a reasonable size, it may be desirable to limit the number of entries in these two fields. This could be done by imposing a fixed limit on the number of entries or by defining a maximum desirable size and adjusting the number of entries to stay within this limit. However, care must then be taken in selecting the entries to preserve so that any combination of currently deployed node software versions will always find a common algorithm for encryption and integrity/authenticity protection. This is followed by the EncrAlgo field specifying the encryption algorithm to be used for communication between node and Tracker and EncrKey, giving the key and any other algorithm specific data necessary for encryption that like initialization vectors have to be agreed on beforehand but unlike IVs have to be kept secret. For a symmetric algorithms, this will usually be just the secret key. Again, the IAAlgo and IAkey fields have the same functions as the their Encr* coun- terparts, giving algorithm, key(s) and other data for the integrity and authenticity pro- tection between node and Tracker. If encryption is done using a mode providing au- thenticated encryption with additional data (AEAD), such as CCM [33], GCM [35] or EAX [15], then these fields may be set to indicate no integrity and authenticity protection and an empty key. The last encrypted field in the ticket, CustIDs, contains a list of Customer IDs that may be registered and connected to using this ticket, in other words, the VPNs that the node may join. In order to keep tickets from becoming overly long, a special value should be reserved for “normal” end-user nodes, which may connect to slices of all customers (Just listing the Customer IDs of all Slices the node is currently running would not be

34 3 Concept feasible, as slices may be installed or shut down at any time and this should not require getting a new ticket.), and possibly other situations. For untrusted nodes (see previous section 3.4.2), this field would only contain the ID assigned to the ISP’s software update service. All these fields are encrypted under a key shared between the ATS and the Tracker (or optionally the Tracker’s public key). Their integrity and authenticity are protected by a MAC using a key shared between the ATS and the Tracker (or by a signature using the ATS’ signature key).

3.4.4 Tracker Registration Once a node has received a Tracker Ticket, it can use it to authenticate to and register with a Tracker and thus join the actual network. This happens in two distinct phases: First the node registers itself, then the slices it hosts.

← (1) N → T: TT, E Encr (NodeID, TrackerID, Timestamp, NonceN ), MAC IA (...) KNT KNT ← (2) T → N: E Encr (NonceT ), MAC IA (..., NonceN ) KNT KNT (3) N → T: MAC IA (NonceT ) KNT ← (4) T → N: E Encr (ExpiryTime), MAC IA (...) KNT KNT Protocol 3.3: Node Registration with Tracker

In the first step, the node authenticates to the Tracker and registers itself using pro- tocol 3.3. To do so, it uses the information received from the ATS to contact the assigned Tracker with the Tracker Ticket and its NodeID, the ID of the Tracker, a current timestamp and a fresh random nonce encrypted under the algorithm and key provided by the ATS and followed by a MAC over the entire message, again using the provided algorithm and key. Upon receipt of this message, the Tracker first decrypts the ticket and verifies that

• the TrackerID given by the node matches its own,

• the ticket is being presented inside its validity period, meaning that – the timestamp is earlier that the current time and – the current time is earlier than either the expiry time of the ticket or –if that is used– the timestamp plus the TPW.

• the IP address and port number the message was received from equal the values from the ticket.

It then retrieves from the ticket the algorithms and keys for encryption and in- tegrity/authenticity protection, uses that information to decrypt the message from the node and further verifies that the claimed NodeID matches the NodeID from the ticket,

35 3 Concept the TrackerID given by the node matches its own and the timestamp from the message is current and not earlier than that from the ticket. Now the tracker can create a temporary record for the node, containing the NodeID, expiry time of the record, the node’s IP address and port number, the encryption and MAC algorithms and keys used to communicate with the node, a list of encryption and MAC algorithms supported and a list of the Customer IDs the node may host and contact. It then chooses a nonce of its own and encrypts it. The resulting ciphertext is sent to the node, together with a MAC over both this message and the plaintext of the encrypted nonce received from the node. The node decrypts the nonce from the Tracker and replies with a MAC calculated over it using the shared key. After the Tracker has verified the MAC, it makes the record for this node permanent and concludes the registration by informing the node of its expiry time, again encrypted and protected by a MAC. At this point, node and Tracker are mutually authenticated due to the fact that both sides were able to decrypt and sign the other’s nonce. This means that both are in possession of the keys assigned by the ATS and thus have established a secure communications channel. The node also knows when its registration will expire if it does not retrieve and present a new Tracker Ticket. In the next step, the node registers with the Tracker all slices it is currently hosting. The protocol to do so is shown as protocol 3.4 and can be simpler than the previous one due to the fact that node and Tracker have already authenticated.

(1) N → T: E Encr (Timestamp, NodeID; SliceID1/Customer ID1, SliceIP1, KNT ← Netmask1, Gateway1; . . . ), MAC IA (...) KNT (2) T → N: E Encr (ExpiryTime; SliceID1, SliceIP1, Netmask1, Gateway1; . . . ), KNT ← MAC IA (...) KNT Protocol 3.4: Slice Registration with Tracker

For each slice it wants to register, the node prepares a tuple consisting of four elements: The SliceID, if it is known (either because the slice had already been registered or because this information was included with the slice when it was deployed), or the Customer ID of the customer that owns the slice (and whose VPN it will become part of) otherwise, and the slice’s IP address, netmask and default gateway7 on the VPN, again if they are known already. It then concatenates its NodeID and the slice tuples, encrypts the result, protects it by a MAC and sends it to the Tracker.

7While the netmask and gateway settings of a network interface only affect IP routing at the data link layer [134] (e.g. the destination address of the Ethernet frame an IP packet is transmitted in) and thus have no effect in a VPN working at layer 3, they may influence the expectations of software running in a slice regarding the behaviour of broadcasts.

36 3 Concept

Upon receipt of this message, the Tracker first verifies the currency of the timestamp and that the NodeID given matches the one recorded for the IP address and port number from which it was received, then processes each slice registration: First, the Tracker verifies that the Customer ID of the slice was present in the CustIDs field of the node’s Tracker Ticket, indicating that the node is authorized to host slices of that customer. Then, if all four values are known, it enters the slice into its database, together with the NodeID and registration expiry time of the hosting node. Should the slice already be listed in the database, only its expiry time needs to be updated. (There may however exist customer-specific policies to handle cases where some of the values have changed, for example a known SliceID is being registered with an IP address differing from what is currently recorded. Depending upon the customer’s application, this may be normal behaviour or indication of an intrusion attempt.) If on the other hand not all values are contained in the registration request, the Tracker assigns these (by looking them up in a database, generating them according to a policy provided by the customer, by querying a service provided by the customer or by some other means), then stores the slice information in its database as before. The Tracker then assembles its response message, consisting of the expiry time (which is the same for all slices on a node because the slice registrations expire together with the registration of their hosting node) and, for each registered slice, the SliceID, VPN IP address, netmask and gateway, in the same order as in the registration request message from the node. This message is encrypted, protected with a MAC and sent to the node. The same process is also used by the node to register a new slice that is installed during operation. In this case, only the data for the newly installed slice have to be transmitted to the Tracker, but its registration will still expire together with the others, so it will have to be included in the renewal registration normally. To ensure uninterrupted availability, both the node and slice registration (and conse- quently, Tracker Ticket retrieval) have to be repeated and completed before they expire.

3.4.5 Querying the Tracker Wires can be built between two different kinds of entities: Either they connect two slices communicating through tunneling of encapsulated IP packets, or they are used by the NodeManagement entities on nodes to transfer data, in which case these can be sent over the Wire in the raw or using whatever protocol is agreed on. Additionally, slices can be addressed either by their VPN tag (the Customer ID) and VPN IP address or by their SliceID, resulting in three different variants of the protocol used to query the Tracker for the information needed to establish a Wire (protocols 3.5, 3.6 and 3.7). These are executed both when a new Wire is required or when an existing Wire is about to expire and thus needs to be renewed. The protocol shown as 3.5 is used to request connections to slices based on Customer - ID and the slice’s VPN IP address. This will usually be triggered by a slice sending an IP packet to another slice on its virtual network interface. This packet is then intercepted by the node software. To prevent the software in the slice from spoofing its IP address,

37 3 Concept

← (1) N → T: E Encr (srcSliceID, destCustID, destSliceIP), MAC IA (...) KNT KNT

(2) T → N: E Encr (destSliceID, destNodeID, destSliceIP, destNodeIP, destNodePort, KNT Timestamp, ExpiryTime, EncrAlgo, EncrKey, IA-Algo, IA-Key), PT, ← MAC IA (...) KNT Protocol 3.5: Tracker Query by VPN IP customer policy may require the node to check that the sender address of the packet equals the address assigned to the slice. If no Wire currently exists between the source and destination slice, the node then has to look up the remote node (peer) hosting the destination slice and request a Peer Ticket authorizing the connection and allowing authentication to the peer. This is done using protocol 3.5 by querying the Tracker with the SliceID of the source slice and the Customer ID and VPN IP address of the destination slice, encrypted and protected with a MAC. When the Tracker receives this request, it first verifies that the source and destina- tion slice belong to the same Customer ID to ensure isolation between the VPNs, then examines the record of the originating node to ensure that it is authorized to connect to the requested Customer ID. The destination slice data are looked up next, including the ID of the node it is hosted on (the destination node). Then the Tracker looks up the destination node, again first verifying that it may connect to the source slice (however, if this authorization is already checked at slice registration, this verification should never fail for either node). Next, common algorithms for encryption and integrity/authenticity protection be- tween the nodes are selected based on their database entries –it is assumed that a com- mon algorithm always exists– and keys for these algorithms are generated. The Tracker then needs to determine the validity period for the Peer Ticket to be issued. At first, using an approach analog to the shell model of certificate chain validation [9] (as used for X.509 certificates [23]) would seem sensible. This would mean looking up the expiry time of the registrations of both nodes and using the earlier one as the expiry time of the peer ticket. This would ensure that no node is able to participate in any communication on the network after the Tracker Ticket vouching for the successful remote attestation of its system state to the ATS had expired. It would however require a node nearing this point in time to not only renew its registration with the tracker but to also renew the Peer Tickets for all Wires it currently has open, leading to a high burst load on the Tracker. If the destination node is the one to expire first, it could also lead to a race condition where the source node would try to renew the Peer Ticket before the destination node had renewed its registration and either receive a useless ticket with a very short validity period or even receive the reply that the destination node was not registered. For these reasons, using a fixed validity period for the Peer Ticket is a better solution, even if it increases the time span that a node may participate in the network after its remote attestation to the ATS.

38 3 Concept

Finally, a Peer Ticket (see next section 3.4.6) for the connection is created. After it has completed these steps, the Tracker sends to the requesting node the SlideID and VPN IP address of the destination slice, the NodeID of the node host- ing the destination slice, the IP address and port number of the destination node, a current timestamp and the expiry time of the Peer Ticket, and the encryption and in- tegrity/authenticity protection algorithms and associated keys to be used between the nodes, all encrypted using the key used between Tracker and requesting node. This is followed by the generated Peer Ticket and concluded by a MAC over the entire message. This provides the node with all information and credentials necessary to contact the destination node and connect the slices.

← (1) N → T: E Encr (srcSliceID, destSliceID/destCustID), MAC IA (...) KNT KNT

(2) T → N: E Encr (destSliceID, destNodeID, destSliceIP, destNodeIP, destNodePort, KNT Timestamp, ExpiryTime, EncrAlgo, EncrKey, IA-Algo, IA-Key), PT, ← MAC IA (...) KNT Protocol 3.6: Tracker Query by SliceID

A node may also want to connect two slices using the SliceID for addressing. This might for example happen when a Peer Ticket is about to expire and the node wishes to renew it. The protocol does not change much in this case (as shown as protocol 3.6), the request from the node just contains the SliceID of the destination slice instead of Customer ID and VPN IP address. Alternatively, it may also contain a Customer ID only, the semantic being that the node wishes to connect to a slice belonging to that customer or function that is topologically close to itself, providing a kind of anycast [96] addressing. This could for example be used by newly booted slices for initial peer discovery without requiring predetermined central servers. The actions necessary on the part of the Tracker also do not change, except that it looks up the target slice based on its SliceID instead of Customer ID and VPN IP. If the destination is a Customer ID, the Tracker selects a slice belonging to that customer or function that is hosted in the same region that the originating node belongs to; if no such slice can be found it either replies with a message indicating that the destination was not found or extends the search to neighbouring regions. Research into the customers’ requirements would be necessary to discern which of these alternatives could serve them better.

← (1) N → T: E Encr (destNodeID), MAC IA (...) KNT KNT

(2) T → N: E Encr (destNodeID, destNodeIP, destNodePort, Timestamp, ExpiryTime, KNT ← EncrAlgo, EncrKey, IA-Algo, IA-Key), PT, MAC IA (...) KNT Protocol 3.7: Tracker Query by NodeID

The third addressing mode (protocol 3.7) is used not to connect slices, but to connect

39 3 Concept nodes themselves. In this case, the query from the node contains the NodeID of the destination node. The Tracker now does not need to look up a destination slice, but still has to verify the source node’s authorization to directly connect to other nodes. Any- casting could also be implemented here, but the Customer ID replacing the destination NodeID here would have to belong not to an actual customer, but to a service that is able to communicate on the Wire without using encapsulated IP packets. A typical use case here would be a node wanting to connect to the software update service. The reply message from the tracker has to be changed by removing the destination SliceID, which is now unnecessary, and the destination VPN IP, which is also dispensable because nodes do not possess an IP address in any VPN8. The same changes are made to the Peer Ticket.

3.4.6 Peer Ticket The Peer Ticket is a credential issued to a node by a Tracker and serves both authen- tication and authorization functions when connecting to another node. It is sent to the source node for presentation to the destination node. The structure of a Peer Ticket is given in table 3.2 and consists of the following fields, most of which also appear in the Tracker Ticket: The NodeIDs of both source and destination node, IP address and port number of the source node, a timestamp indicating the creation time of the ticket and thus the beginning of its validity period, the expiry time of the ticket indicating the end of its validity period. The fields giving the algorithms and keys to be used between the peers for encryption and integrity/authenticity protection also follow the same semantics as those in the Tracker Ticket that specify the algorithms and keys used between node and Tracker. This is followed by the SliceID and VPN IP address of the source slice, if this ticket is used to connect two slices. If it does instead authorize communication between the software of the nodes themselves, the source node’s NodeID replaces the SliceID. The last field of the Peer Ticket’s contents holds the SliceID of the destination slice. Again, if the ticket is to be used for node-node communication, the NodeID of the destination node is entered here. All these fields are encrypted using the algorithm and key also used for communication between the Tracker and the destination node. A MAC also using the algorithm and key shared between Tracker and destination node protects the ciphertext from unauthorized modification and ensures the authenticity of the ticket.

8While it would be possible to build an additional VPN for the nodes themselves, this would only add unnecessary TCP/IP overhead to their transmissions. As the nodes need to be aware of the virtual nature of the network they are communicating on anyway, they can transfer their data directly using an appropriate API function.

40 3 Concept

# Name Description 1 srcNodeID ID of the node initiating the communication (source node; the node this ticket is issued to) 2 destNodeID ID of the node the srcNode wants to connect to (destination node; the one this ticket is encrypted to) 3 srcNodeIP IP address of srcNode 4 srcNodePort Port Number of srcNode 5 Timestamp Time this ticket was created 6 ExpiryTime Time when authorization granted by this ticket expires 7 EncrAlgo Algorithm with which the traffic between the nodes is to be en- crypted Encr 8 EncrKey Key data KP eer to be used for encryption 9 IA-Algo Algorithm for integrity and authenticity protection IA 10 IA-Key Key data KP eer to be used for integrity and authenticity protection 11 srcSliceID ID of the Slice wanting to contact the destination slice (source Slice) 12 srcSliceIP VPN IP address of the source Slice 13 destSliceID ID of the Slice that may be contacted using this ticket 14 MAC(Ticket) Integrity and Authenticity protection for this ticket (calculated over ciphertext of fields 1 through 13)

Table 3.2: Peer Ticket. Italicized names indicate encrypted fields.

3.4.7 Connecting Slices After a node has retrieved a Peer Ticket, it can establish a Wire between the source and destination slice or between itself and the destination node.

(1) NS → ND : WireID, PT, E Encr (srcNodeID, srcSliceID, srcSliceIP, destSliceID, KP eer ← destSliceIP, NonceS), MAC IA (...) KP eer ← (2) ND → NS : WireID, E Encr (NonceD), MAC IA (..., NonceS) KP eer KP eer ← (3) NS → ND : WireID, E Encr ([IP Packet]), MAC IA (..., NonceD) KP eer KP eer Protocol 3.8: Wire Setup/Renewal (Slice-Slice Wire)

For slice-to-slice Wires, this is done using the Wire setup protocol 3.8 between the node and the remote node (or peer): First, the node selects a WireID to identify the wire. This value is not relevant to security, but has to be unique between the node and the peer for the lifetime of the Wire. The node then builds a message by concatenating this WireID, the Peer Ticket, the ciphertext of its own NodeID, the SliceID and VPN IP of the source and destination slices and a fresh random nonce under the peer encryption key provided by the Tracker,

41 3 Concept protects it using a MAC and sends it to the peer. Upon receiving this message, the peer first decrypts the Peer Ticket and verifies that it actually is the correct destination node, that the IP address and port number from which the message was received equal the IP and port given in the ticket, and that the current time lies within the ticket’s validity period, as defined by the Timestamp and ExpiryTime fields. It then retrieves the algorithm IDs and keys for encryption and integrity/authenticity protection, verifies the MAC and decrypts the part of the message encrypted by the node. It next checks that the source NodeID, SliceID, IP address and destination SliceID in the message match those from the ticket, that source and destination SliceIDs belong to the same customer and that it is currently hosting a slice with the destination SliceID and VPN IP address. The peer now generates its own fresh random nonce and then creates a reply message consisting of the WireID, its encrypted nonce and a MAC over this message and the node’s decrypted nonce. This message is sent to the node. The node can now ensure that the peer is in possession of the correct encryption and MAC keys (and, by extension, that is was able to decrypt the Peer Ticket encrypted for the intended destination node, thus authenticating itself) by verifying the MAC on the message. It completes the Wire setup by sending a message consisting of the WireID, the ciphertext of an IP packet that may be waiting to be transmitted over this Wire (or nothing if no packet is pending; however, in the case of a newly established slice-to-slice Wire at least the packet that triggered its establishment should always be waiting) and a MAC over this message and the peer’s nonce, thus completing the mutual authentication.

← (1) NS → ND : WireID, PT, E Encr (srcNodeID, destNodeID, NonceS), MAC IA (...) KP eer KP eer ← (2) ND → NS : WireID, E Encr (NonceD), MAC IA (..., NonceS) KP eer KP eer ← (3) NS → ND : WireID, E Encr ([Payload]), MAC IA (..., NonceD) KP eer KP eer Protocol 3.9: Wire Setup/Renewal (Node-Node Wire)

The Wire setup protocol for node-to-node Wires (protocol 3.9) differs from the one just described mainly by replacing the destination SlideID with the NodeID of the peer and omitting the slice IP addresses. The initial message then consists of the WireID, the Peer Ticket and the ciphertext of the source and destination NodeID and the node’s nonce, all protected by a MAC. Consequently, the verification the peer does upon receipt of this message can skip the non-existent slice information. The second message is unchanged from the previous protocol, and in the third step the payload to be encrypted is not an IP packet but any data the NodeManagement may wish to send on the Wire. When the Peer Ticket (and the corresponding Wire with it) is about to expire, the source node needs to decide whether to renew the connection or let it die. This could be done by remembering the time a packet was last sent or received over the Wire and

42 3 Concept renewing it only if it has not been idle for too long. It should be noted that while the Wire itself is bidirectional, it can only be renewed by the source node; however, a peer wishing to force the renewal of a expiring Wire would only have to send a message with an empty payload over it to do so. Renewal of a Wire is effected by retrieving a new Peer Ticket and then re-running the above Wire setup protocol, with the difference that the WireID is already known. However, as soon as the first message of the new Wire setup protocol run is sent or received, both sides have to hold and queue any other traffic on that Wire. This reduces the chance of a message being sent by one node still using the old encryption and MAC keys, but being received by the other only after the negotiation is finished and new keys have been established, resulting in a garbled message being delivered to the slice or NodeManagement if it had not been dropped anyway because the verification of the MAC had failed. Still, as IP packets can be delayed or use different routes, this event cannot be completely prevented without adding more overhead by prepending every message with an indication of which keys have been used in its encryption and protection. But as this occurrence would be relatively rare (because routes usually are stable and thus packets seldom overtake each other) and the possibility of an occasional loss of a packet has to be taken into account by the receiver anyway, adding these bytes to each message (and thus reducing the room available for the payload) seems unnecessary and even counterproductive.

3.4.8 Transferring Data The payload transmitted over a Wire is either an IP packet that was sent by a slice on its virtual network interface or raw data being sent by a node. In either case, the node selects a Wire connecting source and destination (There may be more than one if both sides set one up at the same time. In this case, the Wire with the lowest WireID is used, which will allow the redundant one to expire.), and sends its WireID, the encrypted payload and a MAC over the message to the associated peer (protocol 3.10).

← (1) N1 → N2 : WireID, E Encr (Payload/IP Packet), MAC IA (...) KP eer KP eer

Protocol 3.10: Data Transfer

As the VPN works at the Internet Protocol layer (layer 3), which does not provide reliability [103], no acknowledgement is sent in reply. If an application such as file transfer does require acknowledgements, these must be provided by a higher layer; this is in keeping with the end-to-end argument [117], since for other uses, such as live streaming video, the overhead introduced by detecting and remedying packet loss would be undesirable and even degrade performance. However, customers may still have different requirements as to the security properties provided for their transmitted data. Although they can also be realized at a higher layer, services like timestamping or non-repudiation (provided for example by digital signatures and/or logging, with the node acting as a trusted third party), replay protection or

43 3 Concept ordered delivery (through the use of sequence numbers or rolling nonces) or complication of traffic analysis (by padding and/or dummy messages) could be offered. These could be selected by the entity initiating a Wire through an API call or selection of previously defined DiffServ Codepoints in the DS Field [48,93] (formerly the TOS (type of service) octet [103]) in the header of the first IP packet sent over the Wire. The customer could then be billed according to the resource usage of the selected services. This technique might even be used to disable encryption of the payload; while this would expose the link between the IP addresses of the involved nodes and the VPN IP addresses9 of the involved slices and the transferred data to an eavesdropper, an ISP may choose to allow this (and thus reduce the CPU load on his nodes) if he is ensured that all messages sent between nodes will always only be transmitted on his own network and therefore never be visible to unauthorized parties. However, as the owners of the set-top boxes must be assumed to be able to monitor all traffic being sent and received by their nodes and some of these owners must be assumed to be malicious, this would be limited to a very narrow field of use, unless the lower-layer traffic between the node and its next hop could be encrypted at a significantly lower computational cost (e.g. through hardware assistance). Some applications such as streaming audio and video could also benefit from being able to disable integrity protection: If just a single bit of a message is flipped, error correction mechanisms might be able to mitigate this error more easily than the loss of an entire packet that would occur if the packet were dropped because its MAC verification failed. However, this would also disable authentication, as both of these functions are performed by the MAC. But without authentication, the receiver could be flooded with bogus or malicious data from an attacker, creating a denial of service situation. (If the virtualization technology used for the slices allows the limitation of CPU resources for each slice, the load on the node under such an attack may even be lower without authentication if forwarding the received packets is cheaper than verifying the MAC on each of them. However, it can be hoped that the fact that incoming traffic is checked for authenticity will discourage an adversary from trying such an attack in the first place.) No provision is made for explicitly tearing down an existing Wire, for example if it is no longer needed or one of the nodes is about to shut down. This is not only because a Wire will eventually die anyway when the Peer Ticket authorizing it expires, but also because the effect would often even be detrimental: If a slice tries to send a message on a Wire whose other endpoint is no longer available, the packet will simply get dropped. The slice will notice the lack of a reply, possibly try again, but will eventually give up after a few attempts. Had the Wire been torn down on the other hand, the node hosting the sending slice would intercept the message, see that it had no Wire to the destination and contact the Tracker. There, a lookup of the destination would either show that it is no longer available (Which is the preferable outcome, but still would have required several cryptographic operations both on the part of the node and the Tracker.), or a new Peer Ticket would be created and sent to the

9but not the Customer ID, although this information may be revealed intentionally or unintentionally by the data transferred

44 3 Concept node, which would then also try to make contact, see the attempt time out, retry and give up eventually. Thus, not tearing down the Wire would have caused less load and traffic for both the node and the Tracker, which is the most highly loaded entity in the network anyway. This is even more true for the situation in which the receiver is still available and the Wire would have been torn down for other reasons: Here the difference is that of just sending one more packet down the still-existing Wire or first having to query the Tracker, retrieve a PT and then establish a new Wire. The only situation where the deletion and rebuilding of a Wire would be beneficial is that of the remote node having rebooted and thus lost all previously valid keys and Wire information as well as having received a different IP address. However, if the validity time of the Tracker and Peer Tickets is kept low –around the time required for a shutdown and reboot–, the difference will be negligible.

3.4.9 Deregistration from Tracker Whenever a node shuts down gracefully, for example due to the end user pressing the soft-off button on the set-top box, it first deregisters all the slices it is currently host- ing, then itself. While the registrations would expire anyway at the end of the node’s Tracker Ticket validity –this will still happen if the node ceases operation due to loss of power or connectivity– explicit deregistration avoids unsuccessful connection attempts by other nodes in the meantime, because the Tracker can inform them that the requested destination is no longer available directly upon receiving a query. Additionally, a node will deregister one of its slices if that slice is shut down or removed during normal operation.

← (1) N → T: E Encr (NodeID, Timestamp; SliceID1, . . . ), MAC IA (...) KNT KNT

Protocol 3.11: Slice Deregistration from Tracker

Protocol 3.11 is used to deregister one or more slices from the Tracker. It consists of a single step in which the node encrypts its NodeID and a current timestamp, followed by the SliceIDs of all slices to be deregistered, protects this message with a MAC and sends it to the Tracker. The Tracker then first verifies that the NodeID given matches the IP address and port number from which the message was received, that the timestamp is reasonably current and that the slices given are actually hosted by the sending node and, if these checks were successful, removes the listed slices from its database.

← (1) N → T: E Encr (NodeID), MAC IA (...) KNT KNT

Protocol 3.12: Node Deregistration from Tracker

Deregistration of the node itself is shown in protocol 3.12 and also consists of a single message now only containing the encrypted and MAC protected NodeID of the node

45 3 Concept shutting down. This message causes the Tracker to remove the node from its database (again after matching the NodeID with the source IP address and port number of the message) or at least mark it as being down for a grace period in which a delayed slice deregistration message may still arrive that could not be processed if the database record containing the communications keys had already been deleted. The deregistration messages are not acknowledged by the Tracker for several reasons: In the most common scenario, the node requesting the deregistration is in the process of shutting down and would not receive the acknowledgement anyway. Explicitly waiting for a reply from the Tracker would only delay the process and possibly confuse the user into thinking the keypress had not been registered. Loss of the deregistration message also is not a critical concern, since the registration will eventually expire anyway, as it would if the node had been shut down hard or lost connectivity. Lastly, there is the security concern that an attacker could forge a deregistration message for a slice or node in order to create a denial of service to and from that node until it discovered the malicious deregistration (or its Tracker Ticket expired) and re- registered with the Tracker. However, such an attack would have to be a replay and could thus only work for a slice that had previously been deregistered and then reregistered within the lifetime of the same Tracker Ticket (as renewal of the ticket would invalidate the communication keys and thus cause the replayed message to be discarded by the Tracker), a window of opportunity further reduced by the use of a timestamp in the slice deregistration message. The attack would never be feasible on a node, since enforcement of the Ticket Presentation Window means that a new registration after a deregistration would require the retrieval of a new Tracker Ticket in any case. Alternatively, the attacker would need to know the keys currently used between node and Tracker. This assumption not only exceeds the capabilities of even the commonly used strong Dolev-Yao attacker model [28] but also would invalidate the entire protocol that bases authentication mainly on the knowledge of a shared secret in the form of the encryption and MAC keys.

3.5 Scalability Enhancement

In the following, the scalability of the proposal developed so far will be examined. Table 3.3 lists some of the operations necessary on part of the servers. While these numbers can only be approximations, as they depend not only on the exact implementation but also on other factors (i.e. slice registration requires two database operations, lookup and storage, for each slice processed), they nevertheless provide a starting point for investigation of the load levels being handled by the PCA, ATS and Tracker. Assuming that all types of operations take approximately the same CPU time (since I/O-bound tasks can be executed asynchronously), except for asymmetric private key operations (coCrypt), which take five times as long10, defining this time as one operation equivalent (OE) and further assuming a validity of 24 hours for the Attestation Identity

10Which is a low, but reasonable assumption. [135, 140]

46 3 Concept

Protocol (Server) chCrypt coCrypt DB Msgs 3.1 AIK Certification (PCA) 11 2 3 4 3.2 TT Retrieval (ATS) 10 2 1 4 3.3 Node Registration (Tracker) 9 2 4 3.4 Slice Registration (Tracker) 4 3 2 3.5 Tracker Query (Tracker) 5 4 2 3.11 Slice Deregistration (Tracker) 2 3 1 3.12 Node Deregistration (Tracker) 2 2 1

Table 3.3: Number of server operations in the basic protocol. chCrypt are “cheap” cryp- tographic operations, such as asymmetric encryption and signature verifica- tion, symmetric encryption and hashing. coCrypt are “costly” cryptographic operations such as asymmetric decryption and signing. DB are database op- erations like lookups and Msgs are messages sent or received.

Credential, 120 seconds for the Tracker and Peer Tickets and 20 concurrent Wires per node, the loads on the three servers per second for a network of 10 000 nodes can be approximated as shown in table 3.4.

Server OEs PCA 3 ATS 2000 Tracker 20000

Table 3.4: Approximate number of server operations per second for a network of 10 000 nodes in the basic protocol. OE are operation equivalents as defined in the text.

Even if high performance hardware, such as specialized cryptographic accelerators, allowed 1 OE to equal only 1 µs, it is obvious that the protocols introduced so far will not be able to fulfill the scalability requirement given in section 3.1.7. To solve this problem, several changes are necessary:

The Tracker with its double task of keeping a directory of nodes and slices and medi- ating Wire setups between the nodes handles the highest load by far. As it keeps a high amount of dynamic data, it also does not lend itself well to straightforward replication. Instead, one Tracker is assigned to each Region (or group of Regions, depending on load), responsible only for the nodes belonging to that Region(s). This requires more changes to still make cross-Region communication possible. The Tracker function is subdivided into two services: The Node Tracker (NT), responsible for keeping a database of nodes in one or more Region(s) and introducing them, and the Slice Tracker (ST), which keeps track of the Slices installed on all nodes network-wide. There may again be more than one Slice Tracker, but these are not distinguished by Region, but by customer:

47 3 Concept

A customer with a high number of deployed slices may need an ST of his own, while many customers with only a few slices each can be handled by another one. (As NodeIDs and SliceIDs contain Region information anyway, the separation of Node and Slice Trackers could be prevented by assigning VPN IP addresses in a way that allows the Region a slice belongs to –and therefore the responsible Tracker– to be determined by its IP. This would reduce the complexity of the ISP’s network structure without signifi- cantly increasing, possibly even lowering, the load on the individual Tracker. However, it would restrict the customers’ freedom in assigning IP addresses to slices, which they might want to use to impose a certain structure upon their VPN. If this flexibility is not needed, implementations may for example map IP ranges to Regions and do away with the Slice Tracker.) All these Trackers have to be able to communicate with each other; the layout of this Tracker network can be adapted to the ISP’s network structure and may range from a hierarchical star or tree topology with a Root or Master Tracker at the top to a self-organizing peer-to-peer system.

The Attestation Ticketing Service bears less load than the Tracker and does not need to keep dynamic state about the nodes between attestations; the operation of the network would not be affected even if a node attested to a different ATS each time it needed a new Tracker Ticket. However, as ATS and Node Tracker use symmetric cryptography for performance reasons, simply dispersing as many ATS’ across the network as needed would quickly cause key management to become a problem: Each ATS would require a separate shared secret with each NT. Assigning one ATS to each NT or –for better redundancy and load balancing– a group of ATS’ to a group of NTs solves this problem without incurring a high overhead or having to resort to slower public-key cryptography. As there may now be several ATS’ in the network, there must be a way to distinguish them. Therefore, an AtsID is now necessary, which is also part of the common ID space.

The Privacy CA is not only contacted much more rarely by each node, it also does not exchange messages with any other server. Its only point of contact with the ATS is its distributing certificates for the ATS’ keys to the nodes after having certified their AIKs. It also, like the ATS, does not keep any state about the nodes that would need to be used in a later certification process. Thus, PCAs can be freely dispersed across the network and chosen at will (either randomly or by using some kind of heuristics to find the nearest one) by the nodes to provide redundancy and load balancing. Each does however need a full set of certificates for all the ATS’ keys and a table indicating which ATS’ are assigned to which Regions to refer the nodes to the right one(s). As with the ATS, multiple instances of the PCA in the network necessitate a PcaID to be able to distinguish them where needed. The protocol flows need to be revised to accommodate these changes:

48 3 Concept

3.5.1 AIK Certification As described above, the protocol for retrieval of the Attestation Identity Credential from the PCA requires only a minor change: Since more than one ATS may exist and be responsible for a node’s Region, several certificate pairs may be provided to the node, which can then choose the ATS instance to connect to.

3.5.2 Tracker Ticket Since a Tracker Ticket can now be issued by more than one ATS per Tracker, it is nec- essary to indicate the source of the ticket to allow the recipient to select the correct keys for decryption and integrity and authenticity verification. To this end, an unencrypted but integrity protected field called Issuer is added as the first field in the Tracker Ticket.

3.5.3 Slice Registration The introduction of a separate Tracker for slice information means that some changes are necessary to the process by which nodes register the slices hosted on them. However, having the node register its slices directly with the Slice Tracker would not only require issuing another set of keys to the node, it would also deny the Node Tracker information pertinent to the operation of its Region(s). Therefore, the protocol between node and Node Tracker for slice registration is un- changed, but the process extended by the NT then forwarding the slice information it has learned to the responsible ST, where it is stored until it expires.

3.5.4 Tracker Query Since now there is no longer one Tracker responsible for all nodes and slices, the query process, in which the Tracker provides not only information but also keys and an en- crypted ticket to the requestor, must necessarily become more complex. Every node can only communicate with the Node Tracker responsible for the Region it belongs to (because it shares the required keys only with this NT), but contact between nodes in different Regions must still be possible. When a Node Tracker receives a query for a slice (by SliceID or by CustomerID and VPN IP), it first contacts the Slice Tracker responsible for that customer to learn the NodeID of the node it is hosted on. (This step is obviously not necessary if the request is for a connection to a node.) If this node belongs to one of the Regions it is responsible for, the rest of the protocol can flow as before. If the destination node however belongs to another Region (as discernible from the NodeID), the NT must contact the responsible NT and request not only the node’s database record but also the keys to be used in the communication between the two nodes and a Peer Ticket already encrypted with the key shared between the destination node and its NT11. These are then forwarded to the requesting node, to whom this process is completely transparent. 11As long as this is a relatively rare occurrence, Trackers could use the same query protocol as nodes

49 3 Concept

As the majority of Wires is still assumed to be built between nodes belonging to the same Region (due to the incentives described in section 3.3.6), most connections to the Slice Tracker can be avoided, lowering the load on both NT and ST, by the NT caching information about the slices deployed on the nodes in its Region(s). This would also allow NTs to immediately contact the responsible remote NT for queries by SliceID, where the correct region can be determined directly without going to the ST first to retrieve a slice-node mapping that the remote NT would now also have. Because new entries and updates of these records always happen through the NT, it controls these and therefore the cached data could never become stale. On the other hand, caching node or slice information from other Regions would bring improvements only in the case of several slices from a Region wanting to contact the same out-of-Region slice within the validity time of its registration. In the more common case of a node wanting to maintain a Wire after the Peer Ticket authorizing it has expired, the cached node and slice information would also have expired in the meantime, assuming –as has been done so far– an identical validity time for Tracker and Peer Tickets. But as nodes are expected to make renewal queries by SliceID and not by CustomerID and VPN IP anyway, contacting the Slice Tracker could still be avoided in this case.

do and make the request in the name and on behalf of the querying node. “Tracker Tracker Tickets” could be issued by the Root oder Master Tracker and have a much longer validity time than for nodes, as they would not carry the proof-of-attestation semantic Tracker Tickets do for these.

50 4 Implementation details

The previous chapter provided an abstract, “idealized” description of the proposed pro- tocols suited for description and analysis of their basic principles and properties. How- ever, this level of description is not sufficient to allow interoperable implementations of the concept to be created. This chapter extends the introduced concept by the details needed to actually do so.

4.1 Data Types

The tables describing the Tracker and Peer Tickets use symbols for different data types. These data types and their corresponding symbols are listed in table 4.1.

Symbol Name Description N() Number An unsigned integer number of bytes. O() Octet string An octet string bytes long. O(var) variable Octet string An octet string of variable length. Consists of 2 bytes length specifier, followed by data. BF() Bitfield bytes of one-bit flags L() List Zero or more elements of . Consists of 2 bytes element count, followed by that many in- stances of .

Table 4.1: Data Types

N() and O() are numbers and octet strings comprised of a fixed number of bytes. Their difference is semantic rather than syntactic: Numbers can be used in comparisons and calculations, while octet strings may consist of arbitraty data and are treated as opaque. For example, 64 bit timestamps are N(8) because they can usefully be compared to each other (for example to determine which one represents the earlier point in time) and used in calculations (for example by adding a certain number of seconds), while 128 bit IPv6 addresses are of type O(16). O(var) is an octet string of variable length. It is constructed by prefixing the octet string to be encoded –which may contain leading zero bytes– by a two-byte number giving the number of bytes the original octet string consists of. For example, 0x0000 encodes the empty string, i.e. a string of length zero. BF() denotes a bit field of the given size in bytes. Each bit herein represents a flag with a yes/no or on/off semantic. Bit 0 of a bit field is its least significant bit (LSB).

51 4 Implementation details

L() finally is a variable length list of elements belonging to the data type given the argument. It consists of two bytes giving the number of elements in the list, followed by that many instances of the given type. An empty list of any type is represented as 0x0000.

4.2 Entity Identifiers

As described in section 3.3, most entities are referenced by an identifier that is part of a common ID space. Like the peer id in BitTorrent [22], these identitifiers are 20 bytes (160 bits) long; however, as they are not created at random but issued hierarchically by the ISP, customer or by another entity, they can carry several kinds of information without the risk of collisions.

NodeID composition is shown in table 4.2. It is 20 bytes long, part of the common ID space and begins with a one-byte entity Type of 0x06. This is followed by four bytes giving the number of the Region the node belongs to, two bytes giving the Privacy CA that issued the NodeID and an eight-byte timestamp representing the (approximate) time the ID was issued in milliseconds since 1970-01-01T00:00:00Z. The following byte is reserved for Flags giving information about the node or its ID that is of global interest (None are currently defined, however this byte is reserved for future extensions). Finally, four pseudo-random bytes distinguish NodeIDs issued by one PCA at the same time. (Since the resolution of a PCA’s system timer may not be at millisecond level, this is a possible ocurrence. To prevent the improbable event of NodeID duplication, it is assumed the PCA remembers all random values used for NodeID generation until the timestamp changes.)

# Bits Name Description 1 8 Type 0x06 2 32 Region Region number 3 16 PCA-ID ID of the NaDa Privacy CA that issued this Node ID 4 64 Timestamp When this Node ID was issued 5 8 Flags Currently reserved 6 32 Random Random bits to distiguish Node IDs issued by the same PCA at the same time

Table 4.2: Node ID composition

SliceID (table 4.3) length also is 20 bytes, as SliceIDs also are part of the common ID space. Their first byte of 0x03 gives the entity Type. Four bytes specifying the Region the slice is located in follow, then four more bytes indicating the customer it belongs to. Flags can again be given in the following byte once defined, and finally a ten-byte APP ID issued by the customer provides the actual identification of the slice within his domain.

52 4 Implementation details

# Bits Name Description 1 8 Type 0x03 2 32 Region Region number 3 32 Customer ID ID of the Customer this slice belongs to 4 8 Flags Currently reserved 5 80 APP ID ID of this slice (provided by customer)

Table 4.3: Slice ID composition

CustomerID –as shown in table 4.4– provides wrapping of the Customer ID to fit it into the common ID space, which also fixes its length at 20 bytes. Its leading Type byte is 0x01, followed by four zero bytes, then the actual four-byte Customer ID. The remaining eleven bytes are again mandatorily set to zero. The two most significant bits of the Customer ID carry additional information about the entity described: 00b indicates a regular customer, 10b is used for values carrying a special meaning and ISP-provided services have these bits set to 11b.

# Bits Name Description 1 8 Type 0x01 2 32 Reserved Must be zero 3 32 Customer ID ID of the Customer this slice belongs to 4 88 Reserved Must be zero

Table 4.4: Customer ID composition

RegionID also acts as a wrapper, this time making the Region number part of the common ID space. As shown in table 4.5, it begins with a byte with a value of 0x02, giving the entity Type, followed by the four-byte Region number. It is then padded to the required length of 20 bytes by 15 zero bytes.

# Bits Name Description 1 8 Type 0x02 2 32 Region Region number 3 120 Reserved Must be zero

Table 4.5: Region ID composition

PcaID allows a Privacy CA to be represented within the common ID space, as shown in table 4.6. Its Type byte of 0x04 is followed by four bytes set to zero, then four bytes giving the number assigned to the PCA. 13 more zero bytes bring the PcaID to the required length.

53 4 Implementation details

# Bits Name Description 1 8 Type 0x04 2 32 Reserved Must be zero 3 16 PCA-ID Number assigned to the Privacy CA 3 104 Reserved Must be zero

Table 4.6: PCA ID composition

AtsID identifying an Attestation Ticketing Service instance and TrackerID represent- ing a Tracker are the two remaining members of the common ID space. Their identity type bytes are 0x08 for the AtsID and 0x10 for the TrackerID, with the remaining 19 bytes free for arbitrary assignment by the ISP. The identifiers comprising the common ID space can be differentiated as being ele- mentary IDs on one hand and composite IDs on the other. CustomerID, RegionID and PcaID, as well as AtsID and TrackerID are elementary, as they are independent of any other identitier. On the other hand, NodeID and SliceID incorporate information from other identifiers: The NodeID can be created by bitwise ORing the RegionID of the Region the node belongs to, the PcaID of the Privacy CA that issued the NodeID and the informa- tion controlled by that PCA. For the SliceID, the elements to be ORed are again the RegionID, CustomerID, Flags (shifted to the correct position) and the zero-extended APP ID.

WireID is an identifier that for brevity reasons is not part of the common ID space. Since it needs to be unique only between the two nodes that are the endpoints of the Wire, a node hosts no more than 100 slices (as per section 3.1.7), no more than two Wires can exist between two slices or nodes (and even that only if both sides happen to try and establish one almost simultaneously), and WireIDs are selected by the participating nodes, so the danger of collisions is low, a length of one byte (allowing 256 possible values) is sufficient.

4.3 Algorithm Identifiers

At several points, a concise representation of cryptographic algorithms is required, namely for those providing protection of confidentiality on the one hand and of integrity and authenticity on the other. While object identifiers (OIDs) have been assigned to some algorithms, they are of variable and often high length, making them unsuitable for an environment where potentially long lists may be used which should still be easily parsable. Therefore, own algorithm indentifiers are proposed here.

54 4 Implementation details

4.3.1 Encryption Encryption algorithm identifiers consist of four bytes giving the outer and inner encryp- tion algorithm and key length (This allows for the use of hybrid asymmetric-symmetric encryption, although due to performance reasons this is not further specified in this proposal.), mode of operation and padding for the inner encryption. The two latter parameters are not explicitly given for the outer encryption; however, as that algorithm will usually be used in a key-wrapping mode (such as KEM [124]), it can be assumed that 256 values will still be sufficient to encode algorithm, key length and mode. Where keys need to be transmitted, the data type used is L(O(var)). The list consists of the key data list entries for the outer algorithm, followed by the entries for the inner algorithm (which may in turn be modified or extended by the mode, for example if an au- thenticated encryption mode uses different keys for confidentiality and authentication).

Identifier Algorithm 0x00 No outer encryption 0x80 Rsvd. for RSA (1024) 0x81 Rsvd. for RSA (2048)

Table 4.7: Outer Encryption Algorithm Identifiers

As already stated, no hybrid encryption is defined in this proposal, therefore table 4.7 listing the outer encryption algorithms specifies only the value indicating the fact that no such encryption is used. Since no key is needed, key data consists of the empty list.

Identifier Algorithm Identifier Algorithm 0x00 No inner encryption 0x0C Blowfish/128 [121] 0x01 DES [87] 0x0D Blowfish/192 0x03 3DES (168/192) [11] 0x0E Blowfish/256 0x04 AES128 [88] 0x10 Camellia/128 [6] 0x05 AES192 0x11 Camellia/192 0x06 AES256 0x12 Camellia/256 0x08 Serpent/128 [5] 0x14 SHACAL-2/128 [105] 0x09 Serpent/192 0x15 SHACAL-2/192 0x0A Serpent/256 0x16 SHACAL-2/256

Table 4.8: Inner Encryption Algorithm Identifiers

Table 4.8 lists the currently defined block cipher algorithms and key lengths for the inner symmetric encryption. For no encryption, the key again is represented by the empty list; for all other specified algorithms, the list consists of one element containing an octet string of the required length (192 bit for 3DES).

55 4 Implementation details

Identifier Mode 0x00 ECB [32] 0x01 CBC 0x02 CTR 0x40 Rsvd. for Galois/Counter (GCM) [35] 0x41 Rsvd. for Counter with CBC-MAC (CCM) [33] 0x42 Rsvd. for EAX [15]

Table 4.9: Operation Mode Identifiers

The defined modes of operation are shown in table 4.9. None of the given modes require an addition to the key data list. An initializazion vector (IV) is also not needed for ECB and is therefore set to the empty (i.e. zero length) octet string. For CBC, the IV length needs to equal the block size of the block cipher used; the same also applies to the initial counter block of the CTR mode, which is then incremented for each successive block of the same message.

Identifier Padding 0x00 No padding 0x01 PKCS#5 padding [63]

Table 4.10: Padding Method Identifiers

Only two padding schemes are currently specified, as shown in table 4.10. The use of an entire byte for storing so few values may seem wasteful and indeed, mode and padding information could currently be combined into one byte by using one nibble (allowing 16 values) for each. However, the design chosen here allows for higher extensibility and provides modularity by clearly separating the different sub-parts of the identifier.

4.3.2 Integrity and Authenticity Protection Algorithms providing protection against forgery and manipulation can by seperated into two classes: Symmetric message authentication code (MAC) algorithms on one hand and asymmetric digital signature algorithms on the other. Both use a compression function –either a hash function or a symmetric encryption algorithm employed in a suitable mode of operation– to reduce the input data, which may be of arbitrary length, to the size of the function’s output [130]. Each of these sub-functions is specified by one byte, giving a total length of two bytes for the integrity and authenticity protection algorithm identifier. The values for the first byte, giving the MAC or signature algorithm used, are listed in table 4.11, while table 4.12 lists the identifier bytes for the compression function, incor- porating values for symmetric encryption algorithms from table 4.8 for MAC algorithms such as CMAC that use such a function for compression.

56 4 Implementation details

Identifier Compression Function Identifier I/A Algorithm 0x00 None 0x00 None 0x01– Symmetric encryption 0x01 HMAC [69,89] 0x79 algorithms from table 4.8 0x02 HMAC-96 0x81 SHA-1 [90] 0x11 CMAC [34] 0x83 SHA-256 0x80 Rsvd. for RSA Signature 0x85 SHA-512 (1024) 0x93 SHA-3/256 [16] 0x81 Rsvd. for RSA Signature 0x95 SHA-3/512 (2048) 0xA5 Whirlpool [12, 105] Table 4.11: Integrity/Authenticity Table 4.12: Compression Function Algorithm

For HMAC and HMAC-961, the key list consists of one element containing the secret key as an octet string. This may be of any length, but should match the block size of the underlying hash function. Likewise, the length of the output MAC value is that of the hash function, while for HMAC-96 the output is truncated to 96 bits as described in [69]. In contrast, the key list entries for CMAC are that for the encryption function used, while the output size equals its block size. Since the length of the output is fixed for these algorithms, messages so protected do not contain length information as part of the MAC value to save space. This may be different for other MAC or signature functions, which is why the Tracker and Peer Ticket always use the O(var) data type –which includes two byte length specifier– for storing this value. Not all possible combinations (such as 0x11A5: CMAC with Whirlpool as a compres- sion function, meaning no key would be used at all) do make sense; it is the responsibility of the implementor to report and use only those that are semantically valid. This applies to both encryption and integrity/authenticity protection algorithm identifiers, as well as the combination of these (for example, no explicit integrity/authenticity protection is needed if and only if an authenticated encryption with additional data (AEAD) mode is used).

4.4 Changes

In the following section, several additions are made to the protocol flows established so far. These changes do not introduce new or different functionality, but are necessary mostly to facilitate the parsing of received messages. They generally fall in one of these categories:

1Used to construct truncated-output MACs [69] such as HMAC-SHA-1-96, which would have the ID 0x0281. Note that the truncation is a function of the MAC, not the hash algorithm – only the end result of the computation is truncated.

57 4 Implementation details

Message Type: To detect loss, duplication and out-of-order reception of messages (which could also include replay attacks) and allow distiction of messages for easier parsing, each message is prepended with a one-byte Message Type identifier2. Message Type octets consist of two parts: The three highest order bits (bits 7–5) indicate the protocol the message belongs to, while the other five bits (4–0) indicate the message type within that protocol. (Where possible, bit 4 is used to indicate a message sent due to an error condition.)

Consistent Formats: To reduce the number of message types and thus again facilitate parsing, messages with similar semantics that also can be sent at the same point in the flow of a protocol are given an identical structure. This may require adding “dummy” fields which carry no information, but still improves performance by requiring fewer distinctions to be made when processing the messages. Also, for consistency with TCG use, all nonces are 20 bytes (160 bits) long.

Version: Since it is impossible to update the software on all deployed nodes at the same time, the situation may arise that nodes and servers speaking different protocol versions with different message structures are operating in the network concurrently. To allow these entities to still communicate, every protocol allows the negotiation of a common version – or at least the conveyance of the information that the version a node is using is no longer considered secure and a software update is necessary. It is however assumed that new node software versions will be able to also speak at least the last one or two protocol versions, unless these are considered to be insecure, and that PCA, ATS and Update Tracker will speak all protocol versions that could still reasonably be expected to exist in the network, as long as no flaw is discovered that makes it absolutely necessary to withdraw one3. It is also assumed that these servers, which are relatively low in number and are under direct control of the ISP, will always be updated to a new software version before that version is made available to nodes. The protocol version to be used is determined by the node initiating the communica- tion and indicated as the first field (after the message type) of the first message sent. This will usually be the highest version supported by that node, but may be a lower one if the node has already had previous contact with the other node and has learnt that it only supports a lower one. If the remote side supports the selected protocol version, the protocol continues as designed, with the reply containing the highest version the entity supports. This serves two purposes: Firstly, it allows information about availability of a new software version to be gossipped among nodes, reducing the number of unnecessary connections to the update service while still ensuring that nodes can learn of available updates quickly. Secondly, a node that has remembered another node only supporting a lower version than itself can learn when that node has updated its software.

2This concept is called “MessageID” in BitTorrent [53], however that term is traditionally used for a unique identifier allowing distinction of individual messages of the same type [94, 110]. 3This is because without a way to contact even an Update Tracker, a node that has not been online for an extended period of time would have to be manually updated by its end user.

58 4 Implementation details

If the remote side does however not support the selected protocol version, because it is either too new, too old or known to be vulnerable, it replies with an error message containing the type of the message that triggered the reply and a list of supported protocol versions. However, as the receiver was not able to parse the message it got and therefore was not able to retrieve the algorithm and key to use, this error message cannot be authenticity protected. This means that the initiating node cannot be certain that it was not sent by a malicious third party trying to prevent the connection from being established; therefore it must still wait for a possible proper (and authenticated) reply, especially if no alternative protocol version is available. Version information currently consists of one byte interpreted as an unsigned integer. Should version 0xFE ever be reached, it is suggested that the next version set the version byte to 0xFF and add one or more byte(s) giving further version information. While wasteful by using a full byte to transmit just one bit of information, this would allow older software versions to correctly determine that the remote side is using a newer protocol version that they cannot understand.

Initialization Vector (IV): Most cipher modes of operation, such as Cipher Block Chaining (CBC) or Counter mode (CTR) use an IV or initial counter block (nonce) [32], which must be transmitted together with the ciphertext. To this end, it is prefixed with one byte of length information and then prepended to the ciphertext. For modes not using an IV, it is left empty (i.e. its length it set to zero), but not omitted altogether.

Length information: While the Transmission Control Protocol (TCP) [104] provides protection against loss, duplication and out-of-order delivery of underlying IP packets, it –being a stream protocol– does not preserve message boundaries [128]. Measures against this problem have been suggested [119], but not been incorporated into the protocol. Since all protocols proposed in this thesis are message-based, those that are conducted using TCP therefore need to have length information added to them. It consists of a two-byte unsigned integer and indicates the number of bytes following itself that still belong to the message. (This means that a message ending directly after the length information would have these two bytes set to 0x0000.) Length information also facilitates parsing of encrypted parts of messages, which may be of variable length and by design do not exhibit any structure that may indicate their size. It is therefore prepended to each IV/ciphertext block with the same semantics as for messages, i.e. two bytes giving the number of bytes to read until the end of the ciphertext is reached (including the IV and its length byte).

4.5 Protocol Flow

The changes described in the previous section are now applied to the protocols developed in the previous chapter. The following notational details are used: “External” IP addresses (i.e. addresses not inside a VPN) are always expressed in 128 bit IPv6 notation. If IPv4 is still used on the network, then these addresses are ex-

59 4 Implementation details pressed as IPv4-mapped IPv6 addresses [56](::FFFF:a.b.c.d). Inside the VPNs, IPv4 is used. This provides ample address space even for the projected maximum scenario while requiring only 4 bytes storage space per address in messages. As described above, ciphertext is always prepended with length information and an IV. For better readability, these fields are not explicitly included in the protocol listings. Therefore, EK (. . . ) is to be read as Length, IV-Length, IV, EK (...) where it appears. The Object Identifiers (OIDs) needed in certificates are taken from the tentative arc id-nv ::= { joint-iso-itu-t(2) uuid(25) (185057635718266902296576886847292425499) }.

4.5.1 AIK Certification As the Privacy CA is relatively lightly loaded, the protocol for certification of Attestation Identity Keys runs over TCP. This provides the convenient notion of a bidirectional data stream between the endpoints, thus allows the mapping of messages from different nodes to their responsible server thread. The protocol is given the number 1, thus its messages are numbered 0x21–0x24. It is shown as protocol 4.1.

(1) N → PCA : 0x21, Version, Length, IdReq

(2) PCA → N: 0x22, HighestVersion, EEKPUB(Hash(AIKPUB), Nonce) (3) N → PCA : 0x23, Length, Hash(AIKPUB, Nonce)

AT S1 AT S1 (4) PCA → N: 0x24, EEKPUB(AIC, Cert(KP ubE ), Cert(KP ubS ), . . . ) Protocol 4.1: AIK Certification

Version negotiation as described in section 4.4 happens in messages 0x21 and 0x22. Length information is added to all messages, however as messages 0x22 (aside from the version number) and 0x24 consist only of ciphertext, which always has its length prefixed, no additional explicit length field is needed. The hash algorithm to be used is assumed to be stored in the node software together with the public encryption key of the PCA that is used to create the identity request package IdReq. In message 0x24, the certificate list may also contain certificates of intermediate CAs neccessary to build a certificate path from the trust anchor contained in the node software to the certificate of one or more ATS’. As all entities are however under the control of one ISP, these intermediates should usually be already known to the node.

Attestation Identity Credential The Attestation Identity Credential AIC issued is an X.509/PKIX certificate [23] as described in [148], intended for consumption by the Attestation Ticketing Service only. It contains some application specific extensions (as permitted by [144]):

60 4 Implementation details

• Its Extended Key Usage extension is set to contain an identifier stating the AIK’s purpose as “NaDa Tracker Ticket Retrieval” (OID: ttretr ::= { id-nv eku(37) 1 }) only. The extension is marked as critical. This helps prevent masquerading attacks by ensuring that this AIK is only ever used in the Tracker Ticket retrieval protocol, as implementations of other protocols will not understand this extension value.

• The assigned NodeID is stored in the Subject Alternative Name extension in an otherName field. Its type is set to “NodeID” (OID: nodeid ::= { id-nv san(17) 1 }) and its value to the NodeID represented as an octet string of 20 bytes length.

• Finally, the Subject Directory Attributes extension contains a “Node Type” at- tribute with a type of nodetype ::= { id-nv sda(9) 1 } and a value consisting of an octet string with a length of 20 bytes (or multiples thereof) containing the Cus- tomerID in the case of a customer node or special values as used in the Tracker Ticket for regular (end user) or ISP nodes.

The node’s IP address is not added to the credential, as it may change within the validity time of the certificate. This prevents the node from having to renew the AIC if it is disconnected from the internet, while not adding a security risk: The semantic of the AIC is only the certification of the binding between the NodeID, the AIK and the TPM, which will not be affected by an IP address change. The AIC is only kept in the node’s RAM, so there is no danger of an accidential mismatch between the Region ID stored in the NodeID and the node’s actual IP address – moving a set-top box would (usually) require powering it off, erasing the old credential. As the ATS verifies that the node’s IP address matches its Region, an attempt to gain any advantage by somehow moving a node while retaining its old NodeID would still be thwarted.

ATS Certificates To convey information about the Attestation Ticketing Services to the node, the cer- tificates for their encryption keys sent by the PCA also use some application specific extensions:

• The Subject Alternative Name extension contains a URL giving the IP address and port number4 of the respective ATS using the scheme name nttr (for “NaDa Tracker Ticket Retrieval”). Its host subcomponent is either an IPv4 address expressed as a dotted quad or an IPv6 address in square brackets; DNS names are not used to prevent possible attacks using that vector. The use of a URL has the advantage of allowing IP address and port to be given in one extension; otherwise the port number could not be conveyed within the standard certificate extensions and would require defining another private one. Its disadvantage is the necessity to register (or use without registration) a URI scheme

4This means that no default port is required, although it may be desirable to define one for adminis- trative and policy reasons.

61 4 Implementation details

name for this very narrow field of use – however, as this field is so closely defined, even a scheme name collision should not cause any problems.

• The symmetric encryption and hash algorithms supported by the ATS are given in the Subject Directory Attributes extension in two attributes: – The symmetric encryption algorithms are given in order of preference as one or more four-byte algorithm IDs as listed in section 4.3.1 with the attribute type set to encralgo ::= { id-nv sda(9) 11 }. – Creation of the External Data nonce for the Quote operation requires a hash function with an output of 160 bits length. It is assumed that this will usually be SHA-1 because this is the digest algorithm chosen by the Trusted Computing Group for use in TPM operations. Should the existing attacks on SHA-1 [133] however be improved upon enough to yield a feasible practical attack, replacement by another function, such as a truncated SHA-3, would become necessary5. To allow this, a list of the supported hash functions with an output length suited for producing the Quote nonce is stored in a second attribute with the type OID quotehash ::= { id-nv sda(9) 13 }, expressed as two-byte in- tegrity/authenticity protection algorithm identifiers as defined in section 4.3.2, with the first byte usually set to 0x00. To provide an automatic upgrade path for nodes with outdated software versions, a special “Update ATS” could be set up which specifically advertises support only for those algorithms that are no longer supported and only issues tickets authorizing connections to the Update Tracker. Nodes that do not support any of the algorithms used by the regular ATS’ would then automatically select the Update ATS to connect to, while those with obsolescent software versions allowing both supported and unsupported algorithms may also connect to a regular ATS and be referred to the Update Tracker from there if necessary.

No special extensions are added to the ATS signing key certificate.

4.5.2 Attestation and Tracker Ticket Retrieval Before retrieving a Tracker Ticket, a node first has to select the ATS to connect to from the certificate pairs it received from the PCA. If corresponding data is available, some heuristics could be used to find the topologically closest one, but as the traffic between node and ATS is of negligible volume, one could just be chosen at random. The node then has to check whether it supports at least one of the algorithms offered by the ATS for encryption and 160 bit hashing respectively, as well as the signature algorithm

5Although with the current TCG specifications, the integrity of the Stored Measurement Log would no longer be ensured by the Platform Configuration Registers in this case, invalidating the entire Quote operation.

62 4 Implementation details from the respective certificate; this is done by traversing each list and selecting the first algorithm supported by the node. The protocol itself (shown as protocol 4.2) is assigned the number 2 and uses the message types 0x41–0x44. It uses TCP and therefore needs message length information for the messages 0x41 and 0x44, while 0x42 and 0x43 consist only of a single ciphertext block (except for the HighestVersion field) and therefore need no additional explicit length field.

(1) N → ATS : 0x41, Version, Length, EncrAlgo, Hash160Algo, E P ubE (KSess), KAT S

EKSess (Timestamp, AIC, EncrAlgoList, IA-AlgoList) (= M1)

(2) ATS → N: 0x42, HighestVersion, EKSess (Nonce)

(3) N → ATS : 0x43, EKSess (Quote(Hash160(Nonce, M1)), SML)

(4) ATS → N: 0x44, Length, EKSess (TrackerID, TrackerIP, TrackerPort, Flags, Timestamp, ExpiryTime, EncrAlgo, EncrKey, IA-Algo, IA-Key, CustIDs), ← TT, Sig P rivS (...) KAT S Protocol 4.2: Tracker Ticket Retrieval

In message 0x41, the Hash160Algo field contains a value from the identifier list for integrity protection algorithms taken from the ATS encryption certificate. The EncrAlgoList and IA-AlgoList fields in message 0x44 are of type L(O(4)) and L(O(2)) respectively, i.e. their entries are preceded by a two-byte value giving the entry count. The one-byte Flags field allows additional information about the assigned Tracker to be given to the node. Bit 0, if set, indicates that the Tracker will only supply software updates. CustIDs contains a list of type L(O(20)) giving the CustomerIDs the node may attempt to connect to; details are given in the following section about the Tracker Ticket. The node has to verify whether this field contains only the ID of the software update service, which would indicate that its software is outdated and needs to be updated before it can join the regular network again, even if the assigned Tracker is not an Update Tracker.

4.5.3 Tracker Ticket Just like the protocol messages, the Tracker Ticket also receives version and length information for easier parsing. Table 4.13 shows the new composition and also gives the data types for its fields. Most of the ticket is encrypted using an algorithm and key previously established between the ATS and NT. The initialization vector used in this encryption is given in the IV field. As the size overhead is not critical here, the O(var) data type with two length bytes is used instead of the usual IV format for consistency and to facilitate parsing.

63 4 Implementation details

# Type Name Description 1 N(1) Version Version number of ticket (not encrypted) 2 O(20) Issuer ID of the ATS that issued this ticket (not encrypted) 3 N(2) CipherLength Size of IV and ciphertext in bytes (not encrypted) 4 O(var) IV Initialization vector or nonce for the following ciphertext (not encrypted) 5 O(20) NodeID ID of the node this ticket is issued to 6 O(20) TrackerID ID of the tracker that can be accessed with this ticket 7 O(16) NodeIP IPv6 address of the node 8 N(2) NodePort Port number of the node 9 BF(2) Flags Currently reserved 10 N(8) Timestamp Time (in ms since 1970-01-01T00:00:00Z) this ticket was cre- ated 11 N(8) ExpiryTime Time when authorizations granted by this ticket expire 12 L(O(4)) SuppEncrAlgos List of Encryption algorithms supported by node (in order of preference) 13 L(O(2)) SuppIA-Algos List of integrity/authenticity protection algorithms sup- ported by node (in order of preference) 14 O(4) EncrAlgo Algorithm with which the traffic between node and tracker is to be encrypted Encr 15 L(O(var)) EncrKey Key data KNT to be used for encryption 16 O(2) IA-Algo Algorithm for integrity and authenticity protection between node and tracker IA 17 L(O(var)) IA-Key Key data KNT to be used for integrity and authenticity pro- tection 18 L(O(20)) CustIDs List of CustomerIDs that may be contacted using this ticket 19 O(var) Sig/MAC(Ticket) Integrity and Authenticity protection for this ticket (calcu- lated over plaintext of fields 1 through 4 and ciphertext of fields 5 through 18) (not encrypted)

Table 4.13: Tracker Ticket. Italicized names indicate encrypted fields.

A Flags field is also added to allow information to be conveyed from the ATS to the Tracker. This field is closely related, though not necessarily identical, to its counterpart in message 0x44 of protocol 4.2. Lists are used for the EncrKey and IA-Key fields to allow for modes or algorithms that use multiple keys or keys which consist of multiple parts. The list of CustIDs may either contain one or more regular CustomerIDs, the ID of the software update service or special values. A CustomerID with its inlying Customer ID set to 0x80000001 identifies a regular end-user node which may connect to all customer slices (if it is hosting a slice of that customer) and services, while 0xBFFFFFFF indicates that the node presenting this ticket is being operated directly by the ISP and may additionally connect to the administrative functions of other nodes.

64 4 Implementation details

4.5.4 Tracker Registration As the (Node) Tracker is very highly loaded, all communication between it and the nodes is done via UDP, which reduces the operating system overhead for managing connections. It also removes the necessity of adding message length information. However, as the port number is part of the Tracker Ticket and is used for authentication, the local UDP port used by the node must have the same port number as the TCP port used for contacting the ATS. The protocol number for both node and slice registration is 3, leading to message types 0x61–0x64 for the former (protocol 4.3) and 0x65 and 0x66 for the latter (protocol 4.4).

(1) N → T: 0x61, Version, TT, E Encr (NodeID, TrackerID, Timestamp, NonceN ), KNT ← MAC IA (...) KNT ← (2) T → N: 0x62, HighestVersion, E Encr (NonceT ), MAC IA (..., NonceN ) KNT KNT ← (3) N → T: 0x63, MAC IA (..., NonceT ) KNT ← (4) T → N: 0x64, E Encr (ExpiryTime, Flags), MAC IA (...) KNT KNT Protocol 4.3: Node Registration with Tracker

Version negotiation is done only during registration of the node; the Tracker remem- bers the protocol version used for all following exchanges, including queries and dereg- istration. The final message of the node registration protocol (0x64) is extended by an encrypted field called Flags which allows the Tracker to return to the node information pertinent to the registration process or further communications. The field is currently defined to be one byte long, but could easily be extended without even changing the protocol version number, should that be needed. Older implementations would then just discard bytes following those whose meaning they understand. Currently, one flag meaning is defined: Bit 0 (of the first byte if there are more) is set to 1 if the Tracker already has that node registered (i.e. to indicate a re-registration) and to 0 if the Tracker does not currently have a record for that node. This allows a re-registering node to ascertain whether it has started its re-registration process too late and adjust its timers accordingly.

(1) N → T: 0x65, E Encr (Timestamp, NodeID; SliceID1/Customer ID1, SliceIP1, KNT ← Netmask1, Gateway1, Flags1; . . . ), MAC IA (...) KNT (2) T → N: 0x66, E Encr (ExpiryTime; SliceID1, SliceIP1, Netmask1, Gateway1, KNT ← Flags1; . . . ), MAC IA (...) KNT Protocol 4.4: Slice Registration with Tracker

65 4 Implementation details

The slice registration protocol is also extended by a one-byte Flags field for each slice to be registered. In the reply, bit 0 has the same meaning as in the node registration protocol: It is set to 0 for new registrations and to 1 for re-registrations. It should also be noted that for a node with many slices, the size of the registration message might grow beyond that supported by the network. In this case, the slices to be registered can be split up into two or more such messages; as an extreme case, it would even be possible to send one registration message per slice, but this puts an unnecessary load on the Tracker and should thus be avoided. As the NodeID is not repeated in the registration reply, type 0x66 messages will always be smaller than the registration messages that triggered them, so no special precautions against the size problem are needed here.

4.5.5 Querying the Tracker The three protocol versions for Tracker queries also use UDP and require neither message length information nor version negotiation, as explained. However, as formats differ for queries based on VPN IP address and on SliceID or NodeID, a new QueryType field is added, with a value of 0x01 for IP-queries and 0x02 for ID-based ones. This differentiates not only the query, but also the reply messages, which share the message type bytes 0x81 and 0x82 for all three variants.

← (1) N → T: 0x81, E Encr (0x01, srcSliceID, destCustID, destSliceIP), MAC IA (...) KNT KNT

(2) T → N: 0x82, E Encr (destSliceID, destNodeID, destSliceIP, destNodeIP, KNT destNodePort, Flags, Timestamp, ExpiryTime, EncrAlgo, EncrKey, ← IA-Algo, IA-Key), PT, MAC IA (...) KNT Protocol 4.5: Tracker Query by VPN IP

The IP-based query is now shown as protocol 4.5. It differs from its conceptual counterpart by the addition of the mentioned QueryType value of 0x01 and, again, one byte of reply Flags for future extension.

(1) N → T: 0x81, E Encr (0x02, srcSliceID, destSliceID/destCustID, Flags), KNT ← MAC IA (...) KNT

(2) T → N: 0x82, E Encr (destSliceID, destNodeID, destSliceIP, destNodeIP, KNT destNodePort, Flags, Timestamp, ExpiryTime, EncrAlgo, EncrKey, ← IA-Algo, IA-Key), PT, MAC IA (...) KNT Protocol 4.6: Tracker Query by SliceID

In the query by SliceID (protocol 4.6), the QueryType is set to 0x02, and another Flags byte is added. In queries which use a CustomerID to achieve an Anycast-like service, its bit 0 indicates whether the Tracker is to reply with an error message (value 0) or extend

66 4 Implementation details its search to neighbouring Regions (value 1) if no match is found within the querying node’s own region. The Flags field in the reply is again reserved for future use.

← (1) N → T: 0x81, E Encr (0x02, srcNodeID, destNodeID, Flags), MAC IA (...) KNT KNT

(2) T → N: 0x82, E Encr (destNodeID, destNodeID, all-zeroes, destNodeIP, KNT destNodePort, Flags, Timestamp, ExpiryTime, EncrAlgo, EncrKey, ← IA-Algo, IA-Key), PT, MAC IA (...) KNT Protocol 4.7: Tracker Query by NodeID

The NodeID query message in protocol 4.7 retains the Flags field only to achieve a syntax consistent with its counterpart from the previous variant, with which it shares the ID-query type of 0x02. The same argument applies to the reply message, whose first encrypted field now con- tains the destination NodeID that was being queried, even though this is doubled in the following field. Since nodes do not possess their own VPN IP address, the corresponding field is set to an all-zeroes value.

4.5.6 Peer Ticket Table 4.14 shows the Peer Ticket composition with the data types of its fields. The version number entered in the Version field depends not on the protocol version used with the originating node, but on the destination. While the Tracker knows the protocol versions it has negotiated with both nodes, it does not necessarily know which other versions are also supported; therefore, it cannot foresee or even dictate the protocol version to be used between the two peers. Instead, the Peer Ticket is viewed as part of the communications between the Tracker and the destination node, meaning that the version of the ticket will be that used between the Tracker and the destination node. This will not be a problem if the destination uses a lower software version than the originator: In this case, the peers will probably negotiate that protocol version for use between them (unless they cannot find a common version at all). On the other hand, if the destination receiving the ticket uses a newer version than the originator, the ticket will have a higher version than the protocol finally employed. This means that new protocol versions must be downward compatible in the sense that they do not remove fields or information from the Peer Ticket that was present in previous versions.

4.5.7 Connecting Slices The two versions of the protocol for Wire setup and renewal use the protocol number 5, their messages are numbered 0xA1–0xA3. The transport protocol used is UDP and again, as the local port from which the node made the connection to the Tracker is part of the Peer Ticket, the node must use the same local port to connect to the peer.

67 4 Implementation details

# Type Name Description 1 N(1) Version Version number of ticket (not encrypted) 2 N(2) CipherLength Size of IV and ciphertext in bytes (not encrypted) 3 O(var) IV Initialization vector or nonce for the following ciphertext (not encrypted) 4 O(20) srcNodeID ID of the node initiating the communication (source node; the node this ticket is issued to) 5 O(20) destNodeID ID of the node that srcNode wants to connect to (destination node; the one this ticket is encrypted to) 6 O(16) srcNodeIP IPv6 address of srcNode 7 N(2) srcNodePort Port Number of srcNode 8 O(20) srcSliceID ID of the Slice wanting to contact the destination slice 9 O(4) srcSliceIP VPN IP address of the source slice 10 O(20) destSliceID ID of the Slice that may be contacted using this ticket 11 BF(2) Flags Currently reserved 12 N(8) Timestamp Time (in ms since 1970-01-01T00:00:00Z) this ticket was cre- ated 13 N(8) ExpiryTime Time when authorization granted by this ticket expires 14 O(4) EncrAlgo Algorithm with which the traffic between the nodes is to be encrypted Encr 15 L(O(var)) EncrKey Key data KP eer to be used for encryption 16 O(2) IA-Algo Algorithm for integrity and authenticity protection IA 17 L(O(var)) IA-Key Key data KP eer to be used for integrity and authenticity protection 18 O(var) MAC(Ticket) Integrity and Authenticity protection for this ticket (calcu- lated over plaintext of fields 1 through 3 and ciphertext of fields 4 through 17) (not encrypted)

Table 4.14: Peer Ticket. Italicized names indicate encrypted fields.

Protocol 4.8 is used for setting up or renewing a Wire between two slices. The only differences to its conceptual version are the addition of message type numbers and version negotiation. To prevent collisions of the short one-byte WireIDs in case two nodes attept to estab- lish Wires with each other concurrently, the originating node uses an odd WireID if its NodeID is lower than that of the destination node and an even one otherwise. If no IP packet is pending, then the ciphertext (including length information and IV) of the empty string is sent in message 0xA3. Wires between two nodes are set up and renewed using protocol 4.9. While again maintaining the same message structure, it differs from the previous variant by replacing all SliceIDs by NodeIDs and setting all slice VPN IP addresses to all-zeroes values.

68 4 Implementation details

(1) NS → ND : 0xA1, Version, WireID, PT, E Encr (srcNodeID, srcSliceID, srcSliceIP, KP eer ← destSliceID, destSliceIP, NonceS), MAC IA (...) KP eer ← (2) ND → NS : 0xA2, HighestVersion, WireID, E Encr (NonceD), MAC IA (..., NonceS) KP eer KP eer ← (3) NS → ND : 0xA3, WireID, E Encr ([IP Packet]), MAC IA (..., NonceD) KP eer KP eer Protocol 4.8: Wire Setup/Renewal (Slice-Slice Wire)

(1) NS → ND : 0xA1, Version, WireID, PT, E Encr (srcNodeID, srcNodeID, all-zeroes, KP eer ← destNodeID, all-zeroes, NonceS), MAC IA (...) KP eer ← (2) ND → NS : 0xA2, HighestVersion, WireID, E Encr (NonceD), MAC IA (..., NonceS) KP eer KP eer ← (3) NS → ND : 0xA3, WireID, E Encr ([Payload]), MAC IA (..., NonceD) KP eer KP eer Protocol 4.9: Wire Setup/Renewal (Node-Node Wire)

4.5.8 Transferring Data Wire data transfer (protocol 4.10) shares with the Wire setup protocol the number 5 und uses the message type 0xAF for its only message.

← (1) N1 → N2 : 0xAF, WireID, E Encr (Payload/IP Packet), MAC IA (...) KP eer KP eer

Protocol 4.10: Data Transfer

It can be assumed that a high amount of data will be transferred over a wire, meaning that the three-way handshake connection setup, state keeping and slow start required for TCP could be offset by the loss and duplicate prevention, ordering and flow and congestion control it provides. However, towards the slice the Wire looks like a regular layer 3 IP link supporting any higher-layer protocol, meaning that it is probable that TCP will be used for bulk transfers such as those done using the BitTorrent protocol6. This would be problematic if TCP were also used for the Wire itself, as its mechanisms providing these desirable properties can lead to high delays and reduced goodput if two instances of TCP are stacked on top of each other (TCP over TCP) which are not well tuned to each other [58], especially if the latency of the link is low, as will usually be the case for intra-Region Wires. Additionally, as explained in section 3.4.8, the provision of these properties may be contrary to the requirements of the customer application. For example, real-time au- dio/video streams such as video telephony are usually designed to be robust against occasional packet loss or unordered delivery, while they would suffer visible drop-outs if an underlying protocol withheld already received packets from the application to ensure

6Although it would be possible to supply customers with a BitTorrent variant using UDP through an application slice if that were to only significant problem.

69 4 Implementation details that data are passed to it in the order in which they were sent. For these reasons, UDP is used as the transport layer protocol for transferring Wire payload messages. This means that properties like those mentioned before must be ensured by the software running in the slices if they are desired (or, in the case of congestion control, fundamental to the functioning of the network), either by using a layer 4 protocol such as TCP on top of the layer 3 interface provided by the Wire or by implementing them in the application layer protocols used by the software running in the slice. Due to the overhead introduced by the Wire data transfer protocol, the MTU of the slices’ virtual network interface needs to be reduced (or respective ICMP messages created by the node and sent to the slice) to prevent the Wire messages from exeeding the Path MTU between the nodes and thus needing to be fragmented, which would reduce efficiency. For a cipher with a block size of 128 bit in a mode requiring an IV and a MAC algorithm with an output value size of 256 bits, the overall overhead consists of one byte message type, one byte WireID, two bytes ciphertext length, one byte IV length, 16 bytes IV and 32 bytes MAC (for a total of 53 bytes) plus the size of the IP (20 bytes for IPv4 without options and 40 bytes for IPv6 with no extension headers) and UDP header (eight bytes). Assuming that the nodes connect to the internet using a PPP-over-Ethernet DSL connection with its own eight-byte overhead, their own MTU on that interface will be 1492 bytes. The added overhead of a Wire being run over IPv4 would thus allow a VPN payload size (with headers) of 1411 bytes; if a cipher with a block size of 256 bits and a 512 bit MAC are used over a IPv6 link, this is further reduced to 1343 bytes.

4.5.9 Deregistration from Tracker Deregistration of slices and nodes from the Tracker shares the protocol number (3) with its counterpart operation of registration. Like all communication with a Tracker, it is done over UDP to reduce overhead.

← (1) N → T: 0x69, E Encr (NodeID, Timestamp; SliceID1, . . . ), MAC IA (...) KNT KNT

Protocol 4.11: Slice Deregistration from Tracker

Protocol 4.11 uses the message type number 0x69 for deregistration of slices. As with the registration, several iterations of the protocol can be used if deregistering all slices at once would cause the message to become too large for the network path between node and Tracker to handle. Finally, nodes are deregistered using a message with type 0x6B, as shown in protocol 4.12.

← (1) N → T: 0x6B, E Encr (NodeID), MAC IA (...) KNT KNT

Protocol 4.12: Node Deregistration from Tracker

70 5 Analysis

This chapter analyses the developed concept and highlights some noteworthy points. Special focus is put on several aspects and flaws of the system’s security and on the network overhead incurred by the proposed protocols.

5.1 Security

Among the required properties for node identites identified in section 3.1.1 were per- sistance, distictness, unforgeability and uniqueness. While NodeIDs are unforgeable because they are bound to the AIC that can only be accessed by the TPM it was issued to and their uniqueness is ensured by the issuing PCA, it is less obvious that the other two demands are also fulfilled. A Sybil attack [29] on distictness could be possible if a rogue node consecutively requested requested several AICs, and thus NodeIDs, from a PCA. Since the PCA would not be able to determine whether the node had been rebooted in the meantime, thus losing its old AIK and legitimately requesting a new certificate, it could not simply refuse its issuance. While it would be possible to revoke all certificates previously issued to that node and have the ATS verify their status before issuing a tracker ticket, this would provide no defense if the node had already received such a ticket, since revocation of tickets is not feasible given the additional verification overhead it would incur in the tracker. Fortunately, a node running software modified to act in this way would be exposed in the attestation process, so that while it may be able to aquire multiple identities, it would not be able to make any meaningful use of them. Finally, while nodes do need persistent identities for billing and authorization pur- poses, a change of NodeID as a result of a reboot or changed IP address does not disrupt the security of the network. The endorsement key of the node’s TPM can fulfill this role and information about the mapping from a NodeID to the EK of its node is available from the PCA. The developed concept does not provide Perfect Forward Secrecy. While the keys used between two nodes are independent from those used before and afterwards, they are assigned to the peers using the keys shared between each node and its tracker. These keys in turn stem from an exchange with an ATS that is protected by a session key sent from the node to the ATS encrypted under the public key from the latter’s encryption certificate. Therefore, the private key of the ATS forms the root of what could be called its “key tree”. The size of this tree could be reduced to the keys used by one node during the lifetime of one tracker ticket by negotiating the session key using Diffie-Hellman-Merkle key agreement; however, this computationally intensive operation

71 5 Analysis would further burden the already highly loaded ATS. Adequate protection of the critical key should be the more efficient solution, especially as the ATS remains under the IPS’s physical control. Another flaw is resolved more easily: For both encryption and protection of integrity and authenticity, the proposed protocols employ one respective key for both directions, while the use of separate keys for sending and receiving represents the state of the art in protocols such as IPsec [68] and TLS [26]. If desired, this can be fixed by adding the additional keys to the protocols where they are assigned; this was omitted intentionally as it would have made the protocol diagrams even more complex without providing any significant additional information. Not all of the designed protocols provide explicit protection against replay attacks. In the case of the Wire protocol, this is not neccessary because the VPN offers layer 3 (e.g., IP) functionality, and since IP itself does not protect against packet duplication, higher-layer protocols susceptible to such an occurrence need to implement their own protection anyway. Of the management protocols, AIK certification, tracker ticket retrieval, node regis- tration and wire setup are protected by the use of nonces. For performance reasons, slice registration and deregistration, which may need to be performed multiple times, use timestamps; this provides enough protection as it is not assumed that slices will be registered and deregistered multiple times within a short time span. Only two of the management protocols are not protected against replay attacks: Queries to trackers do not cause any state changes and elicit a response that is unreadable to the attacker and would be dropped as unsolicited by the node that made the original request. And node deregistration is only performed during shutdown, which means that the node would not re-register using the same NodeID, ticket and keys. In either case, if additional replay protection is desired, a host could store the MACs of all messages received from a node and silently drop any duplicates. Since this list could be discarded as soon as the node’s ticket expired, its would remain of limited size.

The use of timestamps obviously requires the system clocks of all participating plat- forms to be reasonably synchronized. This could be achieved using standard mechanisms, e.g. by providing an authenticated NTP service [50,81] on the servers acting as PCAs. The biggest problem however stems from the fact the the set-top boxes are deployed under physical control of the end user, who may actually be working for a customer or even a competitor interested in gaining information about the network structure, usage patterns and operative metrics that may be considered sensitive business secrets of the ISP or another customer [83] or in extracting data stored in or transmitted over the net- work. Disclosure of such information should be prevented by the integrity monitoring functions provided by Trusted Computing, and the TCG specifies the use of tamper- protected packaging to resist physical attacks against the TPM [143]. However, it has been shown possible to circumvent this protection on current TPMs, allowing the at- tacker to monitor internal communication and extract private key data [138]. While the

72 5 Analysis cost of such an attack should be prohibitively high for most attackers, and certainly for a private user wishing to extract or distribute a few unprotected movies, a competitor wishing to build or optimize an own NaDa-style network might well find it worthwhile if it allows the acquisition of the desired data. A possible, if radical, solution would be to move the functions of the set-top box one step closer to the network backbone by installing “super-nodes” providing most of the previous node functionality (such as storage) at the locations of the ISP’s points of pres- ence (e.g. the broadband remote access router), one hop before the customer premises, and reducing the set-top boxes to video players (or even integrating this function into the TV set itself, something many current sets already provide) that receive an already watermarked [18] copy of the requested movie from that super-node. While this would require substancially more powerful hardware for the latter and thus incur some of the problems of traditional data centers, such as high energy consumption and the need for more elaborate cooling systems, it could still retain some of the properties that the NaDa system was designed to provide, especially that of moving a high amount of traffic away from the ISP’s backbone and close to the network edge. On the other hand, given the high threat potential of the described attack it should be expected that TPM manufacturers will provide future models with a much higher level of protection against physical tampering, making attacks using this vector costly enough that they are not feasible even for an adversary with the delineated motivation.

5.2 Performance

While protocols like TLS [26] and SSH [152] are designed to optionally provide com- pression of the transferred data –which is sensible because lower-layer protocols will not be able to compress the ciphertext they create–, no such capability is envisaged for the concept developed in this thesis. This is because it is assumed that most use cases for NaDa, such as video or audio on demand or teleconferencing, will transfer already- compressed data, so that any attempt to compress it further with generic algorithms would require a high computational effort with no or no significant reduction in size. It is therefore deemed sensible to leave the compression of their data to the customers, possibly incentivizing them to do so by basing pricing schemes on the amount of data transferred, among other factors. As shown in section 4.5.8, the overhead incurred by the wire protocol amounts to 53 bytes when using a 128 bit encryption algorithm with a block size of 16 bytes in a cipher mode requiring an IV and a 256 bit MAC algorithm. In an IPv4 DSL environment offering an MTU of 1492 bytes, this represents 3.6% of the the 1464 bytes of payload available in a datagram after substracting the IP and UDP headers (20 and 8 bytes, respectively). If neccessary, this ratio could be reduced by using CTR mode for encryption and constructing the counter block as described in [59], with the nonce part provided by the tracker as part of the key data, thus reducing transmitted IV size from 16 to 8 bytes, and using a truncated MAC value, for example HMAC-SHA1 truncated to 96 bits (12 bytes),

73 5 Analysis which is deemed secure enough for IPsec1, saving another 20 bytes. This would result in the wire overhead being more than halved to 25 bytes per datagram, or 1.7%. Overhead is also incurred by connection management operations, i.e. the retrieval of new tracker and peer tickets, tracker re-registration and wire renewal, that may be neccessary several times during the lifetime of a wire. Assuming a validity period of 120 seconds for both ticket types, a node might retrieve new tickets after 100 seconds to ensure that they are available before the old ones expire. During this time, appoximately 60 MiB can be downloaded on a 5 000 kbps link. However, assuming that only one wire is established during this time would not re- flect a realistic operating environment. Instead, the value of 40 concurrent connections established in section 3.1.5 is used in the following calculations. This means that during the 100 seconds

• 1 Tracker Ticket Retrieval

• 1 Node Registration

• 1 Slice Registration (40 Slices)

• 40 Tracker Queries and

• 40 Wire Setups/Renewals are performed. While the amount of data transferred during the tracker ticket retrieval depends heavily on the size of the SML, it can safely be said that in total, no more than 100 KiB are required for these operations2. Since nodes will probably be connected to the internet using asymmetric technologies such as ADSL, it must be assumed that their uplink will have only one tenth of the capacity of the downlink. However, even so and even assuming for simplicity that all management overhead is transferred over the slower of the two links, it still requires only 0.2% of the available bandwith.

5.3 Privacy

Few privacy issues present themselves at this low layer in the NaDa system. Since the identity of the end user is discenible only from the EK used by the TPM in his set-top box, the use of a Privacy CA hides this persistent identity from all principals consuming NodeIDs. If the PCA is organizationally seperated from the rest of the NaDa infrastructure, even technicians responsible for the latter will not easily be able to resolve the mapping of a NodeID to the account its actions are billed to.

1It should be noted here that network messages are ephemeral and thus an attack would be time-critical and have to be completed within the lifetime of the used key. Contrast this with the forgery of a signature on a document or software package, from which the attacker may still yield benefits after several months or even years. 2Approx. values used: Tracker Ticket Retrieval 15 KiB, Node Registration 600 bytes, Slice Registration: 3 000 bytes, Query 500 bytes, Wire Setup 500 bytes.

74 5 Analysis

Furthermore, customers do not even learn the NodeID of the node a slice of theirs is hosted on. From the customers’ point of view, addressing is done using either SliceIDs or VPN IP addresses, and while these need to mapped to the ID of the respective node, this information enters and leaves the trusted STB only in encrypted form.

75 6 Conclusion and Outlook

In this thesis, a Virtual Private Network concept for the Nanodatacenters (NaDa) plat- form was developed. Requirements analysis identified several issues that do not pose themselves in conventional VPN settings, including node security, isolation of customer domains, economical use of the ISP’s network resources and issues arising from the pos- sibility of very large-scale deployments under the control of a single network operator. For performance reasons, the resulting design features separation of duties wherever possible and allows highly loaded entities to be subdivided as needed. Provisions are made for upgrades of the system without hampering overall operation as well as for integration with the ISP’s authentication and billing systems. The system allows com- munication with slices as well as with the NaDa managment on nodes and allows the ISP to offer application slices, while still maintaining isolation of customers not only from each other, but also from the overall network structure. Security is provided by using TCG Remote Attestation to verify the integrity of nodes before they are allowed to join the network and the use of encryption and integrity and authenticity protection whenever sensitive data is transmitted. The use of symmetric algorithms in almost all network operations provides a high throughput. Besides the ideas for further development of this concept already described in other parts of this thesis, the following may also be of interest: The centralized servers PCA, ATS and the Trackers may experience a high load and thus become bottlenecks, especially during unexpected peak use of the network. Dis- tributing their functions among the deployed trusted nodes (e.g. using a structured peer-to-peer overlay) may be a feasible way to reduce the reliance on a centralized man- agement infrastructure. However, this might not be in the interest of an ISP wishing to exert physical control over these security-critical systems. A problem that has already been mentioned is the danger of a malicious customer or end user performing traffic analysis on the Set-Top Box that is under her physical control. Using the system’s regular user interface, such an attacker might issue requests that cause predictable connections to be established and then use the gathered traffic data to garner information about the structure of the NaDa network, trying to ascertain information such as “How many nodes does the ISP have deployed in my area?” or “What is the user base of customer X?”. Another attack vector may lie in analysis of the control messages exchanged, both to learn about the network structure and to gain information about the cryptographic algorithms and parameters used. Message padding and dummy traffic could be employed to mitigate such attacks. However, the fact that a Video on Demand use-case will usually require bulk transfers of data serveral gigabytes in size complicates the use of straightforward strategies if

76 6 Conclusion and Outlook convincing dummy traffic is to be created without prohibitively reducing the goodput of the system. Lower-layer encryption of the link between the STB and the access router on the ISP’s side could also provide suitable defense, but would require additional processing capacity especially on a router serving many end users. While Broadcasts are rarely needed by Internet protocols and can easily be contained by assigning a separate subnet to each node, many conceivable applications of the NaDa network, such as the distribution of real-time IPTV, could greatly benefit from the use of Multicasting. However, the current design of this VPN makes no provisions for such a mode of operation. Explicit Multicast support should not only allow efficient manage- ment of multicast trees and group memberships but also take into account the compu- tational overhead required by encryption and integrity and authenticity protection, for example through the use of group keys or related mechanisms. Finally, the greatest obstacle for the deployment of cost-intensive, large scale NaDa type networks is the current lack of protection against concerted physical attack on the Set-Top Boxes supplied to the end users. As long as Trusted Platform Modules are unable to withstand or reliably detect attacks by a resourceful, well-equipped ad- versary, corporate customers will have little incentive to make substantial investments in a network basing the security of some of their business-relevant metrics on Trusted Computing technology.

77 List of Protocols

3.1 AIK Certification...... 29 3.2 Tracker Ticket Retrieval...... 31 3.3 Node Registration with Tracker...... 35 3.4 Slice Registration with Tracker...... 36 3.5 Tracker Query by VPN IP...... 38 3.6 Tracker Query by SliceID...... 39 3.7 Tracker Query by NodeID...... 39 3.8 Wire Setup/Renewal (Slice-Slice Wire)...... 41 3.9 Wire Setup/Renewal (Node-Node Wire)...... 42 3.10 Data Transfer...... 43 3.11 Slice Deregistration from Tracker...... 45 3.12 Node Deregistration from Tracker...... 45

4.1 AIK Certification...... 60 4.2 Tracker Ticket Retrieval...... 63 4.3 Node Registration with Tracker...... 65 4.4 Slice Registration with Tracker...... 65 4.5 Tracker Query by VPN IP...... 66 4.6 Tracker Query by SliceID...... 66 4.7 Tracker Query by NodeID...... 67 4.8 Wire Setup/Renewal (Slice-Slice Wire)...... 69 4.9 Wire Setup/Renewal (Node-Node Wire)...... 69 4.10 Data Transfer...... 69 4.11 Slice Deregistration from Tracker...... 70 4.12 Node Deregistration from Tracker...... 70

I List of Tables

3.1 Tracker Ticket...... 33 3.2 Peer Ticket...... 41 3.3 Number of Server Operations in Basic Protocol...... 47 3.4 Approx. Number of Server Operation Equivalents in Basic Protocol.... 47

4.1 Data Types...... 51 4.2 Node ID composition...... 52 4.3 Slice ID composition...... 53 4.4 Customer ID composition...... 53 4.5 Region ID composition...... 53 4.6 PCA ID composition...... 54 4.7 Outer Encryption Algorithm Identifiers...... 55 4.8 Inner Encryption Algorithm Identifiers...... 55 4.9 Operation Mode Identifiers...... 56 4.10 Padding Method Identifiers...... 56 4.11 Integrity/Authenticity Algorithm...... 57 4.12 Compression Function...... 57 4.13 Tracker Ticket...... 64 4.14 Peer Ticket...... 68

II Bibliography

[1] M. Abadi and R. Needham. Prudent Engineering Practice for Cryptographic Protocols. IEEE Transactions on Software Engineering, 22:6–15, 1996.

[2] Ammar Alkassar, Christian St¨uble,and Ahmad-Reza Sadeghi. Secure object identification: or: solving the Chess Grandmaster Problem. In NSPW ’03: Proceedings of the 2003 workshop on New security paradigms, pages 77–85, New York, NY, USA, 2003. ACM.

[3] Jee Hea An and Mihir Bellare. Does Encryption with Redundancy Provide Authenticity? In Birgit Pfitzmann, editor, Advances in Cryptology - EUROCRYPT 2001, International Conference on the Theory and Application of Cryptographic Techniques, Innsbruck, Austria, May 6-10, 2001, Proceeding, volume 2045 of Lecture Notes in Computer Science, pages 512–528. Springer, 2001. ISBN 3-540-42070-3.

[4] Ross Anderson. ’Trusted Computing’ Frequently Asked Questions, August 2003. http://www.cl.cam.ac.uk/~rja14/tcpa-faq.html, retrieved 2012-07-03. [5] Ross Anderson, Eli Biham, and Lars Knudsen. Serpent: A Proposal for the Advanced Encryption Standard. In Proceedings of the First AES Candidate Conference, Ventura, CA, USA, June 1998. National Institute of Standard and Technology.

[6] Kazumaro Aoki, Tetsuya Ichikawa, Masayuki Kanda, Mitsuru Matsui, Shiho Moriai, Junko Nakajima, and Toshio Tokita. Camellia: A 128-Bit Block Cipher Suitable for Multiple Platforms - Design and Analysis. In Douglas R. Stinson and Stafford E. Tavares, editors, Selected Areas in Cryptography, 7th Annual International Workshop, SAC 2000, Waterloo, Ontario, Canada, August 14-15, 2000, Proceedings, volume 2012 of Lecture Notes in Computer Science, pages 39–56. Springer, 2000. ISBN 3-540-42069-X.

[7] Frederik Armknecht, Yacine Gasmi, Ahmad-Reza Sadeghi, Patrick Stewin, Martin Unger, Gianluca Ramunno, and Davide Vernizzi. An Efficient Implementation of Trusted Channels based on OpenSSL. In STC ’08: Proceedings of the 3rd ACM workshop on Scalable trusted computing, pages 41–50, New York, NY, USA, 2008. ACM.

[8] Atmel Corporation. Trusted Platform Module AT97SC3204. Datasheet Summary, March 2011.

III Bibliography

[9] Harald Baier and Vangelis Karatsiolis. Validity models of electronic signatures and their enforcement in practice. In Fabio Martinelli and Bart Preneel, editors, Public Key Infrastructures, Services and Applications - 6th European Workshop, EuroPKI 2009, Pisa, Italy, September 10-11, 2009, Revised Selected Papers, volume 6391 of Lecture Notes in Computer Science, pages 255–270. Springer, 2009. ISBN 978-3-642-16440-8.

[10] Shane Balfe, Amit D. Lakhani, and Kenneth G. Paterson. Securing Peer-to-Peer Networks Using Trusted Computing. In Chris J. Mitchell, editor, Trusted Computing, pages 271–298, London, 2005. IET Publishing. ISBN 978-0-86341-525-8.

[11] William C. Barker and Elaine Barker. Recommendation for the Triple Data Encryption Algorithm (TDEA) Block Cipher. NIST Special Publication 800-67 Revision 1, National Institute of Standards and Technology, Gaithersburg, January 2012.

[12] Paulo S.L.M. Barreto and Vincent Rijmen. The Whirlpool Hashing Function, May 2003.

[13] Mihir Bellare, Tadayoshi Kohno, and Chanathip Namprempre. Breaking and provably repairing the SSH authenticated encryption scheme: A case study of the Encode-then-Encrypt-and-MAC paradigm. ACM Transactions on Information and System Security, 7(2):206–241, 2004.

[14] Mihir Bellare and Chanathip Namprempre. Authenticated Encryption: Relations among Notions and Analysis of the Generic Composition Paradigm. Journal of Cryptology, 21(4):469–491, September 2008.

[15] Mihir Bellare, Phillip Rogaway, and David Wagner. The EAX Mode of Operation. In Bimal K. Roy and Willi Meier, editors, Fast Software Encryption, 11th International Workshop, FSE 2004, Delhi, India, February 5-7, 2004, Revised Papers, volume 3017 of Lecture Notes in Computer Science, pages 389–407. Springer, 2004. ISBN 3-540-22171-9.

[16] Guido Bertoni, Joan Daemen, Micha¨elPeeters, and Gilles Van Assche. The Keccak reference, January 2011.

[17] P. Oscar Boykin, Jesse S. A. Bridgewater, Joseph S. Kong, Kamen M. Lozev, Behnam A. Rezaei, and Vwani P. Roychowdhury. A Symphony Conducted by Brunet. September 2007.

[18] Andreas Brett. Trusted Watermarks. Diploma thesis, Technische Universit¨at Darmstadt, April 2009.

[19] Central Intelligence Agency. CIA - The World Factbook - China, September 2012. https:

IV Bibliography

//www.cia.gov/library/publications/the-world-factbook/geos/ch.html, retrieved 2012-09-18. [20] Byung-Gon Chun, Gianluca Iannaccone, Giuseppe Iannaccone, Randy Katz, Gunho Lee, and Luca Niccolini. An energy case for hybrid datacenters. SIGOPS Oper. Syst. Rev., 44(1):76–80, March 2010. [21] Bram Cohen. Incentives Build Robustness in BitTorrent. In 1st Workshop on Economics of Peer-to-Peer Systems, 2003. [22] Bram Cohen. BEP 3: The BitTorrent Protocol Specification, June 2009. [23] D: Cooper, S. Santesson, S. Farrell, S. Boyen, R. Housley, and W. Polk. RFC 5280: Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile, May 2008. [24] Renzo Davoli. VDE: Virtual Distributed Ethernet. Technical Report UBLCS-2004-12, University of Bologna, June 2004. [25] Luca Deri and Richard Andrews. N2N: A Layer Two Peer-to-Peer VPN. In David Hausheer and J¨urgenSch¨onw¨alder,editors, Resilient Networks and Services, Second International Conference on Autonomous Infrastructure, Management and Security, AIMS 2008, Bremen, Germany, July 1-3, 2008, Proceedings, volume 5127 of Lecture Notes in Computer Science, pages 53–64. Springer, 2008. ISBN 978-3-540-70586-4. [26] T. Dierks and E. Rescorla. RFC 5246: The Transport Layer Security (TLS) Protocol, Version 1.2, August 2008. [27] Whitfield Diffie and Martin E. Hellman. New Directions in Cryptography. IEEE Transactions on Information Theory, 22(6):644–654, November 1976. [28] Danny Dolev and Andrew Chi-Chih Yao. On the Security of Public Key Protocols. Technical Report STAN-CS-81-854, Department of Computer Science, Stanford University, May 1981. [29] John R. Douceur. The Sybil Attack. In Peter Druschel, M. Frans Kaashoek, and Antony I. T. Rowstron, editors, Peer-to-Peer Systems, First International Workshop, IPTPS 2002, Cambridge, MA, USA, March 7-8, 2002, Revised Papers, volume 2429 of Lecture Notes in Computer Science, pages 251–260. Springer, 2002. ISBN 3-540-44179-4. [30] Hiro Dudani. Identification in Peer-to-Peer Networks. Term Paper, TU Darmstadt, 2007. [31] Alan M. Dunn, Owen S. Hofmann, Brent Waters, and Emmett Witchel. Cloaking Malware with the Trusted Platform Module. In 20th USENIX Security Symposium, San Francisco, CA, USA, August 8-12, 2011, Proceedings. USENIX Association, 2011.

V Bibliography

[32] Morris Dworkin. Recommendation for Block Cipher Modes of Operation: Methods and Techniques. NIST Special Publication 800-38A, National Institute of Standards and Technology, Gaithersburg, December 2001.

[33] Morris Dworkin. Recommendation for Block Cipher Modes of Operation: The CCM Mode for Authentication and Confidentiality. NIST Special Publication 800-38C, National Institute of Standards and Technology, Gaithersburg, May 2004.

[34] Morris Dworkin. Recommendation for Block Cipher Modes of Operation: The CMAC Mode for Authentication. NIST Special Publication 800-38B, National Institute of Standards and Technology, Gaithersburg, May 2005.

[35] Morris Dworkin. Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC. NIST Special Publication 800-38D, National Institute of Standards and Technology, Gaithersburg, November 2007.

[36] J¨orgEbersp¨acher and R¨udigerSchollmeier. First and Second Generation of Peer-to-Peer Systems. In Steinmetz and Wehrle [131], pages 35–56. ISBN 3-540-29192-X.

[37] Claudia Eckert. IT-Sicherheit. Konzepte – Verfahren – Protokolle. Oldenbourg, M¨unchen, fifth edition, 2008. ISBN 978-3-486-58270-3.

[38] P. Eronen and P. Hoffman. RFC 4718: IKEv2 Clarifications and Implementation Guidelines, October 2006.

[39] Niels Ferguson and Bruce Schneier. A Cryptographic Evaluation of IPsec. Technical report, Counterpane Internet Security, Inc, 2000.

[40] Paul Ferguson and Geoff Huston. What is a VPN?, April 1998.

[41] Rezan Fisli. Secure Corporate Communications over VPN-Based WANs. Master’s thesis, Department of Numerical Analysis and Computer Science, Royal Institute of Technology, Stockholm, Sweden, 2005.

[42] Catherine Flick. The Controvery over Trusted Computing. Bachelor thesis, University of Sydney, June 2004.

[43] A. Freier, P. Karlton, and P. Kocher. RFC 6101: The Secure Sockets Layer (SSL) Protocol Version 3.0, August 2011.

[44] Andreas Fuchs. Improving Scalability for Remote Attestion. Diploma Thesis, TU Darmstadt, January 2008.

[45] Arijit Ganguly, Abhishek Agrawal, P. Oscar Boykin, and Renato J. O. Figueiredo. IP over P2P: Enabling Self-configuring Virtual IP Networks for Grid Computing. In 20th International Parallel and Distributed Processing Symposium

VI Bibliography

(IPDPS 2006), Proceedings, 25-29 April 2006, Rhodes Island, Greece. IEEE, 2006.

[46] Yacine Gasmi, Ahmad-Reza Sadeghi, Patrick Stewin, Martin Unger, and N. Asokan. Beyond Secure Channels. In Peng Ning, Vijay Atluri, Shouhuai Xu, and Moti Yung, editors, Proceedings of the 2nd ACM Workshop on Scalable Trusted Computing, STC 2007, Alexandria, VA, USA, November 2, 2007, pages 30–40. ACM, 2007. ISBN 978-1-59593-888-6.

[47] Kenneth Goldman, Ronald Perez, and Reiner Sailer. Linking Remote Attestation to Secure Tunnel Endpoints. In Juels et al. [62], pages 21–24. ISBN 1-59593-548-7.

[48] D. Grossman. RFC 3260: New Terminology and Clarifications for Diffserv, April 2002.

[49] Sigrid G¨urgensand Carsten Rudolph. AIK certification. Unpublished, BSI / Fraunhofer SIT, April 2006.

[50] B. Haberman and D. Mills. RFC 5906: Network Time Protocol Version 4: Autokey Specification, June 2010.

[51] K. Hamzeh, G. Pall, W. Verthein, J. Taarud, W. Little, and G. Zorn. RFC 2637: Point-to-Point Tunneling Protocol (PPTP), July 1999.

[52] Markus Hansen and Marit Hansen. Auswirkungen von Trusted Computing auf die Privatsph¨are.In Pohlmann and Reimer [101], pages 209–220. ISBN 978-3-8348-0309-2.

[53] David Harrison. BEP 4: Assigned Numbers, September 2008.

[54] Gerhard Haßlinger. ISP Platforms Under a Heavy Peer-to-Peer Workload. In Steinmetz and Wehrle [131], pages 369–381. ISBN 3-540-29192-X.

[55] heise online. Weltgr¨oßterBitTorrent-Tracker offline, May 2006. http://www.heise.de/newsticker/meldung/ Weltgroesster-BitTorrent-Tracker-offline-128583.html, retrieved 2012-07-09.

[56] R. Hinden and S. Deering. RFC 4291: IP Version 6 Addressing Architecture, February 2006.

[57] John Hoffman. BEP 12: Multitracker Metadata Extension, February 2008.

[58] Osamu Honda, Hiroyuki Ohsaki, Makoto Imase, Ishizuka Mika, and Junichi Murayama. Understanding TCP over TCP: Effects of TCP Tunneling on End-to-End Throughput, Latency, and Loss Characteristics. In IEICE Technical Reports, volume 104 of IN2004-121, pages 79–84, Osaka, November 2004.

VII Bibliography

[59] R. Housley. RFC 3686: Using Advanced Encryption Standard (AES) Counter Mode With IPsec Encapsulating Security Payload (ESP), January 2004.

[60] A. Huttunen, B. Swander, V. Volpe, L. DuBurro, and M. Stenberg. RFC 3948: UDP Encapsulation of IPsec ESP Packets, January 2005.

[61] Mikel Izal, Guillaume Urvoy-Keller, Ernst W. Biersack, Pascal Felber, Anwar Al Hamra, and Luis Garc´es-Erice.Dissecting BitTorrent: Five Months in a Torrent’s Lifetime. In Chadi Barakat and Ian Pratt, editors, Passive and Active Network Measurement, 5th International Workshop, PAM 2004, Antibes Juan-les-Pins, France, April 19-20, 2004, Proceedings, volume 3015 of Lecture Notes in Computer Science, pages 1–11. Springer, 2004. ISBN 3-540-21492-5.

[62] Ari Juels, Gene Tsudik, Shouhuai Xu, and Moti Yung, editors. Proceedings of the 1st ACM Workshop on Scalable Trusted Computing, STC 2006, Alexandria, VA, USA, November 3, 2006. ACM, 2006. ISBN 1-59593-548-7.

[63] B. Kaliski. RFC 2898: PKCS #5: Password-Based Cryptography Specification Version 2.0, September 2000.

[64] Bernhard Kauer. OSLO: improving the security of trusted computing. In SS’07: Proceedings of 16th USENIX Security Symposium on USENIX Security Symposium, pages 1–9, Berkeley, CA, USA, 2007. USENIX Association.

[65] C. Kaufman, Ed. RFC 4306: Internet Key Exchange (IKEv2) Protocol, December 2005.

[66] S. Kent. RFC 4302: IP Authentication Header, December 2005.

[67] S. Kent. RFC 4303: IP Encapsulating Security Payload (ESP), December 2005.

[68] S. Kent and K. Seo. RFC 4301: Security Architecture for the Internet Protocol, December 2005.

[69] H. Krawczyk, M. Bellare, and R. Canetti. RFC 2104: HMAC: Keyed-Hashing for Message Authentication, February 1997.

[70] Hugo Krawczyk. The Order of Encryption and Authentication for Protecting Communications (or: How Secure Is SSL?). In CRYPTO ’01: Proceedings of the 21st Annual International Cryptology Conference on Advances in Cryptology, pages 310–331, London, UK, 2001. Springer-Verlag.

[71] Nicolai Kuntze, Andreas Fuchs, and Carsten Rudolph. Reliable Identities using off-the-shelf hardware security in MANETs. In Proceedings of the International Symposium on Trusted Computing and Communications (TrustCom 2009), 2009.

[72] Nicolai Kuntze, Carsten Rudolph, and Andreas Fuchs. Trust in Peer-to-Peer Content Distribution Protocols. In Pierangela Samarati, Michael Tunstall,

VIII Bibliography

Joachim Posegga, Konstantinos Markantonakis, and Damien Sauveron, editors, Information Security Theory and Practices. Security and Privacy of Pervasive Systems and Smart Devices, 4th IFIP WG 11.2 International Workshop, WISTP 2010, Passau, Germany, April 12-14, 2010. Proceedings, volume 6033 of Lecture Notes in Computer Science, pages 76–89. Springer, 2010.

[73] Nicolai Kuntze, Carsten Rudolph, and Janne Paatero. Establishing Trust between Nodes in Mobile Ad-Hoc Networks. In 4th International Conference on Trusted Systems (InTrust 2012). Royal Holloway, University of London, 2012.

[74] J. Lau, M. Townsley, and I. Goyret. RFC 3931: Layer Two Tunneling Protocol - Version 3 (L2TPv3), March 2005.

[75] Andreas Leicher. Trusted Ticket Systems. Diploma Thesis, Johann Wolfgang Goethe-University, April 2009.

[76] Andreas Leicher, Nicolai Kuntze, and Andreas U. Schmidt. Implementation of a Trusted Ticket System. In Dimitris Gritzalis and Javier Lopez, editors, Emerging Challenges for Security, Privacy and Trust, 24th IFIP TC 11 International Information Security Conference, SEC 2009, Pafos, Cyprus, May 18-20, 2009. Proceedings, volume 297 of IFIP, pages 152–163. Springer, 2009. ISBN 978-3-642-01243-3.

[77] Andrew Loewenstern. BEP 5: DHT Protocol, January 2008.

[78] Gregor Maier, Anja Feldmann, Vern Paxson, and Mark Allman. On Dominant Characteristics of Residential Broadband Internet Traffic. In IMC ’09: Proceedings of the 2009 Internet Measurement Conference, pages 90–102, New York, NY, USA, November 2009. ACM Press.

[79] A. Medvinsky and M. Hur. RFC 2712: Addition of Kerberos Cipher Suites to Transport Layer Security (TLS), October 1999.

[80] G. Meyer. RFC 1968: The PPP Encryption Control Protocol (ECP), June 1996.

[81] D. Mills, J. Martin, J. Burbank, and W. Kasch. RFC 5905: Network Time Protocol Version 4: Protocol and Algorithms Specification, June 2010.

[82] Nanodatacenters Project. Deliverable D1.1, D3.1: System Design and Decomposition, October 2009.

[83] Nanodatacenters Project. Deliverable D3.2: Final Architecture Specification of security, privacy, and incentive mechanisms, November 2009.

[84] Nanodatacenters Project. Deliverable 2.1: Measurement-based characterisation of application and user behaviour, January 2010.

[85] Nanodatacenters Project. Deliverable D1.2: Evaluation of the energy efficiency of distributed vs. centralised content distribution, January 2010.

IX Bibliography

[86] Nanodatacenters Project. Deliverable D1.5: Final Architecture, June 2011.

[87] National Institute of Standards and Technology. Data Encryption Standard (DES). Federal Information Processing Standards Publication 46-3, October 1999. (Withdrawn).

[88] National Institute of Standards and Technology. Specification for the Advanced Encryption Standard (AES). Federal Information Processing Standards Publication 197, November 2001.

[89] National Institute of Standards and Technology. The Keyed-Hash Message Authentication Code. Federal Information Processing Standards Publication 198-1, July 2008.

[90] National Institute of Standards and Technology. Secure Hash Standard. Federal Information Processing Standards Publication 180-4, March 2012.

[91] Andreas Neumann. Rechtliche Chancen und Risiken des ,,Trusted Computing”. In Pohlmann and Reimer [101], pages 221–235. ISBN 978-3-8348-0309-2.

[92] C. Neumann, T. Yu, S. Hartman, and K. Raeburn. RFC 4120: The Kerberos Network Authentication Service (V5), July 2005.

[93] K. Nichols, S. Blake, F. Baker, and D. Black. RFC 2474: Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers, December 1998.

[94] Jim Nutt. FTS-0009: MSGID/REPLY - A standard for unique message identifiers and reply chain linkage. FidoNet Technical Standard, December 1991.

[95] G. Pall and G. Zorn. RFC 3078: Microsoft Point-To-Point Encryption (MPPE) Protocol, March 2001.

[96] C. Partridge, T. Mendez, and W. Milliken. RFC 1546: Host Anycasting Service, November 1993.

[97] B. Patel, B. Aboba, W. Dixon, G. Zorn, and S. Booth. RFC 3193: Securing L2TP using IPsec, November 2001.

[98] Gang Peng. CDN: Content Distribution Network. Technical Report TR-125, Experimental Computer Systems Lab, State University of New York, Stony Brook, NY, February 2008.

[99] J. Peterson and A. Cooper. RFC 5594: Report from the IETF Workshop on Peer-to-Peer (P2P) Infrastructure, May 28, 2008, July 2009.

[100] David C. Plummer. RFC 826: An Ethernet Address Resolution Protocol, November 1982.

X Bibliography

[101] Norbert Pohlmann and Helmut Reimer, editors. Trusted Computing - Ein Weg zu neuen IT-Sicherheitsarchitekturen. Vieweg+Teubner, Wiesbaden, first edition, 2008. ISBN 978-3-8348-0309-2.

[102] J. Postel. RFC 768: User Datagram Protocol. STD 6, August 1980.

[103] Jon Postel. RFC 791: Internet Protocol. DARPA Internet Program. Protocol Specification. STD 5, September 1981.

[104] Jon Postel. RFC 793: Transmission Control Protocol. STD 7, September 1981.

[105] B. Preneel, A. Biryukov, C. De Canni`ere,S. B. Ors,¨ E. Oswald, B. Van Rompay, L. Granboulan, E. Dottax, G. Martinet, S. Murphy, A. Dent, R. Shipsey, C. Swart, J. White, M. Dichtl, S. Pyka, M. Schafheutle, E. Biham P. Ser and, E. Barkan, Y. Braziler, O. Dunkelman, V. Furman, D. Kenigsberg, J. Stolin, J-J. Quisquater, M. Ciet, F. Sica, H. Raddum, L. Knudsen, and M. Parker. Final report of European project number IST-1999-12324, named New European Schemes for Signatures, Integrity, and Encryption (NESSIE). Springer-Verlag, Berlin Heidelberg NewYork London Paris Tokyo Hong Kong Barcelona Budapest, April 2004.

[106] Jason Reid. Enhancing Security in Distributed Systems with Trusted Computing Hardware. PhD thesis, Queensland University of Technology, 2007.

[107] E. Rescorla and N. Modadugu. RFC 6347: Datagram Transport Layer Security Version 1.2, January 2012.

[108] E. Rescorla, M. Ray, S. Dispensa, and N. Oskov. RFC 5746: Transport Layer Security (TLS) Renegotiation Indication Extension, February 2010.

[109] Eric Rescorla. Notes on P2P Blocking and Evasion, May 2008.

[110] P. Resnick. RFC 5322: Internet Message Format, October 2008.

[111] C. Rigney, S. Willens, A. Rubens, and W.Simpson. RFC 2865: Remote Authentication Dial In User Service (RADIUS), June 2000.

[112] Troy Rollo. A description of the DCC protocol, October 1991. URL: news:[email protected] in alt.irc.

[113] Ahmad-Reza Sadeghi, Marcel Selhorst, Christian St¨uble,Christian Wachsmann, and Marcel Winandy. TCG Inside? A Note on TPM Specification Compliance. In Juels et al. [62], pages 47–56. ISBN 1-59593-548-7.

[114] Ahmad-Reza Sadeghi, Marko Wolf, Christian St¨uble,N. Asokan, and Jan-Erik Ekberg. Enabling Fairer Digital Rights Management with Trusted Computing. In Juan A. Garay, Arjen K. Lenstra, Masahiro Mambo, and Ren´ePeralta, editors, Information Security, 10th International Conference, ISC 2007,

XI Bibliography

Valpara´ıso,Chile, October 9-12, 2007, Proceedings, volume 4779 of Lecture Notes in Computer Science, pages 53–70. Springer, 2007. ISBN 978-3-540-75495-4.

[115] David Safford. Clarifying Misinformation on TCPA. IBM Research, October 2002.

[116] S. Sakane, K. Kamada, M. Thomas, and J. Vilhuber. RFC 4430: Kerberized Internet Negotiation of Keys (KINK), March 2006.

[117] J. H. Saltzer, D. P. Reed, and D. D. Clark. End-to-End Arguments in System Design. ACM Transactions in Computer Systems, 2(4):277–288, November 1984.

[118] Ravi S. Sandhu and Xinwen Zhang. Peer-to-Peer Access Control Architecture Using Trusted Computing Technology. In Elena Ferrari and Gail-Joon Ahn, editors, SACMAT 2005, 10th ACM Symposium on Access Control Models and Technologies, Stockholm, Sweden, June 1-3, 2005, Proceedings, pages 147–158. ACM, 2005. ISBN 1-59593-045-0.

[119] C. Sapuntzakis. TCP Message Boundary Option. Internet-Draft, August 2000.

[120] Stuart E. Schechter, Rachel A. Greenstadt, and Michael D. Smith. Trusted Computing, Peer-To-Peer Distribution, and the Economics of Pirated Entertainment. In The Second Workshop on Economics and Information Security, pages 29–30, May 2003.

[121] Bruce Schneier. The Blowfish Encryption Algorithm. http://www.schneier.com/blowfish.html, retrieved 2012-09-26.

[122] Steffen Schulz and Ahmad-Reza Sadeghi. Secure VPNs for Trusted Computing Environments. In Liqun Chen, Chris J. Mitchell, and Andrew Martin, editors, Trusted Computing, Second International Conference, Trust 2009, Oxford, UK, April 6-8, 2009, Proceedings, volume 5471 of Lecture Notes in Computer Science, pages 197–216. Springer-Verlag, Berlin Germany, 2009. ISBN 978-3-642-00586-2.

[123] Steffen Schulz and Ahmad-Reza Sadeghi. Extending IPsec for Efficient Remote Attestation. In Radu Sion, editor, Financial Cryptography, Lecture Notes in Computer Science. Springer, January 2010. Workshop on Real-Life Cryptographic Protocols (RLCPS).

[124] Victor Shoup (ed.). FCD 18033-2. Encryption algorithms – Part 2: Asymmetric ciphers. ISO Final Committee Draft, December 2004.

[125] W. Simpson. RFC 1661: The Point-to-Point Protocol (PPP). STD 51, July 1994.

[126] W. Simpson. RFC 1994: PPP Challenge Handshake Authentication Protocol (CHAP), August 1996.

[127] Sirrix AG security technologies. Sirrix. TrustedVPN data sheet, February 2010.

XII Bibliography

[128] T. Socolofsky and C. Kale. RFC 1180: A TCP/IP Tutorial, January 1991.

[129] Frank Stajano. Security for Whom? The Shifting Security Assumptions of Pervasive Computing. In Mitsuhiro Okada, Benjamin C. Pierce, Andre Scedrov, Hideyuki Tokuda, and Akinori Yonezawa, editors, Software Security – Theories and Systems, Mext-NSF-JSPS International Symposium, ISSS 2002, Tokyo, Japan, November 8-10, 2002, Revised Papers, volume 2609 of Lecture Notes in Computer Science, pages 16–27, Berlin, Heidelberg, 2003. Springer-Verlag. ISBN 3-540-00708-3.

[130] William Stallings. Cryptography and Network Security: Principles and Practice. Prentice Hall, fourth edition, 2006. ISBN 0-13-187316-4.

[131] Ralf Steinmetz and Klaus Wehrle, editors. Peer-to-Peer Systems and Applications, volume 3485 of Lecture Notes in Computer Science. Springer, 2005. ISBN 3-540-29192-X.

[132] Ralf Steinmetz and Klaus Wehrle. What Is This “Peer-to-Peer” About? In Peer-to-Peer Systems and Applications [131], pages 9–16. ISBN 3-540-29192-X.

[133] Marc Stevens. Attacks on Hash Functions and Applications. PhD thesis, Universiteit Leiden, June 2012. ISBN 978-94-6191-317-3.

[134] W. Richard Stevens. TCP/IP Illustrated, Volume 1: The Protocols. Addison-Wesley Longman Publishing Co., Inc., Boston, MA, USA, 1994. ISBN 0-201-63346-9.

[135] STMicroelectronics. ST33TPM12LPC Trusted Platform Module with LPC interface based on 32-bit ARM SecurCore SC300 CPU. Data Brief, December 2011.

[136] Frederic Stumpf, Omid Tafreschi, Patrick R¨oder,and Claudia Eckert. A Robust Integrity Reporting Protocol for Remote Attestation. In Second Workshop on Advances in Trusted Computing (WATC ’06 Fall), Tokyo, Japan, November 2006.

[137] Andrew S. Tanenbaum. Computer Networks. Prentice Hall PTR, Upper Saddle River, New Jersey 07458, fourth edition, 2003. ISBN 0-13-038488-7.

[138] Christopher Tarnovsky. Hacking the Smartcard Chip / Deconstructing a ’Secure’ Processor. In Black Hat Technical Security Conference: DC, 2010.

[139] M. Thomas. RFC 3129: Requirements for Kerberized Internet Negotiation of Keys, June 2001.

[140] Stefan Tillich and Johann Großsch¨adl.A Survey of Public-Key Cryptography on J2ME-Enabled Mobile Devices. In Cevdet Aykanat, Tugrul Dayar, and Ibrahim Korpeoglu, editors, Computer and Information Sciences - ISCIS 2004, 19th International Symposium, Kemer-Antalya, Turkey, October 27-29, 2004.

XIII Bibliography

Proceedings, volume 3280 of Lecture Notes in Computer Science, pages 935–944. Springer, 2004. ISBN 3-540-23526-4.

[141] W. Townsley, A. Valencia, A. Rubens, G. Pall, G. Zorn, and B. Palter. RFC 2661: Layer Two Tunneling Protocol “L2TP”, August 1999.

[142] Trusted Computing Group. TCG Software Stack (TSS) specification version 1.2, March 2007.

[143] Trusted Computing Group. TCG Specification Architecture Overview, August 2007.

[144] Trusted Computing Group. TPM Main, Part 1: Design Principles, March 2011.

[145] Trusted Computing Group. TPM Main, Part 2: TPM Structures, March 2011.

[146] Trusted Computing Group. TPM Main, Part 3: Commands, March 2011.

[147] Trusted Computing Group Best Practices Commitee. Design, Implementation, and Usage principles, February 2011.

[148] Trusted Computing Group Infrastructure Working Group. TCG Credential Profiles, May 2007.

[149] A. Valencia, M. Littlewood, and T. Kolar. RFC 2341: Cisco Layer Two Forwarding (Protocol) “L2F”, May 1998.

[150] Olaf van der Spek. BEP 15: UDP Tracker Protocol for BitTorrent, February 2008.

[151] B. Weis. RFC 4359: The Use of RSA/SHA-1 Signatures within Encapsulating Security Payload (ESP) and Authentication Header (AH), January 2006.

[152] T. Ylonen and C. Lonvick. RFC 4253: The Secure Shell (SSH) Transport Layer Protocol, January 2006.

[153] Xinwen Zhang, Songqing Chen, and Ravi S. Sandhu. Enhancing Data Authenticity and Integrity in P2P Systems. IEEE Internet Computing, 9(6):42–49, 2005.

XIV