 So, good morning, my name is Janne Lindquist and I'm with the Helsinki University of Technology in Finland and also with the International Computer Science Institute in Berkeley, California. And the title of the talk is IPv6, it's bad for your privacy, but I can start saying that well it's not that bad after all, after when you have arrived to listen to this. So it's kind of silly saying that you could say that IPv4 is bad for your privacy or internet is bad for your privacy, but you'll see what's my point. So to introduce the topic, so I'm actually going to talk about how the IPv6 address itself can be used as a covered channel. A covered channel is a mechanism that is not designed for communication, but can be used for that. So IPv6 address is designed for as an interface identifier for a host or for routing purposes to show the location of the host. But it's not designed to communicate any other kind of information. About covered channels in IPv6, so there is well some related work already in this. So I gave this talk before in military communications conference in last year and last year deaf gone, Murphy presented how to use ICMPv6 as a covered channel. So I have only read the abstract of that presentation so I don't know the actual contents. But then in privacy enhanced technologies workshop there was a paper about covered channels in IPv6 and the authors listed 22 different covered channels that are in IPv6 and had some discussion about how to detect these covered channels. Then in information hiding workshop there's a paper about how you can embed covered channels in IPv4 and how to make this undetectable and how to detect trivial covered channels. Then in CCS there's a paper about how to do timing covered channels so that's quite interesting because as you probably know IP is not a reliable service so it's not that trivial to send timed IP packets so that the recipient actually can deduce what's the actually timing pattern. And there's one other paper about covered channels in IP that I'm aware of but all these other work didn't point out this well when I say to it's rather obvious and simple covered channel. So in IPv6 address can be configured manually just like in IPv4 and we can use in IPv6 networks DHCP v6 which is equivalent of the IPv4 DHCP or we can use the stateless address of the configuration which is the source of this covered channel problem. So the IPv6 stateless address auto configuration is designed to auto-configure unicast IPv6 addresses so just a reminder that the IPv6 address basically consists of 64 bits of subnet prefix and 64 bits of the interface identifier which marks the particular host. So auto-configuration can be used so that you don't have to manually configure it or use DHCP v6 and you can acquire both link local address that you use in the local area network and the global address with the help of root advertisements. And auto-configuration procedure is quite simple. So a node chooses a tentative address candidate and then performs a duplicate address detection. So it sends this tentative address candidate to the network and if nobody replies that this tentative candidate address that the address is actually in use, the node starts to use the address. Or if somebody replies that okay I'm using the address, the node chooses another address and starts to use that, first sends the duplicate address detection and if nobody replies that starts to use the address. And then there's a very well-known privacy issue with this IPv6 auto-configuration mechanism that this has been addressed by the ITF. So by default still in the proposed draft standard RFC, the interface identifier is derived from the MAC address of the network interface. And this creates private problems in the sense that the interface identifier would be the same in every network that you would attach your computer. So it could, it actually could be used to correlate all traffic that originates from the node and possibly the user of the host. This correlation can be performed by the attacker that is in the path of the communicating peers or has access to the logs of the peers. And the RFC 3041 proposes privacy extensions to the address of the configuration. So basically the address can be chosen randomly instead of using the MAC address derived version. So this is pretty obvious. So since the interface identifier can be chosen randomly, it also contains useful information that can be used for an attack. So 64-bit is actually quite a big coverage channel. However, we need to assume that data can compromise the operating system, but well you probably all know well that how that can be done, so I don't need to go there. But okay, so as I mentioned, there is related work about these coverage channels. So there are quite a few possibilities, but why is this different? Why it's even mentioning, worth mentioning about? So the thing is that the IPv6 address is in every packet that you send to the IPv6 network. So for example, you could use TCP sequence numbers as coverage channels, but if you happen to use IP security ESP to protect your traffic, the outside attacker cannot see the TCP sequence number. So of course there are possibilities for coverage channels in the IP security too. And what I'm trying to say here is that since it's in every packet, so this is not that you include in the packet. So IPv6, for example, has optional headers that you could include and use as a coverage channels. What do you detect? You need to have this address in every packet that you send. And if you can choose it randomly, well I'm saying that there's actually no way to detect that somebody is using the coverage channel on the network if you're careful. You can of course in the operating system do stuff to detect it, but not on the network. So exploits for these coverage channels are there. So the traditional two-party communication, so Alice talks to Bob and Bob talks to Alice. So if you were in DEF CON last year, I think you saw a demonstration about this. But then there are these third-party attacks. So you can, for example, transmit secrets unknowingly for the user or do Big Brother surveillance. And I'll give an example of both of these attacks, but I'm emphasizing this point that of course you can do this kind of attacks in various ways. So for example, you could just open a connection to a server or whatever, but that's not very covered. So that can be detected on the network, for example, if an intrusion detection system perhaps. So for the first possible exploit. So in this scenario we need some way to identify the compromised devices. So this is kind of limited as you will see. So let's say that you have a laptop with the wireless LAN and you're using it. So the attacker has somebody somehow compromised it. Perhaps it's Malice's vendor or whatever or a worm that spreads on the wireless interface or whatever. So that's the base of these devices that are compromised and the MAC addresses. So you use the MAC address of the wireless link to identify the devices. So then you just passively listen to the wireless traffic and check if there are compromised devices nearby and then, for example, the IP address, the 64 bits, excuse me, contains, for example, the IP security or TLS session key. So encoded in some way. So this is currently, this can be done, for example, for triple this, so 56-by, oops, 56-by bit desktop. For example, this will not be that feasible when advanced encryption standard will use 128 bits by default or asymmetric crypto. So this, sending the keying material with just this covered channel is not that feasible in the near future anymore. So when we are migrating to symmetric crypto, that use better keys. But it's still feasible today. But the big product surveillance scenario, so this is more feasible. So I have just outlined the strawman scenario for this. So you can think many other ways to do the surveillance. So let's say that Big Brother has, well, it doesn't want that the users, well, he, it wants to know that if the users are accessing certain websites. So the compromised operating system then includes a list of the websites, the black list of the websites. And the web browsing is monitored by the operating system. And if the user happens to go to a website that is on the black list, the operating system does the attack that follows. So the next time the computer is rebooted, so the emphasis is that this kind of surveillance attack doesn't need to be that timely. So the Big Brother can wait that, okay, well, the user has gone to this kind of site. So next time he reboots the computer, it starts to announce this. So the next time the computer is rebooted, the IPv6 stateless address or the configuration configures the address to a predefined bit pattern. And the address will seem random. And when the address is changed, for example, if the user uses the privacy extension that way, that it changes more often than the default, it just will put another pre-con to a good bit pattern. And the device is thus marked so everywhere the computer is now attached, it will send in all the IP packets that, okay, I have accessed these websites. And of course we can see here that, okay, there's a possibility that by somebody accidentally, since the default way is to choose the address in random, so it's accidentally the pre-configured bit pattern, but I guess the Big Brother can sort these things out. And then, now that I have described the attack, so how can we mitigate this attack? So the obvious answer is that you do not use the stateless address or the configuration. Use the manual configuration or DHC6. And actually Tor would help when it's in IPv6. So if you use Tor, your address would be announced only into the nearest Tor node, so not to the whole network that you browse. For example, IPv6 network address translation, if it will come. So one of the things that have been said, but IPv6, that okay, there will be no network address translators, but as far as it has been on the news, so that many companies would like to have the similar things that are in IPv4 used. But one efficient mitigation is actually this so-called cryptographically generated addresses, so CGA. So these are defined in RFC 3972, and these are mainly used for secure neighbor discovery. And in CGA, the interface identifier is actually a hash of the subnet prefix, public security parameter and something else. And this actually prevents pre-competition of a suitable hash so that you can have the pre-configured bit pattern, because you actually cannot pre-competate for every subnet prefix the hash pattern that you would like. So if this CGA was just based on the public key, you could actually do it this way that you just install some public-private key pairs that the public key hashes to the pre-configured pattern. But this way you cannot actually pre-compute. But it's still possible, so if you have a list of these pre-configured bit patterns that you would like to hash this so you could use it, but it would need that you would need to create lots of public keys, so it's not that feasible anymore. So I don't have much time anymore. So in conclusion, the point of this talk was that, okay, we actually have quite a few of these protocols today that try to protect the privacy of the user by introducing random protocol identifiers. For example, session initiation protocol SIP has these privacy extensions and I don't know have you heard about HIP, but it has also these. So whenever we introduce these random protocol identifiers to protect the privacy of the user, we introduce also the possibility of covert channels that can be used by the Alice and Bob to communicate with some other traffic or can be used by a third party to compromise the confidentiality of the configuration or can be used to reveal any kind of information about the user of the third parties. And so in the end, as I said, the IPv6 is not that bad for your privacy compared to IPv4, but the stateless address of the configuration, the privacy extensions make possible to do other kind of privacy attacks. And I was, so the questions and answers are at room 108, but I think I have a couple of minutes still. So thank you.