A Crypto Filter in a Day (or "I'm going to rant about this topic for a moment...")

For those who really do need an encryption filter next month, they are
welcome to come talk to us (or Dejan, or perhaps a few others on
here…) about licensing an existing solution. I can’t speak to other
people’s kits, but I can speak to ours - adding encryption is trivial.
I’ve done it - pick up an AES or Blowfish package, replace our sample
XOR logic in one place, recompile and you are done. You can encrypt.

We allow you to easily compress and encrypt (hey, it’s something like 12
extra lines to add compression before you encrypt - and decompression
after you decrypt, using the standard Windows OS LZW library routines in
the kernel.)

For a demo, you can add the encryption, attach to a volume and anything
you touch magically becomes encrypted - it happens in the background, is
robust and can recover from encryption key changes (think “clear to
encrypted” or “key 1 to key 2”).

But don’t think that a real product is so simple because the problems
don’t even stop there. What we don’t do (because it doesn’t have
anything to do with file systems or filters) is we don’t implement the
POLICY that people want around encryption. “Gee, I just want to encrypt
all WORD documents”. Whatever that means (honestly, to me that should
mean “anything Word touches” but I’m not going to try and solve the “is
this Microsoft Word, or is this some other program called word.exe…”
issue.)

And then there’s key management. And dealing with ways to steal the
information (think “what about the clip board?”) And so on, and so
forth.

While WE focus on why it is difficult to do the file systems piece of a
data encryption product, there are some other very complex issues in the
“what to encrypt” question. I sometimes wonder how long it takes before
people start thinking about THOSE questions because they are focused on
the issues at our level at first…

Bottom line: you need something fast, use someone who already knows how
to do it. If you don’t control the company purse, and the person who
does balks, go through the archives and start finding the numerous
postings on this very topic and tell them: “it might look expensive now,
but a year from now when we’re still trying to make this work right
you’ll appreciate how much cheaper it would have been…”

We might be able to make it easy to do the encryption piece, but you’ll
still have plenty of technical challenges - key management, policy
management, etc.

I’m extremely proud of our Data Modification Kit - it represents
considerable technological innovation in a format intended to allow
people who don’t want to understand the file systems business to do
things they probably never even considered (want streams on FAT? They
are there. Need compression + encryption, they are there. Want to
allow people to transparently encrypt a 17MB file on a 32MB USB drive,
we can do it. We have sparse files on any underlying file system. We
work over the network, we have solutions to the hideous naming problems.
Worried about losing data in the case where the system crashes or
someone yanks the USB drive out while the data is being encrypted?
We’ve thought about it, we make it “just work”. Need to have utilities
to read those files from other OS platforms, we have a nice ‘C’ library
in the kit you can port and use.) Do we want our due from that? Of
course we do. We’re not the cheap kids on the block, most folks know
that. But we support our customers, we’ve been at this a long time, and
we’ll be standing behind you to help YOU get your product out the door -
the biggest problem I have these days with our toolkits (like the FSDK)
is to get people to upgrade to newer releases of the kits.

I try to assist people quite a lot in this forum, but there are things
that I don’t do any more than other people do, like give away my code
for free - I value it, so should you.

'Nuff said. Time to go back to Plugfest so I can answer more questions,
taunt Neal with the depth of my useless NT 4.0 knowledge (yes, the
advanced FCB header WAS in NT 4.0…) and work with our team that is
pushing the DMK through its paces on Windows Vista, interop with other
folks, and expand people’s horizons.

Tony

Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com

Speaking as someone who hired Tony Mason and OSR to help my company
develop a custom file system filter, it was the BEST decision we
ever made. We did this project back in 1996 and OSR’s filter
driver has been running flawlessly in production environments
since 1997…even though I’ve modified it a few times myself
to add our unique functionality. :slight_smile:

There are soooo many undocumented or partially documented aspects to
developing a file system driver, even though there has been much
improvement since 1996, it really makes sense to use a framework
like Tony can provide so that you can concentrate on just the
aspects of the driver that make your implementation unique. So if
you can convince your management to purchase the “plumbing” from
OSR, then perhaps it will be possible for you to get to end-of-job
in a few months by adding your unique code on top of a working model.

Brian Hutchison

I worked on encryption filter before - and I still must say
rather I would implement it from scratch, I would rather
try to convince the management it’s much cheaper to
buy an existing solution.

As far as I remember, the filter was developed for about
6 years (first on NT, then on 2000, then on XP).

Even if driver dev salaries here are not as high as in the U.S,
it would be still cheaper to buy something now than work on it from scratch
(ofc there was no DMK at the time when the driver was started).

All of you people who started to write a filter 1st of this month
and are required to show the demo at the end of the next month,
don’t worry. You are NOT gonna make it.

L.

I’ve been working on mine for five years and I’m still learning new stuff.

My next challenge: sports drinks!

----- Original Message -----
From: “Ladislav Zezula”
To: “Windows File Systems Devs Interest List”
Sent: Thursday, November 09, 2006 12:16 PM
Subject: Re: [ntfsd] A Crypto Filter in a Day (or “I’m going to rant about
this topic for a moment…”)

>I worked on encryption filter before - and I still must say
> rather I would implement it from scratch, I would rather
> try to convince the management it’s much cheaper to
> buy an existing solution.
>
> As far as I remember, the filter was developed for about
> 6 years (first on NT, then on 2000, then on XP).
>
> Even if driver dev salaries here are not as high as in the U.S,
> it would be still cheaper to buy something now than work on it from
> scratch
> (ofc there was no DMK at the time when the driver was started).
>
> All of you people who started to write a filter 1st of this month
> and are required to show the demo at the end of the next month,
> don’t worry. You are NOT gonna make it.
>
> L.
>
>
> —
> Questions? First check the IFS FAQ at
> https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: xxxxx@netlib.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>

At some point it did exist a middle ground solution of using a filter to
redirect all irps to user land. This way the kernel exposure is minimal and
all the logic may be serialized in user space so you can easily debug and
not crash your system.
MS research proposed an example for FS dev if I recall properly.

This may buy you time in front of a not too tech savy management to show a
working prototype so you can learn and/or use a kit later.

Needless to say this solution is *not* industrial strength for security
module: very easily prone to user space attack, suffer performance penalty,
does not support all the features, transactions etc…

Jerome.

“Neil Weicher” wrote in message news:xxxxx@ntfsd…
> I’ve been working on mine for five years and I’m still learning new stuff.
>
> My next challenge: sports drinks!
>
> ----- Original Message -----
> From: “Ladislav Zezula”
> To: “Windows File Systems Devs Interest List”
> Sent: Thursday, November 09, 2006 12:16 PM
> Subject: Re: [ntfsd] A Crypto Filter in a Day (or “I’m going to rant about
> this topic for a moment…”)
>
>
> >I worked on encryption filter before - and I still must say
> > rather I would implement it from scratch, I would rather
> > try to convince the management it’s much cheaper to
> > buy an existing solution.
> >
> > As far as I remember, the filter was developed for about
> > 6 years (first on NT, then on 2000, then on XP).
> >
> > Even if driver dev salaries here are not as high as in the U.S,
> > it would be still cheaper to buy something now than work on it from
> > scratch
> > (ofc there was no DMK at the time when the driver was started).
> >
> > All of you people who started to write a filter 1st of this month
> > and are required to show the demo at the end of the next month,
> > don’t worry. You are NOT gonna make it.
> >
> > L.
> >
> >
> > —
> > Questions? First check the IFS FAQ at
> > https://www.osronline.com/article.cfm?id=17
> >
> > You are currently subscribed to ntfsd as: xxxxx@netlib.com
> > To unsubscribe send a blank email to xxxxx@lists.osr.com
> >
>
>