No one shall be subjected to arbitrary interference with his privacy, family, home or correspondence, nor to attacks upon his honor and reputation. Everyone has the right to the protection of the law against such interference or attacks.
—Universal Declaration of Human Rights, article twelve
Before we look at how to use Openswan to secure and protect your communications, we will first go over a little of the history of cryptography, and the reasons why we are now able to discuss and use a technology that was until recently considered a vital military secret. Three important events made this possible: the creation of the Internet, the (re)invention of public key cryptography, and the creation of free-to-use software.
Another important issue we will cover in this chapter is the legal side of using Openswan. While the creators of Openswan grant everyone the right to use the product, some governments have additional laws governing cryptography. Before you use, give, or sell Openswan, you should make sure it is legal for you to do so. Though the authors are no lawyer, we hope this chapter will provide enough information for you to properly consider this aspect.
The history of cryptography and therefore the history of IPsec and Openswan involve some level of politics.
Today, a lot of what we do is logged somewhere. Our cellphone companies keep a database of where we have been and whom we talked to. Some countries, not only totalitarian regimes or theocracies, but Western democracies as well, are implementing data retention laws to force ISPs to store a copy of everything their customers do for anything from a number of years to indefinitely. Companies gather massive amounts of data using discount cards and RFIDs, turning citizens into statistical consumers. Certain well-known companies have been known to employ the tactics of spyware and viruses, deliberately infecting customers' PCs with rootkits to monitor their activity, and even control what they can do with their own computers, all in the name of anti-piracy.
If you play the online game of World of Warcraft, every title bar your computer displays, including subjects and recipient names of your emails, will be sent to the vendor, Blizzard, to ensure you "do not cheat" in the game. Governments have made secret deals with printer vendors such as Canon, who secretly implemented a 'fingerprint' on pages produced by their color printers in almost invisible yellow dots that encode the printer's serial number, as well as the date and time the page was printed. Anonymity and privacy has never been so far away. Neighbors can easily watch what you do on your wireless network at home. We are leaving our digital footprints everywhere, for better or worse. The Big Brothers (and even more little ones) are here to stay. Everyone needs to take their precautions. They should, and now can, use strong cryptography.
However, this freedom for the good guys also means that organized crime, petty thieves, vandals, frauds, and terrorists can use cryptography. This fact is often cited by governments to justify regulations to limit the use of cryptography for private citizens and to increase surveillance. Unfortunately, the "privacy versus security" argument is a persuasive one, although it is in our opinion a fallacy at best, and a deliberate misrepresentation at worst. The argument is framed with manipulative questions such as, "Would you be willing to sacrifice some privacy to increase your security against terrorism?" However, the truth is that privacy and security are separate issues. One need not be sacrificed for the other.
We will never be able to hide the information needed for terrorists to do harm, but we can show potential terrorists what a true free world has to offer. And a free world is not one where governments and corporations look at and predict all your steps along the way so they can manipulate, intervene, or maximize profits. Privacy is essential to what makes us individuals. It is a Human Right.
Cryptography does not just provide privacy; it also provides security. Using cryptography we can ensure that we are talking to whom or what we intend, whether it is a person or an ATM machine. We can ensure that no one else is eavesdropping on us, and that no one else is pretending to be us. By encrypting data, we prevent information leakage. We protect against manipulation of our data stream. The security works both ways. We can trust them, and they can trust us. Security gives us integrity.
The Internet was, in fact, not invented by Al Gore. If one could bestow the invention of the Internet onto a single person, this person would be Jon Postel. However, he is not considered as the inventor of the Internet. By most, he is considered the first Guardian of the Internet.
The key to the Internet's success is that these millions of computers are able to communicate to one another without disrupting the communications of other computers trying to accomplish the same thing. At the core of that success is the Internet Protocol (IP). Another essential part of the Internet is the lack of central control, and the absence of any third-party approval—be it governmental or corporate—before one may communicate.
The Internet is an international network. It is not owned by any organization. And though some governments would like to believe otherwise, it is not under the control of any national or international governmental body either. No single individual or company dictates how the Internet should be run or evolve, and no single restrictive non-free patented technology is necessary to communicate using the Internet. For this to continue, many parties need to agree on protocols, and on top of that, need to recognize and adhere to these protocols. These protocols usually have many options, which all parties communicating need to agree upon. Compare this to the 'car driving' protocol, where everyone agrees to stop for a red light, and to continue on a green light.
These formal registrations used to be maintained by one man, Jon Postel. The task was later delegated to a more formal group of technology people, the Internet Assigned Number Authority, IANA. In 1998 the US Department of Commerce (DoC) released two policy documents that called for the creation of a new body to govern these core functions of the Internet, which led to the creation of the Internet Committee for Assigned Names and Numbers, ICANN.
ICANN's creation was not very well received internationally, as it gave the US full control over the root of the Internet. As such, worldwide engineers largely ignored this non-technical political organization. An attempt was made to gain more widespread acceptance by reforming ICANN. Though this process started in 1998, it took years to complete. A famous Green Paper and White Paper with recommendations were written, leading to a Memorandum of Understanding (MoU) between ICANN and the DoC.
The 'ICANN at large' program, which allowed every individual to participate with ICANN and elect three board members, took two years to set up and was launched in 2000.
Two of these newly elected directors—Karl Auerbach, a legal scholar and Internet veteran who had been involved with the Internet before the Internet Protocol existed and Andreas Mueller‑Maguhn from the German hacker community Chaos Computer Club—tried to get a true reform going but they were instantly blocked by the directors that had not been elected by the public. They were not even allowed to see the books of the organization they represented, and for which they were formally held responsible for.
The Electronic Freedom Frontier (EFF), a digital rights organization, assisted Auerbach so he could sue the Board of Directors in 2002. After he won the case, ICANN squirmed until finally a judge ordered ICANN to allow all the directors to see the books. However, while ICANN stalled handing out this information, it changed its own rules and more or less fired the At Large elected directors instead. It was pretty much apparent that ICANN was to be kept a US-only affair, and the international Internet community responded in a way that became typical of the Internet. It started to collectively maneuver around ICANN.
ICANN was supposed to handle three separate tasks: protocol registrations, IP address allocation, and top-level domain (TLD) management.
Protocol registrations are really done by the IETF and IANA, and ICANN just stamps its approval. It completely lacks the skill or desire to interfere with this process.
The IP address allocation is really done by the Regional Internet Registries (RIRs), which are pro-actively ignoring ICANN completely. This became painfully obvious when the three major RIRs, ARIN (for North America and South America), RIPE (for Europe, Africa, and the Middle East), and APNIC (Asia and the Southern Pacific), set up the Number Resource Organization (NRO). They no longer acknowledged ICANN as the central authority for handing out IP allocations to the RIRs. It was nothing less than a coup d'état.
For technical reasons, there should not be more than thirteen name servers for any given domain, including the root. Otherwise, a DNS query answer would not fit into a single UDP packet, greatly delaying the answer of DNS requests. These name servers, eleven in the US and two in Europe, were historically placed at locations with the best Internet connectivity. They were run by volunteers, often at the big universities. When ICANN formally received control, they only actually got control of one of these root name servers, the so called 'A' root server, although this is the ultimate master root server. The other twelve servers are set up to pull data from the 'A' server. The 'A' server is currently run for ICANN by Verisign.
The reliance of the entire Internet on only thirteen servers has been a major concern for those involved in Internet design. A new protocol was created, called ANYCAST. In essence, it allows an IP address to exist at multiple places at once, and a computer requesting that IP address will be directed to the nearest ANYCAST IP address. The most important non-US root server, 'K', is run by RIPE-NCC, the operational branch of RIPE. Using ANYCAST, it currently resides in multiple places, including the two biggest conglomerations of Internet connections, LINX in London and the AMSIX in Amsterdam. An important side effect of ANYCAST was that the international community is no longer as dependent on the 11 of the 13 root servers that are based in the US and which are still in large part formally under government control. It has greatly reduced ICANN's influence over the root. The 'K' root server is a prime candidate to split off from the 'A' server if for some technical or political reason such a change becomes necessary.
ICANN is left with only the top-level domain management. This task is perhaps the most politically loaded task, and not as technologically neutral as handing out IP addresses or Internet protocol numbers or running the root name servers.
There are two kinds of TLDs, country code TLDs ("cc:tld") and generic TLDs ("gtld"). The cc:tlds are fairly straightforward. There are already international ISO procedures for this. Every country receives a two or three letter representation. The US has 'us', the Netherlands has 'nl', and China has 'ch'. These translate one to one to the top-level domains, .us, .nl, and .ch respectively.
ICANN has no real say in this matter either. Whether Taiwan is recognized as a separate country or as a Chinese province, for instance, is not something that ICANN or even the US government will have the final say on.
What's left under ICANN's control is management of the generic top-level domains. The most common ones are .com, .net, and .org. ICANN created a few more, such as .info, .biz, and .museum. But after the 'dot com' hype was over and Internet stock lost its magic (and power), no one was really interested in these obscure generic TLDs. For a few years, no new ones were created. Then in mid-2005, ICANN was about to approve the top-level domain .xxx for adult websites. The US Department of Commerce, under pressure from the religious-influenced Bush administration, forbade ICANN from doing this, for the first time using their formal control over ICANN.
The issue threw the public spotlight onto the government's influence over ICANN. There was a national and international call for a truly independent body to take its place, perhaps UN-based. Whether such politics will have any real technical effect on the Internet is not known, but it is not unthinkable that the root as we know it now will cease to exist, to be replaced by several new roots, under the control of various international organizations.
One thing that is clear is that Internet governance is set to change, affecting the creation of new top-level domains and the creation or deletion of cc-tlds. The creation of .biz and .info has been largely ignored on the Internet as a whole, and a similar fate is to be expected for the newly approved .mobi domain, a domain intended for mobile phone content. Some see these domains as milk cows for ICANN. Even Tim Berners-Lee, inventor of the World Wide Web, was strongly opposed to this domain, as it broke a fundamental paradigm of the Web, namely that content should have a proper device-neutral markup so that any device can decide how best to display the information. The .eu domain, originally planned for EU organizations, will soon be opened for everyone, but whether it will become an alternative for .com is unknown. Lastly, we should not forget the grassroots community that was responsible for creating the Internet. The technicians still have a remarkable influence envied by the political powers.
Those people involved in the birth of the Internet never talk about the Internet as having been 'invented', as it was not. It was engineered by many people. It incorporates many, now standard, protocols for communicating in many different but specific ways, suitable for a wide range of different applications. The creation of the Internet was not only a breakthrough on the technological front, it was also a tremendous breakthrough sociologically. It all started with a handful of people meeting in a single room to talk about how to connect their computer networks, and grew to become an international ad hoc effort with the least amount of formal and official structure possible. In short, it was a meeting of technicians, not a meeting of politicians.
The fact that no formal organization is responsible for the design and development of the Internet does not mean that the Internet is in a perpetual state of chaos and near collapse. On the contrary, the Internet functions with extreme reliability, made possible by the ad hoc organization of the IETF, the Internet Engineering Task Force. And what makes this even more unique is that the IETF does not exist. There is no legal entity called IETF. The IETF solely works by the existence of two processes and a mantra.
The mantra that describes the goals of the IETF is concrete and precise: Consensus and running code. The two processes that make this possible are the mailing lists that are organized in 'working groups', and the quarterly gatherings of people at IETF conferences around the world, which give everyone and anyone, even those not backed by a large organization, a chance to attend a few meetings per year. Anyone can join a working group mailing list and become part of this process. There are no fees involved. The conferences are usually sponsored by vendors of networking equipment, and cost about $1500 to attend. These fees are to recover the rent of the conference facilities and administrative costs.
People attend and speak at the IETF as individuals, and not on behalf of their employer. In fact, many IETF regulars have switched jobs repeatedly without letting it impact their work within the IETF.
The procedure followed by the IETF is relatively simple. When some people identify a need for a new protocol to solve some technical issue, they can form a working group. They pick a chairman, and set up one or more mailing lists. They create a charter that formulates the problem and then discussion on the mailing lists and at IETF conferences proceeds until the working group reaches a consensus on the design. This process generally sees the working group publish several draft documents. At some point, a working implementation will be written by someone, some group, or vendor with a specific interest in the new protocol. Once the working group is confident enough that no flaws can be found in the protocol, and when those claims are backed by at least two independently written functioning (interoperating) implementations of the drafted protocol, it will be submitted to the Internet Engineering Steering Group (IESG). This group consists of individual experts who have proven their knowledge and skills over a prolonged time at the IETF. They are expected to be very knowledgeable, and capable of confirming the working group's claims. For certain essential core protocols, the process might also involve the Internet Architecture Board, another group of IETF veterans.
Once this group gives its approval to the new protocol, the draft protocol needs to be assigned a unique identifier. Historically, though now somewhat badly, named, this official registration is called a Request For Comments, or RFC. Furthermore, there are usually options or parameters of the new protocol that need some kind of central registration as well. These will receive their unique registrations in one of the IANA registers. For example, the list of ports used by certain protocols such as HTTP or SMTP is such a register.
This process of finalizing is done by the RFC Editor. The first RFC Editor was Jon Postel, but nowadays the RFC Editor is actually a small group of varying people. The RFC Editor will stamp the new protocol with its final official RFC registration number. Vendors who have not yet implemented the draft protocol can now go and implement the final RFC-specified implementation. Sometimes, vendors get together in bake off events. There, they will test their implementation with those of other vendors, to see if they interoperate correctly. Once they do, the new protocol is ready to be included in their new equipment or software.
This is exactly the same procedure that the IPsec protocols went through, before becoming RFCs. Due to the complexity of IPsec, there are over 20 RFCs describing the various parts of the protocols. An overview of those can be found in Appendix D.
At some point, even in the old days of the first RFC Editor, Jon Postel, it became clear that the IETF had to take a stance on security, cryptography, and whether or not its protocols should have backdoors or key escrow built in. Some people noticed that the RFCs had skipped one particular RFC number, the number 1984. In August 1996, the IETF released RFC 1984, expressing the view of the IETF on cryptography and key escrow. The IETF strongly opposed any backdoors or key escrow feature in its protocols. Any attempt to make a protocol weaker just to assist a government in online surveillance was considered extremely dangerous. This was not a political opinion, but purely motivated by technological reasoning. The IETF would not hamper its protocol design. An excerpt from RFC 1984:
The Internet Architecture Board (IAB) and the Internet Engineering Steering Group (IESG), the bodies which oversee architecture and standards for the Internet, are concerned by the need for increased protection of international commercial transactions on the Internet, and by the need to offer all Internet users an adequate degree of privacy.
Security mechanisms being developed in the Internet Engineering Task Force to meet these needs require and depend on the international use of adequate cryptographic technology. Ready access to such technology is therefore a key factor in the future growth of the Internet as a motor for international commerce and communication.
The IAB and IESG are therefore disturbed to note that various governments have actual or proposed policies on access to cryptographic technology that either:
(a) impose restrictions by implementing export controls; and/or
(b) restrict commercial and private users to weak and inadequate mechanismssuch as short cryptographic keys; and/or
(c) mandate that private decryption keys should be in the hands of the government or of some other third party; and/or
(d) prohibit the use of cryptology entirely, or permit it only to specially authorized organizations.
We believe that such policies are against the interests of consumers and the business community, are largely irrelevant to issues of military security, and provide only a marginal or illusory benefit to law enforcement agencies, as discussed below.
The IAB and IESG would like to encourage policies that allow ready access to uniform strong cryptographic technology for all Internet users in all countries.
RFC 1984 has been complemented by RFC 2804, Policy on Wiretapping, where the IETF announced its stance that wiretapping had no place in the protocol standards, and should be achieved using alternative means. This position was not based on a consensus of political opinion, but was based purely on technical arguments.
In the late eighties, with the increased use of the Internet, then still mostly limited to governments, military, big corporations, and universities, the friendly nature of the Internet and its old trust in everyone was disappearing. Protocols such as Telnet and FTP that used plaintext passwords were becoming a big problem. The Internet was becoming too big to trust.
Everyone was further abandoning expensive secure private leased lines in favor of cheaper Internet connections, just as now people are switching from classic phone lines to Voice over IP telephony. These things all need security and they need privacy. In other words, they needed cryptography.
Cryptography has always been enshrouded in secrecy. What started as the art of concealing a secret has now bloomed into protecting secrets out in the open in plain view of everyone, using near-unbreakable mathematical formulae. Of course, the early adopters of these technologies were the military, but in the 70s it became clear that companies would need cryptography, and today just about everyone is communicating using electronic means, and has a need for privacy.
Researchers at IBM invented DES, the Digital Encryption Standard, and the NSA gave in. They allowed American companies to use DES, and even suggested that IBM slightly change its new encryption scheme, to make the protocol far more robust against a certain attack than it would have otherwise been.
One by one, all inventions made secretly within the military were being re-invented by non‑military cryptanalysts. And new algorithms and ciphers were being designed at universities and private companies. Rivers, Shamir, and Adelman invented RSA public key encryption. In 1976 Diffie and Hellman came up with a technique which has become known as DH key exchange, enabling the safe exchange of public keys. Unbeknownst to them, the technique had already been discovered a few years earlier by Malcolm J. Williamson of GHCQ, the British version of the NSA, who kept it secret. Phil Zimmerman wrote PGP, the first simple-to-use encryption program for the PC. And in 1994 Bruce Schneier published his book on the once-secret science of cryptography, completely letting the genie out of the bottle. The book, Applied Cryptography (John Wiley & Sons, 1995, ISBN 0-471-11709-9), quickly became the standard work for anyone who needed or wanted to learn and understand cryptography.
Under the Clinton administration, the US government adopted a strategy of containment to control the spread of unbreakable cryptography. The idea was to allow a broken cryptography standard to be used by the general public, with a built-in backdoor for governmental use. The Escrowed Encryption Standard, with its now infamous Clipper Chip, was signed into law in 1994.
The Clipper Chip was designed by the NSA and implemented the Skipjack algorithm, which contained a backdoor accessible to the US government. Perhaps not surprisingly, few foreign entities embraced this crippled security. Other governments and organizations, especially in Europe, were working hard on making unbreakable crypto, and in the end the US Government gave into pressure and the Clipper Chip never saw the light of day.
Encryption methods not requiring the Clipper Chip were still legal for US companies and citizens, but in order to try to prevent everyone else from using cryptography, cryptography was classed as munitions, an item on the list of controlled weapons and resources that may not be exported to other countries without explicit government permission. Cryptography was treated exactly the same way as nuclear bombs.
But the export laws could not prevent the world from obtaining cryptographic software independently. The European countries still do not recognize software patents, meaning encryption algorithms patented in the US can be freely used by anyone outside the US. This included the RSA and IDEA algorithms, both used by the PGP software, though Phil Zimmerman never actually licensed RSA for this.
Other countries, especially Europe and Israel, were working hard to catch up with the US. Companies from these countries were free to sell strong cryptographic software to the US, but US companies were not getting the government permission they needed to export their products outside the US. The result was that many products existed in two versions: a US version, with full encryption, which usually meant 128-bit encryption, and an international version, which was usually limited to 40-bit encryption. This was most visible when Netscape invented the Secure Socket Layer (SSL), a method allowing a browser to talk securely to a web server without anyone being able to eavesdrop on the content of the communication. This was essential for doing business on the Internet, allowing users to give a web server their credit card information with the confidence that it could not be read by an unauthorized party.
Netscape had to release two browser versions, one with 40-bit encryption and one with 128-bit encryption. But since its browser program was freely downloadable, it was impossible for Netscape to restrict the 128bit version to the US alone, but it still needed to make some effort in order to comply with the US export laws. It was not really practical to stop the spread of the 128-bit encryption version of their browser. People mirrored the software in Europe, others wrote software to tweak the 40-bit version to enable its 128-bit encryption that was built into the software binaries.
The Linux Debian distribution started a non-US branch, which contained the cryptographic software, and only non-US Debian download sites could have this software. Cryptography in the Linux kernel existed for a while as a separate patch on a non-US site, www.kerneli.org.
Pressure from researchers at universities in the US increased. With help of the EFF, Prof. Bernstein, then still a graduate student at Berkeley, sued the US government in 1995, claiming that talking about cryptography was a right protected by the First Amendment. He followed up with another lawsuit in 2002 claiming that "it's inexcusable that the government is continuing to interfere with my research in cryptography and computer security." But while Bernstein was fighting to liberate crypto, someone else had found a loophole in the law.
The munitions laws that restricted cryptography were focused on software. Bernstein was suing the US government so he would be able to teach cryptography in his classes. But exporting paperwork, such as research material, was never covered by the export restrictions. Two groups of hackers, the Dutch 'Hacktic' group and the San Francisco 'Cypherpunks', took on a project and printed the entire source code of the PGP program, with checksums on every page.
They then took this stack of paper and flew to The Netherlands to an open-air hacker event called 'Hacking In Progress'. They scanned the papers, ran character recognition software on them, manually fixing letters that were not read correctly, aided by the checksum printed on each page. At the end of the five-day event, the PGP source code had been reconstructed in digital form. PGP had now been legally exported from the US.
The export laws came under more and more pressure, mostly from US companies who were crippled in selling their software abroad. They could still only sell crippled 40-bit encryption outside the US, and nobody wanted it, since a lot of European software with strong cryptography had become commercially available. Then the EFF put the final nail in the coffin of weak crypto.
In a basement room of John Gilmore in San Francisco, a machine was built, the DES Cracker. It consisted of a Linux machine that acted as console for a large array of specially-designed DES cracking chips. The costs, including all R&D, were $250,000. On July 18 1998, it took 'Deep Crack' only three days to crack RSA Laboratory's 'DES Challenge II'. On January 19 1999, it cracked the 'DES Challenge III' in 22 hours. The previous record on that challenge had taken 56 hours using 100,000 PCs worldwide. The US government could no longer claim that DES was good enough for encryption. A few months later it became clear why the US government wanted the international community to use weak crypto.
In April 1999, Duncan Campbell, a British journalist, handed over his report entitled Interception Capabilities 2000 to the Director General for Research of the European Parliament. Campbell reported that, after years of research all over the world, he had uncovered the existence of Echelon, a massive top-secret network of interception capabilities built and operated by the US and the UK, aimed at their allies in Europe. Tension between Europe and the US rose. Accusations of industrial espionage were highlighted in a case where US airplane manufacturer Boeing underbid the European Airbus in a very large contract, apparently after having inside information handed to it by the NSA.
In 1999, the US finally relaxed the export laws covering cryptography. Under License Exception TSU pursuant to 15 C.F.R. Section 740.13(e), cryptographic software could now be exported freely to anyone in the world, with the exception of the Usual Suspects (Iran, Iraq, Cuba, and a few other countries). It allowed the publication of cryptographic software on the Internet, even if it meant that people from those blacklisted countries could download it as well. But there is an emergency break. Formally, to this day, the President of the United States can still at any time issue a decree that limits or bans the export and use of cryptography.
Though this seems a great concession, it was merely the formalization of the existing situation. A new phenomenon had given rise to an immense amount of cryptographic software being available on the Internet, following something started in 1984 by a former MIT graduate, Richard Stallman.
Richard Stallman wanted to share his software with others. He wanted to continually improve the software, and share these improvements. However, no vendors were interested in giving away their software; they wanted to sell many copies to everyone. In 1982 Stallman began to write alternative software from scratch—software that everyone was allowed to copy and modify as they saw fit. He wrote various key tools that we now take for granted, as part of his 'GNU: Gnu's Not Unix' project. He wrote the GNU C compiler, GNU make, Emacs, and much more. In 1985 he founded the Free Software Foundation.
He had rewritten most of the tools that came with the commercial Unix operating systems; all he needed was the core of the system itself, the kernel. As it turned out, Linus Torvalds from Finland had just written that part and released his Linux kernel on 25 August 1991. The GNU project tools, together with the Linux kernel, provided a completely free operating system for the first time ever. In parallel with that, another Unix operating system, the AT&T BSD code, was being rewritten. Though the source code was available, it still came with restrictions, and you needed to buy a license from AT&T. NetBSD released its first distribution in April of 1993, which contained no AT&T code. Around the same time, another BSD variant, FreeBSD, was also released.
The BSD variants allowed anyone to do whatever they wanted with the code, with the provision that an acknowledgment in the form of a copyright statement be visible in all products that used BSD code, a requirement that was eventually dropped as well. However, GNU software came with a strong philosophy. Though both the BSD people and the GNU people wanted to share their software with others, and collectively improve software and allow everyone the freedom to run, distribute, and change that software, the fundamental difference was that those in the GNU camp wanted to ensure that these freedoms would not be lost in the future. They wanted to prevent someone taking their code, and releasing an improved version that was licensed under non-free terms.
For this purpose, Richard Stallman created the GNU Public License (GPL), which applied copyright in a completely different way than usual. Normally, people use copyright to prevent their works from being distributed without their consent. The GPL copyright statement, also called copyleft, aimed to ensure that freely available source code could only be used in programs that also offered the same freedom to use, modify, and redistribute the source code. As they explain it in the preamble to the GPL:
To copyleft a program, we first state that it is copyrighted; then we add distribution terms, which are a legal instrument that gives everyone the rights to use, modify, and redistribute the program's code or any program derived from it but only if the distribution terms are unchanged. Thus, the code and the freedoms become legally inseparable.
This is usually expressed within the community in the phrase, "Free as in freedom, not beer", referring to the difference between free and gratis. Free beer is great, but it's a different kind of free to free as in freedom. It is perfectly legal to sell software covered under the GPL. In fact, GPL software now powers many small appliances, ranging from wireless access points, to phones, to specialized industrial computers. Sometimes, vendors take GPL code, use it, and refuse to give the source code to someone asking for it. Several court cases have now upheld the license conditions of the GPL, and most infringing vendors quickly settle out of court because they know they would lose. Vendors that have produced source code in response to lawsuits on GPL violations include Cisco/Linksys, TomTom, Fujitsu-Siemens, Asus, Sitecom, Edimax, and Belkin. Another huge court case, between the SCO group and IBM, is ongoing, with SCO claiming that IBM stole code, which IBM then released under the GPL. To date, all of SCO's claims have been disproved by both the free software community at large, and more importantly, the court. However, the case is still underway and SCO has yet to come up with verifiable proof. The outcome of this court case is expected to firmly confirm the legal standing of the GPL in court.
Especially for cryptography, it is essential that the code is free. One can never trust a cryptographic machine whose internal workings are unknown. Because it is impossible to detect whether such a black box is doing something subtly bad, such as leaking key information, or using a set of bad or predefined random numbers, either of which would fundamentally undermine the security of the encryption in a completely undetectable way.
Note
One should never, under any circumstances, trust cryptographic software without having the source code of the software to verify the absence of insecure or malicious code.
Even now, many governments do not even have the source code of their own digital tapping rooms, and they are at the mercy of certain vendors and the governments of those vendors.
The term open source software is often used when talking about free software. It was coined by Eric Raymond to make free software more appealing to corporations. It was believed that the term free was misinterpreted by commercial companies to mean gratis, which was believed to be a reason why many companies shied away from such free software. It was also thought to have an image of being free and unsupported. A myriad of free and open source licenses have now appeared, as each vendor's lawyers want its license to be phrased slightly differently for a certain legal reason.
While the IETF was still busy designing the IPsec protocols, entrepreneur John Gilmore founded the FreeS/WAN Project. S/WAN stands for Secure Wide Area Network. The ultimate goal of the project was to make IPsec the default mode of operation for the entire Internet. Version 1.0 was released for Linux in April of 1999 under the GPL license and worked on the Linux 2.0.36 kernel.
In effect, the Presidential decrees on crypto export meant that should an American touch the Free/SWAN code, the US government could legally restrict its use to whomever they wanted. For this reason, Gilmore barred any American from ever coding for the project, running it entirely outside of the US from Canada and Europe. No patches from Americans were ever accepted.
This became a major problem when end users really wanted the kernel code of FreeS/WAN (KLIPS) to be merged into the mainstream Linux kernel. First of all, Linus Torvalds, the original programmer and current maintainer of the Linux kernel as a whole, has a policy of keeping politics from entering into the kernel, so code with such restrictions would never be permitted. On top of this problem, the maintainer of the network subsystem of the Linux kernel, Dave Miller, was an American. Thus, KLIPS never made it into the mainstream kernel, and FreeS/WAN never got included in the popular Red Hat Linux distributions. This situation lasted for a few years during which users had to patch their kernel manually to add IPsec support, and compile their own FreeS/WAN software. Later on the project shipped binary packages for Red Hat (RPMs) to make IPsec deployment relatively easy.
Meanwhile, although Gilmore's project was widely used as a VPN solution, the intention to encrypt the entire Internet was failing. It seemed that the project was not succeeding in its political goal, even though FreeS/WAN was widely deployed to increase the privacy and security of military organizations and Fortune500 companies.
To encrypt the entire Internet using IPsec, through a method dubbed Opportunistic Encryption (OE), it was necessary that a certain DNS record be added for FreeS/WAN support. Purists at the IETF did not want applications to use DNS, and worse, DNS itself was long overdue for an overhaul to add cryptographic security to it, but the process of drawing up this new DNSSEC protocol has been one of the slowest projects coming out of the IETF and was only released as RFC 4034 and RFC 4035 in March 2005. On top of these DNS issues, OE faced more and more problems due to the wide deployment of NAT, a method for connecting multiple computers using 'internal-only' IP addresses behind a single computer with a single real Internet-connected IP address. IPsec however, was more and more necessary after wireless networking took off, and the WiFi encryption standards were broken one after the other.
The rigorous views of the FreeS/WAN project were extremely problematic. Its political leanings drew it away from the real-world demands for certain VPN features and IETF standards implementation. Most notably, the refusal for inclusion of the X.509 patch, written by Andreas Steffen, a computer science research professor at the University of Applied Sciences Rapperswil in Switzerland, and the NAT-Traversal patch written by the French security company Arkoon, made a "stock FreeS/WAN" release next to useless for most real-world VPN usage, something the FreeS/WAN Project was not too concerned about since X.509 was deemed inferior compared its own DNS-based OE. This was because it was only really offering privacy to businesses rather than everyone on the Internet.
The non-DNS-based authentication method in IPsec using X.509 Certificates was becoming further entrenched because of Windows support. If someone wanted IPsec to support their Windows users, they would now need to download FreeS/WAN, download a few patches, patch the FreeS/WAN code, patch the kernel, compile the kernel IPsec module, and then compile the rest of the non-IPsec kernel modules and install all of the compiled components. And since there was no coordination between the patch maintainers and the FreeS/WAN maintainers, the patches were breaking continuously when new versions of FreeS/WAN or the Linux kernel were released. It was a very difficult process for someone not familiar with FreeS/WAN. This resulted in the creation of Super FreeS/WAN by one of the authors of this book (Ken Bantoft) to provide an easy‑to-use patched version of FreeS/WAN that had all of the features people needed for VPNs and interoperability. However, maintaining Super FreeS/WAN was becoming harder and harder.
The lack of out-of-the-box IPsec code for the Linux kernel was becoming a big problem for users setting up VPNs, and there were members of the FreeS/WAN project who wanted to work on a solution. In the summer of 2003, European volunteers and some members of the FreeS/WAN project—led by Paul Wouters, one of the authors of this book—met and talked to Gilmore at the Chaos Computer Club summer camp near Berlin. The foundation of the fork was laid, and in November of that year, Openswan was released by Xelerance, a newly founded company for the continued development of a free IPsec implementation for Linux.
Openswan's main mission was to cater more to the commercial world, while still keeping the FreeS/WAN ideals alive. This new code-fork also released the FreeS/WAN Project to stick even more strongly to its philosophies, and the next FreeS/WAN version removed support for AH and Transport Mode, two hardly used modes of IPsec, even though that completely broke interoperability with Microsoft Windows 2000 and XP. In April 2003, the end of the FreeS/WAN Project was announced and the last version of FreeS/WAN, with KLIPS support for the Linux 2.6 kernel, was released. In the next year, Openswan expanded and became the de facto IPsec implementation for Linux in practically all Linux distributions.
While this was happening, the lack of native IPsec support in Red Hat was a big problem for Linux distributions aimed at the enterprise market. They decided to code their way out of this problem by porting the IPsec code from another free operating system, FreeBSD. At this point, many kernel hackers also worked for Red Hat, so inclusion in the kernel would come naturally. Their adaptation of the KAME IPsec code from the BSD resulted in the Linux kernel NETKEY code.
Red Hat initially used the somewhat limited Racoon userland IPsec software in combination with the NETKEY code, but Openswan was added in version 3 of the Fedora Core distribution when Red Hat realized the political constraints of the FreeS/WAN Project did not apply to Openswan.
This book is not about politics. Software should not be about politics. If you are interested in these historical and political matters, we can recommend some excellent books that deal with these subjects.
Firstly, the following table lists some very useful non-fiction guides:
|
Crypto: how the Code Rebels Beat the Government—Saving Privacy in the Digital Age Steven Levy, Diane Pub Co, ISBN 0-7567-5774-6. |
This book gives an excellent overview of the history and politics surrounding modern cryptography and software. (Another book by Levy, 'Hackers', gives a similar overview for computer technology in general.) |
|
Secrets and Lies: Digital Security in a Networked World Bruce Schneier, Hungry Minds Inc, ISBN 0-471-45380-3. |
This book talks about the true and false claims and thoughts behind using cryptography. |
|
Database Nation : The Death of Privacy in the 21st Century Simpson Garfinkel, O'Reilly, ISBN 0-596-00105-3. |
This book shows the danger of the information age and the massive collecting of the digital bits of our lives and the mistakes made with this data. |
|
Cracking DES: Secrets of Encryption Research, Wiretap Politics and Chip Design Electronic Frontier Foundation, O'Reilly, ISBN 1-56592-520-3. |
The story behind the building of the DES Cracker machine. |
And if you want some engaging bedtime reading, try the books on the following list:
|
1984 George Orwell, Penguin Books Ltd, ISBN 0-14-012671-6. |
A classic you should have read by now. |
|
True Names Vernor Vinge, Tor Books, ISBN 0-312-86207-5. |
A story about anonymity written before the Internet was invented. |
|
Fahrenheit 451 Ray Bradbury, Voyager, ISBN 0-00-718170-1. |
The classic about information restriction. |
|
Cryptonomicon Neal Stephenson, Arrow, ISBN 0-09-941067-2. |
A story about information 'havens' and the use of crypto. (Another recommended book by Stephenson is The Diamond Age.) |
If reading about the politics and license issues has made you nervous about the legality of your use of Openswan, do not worry. The following section will explain the legalities of Openswan, though you should not read this section as a replacement for the advice of a skilled lawyer. Treat it more as the basic information you would supply to your lawyer to determine your specific case.
If you are in doubt whether or not it is legal for you to use Openswan, consult a lawyer!
Openswan is based in large part on FreeS/WAN. The copyright of that code lies with the respective developers, who all released their code under the GNU Public License. All the patches to FreeS/WAN are copyright of the respective authors and released under the GPL. New Openswan code written by Xelerance is copyright of Xelerance, and is also released under the GPL.
The GPL does not discriminate against use. Anyone is encouraged to use this software as they see fit, whether for a homebrew VPN or a nuclear power plant. As programmers, we, the authors of this book, believe that we do not have the skills, nor should we have the authority, to distinguish rebels from freedom fighters or insurgents from dissidents. We provide the tools; it is society's responsibility to provide the ethical framework. Should we limit our own freedom to grow out of fear that someone might use our software for something bad? Should we never have picked up those stones to make tools because some of us would use them as weapons? Should the toolmaker dictate what goals are righteous? If we limit the use of our cryptography to certain people, how much different would that be from the movie studios telling us in which country, using what vendors and software we can play our purchased movie? Should your car agree with your destination? Precisely some of these concerns about individual freedoms were originally behind the project to bring IPsec to the Linux kernel.
Since Openswan is released under the GPL, any modifications or additions to the code that are distributed will have to be released under the same license, the GPL. Though you could also release modifications under a BSD license, as soon as the code is incorporated into Openswan, it is (as the BSD license allows) re-released under the GPL. Failure to comply to the GPL will mean that you no longer have the legal right to use or distribute Openswan at all.
Though at first this might seem simple and straightforward, but there can be some additional hassle. What if you just received a patch to Openswan from a vendor under a Non Disclosure Agreement (NDA)? Are you allowed to publish this patch? Probably not, as you would be violating the NDA with the vendor and be in violation of your contract, a civil offense. Of course, in this (unfortunately not so hypothetical) case, the vendor is actually violating the GPL and could be sued by any of the copyright holders of Openswan even if they have no business relationship with the vendor. The vendor has also committed a civil offense. The third party clause in the GPL guarantees that copyright holders can sue whoever is responsible for violations without having been a victim of that violation personally. If a copyright holder who has signed an NDA finds that the copyright has been violated, the copyright holder—whether it is a company or an individual—could probably sue since a contract can never be used as a protection scheme against a civil offense.
It is therefore important to realize that if you distribute GPL code in binary-only form, and you cannot release the source code—for instance, because you yourself bought the code as binary‑only—you are still violating the GPL, and you can be sued and restrained from using Openswan in your products by a court. So those who are thinking of implementing certain hardware IPsec accelerators for Openswan, of which they cannot redistribute the patches, should definitely have a long talk with their lawyers.
If you release a new product based on Openswan (or any other GPL software for that matter), you are quite free to ship Openswan on the CD of your new product—as long as you meet the GPL license requirements such as supplying the Openswan source code to any interested party.
However, there might be other laws that apply to you. Different countries have varying legal requirements, since many countries consider cryptography as munitions, as a weapon. So even though the copyright holders of Openswan say you can use it, your government, or a completely other government or international body, might deem that you may not use it. So the first thing to do is to check whether your own government allows you to use cryptography.
A survey in 1999 by the Electronic Privacy Information Center (EPIC) found the following countries limit the use of cryptography by their own citizens: Belarus, China, Israel, Kazakhstan, Pakistan, Russia, Saudi Arabia, Singapore, Tunisia, Vietnam, and Venezuela. France and Belgium were on this list for a long time, and the US allow their citizens to use cryptography, but if it is used to commit an offense, the use of cryptography itself is an offense on its own. Countries on this list probably also restrict or ban the import of cryptographic software.
You should also be aware that some Western governments are considering a ban on crypto as part of anti-terrorist measures, so be sure to get up-to-date information from your government.
Apart from national law, whether or not you may use or export cryptography also depends on international treaties that countries adhere to. International treaties that may apply to your country are the 1886 Bern Convention on copyrights (though it was last amended in 1979), the 1995 Wassenaar Arrangement on the export restrictions of munitions to 'Evil Regimes', amended in 1998 to get an additional section on cryptography guidelines, and the European Union Dual-Use Export laws. Then there are also recommendations and guidelines from the Organization for Economic Cooperation and Development (OECD), the European Union, the G-7/G-8, the Council of Europe, the Organization for Security and Co-operation in Europe (OSCE but also sometimes called OVSE) and perhaps the UN Security Council has issued a specific resolution boycotting your country from receiving munitions, which would include cryptographic software.
Probably the most relevant international agreement is the Wassenaar Arrangement, which has a special exemption in the General Software Notes, entry 2, for software which is in 'the public domain'. The use of public domain should probably be interpreted as "readily available at no cost". This would seem to include Openswan.
The list of restricted countries varies between the various international agreements, partially as a result of the Wassenaar Arrangement that dictated the individual countries are responsible for implementing the Arrangement in local law. Sometimes, a country is not completely banned, but a separate export license is required before you can export cryptography to those restricted countries. The list of restricted countries at this point probably includes Cuba, Iran, Iraq, Libya, North Korea, Sudan, Syria and strangely enough international organizations such as the United Nations. But again, the implementation of the Wassenaar Arrangement varies from country to country, so check the export laws of your own country.
For example, the following countries have listed extra restrictions on top of the Wassenaar Arrangement: Australia, France, New Zealand, Russia, and the US.
The Wassenaar Arrangement website has a convenient list of countries and contact information for their respective government departments that deal with export.
So far, we have only covered the receiver of the cryptographic software. But there is also law that applies to the export of cryptographic software in the country of the sending party.
Xelerance is a company incorporated under Canadian law. Distribution of the code happens from servers located in the Netherlands, therefore Dutch export law applies. Xelerance still needs to adhere to export restrictions on crypto code. It is legal to export cryptographic code from Canada to The Netherlands.
Xelerance does not own the copyright on all the code in Openswan. We can only speak for the parts that are copyrighted by Xelerance. But as far as we know, no separately copyrighted code by US individuals or companies is included. And even if some lines were written by US citizens, Canadian law seems to dictate that software is Canadian if more than 50% of the code has been written by Canadians, a requirement that Openswan easily satisfies.
Xelerance, however, cannot be held responsible for where the code is exported to, since the code is free software. The Netherlands and Canada signed the Wassenaar Agreement, which exempts 'public domain' software. The Netherlands also complies with the European Union Dual-Use Export laws. As far as we know, we are not violating any export laws, meaning that whoever downloads Openswan cannot be accused of assisting in an export violation.
Certain countries claim jurisdiction even outside their national borders. Most notably, France claims the right to regulate information on foreign servers, Italy assumes jurisdiction over sites directed to an Italian audience, and the US reserves the right to prosecute offenses against American interests according to US law irrespective of where they take place.
You may want to consider the possibility that you can be sued or prosecuted in another country. Additionally, if you are physically in a country other than the Netherlands when you download our software, you are probably subject to that country's jurisdiction anyway.
On 1 June 2001, WIPO members adopted the Patent Law Treaty. However, software patents are not universally recognized. Specifically, software patents are not recognized in The Netherlands or Canada. However, US patents may in some circumstances be enforced in Canada. Since US patents cover things such as prime numbers, Openswan would likely be considered in violation of a few software patents in the US. There are at least two known US software patents covering concepts used in Openswan.
The first patent relates to NAT-Traversal, and has been patented by SSH Communications. However, they have given the IETF the following statement:
SSH Communications Security Corp hereby makes it known that it will not assert any claims in any patents issued in any country based on
—the Finnish patent application FI974665 or any patent application listing the same as a priority application; or
—the US patent application 09/333,829 or any patent application listing the same as a priority application,
—against any party that makes, uses, sells, imports, or offers for sale a conforming implementation of an IETF standards-track specification of an IPSec NAT traversal module.
This statement is limited in that SSH Communications Security Corp does not give any rights to incorporate NAT traversal technology covered by patents of SSH Communications Security Corp in implementations for any other protocols other than the IETF standards-track IPSec protocols.
Interestingly, this might actually be a benefit for the community. Microsoft cannot play 'embrace and extend' techniques unless it buys out SSH. And technically, Apple has no license to use the NAT-Traversal patent since it incorrectly implements the IETF NAT-traversal specification.
A second patent involves the DH groups and their numbers, which seem to have been patented. Information about this is unclear, and it is unlikely to be ever enforced.
A number of patents related to Elliptic Curve Cryptography are still valid (in the US only).
In 1997 the Diffie-Hellman key exchange patent and the Knapsack (and probably all public key cryptography methods) patent expired. The RSA patent expired on September 20, 2000. In 2001 a patent on Exponentiation Cryptographic Apparatus and Method expired.
There are also a lot of blatantly bogus patents that could theoretically be used against Openswan users. In 2002 for example, five years after the start of the FreeS/WAN Project, Safenet was awarded a patent that covers 'Extending cryptographic services to the kernel space of a computer operating system'. Patents like these only prove the absurdity of software patents.
http://www.freeswan.org/freeswan_trees/freeswan-1.5/doc/exportlaws.html
The above site provides a good overview of cryptography export laws.
Information on the Wassenaar Arrangement, covering national export controls.
http://www.gnu.org/philosophy/wassenaar.html
Further notes on the Wassenaar Arrangement.
http://www.wipo.int/treaties/en/ip/berne/
The Berne Convention on copyright.
http://www.efc.ca/pages/doc/crypto-export.html
This document provides a summary of Canada's export controls on cryptographic software. This is relevant to all Openswan users, as Openswan is developed in Canada.
http://rechten.uvt.nl/koops/cryptolaw/index.htm
A survey of existing and proposed laws and regulations on cryptography in Europe. This is relevant even if you are outside of the EU, as Openswan is hosted on a Dutch server.
http://trade-info.cec.eu.int/doclib/html/118992.htm
EC Regulation 1504/2004 for the control of exports of dual-use items and technology.
http://europa.eu.int/comm/trade/issues/sectoral/industry/dualuse/index_en.htm
This page provides a detailed description of dual-use goods and EU legislation on them.
http://europa.eu.int/comm/trade/issues/sectoral/industry/dualuse/faqs.htm
Frequently asked questions and background on the EC Regulation on export control of dual-use goods.
http://trade-info.cec.eu.int/doclib/html/118993.htm
Report to the EU Parliament and Council on the implementation of EU Regulation 1334/2000 on dual-use items and technology.
A list of US patents relating to cryptographic software.
http://www.nosoftwarepatents.org/
The home-page of a campaign against the further legalization of software patents.
It might not come as a surprise that people involved with cryptography often also have strong political views on freedom, privacy, and civil rights. It is easy, even tempting, to wander from the realm of technology into the realm of politics. These issues are the cause for the formation of groups such as The Electronic Frontier Foundation (EFF), European Digital Rights (EDRI), the Foundation for Information Policy Research (FIPR), and IPJustice, as well as more informal groups such as the free software and open source movements, the Cypherpunks, Groklaw, Politech, 2600 Magazine, the CCC, Hacktic/HfH, and many more.
All these groups have reached the same conclusion. Cryptography is a strong tool that can be used and abused by governments, criminals, businesses, and individuals. Cryptography has become an essential part of daily life, and should not be limited to the military. It is essential to freedom, something the FreeS/WAN Project believed strongly in. They have created the foundation for widespread use of IPsec to ensure privacy for many, ranging from NATO to Greenpeace. Openswan continues to provide those means for everyone. And the remainder of this book will help you accomplish the same.
Esther Dyson, member of the President's Export Council Subcommittee on Encryption and board member of the EFF, formulated these believes in a powerful concise matter:
Encryption...is a powerful defensive weapon for free people. It offers a technical guarantee of privacy, regardless of who is running the government...It's hard to think of a more powerful, less dangerous tool for liberty.