Hi folks,
for a few weeks now we are struggling to implement encryption in a file
filter driver for Windows NT. The idea is that an encrypted file gets a
small header which my filter driver recognizes. Upon receipt of an
IRP_MJ_CREATE request the filter driver would decrypt the file (if it was
previously encrypted, that is, if it has the header). On the other side,
when an IRP_MJ_CLOSE is received the file is examined for specific
characteristics and if the file should be encrypted, the IRP_MJ_CLOSE is
first completed and then the file gets encrypted. We really need the
header, since the thing should work for both FAT and NTFS, and we must
support multiple encryption algorithms. The same approach works perfectly
for Win9x installations.
For file I/O the filter driver uses simple ZwXXX functions. In the main
hook routine the filter recognizes file I/O requests that are a result of
the filter driver’s own file I/O.
The problem is that I cannot get this to work properly. Text file
encryption is alright, but as soon as I am trying to encrypt MS-Office
files, the thing starts to behave badly, it hangs, or MS-Office cannot read
the file etc. etc… The decryption process is working alright, it is
‘just’ the encryption that is causing us headaches, gray hair and sleepless
nights.
Maybe the problem is that “too many” IRP_MJ_CREATE/IRP_MJ_CLOSE calls are
intercepted, because not all of them are actually used to start
reading/writing a file. Since the file filter driver also interacts with a
user-mode service, maybe it’s an idea to make the service decide wether or
not it is safe to start encryption.
We would like to hear your opinion on this…
With kind regards,
Bartjan Wattel
I think it is not good idea to decrypt on open and encrypt on close.
There may be an occasion when the file is not encrypted on the disk -
mostly in unexpected system crashes.
I think the file on disk should ALWAYS be encrypted.
When read occurs the filter has to decrypt data.
When write occurs the filter has to encrypt data.
But there are some problems:
- File on the disk (encrypted) is greater than decrypted one
(diffrence is the header and data alignment for block ciphers)
- For performance reasons only non-cached I/O would be en/decrypted.
Data in the system cache should be decrypted and normal I/O
gets them right from the system cache without any enc/dec.
- You should do not use ZwXxxx routines. Instead build your own IRPs
and send them to the underlying driver.
Another advanced reason is to maintain the header not at the file’s begin
but at the end of (aligned) file. It is because file offsets in both
encrypted
and decrypted variants are the same.
I am working on such a filter driver for a year and I have many problems
solved. If you want to go into some advanced discussion please contact
me at xxxxx@sodatsw.cz.
Paul
-----P?vodn? zpr?va-----
Od: Bartjan Wattel [SMTP:xxxxx@wxs.nl]
Odesl?no: 26. kv?tna 2000 14:50
Komu: File Systems Developers
P?edm?t: [ntfsd] Need your opinion about on-the-fly encryption
Hi folks,
for a few weeks now we are struggling to implement encryption in a file
filter driver for Windows NT. The idea is that an encrypted file gets a
small header which my filter driver recognizes. Upon receipt of an
IRP_MJ_CREATE request the filter driver would decrypt the file (if it was
previously encrypted, that is, if it has the header). On the other side,
when an IRP_MJ_CLOSE is received the file is examined for specific
characteristics and if the file should be encrypted, the IRP_MJ_CLOSE is
first completed and then the file gets encrypted. We really need the
header, since the thing should work for both FAT and NTFS, and we must
support multiple encryption algorithms. The same approach works perfectly
for Win9x installations.
For file I/O the filter driver uses simple ZwXXX functions. In the main
hook routine the filter recognizes file I/O requests that are a result of
the filter driver’s own file I/O.
The problem is that I cannot get this to work properly. Text file
encryption is alright, but as soon as I am trying to encrypt MS-Office
files, the thing starts to behave badly, it hangs, or MS-Office cannot
read
the file etc. etc… The decryption process is working alright, it is
‘just’ the encryption that is causing us headaches, gray hair and
sleepless
nights.
Maybe the problem is that “too many” IRP_MJ_CREATE/IRP_MJ_CLOSE calls are
intercepted, because not all of them are actually used to start
reading/writing a file. Since the file filter driver also interacts with a
user-mode service, maybe it’s an idea to make the service decide wether or
not it is safe to start encryption.
We would like to hear your opinion on this…
With kind regards,
Bartjan Wattel
You are currently subscribed to ntfsd as: xxxxx@sodatsw.cz
To unsubscribe send a blank email to $subst(‘Email.Unsub’)