DEFCON 21. Passwords alone are not enough, or why disk encryption “breaks down” and how it can be fixed. Part 2

Original author: Daniel Selifonov
  • Transfer
DEFCON 21. Passwords alone are not enough, or why disk encryption “breaks down” and how it can be fixed. Part 1

There are funny things, such as monotonically increasing counters, with which you can monitor the activity of TMP, and then check the values ​​obtained. There is a small range of non-volatile memory that can be used for your needs, it is not as big as a kilobyte, but it can also be useful. There is a clock counter, which allows you to determine how long the system has been running since the last run. There are commands that you could give TMP to get him to do things on your behalf, including clearing your own memory if necessary.

Then we want to develop a protocol that the user can run on the computer to make sure that the computer has not been hacked, before it is authenticated on the computer and will begin to use it. What is useful for such a protocol, we can try to "seal" in the configuration registers of the platform?

I have a couple of suggestions: these are tokens for one-time user passwords, a unique image or animation, for example, your photo, something original that cannot be easily found elsewhere. You can also turn off “video out” on your computer when you are in request mode and authentication authentication.

You may also want to “seal” part of a disk key, and there are several reasons why you would like to do this. Within certain security assumptions, this ensures that the system will only boot into some approved software configuration that you control as the owner of the computer. Ultimately, this means that anyone who wants to attack your system must do this either by breaking TMP or doing it in the sandbox you created for them. Of course, this is not a very strong cryptographic protection, because you will not have a protocol that allows the user to securely authenticate with the same level of security that, say, AES provides. But if you are not able to organize something like RSA encryption in your own head,

I mentioned that in TPM there is a self-erase command, which can be executed through software. Because TPM requires a certain system configuration, before it reveals “secrets,” you can do something interesting, such as self-destruction. You can develop software and create your own protocol to limit the number of unsuccessful computer starts, you can set a timeout after the password has been on the screen for a certain period of time, or limit the number of attempts to enter the wrong password.

You can set a time limit to restart the computer after the previous work cycle, if the computer was in the “frozen state” for one or two weeks, restrict access to the computer for a period of time when you are going to go abroad - you are blocking it for as long as you are the road to unlock no sooner than you get to the hotel.

You can also do some fun things, for example, leave little canaries on a disk that contains critical data from a security point of view. In fact, these will simply be “stretch marks”, the triggering of which will lead to a change in the values ​​of the monotone counter inside the TPM.

You can also create a self-destruct password or force code to automatically execute a reset command. Since an attacker can attack in two ways: hack into a trusted platform module or launch malicious software, you can make him play by these rules and actually perform effective self-destruction.

The trusted platform module is specifically designed to make it very difficult to copy, so it is not possible to simply clone it. That way, you can use things like monotone counters to detect any recovery or playback attacks. And as soon as the “clear” command is executed in TPM, the attacker who wants to gain access to your data will end the game.
There are some similarities with the system that Jacob Applebaum discussed at the Chaos Communication Congress many years ago, in 2005. He suggested using a remote network server to implement many of these options, but acknowledged that it would be difficult to use in practice. Since TPM is an integrated component of the system, you can get many benefits only through the built-in TPM module, and not a module located on a remote server. Potentially possible hybrid approach. You could set up a system, say, like in the IT department, when you temporarily block the system, and it can become available only after you connect it to the network, call your IT administrator, and he will unblock it. I hesitate to expose the network stack at the beginning of the boot process, simply because that it significantly increases the attack surface. But it is still possible.

I want to clarify that the attacker can only do this, assuming that he will not be able to easily break the TPM. The next slide shows a snapshot of the TPM chip design, made by Chris Tarnovsky with a microscope. Chris spoke at DefCon last year and a few years ago gave a presentation at the BlackHat conference about TPM security.
He really did a lot of work to understand how difficult it is to break this thing. He listed the countermeasures, found out what it would take to actually break this thing, and then tested the entire chip. There are light detectors, active grids on the TPM board, various completely crazy circuits are implemented to mislead the attacker as to what this module actually does.

But if you spend enough time and resources and are careful enough, you can bypass most of the protective measures. You will be able to remove the chip, place it with an electron microscope in a workstation, find where the tire with unencrypted data is located and extract all secrets from it. Nevertheless, such an attack, even if you thoroughly prepared for it and figure out what is located using an expensive microscope, would still take time and effort to eliminate the chip's physical protection and not accidentally “fry” it during dismantling. .

Consider a restart attack. I mentioned earlier that in almost all cases TPM is a separate chip on the motherboard. This is a very low link in the system hierarchy. It is not part of the CPU, as is done with DRM in video consoles. Therefore, if the hacker succeeds in restarting the TPM, it will not have an irreversible effect on the system. This is bad, because such an attack may go unnoticed by you.

This is usually a chip that is outside the LPC computer bus, which itself is an outdated bus and is located outside the south bridge of the motherboard. In modern systems, the only things located on the surface of motherboards are TPM, BIOS module, keyboard controllers, but I think that in fact flexible controllers are no longer used. And if you find a way to restart the bus with a small number of contacts, you will reset the TPM to the “fresh operating system” boot state. You will probably lose access to the keyboard via the PS / 2 connector, but this is not a big problem, but you will be able to reproduce the TPM boot sequence, in which the secret data is “sealed” without actually performing the secure sequence, and you can use this to extract the data.

There are several attacks that try to use this method. If TPM uses the old mode called Static Root of Trust Measurement (SRTM), then you can do it quite easily. I have not seen any research about the successful attacks against new reliable technologies to execute the activation options for the Intel module. It is probably still possible to capture the LPC bus and what it sends to the CPU, is an area that needs more research. This can be another way to attack a trusted platform module.
So, let's look at the scheme of what we should have to cold boot the system with a reliable configuration. There are many rather vulnerable components in PC architecture.

For example, in the BIOS, you can capture a table of interrupt vectors and modify disk read permissions, or intercept keyboard input, disguise all functions of the CPU registers — there are many attack options. In my opinion, you do not need to do a security check in the real BIOS boot mode, you just need to measure the performance of the boot process.

As soon as you enter the “pre-boot” mode, which is actually just your operating system, such as the initial Linux RAM disk, you begin to run your protocol and do these things. I mean, as soon as you start using the resources of the operating system, what someone does at the BIOS level, operating with the interrupt table, will not affect you in any way. You really won't care.

You can check the performance of registers. For example, if you work with a Core i5 processor, then you know that it will support such things as the execution inhibit bit, debug registers and other things that people may try to disguise in the possibilities of registers.

This slide shows what the layout of the system running in the running configuration should look like.

There was a project called BitVisor that implemented many aspects of disk encryption security using the processor registers and the IOMMU protection in your main memory. The problem is that BitVisor is a rather specific and rarely used program.
Xen is a kind of open source canonical hypervisor that participates in many security studies, during which people were convinced that it worked. In my opinion, we need to use the Xen hypervisor as the bare-level hardware interface, and then add the Linux administrative domain dom0 to it to initialize your hardware.

Again, in Xen, all of your virtualized domains run in non-privileged mode, so you don’t actually have direct access to the debug registers, this is one of the things that has already been done. Xen provides hypercalls that give you access to such things, but this feature can be turned off in the software.

So, the approach that I use is that we place the master key in the debug registers. We allocate the first two debug registers to store the 128-bit AES key, which is our master key.

This thing never leaves the CPU registers after it is entered by a process that accepts user credentials. Then we use the two second registers as specific registers of the virtual machine — they can be used as ordinary debug registers or, as in this case, we can use them to encrypt the main memory. In this particular case, we need to have several devices that are directly connected to the administrative domain. This graphics processor, which is a PCI device, keyboard, TPM — all of this must be directly accessible.

You cannot use IOMMU protection for these things, but you can configure this protection for the network controller, storage controller, arbitrary devices on the PCI bus, that is, for components that have no access to the administrative domain or hypervisor memory spaces. You can access things like a network by actually placing a network controller in dedicated Net VMs. These things will be mapped to specific devices that have an IOMMU security configured, so that such a device can access only the memory area of ​​this virtual machine.

You can do the same with the Storage Controller, and then run all applications on APP VM virtual machines with absolutely zero direct access to the hardware. Thus, even if someone takes possession of your web browser or sends you a malicious PDF file, he will not receive anything that would seriously compromise disk encryption.

I can not take responsibility for this architectural design, because in fact it is the basis of a great project called Qubes OS.

Its developers describe this project as a pragmatic formation of Xen, Linux, and several user tools for doing many things that I just mentioned. Qubes OS implements the policy of unprivileged guests and creates a unified system environment, so that it seems that you are working with one system, but in fact it is a bunch of different virtual machines "under the same hood." I use this idea to implement my codebase.

So, the tool that I am developing is an experimental code confirming this concept, I called it Phalanx. This is a patched Xen that allows you to implement disk encryption according to the technology I described.

The master key is located in the first 2 debug registers of the DR1-2, the second two debug registers of the DR2-3 are absolutely not limited to domU. For security reasons, the XMM 0-12 registers used as the operating memory, the DR2-3 and the key are encrypted when the context switches by the virtual machine. I also made a very simple implementation of encryption using the Linux kernel module zRAM, because it is an embedded element that does almost everything except cryptography, so for encryption I just added a very small piece of code on top of it. As you know, the most secure code is code that you do not need to write. A good feature of zRAM is that it provides you with a bunch of bits that are needed to securely implement things like AES Counter-Mode.

We have several hardware requirements. You need a system that supports the new AES instructions, which are fairly common, but not every system has them. Most likely, if you have an Intel i5 or i7 processor, these instructions are supported.

But the rest of the "iron" must be checked to make sure that it supports all the necessary functions. HVE virtualization hardware extensions became widespread around 2006. It will be a little harder to find a computer with IOMMU. This is not specified in the specification of the system unit, and you will need to delve into its characteristics, and also find out what is the difference between VTX and VTD and so on. So, you may have to look for a system that supports these things. And, of course, you need a system with a TPM TPM module, because otherwise you will not be able to measure the load indicators at all. You usually look at business class computers where you can check for the presence of necessary components. If you find Intel TXT with Trusted Execution technology, then it will have almost everything you need.

So, to ensure security, we have several assumptions about certain components of the system. TRM, of course, is a very important component to ensure the integrity of the download. You need to make sure that there is no backdoor that can reset NVRAM, manipulate monotone counters, or make the system think that it is using a trusted state, although in reality it is not. Based on the comments of Tarnowski, who performed the reverse engineering of these chips, I set a limit of approximately 12 hours of exclusive access to the computer, which is required if you want to make a TPM attack on him to get all the secrets.


There are several assumptions regarding the processor, memory controller and IOMMU, mainly regarding the fact that they are not cracked and correctly implement their functions. Some of these assumptions do not have to be very strict, because Intel can easily bypass some of these things, and we won’t find a way to find out.

Some of the security assumptions concern Xen. It is a piece of software that actually has a very powerful security system, but nothing is perfect, and sometimes vulnerabilities even occur in a secure system. Given that Xen has a privileged position in the system, it is very important to make sure that it is in a safe state.
Thus, with such security assumptions, we have a kind of basis for a threat model. We want to conduct a realistic threat assessment, understanding that not every system is invulnerable, especially when there are so many legacy components that have been developed without any consideration of security. But at the same time, not all theoretical attacks are feasible in practice, and you cannot combine very simple and very complex hardware attacks. However, it should be remembered that our assumptions may be incorrect.
I think a good analogy is the security of a regular safe. We all know that every safe can eventually be broken, the question is how much time do you have for reverse engineering, what is your time margin for hacking.

I think we need to think about our systems in the context of physical protection in terms of hours, not minutes, which we have right now. And, as always, if I screwed up, if I made the wrong assumption - prove it, recheck me to make sure I am right or wrong.

Expected safety is what you really get. A cold boot attack will not be effective against FDE keys and user information encrypted in RAM.

Hardware capture of RAM will not be effective, because it will be isolated in the IOMMU sandbox, and such capture will not allow mastering the state of the application or the state of the system. Even if you plan to extract secrets from the TPM NVRAM trusted platform module, all you have to do is return to its original state, and although it is easy to break, you will still come to zero.

I admit that if you have a good habit of checking security, you will be able to detect someone else’s interference with your computer if you left it unattended for at least 12 hours. As long as you are alert enough, you'll be fine.

There are several basic attack methods that I would use when trying to hack the system. Effective protection against keyloggers still does not exist, and even the use of disposable tokens will be an imperfect protection.

The previously mentioned TPM attacks are quite dangerous - removing NVRAM or intercepting / resetting LPC bus equipment. You can find a way to trick the TPM into a relatively safe configuration, which, in his opinion, is trustworthy, but in fact is not trusted.

RAM memory manipulations also threaten security. If you have something that looks like RAM and behaves like RAM, but in fact it is not, because it has been adversely affected from the outside, you cannot do anything about it. An attacker can try things like a temporary impulse download, with which George Hots broke the hypervisor defense of the Sony PS3 game console.

Since I am not a lawyer, I will very briefly mention the legal aspects of the problem. As far as I know, the self-destruction of the system is not illegal. This is illegal in some countries where you cannot use a trusted platform module and strong encryption, like, say, in China, and you also cannot use TPM in Russia. In some countries, such as the United Kingdom, the disclosure of the encryption key is mandatory, and you can go to jail if you do not disclose your key at the request of RIPA - the UK Investigative Act to allow interception of communications.
I will tell you a little about my future work and improvements. The version of my program is not yet stable, for example, if you put your computer into sleep mode, my program may begin to erase your data. I am currently working on a solution to this problem.

There is something else that may be interesting to do in the future. Since OpenSSL keys are a really interesting and important thing, I'm going to develop an API that allows you to quickly change the contents of the memory.

I'm also going to think about the easy-to-install version of the Qubes OS based system.

From my speech, we can draw the following conclusions: even the best security model in the world cannot be used if it is unsuitable for use. The security model should take into account the possibility of its practical use in real conditions.

Disk encryption alone is not enough - real protection comes with full encryption of the entire system.

System encryption requires the appropriate hardware, but it is in any case better than the current status quo. It's hard to do, but I think it is possible, and we should try it. Thanks for attention!

Thank you for staying with us. Do you like our articles? Want to see more interesting materials? Support us by placing an order or recommending to friends, 30% discount for Habr's users on a unique analogue of the entry-level servers that we invented for you: The whole truth about VPS (KVM) E5-2650 v4 (6 Cores) 10GB DDR4 240GB SSD 1Gbps from $ 20 or how to share the server? (Options are available with RAID1 and RAID10, up to 24 cores and up to 40GB DDR4).

VPS (KVM) E5-2650 v4 (6 Cores) 10GB DDR4 240GB SSD 1Gbps until spring for free if you pay for a period of six months, you can order here .

Dell R730xd 2 times cheaper? Only we have 2 x Intel Dodeca-Core Xeon E5-2650v4 128GB DDR4 6x480GB SSD 1Gbps 100 TV from $ 249in the Netherlands and the USA! Read about How to build an infrastructure building. class c using servers Dell R730xd E5-2650 v4 worth 9000 euros for a penny?

Also popular now: