DEFCON 21. Passwords alone are not enough, or why disk encryption “breaks down” and how it can be fixed. Part 2
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 was not hacked, before it is authenticated on the computer and will start using 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 by 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 safely 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, it will never be perfect.
I mentioned that in TPM there is a self-erase command, which can be executed through software. Because TPM requires a specific 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 failed 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 a “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 funny things, for example, leave small 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 a forced code to automatically execute the 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 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 made a presentation at the BlackHat conference about TPM security a few years ago.
He really did a lot of work to understand how hard it is to break this thing. He listed countermeasures, found out what it would take to actually break this thing, and then tested the entire microchip. 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 at the same time 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 the 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 a lot of 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 can 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 download 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, this 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 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 capabilities of the 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 is involved in many security studies, during which people were convinced that it worked. In my opinion, we need to use the Xen hypervisor as a bare-level hardware interface, and then add the Linux dom0 administrative domain 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 things like this, 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 GPU, 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 a 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 the network controller in dedicated Net VMs. These things will be mapped to specific devices that have an IOMMU configured for protection, 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 the applications on the 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 2 first 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 operating memory, the DR2-3 and key are encrypted when the context switches by the virtual machine. I also made a very simple encryption implementation using the zRAM Linux kernel module, 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 you, of course, 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, it will have almost everything you need. The Qubes team on its wiki presents an excellent hardware compatibility list, which lists details for many systems implementing such things.
So for security, we have several assumptions about some of the 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 hacked 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. This 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 sort of basis for a threat model. , , , , - . , . , .
, – . , , , , .
, , , . , , , — , , , .
— , . FDE , RAM.
, IOMMU, . TPM NVRAM, , – , , .
, , , 12 . , .
, , . , .
TPM — NVRAM, / LPC. TPM , , , , .
RAM . , RAM RAM, , , . , , Sony PS3.
, . , . , , , , , TPM . , , , , , RIPA – , .
. , , , . .
-, . OpenSSL , API, .
Qubes OS.
: , . .
– .
, , -. , , , . 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 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 $ 249 in 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?
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 was not hacked, before it is authenticated on the computer and will start using 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 by 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 safely 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, it will never be perfect.
I mentioned that in TPM there is a self-erase command, which can be executed through software. Because TPM requires a specific 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 failed 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 a “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 funny things, for example, leave small 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 a forced code to automatically execute the 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 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 made a presentation at the BlackHat conference about TPM security a few years ago.
He really did a lot of work to understand how hard it is to break this thing. He listed countermeasures, found out what it would take to actually break this thing, and then tested the entire microchip. 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 at the same time 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 the 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 a lot of 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 can 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 download 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, this 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 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 capabilities of the 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 is involved in many security studies, during which people were convinced that it worked. In my opinion, we need to use the Xen hypervisor as a bare-level hardware interface, and then add the Linux dom0 administrative domain 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 things like this, 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 GPU, 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 a 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 the network controller in dedicated Net VMs. These things will be mapped to specific devices that have an IOMMU configured for protection, 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 the applications on the 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 2 first 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 operating memory, the DR2-3 and key are encrypted when the context switches by the virtual machine. I also made a very simple encryption implementation using the zRAM Linux kernel module, 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 you, of course, 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, it will have almost everything you need. The Qubes team on its wiki presents an excellent hardware compatibility list, which lists details for many systems implementing such things.
So for security, we have several assumptions about some of the 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 hacked 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. This 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 sort of basis for a threat model. , , , , - . , . , .
, – . , , , , .
, , , . , , , — , , , .
— , . FDE , RAM.
, IOMMU, . TPM NVRAM, , – , , .
, , , 12 . , .
, , . , .
TPM — NVRAM, / LPC. TPM , , , , .
RAM . , RAM RAM, , , . , , Sony PS3.
, . , . , , , , , TPM . , , , , , RIPA – , .
. , , , . .
-, . OpenSSL , API, .
Qubes OS.
: , . .
– .
, , -. , , , . 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 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 $ 249 in 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?
Source: https://habr.com/ru/post/435178/
All Articles