Booby Trapping Boxes: Running Private Services as a High Value Target
CC Attribution 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Levison, Ladar
hon1nbo
Ever worry about the hardware you leave behind? In a world where servers are co-located, and notebooks get left in hotel rooms, the ability to resist tampering, and if necessary actively respond to attack, has become increasingly important. And of course everybody knows the best booby traps are the ones you don't know are there. This talk will prepare you for life in 1984, where the maids are evil, and step brothers can't be trusted. Whether your running servers as a high value target, or simply want to protect your Monero private key, this talk will show you to achieve FIPS 140-2 level 4 security, without the FIPS 140-2 level 4 price tag. Specifically, we'll cover acquisition considerations, physical hardening, firmware mitigation, tamper detection and more.
 All right, good morning. I say good morning because I know by this point in DEF CON, we're better off using the same time zone as Tokyo, which makes this about 7 AM. So thank you for getting out of bed. The good news is we have an interesting topic ahead. We'll get to spend the next hour talking about boobies. Or more specifically, strategies designed to protect an execution environment for manipulation with a specific eye towards ensuring cryptographic keys can't be exfiltrated via physical access. Try three times fast. Oh, man. There we go. Yeah, I tried to change the slide over here, and Google was asking me for a question. Your presenters today are myself, Ladar Levison, and I'm Hanimbo. Hanimbo Tales, what we're going to be talking about are essential skills for life in the world of 1984, where the maids can't be trusted and your big brother is out to get you. For my part, I'm the operator of LavaBit and encrypted email service. I'm a technological warlock, a corporate kingpin, and some would say a team linchpin. My assistant, Hanimbo, is the proprietor of hacking and coffee, and he enjoys robbing banks under the cover of darkness. Assistant, come on, man. I'm your web host at this point. I'm a little more than that. Let's talk about security. As an industry, I think we've come a long way. Speaking for myself, it's been a few years since I've seen anybody try to log into their box via Telnet. One of the key factors pushing that security is encryption and its proliferation. Encryption is important because it provides a mathematical guarantee that the data can't be accessed without the corresponding key. Of course, the problem is that as we've evolved, so have the attacks. Unfortunately, as good as we are at architecting and building secure systems, we still need a reliable and friendly environment to run our bug-free, ultra-secure code. With encryption specifically, we've seen a new breed of attacks where all the security measures we put in place get simply via physical access. Now, there's a picture of an altair because that was probably the last computer you could look at and kind of understand how it worked on the inside. Before we go any further, we should talk about our assumptions. For our purposes, we're focused on targeted physical attacks, which means we're making the assumption there is no universal backdoor in x86 hardware. As always, when it comes to assumptions, your mileage may vary. Unfortunately, we don't have time to cover it today, but it makes sense that if your threat model requires you to install booby traps in your hardware, you probably want to do to your IME as well. For those of you who spent some time in this building, what we're talking about will look familiar. Essentially, we're talking about taking commodity hardware and modifying it to afford you some of the security guarantees provided by FIPS Level 4. So we can run our common criteria EAL 4 plus software in a secure environment. Unlike the actual FIPS Level 4, our recommendations don't come with certificates from the government though. If you aren't familiar with those standards, don't fret. It only means you haven't spent much time working for the man. For those folks, I'll summarize by saying FIPS Level 4 is what the State Department would use for a classified information terminal. They have located in the basement of the American Embassy in Taylor. Some place interesting like that, if a machine can stay secure in an environment like that, is that the same computer would be worthy of being placed in a co-located facility and be safe from legal, extra legal, and illegal access, probably. There are plenty of commercial solutions available. And they'll work great if you don't mind paying too much for five-year-old technology. Personally, I have a problem trusting Black Box crypto modules, particularly when the vendor's largest customer happens to be the government that you may be trying to protect yourself from. There's some notable open projects, the most notable being Orwell as in 1984. And for those of you looking for a secure solution to place at home just to protect your Monero private key, that might be a good way to go. Unfortunately, running a service like LavaBit takes a few more MIPS than a sixth gen mobile processor can give you. Unfortunately, even if that was enough, unfortunately, their RAC solution leaves something to be desired. So I decided to go with commodity hardware. And while I have my concerns about Dell, it's easy to find warehouses that let you pay cash and carry away the equipment. It's always good to purchase your gear anonymously. As a tip, if you have trouble finding a local vendor, try searching eBay for sellers selling what you want in your local area. Odds are, if they have multiple listings, they're simply a vendor with a warehouse full of gear. More than happy to sell it to you. Bo. Am I? OK. If you're a high value target, I'd certainly recommend against ordering equipment online and having it shipped. You never know what can happen to it in route. In case you didn't catch the subtext in this note, Apple even has problems with their servers being intercepted and modified during shipping. If the largest company in the world can't do it, what chance do we have? Interesting factoid. If you look at the SEC filings for Intel, you'll find out the three of their biggest customers for custom x86 chips are the NSA, Google, and Facebook. Makes you wonder what customizations they're having done to their particular chips. If there are any FOIA fans in the audience, they may want to go after those details. Be sure to pick a commodity hardware vendor with a reasonably robust and competent security team. So you could probably meet a big portion of the security team here, and you can make your own judgments about whether or not they're competent. You also want to look for one that's going to use signed firmware updates and will continue to publish firmware updates for some time after you purchase the hardware. Unfortunately, when it comes to commodity hardware, most servers do ship with tamper detection circuits, but they tend to be rudimentary and thus easy to bypass. It doesn't help that their location is known in advance. That's one of the benefits to the do-it-yourself approach. You can randomize the location, even add a reverse switch. To demonstrate just how easy it is to bypass these tamper detection circuits, Honimbo is going to demonstrate on this R710. So we need some volunteers in the audience who can see the front LED and tell us if he manages to trip the circuit. The trick in this case is to take the shim and go through the regulatory label hole in the top of the case, find the tamper circuit, depress it. They said it would be fast. We may have had a malfunction earlier. You know that always helps. Who's got something? Hey, you try getting up in front of 1,000 people at 7 in the morning and doing this. Here. Yeah, I did. Once you have the tamper circuit depressed, you can lift the top cover. Is that safe? Will it pop off? And remove the case, remove the lid, giving you access to all sorts of different ways of attacking the system. Most notably, being those exposed JTAG ports. Yeah, I didn't take it off now. Moving on, if you think about security as an absolute where something is either secure or it isn't, then you're going about it all wrong. I like to think about security in the same way physical safe manufacturers do. The first and most important job of a safe is to defend against spoofed access. If you can break into the safe without leading a trail, like by using this particular dialing that was demonstrated last year, the safe has failed. So our first mission in modifying our servers was to ensure that nobody could access them without us knowing. The second consideration is the degree of difficulty that an attacker would need in order to brute force their way past the locks. Presumably, with a physical safe, it's a blowtorch. With our approach, it's the same thing. And the goal is that the amount of force and heat required to remove our modifications are efficient to destroy the machine, thus accomplishing our goal. To continue, I'm going to turn the mic over to Honimbo, who's going to talk about how we made those modifications. So the first thing to know about all of these Dell systems is there's a very large debug headers, expansion modules, and available on these boards. Some of these are for legitimate things for businesses. You've got your iDRAC. You've got your various OpenManage. You've got these that sometimes have additional hands. And the next thing you do is take whatever hardware you end up with, and you've got to do a little bit of engineering and in our case, we took the little bit messy approach for some of this. So some people may recognize this as PC7 epoxy that we went through a lot of the boards. So anything that can't be physically removed from the board, we basically are unable to remove it. That they're not going to be able to practically do it while the sensors are still in place. So all over the other things that we also do the connectors. So these whole sides of the chassis, all for a very easy spot to pick probes through. And with those probes, there are various things, like the front header of the USB bus on the underneath the front bezel. And part of this is not just the debug interfaces, but the ones that you're actually using to conduct operation you have. There's only so much that you can actually turn off and still have a working system. PCI risers, we just went ahead and go for that. And just wear some gloves to take skin off. I know this the hard way. One thing some people may notice, I have some very cruddy solder joints on here. There is a reason for this is if someone were to start physically removing this switch, we would have the server fail off. So you may notice that we have a few different types of contacts here. One, we have just a sample of a simple lever switch or the roller next to the original Dell chassis sensor. So we have a few different types. Again, solder joints. And this is really interesting. So we take advantage of the actual disassembly for these servers. In this case, assembly module inside of one of these Dell R710s. Fan module comes out as a big tray. And we can pull out any hands. Luckily for us, Dell has lots of alerts for the system failure. What we started doing is in the modules, we added a lot of our circuitry and sensors for some of the units. And part of this is that in order to get to the initial components, not only do you have to try and bypass our sensors, but at the same time, you've got the existing diagnostic sensors that weren't even tamper intrusion working for you. So all of these extra fans, the speed sensors, there are tons of diagnostic information that lets you know something's wrong with your environment. Because inside of a co-location facility, any decent quality data center, you know what the environment is. And you take that to see whether or not the airflow is starting to lessen that something's in the room with you, whether or not the temperature is really going up in a way that's not related to hardware. And it comes down to a lot of monitoring. I'd just like to add that bearing the switch in the assembly here, you'll notice the lip, which protects an attacker against an attacker accessing it unless they go directly because they can't get the shim past this little lip here. It's important to take advantage of the natural character of your particular server when deciding where to place it. So we take advantage of that from the top, but also we actually will modify the frame as well. One thing that drilled to the top and risked that power supply are causing some kind of faults, which is quite nice enough to do this with various types of equipment from a hole on the side, a fiber laser on the government side. But going through the actual motherboard on the bottom, you're getting into the SATA buses that run underneath the particular area that we chose. And you're getting into a lot of other interfaces where if you started drilling through, it's going to be very, very difficult to get to those sensors. Take advantage of everything from your traces to your layout, just how tiny you can get these little microcontrollers in place. So we use the internal headers for connecting up our equipment rather than running it back out, obviously. And we just slathered everything on there. And you may notice we explicitly did not use pin headers. Again, just very, very cruddy solder joints in this epoxy. As a lot of people, like my challenge here, know, is that it is very easy to make a mistake and cause something to slip. And we want to take advantage of that, where a minor slip that normally wouldn't trigger will cause damage. As again, failing off is exactly what we want. And when you get to the code that we have available right now, it's currently in its older state. It's just a simple Arduino script that's currently up. We're uploading our new version of this talk. And we've since added tilt sensors. We've added other types of contact sensors besides shown. And one of the ones that we're actually working on right now is a challenge response NFC tag inside of some of the components. And with that, you'll actually be able to authenticate not just a little magnetic read sensor, but the particular tag inside of the chassis being used. We're doing great on time, so keep talking. So when we get into these challenge response systems in the box village just next door, you will notice that a lot of people just bring magnets and bypass the sensors directly. One of the unique things that you can get away with when you get into the DIY approach is you can have sensors that aren't documented outside of your own design. So we actually can have unique tags per contact point inside of this chassis on top of the more traditional methods. Because in a certain environment, you may be able to get the NFC signal out reliably. For practical purposes, these servers might as well be Faraday cages, as well as they're well-grounded. If someone were to try and tamper with the power supply to try to damage that, you have another Dell sensor that has a potential to kick in. And with this environment, you also have some other interesting approaches you can take. So we actually also control the server cabinets as well. And with control of the server cabinets, you know whether or not someone's supposed to be doing maintenance or whether or not someone's opening your doors to try and get access to the fiber line that's running into it. And actually, this is where you get to a little bit of the balance act that you have to do, is that it is very easy to shoot yourself in the foot with these sensors. So test your switches before you install them. Yes, test your switches before you install them. The hard drives that were originally going to come here succumb to that. The other thing to test is not just whether or not your own the individual server sensors work, but whether or not what you're sensing for the environment as a whole is not going to just come back to bite you. So overall, any operation, any home lab, any rack, and a data center, it's going to need maintenance. So if I were servicing this box right now, I could easily just shut off the sensors from the servicing purpose, lock the data, do whatever is necessary. But what about the server above and below it? Well, contact sensors won't be an issue. But let's say you start adding in things like various motion, tilt, and one of the more interesting ones to play with is light sensors. You have to maintain good airflow through your server still. So such sensors become very effective at detecting anything in your environment that's changed. But at the same time, you have to make sure the servers are still functional and what you can actually block off. The tilt sensors are actually one of the ones that we found the most problematic. Those server racks in particular, if you're not fortunate enough to have the ones anchored to the ground, will vibrate quite a bit when unracking the server beneath it and promptly lock or erase everything. Yeah. I mean, I can take over. Yeah, the great thing about those ball bearing tilt sensors is that if somebody tries to pull the server out on its rails, the tilt sensor will get switched from the movement, the inertia. So try drilling a hole in the top of a case when you've got two other computers on top of it that are equally protected. Like I said, it's about taking advantage of your environment. I wanted to talk about briefly how you go about building these particular modifications. It's a pretty simple process. Takes a little bit of practice. But it involves purchasing switches like this along with some ribbon cables. You solder it to the two pins, mount it in your chassis in various parts, and then wire everything back to the port on this little Arduino, which we protected with electrical tape to keep it from grounding. And copious amounts of epoxy. And then, of course, epoxy did in. You then connect that to your internal USB port. And you can use the Python script, the rudimentary version of it, which is in this repo, to monitor that Arduino and detect when any of your switches or detection modules get tripped and then choose to take the appropriate action. Presumably, if you have a fully encrypted system, it would be to shut down. Once you get all your modifications in place, one of the things we like to do, I didn't bring it, is use thread locker to ensure you can't even unscrew it. We didn't have the screw in this particular lid, but most of these servers have at least one optional screw that you can use. Another great tip is to cover your joints with something like varnish or my personal favorite, nail polish. The more glitter, the better. Sprinkle that on. Take a photo of the glitter pattern. And if anybody tries to remove the case, they won't be able to replicate the exact dispersion of the glitter. Foreman's holographic seals. Now, I'd like to talk a little bit about operational considerations when you're working in a high-thread environment and you have one of your sensors actually get tripped. One of the recommendations that I would make is to take advantage of the fact that Luxe supports multiple key slots. I don't have a lot of time to do that. But you can see that it supports up to eight different passwords. All you need to do is write a little script that when somebody enters the password in one of those high numbered key slots, it wipes the slot. That way, if you need to tell somebody the boot password, they can type it in. And if that password were intercepted, they wouldn't be able to use it again. We didn't talk about it earlier, but one of the reasons that we used PC7 epoxy is because it has the right thermal and electrical properties. You want to pick something that isn't going to create a short circuit with your board or trap the heat and destroy the heat. We also chose PC7 because it's incredibly difficult to remove as he mentioned. Don't get it on your hands. There are also other advantages or things that you can take advantage of if you're not using enterprise grade equipment. One of the things you want to look for, for example, is to look at the things you want to look for, for example, is ECC registered memory. The reason being, it's incredibly difficult to remove ECC memory and still read the information off the chip after the system is shut down because ECC memory, by default, cycles itself every time it powers on. You also want to add things like this project, USB kill, which will detect if anybody inserts a USB drive into any of your ports and can take appropriate action in that situation as well. Anything else we should cover? Let me pull up my notes. I feel like I'm forgetting something important. So actually that's a really good question. So there's a couple of options. Repeat the question. So he asked, how are we killing our hard drives? So the first method is simple. If you have Lux enabled, you're going to zero out your memory and shut down. The second is a little more aggressive and the reason that I had to drive out here. The hard drives that we use for some of the equipment actually has a two ounce thermite charge embedded inside of it next to the platters. I thought we weren't going to mention that. Well, good luck dealing with it. Yeah, don't nobody tell our Kolo. It's OK. Just a little smoke. It won't throw much fire. So the big trick to using a thermite drive, however, is choosing the right composition. The most common alloy used is FE304 based, I'm sorry, FE203. And FE304 is the variant that you want to use. It has a higher instantaneous heat output. And depending on how aggressive you really want to get, there's various other types of compounds that can be added in with it. Using a hobby rocketry igniter with a potassium permainate mixture gives a reliable ignition at a low voltage that can be delivered by the computer's power supplies. In terms of actually building the drives, the big difficulty is doing it in a clean environment. So with the hard drives, they're so dense now that a single speck of dust can kill a lot of sectors. So either A, if you can finagle your local university to let you use your clean room for a little bit in exchange for some beer, which is what I did. Or you can instead do the improvised clean room method in which you actually raise the humidity very high inside of an enclosed space. But the problem is that when you do this, you have to have some very good method of drying out the drives air after the fact. I take some fresh desiccant and I make sure it's in every drive when I do this. So when the air has a high moisture content, the dust will actually sit to the ground and you have a safe working environment to modify your drives. Don't assume a single drive will have good sectors afterwards. They won't. But over a large array of drives, like a sand, you'll end up with enough reliability that you can safely do it. Yeah. One of the things to consider is the fact that the old fashioned spinning magnetic disks are easy to destroy. All you need is to breach the case. And like you said, get a little dust in there and it'll be impossible to read the data. The problem with SSDs is they're a little bit more robust. And that's where the thermite patch or something of that nature might be required to physically destroy. Now, we're not recommending you go that route because we like to think that encryption software still provides the mathematical guarantee that you need so that if you shut power off to the device, it's just as good as if you would destroy it physically. In lieu of that, if you're using something like Opal to do your encryption, you can do an instant key erasure on the flash ROM and then nobody will ever be able to recover that data. The downside to Opal is that it's a black box module. It's implemented by the drive manufacturer. You're never going to get a chance at looking any code for it. There's a free PBA available from the Drive Trust Alliance and the self-encrypting drive utilities. However, that just talks to the drive. The actual encryption is still done on the drive itself, which if you choose to trust Samsung or Micron or one of the other manufacturers, it's a very fast and high-performance encryption system that actually erases it instantaneously. The downside is it's not testing a black box again. Did we talk about the NFC switches? I guess we have time for questions. I wasn't expecting that. Any questions? How do we test it? I will tell you right now, do not test in prod. What we actually do is I'll have usually a couple friends of mine that are various involvements and levels of tamper evidence are bypassing and I will not tell them what I did to a particular system and I will let them have at it. Beer goes a long way to bribe hackers. Pay your testers. We intended to actually bring a system out here for the tamper evidence village, but travel disruptions got in the way. Yeah. Basically, in terms of testing, you have to think about the entirety of your state machine, what possible attacks that you're considering, what your switchers are designed to do, and what exactly you're working on in the event of an intrusion. You may choose to say, I have different ranks of intrusion that I'm going to switch to just simply raising an alert or actually shutting down or even erasing the data. So, for example, the internal contact sensors, when we test those, we'll have people using various types of shims, various types of cutting tools, and various types of probes to try and bypass them. We actually use a randomized mixture per deployment on whether or not it's an open-ly contacted switch or a normally closed switch. So that way, you actually don't know, except per device for the person who built it, whether or not that switch is going to open or close if someone tried to short or bypass it. So when testing, we'll load up some data, and the goal is for whoever's looking at it, can they get this data off, whether they do it through a cold boot attack via USB, whether they do it through actually pulling out a drive and trying to keep power to it if you're using an OPAL method, or whether or not they can simply get, if they can get the chassis off without triggering it, that's considered a failed unit. You can just get the lid off, regardless of whether or not they do any memory-based attacks yet. Yeah, one of the photos that we showed, Chromebooks having trouble keeping up with the 700 megabyte PDF, is we actually epoxied the power cable from the PSU to the motherboard to ensure that somebody couldn't swap it out and remove the board that way while maintaining power to the system. And this is a photo that we took after just doing the connector. We actually slathered parts of the cables as well that are exposed. One of the attacks that actually is done for forensic purposes is they will actually slice the sheath of a power cable and apply power from a secondary source to try and keep the system running. Hot jacking. Yeah, hot jacking. And with that as a concern, we took kind of precautions in terms of epoxying over the existing power so that basically any attack that will remove the sheathing with it and cause a short. So we will accept the hard fail and data corruption as a path in that environment. Be sure to epoxy all of the places that an attacker could plug into and get direct memory access. As you can see here, we covered up the ports on the riser card so that nobody could insert anything into them and add something to the system. I didn't show it, but... You want to look for the BIOS chip, and we don't have a picture of it here, but the pins on the side of some of these integrated ports, you also want to cover those up so that nobody can add a lead to it and directly manipulate the integrated circuit. You also want to cover up the battery so nobody can kill power to your BIOS, particularly if you're using hardware level protection methods like OPAL. Most of the modern UEFI BIOS is for OPAL. If it detects a warm reboot, it will send the lock commands to the drives. However, if you don't have the ability for the BIOS to actually process and update to the current system status, that enables a possible hot jacking attack, this is again specific to OPAL when you have the encryption on the drive itself rather than using a method such as LUX where you're offloading it to memory. Also, be sure you don't overlook your integrated lights out management board. One of the problems we found with Dell equipment in particular is that it's possible to disable IPv4 access to the DRAC controller. What we ended up doing was setting the IP address to... A slash 32. Yep, make your subnet all 255s so that it can only talk to itself. And then you can sit there and wonder what it's saying. A non-existent broadcast domain is something that in some of the Dell firmwares you can actually set. So take that to your advantage since they don't allow you to actually turn the features off. You also want to cover up some of these unused ports in the back. You can swap out these default covers, which have convenient little holes in them, with ones that don't... You don't really have to worry about airflow because the rear air can still eject out the back of the power supply. And of course, it's a lot easier, or sorry, a lot harder, to get into the machine by sticking a fiber optic camera through an active power supply. We tried this and it ended in a lot of fireworks. We were curious. We had an old system. Any more questions? I think people install webcams inside the processor before... Yeah, we do it at the rack level. One of the things you want to look for is a motion. Oh, so he is asking if we install webcams inside of the hardware so we can watch anyone trying to manipulate it. So we install the webcam at the rack level, and then if you have a good one that can trigger on motion, you can see when anybody approaches the environment. And then presumably email the photo to you. Make sure that the photo actually gets transmitted. You don't want to have a situation where the only copy of the image happens to be in the device in the environment that the person is accessing. We actually also recommend that you have a secondary link going out besides your primary routers, especially in a Colo facility where the facility provides every bit of internet access otherwise. We actually experimented with cellular modules. Kalex actually has the sprint devices. And you can also, of course, for the various embedded hardware, various Arduino add-ons, etc., add GSM chipsets as well for Excel trading. Don't overlook hardening your routers as well. We use PF Sense machines, which run on commodity hardware. So we can do the same modifications to that as we do to the machines that run the encrypted services. It seems like most of this is geared around preventing a tap that you would be otherwise not aware of. If your goal is simply to deny them the hard disk, wouldn't it be straightforward and simple to use those switches to simply set the power of the hard drives and then when they go back up, they're not going to have access? So the question was, is that it seems this is geared around denying access in an undetected fashion to our data and whether or not the switches should just kill power to the system. So the reason that it doesn't just immediately kill power in every case is that first, some of the sensors are particularly sensitive. Regular maintenance in the racks around it will trigger them. So you first want an alert for that because you do have to balance what your actual operational goal is and what your security goal is. The contact sensors are designed to just kill things immediately because the contact sensor is not something that will go off via traditional rack maintenance like the tilt sensor might. Yeah, you'll find out through experimentation which sensors are more reliable than others. That's where the testing comes into play. And if you look at that Python script I posted a link to, all it does is monitor the sensors, the area of the script where you actually have to decide what happens is left blank. But presumably as I mentioned earlier, our recommendation isn't physical destruction. It's to rely on the mathematical guarantee provided by the encryption when you cut power. That at least affords you the option of restoring. You do have to be careful about using the same hardware that may have actually been tripped. So if you have a confirmed breach situation, you may just want to remove the hard drives and place them in a new chassis. I actually have a funny story. At Hope a couple of years back, the guys from Rise Up had the server that the FBI had confiscated and held on to for a year, and they brought it back to the hacking conference. They lifted the top of the cover off, and the challenge was to see if you could spot the modification. Any more questions? We're almost out of time. I'm actually recalling. Not yet. We've had a few false alarms when a prior facility of ours would actually do maintenance in our racks without notice, and they generated zero audit logs when they did this. They didn't tell us, they told no one. They wouldn't tell us what they were doing at one point, and I had to pry that information out of them. And while they didn't open up any of the chassis, they were moving the racks around, and at one point, recabling some of the... We found out later with the PDUs when we looked at the camera. So while that wasn't a particular intrusion attempt from the hard drive perspective, the sensors did catch it, and that's already a very suspicious thing just to be inside of someone's rack. Then recabling above the racks is very typical. Recabling the PDU inside of the rack is a very rare thing. What encryption do you guys recommend to guarantee the... So the question is, what encryption do we recommend to guarantee the security of the drives? I use AES-256 for my symmetric cipher. I've traditionally, for all my pub key stuff, have been switching to elliptical curve, although I heard yesterday at one of the talks that it's possible the National Security Agency might have a quantum computer in the very near future capable of breaking ECC and is now recommending that we use very large RSA keys. I don't know if I believe it yet because I'm not looking forward to switching back to 8K RSA keys. When it comes to the AES, you also have to choose what mode you want to use, whether you're using something as XTS or the CVC modes. Stick with an authenticated protocol if you can. If you have it and it supports it, you want to be operating in GCM block mode. Unfortunately, that won't work with a full disk encryption because it's a chain cipher. So in order to decrypt block, you have to know the previous block. So it's a stream cipher, sorry. You have to use a block mode like XTS. I do have pretty high hopes. I haven't implemented it yet in prod, but Chacha and Poly 1305 look like very promising replacements for AES. But when it comes to crypto, what I like to say is that speed kills. You move too fast and you're guaranteed to make a mistake and do something wrong, particularly when it comes to picking a new cipher or a new implementation. It's always good to go with the tried and true. The nice thing about symmetric ciphers is that they're much harder to break because of the mathematical principles behind them. They're essentially random number generators that are doing a one-time pat. So if nobody can break the random number generator, either by brute forcing the key or by taking the stream and determining what comes next, the algorithm stays secure. It's the public key algorithms that you have to worry about. And on a related note, cryptographic hash algorithms are an interesting discussion because traditionally SHA-256 and 512 have been very secure alternatives. But what we're seeing is that with the emergence of Bitcoin and all of the investment in A6 is the speed at which they run reduces the security of those older algorithms. One more question if we have it. All right, well, if you think of something later, just come find me at the pool. I'll be at the 303 party tonight.
 All right, good morning.  I say good morning because I know by this point in DEF CON,  we're better off using the same time zone as Tokyo, which  makes this about 7 AM.  So thank you for getting out of bed.  The good news is we have an interesting topic ahead.  We'll get to spend the next hour talking about boobies.  Or more specifically, strategies designed  to protect an execution environment for manipulation  with a specific eye towards ensuring cryptographic keys  can't be exfiltrated via physical access.  Try three times fast.  Oh, man.  There we go.  Yeah, I tried to change the slide over here,  and Google was asking me for a question.  Your presenters today are myself, Ladar Levison,  and I'm Hanimbo.  Hanimbo Tales, what we're going to be talking about  are essential skills for life in the world of 1984,  where the maids can't be trusted and your big brother  is out to get you.  For my part, I'm the operator of LavaBit and encrypted email  service.  I'm a technological warlock, a corporate kingpin,  and some would say a team linchpin.  My assistant, Hanimbo, is the proprietor of hacking and coffee,  and he enjoys robbing banks under the cover of darkness.  Assistant, come on, man.  I'm your web host at this point.  I'm a little more than that.  Let's talk about security.  As an industry, I think we've come a long way.  Speaking for myself, it's been a few years  since I've seen anybody try to log into their box via Telnet.  One of the key factors pushing that security is encryption  and its proliferation.  Encryption is important because it provides  a mathematical guarantee that the data can't be accessed  without the corresponding key.  Of course, the problem is that as we've evolved,  so have the attacks.  Unfortunately, as good as we are at architecting and building  secure systems, we still need a reliable and friendly  environment to run our bug-free, ultra-secure code.  With encryption specifically, we've  seen a new breed of attacks where all the security measures  we put in place get simply via physical access.  Now, there's a picture of an altair  because that was probably the last computer you could look at  and kind of understand how it worked on the inside.  Before we go any further, we should talk about our assumptions.  For our purposes, we're focused on targeted physical attacks,  which means we're making the assumption there is no universal  backdoor in x86 hardware.  As always, when it comes to assumptions,  your mileage may vary.  Unfortunately, we don't have time to cover it today,  but it makes sense that if your threat model requires you  to install booby traps in your hardware,  you probably want to do to your IME as well.  For those of you who spent some time in this building,  what we're talking about will look familiar.  Essentially, we're talking about taking commodity hardware  and modifying it to afford you some of the security guarantees  provided by FIPS Level 4.  So we can run our common criteria EAL 4 plus software  in a secure environment.  Unlike the actual FIPS Level 4, our recommendations  don't come with certificates from the government though.  If you aren't familiar with those standards, don't fret.  It only means you haven't spent much time working for the man.  For those folks, I'll summarize by saying FIPS Level 4  is what the State Department would  use for a classified information terminal.  They have located in the basement of the American Embassy  in Taylor.  Some place interesting like that,  if a machine can stay secure in an environment like that,  is that the same computer would be worthy of being placed  in a co-located facility and be safe from legal, extra legal,  and illegal access, probably.  There are plenty of commercial solutions available.  And they'll work great if you don't mind paying  too much for five-year-old technology.  Personally, I have a problem trusting Black Box crypto  modules, particularly when the vendor's largest customer happens  to be the government that you may be trying  to protect yourself from.  There's some notable open projects, the most notable being  Orwell as in 1984.  And for those of you looking for a secure solution to place  at home just to protect your Monero private key,  that might be a good way to go.  Unfortunately, running a service like LavaBit  takes a few more MIPS than a sixth gen mobile processor  can give you.  Unfortunately, even if that was enough,  unfortunately, their RAC solution  leaves something to be desired.  So I decided to go with commodity hardware.  And while I have my concerns about Dell,  it's easy to find warehouses that let you pay cash  and carry away the equipment.  It's always good to purchase your gear anonymously.  As a tip, if you have trouble finding a local vendor,  try searching eBay for sellers selling what you want  in your local area.  Odds are, if they have multiple listings,  they're simply a vendor with a warehouse full of gear.  More than happy to sell it to you.  Bo.  Am I?  OK.  If you're a high value target, I'd certainly  recommend against ordering equipment online and having  it shipped.  You never know what can happen to it in route.  In case you didn't catch the subtext in this note,  Apple even has problems with their servers being intercepted  and modified during shipping.  If the largest company in the world can't do it,  what chance do we have?  Interesting factoid.  If you look at the SEC filings for Intel,  you'll find out the three of their biggest customers  for custom x86 chips are the NSA, Google, and Facebook.  Makes you wonder what customizations  they're having done to their particular chips.  If there are any FOIA fans in the audience,  they may want to go after those details.  Be sure to pick a commodity hardware vendor  with a reasonably robust and competent security team.  So you could probably meet a big portion of the security team  here, and you can make your own judgments about whether or not  they're competent.  You also want to look for one that's  going to use signed firmware updates  and will continue to publish firmware updates for some time  after you purchase the hardware.  Unfortunately, when it comes to commodity hardware,  most servers do ship with tamper detection circuits,  but they tend to be rudimentary and thus easy to bypass.  It doesn't help that their location is known in advance.  That's one of the benefits to the do-it-yourself approach.  You can randomize the location, even add a reverse switch.  To demonstrate just how easy it is  to bypass these tamper detection circuits,  Honimbo is going to demonstrate on this R710.  So we need some volunteers in the audience  who can see the front LED and tell us  if he manages to trip the circuit.  The trick in this case is to take the shim  and go through the regulatory label hole in the top of the case,  find the tamper circuit, depress it.  They said it would be fast.  We may have had a malfunction earlier.  You know that always helps.  Who's got something?  Hey, you try getting up in front of 1,000 people  at 7 in the morning and doing this.  Here.  Yeah, I did.  Once you have the tamper circuit depressed,  you can lift the top cover.  Is that safe?  Will it pop off?  And remove the case, remove the lid,  giving you access to all sorts of different ways  of attacking the system.  Most notably, being those exposed JTAG ports.  Yeah, I didn't take it off now.  Moving on, if you think about security as an absolute  where something is either secure or it isn't,  then you're going about it all wrong.  I like to think about security in the same way  physical safe manufacturers do.  The first and most important job of a safe  is to defend against spoofed access.  If you can break into the safe without leading a trail,  like by using this particular dialing  that was demonstrated last year, the safe has failed.  So our first mission in modifying our servers  was to ensure that nobody could access them  without us knowing.  The second consideration is the degree of difficulty  that an attacker would need in order  to brute force their way past the locks.  Presumably, with a physical safe, it's a blowtorch.  With our approach, it's the same thing.  And the goal is that the amount of force  and heat required to remove our modifications  are efficient to destroy the machine,  thus accomplishing our goal.  To continue, I'm going to turn the mic over to Honimbo,  who's going to talk about how we made those modifications.  So the first thing to know about all of these Dell systems  is there's a very large debug headers, expansion modules,  and available on these boards.  Some of these are for legitimate things for businesses.  You've got your iDRAC.  You've got your various OpenManage.  You've got these that sometimes have additional hands.  And the next thing you do is take whatever hardware you end up  with, and you've got to do a little bit of engineering  and in our case, we took the little bit messy approach  for some of this.  So some people may recognize this as PC7 epoxy  that we went through a lot of the boards.  So anything that can't be physically removed from the board,  we basically are unable to remove it.  That they're not going to be able to practically do it  while the sensors are still in place.  So all over the other things that we also do the connectors.  So these whole sides of the chassis,  all for a very easy spot to pick probes through.  And with those probes, there are various things,  like the front header of the USB bus  on the underneath the front bezel.  And part of this is not just the debug interfaces,  but the ones that you're actually using to conduct  operation you have.  There's only so much that you can actually turn off  and still have a working system.  PCI risers, we just went ahead and go for that.  And just wear some gloves to take skin off.  I know this the hard way.  One thing some people may notice, I have some very  cruddy solder joints on here.  There is a reason for this is if someone were to start  physically removing this switch, we would have the server fail  off.  So you may notice that we have a few different types of contacts  here.  One, we have just a sample of a simple lever switch  or the roller next to the original Dell chassis sensor.  So we have a few different types.  Again, solder joints.  And this is really interesting.  So we take advantage of the actual disassembly  for these servers.  In this case, assembly module inside of one of these  Dell R710s.  Fan module comes out as a big tray.  And we can pull out any hands.  Luckily for us, Dell has lots of alerts  for the system failure.  What we started doing is in the modules,  we added a lot of our circuitry and sensors  for some of the units.  And part of this is that in order  to get to the initial components, not only do you  have to try and bypass our sensors, but at the same time,  you've got the existing diagnostic sensors that  weren't even tamper intrusion working for you.  So all of these extra fans, the speed sensors,  there are tons of diagnostic information  that lets you know something's wrong with your environment.  Because inside of a co-location facility,  any decent quality data center, you know what the environment is.  And you take that to see whether or not  the airflow is starting to lessen that something's  in the room with you, whether or not  the temperature is really going up in a way that's not  related to hardware.  And it comes down to a lot of monitoring.  I'd just like to add that bearing the switch in the assembly  here, you'll notice the lip, which protects  an attacker against an attacker accessing it  unless they go directly because they can't get the shim past  this little lip here.  It's important to take advantage of the natural character  of your particular server when deciding where to place it.  So we take advantage of that from the top,  but also we actually will modify the frame as well.  One thing that drilled to the top and risked that power supply  are causing some kind of faults, which  is quite nice enough to do this with various types of equipment  from a hole on the side, a fiber laser on the government side.  But going through the actual motherboard on the bottom,  you're getting into the SATA buses that run underneath  the particular area that we chose.  And you're getting into a lot of other interfaces  where if you started drilling through,  it's going to be very, very difficult to get to those sensors.  Take advantage of everything from your traces to your layout,  just how tiny you can get these little microcontrollers  in place.  So we use the internal headers for connecting up  our equipment rather than running it back out, obviously.  And we just slathered everything on there.  And you may notice we explicitly did not use pin headers.  Again, just very, very cruddy solder joints in this epoxy.  As a lot of people, like my challenge here,  know, is that it is very easy to make a mistake  and cause something to slip.  And we want to take advantage of that, where a minor slip that  normally wouldn't trigger will cause damage.  As again, failing off is exactly what we want.  And when you get to the code that we have available right now,  it's currently in its older state.  It's just a simple Arduino script that's currently up.  We're uploading our new version of this talk.  And we've since added tilt sensors.  We've added other types of contact sensors besides shown.  And one of the ones that we're actually working on right now  is a challenge response NFC tag inside of some of the components.  And with that, you'll actually be able to authenticate not just  a little magnetic read sensor, but the particular tag  inside of the chassis being used.  We're doing great on time, so keep talking.  So when we get into these challenge response systems  in the box village just next door,  you will notice that a lot of people just bring magnets  and bypass the sensors directly.  One of the unique things that you can get away with when  you get into the DIY approach is you  can have sensors that aren't documented outside  of your own design.  So we actually can have unique tags per contact point  inside of this chassis on top of the more traditional methods.  Because in a certain environment, you  may be able to get the NFC signal out reliably.  For practical purposes, these servers  might as well be Faraday cages, as well as they're well-grounded.  If someone were to try and tamper with the power supply  to try to damage that, you have another Dell sensor  that has a potential to kick in.  And with this environment, you also  have some other interesting approaches you can take.  So we actually also control the server cabinets as well.  And with control of the server cabinets,  you know whether or not someone's supposed  to be doing maintenance or whether or not someone's  opening your doors to try and get access to the fiber line that's  running into it.  And actually, this is where you get to a little bit of the balance  act that you have to do, is that it is very easy to shoot yourself  in the foot with these sensors.  So test your switches before you install them.  Yes, test your switches before you install them.  The hard drives that were originally going to come here  succumb to that.  The other thing to test is not just whether or not  your own the individual server sensors work,  but whether or not what you're sensing for the environment  as a whole is not going to just come back to bite you.  So overall, any operation, any home lab, any rack,  and a data center, it's going to need maintenance.  So if I were servicing this box right now,  I could easily just shut off the sensors  from the servicing purpose, lock the data,  do whatever is necessary.  But what about the server above and below it?  Well, contact sensors won't be an issue.  But let's say you start adding in things like various motion,  tilt, and one of the more interesting ones to play with  is light sensors.  You have to maintain good airflow through your server still.  So such sensors become very effective at detecting anything  in your environment that's changed.  But at the same time, you have to make sure the servers are  still functional and what you can actually block off.  The tilt sensors are actually one of the ones  that we found the most problematic.  Those server racks in particular,  if you're not fortunate enough to have the ones anchored  to the ground, will vibrate quite a bit  when unracking the server beneath it  and promptly lock or erase everything.  Yeah.  I mean, I can take over.  Yeah, the great thing about those ball bearing tilt sensors  is that if somebody tries to pull the server out on its rails,  the tilt sensor will get switched from the movement,  the inertia.  So try drilling a hole in the top of a case  when you've got two other computers on top of it  that are equally protected.  Like I said, it's about taking advantage of your environment.  I wanted to talk about briefly how  you go about building these particular modifications.  It's a pretty simple process.  Takes a little bit of practice.  But it involves purchasing switches  like this along with some ribbon cables.  You solder it to the two pins, mount it in your chassis  in various parts, and then wire everything back  to the port on this little Arduino, which we protected  with electrical tape to keep it from grounding.  And copious amounts of epoxy.  And then, of course, epoxy did in.  You then connect that to your internal USB port.  And you can use the Python script, the rudimentary version  of it, which is in this repo, to monitor that Arduino  and detect when any of your switches or detection modules  get tripped and then choose to take the appropriate action.  Presumably, if you have a fully encrypted system,  it would be to shut down.  Once you get all your modifications in place,  one of the things we like to do, I didn't bring it,  is use thread locker to ensure you can't even unscrew it.  We didn't have the screw in this particular lid,  but most of these servers have at least one optional screw  that you can use.  Another great tip is to cover your joints with something  like varnish or my personal favorite, nail polish.  The more glitter, the better.  Sprinkle that on.  Take a photo of the glitter pattern.  And if anybody tries to remove the case,  they won't be able to replicate the exact dispersion  of the glitter.  Foreman's holographic seals.  Now, I'd like to talk a little bit about operational  considerations when you're working in a high-thread  environment and you have one of your sensors actually  get tripped.  One of the recommendations that I would make  is to take advantage of the fact that Luxe supports  multiple key slots.  I don't have a lot of time to do that.  But you can see that it supports up to eight  different passwords.  All you need to do is write a little script  that when somebody enters the password in one of those high  numbered key slots, it wipes the slot.  That way, if you need to tell somebody the boot password,  they can type it in.  And if that password were intercepted,  they wouldn't be able to use it again.  We didn't talk about it earlier, but one of the reasons  that we used PC7 epoxy is because it has the right  thermal and electrical properties.  You want to pick something that isn't going to create a short  circuit with your board or trap the heat and destroy the  heat.  We also chose PC7 because it's incredibly difficult to remove  as he mentioned.  Don't get it on your hands.  There are also other advantages or things that you can take  advantage of if you're not using enterprise grade equipment.  One of the things you want to look for, for example,  is to look at the  things you want to look for, for example,  is ECC registered memory.  The reason being, it's incredibly difficult to remove  ECC memory and still read the information off the chip after  the system is shut down because ECC memory, by default,  cycles itself every time it powers on.  You also want to add things like this project,  USB kill, which will detect if anybody inserts a USB drive  into any of your ports and can take appropriate action in  that situation as well.  Anything else we should cover?  Let me pull up my notes.  I feel like I'm forgetting something important.  So actually that's a really good question.  So there's a couple of options.  Repeat the question.  So he asked, how are we killing our hard drives?  So the first method is simple.  If you have Lux enabled, you're going to zero out your memory  and shut down.  The second is a little more aggressive and the reason that  I had to drive out here.  The hard drives that we use for some of the equipment actually  has a two ounce thermite charge embedded inside of it next  to the platters.  I thought we weren't going to mention that.  Well, good luck dealing with it.  Yeah, don't nobody tell our Kolo.  It's OK.  Just a little smoke.  It won't throw much fire.  So the big trick to using a thermite drive, however,  is choosing the right composition.  The most common alloy used is FE304 based, I'm sorry,  FE203.  And FE304 is the variant that you want to use.  It has a higher instantaneous heat output.  And depending on how aggressive you really want to get,  there's various other types of compounds  that can be added in with it.  Using a hobby rocketry igniter with a potassium permainate  mixture gives a reliable ignition at a low voltage that can be  delivered by the computer's power supplies.  In terms of actually building the drives,  the big difficulty is doing it in a clean environment.  So with the hard drives, they're so dense now that a single  speck of dust can kill a lot of sectors.  So either A, if you can finagle your local university to let  you use your clean room for a little bit in exchange  for some beer, which is what I did.  Or you can instead do the improvised clean room method  in which you actually raise the humidity very high inside of an  enclosed space.  But the problem is that when you do this,  you have to have some very good method of drying out the drives  air after the fact.  I take some fresh desiccant and I make sure it's in every drive  when I do this.  So when the air has a high moisture content,  the dust will actually sit to the ground and you have a safe  working environment to modify your drives.  Don't assume a single drive will have good sectors afterwards.  They won't.  But over a large array of drives, like a sand,  you'll end up with enough reliability that you can safely do it.  Yeah.  One of the things to consider is the fact that the old fashioned  spinning magnetic disks are easy to destroy.  All you need is to breach the case.  And like you said, get a little dust in there and it'll be impossible  to read the data.  The problem with SSDs is they're a little bit more robust.  And that's where the thermite patch or something of that nature  might be required to physically destroy.  Now, we're not recommending you go that route because we like  to think that encryption software still provides the mathematical  guarantee that you need so that if you shut power off to the device,  it's just as good as if you would destroy it physically.  In lieu of that, if you're using something like Opal to do your  encryption, you can do an instant key erasure on the flash ROM  and then nobody will ever be able to recover that data.  The downside to Opal is that it's a black box module.  It's implemented by the drive manufacturer.  You're never going to get a chance at looking any code for it.  There's a free PBA available from the Drive Trust Alliance  and the self-encrypting drive utilities.  However, that just talks to the drive.  The actual encryption is still done on the drive itself,  which if you choose to trust Samsung or Micron or one of the other manufacturers,  it's a very fast and high-performance encryption system that actually erases it  instantaneously. The downside is it's not testing a black box again.  Did we talk about the NFC switches?  I guess we have time for questions.  I wasn't expecting that.  Any questions?  How do we test it?  I will tell you right now, do not test in prod.  What we actually do is I'll have usually a couple friends of mine  that are various involvements and levels of tamper evidence are bypassing  and I will not tell them what I did to a particular system  and I will let them have at it.  Beer goes a long way to bribe hackers.  Pay your testers.  We intended to actually bring a system out here for the tamper evidence village,  but travel disruptions got in the way.  Yeah.  Basically, in terms of testing, you have to think about the entirety of your state machine,  what possible attacks that you're considering,  what your switchers are designed to do,  and what exactly you're working on in the event of an intrusion.  You may choose to say, I have different ranks of intrusion  that I'm going to switch to just simply raising an alert  or actually shutting down or even erasing the data.  So, for example, the internal contact sensors, when we test those,  we'll have people using various types of shims, various types of cutting tools,  and various types of probes to try and bypass them.  We actually use a randomized mixture per deployment  on whether or not it's an open-ly contacted switch or a normally closed switch.  So that way, you actually don't know, except per device for the person who built it,  whether or not that switch is going to open or close  if someone tried to short or bypass it.  So when testing, we'll load up some data,  and the goal is for whoever's looking at it, can they get this data off,  whether they do it through a cold boot attack via USB,  whether they do it through actually pulling out a drive  and trying to keep power to it if you're using an OPAL method,  or whether or not they can simply get, if they can get the chassis off  without triggering it, that's considered a failed unit.  You can just get the lid off, regardless of whether or not they do any memory-based attacks yet.  Yeah, one of the photos that we showed,  Chromebooks having trouble keeping up with the 700 megabyte PDF,  is we actually epoxied the power cable from the PSU to the motherboard  to ensure that somebody couldn't swap it out  and remove the board that way while maintaining power to the system.  And this is a photo that we took after just doing the connector.  We actually slathered parts of the cables as well that are exposed.  One of the attacks that actually is done for forensic purposes is  they will actually slice the sheath of a power cable  and apply power from a secondary source to try and keep the system running.  Hot jacking.  Yeah, hot jacking.  And with that as a concern, we took kind of precautions  in terms of epoxying over the existing power  so that basically any attack that will remove the sheathing with it and cause a short.  So we will accept the hard fail and data corruption as a path in that environment.  Be sure to epoxy all of the places that an attacker could plug into and get direct memory access.  As you can see here, we covered up the ports on the riser card  so that nobody could insert anything into them and add something to the system.  I didn't show it, but...  You want to look for the BIOS chip, and we don't have a picture of it here,  but the pins on the side of some of these integrated ports,  you also want to cover those up so that nobody can add a lead to it  and directly manipulate the integrated circuit.  You also want to cover up the battery so nobody can kill power to your BIOS,  particularly if you're using hardware level protection methods like OPAL.  Most of the modern UEFI BIOS is for OPAL.  If it detects a warm reboot, it will send the lock commands to the drives.  However, if you don't have the ability for the BIOS to actually process and update  to the current system status, that enables a possible hot jacking attack,  this is again specific to OPAL when you have the encryption on the drive itself  rather than using a method such as LUX where you're offloading it to memory.  Also, be sure you don't overlook your integrated lights out management board.  One of the problems we found with Dell equipment in particular  is that it's possible to disable IPv4 access to the DRAC controller.  What we ended up doing was setting the IP address to...  A slash 32.  Yep, make your subnet all 255s so that it can only talk to itself.  And then you can sit there and wonder what it's saying.  A non-existent broadcast domain is something that in some of the Dell firmwares  you can actually set.  So take that to your advantage since they don't allow you to actually turn the features off.  You also want to cover up some of these unused ports in the back.  You can swap out these default covers,  which have convenient little holes in them,  with ones that don't...  You don't really have to worry about airflow  because the rear air can still eject out the back of the power supply.  And of course, it's a lot easier, or sorry, a lot harder,  to get into the machine by sticking a fiber optic camera through an active power supply.  We tried this and it ended in a lot of fireworks.  We were curious. We had an old system.  Any more questions?  I think people install webcams inside the processor before...  Yeah, we do it at the rack level.  One of the things you want to look for is a motion.  Oh, so he is asking if we install webcams inside of the hardware  so we can watch anyone trying to manipulate it.  So we install the webcam at the rack level,  and then if you have a good one that can trigger on motion,  you can see when anybody approaches the environment.  And then presumably email the photo to you.  Make sure that the photo actually gets transmitted.  You don't want to have a situation where the only copy of the image happens to be in the device  in the environment that the person is accessing.  We actually also recommend that you have a secondary link going out besides your primary routers,  especially in a Colo facility where the facility provides every bit of internet access otherwise.  We actually experimented with cellular modules.  Kalex actually has the sprint devices.  And you can also, of course, for the various embedded hardware, various Arduino add-ons, etc.,  add GSM chipsets as well for Excel trading.  Don't overlook hardening your routers as well.  We use PF Sense machines, which run on commodity hardware.  So we can do the same modifications to that as we do to the machines that run the encrypted services.  It seems like most of this is geared around preventing a tap that you would be otherwise not aware of.  If your goal is simply to deny them the hard disk, wouldn't it be straightforward and simple to use those switches  to simply set the power of the hard drives and then when they go back up, they're not going to have access?  So the question was, is that it seems this is geared around denying access in an undetected fashion to our data  and whether or not the switches should just kill power to the system.  So the reason that it doesn't just immediately kill power in every case is that first,  some of the sensors are particularly sensitive.  Regular maintenance in the racks around it will trigger them.  So you first want an alert for that because you do have to balance what your actual operational goal is  and what your security goal is.  The contact sensors are designed to just kill things immediately  because the contact sensor is not something that will go off via traditional rack maintenance like the tilt sensor might.  Yeah, you'll find out through experimentation which sensors are more reliable than others.  That's where the testing comes into play.  And if you look at that Python script I posted a link to,  all it does is monitor the sensors,  the area of the script where you actually have to decide what happens is left blank.  But presumably as I mentioned earlier, our recommendation isn't physical destruction.  It's to rely on the mathematical guarantee provided by the encryption when you cut power.  That at least affords you the option of restoring.  You do have to be careful about using the same hardware that may have actually been tripped.  So if you have a confirmed breach situation,  you may just want to remove the hard drives and place them in a new chassis.  I actually have a funny story.  At Hope a couple of years back, the guys from Rise Up had the server that the FBI had confiscated  and held on to for a year, and they brought it back to the hacking conference.  They lifted the top of the cover off, and the challenge was to see if you could spot the modification.  Any more questions? We're almost out of time.  I'm actually recalling.  Not yet.  We've had a few false alarms when a prior facility of ours would actually do maintenance in our racks  without notice, and they generated zero audit logs when they did this.  They didn't tell us, they told no one.  They wouldn't tell us what they were doing at one point, and I had to pry that information out of them.  And while they didn't open up any of the chassis, they were moving the racks around,  and at one point, recabling some of the...  We found out later with the PDUs when we looked at the camera.  So while that wasn't a particular intrusion attempt from the hard drive perspective,  the sensors did catch it, and that's already a very suspicious thing just to be inside of someone's rack.  Then recabling above the racks is very typical.  Recabling the PDU inside of the rack is a very rare thing.  What encryption do you guys recommend to guarantee the...  So the question is, what encryption do we recommend to guarantee the security of the drives?  I use AES-256 for my symmetric cipher.  I've traditionally, for all my pub key stuff, have been switching to elliptical curve,  although I heard yesterday at one of the talks that it's possible the National Security Agency  might have a quantum computer in the very near future capable of breaking ECC  and is now recommending that we use very large RSA keys.  I don't know if I believe it yet because I'm not looking forward to switching back to 8K RSA keys.  When it comes to the AES, you also have to choose what mode you want to use,  whether you're using something as XTS or the CVC modes.  Stick with an authenticated protocol if you can.  If you have it and it supports it, you want to be operating in GCM block mode.  Unfortunately, that won't work with a full disk encryption because it's a chain cipher.  So in order to decrypt block, you have to know the previous block.  So it's a stream cipher, sorry.  You have to use a block mode like XTS.  I do have pretty high hopes.  I haven't implemented it yet in prod,  but Chacha and Poly 1305 look like very promising replacements for AES.  But when it comes to crypto, what I like to say is that speed kills.  You move too fast and you're guaranteed to make a mistake and do something wrong,  particularly when it comes to picking a new cipher or a new implementation.  It's always good to go with the tried and true.  The nice thing about symmetric ciphers is that they're much harder to break  because of the mathematical principles behind them.  They're essentially random number generators that are doing a one-time pat.  So if nobody can break the random number generator, either by brute forcing the key  or by taking the stream and determining what comes next, the algorithm stays secure.  It's the public key algorithms that you have to worry about.  And on a related note, cryptographic hash algorithms are an interesting discussion  because traditionally SHA-256 and 512 have been very secure alternatives.  But what we're seeing is that with the emergence of Bitcoin  and all of the investment in A6 is the speed at which they run  reduces the security of those older algorithms.  One more question if we have it.  All right, well, if you think of something later, just come find me at the pool.  I'll be at the 303 party tonight.
DEF_CON_26_-_Ladar_Levison__hon1nbo_-_Booby_Trapping_Boxes_XrzIjxO8MOs_0_899.png DEF_CON_26_-_Ladar_Levison__hon1nbo_-_Booby_Trapping_Boxes_XrzIjxO8MOs_900_2327.png DEF_CON_26_-_Ladar_Levison__hon1nbo_-_Booby_Trapping_Boxes_XrzIjxO8MOs_2328_3455.png DEF_CON_26_-_Ladar_Levison__hon1nbo_-_Booby_Trapping_Boxes_XrzIjxO8MOs_3456_12287.png DEF_CON_26_-_Ladar_Levison__hon1nbo_-_Booby_Trapping_Boxes_XrzIjxO8MOs_12288_13547.png DEF_CON_26_-_Ladar_Levison__hon1nbo_-_Booby_Trapping_Boxes_XrzIjxO8MOs_13548_14759.png DEF_CON_26_-_Ladar_Levison__hon1nbo_-_Booby_Trapping_Boxes_XrzIjxO8MOs_14760_22871.png DEF_CON_26_-_Ladar_Levison__hon1nbo_-_Booby_Trapping_Boxes_XrzIjxO8MOs_22872_26711.png DEF_CON_26_-_Ladar_Levison__hon1nbo_-_Booby_Trapping_Boxes_XrzIjxO8MOs_26712_26855.png DEF_CON_26_-_Ladar_Levison__hon1nbo_-_Booby_Trapping_Boxes_XrzIjxO8MOs_26856_27107.png DEF_CON_26_-_Ladar_Levison__hon1nbo_-_Booby_Trapping_Boxes_XrzIjxO8MOs_27108_28775.png DEF_CON_26_-_Ladar_Levison__hon1nbo_-_Booby_Trapping_Boxes_XrzIjxO8MOs_28776_28835.png DEF_CON_26_-_Ladar_Levison__hon1nbo_-_Booby_Trapping_Boxes_XrzIjxO8MOs_28836_29159.png DEF_CON_26_-_Ladar_Levison__hon1nbo_-_Booby_Trapping_Boxes_XrzIjxO8MOs_29160_31991.png DEF_CON_26_-_Ladar_Levison__hon1nbo_-_Booby_Trapping_Boxes_XrzIjxO8MOs_31992_32255.png DEF_CON_26_-_Ladar_Levison__hon1nbo_-_Booby_Trapping_Boxes_XrzIjxO8MOs_32256_35819.png DEF_CON_26_-_Ladar_Levison__hon1nbo_-_Booby_Trapping_Boxes_XrzIjxO8MOs_35820_40175.png DEF_CON_26_-_Ladar_Levison__hon1nbo_-_Booby_Trapping_Boxes_XrzIjxO8MOs_40176_40235.png DEF_CON_26_-_Ladar_Levison__hon1nbo_-_Booby_Trapping_Boxes_XrzIjxO8MOs_40236_41603.png DEF_CON_26_-_Ladar_Levison__hon1nbo_-_Booby_Trapping_Boxes_XrzIjxO8MOs_41604_42659.png DEF_CON_26_-_Ladar_Levison__hon1nbo_-_Booby_Trapping_Boxes_XrzIjxO8MOs_42660_42803.png DEF_CON_26_-_Ladar_Levison__hon1nbo_-_Booby_Trapping_Boxes_XrzIjxO8MOs_42804_47651.png DEF_CON_26_-_Ladar_Levison__hon1nbo_-_Booby_Trapping_Boxes_XrzIjxO8MOs_47652_48767.png DEF_CON_26_-_Ladar_Levison__hon1nbo_-_Booby_Trapping_Boxes_XrzIjxO8MOs_48768_50567.png DEF_CON_26_-_Ladar_Levison__hon1nbo_-_Booby_Trapping_Boxes_XrzIjxO8MOs_50568_55907.png DEF_CON_26_-_Ladar_Levison__hon1nbo_-_Booby_Trapping_Boxes_XrzIjxO8MOs_55908_57263.png DEF_CON_26_-_Ladar_Levison__hon1nbo_-_Booby_Trapping_Boxes_XrzIjxO8MOs_57264_57311.png DEF_CON_26_-_Ladar_Levison__hon1nbo_-_Booby_Trapping_Boxes_XrzIjxO8MOs_57312_57623.png DEF_CON_26_-_Ladar_Levison__hon1nbo_-_Booby_Trapping_Boxes_XrzIjxO8MOs_57624_57719.png DEF_CON_26_-_Ladar_Levison__hon1nbo_-_Booby_Trapping_Boxes_XrzIjxO8MOs_57720_58739.png DEF_CON_26_-_Ladar_Levison__hon1nbo_-_Booby_Trapping_Boxes_XrzIjxO8MOs_58740_61763.png DEF_CON_26_-_Ladar_Levison__hon1nbo_-_Booby_Trapping_Boxes_XrzIjxO8MOs_61764_63342.png