Schneier on Security

Nick P • September 17, 2014 6:46 PM

@ thomasblair

They probably did all that after the fact for a court-worthy case. A jury would simultaneously be overwhelmed with the information and see lots of dots connecting. It’s a good case. The problem is they had to start somewhere and they’re known to hide that part.

@ st37

Those documents give the missing piece of the puzzle. Specifically, the vulnerability assessment and thomasblair’s stackoverflow references show the guy had no skill in secure, web development. This is a common problem. Web apps keep getting hit by the same problems, even with free frameworks & libraries to mitigate them. He was probably just throwing stuff together, relying on Tor for security instead of just anonymity. They did some fuzz testing, owned the box, and then the box outed itself.

From there, it was just connecting dots. The FBI has way more experience with that part and appears to have done a good, thorough job.

Nick P • September 18, 2014 8:53 PM

@ Thoth

How to secure services like Tor against FBI/NSA

The topic of Tor security is special: the opponents are typically TLA’s. Silk Road was taken down by a very capable TLA with hackers, 0-days, and legally-empowered investigators. They are partnered with the most powerful TLA (NSA) in the world of SIGINT collection, with ability to ask for their help & parallel construct that away. They also have legal partnerships with others around the world. So, this is a situation where even remote attacks demand a high assurance solution. If it’s medium, it needs to focus assurance activities on everything we know they hit. And you better be covered legally, but I’ll focus on technical side for now.

The best way to start on requirements is look at it logically. Without knowing much about Tor’s insides, I’m guessing the logical system involves these components: hardware, main firmware, peripheral firmware, OS kernel, networking stack, storage, network time, Tor protocol activities, networked apps people connect to/with, configuration management tools, and administrative tools. A number of these are security-critical, being in the TCB and designated “trusted.” The TCB of the Tor engine must be initialized into a trusted state at boot, protected from attacks during running, and be sanitized upon shutdown.

So, what are the threat vectors? Most of the stuff I just mentioned… The FBI definitely can find 0-days in OS kernel, drivers, main firmware, or apps. The skill is the same for each of these, so if we haven’t seen it they just haven’t displayed it yet. The NSA adds attacks on peripheral firmware, protocols, covert channels, side channels, and hardware subversion (esp by interdiction). To stop FBI, one must ensure they can’t hit any layer from I/O up to protocol engine. To stop NSA, one must protect even more. This is… challenging*. 😉

• “Challenging” is synonmous with “You’re f***ed” in this usage.

The simplest strategy for both is physical decomposition. Like my PCI backplane and Artigo designs years ago, the logical “system” is actually a bunch of different computers communicating over various links. You can break the system into untrusted and trusted systems communicating over non-DMA links. Can’t trust U.S. companies’ IOMMU’s because we can’t trust U.S. companies. (Simple, eh?) The hardware is ideally pre-2004 that wasn’t shipped or was couriered by someone who is incredibly trustworthy (yourself even). It must never get into enemy hands. Ever. For those inclined, one can make a custom SOC or board that basically acts as both a switch with IO/MMU and guard for traffic mgmt rules. Will be faster, almost plug n play, simpler, require less hardware, and cost a lot of money to develop. Tradeoffs, tradeoffs… 😉

The simplest decomposition has three nodes: internal transport, tor node, external transport. The transport gateways apply basic security filtering while also converting the packets to easily parsed format sent over non-DMA lines. As such communications are handled by CPU directly, it’s advisable to make a scheduling policy whereby I/O is only done so often. That keeps number of interrupts and cache misses to a minimum. A deprivilged subject does the I/O where possible, moving it to/from a specific and protected storage area. One or more separate subjects with their own protected, internal memory does the security-critical operations.

At this point, we have to secure the main points of attack. Let’s start simple. The middle system is only running a pre-configured Tor server modified to use our safer I/O interfaces rather than networking. It also needs a process or processes to handle that I/O. The configuration, executables, etc are all created on another machine and simply moved to this one. There’s no remote administration in this model: it’s done locally via the hard disk itself or a dedicated port with authentication. This system just runs Tor and only needs the kernel functions that it depends on.

The easiest setup starts with a monolithic OS. You can use OpenBSD or a Linux with extra protections. Configure the Tor service with maximum isolation using any technique you have. Make sure the firewall filters out anything that isn’t Tor (optionally doing other checks). Like in Poly2 project, remove every piece of code in the system that’s not critical to its functioning. Don’t just disable it: go into it, delete the code in the functions, and tell it to return success (or failure). This is easier than outright deleting modules because it requires less work and understanding of the system. For stuff the system does use, ensure security checks are in there & optionally use the special compilers that automatically add safety. Use things like SVA-OS or system call mediation to give kernel a bit of extra protection.

Your attack surface is already very low. The I/O is simple enough to write nearly bug-free implementations. They will be forced to focus on the application and few kernel calls it uses. The application logic should be made in a functional way with an internal state of the entire thing, incoming data causing a change in state, and optionally causing a response. Each state should be analyzed for the effect of common errors and attacks. Error states should recover or fail safely with logging. The system should be written in a safe language or safe subset of a language with input validation, static analysis, dynamic analysis, extensive testing of every state/feature, and fuzz testing running overnight regularly on instrumented code. Techniques such as control flow integrity or safety-critical memory management can be used to reduce likelihood of attacks. The compiler and linker must be verified to not screw anything up, like optimizing away security checks.

That’s one application on a hardened platform. The next step is breaking it into pieces that each do a job and communicate. A microkernel platform open to inspection should be used such as OC.L4, OKL4, Genode, seL4, Minix3, etc. Each logical component, inside or outside of Tor, is put into its own address space. The system is modified using distributed programming techniques to safely coordinate the overall system activity over message passing. Each TCB component is then designed, coded, and tested just as described above. The interaction of components can be modelled in a specification or programming language with concurrency checkers to find such errors, although there are distributed transactional approachs if I recall.

At this point, each part of the TCB is quite hardened. If cash flow continued, higher assurance techniques can be applied. Among the most important would be a covert channel analysis of the system. There’s tools to model and track information flows to make it easier. The next step would be an inherently safer architecture*. Typed (Sandia SSP), tagged (crash-safe.org), or capability (Cambridge CHERI) processors can be employed to contain or prevent code injection attacks. Dedicated I/O processing chips with DMA to Tor memory might be added for performance, extra security, or avoid using the same TCB setup for app logic & I/O. Formal verification might be used on any aspect of the system. Tools might be expanded for automatically adding security protections to safer source code, then certifying compilation & linking at object code level.

• The architecture might actually be one of the first things you do. When I did stuff, there were none around. Now, there’s over a dozen in various stages of maturity, licensing, and ASIC cost. It could be the very first thing the project does.

People might want remote administration. One of my old approaches applies here: use a production system and a management system. There’s a safe link between the two. The production system can be ROM’d to do self-checks, then automatically boot from management system’s storage. Combined with a object store or RAM disk, this design choice means Tor node doesn’t even need a filesystem layer. :O All the tools needed for diagnosing, generating, or otherwise managing the Tor node are on the management computer. Like with Tor, a dedicated application (eg SSH) runs on the Tor node that basically acts as a middleman between external network & management node, shuffling the data. The service is off & I/O blocked by default. A guard application listening on a certain port checks incoming data for an authenticated command to activate administration. It then leverages trusted code for initiating a session… from the Tor node to a designated external node. One can use SSH or just PGP-style encrypted commands sent back and forth asynchronously. I did the latter with pre-shared master secret for simplicity, speed, and immunity to quantum advances.

Finally, for your personal satisfaction, you put all this stuff in an EMSEC safe with obfuscated tamper circuits that can activate thermite. The circuits should detect RF attacks, extreme heat/cold, radiation spikes, and strong vibration. A HEPA filter on incoming air can prevent troubles nobody has published yet. (Don’t ask.) The circuits should send data to radiation-hardened microcontrollers that have battery backup. Need at least three in lockstep with voting protocols. Redundancy and diversity in detection circuits helps. All this stuff costs so much already (esp EMSEC) that you might as well spend a bit more to prevent your tamper circuitry from nuking it accidentally. Let them run in the production environment under your supervision in a learning mode to adjust to the common operating ranges of the environment. Then, they are put into production mode and can’t be disabled without a secure, secret method. You need to personally courier it to destination and set it up. See how costs can add up for tamper resistant remote solutions?

Of course, they are a coalition with legal authority and covert ops. You cannot control the box if you’re in a Five Eyes country and there’s risk in a foreign one. Whoever is managing it can’t be a citizen of one of these countries as they can be extradited. Their citizenship, location and travels must keep them away from those countries complicit in Five Eye’s covert activity. You also need crime to be low with a decent standard of living to make bribes cost more. Switzerland has best track record in most of these traits, with Iceland having some strong attributes. In short, if Five Eyes courts or spooks can target you easily, then you are screwed no matter what tech you use.

So, there you people have it: a combo of NSA-resistant INFOSEC 101 & Tor Secure Development Guide. This should be a start. (Hears someone in the audience say, “A… start…?”) Yeah, a start. I don’t list all potential attacks. The opponents are highly likely to fail, though, using most methods they will try. They might even give themselves away while telling you exactly where the flaws are if you’re logging crash data. Now start building! 🙂

Note: My earliest post on this stuff was on Freenet here. It begins an argument for high assurance techniques with covert channel mitigation, along with base deign.

Nick P • September 19, 2014 11:31 AM

@ anon

I addressed web application security innovation here. Use it, build on it, tell your programmer friends. It’s not really the concepts or technology that’s lacking: people just keep building on insecure foundations instead of improving on what’s already proven to work. Same problem throughout IT industry.