A security model is a document, or even just a statement, that phrases clearly what the security system needs to protect, and against what — what are the assets and what are the threats that the security system considers. It gets into more detail, and may also address the “how” part, but that is the essence. If the researcher, or at least the reporter, considered the security model of those encrypted volumes applications, they would have noticed that such a “finding” is irrelevant. It blames the system for not doing something that it should not have been expected to do in the first place. And, such publications are even hazardous to some degree, because they lead the reader into implying that the system is immune against other threats of the same domain as that of the specific failure that was shown.

Software encryption of virtual volumes attempts to protect data at rest against off-line threats, that is, against threats that result from the computer being lost or stolen, either when off, or when the drives are unmounted. It does it properly when used well, and does it less properly in some other situations (but this is a topic for another discussion). In any case, such security software applications are not expected to protect the data against run-time attacks, let alone against run-time attacks that involve alterations to the OS kernel. Seeing a successful runtime attack as a failure of the application is just like claiming the application to fail by not addressing a surveillance camera mounted on the ceiling above the user, capturing his secret passphrase as he enters it to mount the encrypted volume. Such encryption software cannot, and is not expected to, mitigate the threat of external cameras recording the user’s keyboard activity, just as it is not expected to protect the user against the kernel of the operating system.

Almost everything that the user does on his computer somehow goes where the OS kernel can see it. The kernel can see everything the user types, every piece of information stored in memory by any application, anything that any application sends off to the screen, etc. Therefore, no software application (that runs over the kernel) can possibly protect the user against a kernel that has been altered to perform malicious actions. Other means may be available that protect the kernel from such tampering, but this, again, is for a different discussion.

So the paper brings to your attention the fact that a modified kernel can capture your keys. Sure, but so can it capture your keystrokes when you enter the passphrase, so can it capture the volume keys in RAM as files are decrypted on the fly, and so can it just read the decrypted files when you do. If you consulted the security model of the encrypted volumes application, then you would have realized that if your local system is compromised, then such encrypted volumes will just not help you.

Ringing the bell because of a particular issue that is not addressed in a field in which issues are rightfully, clearly, and intently not addressed, is not only improper security research, but also gives the reader false sense of security regarding all these other issues in the same field which are just as lacking, but on which no research was done.