How to handle cache?

NTFSD
1

Hi,

I am writing a FSFD for windows. I want to encrypt data
which is getting written file on to the disk. I am able to do so but
having some query related to cache

  1. Since I am encrypting data for a memory maps application, even
    though I am able to encrypt data on disk, data in cache is still
    unencrypted.
  2. Now if at this time any other application tries to read that
    file, system will return that data from cache and the purpose of
    encrypting file is defeated.
  3. So my questing is how I would prevent any other application to
    read this data from cache?
  4. Is there any way by which I can lock the cache or erase the
    cache ones data is written on to disk.

Thanks & Regards,

Maitri Ved| E-DRM | Tech Mahindra

Oberoi Garden Estate, Chandivali, Mumbai - 72

* Office: +91-22-66882000 | Extn: 8092

Email: xxxxx@techmahindra.com mailto:xxxxx

www.techmahindra.com http:</http:>

============================================================================================================================

Disclaimer:

This message and the information contained herein is proprietary and confidential and subject to the Tech Mahindra policy statement, you may review the policy at http://www.techmahindra.com/Disclaimer.html externally and http://tim.techmahindra.com/Disclaimer.html internally within Tech Mahindra.

============================================================================================================================</mailto:xxxxx>

2

You control access to the cache by either (a) refusing to allow access
to anyone that shouldn’t be able to see the clear data; or (b) point
them to a different cached copy (e.g., the “encrypted” copy.)
Generally, I do a combination of the two (sharing is what gets you here

  • what happens if you want to write both the clear and encrypted data at
    the same time.)

Both of these are done as part of IRP_MJ_CREATE processing.

If you really want to force the cache to clear, the only 100% reliable
way to do so is to reboot the machine (and note that this doesn’t clear
RAM, just the file system data cache.)

Tony

OSR

3

Power down and if there are no batteries connected to the ram, it will clear it all. The BIOS will have to write all of memory if it is of ECC or parity type to stop the random bits from producing false parity error interrupts, though only servers usually have that type of memory.

As to the OP’s problem, couldn’t you open a private handle to the file and use it to actually read/write the file while doing a FSD for the creates from the callers? It becomes much more complex especially with memory mapped files. Another option is to deny a create to any file that has already been opened in an incompatible mode and keep doing it until the cache manager destroys the cache mappings.
“Tony Mason” wrote in message news:xxxxx@ntfsd…
You control access to the cache by either (a) refusing to allow access to anyone that shouldn’t be able to see the clear data; or (b) point them to a different cached copy (e.g., the “encrypted” copy.) Generally, I do a combination of the two (sharing is what gets you here - what happens if you want to write both the clear and encrypted data at the same time.)

Both of these are done as part of IRP_MJ_CREATE processing.

If you really want to force the cache to clear, the only 100% reliable way to do so is to reboot the machine (and note that this doesn’t clear RAM, just the file system data cache.)

Tony

OSR

4

>Since I am encrypting data for a memory maps application, even though I am able to encrypt data on

disk, data in cache is still unencrypted.

Correct. Cache reuses the same pages as MMF use, so, cache is always cleartext (otherwise you cannot have MMF support).

Now if at this time any other application tries to read that file, system will return that data from cache
and the purpose of encrypting file is defeated.

No.

The only purpose of on-disk encryption is protection against laptop or media theft.

You see - if somebody steals the hard disk or the laptop, then he can physically attach the disk to another computer and read everything. So, ACL-based protection is defeated if you have the physical (disassebly) access to the device.

On-disk encryption is not defeated by such a thing. Without the password knowledge, the thieve will only see the ciphertext.

But as about access to the running OS - on-disk encryption provides no protection at all since the cache is always cleartext. So, use the usual ACL-based access control to restrict the code in the running OS, and on-disk encryption to protect against laptop or disk drive theft.

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

5

It may take some time (http://arstechnica.com/news.ars/post/20080221-researchers-crack-filevault-bitlocker-with-canned-air-hack.html ), however, for that to finally happen.

  • S

From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of David Craig
Sent: Tuesday, November 04, 2008 3:33 AM
To: Windows File Systems Devs Interest List
Subject: Re:[ntfsd] How to handle cache?

Power down and if there are no batteries connected to the ram, it will clear it all. The BIOS will have to write all of memory if it is of ECC or parity type to stop the random bits from producing false parity error interrupts, though only servers usually have that type of memory.

As to the OP’s problem, couldn’t you open a private handle to the file and use it to actually read/write the file while doing a FSD for the creates from the callers? It becomes much more complex especially with memory mapped files. Another option is to deny a create to any file that has already been opened in an incompatible mode and keep doing it until the cache manager destroys the cache mappings.
“Tony Mason” > wrote in message news:xxxxx@ntfsd…
You control access to the cache by either (a) refusing to allow access to anyone that shouldn?t be able to see the clear data; or (b) point them to a different cached copy (e.g., the ?encrypted? copy.) Generally, I do a combination of the two (sharing is what gets you here ? what happens if you want to write both the clear and encrypted data at the same time.)

Both of these are done as part of IRP_MJ_CREATE processing.

If you really want to force the cache to clear, the only 100% reliable way to do so is to reboot the machine (and note that this doesn?t clear RAM, just the file system data cache.)

Tony
OSR

—
NTFSD is sponsored by OSR

For our schedule debugging and file system seminars
(including our new fs mini-filter seminar) visit:
http://www.osr.com/seminars

You are currently subscribed to ntfsd as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

6

David,

Bottom line, we’re pretty much describing the same thing (a layered file
system) but both of us are being rather cavalier in our description of
it. To make this work right, you need to manage the caches and
determine what the user is allowed to see. It is potentially a lot of
work, but the threat the OP was asking about is the wrong one to focus
on: you don’t try flushing the cache, you control what the user sees.

Tony

7

Indeed, one of the interesting arguments for per-file encryption versus
per volume encryption is that per-file encryption minimizes the attack
surface area. Other things that can (and should) be done to improve
this behavior is to track all the active key blocks in the driver and
scrub them whenever there is a power state change (ergo, shutdown,
hibernate, standby.) This doesn’t prevent someone from unplugging the
computer and pulling the battery of course, but security is all about
mitigation, not about 100% protection (if you want to protect the
computer, turn it of, unplug it and find a foundation somewhere in which
you can bury it. It’s remarkably secure at that point. But useless…)

In per-file encryption only the files that were actively being uses can
be compromised using cold boot attacks. Since this could easily be < 1%
of your encrypted files, you’ve mitigated the value of the attack.

Truthfully, while people look at the “lost laptop” as a common category
of data leakage, the reality is that USB drives are at least as
vulnerable (if not more.) And of course, there are numerous other ways
for information to leak out - through e-mail, via web pages, etc.
Per-file encryption can help some of those (encrypt the attachments, the
files you copy to your USB drive, etc.)

An important step that I often see skipped when people are building
security products is to define their threat model; that’s a fundamental
failure of their planning process, since not understanding the threat
model means you don’t know what you’re building to protect against.
Nobody can validate your design/implementation and you really don’t know
what you’ve protected against when you’re done. Generally, threat
models tie into the market for the product, so if you don’t know who is
going to buy your product, you don’t know their threats and you don’t
know what you’re building.

Tony

OSR

8

Interesting.

In the UK, for security impact level 3 and above CESG only deems whole
drive encryptors as being sufficiently secure and will not evaluate
software products which do not implement whole drive encryption.
Hardware encryption products must also completely encrypt the full
extent of the storage medium.

BitLocker To Go sounds useful for lower classified files.

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tony Mason
Sent: 04 November 2008 17:59
To: Windows File Systems Devs Interest List
Subject: RE: Re:[ntfsd] How to handle cache?

*** WARNING ***

This mail has originated outside your organization,
either from an external partner or the Global Internet.
Keep this in mind if you answer this message.

Indeed, one of the interesting arguments for per-file encryption versus
per volume encryption is that per-file encryption minimizes the attack
surface area. Other things that can (and should) be done to improve
this behavior is to track all the active key blocks in the driver and
scrub them whenever there is a power state change (ergo, shutdown,
hibernate, standby.) This doesn’t prevent someone from unplugging the
computer and pulling the battery of course, but security is all about
mitigation, not about 100% protection (if you want to protect the
computer, turn it of, unplug it and find a foundation somewhere in which
you can bury it. It’s remarkably secure at that point. But useless…)

In per-file encryption only the files that were actively being uses can
be compromised using cold boot attacks. Since this could easily be < 1%
of your encrypted files, you’ve mitigated the value of the attack.

Truthfully, while people look at the “lost laptop” as a common category
of data leakage, the reality is that USB drives are at least as
vulnerable (if not more.) And of course, there are numerous other ways
for information to leak out - through e-mail, via web pages, etc.
Per-file encryption can help some of those (encrypt the attachments, the
files you copy to your USB drive, etc.)

An important step that I often see skipped when people are building
security products is to define their threat model; that’s a fundamental
failure of their planning process, since not understanding the threat
model means you don’t know what you’re building to protect against.
Nobody can validate your design/implementation and you really don’t know
what you’ve protected against when you’re done. Generally, threat
models tie into the market for the product, so if you don’t know who is
going to buy your product, you don’t know their threats and you don’t
know what you’re building.

Tony

OSR

NTFSD is sponsored by OSR

For our schedule debugging and file system seminars
(including our new fs mini-filter seminar) visit:
http://www.osr.com/seminars

You are currently subscribed to ntfsd as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

9

I believe that only FDE drives such as those Seagate drives. I would want to know for sure the encryption algorithm used and the key generation method, but it stands a chance of being really secure.
“Oliver, Jonathan (UK)” wrote in message news:xxxxx@ntfsd…
Interesting.

In the UK, for security impact level 3 and above CESG only deems whole drive encryptors as being sufficiently secure and will not evaluate software products which do not implement whole drive encryption. Hardware encryption products must also completely encrypt the full extent of the storage medium.

BitLocker To Go sounds useful for lower classified files.

------------------------------------------------------------------------------
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Tony Mason
Sent: 04 November 2008 17:59
To: Windows File Systems Devs Interest List
Subject: RE: Re:[ntfsd] How to handle cache?

WARNING

This mail has originated outside your organization,
either from an external partner or the Global Internet.
Keep this in mind if you answer this message.

Indeed, one of the interesting arguments for per-file encryption versus per volume encryption is that per-file encryption minimizes the attack surface area. Other things that can (and should) be done to improve this behavior is to track all the active key blocks in the driver and scrub them whenever there is a power state change (ergo, shutdown, hibernate, standby.) This doesn’t prevent someone from unplugging the computer and pulling the battery of course, but security is all about mitigation, not about 100% protection (if you want to protect the computer, turn it of, unplug it and find a foundation somewhere in which you can bury it. It’s remarkably secure at that point. But useless.)

In per-file encryption only the files that were actively being uses can be compromised using cold boot attacks. Since this could easily be < 1% of your encrypted files, you’ve mitigated the value of the attack.

Truthfully, while people look at the “lost laptop” as a common category of data leakage, the reality is that USB drives are at least as vulnerable (if not more.) And of course, there are numerous other ways for information to leak out - through e-mail, via web pages, etc. Per-file encryption can help some of those (encrypt the attachments, the files you copy to your USB drive, etc.)

An important step that I often see skipped when people are building security products is to define their threat model; that’s a fundamental failure of their planning process, since not understanding the threat model means you don’t know what you’re building to protect against. Nobody can validate your design/implementation and you really don’t know what you’ve protected against when you’re done. Generally, threat models tie into the market for the product, so if you don’t know who is going to buy your product, you don’t know their threats and you don’t know what you’re building.

Tony

OSR

—
NTFSD is sponsored by OSR

For our schedule debugging and file system seminars
(including our new fs mini-filter seminar) visit:
http://www.osr.com/seminars

You are currently subscribed to ntfsd as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.

10

The security of an FDE product would be directly related to the manner
in which the key itself is managed. The cold boot attacks worked by
using the memory of the machine as a potential key search space. Using
brute force with millions of possibilities isn’t perfect, but it just
becomes a modest hardware cost to search the potential key space. Thus,
if your key is in memory, it becomes a potential target. I have not
examined how the Seagate drives enter the key, but I presume that at
some point it is in RAM and is then sent to the drive itself. The
period of vulnerability would thus be related to its lifetime in the RAM
(which is likely to be short, since this seems obvious.)

However, disk encryption is very much focused on a specific class of
threats (“laptop/desktop loss/theft”) but that’s not the universe of all
potential threat models.

E-mail is a remarkably common way of transmitting information. In very
high security environments that threat is mitigated by not allowing
e-mail, or by using a closed e-mail system. In any e-mail system, the
pool of potential compromises consists of the pool of users - keep that
pool small, and you minimize risk. Make that pool large, and you
increase the risk. The true interesting complexity with security is
that higher levels of security often involve compromising usability of
the system. I’m currently enjoying watching some of the complex work
ongoing in the federated security space (see Microsoft’s newly announced
Geneva server project.) The reason people want federated security is
because in the real world you have to interact with other groups besides
your own and you need some mechanism for communicating with them that
does not involve chain-of-custody control over a physically encrypted
hard drive that you send around (imagine doing document review that way

  • it would just take a long time.)

Government is often not burdened by time based threats, but commercial
interests often are. If you do things in commerce that make your
process slower and more cumbersome, you usually lose out to those that
are willing to speed up their process and take greater risks (e.g., of
information exposure.) Even Governments are not immune to the need to
risk information exposure in exchange for more rapid delivery of the
information (think “emerging situations, in which rapid and informed
response is better than rapid un-informed response, or ‘too late’ (slow)
informed response.”

Again, my point is that it goes back to threat models. If your threat
model is “we want to make sure that information on a laptop isn’t leaked
when I lose it” then FDE works well. Grab one of those nice encrypting
hard drives and go for it! If you worry about what you write onto USB
pen drives being compromised, encrypting them works well. To say there
is one security solution (“hardware FDE”) for all possible threats
suggests the person making that declaration has on blinders - it’s far
too simplistic and unrealistic.

Of course, the ultimate threat to security is users. If we could just
prohibit people from using the systems we build, securing them would be
so much easier.

Tony

OSR