Encryption and Filters between WM2003 and WM5

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.