(ISC)² believes in the importance of open dialogue and collaboration, between both (ISC)², its certified members and members of business and society.
(ISC)² established this blog to provide a voice to its certified members, who have significant knowledge and valuable insights to share that can benefit the information security industry, the people in it and the public at large.
The postings on this site are the author's own and don't necessarily represent
(ISC)²'s positions, strategies or opinions. (ISC)² does not control, monitor, or endorse any links provided in this blog and makes no warranty or statement regarding the content on any linked website.
Those who post comments to blogs should ensure their comments are focused on the topic at hand. (ISC)² reserves the right to remove any post or comment from this site.
Should you find objectionable content in this blog, please notify us as soon as possible at blog@isc2.org.
« Keeping Up-to-Date on a Daily Basis | Main | A Mistaken Conviction Based on Digital Forensics – Part 1 – Pretrial »
TrackBack URL for this entry:
http://www.typepad.com/services/trackback/6a00e54f109b678834010536cf6e33970c
Listed below are links to weblogs that reference Disk encryption driver hole exposes encryption key:
The comments to this entry are closed.
 |
Brian Albrecht |
 |
Otto Aulicino |
 |
Tim Bass |
 |
Dr. Pramod Damle |
 |
John Dittmer |
 |
Don Franke |
 |
Ionut Ionescu |
 |
Bob Johnston |
 |
Praveen |
| John Kinsella |
|
 |
Sinclair Koelemij |
| Adam Kuncewitch |
|
 |
Matthew |
 |
Simon Moffat |
 |
Lester E. Nichols III |
| Peter Pearson |
|
 |
Sean M. Price |
 |
Howard A. |
| James A Scholz |
|
 |
Harry Smith |
Although the described "attack" is technically correct, it doesn't pose a new threat.
Here's why: the DeviceIoControl function is part of Windows. If the operating system you're mounting an encrypted disk on was modified by an adversary, then there are even more issues you're facing. If an attacker can tamper the DeviceIoControl function, than they can also tamper the functions that handle user I/O - including keyboard access. Thus, they could intercept the user's windows login password and the password used for mounting the encrypted disk; but they also could extract the windows security tokens from RAM (can be used for attacks on other systems/resources in an AD environment), ...
The paper describes a convenient technical implementation for intercepting this data in a single location (but only for this specific product), but nothing more.
Sincerely,
Jürgen Pabel
Posted by: Juergen Pabel | 15 January 2009 at 05:53 AM