DEFCON 21. Passwords alone are not enough, or why disk encryption “breaks down” and how it can be fixed. Part 1
Thank you all for coming, today we will talk about full disk encryption (FDE), which is not as secure as you think. Raise your hands, who encrypts the HDD of your computer this way. Amazing Well, welcome to DefCon!
It appears that 90% of you use open source software to encrypt a disk in order to be able to audit them. Now let those who completely turn off the computer raise their hands if they leave it unattended. I think about 20% of those present. Tell me, and who generally leaves your computer unattended for a few hours, doesn’t it turn on or off? Consider that I ask these questions, just to make sure that you are not a zombie and do not sleep. I think that almost everyone had to leave their computer for at least a few minutes.
')
So why do we encrypt our computers? It is difficult to find someone who would ask this question, so I think it is really important to formulate the motivation of specific actions in the field of security. If we do not do this, we will not be able to understand how to organize this work.
There is a lot of documentation on software that encrypts a disk, which describes what the software does, what algorithms it uses, which passwords, and so on, but almost never says why.
So, we encrypt our computer because we want to control our data, we want to guarantee their confidentiality and that no one can steal or change it without our knowledge. We want to decide for ourselves how to deal with our data and control what happens to it.
There are situations where you simply must ensure the secrecy of data, for example, if you are a lawyer or a doctor who has confidential client information. The same applies to financial and accounting documentation. Companies are obliged to inform customers about the leakage of such information, for example, if someone left an unprotected laptop in a car that was hijacked, and now this confidential information may be freely available on the Internet.
In addition, you need to control the physical access to the computer and ensure that it is protected from physical impact, because FDE will not help if someone physically takes over your computer.
If we want to secure the network, we need to control access to the end user's computer. We will not be able to build a secure Internet without ensuring the security of each end user.
So, we have dealt with the theoretical aspects of the need for disk encryption. We know how to generate random numbers to secure keys, how to control block encryption modes used for full disk encryption, how to securely inherit a key for passwords, so we can assume that “mission accomplished”, as President Bush said, speaking on board aircraft carrier. But you know that this is not the case, and we still have a lot to do to complete it.
Even if you have flawless cryptography and you know that it is almost impossible to crack it, in any case it should be implemented on a real computer, where you have no analogs of reliable black boxes. An attacker does not need to attack cryptography if he tries to crack the full disk encryption. To do this, he just needs to attack the computer itself or somehow deceive the user, convincing him to provide the password, or use a keylogger, etc.
The actual use of encryption does not match the FDE security model. If we consider software designed for full disk encryption, it can be seen that its creators paid a lot of attention to the theoretical aspects of encryption. I will quote an excerpt from the technical documentation from the TrueCrypt website: “Our program will not protect any data on the computer if the attacker has physical access to the computer before starting or during TrueCrypt operation.”
In principle, their entire security model looks like this: “if our program correctly encrypts a disk and correctly decrypts it, we did our job.” I apologize for the text shown on the next slide, if you find it difficult to read it, I will do it myself. These are excerpts from the correspondence between the developers of TrueCrypt and security researcher Joanna Rutkowska about the attacks of the janitor.
TrueCrypt: “We never consider the possibility of hardware attacks, we just assume the worst. Once the attacker has “worked” on your computer, you just have to stop using it to store confidential information. The TPM crypto processor is not able to prevent hardware attacks, for example, using keyloggers.
Joanna Rutkovskaya asked them: “How can you determine whether the attacker“ worked ”on your computer or not, because you don’t carry a laptop with you all the time?”, To which the developers replied: “We don’t care how the user ensures safety and security your computer. For example, a user could use a lock or place a laptop while in his absence in a lockable cabinet or safe. ” Joanna answered them very correctly: “If I am going to use a lock or safe, why do I need your encryption at all”?
Thus, ignoring the possibility of such an attack is a hoax, we cannot do that! We live in the real world, where these systems exist, with which we interact and which we use. There is no way to compare 10 minutes of attack, performed only with the help of software, for example, from a "flash drive", with something that you can perform by manipulating the system solely with the help of hardware.
Thus, regardless of what they say, physical security and resistance to physical attacks depends on FDE. It does not matter what you give up on your security model, and, at least, if they don’t want to take responsibility, they should be very clear and honest about how you can easily break the protection they offer.
The next slide shows the scheme for downloading abstract FDE, which is used in most modern computers.
As we know, the bootloader is loaded from the SSD / HDD using the BIOS and copied to main memory on the data transfer path. Storage Controller - PCI Bus - Platform Controller Hub. The bootloader then prompts the user for authentication data, such as a password or a smart card key. Next, the password goes from the keyboard to the processor, after which the loader takes control, with both components — the OS and the key — remaining in memory in order to ensure the transparency of the disk encryption and decryption process. This is an idealized view of the process, suggesting that no one will try to interfere in it in any way. I think you know perfectly well how to hack it, so let's list the things that can go wrong if someone tries to attack you. I divide the attacks into 3 levels.
The first is non-invasive, not requiring the capture of your computer, as it is done with a flash drive with malware. You do not need to “disassemble” the system if you can easily connect to it any hardware component such as a PCI card, Express Card or Thunderbolt — the newest Apple adapter that provides open access to the PCI bus.
A second-level attack will require a screwdriver, because you may need to temporarily remove some component of the system to deal with it in your own little environment. The third level, or “soldering iron attack,” is the most difficult, here you physically either add or modify system components, such as chips, to try to crack them.
One type of first-level attack is a compromised bootloader, also known as the evil maid attack, where you need to execute some unencrypted code as part of the system boot process, something you can download yourself using the user's personal information in order to get access to the rest of the data encrypted on your hard drive. There are several different ways to do this. You can physically change the boot loader in the storage system. You can compromise the BIOS or download a malicious BIOS that will take control of the keyboard adapter or disk reading procedures and modify them so that they are resistant to removing the hard disk. But in any case, you can modify the system so that when the user enters his password, he will be recorded on the disk in an unencrypted form, or do something similar, it will not be difficult for the hacker.
You can do something similar at the operating system level. This is especially true if you are not using full disk encryption, but container encryption.
This can also occur when an exploit is attacked by a system, thanks to which the attacker gets root rights and can read the key from the main memory, this is a very common attack method. This key can be stored on the hard disk as plain text for later use by the attacker or sent over the network to Command & Control.
Another possibility is keyboard interception using a keylogger, be it software, hardware, or something exotic, such as a needle-eye camera or, for example, a microphone that records sounds accompanying keystrokes by the user and tries to figure out what keys. It is difficult to prevent such an attack, because it potentially includes components that are outside the system.
I would also like to mention data recovery attacks, better known as Cold Boot Attack “cold boot attacks”. If 5 years ago you asked even people who were very computer-savvy about the security characteristics of the main memory, they would say that when the power is turned off, the data disappears very quickly.
But in 2008, excellent research was published by Princeton, who found that in fact, even at room temperature, there was very little data loss in RAM memory for a few seconds. And if you cool the module to cryogenic temperatures, you can get a few minutes, during which only a slight degradation of data occurs in the main memory.
Thus, if your key is in the main memory and someone has removed the modules from your computer, they can attack your key by finding out where it is in the main memory in the clear. There are certain methods to counter this at the hardware level, for example, forcing the memory contents to be cleared when the power is turned off or when the computer is restarted, but this does not help if someone simply pulls out the module and places it in another computer or in a dedicated piece of equipment to extract the contents of its memory.
Finally, there is the possibility of direct memory access. Any PCI device in your computer can, in normal mode, read and write the contents of any sector to the main memory. They can do anything.
This was developed even when the computers were much slower and we didn’t want the CPU to “nurse” with each data transfer to the device from the main memory. Thus, devices get direct memory access, the processor can issue commands to them that they can simply complete, but the data will remain in memory whenever you need it.
This is a problem because PCI devices can be reprogrammed. Many of these things have a writeable firmware, which you can just reflash to something hostile. And this may jeopardize the security of the entire operating system, as it will allow to carry out any form of attack, even modify the OS itself, or remove the key directly. In computer forensics, there is equipment designed for such things in the process of investigating crimes: they connect something to your computer and pull out the contents of the memory. You can do this with FireWire, ExpressCard, or Thunderbolt ... In fact, all these are external ports that provide access to the internal system bus.
So, it would be nice if you could not store the key in RAM, because we sort of showed that the RAM is not very reliable from a security point of view. Is there any dedicated keystore or special cryptographic equipment? Yes there is. You can use cryptographic accelerators for a web server to process more SSL transactions per second. They are resistant to unauthorized interference. CA certificate authorities have things that keep them completely secret keys, but in fact they are not intended for such high-performance operations as using disk encryption. So are there any other options?
Can we use the processor as a kind of pseudo-hardware crypto module? Can we calculate something like a symmetric AES block cipher algorithm in the CPU, using instead of RAM only something like CPU registers?
Intel and AMD have added great new instructions to their processors that have taken on the job of performing AES, so now you can perform primitive block encryption operations with just one simple assembly instruction. The question is, can we keep our key in memory, or can we perform this process without relying on the main memory? In modern x86 processors there is a rather large set of registers, and if one of you really tried to add all the bits that are in these, it turns out about 4 kilobytes. Thus, we can actually use some CPUs to store keys and create space to perform encryption operations.
One possibility is the use of hardware debug point registers. In a typical Intel processor, there are 4 such registers, and in the x64 system, each of them will contain a 64-bit pointer. This is 256 bits of potential disk space that most people will never use. Of course, the advantage of using debug registers is their privilege, because only the operating system can access them. There are other nice benefits here, for example, if you turn off the power of the processor when you turn off the system or go into sleep mode, you really lose all the contents of the register, so you can not be afraid of a “cold reset”.
The guy from Germany, Tilo Muller, implemented this similar thing called TRESOR for Linux in 2011. He tested the performance of such a system and concluded that it works no slower than with regular calculation of AES software.
How about storing two 128-bit keys instead of one key? This will lead us to a larger crypto module space. We can store one master key that never leaves the processor when it is loaded, and then load and unload the key versions we need to perform additional operations and solve additional tasks.
The problem is that we can keep our code or our keys out of the main memory, but the CPU will still handle the contents of the memory anyway. Thus, the use of DMA, direct memory access technology, bypassing the central processor, or other manipulations, allows you to change the operating system and keep its dump outside the main memory registers, or, if more exotic methods are used, outside the debug registers.
Can we do something with a DMA angle of attack? As it turned out, yes, we can. Recently, as part of new technologies to increase server virtualization, for performance reasons, people like to be able to connect, say, a network adapter to a virtual server, so it must be connected through a hypervisor.
The IOMMU technology has been designed in such a way that you can isolate a PCI device in your own small memory section, from where it cannot read and write arbitrarily anywhere in the system. This is ideal: we can configure the IOMMU permissions to protect our operating system or what we use to process keys, and protect them from random access.
Again, our friend from Germany, Tilo Muller, implemented the TRESOR version on a microbit bit called BitVisor, which does this. This allows you to run a separate operating system and transparently accesses disk encryption, and it's great that you do not need to take care of it or know something about it. , , IOMMU , - .
, , , , , . , – , .
, , . , RAM , , . , , , , SSH-, PGP-, « », .
: RAM? , , , , .
, , , – , ! 2010 RAM. — : “clear”, , , . 10-50 . , , , -, – 10% . , . , , ? , TPM , , , .
-, , . , , - CPU.
, . , , , . , , - . , ? , . ? , - , , , “ ” , .
, . , , . — Trusted Platform Module – , . , , , , TPM . , «» , . , , . , , .
? -. - , - «» , . , .
, – -, . , RSA/SHA1, , , - . - , . , .
23:10
DEFCON 21. , «» . Part 2
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?
It appears that 90% of you use open source software to encrypt a disk in order to be able to audit them. Now let those who completely turn off the computer raise their hands if they leave it unattended. I think about 20% of those present. Tell me, and who generally leaves your computer unattended for a few hours, doesn’t it turn on or off? Consider that I ask these questions, just to make sure that you are not a zombie and do not sleep. I think that almost everyone had to leave their computer for at least a few minutes.
')
So why do we encrypt our computers? It is difficult to find someone who would ask this question, so I think it is really important to formulate the motivation of specific actions in the field of security. If we do not do this, we will not be able to understand how to organize this work.
There is a lot of documentation on software that encrypts a disk, which describes what the software does, what algorithms it uses, which passwords, and so on, but almost never says why.
So, we encrypt our computer because we want to control our data, we want to guarantee their confidentiality and that no one can steal or change it without our knowledge. We want to decide for ourselves how to deal with our data and control what happens to it.
There are situations where you simply must ensure the secrecy of data, for example, if you are a lawyer or a doctor who has confidential client information. The same applies to financial and accounting documentation. Companies are obliged to inform customers about the leakage of such information, for example, if someone left an unprotected laptop in a car that was hijacked, and now this confidential information may be freely available on the Internet.
In addition, you need to control the physical access to the computer and ensure that it is protected from physical impact, because FDE will not help if someone physically takes over your computer.
If we want to secure the network, we need to control access to the end user's computer. We will not be able to build a secure Internet without ensuring the security of each end user.
So, we have dealt with the theoretical aspects of the need for disk encryption. We know how to generate random numbers to secure keys, how to control block encryption modes used for full disk encryption, how to securely inherit a key for passwords, so we can assume that “mission accomplished”, as President Bush said, speaking on board aircraft carrier. But you know that this is not the case, and we still have a lot to do to complete it.
Even if you have flawless cryptography and you know that it is almost impossible to crack it, in any case it should be implemented on a real computer, where you have no analogs of reliable black boxes. An attacker does not need to attack cryptography if he tries to crack the full disk encryption. To do this, he just needs to attack the computer itself or somehow deceive the user, convincing him to provide the password, or use a keylogger, etc.
The actual use of encryption does not match the FDE security model. If we consider software designed for full disk encryption, it can be seen that its creators paid a lot of attention to the theoretical aspects of encryption. I will quote an excerpt from the technical documentation from the TrueCrypt website: “Our program will not protect any data on the computer if the attacker has physical access to the computer before starting or during TrueCrypt operation.”
In principle, their entire security model looks like this: “if our program correctly encrypts a disk and correctly decrypts it, we did our job.” I apologize for the text shown on the next slide, if you find it difficult to read it, I will do it myself. These are excerpts from the correspondence between the developers of TrueCrypt and security researcher Joanna Rutkowska about the attacks of the janitor.
TrueCrypt: “We never consider the possibility of hardware attacks, we just assume the worst. Once the attacker has “worked” on your computer, you just have to stop using it to store confidential information. The TPM crypto processor is not able to prevent hardware attacks, for example, using keyloggers.
Joanna Rutkovskaya asked them: “How can you determine whether the attacker“ worked ”on your computer or not, because you don’t carry a laptop with you all the time?”, To which the developers replied: “We don’t care how the user ensures safety and security your computer. For example, a user could use a lock or place a laptop while in his absence in a lockable cabinet or safe. ” Joanna answered them very correctly: “If I am going to use a lock or safe, why do I need your encryption at all”?
Thus, ignoring the possibility of such an attack is a hoax, we cannot do that! We live in the real world, where these systems exist, with which we interact and which we use. There is no way to compare 10 minutes of attack, performed only with the help of software, for example, from a "flash drive", with something that you can perform by manipulating the system solely with the help of hardware.
Thus, regardless of what they say, physical security and resistance to physical attacks depends on FDE. It does not matter what you give up on your security model, and, at least, if they don’t want to take responsibility, they should be very clear and honest about how you can easily break the protection they offer.
The next slide shows the scheme for downloading abstract FDE, which is used in most modern computers.
As we know, the bootloader is loaded from the SSD / HDD using the BIOS and copied to main memory on the data transfer path. Storage Controller - PCI Bus - Platform Controller Hub. The bootloader then prompts the user for authentication data, such as a password or a smart card key. Next, the password goes from the keyboard to the processor, after which the loader takes control, with both components — the OS and the key — remaining in memory in order to ensure the transparency of the disk encryption and decryption process. This is an idealized view of the process, suggesting that no one will try to interfere in it in any way. I think you know perfectly well how to hack it, so let's list the things that can go wrong if someone tries to attack you. I divide the attacks into 3 levels.
The first is non-invasive, not requiring the capture of your computer, as it is done with a flash drive with malware. You do not need to “disassemble” the system if you can easily connect to it any hardware component such as a PCI card, Express Card or Thunderbolt — the newest Apple adapter that provides open access to the PCI bus.
A second-level attack will require a screwdriver, because you may need to temporarily remove some component of the system to deal with it in your own little environment. The third level, or “soldering iron attack,” is the most difficult, here you physically either add or modify system components, such as chips, to try to crack them.
One type of first-level attack is a compromised bootloader, also known as the evil maid attack, where you need to execute some unencrypted code as part of the system boot process, something you can download yourself using the user's personal information in order to get access to the rest of the data encrypted on your hard drive. There are several different ways to do this. You can physically change the boot loader in the storage system. You can compromise the BIOS or download a malicious BIOS that will take control of the keyboard adapter or disk reading procedures and modify them so that they are resistant to removing the hard disk. But in any case, you can modify the system so that when the user enters his password, he will be recorded on the disk in an unencrypted form, or do something similar, it will not be difficult for the hacker.
You can do something similar at the operating system level. This is especially true if you are not using full disk encryption, but container encryption.
This can also occur when an exploit is attacked by a system, thanks to which the attacker gets root rights and can read the key from the main memory, this is a very common attack method. This key can be stored on the hard disk as plain text for later use by the attacker or sent over the network to Command & Control.
Another possibility is keyboard interception using a keylogger, be it software, hardware, or something exotic, such as a needle-eye camera or, for example, a microphone that records sounds accompanying keystrokes by the user and tries to figure out what keys. It is difficult to prevent such an attack, because it potentially includes components that are outside the system.
I would also like to mention data recovery attacks, better known as Cold Boot Attack “cold boot attacks”. If 5 years ago you asked even people who were very computer-savvy about the security characteristics of the main memory, they would say that when the power is turned off, the data disappears very quickly.
But in 2008, excellent research was published by Princeton, who found that in fact, even at room temperature, there was very little data loss in RAM memory for a few seconds. And if you cool the module to cryogenic temperatures, you can get a few minutes, during which only a slight degradation of data occurs in the main memory.
Thus, if your key is in the main memory and someone has removed the modules from your computer, they can attack your key by finding out where it is in the main memory in the clear. There are certain methods to counter this at the hardware level, for example, forcing the memory contents to be cleared when the power is turned off or when the computer is restarted, but this does not help if someone simply pulls out the module and places it in another computer or in a dedicated piece of equipment to extract the contents of its memory.
Finally, there is the possibility of direct memory access. Any PCI device in your computer can, in normal mode, read and write the contents of any sector to the main memory. They can do anything.
This was developed even when the computers were much slower and we didn’t want the CPU to “nurse” with each data transfer to the device from the main memory. Thus, devices get direct memory access, the processor can issue commands to them that they can simply complete, but the data will remain in memory whenever you need it.
This is a problem because PCI devices can be reprogrammed. Many of these things have a writeable firmware, which you can just reflash to something hostile. And this may jeopardize the security of the entire operating system, as it will allow to carry out any form of attack, even modify the OS itself, or remove the key directly. In computer forensics, there is equipment designed for such things in the process of investigating crimes: they connect something to your computer and pull out the contents of the memory. You can do this with FireWire, ExpressCard, or Thunderbolt ... In fact, all these are external ports that provide access to the internal system bus.
So, it would be nice if you could not store the key in RAM, because we sort of showed that the RAM is not very reliable from a security point of view. Is there any dedicated keystore or special cryptographic equipment? Yes there is. You can use cryptographic accelerators for a web server to process more SSL transactions per second. They are resistant to unauthorized interference. CA certificate authorities have things that keep them completely secret keys, but in fact they are not intended for such high-performance operations as using disk encryption. So are there any other options?
Can we use the processor as a kind of pseudo-hardware crypto module? Can we calculate something like a symmetric AES block cipher algorithm in the CPU, using instead of RAM only something like CPU registers?
Intel and AMD have added great new instructions to their processors that have taken on the job of performing AES, so now you can perform primitive block encryption operations with just one simple assembly instruction. The question is, can we keep our key in memory, or can we perform this process without relying on the main memory? In modern x86 processors there is a rather large set of registers, and if one of you really tried to add all the bits that are in these, it turns out about 4 kilobytes. Thus, we can actually use some CPUs to store keys and create space to perform encryption operations.
One possibility is the use of hardware debug point registers. In a typical Intel processor, there are 4 such registers, and in the x64 system, each of them will contain a 64-bit pointer. This is 256 bits of potential disk space that most people will never use. Of course, the advantage of using debug registers is their privilege, because only the operating system can access them. There are other nice benefits here, for example, if you turn off the power of the processor when you turn off the system or go into sleep mode, you really lose all the contents of the register, so you can not be afraid of a “cold reset”.
The guy from Germany, Tilo Muller, implemented this similar thing called TRESOR for Linux in 2011. He tested the performance of such a system and concluded that it works no slower than with regular calculation of AES software.
How about storing two 128-bit keys instead of one key? This will lead us to a larger crypto module space. We can store one master key that never leaves the processor when it is loaded, and then load and unload the key versions we need to perform additional operations and solve additional tasks.
The problem is that we can keep our code or our keys out of the main memory, but the CPU will still handle the contents of the memory anyway. Thus, the use of DMA, direct memory access technology, bypassing the central processor, or other manipulations, allows you to change the operating system and keep its dump outside the main memory registers, or, if more exotic methods are used, outside the debug registers.
Can we do something with a DMA angle of attack? As it turned out, yes, we can. Recently, as part of new technologies to increase server virtualization, for performance reasons, people like to be able to connect, say, a network adapter to a virtual server, so it must be connected through a hypervisor.
The IOMMU technology has been designed in such a way that you can isolate a PCI device in your own small memory section, from where it cannot read and write arbitrarily anywhere in the system. This is ideal: we can configure the IOMMU permissions to protect our operating system or what we use to process keys, and protect them from random access.
Again, our friend from Germany, Tilo Muller, implemented the TRESOR version on a microbit bit called BitVisor, which does this. This allows you to run a separate operating system and transparently accesses disk encryption, and it's great that you do not need to take care of it or know something about it. , , IOMMU , - .
, , , , , . , – , .
, , . , RAM , , . , , , , SSH-, PGP-, « », .
: RAM? , , , , .
, , , – , ! 2010 RAM. — : “clear”, , , . 10-50 . , , , -, – 10% . , . , , ? , TPM , , , .
-, , . , , - CPU.
, . , , , . , , - . , ? , . ? , - , , , “ ” , .
, . , , . — Trusted Platform Module – , . , , , , TPM . , «» , . , , . , , .
? -. - , - «» , . , .
, – -, . , RSA/SHA1, , , - . - , . , .
23:10
DEFCON 21. , «» . Part 2
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/435176/
All Articles