hi,
i am writing an encryption fsfd and am currently using the FsContext value
to keep track of different files. so i will create a structure to store the
FsContext value and add the structure to a list when the FsContext is first
initialised. i will remove the structure when there are no more references
to the file. this is as described in the FAQ. all is well when i am storing
the user’s key in memory to encrypt and decrypt each file’s encryption key.
however, if i switch over to use tokens that does not reveal the keys, i
will have to always pass the file’s encryption key to the token for
decryption or encryption. this will slow down performance and may also cause
issues when the token is not available.
i am thinking of at least caching the file’s encryption key throughout the
user’s login session. this will mean that i need to track the files
differently, ie i cannot delete the structure away after the last reference
to the file, in case the file is opened again. the only other thing i can
think of is the filename. maybe i can store the filename in the structure
too, and use this to match.
does anyone have this issue too? or encryption fsfd should not be used in
this way with such tokens?
thanks!
Ampsi
> however, if i switch over to use tokens that does not reveal the keys, i
will have to always pass the file’s encryption key to the token for
decryption or encryption. this will slow down performance and may also cause
issues when the token is not available.
It is absolutely safe to keep the key in the kernel nonpaged memory, just do
not write it to disk.
Remember that the only goal of encryption is to protect against stolen
disk/computer/OS reinstall, so, it is safe to have FEKs floating in volatile
kernel memory.
Max
If you’re really paranoid, you can set a timer to go off and
periodically bit-flip/move around the non-paged key in memory.
Apparently there are techniques to scan powered-off RAM chips for
‘burned-in’ data. Of course, if you’ve got the NSA after you, you’ve
probably got a few TEMPEST vans sitting outside your front door anyways.
Maxim S. Shatskih wrote:
>however, if i switch over to use tokens that does not reveal the keys, i
>will have to always pass the file’s encryption key to the token for
>decryption or encryption. this will slow down performance and may also cause
>issues when the token is not available.
It is absolutely safe to keep the key in the kernel nonpaged memory, just do
not write it to disk.
Remember that the only goal of encryption is to protect against stolen
disk/computer/OS reinstall, so, it is safe to have FEKs floating in volatile
kernel memory.
Max
You are currently subscribed to ntfsd as: xxxxx@nryan.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
–
Don’t forget hibernation where the key will be written to the hibernation
file. Notebooks are the primary problem, but even desktops may have
hibernation enabled. Of course you should detect the hibernation and
destroy the key, forcing the user to log in again.
“Nick Ryan” wrote in message news:xxxxx@ntfsd…
>
> If you’re really paranoid, you can set a timer to go off and
> periodically bit-flip/move around the non-paged key in memory.
> Apparently there are techniques to scan powered-off RAM chips for
> ‘burned-in’ data. Of course, if you’ve got the NSA after you, you’ve
> probably got a few TEMPEST vans sitting outside your front door anyways.
>
> Maxim S. Shatskih wrote:
>
> >>however, if i switch over to use tokens that does not reveal the keys, i
> >>will have to always pass the file’s encryption key to the token for
> >>decryption or encryption. this will slow down performance and may also
cause
> >>issues when the token is not available.
> >
> >
> > It is absolutely safe to keep the key in the kernel nonpaged memory,
just do
> > not write it to disk.
> >
> > Remember that the only goal of encryption is to protect against stolen
> > disk/computer/OS reinstall, so, it is safe to have FEKs floating in
volatile
> > kernel memory.
> >
> > Max
> >
> >
> >
> > —
> > You are currently subscribed to ntfsd as: xxxxx@nryan.com
> > To unsubscribe send a blank email to xxxxx@lists.osr.com
> >
>
> –
> - Nick Ryan (MVP for DDK)
>
>
>
>
oh, what i meant was when my own structure containing the FEK has been
deleted due to the file having no more references, and then the file
re-opened. so i will have to recreate the structure and re-decrypt the FEK.
what i was hoping is a way to cache the FEK longer, across the deletion and
re-creation of my structure.
Ampsi
----- Original Message -----
From: “Maxim S. Shatskih”
To: “File Systems Developers”
Sent: Saturday, August 02, 2003 07:28
Subject: [ntfsd] Re: tracking files
> however, if i switch over to use tokens that does not reveal the keys, i
> will have to always pass the file’s encryption key to the token for
> decryption or encryption. this will slow down performance and may also
cause
> issues when the token is not available.
It is absolutely safe to keep the key in the kernel nonpaged memory, just do
not write it to disk.
Remember that the only goal of encryption is to protect against stolen
disk/computer/OS reinstall, so, it is safe to have FEKs floating in volatile
kernel memory.
Max
—
You are currently subscribed to ntfsd as: xxxxx@pmail.ntu.edu.sg
To unsubscribe send a blank email to xxxxx@lists.osr.com
is there a way to detect hibernation? is it to filter the IRP_MJ_POWER? can
a FSFD do this?
Ampsi
----- Original Message -----
From: “David J. Craig”
Newsgroups: ntfsd
To: “File Systems Developers”
Sent: Saturday, August 02, 2003 08:27
Subject: [ntfsd] Re: tracking files
Don’t forget hibernation where the key will be written to the hibernation
file. Notebooks are the primary problem, but even desktops may have
hibernation enabled. Of course you should detect the hibernation and
destroy the key, forcing the user to log in again.
“Nick Ryan” wrote in message news:xxxxx@ntfsd…
>
> If you’re really paranoid, you can set a timer to go off and
> periodically bit-flip/move around the non-paged key in memory.
> Apparently there are techniques to scan powered-off RAM chips for
> ‘burned-in’ data. Of course, if you’ve got the NSA after you, you’ve
> probably got a few TEMPEST vans sitting outside your front door anyways.
>
> Maxim S. Shatskih wrote:
>
> >>however, if i switch over to use tokens that does not reveal the keys, i
> >>will have to always pass the file’s encryption key to the token for
> >>decryption or encryption. this will slow down performance and may also
cause
> >>issues when the token is not available.
> >
> >
> > It is absolutely safe to keep the key in the kernel nonpaged memory,
just do
> > not write it to disk.
> >
> > Remember that the only goal of encryption is to protect against stolen
> > disk/computer/OS reinstall, so, it is safe to have FEKs floating in
volatile
> > kernel memory.
> >
> > Max
> >
> >
> >
> > —
> > You are currently subscribed to ntfsd as: xxxxx@nryan.com
> > To unsubscribe send a blank email to xxxxx@lists.osr.com
> >
>
> –
> - Nick Ryan (MVP for DDK)
>
>
>
>
—
You are currently subscribed to ntfsd as: xxxxx@pmail.ntu.edu.sg
To unsubscribe send a blank email to xxxxx@lists.osr.com
You can do this, but you will need to maintain your own cache, indexed by
the logon ID.
Max
----- Original Message -----
From: “Ampsi”
To: “File Systems Developers”
Sent: Monday, August 04, 2003 7:31 AM
Subject: [ntfsd] Re: tracking files
> oh, what i meant was when my own structure containing the FEK has been
> deleted due to the file having no more references, and then the file
> re-opened. so i will have to recreate the structure and re-decrypt the FEK.
> what i was hoping is a way to cache the FEK longer, across the deletion and
> re-creation of my structure.
>
> Ampsi
>
> ----- Original Message -----
> From: “Maxim S. Shatskih”
> To: “File Systems Developers”
> Sent: Saturday, August 02, 2003 07:28
> Subject: [ntfsd] Re: tracking files
>
>
> > however, if i switch over to use tokens that does not reveal the keys, i
> > will have to always pass the file’s encryption key to the token for
> > decryption or encryption. this will slow down performance and may also
> cause
> > issues when the token is not available.
>
> It is absolutely safe to keep the key in the kernel nonpaged memory, just do
> not write it to disk.
>
> Remember that the only goal of encryption is to protect against stolen
> disk/computer/OS reinstall, so, it is safe to have FEKs floating in volatile
> kernel memory.
>
> Max
>
>
>
> —
> You are currently subscribed to ntfsd as: xxxxx@pmail.ntu.edu.sg
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>
> —
> You are currently subscribed to ntfsd as: xxxxx@storagecraft.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com