Attack on mount control code of commercial disk encryption software and efficient countermeasure
TurboCrypt is the only OTFE (On-The-Fly-Encryption) software on the market featuring efficient protection against the Mount Control Attack. Our invention is a real competitive advantage over the entire competition. What is encryption good for if a simple attack can be mounted on a (poor) implementation?
View full paper as PDF here (0.1Mb)
Abstract
On-the-fly disk encryption software generally creates a virtual encrypted disk within a file and mounts it via a software driver as a real disk to the file system of a computer. In order to mount a virtual encrypted disk, a user interface application that is part of the software package, passes volume file path information, the selected encryption algorithm as well as the password to the software driver. By intercepting this so-called mount request, all required information to gain access to an encrypted volume is made available to an adversory in an extremely convenient way. In order to apply this side channel attack successfully, it is assumed that the adversory is able to manipulate the kernel of the targetted operating system – an assumption that is increasingly realistic in the political context of the first decade of the 21st century.
Introduction
In the classical attack scenario, commercial on-the-fly (OTFE) disk encryption software makes highly secure virtual volumes available to users since almost two decades. The classical attack scenario is mainly limited to an adversory who gets hold of encrypted volume image files e.g. by stealing a notebook computer that contains such encrypted image files. Currently available OTFE software has consequently been programmed to make attacks on volume image files very time-consuming e.g. by storing little or no plaintext information in such files in order to give the adversory no hint about the selected encryption algorithm, keys, etc..
Hackers are considered as a possible threat in some attack scenarios. In order to make the task of a hacker difficult, passwords are cached by some encryption software and buffers are overwritten with a fixed bit pattern prior to deallocating memory. No malicious software can thus get hold of possibly secret information by reallocating memory locations that had previously been used by the encryption driver or the user interface of an OTFE software.
None of the existing scenarios take into account that the operating system itself could contain malicious code.
Preferred targets in an operating system to log password information
Intelligence agencies, regardless of their provenience and regardless of their mission, are extremely well funded. A certain hunger for civillian information is evident when looking back at the first few years of the 21st century.
It is logical and highly likely that hackers or assigned organisations take advantage of all available synergy effects to maximize the effectiveness of their work.
It would certainly be an advantage if the manufacturer of an operating system from a certain country would cooperate with a certain intelligence agency. There exists no proof for this assumption, but the likelyhood for such two bodies to cooperate secretly is close to 100%.
Certain preconditions although need to be met:
• The attack needs to remain secret
• No or only little data transfer via wide area networks can take place as secrecy would otherwise be in danger
• High efficiency of the attack
• Only very valuable information is worth to be logged – above all other things: passwords as they are literally the key to valuable information
• Small size of the gathered information below any detection limit
These preconditions are very tough to meet.
As an example, popular keystroke loggers log a lot of useless information and attack efficiency is poor due to the fact that somebody who really wants to hide password information takes advantage of key files, virtual keyboards and USB tokens. Too much information needs to be buffered and data transfer of that much information via internet would be suspicious.
The logging of mouse movements, keystrokes, screen content, etc. proves to be rather inconvenient compared with logging MOUNT IO Control Codes:
Data encryption software is definitely a primary target for information loggers. Somebody who uses such software definitely wants to hide information from somebody else.
Vulnerability of such software is particularly high when passwords are being entered or when they are transmitted to a software driver. In order to mount a virtual encrypted disk, the user interface application of an OTFE (disk encryption) software passes volume file path information, the selected encryption algorithm as well as the password to a software driver.
The Windows operating system, as well as most or all other operating systems, provide only a single mechanism for doing this: the DeviceIoControl() function.
The DeviceIoControl() function is the ideal target
The DeviceIoControl() function, which is part of the Windows kernel, provides a device input and output control (IOCTL) interface through which an application can communicate directly with a device driver. The DeviceIoControl() function is a general-purpose interface that can send control codes to a variety of devices. Each control code represents an operation for the driver to perform. For example, a control code can ask a device driver to return information about the corresponding device, or direct the driver to carry out an action on the device, such as formatting a disk.
A number of standard control codes are defined in the Windows SDK header files. In addition, device drivers can define their own device-specific control codes.
Control codes consist of device type information, access mask, function code and method flag. As an example does the mount IOCTL 466944d = 00072000h define DeviceType 7 (=FILE_DEVICE_DISK), ‘any access’, function code 0c00h and that all data passed to the driver shall be buffered.
Any function code greater or equal 0800h = 2048d clearly identifies a user IOCTL. Function codes 0-2047 are reserved for Microsoft Corporation. A tamperared version of the DeviceIoControl() function could thus distinguish the MOUNT IOCTL from any other IOCTL in a timely fashion.
The PDF version of this document contains code fragments taken from source code of a disk encryption software. It shows how the data buffer for the MOUNT IOCTL is filled and how the DeviceIoControl() function is called.
View full paper as PDF here (0.1Mb)
Right after calling DeviceIoControl(), the programmer deletes the password section of the buffer he had passed to the DeviceIoControl() function (yellow color). He was obviously well aware that malicious code could later scan his buffer e.g. to gather password information.
As the programmer immediately overwrites and deletes the password buffer, it is obvious that he has a certain level of mistrust in the environment in which his software will later run. He obviously knows that it would be too easy for malicious software to allocate memory and to scan this memory for password information. He although trusts or has to trust the operating system. He willingly passes extremely sensitive information in the clear to the only function in the whole operating system that dispatches commands to drivers. He further uses a function code that most probably nobody else in this world shares with him.
All in all this is an ideal target for a hacker or an assigned organisation to gather first class secret informations. No other real-life attack comes with all of the following advantages:
- The operating system is not slowed down because only a few private function codes need to be analyzed.
- Password and volume information is available in a highly condensed plaintext format.
- Only very few informations need to be logged over weeks and months.
- Solely ultimately interesting information will ever be logged.
- There exists no work-around.
- Single source of data.
- Very low cost to implement the attack.
- Programming requires no special skills.
- Attack is hidden perfectly in the operating system.
- Distribution to computer users via updates of the operating system.
- Encryption products can be as secure as they could ever be and it’s still possible to break them at a touch of a button.
- Most professional file and disk encryption products are equally affected. There is even no need to know any source code of these products.
- Logged data won’t be longer than a few kilobytes or one megabyte and can be read out quickly and conveniently e.g. when inspecting notebook computers at the airport customs by customs officials.
The only disadvantage is that help from the manufacturer of the operating system is almost a requirement.
Is the MOUNT Control Code Attack a hypothetical or a real-life attack
The MOUNT Control Code Attack, as presented in this paper, works – without any doubt – perfectly as it’s easy to conceive and potentially easy to implement.
It is probably not used so far. Either it had already been invented by the Intelligence Community or this community might now read this paper attentively and perhaps like the idea.
People who’s business it is to spy on other people only set a first class source of information aside if they have no access to it, if they are incredibly stupid or if it’s against the law.
Would it be against the law?
Probably yes. It certainly isn’t illegal to spy on foreigners. As almost everybody in this world is a foreigner to other countries, there are many “targets” legally available.
Is the attack accessible to a major Intelligence Agency?
It is highly uncertain that hackers and most contracting bodies are capable of taking advantage of this kind of attack as the necessary modifications of the operating system can hardly be realized without the help of the original manufacturer. It’s not impossible, although.
No manufacturer in this world would be pleased when asked to manipulate his product(s). It is still pretty likely that this attack has already been realized. It could be a decisive source of information. If not yet realized, somebody might turn this hypothetical attack into a real life attack one fine day if there exist no countermeasures against it.
The availability of countermeasures might be an important reason to stop using it or for not turning this attack into reality. In order for this to happen it would be necessary to have a large user base migrate to truly secure data encryption software.
Countermeasure against the MOUNT Control Code Attack
Disk encryption and certain file encryption software packages cannot operate without software drivers. As the only way to communicate with the driver is the DeviceIoControl() function, there exists no efficient way to circumvent this kernel function. Using the Windows registry or a file to transfer the password would be a bad and highly unprofessional solution as password data would then be possibly permanently stored on a storage device.
The only truly ultimate solution is to take advantage of an extremely well-suited public key exchange protocol: the Diffie-Hellman key agreement.
Prior to the execution of a task that requires optimum protection, both kernel-mode encryption driver and user-mode application (which controls the encryption driver) negotiate a key that is private to both pieces of software. Password information, which is exchanged via the DeviceIoControl() kernel function, is thus totally inaccessible to the operating system.
Diffie-Hellman key exchange uses modular exponentiation to yield a unique key that is only known to the two parties which exchange the key. In the following explanation it is assumed that the key exchange is initiated by the user-mode control client and the client communicates with the driver.
The PDF version of this document contains the mathematical background of the Diffie-Hellman key exchange.
View full paper as PDF here (0.1Mb)
In contrast to RSA, it is impossible to willingly specify the message that is shared by both parties. Key generated by Diffie-Hellman is a random number and it’s identical for both parties.
Both Diffie-Hellman, as well as RSA require an extremely large amount of machine instructions on universal computers so that they are solely suitable to exchange key material.
Diffie-Hellman key exchange does not provide authentication of the communicating parties and is thus vulnerable to the so-called Man-in-the-Middle Attack. A person in the middle may establish two distinct Diffie-Hellman key exchanges, one with the client and the other with the driver, effectively masquerading as client and driver, and vice versa. This allowing the attacker to decrypt (and read or store), then re-encrypt the messages passed between driver and client.
The Man-in-the-Middle Attack is generally a very big threat for Diffie-Hellman protocols like SSL as a remote server might be programmed to mount this attack. All software components of disk encryption software although are running on the very same machine. Assuming that the DeviceIoControl() function was tamperated in a way that it mounts a Man-in-the-Middle Attack on a specific disk encryption software taking advantage of the Diffie-Hellman key exchange, man-in-the-middle inevitably requires a substancial amount of CPU time to perform an additional key exchange. As it’s the very same machine on which the attack is running, the attack would be extremely easy to detect by measuring the transport time span. As a matter of consequence, no Man-in-the-Middle Attack could ever be mounted successfully for a disk encryption software.
Conclusion
A new real-life attack against a broad range of encryption software products has been identified and described by us. Likelihood for many commercially available OTFE (on-the-fly encryption) software packages to be susceptible to this kind of attack is high. The attack exploits the fact that highly secret information is exchanged in the form of plaintext by the components of disk encryption software through a single kernel function. This DeviceIoControl() function is potentially one of the best sources for first class secret data. Likelihood for this function to be manipulated is considerably high.
An efficient countermeasure based on the Diffie-Hellman key exchange against this potential weakness is proposed in this paper. As no workaround against this countermeasure exists, the MOUNT Control Code Attack cannot be applied to disk encryption software and file encryption software that is equipped with the countermeasure presented in this paper.
The OTFE (disk encryption) software TurboCrypt 2008 is the first product of its kind to feature this countermeasure.
Developers of other OTFE products will most probably follow and implement this countermeasure with time. To our knowledge is the described method free of patents and the author can confirm that he hasn’t applied for protection of this intellectual property.