Darknets are not the only way to preserve privacy for online activities. Anonymizer proxy services, both free and commercial, are possibly the best known vehicles to achieve online privacy up to a certain degree. However, they all suffer from a key weakness of this model: the entity controlling the proxy has access, either transient or permanent, to activity records for all the users of that particular service. This poses an interesting question: is your privacy better preserved when your information is only known to a few, potentially interested, parties? The obvious response from privacy purists is that this is not the case.

Darknets, by nature, tend to be decentralized, leading themselves to a paradigm where no single party can control or eavesdrop the information moving across the network. Most of them go to great extents to encrypt data and network identifiers so that they can not be accessed by the transporting parties. Some of them even provide for distributed data storage, allowing for fragments or whole data elements to reside encrypted in permanent storage contributed by participants.

Based on how open or closed a Darknet is, there are essentially three models; all these models can physically and logically coexist within the same Darknet:

1. Closed or pure Darknets, also known as F2F (for friend-to-friend), characterized by the fact that connections are only established between nodes based on extrinsic arrangement or prior knowledge. These are the ones that clearly provide the highest confidentiality; in many cases these Darknets can operate undetected by extended periods of time. However, accessibility is limited to those who know one or more participants before they can connect to the network. Requestor and resource are both contained within the Darknet itself, and no traffic abandons the Darknet, ever.

2. Open Darknets, where new nodes more or less randomly establish connections with existing nodes. This model provides for easy access for new participants to join, but also offers more possibilities for third parties intending to snoop in or subvert the network. Similar to the previous case, both, requestors and resources are internal to the Darknet.

3. Darknets with gateways or “exit nodes”, which allow access to external services not contained in the Darknet itself. As soon as traffic abandons the Darknet, it becomes vulnerable to information leakage, either to attacks by third parties in the way of the traffic (man in the middle) or to compromise by the final recipients. SSL or any other encryption protocol can provide a veil of confidentiality to the data contained in the transmission, but it cannot prevent a third-party from discovering that the transmission itself happened. The third-party may not know who the original sender for the request was (if the Darknet operates as expected and masks the original source network identifier replacing it with the gateway network identifier), but will undoubtedly realize that there was a transmission between the gateway and the destination at a particular time and using specific network protocols and ports.

We’ll go over three of the most popular Darknets including their fundamentals, applicability and limitations.

Tor

Concentric layers of encryption in Tor

The most popular forms of Darknets are usually those that allow for some type of anonymous access to external resources. Since the Internet offers a significantly larger pool of resources than any Darknet in existence, most people just look for ways to conceal their online identities while accessing these resources in the open Internet. Tor, based on a model known as “onion routing”, which provides for multiple concentric layers of encryption for every transmission, is possibly the most prevalent form of Darknet. Nodes relaying data for other nodes within the Darknet are oblivious to the content of the transmissions and the identity of the original sources of the requests, thanks to these multiple encryption layers. Although Tor offers internal resources too (in the “onionland” or .onion URL domain), accessing these resources is conditioned to the existence of prior knowledge of their URI’s, and the fact that there is no central directory of resources doesn’t make finding any given resource a simple task (try to imagine an Internet with no search engines and incomplete indices to sites and information). This limitation is also shared by other Darknets that provide in-network services. Using Tor is extremely simple, and self-contained installation packages are available for the most common operating systems. Tor is not exempt of challenges as two potential problems have been identified in the past:

1. DNS resolution can, if not properly routed through Tor, expose the identities of requestor and resource (not a weakness in Tor itself and it has been addressed and corrected by a relatively recent update);

2. If you could identify the requester beforehand by exploiting a vulnerability on the user’s system or otherwise, you could trace the path within the Tor network for any future request from that user. While the former is not a weakness in Tor itself, the latter is a limitation in the way Tor works. This is known as “the bad apple attack”.

I2P

I2P routing and encryption

The Invisible Internet Project is, in some sense, similar to Tor as it uses multiple encryption layers to encapsulate the requests and that it also replaces the sender information as the message is relayed through the network. However, there are differences between the two, particularly regarding the following two aspects:

1. I2P also replaces the destination information to conceal the identity of the receiver;

2. I2P is based on the so called “garlic routing” which aggregates multiple messages together in an attempt to prevent attacks that could use traffic information to identify sender and receiver of a particular transmission.

I2P also allows for in-the-network anonymous website publishing. These sites are called “eepsites” and use a .i2p domain (similar to the .onion domain for Tor). Since I2P hasn’t been adequately peer reviewed and it has a relatively small group of participants, anonymity can not be guaranteed.

Freenet

Freenet logo

Originally developed by Ian Clarke in the late 90’s, Freenet advocates a different model. The paradigm behind it is based on ensuring a censor resistant anonymous information store. In order to achieve this goal, a combination of a hashed distributed information store and strong cryptography are utilized. Each participant voluntarily contributes permanent storage space which is used to host encrypted data blocks. These blocks are referenced by identifiers based on their hashes, which serve the dual purpose of validating that the data hasn’t been tampered with, and indexing the specific block for later retrieval. Any new data injected into the network is decomposed into blocks and these blocks are migrated to nodes that tend to concentrate that particular portion of the hashing space. The more these blocks are accessed, the more copies of them in existence and the higher the availability for the particular data element. This distributed storage behaves as an LRU (least recently used) cache, so data blocks that have not been recently accessed can be overwritten to make room for new data, effectively expiring uninteresting data in lieu of content in higher demand. One interesting aspect of this approach is the fact that the publisher can disappear almost immediately after the data has been injected into Freenet without affecting the availability of the data itself. In addition to data store, Freenet also provides for peer to peer communication, although latencies vary depending on the actual topology. There is also the inconvenience that there is no delivery assurance (although there is a high probability that if peers are close enough, they will be able to communicate). Moreover, Freenet is based on the “small-world” network theory which sustains that the topology of the network is such that any node can be reached in a small number of hops, with only knowledge of immediately adjacent participants.

As of its latest version (0.7), Freenet can be configured in either one of two modes: F2F or pure Darknet mode, and open Darknet. The former provides for the highest degree of anonymity, while the latter allows for easier joining if there is no prior knowledge of nodes in the network

Ethical considerations and conclusion

The right to privacy and the right to freedom are fundamental rights, and part of many countries’ privacy laws and, in some cases, Constitutions. However, by their own nature, Darknets also provide for a fertile ground for cyber crime, as they hamper the investigators’ ability to perform forensic analysis. In any case, Darknets can be a powerful tool against totalitarian and oppressive regimes.

At the end, Darknets are just a tool: what you do with them is what counts.

Linksys E3000 dual-band wireless router

Perhaps you have decided that you need a feature that your old wireless router doesn’t support: How about the ability to provide a VPN service to access your home network securely from remote? Or maybe a guest network for those relatives coming over for Memorial day weekend? Wouldn’t IPv6 support come handy for this upcoming World IPv6 day event?. Or maybe you want to upgrade your home network to make your media server stutter free (300-450 Mbps would be cool, wouldn’t it?). In any case, running an alternative third-party firmware can provide you with a plethora of additional options at no cost (well, if you feel generous enough you could donate some money to one of these projects, but philanthropy is not cost, isn’t it?) and infuse new life into your older wireless router. In many cases, a third-party firmware is also more reliable, less buggy and runs smoother than the original vendor firmware included with the device.

OpenWRT Backfire release

There are several projects focused on building quality third-party software for wireless routers; some of the most well known and active projects are DD-WRT, OpenWRT, Tomato and Sveasoft. While the last two projects only support older wireless routers (WRT54G and family), DD-WRT and OpenWRT are constantly adding new routers to their lines and have a very active community. One caveat, Sveasoft uses a business model that requires a current subscription before you can try their latest firmware versions (and the older/stable versions tend to be quite limited), so I advice you to look to the other three projects first and resort to Sveasoft if none of them work for you.

DD-WRT web interface

Although these projects are all based on GNU/Linux, there are differences that go beyond the surface of the graphical user interface (GUI). The DD-WRT software tends to have a more thorough and consistent web based user interface, which minimizes the need for configuration through the command line interface (CLI). Support is usually very good through the DD-WRT forums, either from the active community or the developers themselves; documentation is also very high quality and gets regularly updated. DD-WRT also offers a good set of newbie friendly additional packages (Optware) to introduce additional features in a way that is mostly plug and play.

OpenWRT console

OpenWRT is more oriented towards the power user. Although the web interface (LuCI) is quite complete, advanced functionality can only be achieved using the command line interface; the filesystem layout is more in line with the standard Linux Filesystem Hierarchy so Linux folks should feel at home. OpenWRT has a large library of additional packages which can be installed directly from the central repository, either by using the opkg command line utility or through the LuCI web interface. Documentation is also good, with a substantial list of recipes and howtos guiding the users through basic and advanced topics, with an emphasis on command line configuration. On the downside, questions in the OpenWRT project forums are sometimes left unanswered, especially if they are not good questions, and there is typically less tolerance for newbies (see this document before asking for support) than in the DD-WRT project. However, if IPv6 support is a must and you don’t want the hassle of compiling your own ip6tables kernel modules, OpenWRT is your best option as these kernel modules are included in the standard backfire release; compiling any kernel module for a 2.6 DD-WRT kernel can be tricky if the version of the svn source code that your are using to build the kernel modules doesn’t match the exact svn version that you are running in your router (hint: 2.6 kernels require exact module symbol version matching in order to load the module, and the busybox insmod command seems not to allow to force modules without module symbol versions, giving back an “invalid module format” message).

Netgear WNDR3700

If you haven’t purchased your router yet, you should stop now and head over to the supported hardware lists from DD-WRT and OpenWRT; and since making head or tails of such a long list can be difficult, I’ll give you a few tips. If you’re looking for the fastest supported router that can do simultaneous dual band and operate on a/b/g/n, then look no more: the Netgear WNDR3700 is probably the best option there (but make sure that the packaging of the unit you are buying indicates that it contains a wndr3700v2, as there have been reports of dead 2.4Ghz radios with some models of the first version running under DD-WRT). It is Atheros based, and with a very fast CPU, 8MB of flash and 64MB of RAM it is the clear performance king among supported routers. A close second choice would be the Linksys E3000 (with a slower Broadcom CPU, but otherwise similar features). Each one of these routers will set you back around $130-150 at current retail prices but considering that a wireless routers should last you for a good two to four years, you wouldn’t probably set for less. Do not select the Netgear WNDR4000 nor the Linksys E4200: these models are still not supported by either project, and although there may be ongoing efforts to support them, there is no guarantee that they will be supported at all.

Linksys wrt54gs

If you plan on reusing existing hardware instead, and you have an older Linksys WRT54g/gs or similar device, this is your lucky day: every version has excellent support from DD-WRT (except for version 7, which is not and will probably never be supported). Tomato, OpenWRT and Sveasoft have all also good support for these devices, particularly for versions 1 through 4.

In any case, the list of supported devices by OpenWRT and DD-WRT covers hundreds of models across dozens of vendors. Chances are that your existing wireless router is supported by one of these projects and, if not, you can probably pick up an older/used supported unit for just a few dollars.

Depending on the specific router, the steps to upload the third-party software can involve a combination of either the web interface and/or tftp from a command line prompt. In very rare cases you may need a JTAG cable either to install the new software or to de-brick a modified router. I recommend that you stay away from any routers that require creating and soldering a JTAG cable for a third party software to work.

Before you start the process of deploying a third party software to your wireless router, you should ensure that you have a good backup of the settings for your network, including your PPPoE passwords, IP addresses and static DHCP leases, port forwards (in case you need support for incoming calls on a SIP phone, etc.) and recursive DNS settings if these are not dynamically configured by the provider. Some routers also have specific flash partitions containing calibration data, required if you want to ensure that your radios come back alive after a catastrophic flash overwrite or wipe, so go ahead and backup your caldata too (this is especially true for the WNDR3700). Information on how to backup your caldata is available on the DD-WRT forums.

After you covered these initial steps, head over to the particular project for the specific documentation on how to install that third party software on your device. For the OpenWRT project, you can use the hardware support table to identify your device and access the documentation for it. For the DD-WRT project, there is a similar table but you’re probably better off by looking it up in the hardware database.

Once you have installed the new software, sit back, relax and make yourself familiar with the myriad of options and open possibilities. Now it’s time to configure your router, enable those functions that were unavailable with the stock firmware, test everything and possibly donate to the project of your choice to demonstrate your appreciation.

Above all, enjoy and happy hacking!

IPv4 address exhaustion from 1995 to 2011. Graph shows number of available "/8" blocks, each containing 16777216 addresses. From Wikipedia.

In case you haven’t heard about it yet, the Internet Society (ISOC) is planning an IPv6 “test flight” with some large organizations, on June 8th, 2011. The event will last for 24 hours and is intended to raise awareness about the impending migration to IPv6.

This is by no means the “launch of IPv6″ (IPv6 has been available for over a decade since the early days of the 6bone). Instead, this is the opportunity for some large-scale service and content providers to test their IPv6 readiness with a sizable audience over a 24 hours period. Although not the first of its kind, since this event is sponsored by the ISOC and supported by several core content and network providers (some of the participants are big names such as Google, Yahoo, Akamai and Facebook) it has a good chance of becoming the largest IPv6 awareness raising event in history. It is no coincidence that IANA has just allocated the last few available IPv4 blocks to the regional registries, marking the depletion of the IPv4 space (at least when it comes to global allocations, but regional allocation exhaustion will follow soon).

Decomposition of an IPv6 address into its binary form. From Wikipedia.

At this point, you may be wondering how to participate. It is quite simple: just ask your network provider to supply you with IPv6 and you should be all set. You wish it was so simple! Unfortunately the majority of the network providers around the world are still not ready to provide a so-called dual stack (IPv4/IPv6) connectivity to their consumers, so this approach is probably not viable for you (unless you’re part of the elite able to receive native IPv6 service as we speak). Instead, you would probably need to either ask your provider if they have an alternative service for IPv6 (6rd comes to mind) or just set up an IPv6 over IPv4 tunnel from one of the IPv6 tunnel brokers (there are many and they tend to be free, for now). Some of these providers offer 6to4 as the protocol to deliver these IPv6 packets up to your IPv4 destination. Teredo is another mechanism to provide IPv6 connectivity over IPv4 networks, but only provides access to a single endpoint (your windows workstation, for example) and not the entire network, as 6to4 can do with a /48 prefix, for example.

HE sample IPv6 certificate

There are several IPv6 tunnel brokers, but two of the best known are Hurricane Electric (HE) and SixXS which have been providing free IPv6 tunneling services for over a decade. In the case of Hurricane Electric, which is the one that I have the most experience with (used them back in the mid nineties when 6bone was the sandbox to play in), you need to go through a simple registration process at their tunnel broker portal; the whole tunnel creation process is self managed and can be completed in a matter of minutes (it will take more time to configure your endpoint than to configure theirs). What makes HE even more fun is that you can go through their free IPv6 certification to demonstrate your IPv6 knowledge and the IPv6 capabilities of a domain that you register for this certification process.

The next thing that you need to decide is where to terminate the tunnel on your side. Although you could terminate it directly on a host (Windows, Linux or BSD workstation, for example), it would probably be more useful to do so at your network external router (assuming that you have one). Remember that although your regular ISP may only assign you one IP address forcing you to play Network Address Translation (NAT) tricks to work around the fact that your other computers will only have private IP addresses (assigned according to RFC 1918), IPv6 has no such limitations (and in fact discourages any network address translation). Any tunnel broker will assign you a whole /64 segment (allowing for millions of hosts in a single network segment) and most (like HE, for example) will even assign /48 segments (allowing for 65536 networks with millions of hosts each).

Since there are many available resources when it comes to configuring IPv6 in your devices, and most (all) modern operating systems have the ability to use and route IPv6 addresses, it would be silly to describe each one in detail here too.

However, I maybe able to suggest things to make this undertaking more fruitful. If you want to truly learn IPv6 in this process, I recommend that you configure your home router as the endpoint for the tunnel, and that you set up a dual stack IPv4/IPv6 lan segment for all your machines to have access to IPv6 natively. It would also be useful to set up a couple of servers (HTTP and DNS, for example) in one of those machines to get used to some of the configuration differences between IPv4 and IPv6. To really go the extra mile, you could also try some multicast services (hint, there is no IGMP in IPv6, but ICMPv6 performs Multicast Listener Discovery quite well) and, why not, do some packet captures and understand how packet fragmentation works a bit different in IPv6.

What is important to remark, in any case, is that your run of the mill IPv4 firewall will not have you covered. You will need to explicitly configure IPv6 rules (ip6tables in Linux, for example) to block or allow specific IPv6 traffic. Moreover, the 6to4 tunnel itself (if you decide to go this route) uses IPv4 Protocol 41 to encapsulate the IPv6 packet into an IPv4 packet, so any firewall rules must be applied at the endpoint of the tunnel, after extracting the IPv6 packet from their encapsulation.

If your Internet router runs any flavor of Linux (OpenWRT, DD-WRT, etc.) and you are not intending to run any servers on your network, then you just may need a few rules to block any unsolicited communication from the outside over IPv6 (slightly modified from the OpenWRT documentation) while allowing your hosts full access to the Internet:

# start with a clean slate

ip6tables -F

# allow icmpv6

ip6tables -I INPUT -p ipv6-icmp -j ACCEPT

ip6tables -I OUTPUT -p ipv6-icmp -j ACCEPT

ip6tables -I FORWARD -p ipv6-icmp -j ACCEPT

# allow loopback

ip6tables -A INPUT -i lo -j ACCEPT

ip6tables -A OUTPUT -o lo -j ACCEPT

# allow anything out to the tunnel

ip6tables -A OUTPUT -o 6in4-henet -j ACCEPT

# allow LAN

ip6tables -A INPUT -i br-lan -j ACCEPT

ip6tables -A OUTPUT -o br-lan -j ACCEPT

# drop packets with a type 0 routing header

ip6tables -A INPUT -m rt –rt-type 0 -j DROP

ip6tables -A OUTPUT -m rt –rt-type 0 -j DROP

ip6tables -A FORWARD -m rt –rt-type 0 -j DROP

# allow link-local

ip6tables -A INPUT -i br-lan -s fe80::/10 -j ACCEPT

# allow multicast

ip6tables -A INPUT -s ff00::/8 -j ACCEPT

ip6tables -A OUTPUT -s ff00::/8 -j ACCEPT

# allow forwarding

ip6tables -A FORWARD -i br-lan -j ACCEPT

ip6tables -A FORWARD -m state –state ESTABLISHED,RELATED -j ACCEPT

# forward ident requests

ip6tables -A FORWARD -p tcp –dport 113 -j ACCEPT

# default policy…

ip6tables -P INPUT DROP

ip6tables -P FORWARD DROP

ip6tables -P OUTPUT DROP

If you instead plan on running a web server or a DNS server, you’ll need to add the proper ALLOW rules in the FORWARD chain (which should be easy to do based on the example above).

So what is next after you have configured your home network to route IPv6, and that you officially declare yourself ready for World IPv6 day (don’t forget stocking some beer and snacks for the celebration, of course)? Well, you can go ahead and follow the HE certification link for your bragging rights and above all, enjoy your World IPv6 day @ home!

GNU Hurd logo

Roughly 20 years ago, around the time the first versions of Linux started seeing the light, a couple other efforts in the Opensource Operating System arena were underway. On one side, the mythical GNU own kernel (HURD) was discussed about (two decades later, we have just started to see one or two viable distributions based on the HURD kernel); on the other hand, the first versions of the Opensource derivatives from 386BSD (NetBSD, FreeBSD and OpenBSD)  were released.

Puffer fish, OpenBSD project mascot

OpenBSD, the “youngest” member of the BSD family has just released its latest version. The OpenBSD project, led by Theo De Raadt, one of the co-founders of the NetBSD project, focuses on proactive security, code correctness and portability. Some of the software components created by the OpenBSD team, such as OpenSSH, have transcended beyond OpenBSD and have been adopted at large by other Operating Systems.

Despite having a relatively modest team of developers, the OpenBSD project has managed to release a minor version exactly every 6 months for many years. Many of these minor releases only differentiate from the previous release by a few new features and/or drivers and a slew of bugfixes (for example, some of the main new features of 4.9 are read only access to NTFS filesystems in the default kernels, SMP kernels can now boot on machines with up to 64 cores, there can be more than 4000 processes in x86 architectures and OpenSSH 5.8 has been included).

OpenBSD development/testing lab at Theo's basement

What are the key features of OpenBSD? Above all, it’s simple in the most purist BSD/Unix style and makes all its source code freely available (it is Opensource after all, what would you expect?). Special care is put on code correctness and security, including bug fixes and even specific functions (strlcat and strlcopy are good examples in the string manipulation arena) to prevent common coding mistakes. It has a good set of network tools (including dynamic routing protocols support through openbgpd and openospfd), a solid packet filtering implementation through pf and a reliable redundancy protocol (CARP). I also offers a sizable library of binary packages and a larger set of available applications in source code form through their ports repository.

Although OpenBSD and Linux are both Opensource, there are substantial differences in the way they are licensed. The BSD license (under which OpenBSD is distributed) makes source code available to anyone willing to use it, sell it or create derivatives, either for commercial or non-commercial use. There is no obligation to redistribute the source code for any modification, and the only condition is for the original copyright notice to be included with the binary code (the distributor is not bound by any specific license). The GPL license (under which Linux is distributed) makes source code available to anyone willing to use it, sell it or create derivatives, either for commercial or non-commercial use, with the obligation to also re-distribute the source code for the derivatives and to provide them under the same license.

Richard Stallman, head of the Free Software Foundation, house of the GNU project

While the general consensus is that BSD licenses are “less restrictive” (they don’t impose a particular license to the entity distributing derivatives), it all depends on whose rights are being considered: as a company deriving a commercial and closed source product from a BSD licensed code base, the BSD license is certainly less restrictive. But as the consumer who is acquiring and using that product without the rights to access the source code for the modifications performed by that company, the consequences of the BSD license in the first place are an effective further restriction of the consumer rights, because derivatives can be distributed under any license including proprietary closed source models. In the spirit of full disclosure, as a consumer I always prefer Opensource, and a GPL license always guarantees that. BSD licensing supporters (and GPL detractors) argue that GPL impairs the ability for businesses to make money off their software (as they need to release the source code for the modifications and can not impose a license more restrictive than the GPL license that they received).

Which license is better? I guess it all depends: if you are developer expecting to get funding (mostly through donations) from your direct users -especially corporate ones-, and you don’t care about the end user access to the source code for the products that they use, then a BSD License may be a good choice.  If, on the other hand, you sit on the idealist side and want to ensure that nobody can restrict the rights of the end users, GPL is the clear winner.

When comparing the evolution in market share of Linux and OpenBSD, two Operating systems that were born around the same time, a question comes to mind: why is there such a difference in market penetration? Linux, on one side of the spectrum, with a License that apparently impairs commercial venues, has enticed companies and organizations to adopt and support it under varying commercial models, while the BSD derivatives (FreeBSD, OpenBSD and NetBSD), with a larger history and an allegedly more commercial friendly license haven’t been as successful to gather a large installed base and widespread adoption.

Tux, the Linux mascot

This difference probably obeys to several reasons. One of the possibly most clearly defined is the eclectic leadership style of Linus Torvalds who tends to choose practical over doctrine (in the BSD world in general there is normally a higher adherence to rules on how things should be, based on the “BSD tradition”).

The GPL itself seems to be (despite the opinions of some of its detractors) another important reason: if consumers seem to prefer GPL (and consumers are not only you and me, but also large companies and organizations) because they have access to the source code, why wouldn’t companies (developers, integrators, resellers, etc.) make a business out of it? In addition to this, any company releasing an Opensource product wants to reasonably ensure that they will have access to the source code of any potential competitive product derived from their code base. In this sense, GPL levels the field by giving everyone access to everyone else’s source code.

A third important reason goes along the “self-fulfilling prophecy”: as soon as the development community grows enough to reach and exceed the critical mass, the accelerated development pace allows for a continuous and significant amount of contributions in every imaginable direction; the widespread adoption also guarantees innumerable use cases and thorough testing across diverse hardware; the commercial focus provides for code auditing and general security improvements, and the use by Colleges and Government Agencies supplies interesting domain specific features (take SELinux, for example).

So, now that OpenBSD 4.9 is out, should you consider migrating to it? Well, that depends. If you are already a user of OpenBSD and are still on an older version, I would say: why not? You get a few new features, some additional drivers and a ton of bug fixes. If you have been looking into OpenBSD before and you decided that it wasn’t for you, unless your only reason was the inability to access an NTFS partition (you can’t be serious!) or running more than 4000 processes on an x86 server, then you should still be looking somewhere else. If you are a Unix lover and have never been interested in OpenBSD before, maybe you should consider taking it for a spin on a Virtual Machine or an older piece of hardware. It is a reliable, secure, traditional in the BSD sense and simple Operating System, ideal for a firewall (or maybe two thanks to CARP), a SOHO router or even an unpretentious workstation.

A few years passed and Joanna created a company called Invisible Things Labs to develop a secure Operating System (Qubes OS) based on isolation and containment. Joanna herself commented that she doesn’t believe in antivirus and that she doesn’t run one herself. While traditional antivirus are undeniably better than nothing, due to the fact that they rely on pattern matching against known threats they are always one step behind the malware authors. Nowadays, antivirus vendors started to realize this fact and are pursuing other paradigms to improve their effectiveness (behavioral and reputation based systems, for example).

Qubes OS comes from an elegant concept: if you can isolate functional components within disposable containers, and you can separate those components that can be tainted through their interaction with the outside world from the core subsystems, you stand a good chance to preserve the integrity and security of the base Operating System at the possible expense of needing to jump through some hoops to move data around the system. All in all it sounds like a good proposition if it can be demonstrated to be practical.

How Joanna partitions her digital life (from the Invisible Things Labs blog)

In its current inception, Qubes OS is based on Fedora core 14, and uses a Xen hypervisor to provide isolation across security domains. Domain 0 is the administrative and management domain and has no networking at all (quite clever!), networking is isolated in its own domain as has a relatively high chance of getting compromised, and user applications can run in their own domains (i.e. a random browsing session running in its own domain can never compromise a secure home banking browsing session). Joanna describes in her own blog how she partitions her digital life across multiple security domains as an example of a possible layout.

The selection of Xen over KVM/Qemu obeys to the fact that it would be very hard to security proof the entire linux kernel and associated utilities to prevent any “leakage” or compromise across virtualized containers, but the codebase for Xen is quite compact and easy to audit.

The current version of Qubes OS is Beta 1 and was released last March. While it’s far from being ready for general consumption (I have tried it in a couple of systems and got it to different running stages, but none of them could be really considered ready for general use), it provides for a good showcase of what this technology is capable of. Essentially, the user logs into a graphical environment, can set up different security domains based on an existing template (provided by the system) and label them with colors indicating their security/trust level (from red to black). Regardless of the color, the security domains are isolated among each other.

As it stands now, Qubes OS can run only Linux applications, but there is nothing inherently preventing it from running MS Windows applications (probably a must for adoption in corporate environments) so this could be a feature expected to come up in future releases. In addition to this, data flows in Qubes OS seem to be currently loosely defined or discretionary at best (it is up to the user to move data among domains and there are no hard rules of what can and cannot be accessed and/or copied to/from different level security domains). One could expect some sort of mandatory access control that could help implement some of the formal security models (Bell-LaPadula, Biba, Clark-Wilson, etc.) to appear in future releases, in order to foster Corporate and possibly Government adoption, particularly in multi-user environments.

Intel Trusted Execution Technology (from Intel's website)

From a security standpoint, of course Qubes OS is still susceptible to attacks, and the most radical being Bluepill itself, which could be preventing by resorting to Intel Trusted Execution Technology (TXT). Traditional malware, albeit not as frequent in Linux environments, could exploit the exposed security domains, but this should not lead to the compromise of the integrity of the entire system thanks to the isolation among domains. And, of course, attacks to the user (social engineering or otherwise) are still effective as only a discretionary security model is implemented in Qubes as of today.

All in all, Qubes OS is a new and refreshing approach to system security. It is based on a few sound and well proven security principles: concise and auditable code at the core/hypervisor, containment and isolation at the heart (a compromised domain can be disposed of without affecting the integrity of the complete system) and an intuitive graphical interface to allow users to model the segmentation based on their needs. Where it still falls short is in its ability to protect the users from themselves, and history has proven maybe too well that end users can be their worst enemies.

Maybe I just grew numb of the claims of revolutionary features and disruptive technologies. Or it could just be that I believe that “featurism” doesn’t equate to software quality, usability and future proofing.

I’ve been involved with Linux in one way or another for far too long now (ever since I saw the original message posted by Linus in the comp.os.minix newsgroup back in 1991), and I’ve played with every major distribution under the sun. You name it: SLS, Slackware, Yggdrasil, RedHat, SuSE, Conectiva, Mandrake, Debian, Gentoo, Ubuntu, etc., all got their fair share of the flavor of the month hardware that I had at the moment (still remember running the first few of these on a 386SX 20Mhz). And there was a time when I could literally recite from memory the complete boot process including every executable and config file, and remember the layout of the init rc system for each of these installations. There was also a time when I could quickly take a look a the kernel source code to understand certain behavior, or even fix an annoying bug.

Nowadays things have grown significantly more sophisticated. The diversity in hardware has increased by orders of magnitude, generating additional kernel complexity (and this not only affects the drivers subsystems), the multitude of commercially supported distributions striving to survive and make money compete for the latest and greatest differential feature that will allow them to see their market share increase by a slim percentage, and the overzealous competition with Microsoft forces the proliferation of capabilities that most of the end users will never need.

And the additional complexity doesn’t stop there: software engineering became increasingly more complex by adding layers of abstraction on top of layers of abstraction under the (false) pretension of “more efficient programming models”, for dubious programming productivity gains at best in many cases. I am not saying that taking away pointer arithmetic from the average developer responsibilities doesn’t help avoid common mistakes and potentially increases software reliability, but it seems that nowadays programmers can’t even code a simple quicksort without resorting to the latest and greatest class part of their favorite object oriented language toolkit library (and maybe some of those people should not call themselves programmers either, but that is beyond the point).

There is nothing inherently wrong with having options, particularly when you don’t need to pay for them (at least directly), and with squeezing a few more drops of productivity out of every programmer, but bloat comes at a price: complexity is the natural enemy of software reliability (and usability). And when I say reliability, I also mean security, code maintainability and general system stability.

Going back to the central topic of Linux distributions: what is that a Linux distribution must absolutely provide? A relatively easy way to install a stable system, a good package management system that handles package dependencies (even reverse dependencies) well,reasonable defaults, a consistent strategy to the installation of additional packages and timely updates. This is not much more than what you could get with RedHat 3.0 about 15 years ago. So how did Linux distributions spend the last 15 years?

I am not advocating throwing away what we have and installing OpenBSD (BTW, Theo, source code patches and recompilation as the official method of updating your kernel and your basic distribution in 2011 truly sucks!); what I am really saying is that we should seriously spend some time understanding what is absolutely needed and cleaning house in the major Linux distributions. Is there a reason why we need several word processors? And why is that we would want to have 2 or 3 different window managers?

And to the developers: I’m not saying that everyone should become a demoscene wizard, but thinking and coming up with an algorithm on your own once every a while, rather than gluing classes together all the time can be a quite fulfilling experience.

Opensource is based on the noble idea of diversity tolerance, but it’s also based on less altruist principles such as Darwinism and “benevolent dictatorships”. It seems to me that the Linux Kernel benevolent dictatorship works (at least to a point), but the survival of the fittest principle is definitively not working when it comes to modern Linux distributions.

While Sony is undeniably responsible for the security of its systems and the personal information exposed, it is only fair to also put significant responsibility on the credit card industry for what could be the largest credit card compromise in history. This event is yet another sign that PCI DSS is just a bit more than patchwork around a broken process.

Who would ever think that a secret shared across hundreds or thousands of people is still a secret? Can someone believe this assumption to hold true while made subject to the prudent man rule? And yet this seems to be what the credit card industry wants to believe by establishing a process that requires a set of “secrets” (name, credit card number, expiration date and possibly cvv) to be shared among the credit card holder and every merchant and payment gateway that card is ever exposed to.

In the physical world, where you are required to present a piece of plastic (and maybe a magnetic band and possibly a photo ID) together with this information, there is at least the additional challenge of counterfeiting the credit card and driver’s license. But in the virtual world where only bits are presented and used for the verification, there is absolutely no restriction over the leak, copy and misuse of this data.

And it is not that there are no other proven methods to perform secure transactions without the need for a shared secret. Public key infrastructure ciphers such as RSA have been known and used for over 30 years to provide digital signatures and non-repudiation. And the best thing about them is that neither they need a secure channel, nor they require the exchange of any secret.

Why doesn’t the credit card industry recognize that the current payment process is badly broken when it comes to e-transactions and moves forward to using digital signatures? It is certainly not because of cost (the new process could be implemented with little more than GNU gpg, a nice wrapper GUI and a good campaign to demonstrate the value of such an approach). Users would create a key pair, the credit card industry would take care of the client certificates and the payment process would consist of digitally signing the invoice with the secret key (which, by the way, is never exposed to anyone). The verification of the signature using the client certificate (or public key) would constitute enough record of the particular transaction.

What is wrong with this picture? If this is a quantum leap over the existing broken process and is a proven method for identity verification, why isn’t the credit card industry mandating it instead of wasting time trying to build fences (a.k.a. PCI DSS 2.0) around sensitive secrets shared by hundreds or thousands of merchants?

I can think of a quick answer, but I hope it is not the reason behind it. My guess is that, by taking the merchants out of the equation, the residual risk would live with the credit card holders, their workstation security and the credit card companies themselves. This situation would make the credit card issuers liable (and not the merchants anymore). Is this too much blame to take for the credit card companies? Is it better for the credit card industry to pretend that this solution doesn’t exist and continue to blame the merchants for their insufficient security and their inability to meet the requirements of the latest and greatest PCI DSS standard?

Maybe one day in Utopia legislators and regulators will consult with true security experts and will be advised correctly. And perhaps that day they will make credit card issuers liable for their inaction. There is even a possibility that this will happen in our lifetime. Until then, we’ll need to continue to fake that nothing happened, that giving your credit card information electronically to any merchant is fine as long as they present a valid SSL certificate and that merchants are the only ones to be blamed for every case of credit card fraud.

I guess there is not much to say for now, other than “Hello, World!” and “It’s nice to be back!”.