Proposal for keying encrypted filesystem

Proposal for keying encrypted filesystem

[Pierre Abbat]

Each file has a four-byte key ID in its inode and is encrypted with a longer 
key. (One way to make these keys is to hash a passphrase with SHA1 and use 
four bytes for the key ID and the rest for the key.) Each process may hold 
any number of credentials consisting of the key ID and the key. When a 
process attempts to open an encrypted file, the kernel checks whether it or 
any of its ancestors has a credential that matches the file's key ID.

A utility called reiserkey is used to set and unset these keys. It can set or 
unset the key in itself or any of its ancestors running under the same uid, 
or if it's running as root, in any of its ancestors. reiserkey -a n sets the 
key in the nth ancestor; reiserkey -p n sets the key in process n. The 
default is -a 1; if reiserkey is run from a shell script, this sets the key 
in the shell script. To set it system-wide, use -p 1.

phma
-- 
.i toljundi do .ibabo mi'afra tu'a do
.ibabo damba do .ibabo do jinga
.icu'u la ma'atman.

Re: Proposal for keying encrypted filesystem

[Edward Shushkin]

Pierre Abbat wrote:
> 
> Each file has a four-byte key ID in its inode and is encrypted with a longer
> key. (One way to make these keys is to hash a passphrase with SHA1 and use
> four bytes for the key ID and the rest for the key.) Each process may hold
> any number of credentials consisting of the key ID and the key. When a
> process attempts to open an encrypted file, the kernel checks whether it or
> any of its ancestors has a credential that matches the file's key ID.

Never trust 4-byte ID. The first collision that provides any assigned 4 bytes 
in SHA1 output can be found very easy..

Edward.

> 
> A utility called reiserkey is used to set and unset these keys. It can set or
> unset the key in itself or any of its ancestors running under the same uid,
> or if it's running as root, in any of its ancestors. reiserkey -a n sets the
> key in the nth ancestor; reiserkey -p n sets the key in process n. The
> default is -a 1; if reiserkey is run from a shell script, this sets the key
> in the shell script. To set it system-wide, use -p 1.
> 
> phma
> --
> .i toljundi do .ibabo mi'afra tu'a do
> .ibabo damba do .ibabo do jinga
> .icu'u la ma'atman.

Re: Proposal for keying encrypted filesystem

[Pierre Abbat]

On Saturday 29 March 2003 11:46, Edward Shushkin wrote:
> Never trust 4-byte ID. The first collision that provides any assigned 4
> bytes in SHA1 output can be found very easy..

How many bytes of key ID would you use? A 4-byte key ID would mean that if 
about 92682 different keys were in use, there would be half a chance of a 
collision.

By the way, I am on the list.

Re: Proposal for keying encrypted filesystem

[Edward Shushkin]

Pierre Abbat wrote:
> 
> On Saturday 29 March 2003 11:46, Edward Shushkin wrote:
> > Never trust 4-byte ID. The first collision that provides any assigned 4
> > bytes in SHA1 output can be found very easy..
> 
> How many bytes of key ID would you use? A 4-byte key ID would mean that if
> about 92682 different keys were in use, there would be half a chance of a
> collision.
> 

Any collision can be used by attacker for access to remained decrypted data
in memory, so you should assign the *whole* output of any crypto-stable hash 
function (20 bytes for SHA1). If you use 19 bytes for ID, there is no any
guarantee that someone can not find a collision easy.
Edward.
 
> By the way, I am on the list.

Re: Proposal for keying encrypted filesystem

[Pierre Abbat]

On Saturday 29 March 2003 13:17, Edward Shushkin wrote:
> Any collision can be used by attacker for access to remained decrypted data
> in memory, so you should assign the *whole* output of any crypto-stable
> hash function (20 bytes for SHA1). If you use 19 bytes for ID, there is no
> any guarantee that someone can not find a collision easy.
> Edward.

If you use all 20 bytes as the key ID, what do you use as the key?? Using 4 
bytes as the key ID and 16 bytes as the key, if an attacker produces a 
collision and tries to use it to access data, he will get gibberish, as the 
key he is using is different from the key used to encrypt the data.

Please do not send a message to both me and the list. I am on the list.

Re: Proposal for keying encrypted filesystem

[Hendrik Visage]

On Sat, Mar 29, 2003 at 03:49:07PM -0500, Pierre Abbat wrote:
> On Saturday 29 March 2003 13:17, Edward Shushkin wrote:
> > Any collision can be used by attacker for access to remained decrypted data
> > in memory, so you should assign the *whole* output of any crypto-stable
> > hash function (20 bytes for SHA1). If you use 19 bytes for ID, there is no
> > any guarantee that someone can not find a collision easy.
> > Edward.
> 
> If you use all 20 bytes as the key ID, what do you use as the key?? Using 4 

In this whole discussion I'm still missing some references to research papers
on this technique, as it still sounds to me like security by obscurity.

On the key: I'd prefer it to be  "truely" randomly generated
(ie. /dev/random and not /dev/urandom), and then it be encrypted.
I'd prefer it to be encrypted with the public keys of all those that 
would need access to it.

Re: Proposal for keying encrypted filesystem

[Pierre Abbat]

On Sunday 30 March 2003 05:12, Hendrik Visage wrote:
> In this whole discussion I'm still missing some references to research
> papers on this technique, as it still sounds to me like security by
> obscurity.

I didn't find this in research papers. I thought of it in the bathtub. The 
credential could be a private key, if you like. The method of setting the 
credential in some ancestor of the current process is designed to meet two 
objectives:
1. A script can run, and it and all of its children can access the encrypted 
files, whereas no other process can. This would be used by an encrypted 
backup server, so that the operator of the backup server cannot read the 
backups, even while they are being backed up. It could also be used on 
multiuser workstations; if a user logs in twice, he would also have to key 
the filesystem twice.
2. A computer can have an encrypted /home directory, which is keyed once, and 
then every user can access files in it, subject to the permission bits.

> On the key: I'd prefer it to be  "truely" randomly generated
> (ie. /dev/random and not /dev/urandom), and then it be encrypted.
> I'd prefer it to be encrypted with the public keys of all those that
> would need access to it.

If each file has a different key, and each key is generated with /dev/random 
and encrypted with public keys, making a directory containing thousands of 
files is going to be *very* slow.

phma
-- 
.i toljundi do .ibabo mi'afra tu'a do
.ibabo damba do .ibabo do jinga
.icu'u la ma'atman.

Re: Proposal for keying encrypted filesystem

[Hendrik Visage]

On Sun, Mar 30, 2003 at 12:00:53PM -0500, Pierre Abbat wrote:
> On Sunday 30 March 2003 05:12, Hendrik Visage wrote:
> > In this whole discussion I'm still missing some references to research
> > papers on this technique, as it still sounds to me like security by
> > obscurity.
> 
> I didn't find this in research papers. I thought of it in the bathtub. The 

*red*red*lights*flashing*
*smelling*snake*oil*

Seriously:

 I'm not saying this is good not bad, just that I will not trust it
until some decent peer review from people that worked with key management
ala kerberos etc.

> 1. A script can run, and it and all of its children can access the encrypted 
> files, whereas no other process can. This would be used by an encrypted 
> backup server, so that the operator of the backup server cannot read the 
> backups, even while they are being backed up. It could also be used on 
> multiuser workstations; if a user logs in twice, he would also have to key 
> the filesystem twice.

still doable with decent keys & public/private keys

> 2. A computer can have an encrypted /home directory, which is keyed once, and 
> then every user can access files in it, subject to the permission bits.

This is done with inheritance etc. and then giving the computer the key
to the keys (Though it must be protected really well).

> > On the key: I'd prefer it to be  "truely" randomly generated
> > (ie. /dev/random and not /dev/urandom), and then it be encrypted.
> > I'd prefer it to be encrypted with the public keys of all those that
> > would need access to it.
> 
> If each file has a different key, and each key is generated with /dev/random 
> and encrypted with public keys, making a directory containing thousands of 
> files is going to be *very* slow.

Agreed. But then you have directory which could/would share a common key etc.


The issue I have is that I want the key management to be secure, and not like
the historical Microsoft etc. key systems that get compromised by just
thinking twice. Your method I'd like to see a review or two by people that
have worked with key management before, as I get the feeling that it's
more about obscurity rather than security (It's a very subjective view though)

And the hashing part is what I'm cautious about as I would prefer it to be
real keys (encrypted with real keys) used in real Algorithms, rather than
just obscuring I am going to safe sensitive data in these files/directories.

Hendrik

Re: Proposal for keying encrypted filesystem

[Pierre Abbat]

On Saturday 29 March 2003 13:17, Edward Shushkin wrote:
> Any collision can be used by attacker for access to remained decrypted data
> in memory, so you should assign the *whole* output of any crypto-stable
> hash function (20 bytes for SHA1). If you use 19 bytes for ID, there is no
> any guarantee that someone can not find a collision easy.
> Edward.

There isn't any guarantee with all 20 either, it's just 256 times as hard to 
find one and practically impossible. What about using the MD5 of the 
passphrase for the key ID, and the SHA1 of the passphrase for the key?

phma
-- 
.i toljundi do .ibabo mi'afra tu'a do
.ibabo damba do .ibabo do jinga
.icu'u la ma'atman.

Re: Proposal for keying encrypted filesystem

[Edward Shushkin]

Pierre Abbat wrote:
> 
> On Saturday 29 March 2003 13:17, Edward Shushkin wrote:
> > Any collision can be used by attacker for access to remained decrypted data
> > in memory, so you should assign the *whole* output of any crypto-stable
> > hash function (20 bytes for SHA1). If you use 19 bytes for ID, there is no
> > any guarantee that someone can not find a collision easy.
> > Edward.
> 
> There isn't any guarantee with all 20 either,

Yes of course, but with all the 20 bytes I have a guarantee of SHA1 stability
announced in appropriate papers, and I do have nothing for 19 bytes.. 

 it's just 256 times as hard to
> find one and practically impossible. What about using the MD5 of the
> passphrase for the key ID, and the SHA1 of the passphrase for the key?

Each secret key must be generated by special method which is specific for 
the used crypto algorithm, I think such methods are already exists, so we
don't need to invent something new..

Edward.

> 
> phma
> --
> .i toljundi do .ibabo mi'afra tu'a do
> .ibabo damba do .ibabo do jinga
> .icu'u la ma'atman.

Re: Proposal for keying encrypted filesystem

[Edward Shushkin]

Edward Shushkin wrote:
> 
> Pierre Abbat wrote:
> >
> > On Saturday 29 March 2003 13:17, Edward Shushkin wrote:
> > > Any collision can be used by attacker for access to remained decrypted data
> > > in memory, so you should assign the *whole* output of any crypto-stable
> > > hash function (20 bytes for SHA1). If you use 19 bytes for ID, there is no
> > > any guarantee that someone can not find a collision easy.
> > > Edward.
> >
> > There isn't any guarantee with all 20 either,
> 
> Yes of course, but with all the 20 bytes I have a guarantee of SHA1 stability
> announced in appropriate papers, and I do have nothing for 19 bytes..

So from this standpoint I would rather prefer 16-byte ID created by full-grade md5,
then 19-byte ID created by restricted SHA1. Maybe this standpoint is too conservative, 
but this is right.. 

> 
>  it's just 256 times as hard to
> > find one and practically impossible. What about using the MD5 of the
> > passphrase for the key ID, and the SHA1 of the passphrase for the key?
> 
> Each secret key must be generated by special method which is specific for
> the used crypto algorithm, I think such methods are already exists, so we
> don't need to invent something new..
> 
> Edward.
> 
> >
> > phma
> > --
> > .i toljundi do .ibabo mi'afra tu'a do
> > .ibabo damba do .ibabo do jinga
> > .icu'u la ma'atman.

Re: Proposal for keying encrypted filesystem

[Hendrik Visage]

On Mon, Mar 31, 2003 at 04:09:48PM +0400, Edward Shushkin wrote:
> > > There isn't any guarantee with all 20 either,
> > 
> > Yes of course, but with all the 20 bytes I have a guarantee of SHA1 stability
> > announced in appropriate papers, and I do have nothing for 19 bytes..
> 
> So from this standpoint I would rather prefer 16-byte ID created by full-grade md5,
> then 19-byte ID created by restricted SHA1. Maybe this standpoint is too conservative, 
> but this is right.. 

The question that should be answered:

 Are the design suppose to withstand scrutiny from people like the NSA
and other crypto gurus, or just for the mom-a-pop-shops ? 

Re: Proposal for keying encrypted filesystem

[Pierre Abbat]

On Monday 31 March 2003 08:36, Hendrik Visage wrote:
> The question that should be answered:
>
>  Are the design suppose to withstand scrutiny from people like the NSA
> and other crypto gurus, or just for the mom-a-pop-shops ?

As I proposed it, it was not meant to withstand scrutiny from anyone. It was 
meant to be modified by people who know more about kernel and ReiserFS 
internals than I do. What's your current proposal for keying the encryption?

phma
-- 
.i toljundi do .ibabo mi'afra tu'a do
.ibabo damba do .ibabo do jinga
.icu'u la ma'atman.

Re: Proposal for keying encrypted filesystem

[Hendrik Visage]

On Mon, Mar 31, 2003 at 08:54:21AM -0500, Pierre Abbat wrote:
> On Monday 31 March 2003 08:36, Hendrik Visage wrote:
> > The question that should be answered:
> >
> >  Are the design suppose to withstand scrutiny from people like the NSA
> > and other crypto gurus, or just for the mom-a-pop-shops ?
> 
> As I proposed it, it was not meant to withstand scrutiny from anyone. It was 
> meant to be modified by people who know more about kernel and ReiserFS 
> internals than I do. What's your current proposal for keying the encryption?

/dev/random for the paranoid, /dev/urandom for the lesser paranoid

Each file would have a minimum 64bit (For a starter and speed
on <64bit CPUs 32 bit with the top 64bits zeroed and to allow
future 64bit operations) KeyID.

The optimization to it would be to create access groups, and then those
files in the same (sub*)directory & access group could share the same keyID,
if the user/operator so desire (Some would prefer the slowness to the added 
security of the files not sharing the same "guesable" encryption key, while
others would only want to prevent disk scraping from showing something usable).

To make this plugin/future prove, I'd then requested the encryption key
from another process/kernel/module/etc. with at least the minimum tuple
<mount-point,operation[3],KeyID[1a]> or for more expressive information
<mount-point,operation[3],directory,file,UID,GID,KeyID[1a]>.
The data returned from the key database would be
<keyID[1b],EncryptionKey,EncryptionAlgorithm,CryptoOptions[2]>

KeyID should be a globally unique key coming from the key database for recovery 
 purposes in cases the other fields aren't the same anymore, ie. recovering to a
 seperate machine different UIDs etc.)
  [1a]: Would be Zero for an initial/new file
  [1b]: If 1a is zeroed, would be filled with a unique key from key database.

Note [2]: Something in the back of my head tells me that it might just be a
 good idea to add  the facility to provide extra options to the encryption
 or compression algorithm, ie. optimize for size/speed, ie. big files, or
 files on removable devices like USB keydrives

Note [3]: operation ie. create,new, read, write, append, change, rename etc.
 This might look superflous, but if the operator decided on a asymetrical
 encryption method, the read/write requests would yield different keys.

This way I believe the database for the encryption key would then handle the
sharing/management of the keys in whichever way the user/operator would like
to do it, and even do policing of who has access and who doesn't.

The encryption engine I would envisage would then be fed the data and the
encryption key, and the FS would write out the results.

this way we have the following features:

 1) The operator (via key database) can set the policies per file/directory
 2) the key database handle the sharing of keys per file, per directory etc.
 3) The key database would handle the encryption of keys based on certificates
 4) The keying algorithm/methods are outside of the FS.

I believe there would be optimizations to the above, but it would move the
implement away from the FS to allow the changes to the key/encryption
implementations to not impact the FS interface etc.

Hendrik

Re: Proposal for keying encrypted filesystem

[Pierre Abbat]

On Monday 31 March 2003 11:35, Hendrik Visage wrote:
> On Mon, Mar 31, 2003 at 08:54:21AM -0500, Pierre Abbat wrote:
> > On Monday 31 March 2003 08:36, Hendrik Visage wrote:
> > > The question that should be answered:
> > >
> > >  Are the design suppose to withstand scrutiny from people like the NSA
> > > and other crypto gurus, or just for the mom-a-pop-shops ?
> >
> > As I proposed it, it was not meant to withstand scrutiny from anyone. It
> > was meant to be modified by people who know more about kernel and
> > ReiserFS internals than I do. What's your current proposal for keying the
> > encryption?
>
> /dev/random for the paranoid, /dev/urandom for the lesser paranoid
>
> Each file would have a minimum 64bit (For a starter and speed
> on <64bit CPUs 32 bit with the top 64bits zeroed and to allow
> future 64bit operations) KeyID.

"32 bit with the top 64bits zeroed" is nonsense. I assume you mean "64 bits 
with the top 32 zeroed". There is no point in doing this, as it's a key ID, 
not a key. Use the full 64 bits.

> The optimization to it would be to create access groups, and then those
> files in the same (sub*)directory & access group could share the same
> keyID, if the user/operator so desire (Some would prefer the slowness to
> the added security of the files not sharing the same "guesable" encryption
> key, while others would only want to prevent disk scraping from showing
> something usable).

An access group is a group of what?

> To make this plugin/future prove, I'd then requested the encryption key
> from another process/kernel/module/etc. with at least the minimum tuple
> <mount-point,operation[3],KeyID[1a]> or for more expressive information
> <mount-point,operation[3],directory,file,UID,GID,KeyID[1a]>.
> The data returned from the key database would be
> <keyID[1b],EncryptionKey,EncryptionAlgorithm,CryptoOptions[2]>

You need to add the PID to the tuple used to ask for the key. That way a 
process and its children can access a file, but other processes running with 
the same UID cannot. This is necessary for trusted encrypted backup.

What does "To make this plugin/future prove" mean?

> KeyID should be a globally unique key coming from the key database for
> recovery purposes in cases the other fields aren't the same anymore, ie.
> recovering to a seperate machine different UIDs etc.)
>   [1a]: Would be Zero for an initial/new file
>   [1b]: If 1a is zeroed, would be filled with a unique key from key
> database.
>
> Note [2]: Something in the back of my head tells me that it might just be a
>  good idea to add  the facility to provide extra options to the encryption
>  or compression algorithm, ie. optimize for size/speed, ie. big files, or
>  files on removable devices like USB keydrives

or the cryptographic mode, e.g. ECB and no compression for mixrand.bin, CBC 
and bzip2 for a pbm file rarely written to.

Re: Proposal for keying encrypted filesystem

[Hendrik Visage]

On Mon, Mar 31, 2003 at 03:11:40PM -0500, Pierre Abbat wrote:
> On Monday 31 March 2003 11:35, Hendrik Visage wrote:
> > On Mon, Mar 31, 2003 at 08:54:21AM -0500, Pierre Abbat wrote:
> > > On Monday 31 March 2003 08:36, Hendrik Visage wrote:
> > > > The question that should be answered:
> > > >
> > > >  Are the design suppose to withstand scrutiny from people like the NSA
> > > > and other crypto gurus, or just for the mom-a-pop-shops ?
> > >
> > > As I proposed it, it was not meant to withstand scrutiny from anyone. It
> > > was meant to be modified by people who know more about kernel and
> > > ReiserFS internals than I do. What's your current proposal for keying the
> > > encryption?
> >
> > /dev/random for the paranoid, /dev/urandom for the lesser paranoid
> >
> > Each file would have a minimum 64bit (For a starter and speed
> > on <64bit CPUs 32 bit with the top 64bits zeroed and to allow
> > future 64bit operations) KeyID.
> 
> "32 bit with the top 64bits zeroed" is nonsense. I assume you mean "64 bits 
> with the top 32 zeroed". There is no point in doing this, as it's a key ID, 
> not a key. Use the full 64 bits.

Correct. It'll be for speed purposes on 32bit environments until
the need is there for bigger space (ie more than 2^32 files/directories
encrypted/mangled) :(

> > The optimization to it would be to create access groups, and then those
> > files in the same (sub*)directory & access group could share the same
> > keyID, if the user/operator so desire (Some would prefer the slowness to
> > the added security of the files not sharing the same "guesable" encryption
> > key, while others would only want to prevent disk scraping from showing
> > something usable).
> 
> An access group is a group of what?

The specifics should be the key database/engine's responsibility
to define it more precisely, but my initial idea was where two or more
files have the same users having access to these files, these 
users would form an accessgroup.

> > To make this plugin/future prove, I'd then requested the encryption key
> > from another process/kernel/module/etc. with at least the minimum tuple
> > <mount-point,operation[3],KeyID[1a]> or for more expressive information
> > <mount-point,operation[3],directory,file,UID,GID,KeyID[1a]>.
> > The data returned from the key database would be
> > <keyID[1b],EncryptionKey,EncryptionAlgorithm,CryptoOptions[2]>
> 
> You need to add the PID to the tuple used to ask for the key. That way a 
> process and its children can access a file, but other processes running with 
> the same UID cannot. This is necessary for trusted encrypted backup.

Agreed.

However if the key database/engine doesn't have access to an
already decrypted key, then it would return an error. That way the backups
would only be able to copy the file verbatim (ie. un-decryptable) to the backup
medium. Ie. the backups run while the user haven't logged in to enable
decryption. Or am I missing the definition of "trusted encrypted backups"?

> What does "To make this plugin/future prove" mean?

To not be limited by current design for future enhancements or needs.

Hmmm... made me think: The are a bit of information leakage in my data above,
as it assumes the filenames are unencrypted.
However, that could be fixed with the following:
Request:
<mount-point,operation[3],directory,file[4],PID,UID,GID,KeyID[1a]>

The answer:
<keyID[1b],FileName[4]EncryptionKey,EncryptionAlgorithm,CryptoOptions[2]>

Note[4]: The key engine/database might want filenames to be mangled too.
 The request for a new file would be the unmangled, with the response being
 the mangled filename. The reverse would be the case in directory accesses etc.

This could be used for directory names too, thus the only data available to
the attacker (excluding the key engine) would be the mangled names and the
place on the filesystem the data is.

Hendrik

Re: Proposal for keying encrypted filesystem

[Pierre Abbat]

On Monday 31 March 2003 16:31, Hendrik Visage wrote:
> On Mon, Mar 31, 2003 at 03:11:40PM -0500, Pierre Abbat wrote:
> > You need to add the PID to the tuple used to ask for the key. That way a
> > process and its children can access a file, but other processes running
> > with the same UID cannot. This is necessary for trusted encrypted backup.
>
> Agreed.
>
> However if the key database/engine doesn't have access to an
> already decrypted key, then it would return an error. That way the backups
> would only be able to copy the file verbatim (ie. un-decryptable) to the
> backup medium. Ie. the backups run while the user haven't logged in to
> enable decryption. Or am I missing the definition of "trusted encrypted
> backups"?

I don't understand "if the key database/engine doesn't have access to an 
already decrypted key".

Here's the protocol I'm thinking of:
Alice starts an SSH session to Bob, the backup server. Alice tells Bob to run 
"reiserkey -a 1 pa55phrase", which puts the passphrase in the key database as 
being accessible by the SSH session. Alice then starts rsync and tells it to 
use the already existing SSH session (I don't know how to do this, but it 
might be doable) to start rsync on Bob. Alice backs up her data to Bob, but 
no process that is not a child of the SSH session can read the backup on Bob, 
even if Bob becomes the UID that Alice is using. When she is finished, Alice 
runs reiserkey again to remove the passphrase from the key database.

Re: Proposal for keying encrypted filesystem

[Hendrik Visage]

On Mon, Mar 31, 2003 at 05:40:24PM -0500, Pierre Abbat wrote:
> On Monday 31 March 2003 16:31, Hendrik Visage wrote:
> > On Mon, Mar 31, 2003 at 03:11:40PM -0500, Pierre Abbat wrote:
> > > You need to add the PID to the tuple used to ask for the key. That way a
> > > process and its children can access a file, but other processes running
> > > with the same UID cannot. This is necessary for trusted encrypted backup.
> >
> > Agreed.
> >
> > However if the key database/engine doesn't have access to an
> > already decrypted key, then it would return an error. That way the backups
> > would only be able to copy the file verbatim (ie. un-decryptable) to the
> > backup medium. Ie. the backups run while the user haven't logged in to
> > enable decryption. Or am I missing the definition of "trusted encrypted
> > backups"?
> 
> I don't understand "if the key database/engine doesn't have access to an 
> already decrypted key".

ie. for your example below, a reiserfskey haven't yet executed.

Note, my view on the key database is that it shouldn't be limited to
single instance/machine, rather it would be able to communicate with
others or a central key database to exchange keys.

> Here's the protocol I'm thinking of:
> Alice starts an SSH session to Bob, the backup server. Alice tells Bob to run 
> "reiserkey -a 1 pa55phrase", which puts the passphrase in the key database as 
> being accessible by the SSH session. Alice then starts rsync and tells it to 
> use the already existing SSH session (I don't know how to do this, but it 
> might be doable) to start rsync on Bob. Alice backs up her data to Bob, but 
> no process that is not a child of the SSH session can read the backup on Bob, 
> even if Bob becomes the UID that Alice is using. When she is finished, Alice 
> runs reiserkey again to remove the passphrase from the key database.

A very specific case, which could be easily handled with some PAM magic 
to negate the need for a reiserkey execution by the user as it could be
done on the fly, but that is getting OT as it would/should be part of an
external process (read key database specific :) that would make the decision.

The case I had in mind was where you are backing up encrypted files to tape.

Hendrik

Re: Proposal for keying encrypted filesystem

[Edward Shushkin]

Hendrik Visage wrote:
> 
> On Mon, Mar 31, 2003 at 04:09:48PM +0400, Edward Shushkin wrote:
> > > > There isn't any guarantee with all 20 either,
> > >
> > > Yes of course, but with all the 20 bytes I have a guarantee of SHA1 stability
> > > announced in appropriate papers, and I do have nothing for 19 bytes..
> >
> > So from this standpoint I would rather prefer 16-byte ID created by full-grade md5,
> > then 19-byte ID created by restricted SHA1. Maybe this standpoint is too conservative,
> > but this is right..
> 
> The question that should be answered:
> 
>  Are the design suppose to withstand scrutiny from people like the NSA
> and other crypto gurus, or just for the mom-a-pop-shops ?

I didn't invent something new..
I don't understand what should withstand scrutiny from crypto gurus.. md5? SHA?
Edward.

Re: Proposal for keying encrypted filesystem

[Hendrik Visage]

On Mon, Mar 31, 2003 at 05:58:04PM +0400, Edward Shushkin wrote:
> I didn't invent something new..
> I don't understand what should withstand scrutiny from crypto gurus.. md5? SHA?

The keying implementation as proposed.

Re: Proposal for keying encrypted filesystem

[Edward Shushkin]

Hendrik Visage wrote:
> 
> On Mon, Mar 31, 2003 at 05:58:04PM +0400, Edward Shushkin wrote:
> > I didn't invent something new..
> > I don't understand what should withstand scrutiny from crypto gurus.. md5? SHA?
> 
> The keying implementation as proposed.

I agree, but keying implementation is not ready, just in discussion process, so there is 
nothing that should withstand scrutiny for a while.. I want to clear up some order in 
addition to the design document I have posted.
  First we would like to specify the minimal crypto interface that kernel should know about.
Our policy is that it should be exactly *minimal*, so kernel shouldn't worry about key
management. When user tries to open a crypto file by special reiser4_open() system call,
kernel calls appropriate method which checks if the key passed by user is valid. I have 
described the identification mechanism earlier, it uses disk key ID calculated by share or
private key during creation (when kernel creates, or opens a crypto file, it doesn't need to
distinguish, if the key is share or private). With a big probability (which is provided by
using of crypto-stable hash function) kernel makes a right conclusion if the key is valid or
invalid. If passed key is valid, kernel load this key into its own memory, and installs the
pointer to the inode. It means that user has got an access to this file i.e. he can read and
write file's data using this key. At the end of session reiser4_close() method zeroes and frees
the memory allocated for the key. All read(), write() internals I have described earlier. 
 There is an opinion that is *all* what kernel should know about crypto-files. Although one
more thing that kernel also should do (in order to support public-private interface) is
distinguish what key should be used for reading, and what one should be used for writing.
The current list of parameters which should be passed to the kernel via reiser4_open syscall
(including compression info) is:

crypto_id crypto;            / id of the reiser4 crypto-plugin /
crypto_hash_id hash;         / id of the reiser4 crypto-hash plugin /
compression_id compression;  / id of the reiser4 compression plugin /
__u8 *pr_key;                / pointer to the private(share) key /
__u16 pr_key_size;           / private(share) key size /
__u8 *pub_key;               / pointer to the public key /
__u16 pub_key_size;          / public key size /
__u8 *keyid_string;          / pointer to the identification string (secret string randomly
                               generated by appropriate key generation routine) /
__u8  keyid_length ;         / the length of identification string /
__u8  cluster_shift;         / cluster parameter /

Key ID size is defined by crypto-hash plugin (it is just an output size of appropriate hash
function). All other needed information is contained in specified crypto-plugin (if used
crypto-algorithm is symmetric or asymmetric, how to install keys to the inode, etc..)
So we would like to see the following:
   
1) Any opinions whether this crypto-file interface is full enough to implement public-private
keing (or maybe I have missed something that will be needed for some useful features), etc..

2) Any remarks about possible security holes in the reiser4 internals of main system calls I
have described. I don't think this is the only crypto guru who can do this.

3) Any proposals about crypto-directory plugin implementation. Obviously, encryption of directory
entries (which is so desirable by everyone) should be implemented as a new directory plugin. 
This is the main directory plugin methods (->create_child() and ->lookup() responsible for 
new entry creation and name resolution) who will call crypto-plugin (I hope we don't need
to compress file names). Perhaps, it is possible to implement the scheme when all directory entries
and appropriate files are encrypted by the same key which is loaded once for all these files, and
the appropriate key ID is verified once and saved once in directory disk stat-data instead of 
its saving in disk stat-data of each file.

4) Proposals about integrating with a PKI infrastructure.

5) Proposals about user level support.

As I understand, currently we need 1), 2) and 5). Other will be need in future.	
Anyway thanks for all your posts, although some of them I can not comment since the topic is beyond
the scope of DARPA contract.

Edward.

Re: Proposal for keying encrypted filesystem

[Hans Reiser]

Edward Shushkin wrote:

>Hendrik Visage wrote:
>  
>
>>On Mon, Mar 31, 2003 at 05:58:04PM +0400, Edward Shushkin wrote:
>>    
>>
>>>I didn't invent something new..
>>>I don't understand what should withstand scrutiny from crypto gurus.. md5? SHA?
>>>      
>>>
>>The keying implementation as proposed.
>>    
>>
>
>I agree, but keying implementation is not ready, just in discussion process, so there is 
>nothing that should withstand scrutiny for a while.. I want to clear up some order in 
>addition to the design document I have posted.
>  First we would like to specify the minimal crypto interface that kernel should know about.
>Our
>
? ;-)

> policy is that it should be exactly *minimal*, so kernel shouldn't worry about key
>management.
>
My policy is that user hassle should be minimal, and we should try to 
select at least one default key management set of utilities to integrate 
well with and test with.

Are you sure we should not get keys from the environment? Is there too 
much performance cost?

It would be best if people could use applications that are unaware of 
the crypto mechanism when accessing files.

> When user tries to open a crypto file by special reiser4_open() system call,
>kernel calls appropriate method which checks if the key passed by user is valid. I have 
>described the identification mechanism earlier, it uses disk key ID calculated by share or
>private key during creation (when kernel creates, or opens a crypto file, it doesn't need to
>distinguish, if the key is share or private). With a big probability (which is provided by
>using of crypto-stable hash function) kernel makes a right conclusion if the key is valid or
>invalid. If passed key is valid, kernel load this key into its own memory, and installs the
>pointer to the inode. It means that user has got an access to this file i.e. he can read and
>write file's data using this key. At the end of session reiser4_close() method zeroes and frees
>the memory allocated for the key. All read(), write() internals I have described earlier. 
> There is an opinion that is *all* what kernel should know about crypto-files. Although one
>more thing that kernel also should do (in order to support public-private interface) is
>distinguish what key should be used for reading, and what one should be used for writing.
>The current list of parameters which should be passed to the kernel via reiser4_open syscall
>(including compression info) is:
>
>crypto_id crypto;            / id of the reiser4 crypto-plugin /
>crypto_hash_id hash;         / id of the reiser4 crypto-hash plugin /
>compression_id compression;  / id of the reiser4 compression plugin /
>__u8 *pr_key;                / pointer to the private(share) key /
>__u16 pr_key_size;           / private(share) key size /
>__u8 *pub_key;               / pointer to the public key /
>__u16 pub_key_size;          / public key size /
>__u8 *keyid_string;          / pointer to the identification string (secret string randomly
>                               generated by appropriate key generation routine) /
>__u8  keyid_length ;         / the length of identification string /
>__u8  cluster_shift;         / cluster parameter /
>
>Key ID size is defined by crypto-hash plugin (it is just an output size of appropriate hash
>function). All other needed information is contained in specified crypto-plugin (if used
>crypto-algorithm is symmetric or asymmetric, how to install keys to the inode, etc..)
>So we would like to see the following:
>   
>1) Any opinions whether this crypto-file interface is full enough to implement public-private
>keing (or maybe I have missed something that will be needed for some useful features), etc..
>
>2) Any remarks about possible security holes in the reiser4 internals of main system calls I
>have described. I don't think this is the only crypto guru who can do this.
>
>3) Any proposals about crypto-directory plugin implementation. Obviously, encryption of directory
>entries (which is so desirable by everyone) should be implemented as a new directory plugin. 
>
Not this year though, unless someone pays for it.

>This is the main directory plugin methods (->create_child() and ->lookup() responsible for 
>new entry creation and name resolution) who will call crypto-plugin (I hope we don't need
>to compress file names). Perhaps, it is possible to implement the scheme when all directory entries
>and appropriate files are encrypted by the same key which is loaded once for all these files, and
>the appropriate key ID is verified once and saved once in directory disk stat-data instead of 
>its saving in disk stat-data of each file.
>
>4) Proposals about integrating with a PKI infrastructure.
>
How about creating a list of the existing PKIs?

>
>5) Proposals about user level support.
>
>As I understand, currently we need 1), 2) and 5). Other will be need in future.	
>Anyway thanks for all your posts, although some of them I can not comment since the topic is beyond
>the scope of DARPA contract.
>
>Edward.
>
>
>  
>


-- 
Hans

Re: Proposal for keying encrypted filesystem

[Anders Widman]

> My policy is that user hassle should be minimal, and we should try to
> select at least one default key management set of utilities to integrate
> well with and test with.

> Are you sure we should not get keys from the environment? Is there too
> much performance cost?

> It would be best if people could use applications that are unaware of
> the crypto mechanism when accessing files.

I think this is very important. Making all software aware would be a
much bigger task to accomplish?

//Anders

Re: Proposal for keying encrypted filesystem

[Hans Reiser]

Anders Widman wrote:

>>My policy is that user hassle should be minimal, and we should try to
>>select at least one default key management set of utilities to integrate
>>well with and test with.
>>    
>>
>
>  
>
>>Are you sure we should not get keys from the environment? Is there too
>>much performance cost?
>>    
>>
>
>  
>
>>It would be best if people could use applications that are unaware of
>>the crypto mechanism when accessing files.
>>    
>>
>
>I think this is very important. Making all software aware would be a
>much bigger task to accomplish?
>
>//Anders
>
>
>
>  
>
I think it is essential to the task that apps not be aware of keys.

-- 
Hans

Re: Proposal for keying encrypted filesystem

[Pierre Abbat]

On Tuesday 01 April 2003 11:21, Hans Reiser wrote:
> I think it is essential to the task that apps not be aware of keys.

Indeed. The reiser4-specific syscall should insert or delete a key into the 
database; to open a file you use the generic open() syscall, which passes the 
filename to reiser4, which then asks the plugin if it has the key, and fails 
if it doesn't. The only time you should need to use a reiser4-specific call 
to open a file is when you need to read or write the ciphertext, which Bob 
needs to do when he backs up to tape (or another disk) the data which Alice 
backed up to him. This also needs special read and write calls, as you need 
to know how long each block (stored as a tail) is, because it's compressed.

I'd also like to see some other protocols using an encrypted filesystem, 
especially ones using public key, as I don't understand why you need public 
key encryption in a filesystem.

phma
-- 
.i toljundi do .ibabo mi'afra tu'a do
.ibabo damba do .ibabo do jinga
.icu'u la ma'atman.

Re: Proposal for keying encrypted filesystem

[Hans Reiser]

Pierre Abbat wrote:

>On Tuesday 01 April 2003 11:21, Hans Reiser wrote:
>  
>
>>I think it is essential to the task that apps not be aware of keys.
>>    
>>
>
>Indeed. The reiser4-specific syscall should insert or delete a key into the 
>database;
>
why?

> to open a file you use the generic open() syscall, which passes the 
>filename to reiser4, which then asks the plugin if it has the key, and fails 
>if it doesn't. The only time you should need to use a reiser4-specific call 
>to open a file is when you need to read or write the ciphertext, which Bob 
>needs to do when he backs up to tape (or another disk) the data which Alice 
>backed up to him. This also needs special read and write calls, as you need 
>to know how long each block (stored as a tail) is, because it's compressed.
>
>I'd also like to see some other protocols using an encrypted filesystem, 
>especially ones using public key, as I don't understand why you need public 
>key encryption in a filesystem.
>
>phma
>  
>


-- 
Hans

Re: Proposal for keying encrypted filesystem

[Pierre Abbat]

On Wednesday 02 April 2003 01:06, Hans Reiser wrote:
> Pierre Abbat wrote:
> >On Tuesday 01 April 2003 11:21, Hans Reiser wrote:
> >>I think it is essential to the task that apps not be aware of keys.
> >
> >Indeed. The reiser4-specific syscall should insert or delete a key into
> > the database;
>
> why?

We are obviously talking at cross purposes. Please present your protocols so 
that we can all know what you are trying to accomplish with an encrypted 
filesystem.

Re: Proposal for keying encrypted filesystem

[Edward Shushkin]

Pierre Abbat wrote:
> 
> On Tuesday 01 April 2003 11:21, Hans Reiser wrote:
> > I think it is essential to the task that apps not be aware of keys.
> 
> Indeed. The reiser4-specific syscall should insert or delete a key into the
> database; to open a file you use the generic open() syscall, which passes the
> filename to reiser4, 

No, generic sys_open() should return error for encryption file pathname.

> which then asks the plugin if it has the key, and fails
> if it doesn't. The only time you should need to use a reiser4-specific call
> to open a file is when you need to read or write the ciphertext, which Bob
> needs to do when he backs up to tape (or another disk) the data which Alice
> backed up to him. This also needs special read and write calls, as you need
> to know how long each block (stored as a tail) is, because it's compressed.

All this work do reiser4 specific part of vfs's read(), write(). 
We only need special sys_open(). Other methods remain the same.

> 
> I'd also like to see some other protocols using an encrypted filesystem,
> especially ones using public key, as I don't understand why you need public
> key encryption in a filesystem.

Why not?
Maybe Bob will want to create a file so that nobody but Alice can read it..

Edward.

> 
> phma
> --
> .i toljundi do .ibabo mi'afra tu'a do
> .ibabo damba do .ibabo do jinga
> .icu'u la ma'atman.

Re: Proposal for keying encrypted filesystem

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 1333 bytes --]

On Tue, 01 Apr 2003 20:06:32 +0400, Hans Reiser said:

> Are you sure we should not get keys from the environment? Is there too 
> much performance cost?

It's not just a performance cost issue.  It's also a security issue.

There's too many ways to leak the contents of /proc/<nnnn>/environ.  Yes,
it's mode 600.  (Think all the LD_* environment variable bugs.. ;)

Also, there's the problem that keys are per-file (possibly) while environments
are per-process.  As a result, a process that uses files in multiple security
domains can chew up a *LOT* of environment space.

A better bet would be to use the LSM security framework to create a module
that carries the tokens around for the process - this could even allow you
to do things like add a new key token to a process group leader and have
it propagate to already-running children (which is a phenomenally useful
thing to do that you can't do with an environment variable).  So for
instance, you could add a new key to your X login process, and all the
myriad subshells would get it - and thus any processes THEY launch) without
the need to log out from X and log back in again...

> It would be best if people could use applications that are unaware of 
> the crypto mechanism when accessing files.

Correct.  If the app can't use the normal open() call it's a non-starter.

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: Proposal for keying encrypted filesystem

[Hans Reiser]

Valdis.Kletnieks@vt.edu wrote:

>On Tue, 01 Apr 2003 20:06:32 +0400, Hans Reiser said:
>
>  
>
>>Are you sure we should not get keys from the environment? Is there too 
>>much performance cost?
>>    
>>
>
>It's not just a performance cost issue.  It's also a security issue.
>
>There's too many ways to leak the contents of /proc/<nnnn>/environ.  Yes,
>it's mode 600.  (Think all the LD_* environment variable bugs.. ;)
>  
>
You mean because processes might not be secure in what they do with 
their info about their environment variables?

Like shells....

Hmm.....

>
>Also, there's the problem that keys are per-file (possibly) while environments
>are per-process.  As a result, a process that uses files in multiple security
>domains can chew up a *LOT* of environment space.
>
>A better bet would be to use the LSM security framework to create a module
>that carries the tokens around for the process - this could even allow you
>to do things like add a new key token to a process group leader and have
>it propagate to already-running children (which is a phenomenally useful
>thing to do that you can't do with an environment variable).  So for
>instance, you could add a new key to your X login process, and all the
>myriad subshells would get it - and thus any processes THEY launch) without
>the need to log out from X and log back in again...
>
Ok, let's do it.  Edward, find some documentation about this and send us 
info....

>
>  
>
>>It would be best if people could use applications that are unaware of 
>>the crypto mechanism when accessing files.
>>    
>>
>
>Correct.  If the app can't use the normal open() call it's a non-starter.
>  
>


-- 
Hans

Re: Proposal for keying encrypted filesystem

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 435 bytes --]

On Thu, 03 Apr 2003 23:43:42 +0400, Hans Reiser said:

> Ok, let's do it.  Edward, find some documentation about this and send us 
> info....

http://lsm.immunix.org/
http://www.coker.com.au/selinux/   Russ Coker's NSA Security Enhanced Linux package

One thing you want to be careful about is to make sure your LSM module
is "composable" - in other words, that it plays nice with other modules.  Some
modules stack nicely, some dont.

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: Proposal for keying encrypted filesystem

[Hans Reiser]

Valdis.Kletnieks@vt.edu wrote:

>
>A better bet would be to use the LSM security framework to create a module
>that carries the tokens around for the process - this could even allow you
>to do things like add a new key token to a process group leader and have
>it propagate to already-running children (which is a phenomenally useful
>thing to do that you can't do with an environment variable).  So for
>instance, you could add a new key to your X login process, and all the
>myriad subshells would get it - and thus any processes THEY launch) without
>the need to log out from X and log back in again...
>
>  
>
Thanks.  This is why it was important to discuss these things on the 
list....

-- 
Hans

Re: Proposal for keying encrypted filesystem

[Pierre Abbat]

On Thursday 03 April 2003 11:14, Valdis.Kletnieks@vt.edu wrote:
> A better bet would be to use the LSM security framework to create a module
> that carries the tokens around for the process - this could even allow you
> to do things like add a new key token to a process group leader and have
> it propagate to already-running children (which is a phenomenally useful
> thing to do that you can't do with an environment variable).  So for
> instance, you could add a new key to your X login process, and all the
> myriad subshells would get it - and thus any processes THEY launch) without
> the need to log out from X and log back in again...

What's LSM? This sounds like it can do what I want with rsync. Is it possible 
to add a new key token to init and have it propagate to all processes?

phma
-- 
.i toljundi do .ibabo mi'afra tu'a do
.ibabo damba do .ibabo do jinga
.icu'u la ma'atman.

Re: Proposal for keying encrypted filesystem

[Russell Coker]

On Friday 04 April 2003 09:22, Pierre Abbat wrote:
> On Thursday 03 April 2003 11:14, Valdis.Kletnieks@vt.edu wrote:
> > A better bet would be to use the LSM security framework to create a
> > module that carries the tokens around for the process - this could even
>
> What's LSM? This sounds like it can do what I want with rsync. Is it
> possible to add a new key token to init and have it propagate to all
> processes?

LSM is Linux Security Modules http://lsm.immunix.org/

LSM is the interface between a security module such as Security Enhanced Linux 
and the core Linux kernel code.

To do what you want you would have to create your own LSM module (which can 
even be loaded at run-time in an LSM kernel).

I suggest joining the LSM mailing list if you need more information, I'm not 
an expert on this.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page

Re: Proposal for keying encrypted filesystem

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 745 bytes --]

On Thu, 03 Apr 2003 18:22:11 EST, Pierre Abbat <phma@webjockey.net>  said:

> What's LSM? This sounds like it can do what I want with rsync. Is it possible
 
> to add a new key token to init and have it propagate to all processes?

If that's the semantics you *REALLY* want, a better idea would probably be
to use loop-AES to encrypt an entire partition.

Note that this only works if your threat model reduces to "US vs THEM" (i.e.
"me vs whoever stole the laptop".  If you have more than one class of users
involved, you can't do it this way (and yes, there *do* exist threat models
where you want to make sure that even if the attacker manages to bypass
the file system permissions and get the contents of the file, they're still
useless...)

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: Proposal for keying encrypted filesystem

[Pierre Abbat]

On Friday 04 April 2003 09:01, Valdis.Kletnieks@vt.edu wrote:
> On Thu, 03 Apr 2003 18:22:11 EST, Pierre Abbat <phma@webjockey.net>  said:
> > What's LSM? This sounds like it can do what I want with rsync. Is it
> > possible
> >
> > to add a new key token to init and have it propagate to all processes?
>
> If that's the semantics you *REALLY* want, a better idea would probably be
> to use loop-AES to encrypt an entire partition.
>
> Note that this only works if your threat model reduces to "US vs THEM"
> (i.e. "me vs whoever stole the laptop".  If you have more than one class of
> users involved, you can't do it this way (and yes, there *do* exist threat
> models where you want to make sure that even if the attacker manages to
> bypass the file system permissions and get the contents of the file,
> they're still useless...)

That's a semantic that I'd like to be *possible*. It's not the one I want to 
use with rsync. For that I want to set the key in one process (the sshd on 
the backup server Bob that is forked when Alice starts rsync) and have all 
its children (which will just be rsync) but no one else be able to read the 
files.

But I'd also like to be able to have several encrypted directories on one 
partition, with different keys, such that when I give the key any process 
with the right UID can access them. I might have a cron job that needs access 
to encrypted data.

phma
-- 
.i toljundi do .ibabo mi'afra tu'a do
.ibabo damba do .ibabo do jinga
.icu'u la ma'atman.

Re: Proposal for keying encrypted filesystem

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 977 bytes --]

On Fri, 04 Apr 2003 09:30:29 EST, Pierre Abbat <phma@webjockey.net>  said:

> But I'd also like to be able to have several encrypted directories on one 
> partition, with different keys, such that when I give the key any process 
> with the right UID can access them. I might have a cron job that needs access
 
> to encrypted data.

You need to apply "least privilege" - you don't give the key to any process
that doesn't need it.  In your example, you would make sure that any process
running under UID nnn gets given the key, so that other processes couldn't
do anything even if they *did* access them.

Properly applied, you can even leverage it further - for instance, if your
backup process doesn't have the key tokens, you can safely let it have access
to all the files - it can read the 127 meg of data to back it up in a bitwise
manner, but it can't actually DO anything with the data - this is something
that you can't do in the "give everything the token" model....

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: Proposal for keying encrypted filesystem

[Pierre Abbat]

On Friday 04 April 2003 09:47, Valdis.Kletnieks@vt.edu wrote:
> Properly applied, you can even leverage it further - for instance, if your
> backup process doesn't have the key tokens, you can safely let it have
> access to all the files - it can read the 127 meg of data to back it up in
> a bitwise manner, but it can't actually DO anything with the data - this is
> something that you can't do in the "give everything the token" model....

Are you talking about the rsync process on Alice, the rsync process on Bob, or 
the process that Bob uses to make backups of all the encrypted backups that 
Alice and others entrust him with?

If a process that has no key tokens attempts to read an encrypted file with 
the ordinary syscalls, does it get an error or the ciphertext? Should there 
be a token that allows a process to read and write the ciphertext of an 
encrypted file? Will rsync need to be modified to be able to r/w the key ID 
of an encrypted file?

phma
-- 
.i toljundi do .ibabo mi'afra tu'a do
.ibabo damba do .ibabo do jinga
.icu'u la ma'atman.

Re: Proposal for keying encrypted filesystem

[Edward Shushkin]

Pierre Abbat wrote:
> 
> On Friday 04 April 2003 09:47, Valdis.Kletnieks@vt.edu wrote:
> > Properly applied, you can even leverage it further - for instance, if your
> > backup process doesn't have the key tokens, you can safely let it have
> > access to all the files - it can read the 127 meg of data to back it up in
> > a bitwise manner, but it can't actually DO anything with the data - this is
> > something that you can't do in the "give everything the token" model....
> 
> Are you talking about the rsync process on Alice, the rsync process on Bob, or
> the process that Bob uses to make backups of all the encrypted backups that
> Alice and others entrust him with?
> 
> If a process that has no key tokens attempts to read an encrypted file with
> the ordinary syscalls, does it get an error or the ciphertext?

Error. Wanna backup - give a valid key, and backups will be cpu-expensive.. 
Edward.

> Should there
> be a token that allows a process to read and write the ciphertext of an
> encrypted file? Will rsync need to be modified to be able to r/w the key ID
> of an encrypted file?
> 
> phma
> --
> .i toljundi do .ibabo mi'afra tu'a do
> .ibabo damba do .ibabo do jinga
> .icu'u la ma'atman.

Re: Proposal for keying encrypted filesystem

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 1089 bytes --]

On Fri, 04 Apr 2003 20:36:49 +0400, Edward Shushkin said:
> Pierre Abbat wrote:
> > 
> > On Friday 04 April 2003 09:47, Valdis.Kletnieks@vt.edu wrote:
 
> > If a process that has no key tokens attempts to read an encrypted file with
> > the ordinary syscalls, does it get an error or the ciphertext?
> 
> Error. Wanna backup - give a valid key, and backups will be cpu-expensive.. 

In this case, you want it to return the ciphertext, so the backup process can
run cheaply and securely.  Among other things, if somebody steals the backup
tapes, they can't restore your system image.....

And yes, this is a major issue for some sites - you've got some near-minimum
wage tape monkey taking your corporate data to the offsite vault, and you
want to be sure that even if he leaves with the tapes, it doesn't hurt you.

Having the backup read the ciphertext is more secure (and faster) than having
it encrypt on the way to the tape - among other things, this prevents the
underpaid tape monkey from bribing the encryption key for backups from the
backup admin, because they dont HAVE a key...

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: Proposal for keying encrypted filesystem

[Edward Shushkin]

Valdis.Kletnieks@vt.edu wrote:
> 
> On Fri, 04 Apr 2003 09:30:29 EST, Pierre Abbat <phma@webjockey.net>  said:
> 
> > But I'd also like to be able to have several encrypted directories on one
> > partition, with different keys, such that when I give the key any process
> > with the right UID can access them. I might have a cron job that needs access
> 
> > to encrypted data.
> 
> You need to apply "least privilege" - you don't give the key to any process
> that doesn't need it.  In your example, you would make sure that any process
> running under UID nnn gets given the key, so that other processes couldn't
> do anything even if they *did* access them.
> 
> Properly applied, you can even leverage it further - for instance, if your
> backup process doesn't have the key tokens, you can safely let it have access
> to all the files - it can read the 127 meg of data to back it up in a bitwise
> manner,

I am sorry, bitwise manner seems to be impossible in reiser4: the only access
to crypto files is via page cache, it requires a valid key..

Edward.


> but it can't actually DO anything with the data - this is something
> that you can't do in the "give everything the token" model....
> 
>   ----------------------------------------------------------------------------------------------------
>    Part 1.2Type: application/pgp-signature

Re: Proposal for keying encrypted filesystem

[Hans Reiser]

Edward Shushkin wrote:

>Valdis.Kletnieks@vt.edu wrote:
>  
>
>>On Fri, 04 Apr 2003 09:30:29 EST, Pierre Abbat <phma@webjockey.net>  said:
>>
>>    
>>
>>>But I'd also like to be able to have several encrypted directories on one
>>>partition, with different keys, such that when I give the key any process
>>>with the right UID can access them. I might have a cron job that needs access
>>>      
>>>
>>>to encrypted data.
>>>      
>>>
>>You need to apply "least privilege" - you don't give the key to any process
>>that doesn't need it.  In your example, you would make sure that any process
>>running under UID nnn gets given the key, so that other processes couldn't
>>do anything even if they *did* access them.
>>
>>Properly applied, you can even leverage it further - for instance, if your
>>backup process doesn't have the key tokens, you can safely let it have access
>>to all the files - it can read the 127 meg of data to back it up in a bitwise
>>manner,
>>    
>>
>
>I am sorry, bitwise manner seems to be impossible in reiser4: the only access
>to crypto files is via page cache, it requires a valid key..
>
this is not desirable.  Encypted files need to be backed up too...

>
>Edward.
>
>
>  
>
>>but it can't actually DO anything with the data - this is something
>>that you can't do in the "give everything the token" model....
>>
>>  ----------------------------------------------------------------------------------------------------
>>   Part 1.2Type: application/pgp-signature
>>    
>>
>
>
>  
>


-- 
Hans

Re: Proposal for keying encrypted filesystem

[Edward Shushkin]

Hans Reiser wrote:
> 
> Edward Shushkin wrote:
> 
> >Valdis.Kletnieks@vt.edu wrote:
> >
> >
> >>On Fri, 04 Apr 2003 09:30:29 EST, Pierre Abbat <phma@webjockey.net>  said:
> >>
> >>
> >>
> >>>But I'd also like to be able to have several encrypted directories on one
> >>>partition, with different keys, such that when I give the key any process
> >>>with the right UID can access them. I might have a cron job that needs access
> >>>
> >>>
> >>>to encrypted data.
> >>>
> >>>
> >>You need to apply "least privilege" - you don't give the key to any process
> >>that doesn't need it.  In your example, you would make sure that any process
> >>running under UID nnn gets given the key, so that other processes couldn't
> >>do anything even if they *did* access them.
> >>
> >>Properly applied, you can even leverage it further - for instance, if your
> >>backup process doesn't have the key tokens, you can safely let it have access
> >>to all the files - it can read the 127 meg of data to back it up in a bitwise
> >>manner,
> >>
> >>
> >
> >I am sorry, bitwise manner seems to be impossible in reiser4: the only access
> >to crypto files is via page cache, it requires a valid key..
> >
> this is not desirable.  

I understand, but direct io is incompatible with transaction semantics. On the
other hand, on the last seminar we made a conclusion to check key validness in 
oredr to avoid a possible security hole when read() first looks for uptodate
(decrypted!) pages in memory before reading encrypted data from disk..

> Encypted files need to be backed up too...

They will be as ordinary unix files..
Edward.

> 
> >
> >Edward.
> >
> >
> >
> >
> >>but it can't actually DO anything with the data - this is something
> >>that you can't do in the "give everything the token" model....
> >>
> >>  ----------------------------------------------------------------------------------------------------
> >>   Part 1.2Type: application/pgp-signature
> >>
> >>
> >
> >
> >
> >
> 
> --
> Hans

Re: Proposal for keying encrypted filesystem

[Hans Reiser]

Edward Shushkin wrote:

>Hans Reiser wrote:
>  
>
>>Edward Shushkin wrote:
>>
>>    
>>
>>>Valdis.Kletnieks@vt.edu wrote:
>>>
>>>
>>>      
>>>
>>>>On Fri, 04 Apr 2003 09:30:29 EST, Pierre Abbat <phma@webjockey.net>  said:
>>>>
>>>>
>>>>
>>>>        
>>>>
>>>>>But I'd also like to be able to have several encrypted directories on one
>>>>>partition, with different keys, such that when I give the key any process
>>>>>with the right UID can access them. I might have a cron job that needs access
>>>>>
>>>>>
>>>>>to encrypted data.
>>>>>
>>>>>
>>>>>          
>>>>>
>>>>You need to apply "least privilege" - you don't give the key to any process
>>>>that doesn't need it.  In your example, you would make sure that any process
>>>>running under UID nnn gets given the key, so that other processes couldn't
>>>>do anything even if they *did* access them.
>>>>
>>>>Properly applied, you can even leverage it further - for instance, if your
>>>>backup process doesn't have the key tokens, you can safely let it have access
>>>>to all the files - it can read the 127 meg of data to back it up in a bitwise
>>>>manner,
>>>>
>>>>
>>>>        
>>>>
>>>I am sorry, bitwise manner seems to be impossible in reiser4: the only access
>>>to crypto files is via page cache, it requires a valid key..
>>>
>>>      
>>>
>>this is not desirable.  
>>    
>>
>
>I understand, but direct io is incompatible with transaction semantics.
>
This means what?

> On the
>other hand, on the last seminar we made a conclusion to check key validness in 
>oredr to avoid a possible security hole when read() first looks for uptodate
>(decrypted!) pages in memory before reading encrypted data from disk..
>
So how about making a key of 0 be a special case which gets you the file 
in its encrypted form?

>
>  
>
>>Encypted files need to be backed up too...
>>    
>>
>
>They will be as ordinary unix files..
>
This means what?

>Edward.
>
>  
>
>>>Edward.
>>>
>>>
>>>
>>>
>>>      
>>>
>>>>but it can't actually DO anything with the data - this is something
>>>>that you can't do in the "give everything the token" model....
>>>>
>>>> ----------------------------------------------------------------------------------------------------
>>>>  Part 1.2Type: application/pgp-signature
>>>>
>>>>
>>>>        
>>>>
>>>
>>>
>>>      
>>>
>>--
>>Hans
>>    
>>
>
>
>  
>


-- 
Hans

Re: Proposal for keying encrypted filesystem

[Pierre Abbat]

On Friday 04 April 2003 13:45, Hans Reiser wrote:
> Edward Shushkin wrote:
> > On the
> >other hand, on the last seminar we made a conclusion to check key
> > validness in oredr to avoid a possible security hole when read() first
> > looks for uptodate (decrypted!) pages in memory before reading encrypted
> > data from disk..
>
> So how about making a key of 0 be a special case which gets you the file
> in its encrypted form?

Sounds good, but we need to limit who can access the ciphertext. Otherwise the 
tape monkey could get out his infinite typewriter and trash the backup.

Re: Proposal for keying encrypted filesystem

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 1577 bytes --]

On Fri, 04 Apr 2003 19:01:52 EST, Pierre Abbat <phma@webjockey.net>  said:
> On Friday 04 April 2003 13:45, Hans Reiser wrote:
> > Edward Shushkin wrote:
> > > On the
> > >other hand, on the last seminar we made a conclusion to check key
> > > validness in oredr to avoid a possible security hole when read() first
> > > looks for uptodate (decrypted!) pages in memory before reading encrypted
> > > data from disk..
> >
> > So how about making a key of 0 be a special case which gets you the file
> > in its encrypted form?
> 
> Sounds good, but we need to limit who can access the ciphertext. Otherwise th
e 
> tape monkey could get out his infinite typewriter and trash the backup.

I'm not sure what you mean here - do you mean:

a) Given sufficient ciphertext, an attack on the key and/or plaintext could
be mounted?  Possibly a known-plaintext attack if you can get the system to
cough up the crypted version of an inode that you know the contents of..

b) The tape monkey can create a bad backup by injecting corrupted/wrong
ciphertext which won't decrypt if it's reloaded to a disk.

c) Something else I've not thought of?

For the most part, (a) can be dealt with easily if you're using a sufficiently
strong symmetric cipher and proper key management - if the best known attacks
on the cipher require 2**80 blocks all encrypted with the same key, all you
have to do is to use a different key for each <small number of) terabytes.

Threat (b) has always been there - tape monkeys have ALWAYS had the ability
to swap a good backup tape for an intentionally borked one.

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: Proposal for keying encrypted filesystem

[Pierre Abbat]

[-- Attachment #1: signed data --]
[-- Type: text/plain, Size: 861 bytes --]

On Sunday 06 April 2003 20:44, Valdis Kletnieks wrote:
> On Fri, 04 Apr 2003 19:01:52 EST, Pierre Abbat <phma@webjockey.net>  said:
> > tape monkey could get out his infinite typewriter and trash the backup.
>
> I'm not sure what you mean here - do you mean:
>
> a) Given sufficient ciphertext, an attack on the key and/or plaintext could
> be mounted?  Possibly a known-plaintext attack if you can get the system to
> cough up the crypted version of an inode that you know the contents of..
>
> b) The tape monkey can create a bad backup by injecting corrupted/wrong
> ciphertext which won't decrypt if it's reloaded to a disk.
>
> c) Something else I've not thought of?

The tape monkey might could overwrite an encrypted file on disk with random 
gibberish.

phma
-- 
.i toljundi do .ibabo mi'afra tu'a do
.ibabo damba do .ibabo do jinga
.icu'u la ma'atman.

[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Proposal for keying encrypted filesystem

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 1139 bytes --]

On Sun, 06 Apr 2003 21:14:36 EDT, Pierre Abbat <phma@webjockey.net>  said:

> The tape monkey might could overwrite an encrypted file on disk with random 
> gibberish.

The problem we started discussing was that a backup system needs *read*
access to something isomorphic(*) to your data in order to back it up, but
you may not trust your tape monkey, backup software, or a myriad other things.

(*) The trick here is that we don't *actually* have to back up the data,
we need to back up something that will be a copy of the data once restored.
Properly done, the ciphertext of the data fulfills this requirement.

If your tape monkey has *write* access to the files, you're in trouble whether
or not it's encrypted.  Even in this case, encryption helps - if the tape
monkey manages to re-write a block with random gibberish, it will almost
certainly be noticed fairly quickly (Oracle complaining about corrupted
databases, a sudden 4K block of noise in the middle of a document, etc).
The tape monkey will almost certainly be blocked from doing something
subtle (like changing one block on an Oracle database so his salary goes
up 30%).


[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: Proposal for keying encrypted filesystem

[Hans Reiser]

Pierre Abbat wrote:

>On Friday 04 April 2003 13:45, Hans Reiser wrote:
>  
>
>>Edward Shushkin wrote:
>>    
>>
>>>On the
>>>other hand, on the last seminar we made a conclusion to check key
>>>validness in oredr to avoid a possible security hole when read() first
>>>looks for uptodate (decrypted!) pages in memory before reading encrypted
>>>data from disk..
>>>      
>>>
>>So how about making a key of 0 be a special case which gets you the file
>>in its encrypted form?
>>    
>>
>
>Sounds good, but we need to limit who can access the ciphertext. Otherwise the 
>tape monkey could get out his infinite typewriter and trash the backup.
>
>
>
>  
>
I don't understand you.  The tape operator can use bad tape and trash 
the backup that way also....

-- 
Hans

Re: Proposal for keying encrypted filesystem

[Edward Shushkin]

Hans Reiser wrote:
> 
> Edward Shushkin wrote:

> > On the
> >other hand, on the last seminar we made a conclusion to check key validness in
> >oredr to avoid a possible security hole when read() first looks for uptodate
> >(decrypted!) pages in memory before reading encrypted data from disk..
> >
> So how about making a key of 0 be a special case which gets you the file
> in its encrypted form?
> 

Let's rather use special flags of reiser4_open() system call, or something
else instead of new special keys. 
So everyone want:
1) To make cheap backup (without decryption/encryption been involved)
   of ciphertext possible. 
2) To make this	backup possible for everyone who has appropriate
   permissions but doesn't have a secret key. 

I think that read/write methods for crypto files may ignore page cache which
contains decrypted data, if the appropriate reiser4-specific flag O_SDIRECT
is present, so read() will copy the ciphertext to user right from leaf nodes,
and write() will insert the ciphertext from user right to the balanced tree.
Thus, perhaps (1) is possible, *BUT* don't forget that file is stored on disk
as a set of compressed clusters, so all the data clustering issues which was
invisible in kernel will go to user's hassle, so in order to backup file user
will need to do something very unusual like the following:

/* cheap backup routine (draft without key management) */

int fd_src, fd_dst, i, bytes;
off_t fsize, cluster_size;
struct crypt_key * src_key, dst_key;
struct stat * fstat;
char * buf;

/* open the file we want to backup */
fd_src = reiser4_open(src_filename, O_RDONLY | O_SDIRECT, src_key);

/* get src file attributes */
fstat(fd_src, fstat); 

fsize = fstat->st_size;
cluster_size = fstat->st_cluster; /* reiser4 specific attribute */

/* create a new crypto-file with the same cluster_size for backup */
fd_dst = reiser4_open(dst_filename, O_CREAT | O_WRONLY | O_SDIRECT, dst_key, cluster_size);  

buf = malloc(cluster_size);

for (i = 0; i <= fsize/cluster_size; i++) {
    bytes = read(fd_src, buf, cluster_size);
    if (bytes == -1) {
	perror("read failed");
	exit();
    }      	  
    if (write(fd_dst, buf, bytes) != bytes){
        perror("write failed");
	exit();
    }	
    lseek(fd_dst, cluster_size - bytes, SEEK_CUR);
}
free(buf);
close(fd_src);
close(fd_dst);
    	  
Basically the usage of all file syscalls will be senseless for the
files opened with O_SDIRECT flag (it can be applied only in some
operations which are going per cluster), moreover it will be easy to
corrupt this files if they are not readonly. So (1) is possible with
additional kernel support and inflated user's hassle. 
 
The (2) remains to be impossible, since after the file was opened with 
O_SDIRECT flag, its *decrypted* data can be mapped into memory by mmap()
which looks to the page cache, so anyway cheap backup can be done only
by secret/share key owner. 
Suggestions?

Edward.

Re: Proposal for keying encrypted filesystem

[Hans Reiser]

Edward Shushkin wrote:

>Hans Reiser wrote:
>  
>
>>Edward Shushkin wrote:
>>    
>>
>
>  
>
>>>On the
>>>other hand, on the last seminar we made a conclusion to check key validness in
>>>oredr to avoid a possible security hole when read() first looks for uptodate
>>>(decrypted!) pages in memory before reading encrypted data from disk..
>>>
>>>      
>>>
>>So how about making a key of 0 be a special case which gets you the file
>>in its encrypted form?
>>
>>    
>>
>
>Let's rather use special flags of reiser4_open() system call, or something
>
People don't want a reiser4_open() system call.  Nobody wants to rewrite 
an application like cp to be crypto aware.  You need to create a current 
working key, or find out what LSM does.

>else instead of new special keys. 
>So everyone want:
>1) To make cheap backup (without decryption/encryption been involved)
>   of ciphertext possible. 
>2) To make this	backup possible for everyone who has appropriate
>   permissions but doesn't have a secret key. 
>
>I think that read/write methods for crypto files may ignore page cache which
>contains decrypted data, if the appropriate reiser4-specific flag O_SDIRECT
>is present, so read() will copy the ciphertext to user right from leaf nodes,
>and write() will insert the ciphertext from user right to the balanced tree.
>Thus, perhaps (1) is possible, *BUT* don't forget that file is stored on disk
>as a set of compressed clusters, so all the data clustering issues which was
>invisible in kernel will go to user's hassle, so in order to backup file user
>will need to do something very unusual like the following:
>
>/* cheap backup routine (draft without key management) */
>
>int fd_src, fd_dst, i, bytes;
>off_t fsize, cluster_size;
>struct crypt_key * src_key, dst_key;
>struct stat * fstat;
>char * buf;
>
>/* open the file we want to backup */
>fd_src = reiser4_open(src_filename, O_RDONLY | O_SDIRECT, src_key);
>
>/* get src file attributes */
>fstat(fd_src, fstat); 
>
>fsize = fstat->st_size;
>cluster_size = fstat->st_cluster; /* reiser4 specific attribute */
>
>/* create a new crypto-file with the same cluster_size for backup */
>fd_dst = reiser4_open(dst_filename, O_CREAT | O_WRONLY | O_SDIRECT, dst_key, cluster_size);  
>
>buf = malloc(cluster_size);
>
>for (i = 0; i <= fsize/cluster_size; i++) {
>    bytes = read(fd_src, buf, cluster_size);
>    if (bytes == -1) {
>	perror("read failed");
>	exit();
>    }      	  
>    if (write(fd_dst, buf, bytes) != bytes){
>        perror("write failed");
>	exit();
>    }	
>    lseek(fd_dst, cluster_size - bytes, SEEK_CUR);
>}
>free(buf);
>close(fd_src);
>close(fd_dst);
>    	  
>Basically the usage of all file syscalls will be senseless for the
>files opened with O_SDIRECT flag (it can be applied only in some
>operations which are going per cluster), moreover it will be easy to
>corrupt this files if they are not readonly. So (1) is possible with
>additional kernel support and inflated user's hassle. 
> 
>The (2) remains to be impossible, since after the file was opened with 
>O_SDIRECT flag, its *decrypted* data can be mapped into memory by mmap()
>which looks to the page cache, so anyway cheap backup can be done only
>by secret/share key owner. 
>Suggestions?
>
>Edward.
>
>
>  
>


-- 
Hans

Re: Proposal for keying encrypted filesystem

[Pierre Abbat]

On Monday 07 April 2003 14:38, Edward Shushkin wrote:
> Hans Reiser wrote:
> > Edward Shushkin wrote:
> > > On the
> > >other hand, on the last seminar we made a conclusion to check key
> > > validness in oredr to avoid a possible security hole when read() first
> > > looks for uptodate (decrypted!) pages in memory before reading
> > > encrypted data from disk..
> >
> > So how about making a key of 0 be a special case which gets you the file
> > in its encrypted form?
>
> Let's rather use special flags of reiser4_open() system call, or something
> else instead of new special keys.
> So everyone want:
> 1) To make cheap backup (without decryption/encryption been involved)
>    of ciphertext possible.
> 2) To make this	backup possible for everyone who has appropriate
>    permissions but doesn't have a secret key.

If we have a special flag of the reiser4_open() call, it has to be 
encapsulated into a special program. We can't expect every program in the 
world to know how to do a reiser4_open.

If I understand right, encrypted files are compressed before encryption, so 
they consist (usually) of blocks of <4K each with their start points every 
multiple of 4K. A normal read() on a file like that will read as if the block 
were padded with zeros, I think we need a tar-like program that turns such a 
file of short blocks into some format that other programs can deal with.

Re: Proposal for keying encrypted filesystem

[Edward Shushkin]

Pierre Abbat wrote:
> 
> On Monday 07 April 2003 14:38, Edward Shushkin wrote:
> > Hans Reiser wrote:
> > > Edward Shushkin wrote:
> > > > On the
> > > >other hand, on the last seminar we made a conclusion to check key
> > > > validness in oredr to avoid a possible security hole when read() first
> > > > looks for uptodate (decrypted!) pages in memory before reading
> > > > encrypted data from disk..
> > >
> > > So how about making a key of 0 be a special case which gets you the file
> > > in its encrypted form?
> >
> > Let's rather use special flags of reiser4_open() system call, or something
> > else instead of new special keys.
> > So everyone want:
> > 1) To make cheap backup (without decryption/encryption been involved)
> >    of ciphertext possible.
> > 2) To make this       backup possible for everyone who has appropriate
> >    permissions but doesn't have a secret key.
> 
> If we have a special flag of the reiser4_open() call, it has to be
> encapsulated into a special program. We can't expect every program in the
> world to know how to do a reiser4_open.
> 

Sure, it will be so.. I didn't encapsulate it to not obscure main sense ;)

> If I understand right, encrypted files are compressed before encryption,

Yes.

> so they consist (usually) of blocks of <4K each with their start points every
> multiple of 4K.

Yes. To be precisely, multiple of cluster size, which is 4,8,16,32,..K

> A normal read() on a file like that will read as if the block
> were padded with zeros, 

Only if it is a hole. In accordance with current policy, the file system
recognize a hole cluster by absence of the item with appropriate offset,
so fast backup will write nothing but real compressed data

> I think we need a tar-like program that turns such a
> file of short blocks into some format that other programs can deal with.