Dissertation’s End

Cross-posted from the XeroCrypt blog

The last two weeks have been a clustersuck of getting the dissertation finished, having to review, edit and rewrite the better pages here and there, hoping the stack of paper will be turned into a couple of decent hardbacks by the deadline. The working title is ‘Secure IPv6 Communications across Multiple Untrusted Networks‘ (comes with state of the art interactive CD-ROM). Considering the huge deal I made over this last year, it should have been much better.

When I first started thinking about the project a while back, the idea was a group of proxy servers with different IP addresses that would change every 24 hours or so, and a software client that would select the first available one. The central problem was how to communicate those proxy addresses to the clients without those addresses becoming known to whoever’s blocking them. The Global Internet Freedom Consortium creates technologies like that.
Things took another direction after coming across that SecuraBit interview with Sam Bowne on IPv6, then The Second Internet (Lawrence Hughes). All the pieces were there for secure communications system even better than what I originally thought up, and so IPv6 became the focus of the project. Somehow those huge address blocks and IPsec tunneling between hosts can be leveraged to defeat both censorship and surveillance. Probably forever.

About half way through, it was becoming apparent the solution is theoretically very simple, and the main component of my system would be a software client – installed on the Internet-enabled devices, it would handle everything from encryption, IPsec, address management and a couple of other things. It also turned out the system could be used for point-to-point (or P2P) communications and multicasting, so the plan shifted somewhat from defeating censorship in the existing client-server Internet. Actually creating a working product is another matter, as I’m not that technically gifted yet. Certainly not gifted enough to develop the GUI in C++.

Essentially what we have is a design and some components for a client application that could be adapted for a range of things – military communications between PDA-equipped units, P2P social networking (the application database supports this), media broadcasting over IPsec to hidden groups, and even government personnel deployed in other countries could host reports on their own devices without adversaries even being aware of it. Sounds like pretty impressive stuff, but it won’t become relevant for another 8-10 years because the routers and everything in between must be IPv6-ready for this to work.

In the end the dissertation amounted to a colossal amount of research on Internet surveillance and traffic filtering (many thanks to the UWN Thesis blog), a fairly detailed methodology for developing and testing the countermeasures, instructions for setting up a fully IPv6-capable carrier routing system, and some of the main components for the software client.

IPv6 Secure Project – Development Stage

It’s been a while since I last posted an update, largely because the project’s been on hold for the last six weeks. Basically the second year of the course was mainly about theoretical stuff, like policies, compliance, management, legislation, etc., and the third year got very technical (and practical) from day one. And it’s not a bad thing either, as I expect any infosec professional to have at least some experience and a decent understanding of enterprise network and server configuration. So, that’s my excuse.

Roughly a month ago I had the basic secure messaging client application working, and hopefully I can get that communicating with the network. Later it can be modified for audio and video comms, and perhaps even a social network could be built around it someday.

Routing system, minus the cabling

Routing system, minus the cabling

Getting hold of the equipment for the development stage won’t be a problem, as I initially expected. I now have a carrier grade routing system at my disposal, which means the countermeasures can be tested with a collection of Cisco 2800 routers, an Adtran Atlas 550 Integrated Access Device (IAD), and TCP and IP filtering layers. The Adtran is what’s going to simulate the ISP and Internet.
By the end of January 2013, the whole thing should simulate multiple clients communicating between networks, tunneling their comms through whatever interception and filtering exists between them. It’ll be a form of P2P communication, but there’ll be nothing to mark it out to ISPs as such.

Before that happens, I’ll need to somehow configure the routing system, which must be done via serial ports and Telnet sessions, which is apparently quite easy.

What is Packet Inspection?

Originally posted on the XeroCrypt Blog

Packet inspection is something we’ll read about a lot, especially with the Communications Data Bill going through at the moment, and other stuff. It’s directly related to the how of surveillance, traffic management and sometimes censorship. The technology for intercepting Internet traffic and scanning content is commercially available, but who is using it, and how is it being used? As it happens, Deep Packet Inspection (DPI) is deployed widely enough that there’s a good chance everything going over the Internet unencrypted is being read as it crosses the public Internet.

An Overview of Packet Inspection
First it’s important to recognise there’s a difference between packet inspection and Deep Packet Inspection (DPI).
Invented around the mid-1990s, packet inspection was originally for use in a stateful firewall/IDS setup, which is useful where applications might change the ports they’re communicating on, or where someone might attempt to tunnel malicious traffic through a standard port – things a basic port blocking firewall isn’t good at.
This looks at protocol headers and port numbers to determine what services are communicating and how, which in practice means looking for specific bits that represent port numbers, synchronisation, flow control, etc. in a bitstream that makes up the TCP packet, so it’s fairly easy to build that function into a programmable IC. In fact, it shouldn’t be too difficult for an electronics enthusiast with the right equipment and a little programming skill to build something that does this. Even some entry-level routers with just 2-4 MB memory include basic packet inspection capabilities as a Quality of Service (QoS) feature for managing traffic on a local network, although this can also be done by Ethernet port or MAC address.

Some years later the technology was developed enough to scan the TCP payload in real-time with negligable latency, and so we have Deep Packet Inspection that looks at the content of whatever’s being communicated. Although this provides some additional security and traffic management benefits, this is where we quickly run into problems with surveillance and censorship, as Nate Anderson explains in his detailed article:
‘Looking this closely into packets can raise privacy concerns: can DPI equipment peek inside all of these packets and assemble them into a legible record of your e-mails, web browsing, VoIP calls, and passwords? Well, yes, it can. In fact, that’s exactly what companies like Narus use the technology to do, and they make a living out of selling such gear to the Saudi Arabian government, among many others.’

The capabilities of a DPI setup depend largely on the implementation, in particular the location where it’s installed, how much traffic goes through it, and whether the equipment’s used for stripping and warehousing certain packets in a database. For example, an intelligence agency or ‘behavioural advertising’ firm might strip out traffic containing keywords and store it for later analysis.
DPI vendors seem reluctant to reveal much about how their products perform in the real-world, such as the data rates they can handle and their effects on latency. To actually do this in real-time without substantiallly affecting latency, it could only realistically be used for comparing payloads against signatures, or determine the general behaviour of traffic through statistical analysis, but again this could still be used in deciding which packets to archive for later analysis. It’s likely those functions must somehow be built into the hardware itself.

DPI’s Use in Targeted Advertising
DPI has already been used against tens of thousands of Internet users in the UK several years ago, and it was actually done by a ‘behavioural advertising’ company called Phorm. Unlike conventional methods of targeted advertising, Phorm gathered information about peoples’ browsing activities by actually scanning the content of whatever web pages they were visiting, using some DPI equipment installed at the service providers’ exchanges and a cookie that linked the collected data to peoples’ browsers. In other words, Phorm was intercepting their private communications and probably breaking a few laws in doing so.

Several ISPs, notably BT, helped Phorm to secretly trial this without informing their customers, and it was discovered when someone noticed their connection was being redirected. There was enough outrage and campaigning against this over the next few years that the ISPs eventually cut their ties with Phorm. In some sense this might have been good thing, as it made the public more aware of the existence of DPI and lessons were learned, hopefully among those who towed the ‘nothing to hide, nothing to fear’ line.

The Legal Stuff
So, was Phorm acting illegally? Could it have been prosecuted? Two laws relevant here are the Data Protection Act and the Regulation of Investigatory Powers Act 2000. Generally the Data Protection Act prohibits the collection of personal data without the data subject’s consent, unless it’s absolutely necessary and in the interests of the public or those of the data subject. Although there are many exceptions to this, none of them seem relevant to what Phorm was doing. Companies like it are in the business of selling that data to other third-parties, so there’s another possible violation.
RIPA is less ambiguous, stating that it’s an offence to intercept telecommunications ‘intentionally’ and without ‘consent’ from the sender or recipient, unless a court order of some sort was involved. My interpretation is that Phorm would have needed the prior consent of the ISPs’ customers, or to gain the consent from the owners of every server those customers were in communication with. That consent might have been given unknowingly at some point, perhaps by signing something their ISPs dropped through the letter box, or by entering a competition without reading the small print. An opt-out policy certainly wouldn’t have made it legal.

Traffic Management
Another (perhaps the most common) application of packet inspection and DPI is traffic management, and I’m still undecided on the issues of that in relation to privacy and net neutrality. It’s a short fix for a problem that’s going to get much worse – there’s a real limit to the amount of data the infrastructure can carry, and it would be unfair if people couldn’t access critical services like email, Twitter and MySpace because most the bandwidth was taken up by certain ‘consumers’ expecting an unlimited bandwidth service with stupidly high definition media. Anyone who’s been reading the Networking+ magazine will also know there’s also a colossal amount of other corporate WAN-related crap going across those wires that’s defined as ‘critical’, and the peak usage times (somewhere between 5pm and 8pm) are probably the result of an overlap between that and non-corporate traffic.
This is the basic reasoning behind traffic management by ISPs with more customers than they can support, why ‘unlimited’ services are a myth, and why net neutrality, however desirable, might be unacheivable without some feats of engineering.

Encryption is Important
Today it’s no secret that commercial DPI equipment is being commonly used for a variety of reasons, whether it’s for detecting copyright infringment, managing Internet traffic, ‘behavioural advertising’ or surveillance. Where DPI has become a security risk, countermeasures were quickly used. I could argue that anything going over the Internet unencrypted is fair game when it comes to interception, because it’s out there on the public Internet for anyone with the resources to capture. People have kind of accepted that, and the Internet is adapting to this problem – 15 years ago hardly anyone was using encryption, and today the major sites are accessible over HTTPS/SSL. I can imagine encrypted connections and IPSEC will become standard for any Internet exchange in the next few years, which in turn will make effective DPI-based traffic management much harder to achieve. We’ll certainly have a far more secure Internet, but the effects of making legitimate DPI ineffective remains to be seen.

Time to Get Started

The project proposal was originally going to be a formal graded presentation, but was more of an informal chat with my dissertation supervisor, who’s someone with a vast amount of expertise in networking, telecommunications, the Internet and its history, and basically everything this project covers.

It’s going very well, so far. He seems to really like the idea, although there could be some issues over the legalities of encryption, breaking through firewalls and whatnot. Except I’m not really bothered about that – it’s about confidentiality, integrity and availability of comms, regardless of content. We also had very similar thoughts on how the system (if it materialises) could potentially be developed further into a stealth network, making the already encrypted traffic almost impossible to block, intercept or trace.

Some weeks ago I came up with a very simple and workable idea for yet another secure messaging system. I’ve already made a lot of progress with it as a stand-alone project, but it might be included in the dissertation.

An Overview of IPsec

Cross-posted from my personal blog.

IPsec is much more than a single protocol, so it’s neither easy to understand or explain. It’s actually a set of open standards and functions developed to be interoperable between any two points on the Internet.

Short for Internet Protocol Security, IPsec provides confidentiality, integrity and authentication for communications between networks, and between endpoints when IPv6 is deployed. It was actually developed as a native feature of IPv6, but there doesn’t seem to be anything ‘mandatory’ about it, which is what numerous other sources are stating. As we’ll see, the only obvious difference between IPv4 and IPv6 in relation to IPsec is Network Address Translation. We’ll see why that’s important.

There are two modes of use for IPsec: In Transport Mode, only the TCP payload – the content of the traffic – is encrypted, while all other components such as headers and routing information are unprotected. The more commonly-used TLS/SSL might have been developed simply to make this form of encryption more convenient and readily implemented.
In Tunnel Mode, the entire TCP/IP packet is encrypted and encapsulated within another packet. This outer packet is routed to the destination IPsec tunnel gateway, decrypted and forwarded.

In order to understand the basics of how IPsec works, we only need to look at four central components:
* Authentication Headers (AH) provide integrity and authentication.
* Encapsulating Security Payload (ESP) provides confidentiality, authentication and integrity.
* Security Associtions (SA) provide the algorithms and data that enable the use of AH and ESP operations.
* Internet Security Association and Key Management Protocol (ISAKMP) for authentication and key exchange.

Authentication Header
The Authentication Header (AH) ensures integrity and authentication of IP packets. It protects the IP payload and all header fields, except for those that might be altered during transport. It’s mainly used for authenticating the sender of the packet, and for detecting any alterations to the payload as it was routed between the source and destination.
In Transport Mode the payload is hashed, and an integrity check value is placed in an AH header field. In Tunnel Mode, an Integrity Check Value (ICV) is generated for the whole encapsulated packet. At first, it appears anyone could intercept this, alter the payload, rehash it and put the new Integrity Check Value in the header. To eliminate this possibility, both parties share a secret key when establishing the connection (I’ll come to this in a minute), and that secret key is hashed alongside the payload to generate the ICV.

Unfortunately IP addresses are also included when generating the ICV, which is what makes this component of IPsec incompatible with Network Address Translation, so this only works between IPsec gateways until IPv6 is fully deployed.

Encapsulating Security Payload
The Encapsulating Security Payload (ESP) can provide authentication, integrity and confidentiality of TCP/IP packets, working in either encryption only or authentication only configuration. In Tunnel Mode, the entire encapsulated packet is protected, and but the authentication method here only covers the payload and ESP headers. It also adds some padding to improve the efficiency of whatever block cipher might be used. Anyone intercepting the traffic won’t be able to determine the payload or its type.

Together, AH and ESP provide the essential components of a VPN connection when used in Tunnel Mode between two gateways. When implemented alongside IPv6, this type of connection could be made between two clients on separate LANs, which is currently impossible with Network Address Translation.

The Security Associations Database and Key Exchange
Security Associations are simply the authentication and encryption algorithms being used for an IPsec connection, plus the keys. They are initialised as the IPsec link is established, using the Internet Association and Key Management Protocol (ISAKMP).
This information is maintained in a Security Associations Database (SADB), hich specifies the following:
* Authentication algorithms
* Authentication secret
* Encryption algorithm
* Secret key
* Key exchange parameters

A Security Association is one-way, so at least two are required for secure communication between two entities, and the SADB should potentially scale up to support secure multicasting over IPsec.

As with any secure connection, the problem is two endpoints must share a secret key without a third-party intercepting it, and this must happen before any IPsec encryption or authentication is set up. With TLS/SSL, this is acheived using asymmetric encryption to exchange a symmetric encryption key. With IPsec, the common method is the Internet Key Exchange (IKE/ISAKMP), which is normally based on the Diffie-Hellman algorithm.

I’ll probably be in a better position to explain how the Diffie-Hellman algorithm works if I add it to the XeroCrypt software. Basically two communicating parties each generate a random number, which is a secret key used in a mathematical operation to generate two more values – one public and the other private. The two entities exchange their public values, and use them in another mathematical operation that should generate the same result on both sides – this is the shared secret key.