Schneier on Security

Nick P • July 31, 2014 4:33 PM

It’s an unsurprising vulnerability. Any device which has DMA or sends data to trusted processes is part of the TCB. One must either show it’s trustworthy or mediate it. My general rule is to consider every device untrustworthy. This is supported by the large amount of undocumented functionality, increasing use of programmable chips guiding the DMA, and recent discovery of a backdoor in a security-critical FPGA. The chips must be assumed to have functionality useful to the attacker.

So, what to do? Well, you essentially have to mediate. This might be an IOMMU integrated in SOC or inlined in PCI bus. There’s memory crypto schemes. There’s also my old strategy of offloading each I/O device onto a separate chip which has a safe interface to the main chip. That preserves COTS hardware compatibility, while allowing you to choose what chips to put trust in for mediation.

There’s also the economic model to consider. In a previous thread here on USB issues, I pointed out that users are largely to blame as the incentives they give manufacturers work against quality or security. Most that use high assurance methods won’t sell crap. Medium assurance barely sells. So, most stuff is low assurance. The profit motive of the private corporations might also increase the likelihood of them putting in backdoors for profit, as we saw with RSA (and ad-driven services in general).

An economic solution is to have several standards: low, medium, and high. This is essentially what CIA did in its ratings system. High should be considered secure. Low and medium should be considered insecure, yet medium puts substantial effort to reduce risk or make recovery easier. Reference implementations of useful functions (eg link encryptor) sponsored by public and/or private funding will give potential developers a head start on their products and an idea of the costs of each level of assurance. The reference implementation will itself be usable, with hardware sold just over cost. Private parties will differentiate with features they integrate into such models. An independent body (with plenty accountability) will certify each design against its goals and assurance level similar to Common Criteria’s Protection Profiles, but with a more practical than paperwork focus. Each company or individual can then look at a list of products, choose what assurance they want, and then get what they pay for. Lastly, the whole system’s rating is the rating of the lowest security component in the system in accordance with “weakest link” principle, although advanced users can look at ratings of each component.

Nick P • July 31, 2014 11:15 PM

@ old fart & Buck

An update on a USB flash drive is unlikely. However, I suspect that it’s not actually the cause. I mentioned another driver in my post: reuse. Let’s say you develop all kinds of peripheral devices. You need a USB controller in most of them. The main difference in them will be the software on the controller and/or its performance. So, you now have two choices: design a bunch of separate USB chips (or ROM’s) with separate production; design one programmable USB chip with a production step selecting what firmware to put on it. One makes a hell of a lot of sense to a company focused on the bottom line. Now, repeat this process for many chip designs with maximizing reuse being a key goal and you get the modern IC marketplace.

Note: They might also be using a SoC they use in other embedded products which just happens to be field-upgradeable. They might keep their embedded RTOS, timing analysis, etc the same across product lines.

Another good example is hard disks. There’s many models available with different amounts of storage. Consumers assume that higher end models have more of some physical thing that results in a higher price. Actually, they figured out that it’s cheaper to design just one hard disk, then do something in the firmware that changes how much space is available. This saves them plenty of money. They also might need to support firewire, USB, eSATA, and so on. The next step that might benefit would be putting them all on the controller or buying an existing chip on the market that supports them. Then, just like configuring size, you tell the firmware what to enable. And now your new product just needs a different connector soldered onto it.

@ Chris Abbott

I have no idea. Any change could cause BC problems. Like I said above, I think it was functionality that was reused either due to being a COTS chip they bought or them using that functionality in another device.

@ Old Fart

Re Universal

It’s a good observation as it would seem to be the root problem. It’s not, though. There are existing methods to handle general I/O with quite a bit of security. I even posted a few new one’s on this blog. The thing is that the I/O mechanism must be designed for secure operation, which mainstream I/O typically isn’t. Combining insecure I/O architectures, insecure devices, and universal attribute predictably leads to insecurity.

@ Gweihir

I’m mostly in agreement that there’s only so much one can do on microcontollers. Yet, early computer virii were written in the hundreds of instructions range and an injection over DMA for a specific OS might not take up much space. Removing the password, changing existing code to admin/kernel/hypervisor mode, or leaking a key in memory would take even fewer instructions than a rootkit. So, size matters but I’ve seen too much black hat innovation to build assurance on such an attribute.

@ egeltje

The Qubes founder’s blog has a nice writeup on USB security issues:

http://theinvisiblethings.blogspot.com/2011/06/usb-security-challenges.html

I doubt Qubes has gotten to the point of truly isolating damage USB can do. They do use an IOMMU to restrict the device’s DMA and allow you to assign a device to a VM. Those two alone are quite beneficial. Yet, anything you send to or receive from the device still poses a risk as with any isolation method. And as we’re talking storage devices that’s a significant risk.

@ Thoth

Like a general purpose device, a secure microcontroller requires mechanisms to ensure loading of authorized code, protection of internal memory, control flow integrity, and prevent data becoming code. That it might loose power at any moment presents additional issues shared by smart cards. That the software is controlled by the manufacturer, special purpose, and rarely changes means it’s actually easier to secure this kind of device. That the device must be as cheap as possible to ensure profitability pushes against security. So, the solution must use little power, be very cheap, be adaptable to other stuff they do (reuse), meet all performance requirements, and be secure.

The best solution I see is starting with something like Sandia Secure Processor design, then adding trusted boot/upgrade and optionally an I/O coprocessor. The result would be cheap, performing, easy to modify, and unlikely to be hit with code injection. A transactional, versioning approach to persistent storage might also help with failing safe on power failure. Stateless design is the alternative (and default) for that kind of thing.

Nick P • August 1, 2014 1:11 PM

@ Jeremy L

“Signing the firmware doesn’t make it secure.”

As I said, it’s one of a few components necessary in a secure device. The property is that only authorized code can run. Firmware signing is one of many technologies that might be used for this. It has the advantage of allowing firmware to change. If hardware never treats code as data and has firmware signing, it’s not going to run malicious code via a mere software attack. An extra property or two adds protection against attacks by CPU or other hardware.

Changing the protocol itself doesn’t seem to be an option at this point, although the protocol handler can be modified for increased security.

Nick P • August 2, 2014 4:57 PM

@ M.V.

Oops my bad. There’s still the problem that one must trust the implementation of the USB functionality. Experience with write protect shows that what they say it does and what it actually does can be very different.

So back to my mantra of dont trust the device in the design unless it proves it’s trustworthy.

Nick P • August 2, 2014 10:43 PM

@ Thoth

There isn’t a provably secure way to transfer files via software on an architecturally insecure machine. However, there are methods that reduce risk. The classic option is using a guard. They’re used, for example, on moving data between physically isolated networks of different classification levels. The guard just needs I/O to computers, maybe do crypto, run checks on the data, scrub potential covert storage channels, and is special-purpose enough to be built to high assurance standards. There’s been mail, network, and even web application guards with first two done to high assurance by some products. One can remove the DMA risk by using a high-speed PIO device that has no DMA. I once hacked a solution with IDE cables in PIO mode. Or one can leverage a microcontroller, FPGA, etc to build a custom I/O chip on the guard and each endpoint. You can ensure it has DMA, but what’s controlling it is secure. Or has an IOMMU.

The simplest guard is an embedded board with PIO, connections to the computers, and running a microkernel OS with carefully written drivers. OpenBSD on a more powerful embedded board or even old school server with certain Open Firmware changes can do as well. Worst case scenario, a regular computer with open BIOS and Linux with assurance enhancing extensions (eg SVA-OS, SMACK). Remove any piece of code from the system you don’t need. If it has to be there to compile, just change the code to return successfully instead of doing something. 😉 Just make sure that the application level of it uses no dynamic memory allocation, gets size/hash before hand, consistently checks timing to know if device is stalling on transfer, and does bounds checks on arrays/buffers.

Now, if we’re talking just normal computers, you have to decide what you’re use case is. Are we talking computers that were connected in some way to the Internet? If they were, then assume they might get hit with malware at some point. We’re mostly back to “no way to say they’re secure.” However, there’s still some risk reduction here. One is to apply an integrity check to what you’re sending, then send it via a reliable UDP-based protocol (eg UDT) while blocking TCP in the kernel. IP and UDP implementations rarely have flaws compared to TCP and similarly complex protocols. Plus, the UDP-based protocols tend to execute at application layer, meaning they’re in user-mode and you can write the code in a safe way yourself.

Last idea is one I came up with and posted here relatively recently [I think]. The method is to create a computer that’s essentially an external device you plug into a normal PC that can access its memory. There’s various PCI and USB embedded boards that might be used for this. The system runs simple, hardened, security focused software that basically moves files. It might have IOMMU-backed DMA or PIO. Like with the guard, it can be told to receive a file while doing it carefully with custom, highly-assured code. It will deliver that file on another machine similarly. This is more like a user’s normal experience with moving files than a typical guard. It might also be fairly cheap for the hardware and perform decent. The slower PIO’s I did a while back were faster than 10Mbps Ethernet by almost double. So, it’s not Gigabit but you’ll live.

Note: And if it’s an air gapped machine, assuming you’ve done that correctly, you can move files from it using write once CD’s or DVD’s. Moving files to it you’re trusting quite a bit of code you might not even know exists. Hence me bringing up things such as guards and secure pluggable transfer devices. If they sound complex, you’d be overwhelmed seeing what people do to securely receive input that might affect anything from microcode to application. Guards are child’s play in comparison to that job. 😉

Nick P • August 4, 2014 5:20 PM

@ Thoth

“What I meant was transferring data between host computers knowing that no surprises would be injected into the data I attempt to transfer, modify data or give some nasty bite.

Imagine you want to transfer your emails from your internet PC to your air gap via downloading the email text data, compress them and transfer them to another PC by whatever means and ensuring the means you use doesn’t betray you in anyway possible.”

Thanks for clarifying. Scott’s many posts’ main recommendation is to compress and GPG the data. It’s a good idea, but far from adequate. We must always remember that attackers will exploit any link in the chain. You are trying to send data from a possibly malicious machine to a trusted machine. If it’s truly one way, then your requirement is one of the easier problems to solve. Here’s your problems:

1. The data itself might be leaked or modified.
2. The medium used to move the data might be attacked, such as protocol or firmware.
3. The data might contain a malicious payload that executes on your trusted machine. And this might be inserted in a way where you don’t realise it, nullifying the advantage of crypto. This has been done by black hats with PDF’s, Word files, music, movies, and so on. Easier with binary.
4. If the airgapped machine is taken over, it’s communications methods might be re-activated to stealthily leak data. That was in NSA TAO catalog.

So, this is the problem in a nutshell. As it always has been, obscuring and tamperproofing the data itself is the easy part. And it’s rarely what they attack. Hackers will instead hit protocols, OS, viewer apps, firmware, and so on. So, the solution must be a total solution which also involves security features for your air gap machine.

CD/DVD Solution

I’m going to build on this first. The hosting computer shouldn’t have any wireless communications at all. Anything non-essential should be disabled in the BIOS, the BIOS locked, and ideally a flash protection feature (eg jumper based) built-in. Auto-run should be disabled if the system has it. The media itself should be write-once and finalized. The main drawbacks are that it costs a disc each time, it doesn’t allow useful two-way communication (eg update service), it’s very slow (CD/DVD writes), and it’s quite manual. The crypto is unnecessary with this design except to keep you from having to destroy the discs. Of course, it provides the advantage where you can have a dedicated password for these transfers that’s saved on each machine.

Note: The untrusted computer sending the files is assumed compromised. The crypto still blocks random third parties with the disc from getting the data. Dumpster diving is main threat vector here.

Network Solution (Low Assurance)

I mention this solution because you wanted a turnkey solution. There are commercial solutions specifically design to do this. They’re called “cross-domain solutions.” They usually run on guards. They can be quite easy to use and sometimes support (modified) protocols such as FTP or Windows Update. The commercial one’s are quite pricey.

The basic, cheap solution is to build your own. Fortunately, there are already plenty firewall distro’s specifically designed to do this. Take a firewall distro, put it on a cheap board, configure it for one-way networking over UDP, and then you just need an app that will send the packets. A more carefully written policy might allow TCP acknowledgements, but still be one way. The NRL Network Pump works this way albeit with an extra technique to prevent the ACK’s from being used as a timing channel. So, this is a basic solution that’s mostly point and click. I’m also sure even the policies and commands to execute to do what I describe (for UDP) are already online somewhere.

Firewall is easiest option due to use of existing software and potential automations with scripts. The next easiest (and more secure) option is a data diode. Again, there are commercial options of varying price and features. The good news is there are DIY data diodes for ethernet and fiber online. They essentially modify the cable to only send data one direction, then ensure the apps use them that way. The code receiving the data, the firmware of the medium, the apps executing it, and the layers below are still vulnerable, though.

Many also use serial cables to avoid DMA risk. Certain modifications must be made but the drivers are so simple to modify. I used an IDE because it had working drivers in about every OS, is cheap, can operate in non-DMA mode, and is over 100 times faster than serial. My recent work is basically a dedicated chip (or PCI board) containing and running only what I determine to be trustworthy.

Network or Diode Solution (Medium Assurance)

So, how do we eliminate (or reduce) those risks while avoiding all kinds of complexity in design, installation, etc. The absolute simplest strategy is to put OpenBSD on a simple embedded board. Connect both computers to it with serial ports. Configure OpenBSD’s firewall correctly. On trusted system, use OpenBSD, Linux with SELinux/SMACK, FreeBSD with Capsicum, or Solaris with Trusted Extensions. The point is you want an OS on the trusted machine that’s open, has resonable protections, has been source audited for years, fixes problems, has simple app isolation method, and has online guides for about everything.

The effective TCB of the transfer is OpenBSD’s networking code, serial driver, and parts of kernel they use. This is highest quality and most secure code in all of UNIX so that’s a good confidence rating. Serial port gives you no DMA and simplicity of driver, reducing risk. With more effort, you can carefully write apps that move the files through the serial port directly, bypassing network stack. The applications on trusted PC that use the data should be restricted with MAC policies, dedicated user accounts or sandboxes at the least. That reduces risks of attacks via the data itself.

Note: The Cambrige CHERI capability processor is designed for security and legacy compatibility. They’ve already put FreeBSD on the prototype. There are FreeBSD firewall distro’s. I plan to combine them with open Ethernet (and DMA) I.P. later on for a turn key solution that just needs a cheap FPGA board with networking. Clive just supplied links to boards so that knocks out one obstacle. 🙂

Network or Diode Solution (High Assurance)

Obviously tradeoffs here are too much for most users so I’ll leave this off. If they have money, there are numerous vendors (ex Fox, Nexor, Tenix) offering data diodes with supporting software. These were rigorously analyzed and pentested in order to achieve their EAL7 certifications. So, that covers the transfer part at least and is turnkey.

Conclusion

There are your options. One must consider the risks. Hopefully, a BSD/Linux with app isolation, a serial cable, and some Googling will do for you. Otherwise, there’s the firewall distro’s, diodes, sandboxes, and so on. You can choose the security and convenience tradeoff you want with the information I’ve given you. Just remember that each link in the chain must be secured. Primarily, the app/kernel on trusted machine receiving data, the data transmission medium, and extra requirement of ensuring no other mediums on trusted machine can be enabled.

Readers following along wanting to know where all the risks are can get a thorough treatment here. That’s the framework I’ve used for years in high assurance security work, which you can freely distribute so long as you give credit. It also discusses secure code vs secure systems as it was original topic in that thread.

Nick P • August 4, 2014 10:21 PM

@ Figureitout

“One of your better posts in a long, long time. Very practical, and w/in your expertise/comfort zone.”

Why thank you.

re OpenBSD firewall

It has proven value in stopping attacks at the network level. It’s used by numerous governments and even in guard solutions pentested/approved by German government for their use. Their professional firewall hackers couldn’t bypass those without a 0-day. So, now you’ve limited the attackers wanting total control to those smart enough to develop a firmware attack or find a 0-day in the world’s most security-audited code. I also made a provision for making the firmware part tiny and app deprivileged. So, it’s quite a noose around the attackers neck.

Personally, I think top TLA’s probably can find a 0-day due to huge budget for that. Still stops tons of attackers, including lesser TLA’s, in practice. And recall he wanted a solution you can throw together, not the extra work (eg OPSEC/obfuscation) needed to slow/stop major TLA’s. So, a well-configured OpenBSD on embedded hardware with serial ports is one of the better options for quick and dirty mediation.

If I had a guess about the future, I’d say the next easy design for all these issues will leverage OpenFlow. You can easily build almost anything networking with all kinds of policies in that. Still too young to recommend for security purposes, though.

Nick P • August 5, 2014 8:55 AM

@ Q

The link you gave is a bunch of unrelated stuff thrown together. The few that are EAL7 are for the Fox Data Diode. A data diode lets data flow in one direction. The Fox Data Diode does this for optical Ethernet. It doesn’t support two-way computation or USB devices, so it’s not relevant in a discussion of USB. There’s no USB security product evaluated to EAL7 that I’m aware of.

Nick P • August 5, 2014 12:05 PM

@ Q

You’re own linked paper proves my point: it pushes a data diode over Ethernet as an alternative to USB sticks for just one way sharing. Most use cases need two way commmunication. USB is a two-way protocol that’s not EAL7 evaluated either.

So, my point stands that a security proof for unidirectional Ethernet has nothing to do with securing USB device operation. Nor can one even compare them as it’s apples vs oranges.

Nick P • August 6, 2014 11:22 AM

@ Q

Common Criteria 101: What does Owl’s evaluation actually say?

They haven’t delivered a proof that the device is secure: they delivered a security target and an assurance argument that product meets it. The security target lists specific features and considerations. Anything outside that, like whether the chips they use have insecure extra functionality, might be used against it. Likewise, the EAL7 requirement requires an abstract (high-level) design, a formal security policy, a mathematical proof the abstract design holds the security policy, a simplified implementation, and an informal correspondence argument that implementation matches abstract design.

The implementation itself isn’t mathematically verified for security. Not the hardware, the firmware, the software, the covert channel analysis effect on implementation, the testing/proving tools themselves, the compilers/assemblers/linkers, the integration, and so on. Vulnerabilities were found in other products in each of these things. NSA, GHCQ, Russia, and China attack all of these things. The good news is that pro’s typically review and pentest an EAL5+ product so it gets good code reviews. Yet, pro’s also review and pentest things like SSL yet it’s had plenty of design and implementation flaws.

Due to issues like this, the industry puts the burden of proof on the company claiming security. The company must, in each aspect/component, provide arguments that certain invariants always hold despite malicious input, failure modes, etc. It’s not easy. EAL7 combined with the right security target does a ton of good. Matter of fact, data diodes are so simple (and almost uselessly so) that I’m reasonably sure Fox diode is probably secure for that one property: for software attacks and strictly one way configurations the device can ensure traffic is one-way. And that’s all it can do: the traffic can still try to do things on the other end, like enable built-in wireless functionality of receiving devices.

So long as you use it one way, it’s implementation has no problems, it has no backdoors (see BULLRUN), the enemies never have physical access, the administrator makes no mistakes, and so on. All these are assumptions their security relies on, many listed in their own Security Target. Change one, the evaluation result no longer applies per both common sense and Common Criteria. So, let’s look at Fox’s CC documents.

http://www.commoncriteriaportal.org/search/?cx=016233930414485990345%3Af_zj6spfpx4&cof=FORID%3A11&ie=UTF-8&q=Owl+dual+diode&sa=Search

Owl’s certification history indicated they wisely started with EAL2 for data diode because it’s cheap, proves almost nothing (i.e. quick), and allows revenue to flow. This let them sell it to pay for more development and a better evaluation, EAL4+. Most of Owl’s products, including “Dual-Diode” line that references USB, is evaluated to EAL4+. Just like Windows 2000 and Linux… Security engineer & OS developer Jonathan Shapiro summed up nicely what an EAL4+ evaluation means for security. One earlier, more primitive, data diode did get certified to EAL7 in its original configuration and design. The hardware, drivers, etc have been un-evaluated in all of them (per their evaluation reports) with the designers claiming they can’t impact security. (evil grin)

So, they started with a very simple product. They kept evaluating it repeatedly to design new products. The basic diode got evaluated to EAL7 at one point. They kept changing and upgrading it in different ways, getting each evaluated at “strength of function – medium” assurance. And they ignore key aspects of their own product (which NSA attacks per TAO) in all evaluations. So, Common Criteria says the overall security of a product is whats in its security target combined with its evaluation assurance level. All but one of the security targets are certified to low-medium assurance with some extra evaluation components. All security targets, including the rigorous EAL7, leave out stuff attackers can hit to simplify their evaluation.

Conclusion: Based on Common Criteria documents, Fox has rigorously designed at least one product to do its job excellently and the rest are merely tested while reusing the abstract design/policy. Of course, people don’t hack abstractions: they hack hardware, firmware, and software. So, the current Fox products that claim to protect USB (somehow…) can’t be considered secure unless those exact products undergo an EAL7+ evaluation against a security target representing what hackers are actually going to attack. And the hardware/firmware/drivers needs to be in that as the system’s TCB might depend on it regardless of what promises they made to evaluators.

Note: As I write this, it’s important that you should know I’ve actually worked on EAL6+ designs, broken an EAL7-equiv due to “out of scope,” and done years of pen testing. There’s almost no products, despite certifications, that have proven secure over time. A few came close due to hardware up verification and tough usability tradeoffs. The common link is that every component needs to be documented/verified, their interactions must be verified, failure modes must be verified, security method must be verified, and everything that’s TCB must be shown secure in all states. It’s so hard to do this that only a few commercial products have tried and the EAL4+ evaluations show even Owl doesn’t do it anymore.