Condividi tramite

Encryption and Filters between WM2003 and WM5

  • Articolo

Posted by: Sue Loh

 

It seems that a common need people have is to encrypt all the data on a device, or as much as they can. I've seen some confusion over whether it's possible at all, how to do it, and what's different between WM2003 and WM5. Really this answer isn't very specific to encryption.

 

As you know, in WM2003 we had the object store, and there was no way to put a filter on it. So OEMs developed solutions that used hacks to encrypt the object store. They figured out where in RAM the object store lived, and saved/restored an encrypted version of it from some other storage. ISVs didn’t have that option (unless maybe if they were super hackers) but some ISVs did stuff like mount a file system driver (NOT a filter) where all the data on that file system was encrypted. In this case the solution was, “don’t use the object store for anything you want to protect.”

 

In WM5 there is no object store and it’s possible to mount a filter on the persistent store, BUT filters have to be specified in the registry at the time the persistent store is mounted, and the persistent store is mounted during boot before the full system registry is loaded, so as a result the filters have to be specified in the “ROM hive,” the static mini-registry that’s used to bootstrap the full system. So – and it pains me to say this – ISVs still can’t put a filter driver on top of the persistent store. L  OEMs now have the option, but ISVs do not.

 

So, in summary:

  • WM2003 OEM: with hacks they could encrypt the object store, with a filter they can encrypt removable storage
  • WM2003 ISV: filter drivers can encrypt removable storage, and a file system driver can mount a new encrypted directory that’s only a subset of the file system
  • WM5 OEM: with a filter driver they could encrypt everything
  • WM5 ISV: same as WM2003

I sure hope we can come up with a better ISV solution for this in the future, but perhaps you can understand the difficulty. We would either have to make a way to delay-load a filter after a file system driver is already mounted (which is really tough, especially if there are already file handles open) or somehow know about the filter before the persistent store is mounted (at which point -- where would you store that information??). It's a chicken-and-egg problem, and I wouldn't count on it being solved anytime soon.

Comments

  • Anonymous
    February 22, 2006
    Hi,
    Why not create a special folder named Encrypted?

    Any files and folders stored under there will be encrypted on the device. Any access to files and folders in Encrypted will force the user to enter a password.

    Either the user or ISV's could use it.

    K.I.S.S

    Steve.
  • Anonymous
    February 22, 2006
    Thanks, Steve. That's a great suggestion.

    An ISV could implement a custom Auto-Load File System Driver to encrypt data and mount it as a folder off the root directory. This wouldn't technically filter the root file system, but is likely a very workable solution.

    For details on mounting Auto-Load file systems, take a look at my post on file system registry settings:

    http://blogs.msdn.com/ce_base/archive/2005/08/09/449748.aspx.

    This method will work on both WM2003 and WM5.

    Andrew
  • Anonymous
    February 23, 2006
    Andrew, perhaps you mean it SHOULD work on both PPC2003 and WM5.

    Loading a file system driver on WM5 is a bit more complicated than on PPC2003. So far we have been unable to get that little part of the solution working.
  • Anonymous
    March 08, 2006
    Sue, great article!

    I do can do filtering for object store and for installable filesys on 2003/2005. For object store, through hacking, did it at API level (before filesys makes the decision what FILE API to use: FSMGR API or kernel direct file API). This is not the perfect solution I want.  For encryption purpose, filter driver level hooking is acceptable, even though not perfect. You see, for object store, the hooking I have is even above the filtering driver level.  Really want to change it.

    Could you please give us more detail explanation for the following sensences?

    " BUT filters have to be specified in the registry at the time the persistent store is mounted, and the persistent store is mounted during boot before the full system registry is loaded"

    Would you mind telling us (1) "the name of the mounted persistent store" and (2) the block device driver name  for the "persistent store"

    Appreciate it!
  • Anonymous
    March 08, 2006
    ...I mean for ISV
  • Anonymous
    March 08, 2006
    The comment has been removed
  • Anonymous
    March 08, 2006
    Andrew, thanks for your answer.

    IF (big IF) AFTER mounting & booting, the object store is NOT different from other installable file system(store). Then it should not be that hard to hook it! (for 2003, the object store/RAM file system is totally different from normal installable file system, as you know)

    I know, normal filter dll is loaded during booting process. But it's not that hard to add a new filter dll AFTER booting on demand(by hacking the data structure created by filesys inside filesys.exe, essentially insert a new one into the hooking chain). So if object store (after booting) is NOT treated differently, then this scheme should work too, even though you can not hook it from time 0.

    I still suspect that the object store is treated very differently after mounting? is that true? unfortunately, i am almost blind as far as WM5 is concerned: no kernel debugger like PB's

    Just one more question directly related to your answer: even though the backing block driver is provided/controled by OEM, HOW does filesys.exe to find it's name? I guess the emulator (WM5) is controled by you guys :), would you mind telling us about this case?

    Appreciate it!



    How does
  • Anonymous
    March 09, 2006
    Hi.
    How can I load my filter after booting process?
    jz, you say "by hacking the data structure created by filesys inside filesys.exe, essentially insert a new one into the hooking chain", but how can I do it?
  • Anonymous
    March 09, 2006
    The comment has been removed
  • Anonymous
    March 09, 2006
    The comment has been removed
  • Anonymous
    March 09, 2006
    Yes it is, but I just want to filter object store.
    This task is very a urgent for me now. But solving of this problem I not yet find.
  • Anonymous
    March 10, 2006
    I just want to post a quick clarification because there seems to be confusion over "ObjectStore" versus "Persistent Storage:"

    The ObjectStore is the root file system on Windows Mobile 2003 (and earlier) PocketPCs. The ObjectStore is a large chunk of RAM set-aside for storage. The RAM is battery-backed, so it appears to persist until your battery dies. There is no Microsoft supported way of filtering the ObjectStore file system. There may be 3rd party solutions.

    There is no ObjectStore on WM5 devices. Instead, these devices mount persistent storage as the root file system. Because of this change, battery-backed RAM is no longer necessary and your data will persist even after your battery dies. The only Microsoft supported way to filter persistent storage is by using an in-ROM file system filter, which cannot be installed by an ISV. Again, there may be 3rd party solutions.

    Andrew
  • Anonymous
    March 10, 2006
    Thanks, Andrew. Your clarification is very helpful.
    I just would to filter object store on WM5 devices. And the thought struck me that somebody here to prompt me any solution of this task.

    For previous your post I have question.
    For using CeGetVolumeInfo I must inslude storemgr.h to my project and link storeapi.lib with it. But this library did not found on my hard disk though I have installed wm5 SDK and wm2003 SDK. May be this library provided with Platform Builder?