Version 146 (modified by proper, 8 years ago) (diff)

multiple security layers

aos Homepage

Technical Intro

aos aims to be safer than Tor alone. The main goal is, that no one can find out the users IP and location.

The basic idea is, that all applications are untrustworthy. No application must be able to obtain the users real external IP. aos ensures that applications can only connect through Tor. Direct connections (leaks) must be impossible. This is the only way we know of, that can reliably protect your anonymity from client application vulnerabilities and IP/DNS and protocol leaks.10

aos consists of two machines, which are connected through an isolated network. One machine acts as the client or "aos-Workstation", the other as a proxy or "aos-Gateway", which will route all of the aos-Workstation's traffic through Tor. This setup can be implemented either through virtualization and/or Physical Isolation (explained below).

The aos concept is agnostic about everything, the anonymizer, platform, etc. See aos Framework below.

aos example implementation: Anonymity setup build around Tor, two virtual machines using VirtualBox and Ubuntu GNU/Linux. aos can be installed on every computer capable of running VirtualBox. (Supports Windows, OS X, Linux, BSD and Solaris.)

Physical Isolation describes installing aos-Gateway and aos-Workstation on two different pieces of hardware. It is more secure than virtual machines alone, requires more physical space, hardware and electricity costs are higher. Keep in mind that you don't need very powerful dedicated servers or desktops. For more information, see aos/BareMetalHints.

See SecurityAndHardening for the threat model and security of aos.

The listed advantages and disadvantages shall give you an overview, what aos is useful for, what aos can do for you, and what not.

Advantages of aos

  • All applications, including those, which do not support proxy settings, will automatically be routed through Tor.1 Only those dependent on UDP2 or IPv612 will still not function. See footnotes for limited workarounds. Services that need to listen on publicly reachable ports (open/forwarded ports) are also not supported. However you may run Hidden services which are reachable via Tor or tor2web (be careful).
  • Installation of any software package possible.11
  • Safe hosting of Hidden services possible. 7
  • Protection against side channel attacks, no IP or DNS leaks possible3 To test for leaks, see aos/LeakTests.
  • Advantage over Live CD's: Tor's data directory is still available after reboot, due to persistent storage. Tor requires persistent storage to save it's Entry Guards.
  • Java / JavaScript9 / flash / Browser Plugins4 / Malware / misconfigured applications cannot leak your real external IP. See aos security in real world.
  • Uses only Free Software.
  • Building aos from source is easy.
  • Tor+Vidalia5 and Tor Browser are not running inside the same machine. That means that for example an exploit in the browser can't affect the integrity of the Tor process.
  • It is possible to use aos setup in conjunction with VPNs, ssh and other proxies. But see Warning. Everything possible, as first chain or last chain, or both.
  • Loads of Optional Configurations (additional features / Add-Ons) possible.
  • Best possible Protocol-Leak-Protection and Fingerprinting-Protection.

Disadvantages of aos

  • More difficult to set up compared to the regular Tor Browser Bundle.
  • Needs virtual machines or spare hardware.
  • Updating OS and applications behind the Tor proxy is slow.6
  • Higher maintenance required.8
  • Tor Button's New Identity button is not supported with aos, see aos/ApplicationWarningsAndNotes#TorBrowser for a workaround.

1 See application warnings below
2 ICMP, ping, VOIP calls13 over UDP, etc... Limited Workaround 1) OnionCat; Limited Workaround 2) Tunneling UDP over Tor
3 The operating system and applications behind the isolated Tor proxy (gateway) cannot determine the real external IP. Therefore they also cannot leak it as long as the network, gateway server, virtual machine or host system are not compromised as well. See aos/SecurityAndHardening for detailed thread model and security considerations.
4 This is still not recommended as they may decrease anonymity (e.g. flash cookies) and often have security vulnerabilities. Most popular plugins are closed source. See Browser Plugins for more information.
5 Vidalia is optional; Arm is recommend as alternative
6 If using Ubuntu GNU/Linux for the client look into Offline updates.
7 Even if someone hacks your hidden server software (thttpd, apache, etc.), he can not steal your hidden service key. The key is stored on the aos-Gateway. Once you cleaned your aos-Workstation, no one can impersonate your hidden service anymore.
8 You need to maintain three instead of one OS. You need to remember several passwords and update at least three systems.
9 There is no difference compared to using JavaScript directly within the Tor Browser Bundle. Of course JavaScript within TBB inside aos will also not leak your IP. Decide yourself. Browser fingerprinting still applies. For more information see Web-browser!
10 aos protects against IP and DNS leaks. Other possible leaks (such as username; time zone; etc.) and how to mitigate them is documented. Additionally aos mitigates many possible fingerprinting attacks by using common, non-identifying defaults. (username set to user; timezone set to UTC; etc.)
11 Must be able to run on Ubuntu GNU/Linux. See Software installation on aos's aos-Workstation for details.
12 IPv6 not yet supported by Tor. (OnionCat is a limited workaround.)
13 Skype over TCP does work, but it's not recommend, because it's proprietary, closed source and there is no control over the encryption keys. Skype authority can compromise you out any moment. A secure encryption/authentication works different. GPG or OTR for example are secure.

Status of aos

aos 0.2.1 is currently alpha quality software. 0.1.3 is beta quality but is now considered outdated and lacking important features.

The basic functionality is ready. You can use aos to browse the web and host hidden services, use email, IRC, ssh, etc. Development is still ongoing and more features are being added to aos. If you want join the development process or want to see what issues are still open visit aos/Dev.

Comparison of aos and Tails

Quick comparison of aos and Tails key virtues. If ever anything in this table is incorrect/outdated feel free to contact aos developers, we'll correct as fast as possible.


aos Tails
Focus on anonymity, privacy and security Yes Yes
Type general purpose operating system LiveCD/DVD/USB
Based on Tor, Ubuntu 3, Virtual Box Tor, Debian
Live CD No Yes
Live USB No Yes
USB bootable Yes 6 Yes
Requires Virtual Box Yes 4 No
System requirements higher lower
Can run in VM Yes Yes
Persistence Full Optional for Live USB
Number of developers one with lots of anonymous contributions multiple
Maturity project since 2012 established, respected project for many years
Open Source Yes Yes
Anonymous developers Yes Yes


aos Tails
Amnesic Optional Feature 7 Yes
Protection against root exploits Yes 1 No 2
IP/DNS protocol leak protection Full 1 Depends 5
Takes advantage of Entry Guards Yes No
Operating System Updates persist once updated are lost after reboot
Hides hardware serials Yes No
Uses steam isolation to prevent identity correlation through circuit sharing Yes No
Includes Tor Browser Yes No
Encryption Should be applied on host. Yes, for persistent USB.
Cold Boot Attack Protection 8 No, planed. Yes


Conclusion: different thread model, different implementation, different use cases, although some overlap.


1 In case aos-Workstation gets rooted, the adversary can not find out the users real IP/location. This is because aos-Workstation can only connect through the aos-Gateway.
2 In case Tails gets rooted, the adversary can simply run ifconfig and see the user's IP. Or he could tamper with firewall rules and bypass them.
3 We may switch in near future to Debian. In long term we are also agnostic about any other secure distributions.
4 Default downloads are for Virtual Box. (Subject for change in future.) You can build your own images for other virtualizers. You can also install on bare metal but we don't recommend that, because using a virtualizer is the only way to hide hardware serials.
5 See first example of aos security in real world. When applications in Tails are configured wrong, due to a bug in Tails or the application, IP can leak.
6 You can install your host operating system on USB.
7 See Recommendation to use multiple VM Snapshots. 8

Comparison of different aos variants

Name Nr. of systems Comments
OneVM host+VM=2 Protection: better security than Tor Browser Bundle, Tor Live CDs
Standard / Download version host+VM+VM=3 Same as OneVM; redistributable and easy to deploy; larger maintenance overhead
Physical Isolation with bare metal Gateway host+VM+host=3 Protection: stronger than standard
Physical Isolation with virtualized Gateway host+VM+host+VM=4 Easier to deploy; higher attack surface; maintenance overhead
Physical Isolation without any virtualization host+host=2 Basically same as standard Physical Isolation;1; no protection against hardware fingerprinting2

Two options for aos-Gateway's operating system. Ubuntu Server 12.04 GNU/Linux (default, recommand). There is Hardened Gentoo based aos-Gateway. (experts only!)

Potential future variant: Live CD
1 Smaller attack surface because not using Virtual Machines.
2 therefore unsupported!

Virtual machines can provide following security related features:

  • Network isolation (connections can easily be forced through tor)
  • Hardware isolation (hide unique hardware serials)
  • Roll back feature
  • Cheap and simple multi-level security through running multiple clones/VMs

Live CDs offer:

  • Non-persistence in case of software compromises
  • Anti-Forensics and deniability (no encryption keys to disclose, if it's powered down and RAM is wiped/faded everything is "gone")
  • But: difficult to roll out security updates

aos Framework

The aos concept is agnostic about everything. With some development effort you can replace any component. The aos developers would like to support each and any use case, but due to limited amount of developers this is impossible and we focus on the aos example implementation.

The Tor network is aos's official and best supported anonymizing network. aos can also potentially and optionally use other anonymizing networks (Such as JonDo, i2p, freenet, RetroShare), either in addition (tunneled through Tor) or as a replacement for Tor. See the article for more information.

You can also avoid using virtualization by using Physical Isolation, although that is not recommend, see Comparison of different aos variants fore more information.

It's possible to use other virtualization platforms (e.g. VMware, KVM, XEN, Qemu, Bochs, etc.) See the article for more information.

Other operating systems (e.g. Windows; *nix; BSD) can potentially be used as host and/or guest operating system. See the article for more information.

One VM

Alternatively, you could also use one VM instead of two where Tor runs on the host. The host needs to be running Ubuntu 12.04.

aos using Physical Isolation

aos using Physical Isolation, setup using two different computers AND virtualization (the most secure Tor configuration to date) is covered on aos/BareMetalHints.

Always install the latest security updates on all systems



This page intends to document security philosophy, design, goals and current shortcommings of aos

aos follows the principle of security by isolation. We know that making our currently used systems secure is a lost cause. They are too complex and too large to be trustworthy and verifiably free of any bugs. aos can't solve this but it tries to minimize attack surfaces and limit what danger exploitable bugs in more exposed parts can do, one primary danger specific to Tor is the danger of exposing the public IP address of a system. aos isolates client applications inside the aos-Workstation from discovering the external IP address. Specifically, aos is designed to prevent direct detection of the IP (not more!) even if an adversary has unrestricted access to the aos-Workstation.

aos security in real world

Some real world examples that are mitigated by using aos:

At first glance this site may make the impression that aos is completely insecure and everything is a lost cause. We are upfront with things we could do better and we are still working on and try to consider all possibilities and document all thinkable and future threats. You must judge for your own which risks are acceptable for your use cases.

aos does not (yet)…

aos is currently alpha quality software and missing features, some of them security related. Some of the following will probably never get "fixed" or implemented because they are impossible to do in a software only project.

aos in its current form does not:

  • Encrypt your stuff or make crappy passwords stronger.
  • Protect against local adversaries (who for example can mount cold boot and evil maid attacks).
  • Automatically protect against time skew attacks (you need to set and check the time of all aos systems manually!).
  • Protect you if you don't read our documentation or do stupid things or change default settings without knowing what you are doing.
  • Automatically apply security updates. This was a conscious decision because automated updates also come with their own set of security problems.
  • Automatically isolate different identities and pseudonyms from each other, you should use multiple aos-Workstations
  • Protect against global network adversaries.
  • Protect against hardware or software backdoors.
  • Automatically protect against MAC address fingerprinting on public networks.
  • Protect against the more skilled software attack, unless you use Physical Isolation.
  • By default, protect you if Tor is somehow broken. You can improve that to some extend and with caveats by chaining Tor with SSH, proxies or VPNs.
  • By default, hide the fact that you are using Tor, though there is an optional feature, Hide your Tor usage.
  • Use all the possible hardening options like full PIE and grsecurity. It doesn't use AppArmor profiles for everything.
  • Have deterministic builds. Also Tor itself does not have deterministic builds yet.

If you want to help us improve the security of aos, please join the discussions on aos/Dev or expand this site.

About Computer (In)Security

A secure and trustworthy computer is a computer that only does what _you_ (think you) tell it to.

Computers are insecure and not trustworthy and there is nothing we can do about that. Computers are "universal machines" (see Von Neumann, Turing). They can be instructed to do anything they can do according to the laws of physic. It's important to understand that a computer can't discern between "good" and "bad" instructions, bits are bits. There are two general problems:

1) There are a lot of people who can instruct a given machine to do something (anything!), we need to trust them all, or verify everything, which is impossible

If you read or write all instructions (kernel, software, firmware) yourself, study the hardware design (so you understand what an instruction actually does) and compare that with the actual hardware and then make sure you are the only one who can access the machine and give it new instructions, you need to trust that other people only give the machine instructions to do things that you want it to do. You can tell it to accept other, external untrusted instructions in a restricted, controlled fashion (like "render that html but other wise don't touch my system") but this is next to impossible to do reliably because of point 2). Otherwise you could never connect that machine to a network or transfer any input from another system to it ("input" and "instructions" has to be understood in a very broad sense, it's not just about executable code, it can as well be media files or hardware devices that are being attached).

The "Trusted Computing Base" (TCB) refers to all instructions and hardware used to restrict a "universal machine" from accepting and acting on (other) arbitrary instructions. It is used to set a certain security policy to enforce that a computer only does what these trusted instructions allow it to. "Trusted" simply means that we have to trust it, not that it's wise to trust it. The TCB tries to restrict what instructions can do but it consists of instructions itself. It can't restrict or police itself. Any flaw whatsoever in the TCB directly results in a compromise of the security of the system.

2) The machines themselves and the instructions are incredibly complex

Even in an ideal world with mathematically verified hardware and software we may think we are giving instructions to do A while in reality the instructions tell it to do B, or also B. Machines can not make "mistakes" but they certainly can do unexpected things...

We can't give machines instructions in our language (programming language) it needs to be in machine code. The translation is so complex that we need another machine to do that for us, and to create that machine another was used and so on. This expands our chain of trust to basically all machines and humans involved to the first compiler created by an assembler which in turn was created by hand-written machine code.

Hardware is fallible, hardware failure can result in entirely unpredictable results. Cosmic rays "flipping a bit" or just bad memory and extreme temperatures? Look up "Bit-squatting" for an example. Software depends on the hardware to function perfectly, what happens if the most basic assumptions are betrayed?

Another example for complexity, side channel attacks: they are very difficult to protect against and poorly understood by most software developers. E.g. through power or CPU load analysis otherwise isolated parts outside the TCB can influence or eavesdrop on privileged encryption. In other words, determining what is part of the TCB and what is definitely not, is a very hard problem.

If that wasn't enough we also have the problem that circuit layouts, microcode and firmware of most vendors is proprietary. Part because of competition concerns, part because they are afraid of patents... In any case, this makes verification even more difficult that it already is. Further "hardware" (which includes firmware, i.e. software) is becoming more and more capable (=complex and dangerous). Features like Trusted Computing when used to prevent ring 0 access from the user and owner of the computer, EFI that has Internet connectivity and can update itself or Intel RMM which can grant remote access that is invisible to the user and OS combined with a less than perfect track record (e.g. see Intel related research by Invisible Things Lab) doesn't exactly spell trustworthy and 100% dependable.

Conclusion: The TCB can never really be trustworthy. The source code of every currently usable OS kernel alone is too complex and large to completely audit and make error free, not just for a single human but even for large groups like the "Linux community". But let's assume we solve that (e.g. through using microkernels and formal verification): How do you make sure compiled binaries are actually doing what the source intended? Or, how can you verify that complex hardware and integrated circuits are actually built according to their intended design? For all the verification and auditing processes we are dependent on other complex computer systems that would have to be trusted unconditionally. Bootstrapping trust is a chicken and egg problem. We would have to be able to verify systems with just looking at them with our bare eyes and hands or build/verify all systems necessary to bootstrap a modern compiler and hardware development platform. This may have been possible for the first "computers" in the first half of the last century but not anymore.

Since there's nothing we can do about that, what else can we do then?

We need to design our systems in a way that makes it no longer necessary to trust them 100%. We only need to trust that it's good enough and that it's astronomically unlikely that multiple diverse systems are untrustworthy in the same way.

If you don't want a computer to be able to tell anyone your location or identity better make sure the computer doesn't know either... The aos security design in some ways mimics the security design of the Tor network itself: Don't trust any single entity to be trustworthy. We only rely on the fact that it's unlikely that all entities (nodes, computers) are compromised and colluding. To be precise, that's a goal that isn't achieved yet with aos alone, see aos². One could also say that the actual TCB of such a "system" (actually multiple systems) becomes the design, arrangement and usage policy which is very well possible for every user to comprehend and verify.

This could be compared to the "Air Gap" used on most high security networks. They assume that the TCBs are not trustworthy and work around that using a simple and easily verifiable policy that basically eliminates the complete attack surface or hardware and software bugs and even protects against most backdoors (for example, a subverted PRNG could still result in weak crypto being exported from the trusted network where it can be recorded and "cracked" by an adversary. A strong pyhiscal isolation based system could then encrypt data twice on different systems using different PRNG implementations to protect against such attacks.)

Physical Isolation in the sense of aos is not a new idea, see Verifiable Computer Security and Hardware: Issues by William D. Young. September 1991 (PDF!) page 18 for a summary. It seems like the idea was rediscovered by aos (independently, and we came up with the same term), to our knowledge aos is currently the only project following this approach in a defined way.

Our Threat Model

The Threats

First let's quickly consider all the possible threats we could face. We can put threats against computer systems into five categories:

  • 1) Non-technical/non-computer-based and legal attacks

E.g. "rubber hose cryptanalysis", mandatory key disclosure, subpoena, real police work/espionage (done by real humans, not bots), bugs, surveillance cameras...

  • 2) Hardware attacks through physical access.

RAM and Hard disk Forensics, keylogger, TEMPEST, Evil Maid attack...

  • 3) Backdoors

Intentional weaknesses or additional hidden "functionality" put into your system by a manufacturer, vendor or distributor (hardware or software) allowing remote access1 Can be put in anywhere between design/source code, manufacturing/compilation or distribution.

  • 4) Vulnerabilities

Coding or hardware design errors that can be exploited to gain remote access1 Vulnerabilities and Backdoors in practice can look exactly the same, only the way they are created differ.

  • 5) Design flaws

Even in a backdoors-free, error-free system with perfect physical and legal protection (no such thing in reality) perfect security may still be impossible. This is especially true for anonymity systems. While with cryptography a perfect design exists (the one time pad) anonymity isn't binary. You are not either anonymous or not, you only have some non-zero but not-perfect degree of anonymity. Your anonymity depends on hiding amongst others. Anonymity networks require trust and a large and diverse userbase. A perfect security system wouldn't require trusting other parties or depending on such extraneous factors. Any design of a complex (but still usable) system (all computer systems are complex) needs to make tradeoffs. That's why pretty much everything uses non-perfect cryptography instead of the one-time-pad...

1 Used in the broadest sense, can be classic remote code execution, privilege escalation, DoS... Essentially they all allow remote parties to send your system instructions that diverge from the allowed security policy

Attacker capabilities

  • Legal/Non-technical "attacks" and physical access is expensive

Anything that requires real humans to do work instead of letting computers and algorithms do it is prohibitively expensive against more than a small target group.

  • Backdoors (hardware or software) are expensive

It is hard to make one and it's risky. The more you use it the more likely it is it will be caught and closed. Adversaries are not going to waste it on anything but high profile targets. However, well hidden passive "backdoors" are of a concern, they can practically be impossible to detect and remain functional for years. Imagine a backdoor in a compiler affecting the PRNG. The cost for such backdoor is high (for this example an attacker need patience, non-trivial coding and social engineering as well as some crypto skills) but the "ROI" would be great too...

  • Software attacks are cheap

A good 0day can still cost a lot and isn't useful for very long once you start using it. But new vulnerabilities are found all the time, new exploits can be written. Compared to physical access and backdoors it is cheap. It can be fully automated against a large target set.
If you are wondering how realistic or important the client application 0day threat is consider pwn2own 2012. A semi-legal but most certainly immoral and reckless company demonstrated how they can exploit every web browser circumventing all state of the art security features (MAC, Sandbox, ASRL, NX, etc). This is not too surprising, we already established how big code bases always have bugs and a subset of those bugs will always be exploitable. The noteworthy news here is that this company doesn't report their findings to the developers, they sell it to governments (and/or the highest bidder) as offensive "cyber weapons" (naturally not their term).
It's only likely that also Tor vulnerabilities are sold behind closed doors. You should act accordingly and never rely on Tor alone if your threat model demands "reasonably strong anonymity" even from not-nearly-global but well funded adversaries.

  • Crypto-attacks are enormously expensive

If you know how to break currently used crypto you will try keep this a secret at all costs. Most crypto attacks will most likely require enormous computing power.

  • Attacking design flaws: it depends...

The costs can vary greatly but in every case, once you attack a design flaw and it becomes publicly known the target will fix the flaw and will become harder to attack in the future. This can result in an arms race and often neither party wants to go that way. A grave problem for the defender side can be that some systems are so widely used that it becomes almost impossible to mitigate away to a more secure design. The best example for that is the certificate authority system. It's design is flawed on so many levels yet it's relied upon, often solely for all authentication and confidentiality, to this day by pretty much everyone who's ever used a computer. Similarly, a lack of crypto and hash agility in many applications results in a dependence on weak and broken algorithms, not because we don't know any better but because backwards compatibility and some bad apples spoil it for everyone. There's certainly a threshold, were, if an attacker plays it slow and carefully, he can stay just below the radar for a long time and let everyone believe that it's not "that bad yet". For example, a collision attack against SHA-1 (which would affect software updates, version control systems as well as Tor, GPG, TLS and pretty much everything that uses public key crypto) is known to be "within the reach of a powerful adversary" since 2005, with Moore's Law and Schneier/NSA's Law ("Attacks always get better; they never get worse") in play the range of potential adversaries only got larger. SHA-1 will probably be relied on pretty universally until someone publicly demonstrates a collision. Not because we don't know any better, but because to cost of switching are so high.

Our Goals

  • Hiding our Location and Identity when transmitting information
  • Confidentiality, Integrity, Authenticity and Availability of transmitted data

Our Attack Surface

Basically any part used by us to achieve our goals can be attacked:

  • We need some physical security and privacy. It's obvious that anonymity and confidentiality is difficult or impossible to achieve otherwise.
  • Tor, the code, the design, the whole network (see "aos's Tor Setup" below for more)

We also can't look at Tor as an isolated piece of software, we need to consider its whole TCB because if any part of a TCB can be subverted the Tor process can be subverted. The attack surface in case of backdoors is the full TCB, in case of vulnerabilities "only" the network facing parts of the TCB.

  • The aos-Gateway Hardware
  • GNU/Linux/Ubuntu: kernel, essential userland, apt-get and all software update packages provided by the OS distributor/vendor
  • Tor itself
  • The build system (gcc...)

Using Virtualization (instead of "PhyIso") increases the TCB significantly. In addition to the above:

  • Host Kernel
  • Host applications
  • Host software updater
  • Virtualization software
  • We rely that the software we use doesn't more than absolutely necessary reduce our anonymity set through protocol leaks, identity correlation and fingerprinting. For that we also have to rely on the aos-Workstation and the TCB of the applications we use. (for more see

"aos's Protocol-Leak-Protection and Fingerprinting-Protection" below).

For Confidentiality, Integrity and Authenticity we (we all, not just aos...) are still way too heavily dependent on TLS (Transport Layer Security, the "s" in https). Further we depend on:

  • The complete Host (Hardware and Software)
  • all software in aos-Workstation
  • TLS/PKI infrastructure
  • In case of hidden services: The full location/identity TCB.
  • The "other end", the security of whoever you are communicating with, unless it's symmetric key crypto and you got the only key.

To achieve Availability of information we depend on:

  • the upstream internet provider, uptime and connectivity
  • Tor network resilience against DoS
  • resilience of webservers you connect to against DoS
  • Your own system's resilience against DoS

Applying the threat model to aos

First of all, you don't want to end up in the "high profile target" list of any of your resourceful adversaries. Because if you do neither aos nor any other computer based system can protect you.

aos is mostly a software project. There isn't a lot we can do on the hardware and physical side of things. Hardware security would be a much smaller problem if we weren't using monolithic systems where dozens of parts have full system access through DRM (or indirectly though hardware drivers that all run in kernel space). Have a look at QubesOS for state of the art hardware deprivileging. It requires latest gen hardware and software support still needs to catch up, therefore this isn't available in aos yet.

We assume the hardware is trustworthy, we assume the physical location is not compromised. To protect against forensic analysis we recommend to use full disk encryption, wipe the RAM on shutdown. We recommend to use "clean" computers made of parts manufactured by reputable companies and to pay in cash so as to not have hardware IDs leak our identity. Further some pointers:

  • DMA is bad, IOMMU is good, avoid attaching untrusted (or any for that matter) devices on Firewire and PCI* interfaces.
  • Use open source hardware or at least open source friendly that makes specifications public. Open source means that multiple companies can implement the hardware, the Linus law of "many eyeballs and all bugs are shallow" applies, backdoors are harder to hide.
  • simple is beautiful, complexity is the enemy Nr.1 of security. aos-Gateway can run on very simple hardware like the Raspberry Pi.

Crypto is even worse, the only thing we can do is to use cascades of different cipher and hash families. This is slightly more complicated than it sounds and we don't know of any software that does it right.

As established above in "Attacker capabilities" the main attack vector we need to concern (and we can actually do something about) is software attacks.

To protect against software backdoors and vulnerabilities:

  • the source needs to be audited, preferably by yourself and many others and should ideally be bug free.

Popular open source projects are your best bet. aos is fully open source, anyone can audit and patch. aos comes with a software updater which allows rapid deployment of security patches.

  • if you rely on others (you do), you need to make sure that you get the same code as everyone else

Hash sums + signatures, the more public they are, the better. If completely transparent signing is used (as common in proprietary systems) it's much more difficult to determine that you get the same files as everybody else. By default signing is only concerned with making sure that you get code by someone with access to the key. This protects against 3rd parties but not insiders. Checksums and signatures of aos and updates are publicly available.

  • the code you use should have a good track record, know issues must be corrected immediately

Code that doesn't get checked but has zero known problems is worse than code that has hundreds of known and patched security issues but is constantly being reviewed and worked on. However, a trustworthy code should have very few if any security issues despite having been audited thoroughly. After all, projects that constantly need security patches are constantly insecure. But it's not really about numbers, check the severity of the bugs. Linux needs many security patches but fatal flaws that would affect aos are few and far between (i.e. remote code execution with root privileges). Fatal flaws in user facing applications (like browsers, pdf readers, media players, IRC) are frequent and therefore such software is not be part of the TCB (see below).

  • checking the source is not enough, you need trustworthy binaries

analyzing binaries is a lot more difficult than analyzing source code. If you rely on source code auditing you absolutely require a trustworthy compiler (and a complete trusted system to run it on) and use DCC. Similarly you already need a trusted system to check signature and hashes. This is the bootstrapping chicken and egg problem we mentioned earlier. Generally, to address it you need to use at least two different diverse systems that are completely independent (includes their parent build system and compiler) and set up the system in such a way that both would have to be compromised by the same adversary in a compatible way in order to result in a fatal security breach.

If the code base is huge and complex code auditing isn't a realistic strategy, therefore we need to reducing complexity and attack surface by:

  • making the TCB small


  • using privilege separation:

The TCB for identity/anonymity is as small as it gets on a monolithic general purpose OS. It could be smaller (e.g. a custom kernel, busybox, uclibc instead of libc and gnu-utils) but that comes at the cost of maintainability, security updates and ease of use. (and still leaves us with a comparably huge monolithic kernel and a gigantic gcc infrastructure).
Linux/Xorg (with DAC or even MAC) isn't very good with privilege separation (e.g. no trusted path). The strongest privilege separation is offered by using multiple physical computers, that's what we recommend (Physical Isolation ("bare metal") aos-Gateway, multiple aos-Workstations). The more practical but less secure alternative is virtualization. For details about privilege separation between IRC/Browser/Clients and Tor see below: aos Tor Setup.
We've thought a lot about making aos yet more secure but with the (free and open source) tools available today it doesn't seem possible. What we'd need is a isolation kernel that would offer some strong guarantees of isolation between the different subsystems and ideally would be verified so you don't have to worry about sophisticated backdoors (apart from the compiler, see "Trusting trust"/chicken and egg), software vulnerabilities and even some hardware backdoors and vulnerabilities (through IOMMU and microkernel design one can put hardware and firmware components, apart from the CPU, out of the TCB).
For Fingerprint/Protocol leaks and the CIA Triad we are depending on the aos-Workstation TCB. This is a hopelessly large TCB/attack surface. For this reason we use yet another approach which can be called "security through non-persistence". That is, you should extensively make use of the snapshot and roll back feature of the virtual machine. Instead of privilege separation within a Tor-Workstation (e.g. by using a Mandatory Access Control framework) which would come at great usability costs we recommend to use the coarse-grained isolation provided through multiple VMs (also see "About grsecurity" below).

To protect against software attacks (vulnerabilities) in particular:

  • make software hard to attack

ASLR, canaries, NX, kernel hardening, See the ubuntu section below: About Ubuntu. Note that this makes attacks "harder" but not impossible. Hardening is no replacement for fixing bugs. In a really trustworthy system hardening would not be necessary.

  • detection

This is still left to the user. IDS, Log auditing. The usefulness of this approach is limited. It doesn't prevent security breaches. It can only help making future breaches less likely.

To mitigate Design flaws the primary strategy is eliminating single points of failure. Do not rely on Tor alone, use wifi or tunnel through another system running VPN. Do not rely on TLS alone, use GPG as well (and vice versa). Do not rely on a software monoculture, you shouldn't have to rely on Ubuntu/Canonical's infrastructure to never be compromised. We are currently guilty of not following this advice. To lessen the impact of a potential compromise of the update infrastructure (which includes developer machines, build systems, key security and cryptographic primitives like PRNG - remember openssl or Flame?) we do not enable automatic software updates. After all, they are essentially remote root level backdoors (although with some checks in place).

Notes about securing Confidentiality, Integrity and Authenticity

This is no different than in any other computer system without Tor. Use end to end public key encryption, there is not really an alternative to that. But there are alternative implementations: TLS, SSH, GPG... End to end means both ends need to be secure, one end is the aos-Workstation which you can control and secure. In case of hidden services, the aos-Gateway is ALSO part of the TCB!

aos-Worstation isn't specifically hardened because hardening a Desktop system to a degree that makes it actually secure against a serious adversary makes the system unusable. Instead we follow the nuke and restore approach, see below: Recommendation to use multiple aos-Workstation VM's and Snapshots

About Availability: This is most likely the least of our worries. The most resilient approach is probably a distributed data store, like Tahoe-LAFS or Freenet. i2p offers multi-homing built in. For Tor we don't know of any solutions ready for general usage.

Notes about End-to-end security of Hidden Services

Hidden services are not really "end-to-end" encrypted, they encrypted only Tor to End. (or "Tor to Tor") The communication between the browser or server and Tor is sent in clear text. This doesn't really constitute a security issue, as localhost (or Workstation to Gateway on an isolated network), is supposed to be secure. But it has some security implications:

With hidden services alone, without TLS enabled, the adversary only needs to compromise aos-Gateway to get knowledge of the content of the connection and the clients identity/location. To compromise the content of the connection, the adversary only needs to compromise either the gateway or the workstation.

With hidden services, and TLS enabled, an adversary needs to compromise aos-Workstation to gain knowledge of the content of the connection. The adversary would have to compromise aos-Gateway as well, to gain knowledge of the client's identity/location.

It is most likely possible to use hidden services and TLS at the same time ("https://****************.onion"), but since this only offers benefits to users of aos (and other Tor gateway implementations), there is no demand and we don't know if any TLS enabled service exists at all. It would provide some nice defense in depth as it eliminates a single point of failure.

It would open the question, how would the certificate be verified? That's simple for private sites, where server and clients know each other. And public hidden services? It is unlikely, that certificate authorities will give out certificates for .onion sites. Although you could try asking, they offer free SSL certificates for people who can prove that they own a domain. And you prove, that you have control over the domain. (by editing the contents). But CAs should not be relied on anyway. Look into Monkeysphere, Convergence or Perspectives Project...

Hidden Services with aos are still safer than running Tor and the server software on the same host, see below for more information.

Design Document, innovations and research

aos developer proper is also interested in serious design documents. There is only one design documents with respect to Tor, transparent/isolated proxying, isolation and Virtual Machines. Proper has read the old design paper "A Tor Virtual Machine Design and Implementation" from 2009, which can be found at DesignDocumentBase. After reading, proper forked that paper, removed non-essential, non-security relevant stuff and made sure, all considerations from the old design paper, were implemented into aos. The forked paper can be found at DesignDocument.

The whole aos documentation, especially TorBOX/SecurityAndHardening and TorBOX/ApplicationWarningsAndNotes supersedes the old design document. Also the TorifyHOWTO is co-maintained by proper.

Also the following documents are being monitored.

If there are any security/privacy/anonymity updates they will be considered for aos.

The aos project also enjoys asking good questions, providing useful suggestions and creating useful things.

The following list is to keep track of all discussions and to review them in the future again, to see if something has changed.

Hidden Services

Be sure to read and understand Tor: Hidden Service Protocol (generals information) and Configuring Hidden Services for Tor (standard setup, no isolated proxy) first. You can provide any server service, which relies on TCP. Beware of application level leaks. Some servers will leak information such as your time zone or information about your hardware and of course whether the service (and presumably Tor) is up and running or not. See Security And Hardening for more information.

Note that hidden services are always only reachable using Tor or tunnel services, such as tor2web, (be careful).

You do not need SSL, because connections to Tor hidden services are end-to-end encrypted by default (to be exact, only tor-to-tor, see above). This is handy, as you do not have to bother with self singed certificates or certificate authorities.

Even if someone hacks your hidden server software (thttpd, apache, etc.), he can not steal your hidden service key or bypass Tor. The key is stored on the aos-Gateway. Once you cleaned your aos-Workstation, no one can impersonate your hidden service anymore.

aos's Tor Setup

  1. We don't try to defend against network attacks, the usual things discussed, like a massive amount of evil nodes. We leave that to the Tor developers. aos is based on Tor. Any successful attacks against Tor, does also work against aos. This will result in a compromise of location/identity unless Tor is combined with other means of anonymization
  2. if TransPort, DnsPort or SocksPort which aos heavily relies on, can be exploited, then it's also game over. Tor (with TransPort and DnsPort) runs on the aos-Gateway and is able to determine it's real IP. Once there is a vulnerability found in Tor (ex: exploiting TransPort or DnsPort) and an attacker can overtake the aos-Gateway though Tor, he can also find out the real IP.
  3. Same goes for iptables. aos is a setup based on Linux, iptables, Tor, etc. If any of the underlying projects has a vulnerability, which we can not rule out, of course, aos will fail as well.

There is no known bug (or "feature") to obtain the users real IP address through either SocksPort or DnsPort. If there were such a bug found in the future, which is possible, it would be a major bug in Tor, then we would hope, that the Tor developers fix that bug. We hope that compile time hardening features will be added (bug #5024 and #5210).

There are other attacks thinkable, which we can not defend against. For example, if an adversary controls your entry node and has access to the aos-Workstation. He can simply use "morse" (5 seconds much traffic, 10 seconds no traffic...) And then observe it's incoming connections. Then it's game over as well.

There are three ways to torify. Read the link for a comparison of the security.

aos's aos-Workstation has no access to the internet without using Tor. You can look into our setup. It's all Open Source and well documented. IP-forwarding is disabled. The firewall fails "closed": when Tor is disabled, loses connection, or the aos-Gateway crashes, no network connections are possible. Iptables redirects any traffic from aos-Workstation to Tor's ports. Local network connections are dropped. No leaks are possible, assuming the TCB is trustworthy.

aos uses multiple security layers.

  1. Applications are configured correctly using latest suggestions (correct application and proxy settings, stream isolation).
  2. Firewall rules are enforced and prevent accessing the internet directly, thus leaks are prevented in case some application leaks.
  3. Optionally physical isolation is provided.
  4. aos's Protocol Leak and Fingerprinting Protection

aos was tested for leaks and all went negative. Additionally, Skype, which is known for it's ability to punch through firewalls, was not able to establish non-torified connections. Also Bittorrent doesn't leak the IP (there is an online bittorrent leak tester). which of course should never be used through Tor (because it chokes Tor nodes)t but for leak testing it was welcome. Right now we don't know of any leak tests which leaks the real IP.

Protocol leaks, like this this, Skype or Bittorrent are not possible. This already justifies to use a "no non-Tor connections possible" approach.

When you go ahead now, and ask in a cracker forum, they probable won't spread a simple method to get the real IP of aos's TorWorkstation. On the other hand, if you run an intelligence service and have 100.000 $ left over, you can announce something like "find a new exploit in Tor's SocksPort and get 100.000 $". Qualified people start looking into it and might find something.

aos's Protocol-Leak-Protection and Fingerprinting-Protection

* Read Security of aos and aos thread model above first!

aos can not do the impossible and magically prevent all kinds of protocol leaks. However, it does offer best possible protection. It is a multi level protection always trying to prevent the worst.

  1. most dangerous leaks are protected
    • Your real external non-Tor IP address are covered due to the whole aos design, isolated proxy usage and the aos firewall. 1
    • The same as above goes for DNS1 requests, they are safe. 2
      1 This does not cover application vulnerabilities and exploits, which escalate from the virtual machine to the host see *. However, by design, the aos-Workstation does not know it's own external non-Tor IP address.
      2 /etc/resolv.conf in aos-Workstation is configured to use the aos-Gateway as DNS resolver, which is routed through Tor.
  1. Many aos default applications are already configured, not to leak:
  1. Many protocol leaks are documented (read!) and also workarounds are provided (read!).
  1. aos uses common, non-identifying defaults.
    • Internal (virtual LAN) IP address is the same for all aos users.3
      3 You can check that yourself using 'ifconfig'.
    • Time zone is set to UTC.
    • User name is set to user.
    • MAC address is the same for all aos users.
      • aos-Workstation's MAC address is shared among all aos users. That is useful, in case an application leaks the MAC address or in case aos-Workstation got compromised.
      • aos-Workstation can also see aos-Gateway's MAC address.
      • aos-Gateways MAC address is also shared among all aos users. This may have side effects, were are still discussing, see Mac address in public networks.
    • Disc UUID is the same for all aos users.
    • Hardware serial numbers which any applications could collect are hidden due to the Virtual Machine.4
      4 You can check visible hardware yourself with 'sudo lshw' and "sudo lspci". Use 'usbutils' if you installed USB.
    • CPU model and capabilities are hidden by Virtual Box "Synthetic CPU" option.
    • Unfortunately, the clock speed of your host CPU is visible to all code (applications or malware) inside aos-Workstation.5
      5 This is due to the design of virtualization platforms (VirtualBox, VMware, etc.). Most virtualization platforms leak cpu model, capabilities and clock speed. VirtualBox (4.1+ if not earlier) can mask at least the model and capabilities of the CPU with the "Synthetic CPU" option. This option is activated by default on aos 0.2.1 and above. Check cat /proc/cpuinfo. If that is a still problem for you another workaround could be to use an emulator, such as bochs or qemu. Unfortunately such emulators are slow.
    • All aos users have by default the same set of software packages installed. - If you install software packages yourself, you give up that advantage. See also Software updaters and Software installation aoss aos-Workstation.
    • Automatic updates are routed through their own circuit (stream isolation) to prevent accidentally leakage of your software packages and versions (if any custom software installed) which then could be correlated with other anonymous activity. See also Software updaters and Software installation aoss aos-Workstation.
    • Metadata (as explained under protocol leaks) can not be used to de-anonymization, if you follow the following guidelines:
      • Always think twice before uploading anything.
      • Upload only files, which you, either:
        • created inside your aos-Workstation
        • downloaded using your aos-Workstation
        • carefully scrubbed yourself
      • For example, if you want to upload photos or videos, unless you know what you are doing, get an extra device, which you only use for anonymous usage.
      • Keep in mind, that even if de-anonymization is not possible, that still identity correlation to the same pseudonym might happen. For example, let's suppose your created a video using any video creation software and you uploaded it to a popular video portal under the pseudonym A. Then you create a another video using the same machine (and same application) and upload it under the pseudonym B. An adversary checking the metadata could correlate pseudonym A with pseudonym B.
    • Worst case scenario: contents of your RAM (error reporting ram dump; Transparent Proxy Leaks) would "only" contain the RAM of your aos-Workstation. All your non-anonymous stuff on your Host would stay safe.

Software installation on aos's aos-Workstation

You can install your own software packages on aos-Workstation using 'apt-get', as it's based on Ubuntu. This has some advantages and some disadvantages as well.


  • You should still try to prevent any other protocol leaks using the TorifyHOWTO (but most of those most are mitigated by using aos).
  • When you are updating using apt-get, you'll leak which software packages and versions you have installed, see Software updaters. These information can be probable correlated to the same pseudonym. To prevent that, you should update using the guidelines below "How to safely update using apt-get?".

Extra care is needed when adding extra custom repositories, especially PPA's (Personal Package Archives). Single developers may be pressured and/or turn malicious more easily than the main repositories.

How to safely update using apt-get?

  1. Stop all your activities.
  2. Change your circuit.1
  3. Update using apt-get after a random delay.
  4. Change your circuit again.1
  5. Continue your activities later with a random delay.

1 One way to do it using Arm: Go to your aos-Gateway and start "arm". Press 'm' for menu, go down to "New Identity" and press enter.

aos in public networks / MAC Address

Keep care in public networks. Note the following advice.

Source of information: Tails 1; Tails 2. Both worth reading! Thanks to Tails!

Every network interface has a MAC address. The MAC address is only visible inside LAN, not inside WAN. While you are at home, this isn't an issue.

There are cases, were some stupid applications gather your MAC address and send it to a remote server (proprietary license checks use the MAC for hardware fingerprinting). That's not an issue for aos, since all aos users share the same MAC address on aos-Workstation, see aos' s Protocol Leak Protection and Fingerprinting Protection for details.

You have to keep care, if you are going to use aos in public networks (i.e. open WIFI hotspot). The admin might log your MAC address.

Rather the admin might find out, that you are using Tor, depending on your your configuration, i.e. perhaps you are using obfsproxy or you tunnel your traffic SSH/VPN -> Tor and on the adversary's skills.

The MAC address and being a Tor user, might depending on your personal thread model, be a risk visiting that public network (again).

Using a random MAC address is not recommend. While this might sufficiently confuse some adversaries, it won't defeat skilled adversaries. If you are using a random MAC address, it might happen that the vendor id part of the MAC address is non-existent. Even if it were existent, you might up with a vendor id, which has either never been used or never been used in decades. If you are going to spoof your MAC, you have to use a popular vendor id.

The initial second part of the MAC address may be random/unique.

If you are going to use the same public network again, you have to decide, depending on your thread model, if you are going to use the very same MAC address or if you are going to create a new MAC address. In case you suspect, the admin has seen you and logged the MAC, you shouldn't change the MAC, since this were suspicious. If you believe that public network is so public, that no one has seen you, you might decide to use a new MAC address (popular vendor id, random/unique second part) each time you step by.

Unfortunately, we can't yet provide detailed instructions on how to create such appropriate MAC addresses. Research is still ongoing.

Apart from the difficulty creating such an appropriate MAC address, there are also technical hurdles. All the care creating the MAC does not help, if you boot your computer and it instantly connects to the public network and spills your MAC. For Virtual Machine users: your host operating system most likely automatically connects (updates, perhaps time sync). For Physical Isolation users: aos-Gateway automatically connects to Tor after start.

Also if you plug in a wifi stick, it might happen, they automatically try to connect and spill your MAC.

TODO: test and expand, please help! To change the Mac address in Tor-Gateway or a Debian/Ubuntu host edit /etc/network/interfaces and add "hwaddress ether 00:00...." To automatically randomize the MAC address on boot add "pre-up macchanger -e eth0" instead. To prevent automatically bringing up new network interfaces I think all that's needed is to uncomment "auto eth0", then manually bring up with "sudo ifup eth0".


Harden the Host

If the host is compromised so is every VM, Tor and all anonymous communication. The host should only be used to run and manage the VMs. General hardening recommendations apply: Minimize attack surface, securely configure services (e.g. for ssh: use fail2ban, allow only key authentication), add proactive (compile time hardening, MAC, IPS...) and retroactive defenses (rkhunter, IDS, AV...). This is probably beyond the scope of this guide.

To protect against physical attacks use FDE (Full Disk Encryption) and always lock the screen if you leave the system unattended. Keep cold boot attacks in mind. Unfortunately there is not yet a upstream script, to implement wiping the RAM. We can not provide a solution for this attack, this is solved nowhere but partially in Tails and Liberte Linux (not checked), waiting for upstream solution, see Wipe RAM panic script.

Harden Virtualbox

For an overview on security risks of VMs in general: How secure are Virtual Machines really?

The less features the smaller the attack surface. Here are some suggestions for features which you can remove and not impact core functionality:

  • Disable Audio
  • Do not enable Shared Folders
  • Do not enable video accelaration
  • Do not enable Serial Port
  • Do not install Guest Additions
  • Remove Floppy drive
  • Remove CD/DVD drive (after installation)
  • Do not attach USB devices
  • Do not enable Remote Display server
  • Do not enable IO APIC, EFI
  • Enable PAE/NX? (NX is a security feature)

For the best security you should consider using multiple physical systems instead of VMs, see Physical Isolation.

Harden aos-Workstation

If this VM is compromised all data it has access to, all credentials, browser data, passwords... the user has entered can be compromised. The IP is never leaked but these information can still result in identity disclosure.

Use AppAmor:

Best practice is to create snapshots of the VM and "roll back" after risky activity and whenever the user suspect the integrity of the system could have been compromised.

Harden aos-Gateway

Note that the aos-Gateway itself will not be "torified" (routed through Tor) by default.

You should never use it for anything other than running Tor on it!

If this VM/computer is compromised the identity (public IP), all destinations and all clear-text (and hidden service) communication over tor is available to the attacker.

Our first goal in securing the aos-Gateway is minimize its attack surface. By installing a "minimal system" and using static IPs the only attack surface to an external attack (i.e. not physical and not attacks from the host which can never be protected against) is Tor itself. You can verify this with netstat.

Security features that do not prevent exploitation but only restrict what exploits can do, such as chrooting or sandboxing, do not make much sense: A compromise of Tor already results in a compromise of everything the user cares about.

Compile time hardening (see bug #5024) should be done by the Tor package maintainer and is beyond the scope of aos.

Ubuntu is a good choice as a base for the aos-Gateway, Tor is well supported and compared to Debian for example, all the currently used compile time hardening features are supported by default Ubuntu Security Features. More secure and hardened Linux or BSD based options do exist but they require too much work and/or maintenance to be considered for aos. Having said this, you are welcome to use your own distro or follow Hardened Gentoo based aos-Gateway. The basic idea of the aos setup is fairly distro agnostic. You just won't be able to thoughtlessly copy and paste commands or to use the setup script without modifications.

Recommendation to use multiple VM Snapshots

Apart from offering protection against hardware serial leaks VMs got another great advantage: the ability to quickly discard and restore a system.

It is recommended that you keep a master copy of aos-Workstation, keep it updated, make regular "clean" snapshots but do not edit any settings or install additional software or use it directly for any activity. Instead make a clone or use snapshotting (but never mix up clean and unclean states!) for activities that requires anonymity.

Recommendation to use multiple aos-Workstations

For tasks where you want to use additional software you should use a second (or third) VM, you can make a clone. Consider this more of a pseudonymous than an anonymous environment and act accordingly.

Multiple aos-Workstation VM's isolate different torified clients from each other. For example, an exploit in the browser can not read your IRC identity in another VM. However, keep in mind, if Tor inside the aos-Gateway or your host internet connection goes offline, all aos-Workstations will go offline, and if you were simultaneously using something, an attacker could guess, that you are the same person (i.e. two Tor users in one IRC channel go offline at the same moment).

Leaving multiple aos-Workstations running at the same time introduces also new risks. One compromised aos-Workstation can perform various attacks. It's impossible to defeat all those attacks. Depending on the adversary's skills and assumptions and your activity in other aos-Workstations, he could correlate various running aos-Workstations to the same pseudonym.

  • An adversary could stress either/and CPU, HDD, RAM, network connection and other aos-Workstations and perhaps also the host would suffer.
  • There is no defense against DOSing other aos-Workstations or the aosGateway.
  • The adversary could try to exploit other aos-Workstations or the aos-Gateway. This risk can be reduced by hardening. aos-Workstation provides an optional (disabled by default, because it can get into the way for other tasks) firewall to isolate different aos-Workstations from each other.
  • A defense against impersonating (i.e. MITM or malicious gateway) other aos-Workstations or the aos-Gateway can be implemented using authentication, this is outlined below.

Using more than one aos-Workstation is very easy to achieve. The setup for the second or any additional aos-Workstation is the same as for the first aos-Workstation. Or simply clone a clean aos-Workstation. The minimal difference: It needs its own fixed IP address. 'nano /etc/network/interfaces' and change the last octet. E.g. or Reboot or restart network using '/etc/init.d/networking restart' afterwards, done.

NOTE: Connections between aos-Workstation and aos-Gateway are, by default, not authenticated/encrypted. A compromised aos-Workstation can impersonate the Gateway, perform MITM attacks or passively eavesdrop. To mitigate that you need to set up authenticated and encrypted connections. A workaround, when using VirtualBOX, without encryption, one can also enable Virtual Network Adapter 3 and 4 and use uniquely named internal networks, for up to 3 aos-Workstations, which are isolated against each other.

Adding encryption can be done using OpenVPN or SSH. Using SSH and not OpenVPN, has the advantage, that you an later, still easily tunnel a VPN through Tor. If you don't plan to do this, using OpenVPN is probable easier. The disadvantage of using SSH is, that it's complicated to setup for this use case. You must not allow ssh login.

Each aos-Workstation probable needs its own SSH account, with public key authentication and the SSH private key distributed to each T-W. aos-Gateway and all aos-Workstations need the correct SSH commands. aos-Gateway has to autostart SSH and to continuously listening for connections. And aos-Workstation has to autostart SSH as well and continuously reconnect (in case aos-Workstation started before aos-Gateway or aos-Gateway restarted) (perhaps using autossh or something similar). All aos-Workstations need to use the tunnel IP, to connect to the aos-Gateway. And the aos-Gateway should reject unencrypted gateway requests, and only accept forwarding to Tor over the SSH tunnel. And also answer only over the SSH tunnel. All aos-Workstations must use the SSH tunnel as gateway (redirect network level to socks using tranSOCKS_ev or similar). Perhaps also changes in the aos-Gateway firewall are required. Taking all the into account, it looks like, it's not impossible to use SSH for this task, but it's quite complicated.

You are probable better off using OpenVPN.


Right now only supports two modes/security domains:

  • aos-Workstations with the secret key (=trusted) and
  • other workstation with no key/vpn configured.


  • Transparent proxying doesn't seem to work at all, therefore you need to configure all applications to use socks ports (use uwt for apt-get).

On the gateway:

sudo -i
apt-get -y install openvpn

# create a new symmetric key
sudo -u user openvpn --genkey --secret /home/user/static.key

# copy key to workstation (Firewall needs to be disabled and openssh-server installed on aos-Workstation for this to work)
sudo -u user scp /home/user/static.key user@

mv /home/user/static.key /etc/openvpn/static.key
chown root:root /etc/openvpn/static.key
chmod 700 /etc/openvpn/static.key

# create server configuration
echo "
user nobody
group nogroup
dev tun
secret /etc/openvpn/static.key" > /etc/openvpn/server.conf

service openvpn restart

# Edit torrc
# TODO: only selectively change listening addresses. TransPort and optionally other SocksPorts have to remain available,
#       if unauthenticated workstations are to be used.
# NOTE: we are using a hardcoded default IP here, if you are using non standard settings this will have to be edited.
ed -s /etc/tor/torrc <<< $',s/\nw'

# Edit /etc/
# TODO: Put this automatically where it actually belongs
echo '
# Allow openvpn in on port 1194
iptables -A INPUT -i $INT_IF -p udp --dport 1194 -j ACCEPT' >> /etc/
# TODO: replace hardcoded "eth1" with a wildcard
ed -s /etc/<<< $',s/INT_TIF=eth1/INT_TIF=tun0/g\nw'


On the Workstation(s):

TODO: Disable/tweak the new firewall

sudo -i

mv /home/user/static.key /etc/openvpn/static.key
chown root:root /etc/openvpn/static.key
chmod 700 /etc/openvpn/static.key

# should be in the default installation
apt-get --yes install --no-install-recommends torsocks

echo "
user nobody
group nogroup
dev tun
secret /etc/openvpn/static.key" > /etc/openvpn/server.conf

# Edit resolv.conf
chattr -i /etc/resolv.conf
echo "nameserver" > /etc/resolv.conf
chattr +i /etc/resolv.conf

About VirtualBox

VirtualBox is developed by Oracle, a company not exactly know for being very "open". That includes how they announce security issues in their products as well as how they are perceived by the security community and how they will communicate with each other.

VirtualBox is primarily a simple, "user friendly", desktop solution and most certainly not designed with our threat model in mind. I haven't heard of anyone seriously auditing the code and I'd like to recommend a different VM solution at least as an alternative. There's KVM and Xen, open source but not cross-platform. It seems they are still lacking in terms of a reliable "internal networking" feature which aos heavily depends on. (If you know more, please edit this paragraph).

Anyone looking into aos solely because of security should really consider using Physical Isolation.

About Ubuntu

While Ubuntu is one of the more secure Linux distributions it's by no means a secure operating system. It is designed first and foremost to bring Linux to end users. It doesn't protect against some of the threat models that some Tor users will have.

Here's an (incomplete) list of things the more paranoid user will have to consider:

  • apt-get as currently used in Ubuntu does not protect against a "stale mirror attack" where an adversary provides validly signed but outdated metadata to prevent users from downloading and installing the latest critical security updates. When fetching updates over tor this problem is of a lesser extent because no single malicious exit node will realistically prevent users from downloading updates more than once in a row. Malicious mirror is possible but aos-Workstation uses the main US mirror, any irregularities will be uncovered pretty soon. More of concern is the clear text update of the host operating system. Here it's a good idea to manually check how old the repository metadata is yourself:
find /var/lib/apt/lists/* -type f | xargs cat | grep "Date: "

From time to time vulnerabilities that allow installation of untrusted code are discovered in apt. New security features are often implemented in Debian first.

  • aos can't protect against malicious code inserted into Ubuntu infrastructure. Ubuntu uses bzr/launchpad which ensures some chain of trust as it requires contributors to sign commits.
  • The Ubuntu server kernel comes with everything and the kitchen sink. At any given day the kernel will be vulnerable in one way or the other. It's by far the most patched piece of code in the default Ubuntu Server installation, obviously runs at full kernel privileges and naturally can't be protected with mandatory access control. aos-Gateway exposes the kernel to attacks through its firewall, TCP/IP stack and whatever kernel calls Tor does or could be compelled to do. --kernel reports good kernel protection: GCC stack protector support, Enforce read-only kernel data, Restrict /dev/mem and /dev/kmem access are all enabled!

  • Userland protection for Tor is great. Unlike TBB bundles the tor version distributed via the .deb comes with RELRO, canaries etc. and can fully make use of ASLR since it's compiled as PIE. Of course with Grsec the entropy would be higher.

About grsecurity

Linux kernel is not a secure OS, Linus himself made it pretty clear that he doesn't think highly of the "security community". His threat model and a Tor User threat model don't have much in common. Good that Linux is open source and if we disagree with a policy or politics we can just patch or fork it... Grsecurity/PaX is the most comprehensive kernel patch providing much needed security hardening both for the kernel itself and for making userland protections more effective.

Sadly no distribution of binary grsec kernel exists.* That means either a packager/maintainer of aos needs to compile them EVERY TIME there is a security update to the kernel (which is pretty frequently) or the aos users themselves need to compile and update their kernels. This is undesirable because kernel compilation is not set and forget, you need a bit of knowledge, it takes a while, especially in a resource restricted VM and you need to keep updated about new releases via mailing lists or similar because your software updater doesn't automatically handle custom kernels (even emerge in hardened gentoo doesn't). All this would most likely only result in users running old, outdated kernel versions.

Further for aos-Gateway and the Identity/Location TCB grsecurity only addresses a subset of security risks: It can mitigate *some* kernel vulnerabilities (and we only really care about the networking stack which is pretty secure judging from its track record). *Maybe* *some* (memory corruption) vulnerabilities in apt-get and Tor that aren't already mitigated by the existing userland hardening done by Ubuntu. It can't protect against backdoors or security issues related to design, policy or yet unknown classes of exploits. We feel that these relatively small advantages outweigh the issues introduced by using a custom compiled kernel. We hope a binary distro will step forward and start using grsecurity. In that case we'll most likely switch aos' aos-Gateway to that distro as soon as possible. (*There's Alpine Linux but they don't package Tor yet:

For aos-Workstation the benefits are even more doubtful. To be effective grsecurity needs to lock down some functions that are needed by Xorg, JIT compilers... but we need those to be working. To solve this we'd have to write a restrictive RBAC policy which is far from trivial. We think accepting that aos-Workstation will be exploitable and acting accordingly (using snapshots and rolling back to clean state) is the right approach for a desktop system.

If you disagree with this assessment or have any suggestions how to improve the current situation please let us know on aos/Dev!

UPDATE: We now have instructions on how to build a Hardened Gentoo based aos-Gateway.

Adding NAT adapter to aos-Workstation / Updates without Tor

Obviously the anonymity will get compromised if you add another NAT network adapter to the aos-Workstation. It is quite clear not to do that. If you were infected, it could leak then. Therefore it's recommend to do updates over Tor. It's slow and there are not leaks.

Adding Host-Only Networking adapter to aos-Workstation / SSH into aos-Workstation

One might wish to access the aos-Workstation through SSH. Therefore one could add a second network adapter with Host-Only Networking. Dangerous, don't add another network adapter! Also potentially dangerous if any other VMs are running besides aos-Workstation! The warning of VMware Host Only networking may also apply for us: "If you install the proper routing or proxy software on your host computer, you can establish a connection between the host virtual Ethernet adapter and a physical network adapter on the host computer. This allows you, for example, to connect the virtual machine to a Token Ring or other non-Ethernet network.

On a Windows 2000, Windows XP or Windows Server 2003 host computer, you can use host-only networking in combination with the Internet connection sharing feature in Windows to allow a virtual machine to use the host's dial-up networking adapter or other connection to the Internet. See your Windows documentation for details on configuring Internet connection sharing."

If you want to SSH or VNC your aos-Gateway, your safest bet could be to run those services using hidden services.

aos VPN disclaimer

You only have to read this chapter, when you are going to combine aos with a VPN.

aos is in no way affiliated with any VPN provider. The mentioned VPN provider have been chosen, we simply found them, it was easy to register, no personal information were required and because it was free. aos developers do not review or rate VPN providers, that is beyond the aos project. You are welcome to post instructions for other free VPN services, which will be threaded equally. In no way any provider is labeled as a good/bad choice.

Depending on what they were used for, they also fulfilled certain criteria, which are mentioned in the specific article. For example: TCP connection supported; not blocking UDP ports; OpenVPN supported, many other free providers offered only access through proprietary, closed source and/or windows-only clients.

Most websites recommend for choosing a good VPN:

  1. Do not use free VPNs, as they observe you, log everything and sell you.
  2. Leave no money trail, pay anonymously. (Bitcoin etc.)
  3. Research their reputation, background, history, location.
  4. Check their privacy policy and terms of service.
  5. They shouldn't ask for any identifying information. (name, postal address, e-mail etc.)
  6. The providers homepage is reachable over https with a valid SSL certificate.
  7. You can use GPG to mail them.

Use at your own risk.


That's just a code name for a *BOX setup "2.0" that may eventually offer strong guarantees of security and anonymity.

It should address all the current single points of failure:

  • CPU: Even in a microkernel + IOMMU system the CPU (and to some extend the GPU, this ) needs to be trusted blindly. The system needs to consists of multiple (diverse) CPUs. aos with Physical Isolation already does that. This is just an reminder that software based isolation (through next gen sandboxing and microkernel design) will never be able to replace hardware isolation.
  • Software/Compiler Even if the TCB is small and verifiable to some extent there is an inherently unsolvable problem: Compilers ("trusting trust"). The only option to improve this I see is to rely on a diverse "polyculture" of software stacks and infrastructure instead of our current Windows and gcc monocultures. (I suppose most .mil and all research microkernels are written on monolithic untrusted "legacy" systems). Alternatives do exist (most likely built with gcc...) but probably not mature enough, though I hear OpenBSD kernel can be built with pcc. clang/LLVM is probably the best bet. This also extends to the build system, workstations and gateways should be built on their respective target platforms, not a single build system.
  • Software updates: Currently, one single bad update from Ubuntu and it's game over. Software updates are always a root "backdoor", they grant unknown people full remote access to all your systems. This needs to be changed. If the TCB is small and well tested there won't be many security updates and they will be simple, small patches. Deterministic binary builds could make that userfriendly. At least we should not rely on a single organization to provide security updates for all systems in aos (this includes having the same upstream for complicated software, i.e. the Linux kernel...).
  • Tor: Currently, one serious Tor vulnerability and it's game over. Even with true end-to-end communications, if Tor (or its TCB) is subverted an adversary can find out who is talking and to whom one is talking. aos should route all traffic over at least two strong anonymity networks (not just single hop proxy/VPN/SSH). Further, there should be the option to use a high latency network. This could be as simple as a single hidden service (which would have to be fully trusted to not collude with our "global adversary". A real solution would of course have to be decentralized. The only options so far are remailers (Mixminion...) but those have few users (poor anonymity set) which is probably related to their outdated user interface and experience. However, even with a small number of users, if remailers are routed through Tor they are still more secure than Tor (in this context the resulting anonymity is cumulative).
  • "Protocol leaks", Anonymity set reduction: The current platform of choice (for pretty much everything, including anonymous communication) is the web browser. Browser really suck when it comes to privacy, anonymity or security. Allowing scripting, storing IDs (cookies and more), constantly changing features (html5, webgl, websockets...), lack of strong crypto environment make the web browser one of the worst platforms imaginable for strong anonymity (or security). Why? Because we also lack a credible alternative. One such alternative could have been the now dead or in limbo Syndie ("Syndie's design as an anonymity-sensitive client application carefully avoids the intricate data sensitivity problems that nearly every application not built with anonymity in mind does not.")

In summary: aos² needs to consist of at least two very diverse systems, different hardware manufacturers, different kernels, different companies/orgs providing support and offer at least two different anonymizing networks. Bonus points for utilizing diverse crypto systems and cascades. Neither system should "know" both who is communicating and with whom.

Build Anonymity

This does only apply if you are going to build aos from source and/or if you are going to redistribute aos. This is not a aos specific problem. Most projects do not even have a chapter about build anonymity. While building aos, software has to be downloaded. It's a unique selection of software and there is no way to make it not unique. Therefore your internet service provider (ISP) could guess, that you are building aos. This should not be of any concern in a free country (free by your own definition), if the content of your traffic is not being observed or logged.

Especially, but not exclusively, in case you want to redistribute aos, you might be interested to hide the fact, you are building aos (i.e. you want to stay anonymous). Therefore we are working on support to build aos over Tor.

To prevent any kind of personally identifiable or even fingerprintable information leaking from the build system into the aos images it is recommended to build inside of an already torified Virtual machine, this can be quickly set up with "aos-Gateway -onevm". You can build aos inside an existing aos-Workstation, but it can also be built on a headless server and while it is possible to run VirtualBox inside VirtualBox, the part requiring VirtualBox can most likely safely be run on your host, outside of the VM (creating the VM setting and converting the image otherwise doesn't touch the built systems). Using vboxmanage "aos-Workstation" modifyvm --acpi on and vboxmanage "aos-Workstation" modifyvm --ioapic on for all VM's, i.e. for the build_aos-Workstation and the ones you build, speeds up the VM inside the VM a lot.

It's also recommend to build in an already torified Virtual Machine, because that prevents leaks from the build system, which could help an attacker (with root access to the aos-Workstation), to gather identifiable information about that build system, that could ultimately lead back to your identity.

It's also possible to build directly on the host and torify all connections the scripts make, but we don't know what other leaks there may be possible (e.g. hostname, dhcp, resolv.conf...).

We know it's not the best solution to run a VM inside a VM. Virtual Box inside Virtual Box works, but if we change to another virtualization platform later, that may be no longer possible.

aos Thread Model not available as pdf or paper version

You may skip this optional chapter. Written by aos developer adrelanos.

While I read real papers, like the Onion routing design paper and many others, I can't be coerced into creating a paper "Designing an anonymous operating system" with latex as pdf.

Like Mike Perry, developer of Tor Browser said "I find the pdf format heavy and unnerving from a security perspective.". That also goes for me and I also find the pdf format inconvinient. It would also take me some time to learn latex, pdf creation, formatting etiquette and so on. Time, which I rather invest into improving the design, developing and so on. The "Onion routing design paper" is now also outdated and I rather have an editable, often updated and revised website compared to a paper/pdf.

Tails does also not have a design paper as pdf and still lots of users and developers. Also TrueCrypt had not design paper about plausible deniability and still got reviewed by Bruce Schneier et al.

Further hints and readings

There are a few threads on the Tor Talk Mailing List about the security of aos / transparent proxy. "[tor-talk] Operating system updates / software installation behind Tor Transparent Proxy"; "[tor-talk] Obtain real IP behind Tor transparent proxy; was: Operating system updates / software installation behind Tor Transparent Proxy"; "[tor-talk] Risk with transparent proxy mode [was Re:Operating system updates / software installation behind Tor Transparent Proxy]" - Everything fine so far.

This page, 'Application Warnings And Notes' explains a lot security related things you should be aware of. Also see the whole page Security And Hardening for tips how to improve the security. aos-Workstation is firewalled also explains #OptionalFeatureNr.3# (Even more restrictive firewall rules.).

Application specific warnings and hardening instructions


Trusting aos


aos with Physical Isolation

Using hardware instant of virtual machines. More secure. See Physical Isolation.

anonymous 3G modem

Improves anonymity. See anonymous 3G modem.

anonymous wifi adapter

Improves anonymity. See anonymous wifi adapter.

Leak Testing

In your own interest, you should do the additional aos/LeakTests, to check everything is properly set up.

Other projects similar pages