authenticated file systems using HMAC(SHA256)

authenticated file systems using HMAC(SHA256)

[Chris Murphy]

Hi,

What's the status of this work?
https://lore.kernel.org/linux-btrfs/20191015121405.19066-1-jthumshirn@suse.de/

Also I'm curious if it could use blake2b as an option? It's a bit
faster I guess.

Thanks,

-- 
Chris Murphy

Re: authenticated file systems using HMAC(SHA256)

[Johannes Thumshirn]

On 07/04/2020 20:02, Chris Murphy wrote:
> Hi,
> 
> What's the status of this work?
> https://lore.kernel.org/linux-btrfs/20191015121405.19066-1-jthumshirn@suse.de/

It's done but no-one was interested in it and as I haven't received any 
answers from Dave if he's going to merge it, I did not bring it to 
attention again. After all it was for a specific use-case SUSE has/had 
and I left the company.

> Also I'm curious if it could use blake2b as an option? It's a bit
> faster I guess.

Probably yes, I haven't researched if blake2b can be used in a HMAC 
context, but from what I can see there should be no problem. SHA-256 was 
chooses because SUSE Product Management needed SHA for their use-case.

If there is still interest in this work I can re-base my branches [1][2] 
and add blake2b as well, this /should/ be trivially done.

[1] 
https://git.kernel.org/pub/scm/linux/kernel/git/jth/linux.git/log/?h=btrfs-integrity
[2] https://github.com/morbidrsa/btrfs-progs/tree/mkfs-hmac

I just don't want to spend time on it again when it's not going to be 
merged in the end (for what ever reason).

Byte,
	Johannes

Re: authenticated file systems using HMAC(SHA256)

[Chris Murphy]

On Wed, Apr 8, 2020 at 5:17 AM Johannes Thumshirn
<Johannes.Thumshirn@wdc.com> wrote:
>
> On 07/04/2020 20:02, Chris Murphy wrote:
> > Hi,
> >
> > What's the status of this work?
> > https://lore.kernel.org/linux-btrfs/20191015121405.19066-1-jthumshirn@suse.de/
>
> It's done but no-one was interested in it and as I haven't received any
> answers from Dave if he's going to merge it, I did not bring it to
> attention again. After all it was for a specific use-case SUSE has/had
> and I left the company.

I'm thinking of a way to verify that a non-encrypted generic
boot+startup data hasn't been tampered with. That is, a generic,
possibly read-only boot, can be authenticated on the fly. Basically,
it's fs-verity for Btrfs, correct?

Other use cases?


> If there is still interest in this work I can re-base my branches [1][2]
> and add blake2b as well, this /should/ be trivially done.
>
> [1]
> https://git.kernel.org/pub/scm/linux/kernel/git/jth/linux.git/log/?h=btrfs-integrity
> [2] https://github.com/morbidrsa/btrfs-progs/tree/mkfs-hmac

I think 'btrfs check' also needs to be fed the hmac in order to verify
checksums and also rewrite out a new csum or extent tree and do
repairs?

> I just don't want to spend time on it again when it's not going to be
> merged in the end (for what ever reason).

Sure. Seems reasonable.

-- 
Chris Murphy

Re: authenticated file systems using HMAC(SHA256)

[Johannes Thumshirn]

On 09/04/2020 02:18, Chris Murphy wrote:
> On Wed, Apr 8, 2020 at 5:17 AM Johannes Thumshirn
> <Johannes.Thumshirn@wdc.com> wrote:
>>
>> On 07/04/2020 20:02, Chris Murphy wrote:
>>> Hi,
>>>
>>> What's the status of this work?
>>> https://lore.kernel.org/linux-btrfs/20191015121405.19066-1-jthumshirn@suse.de/
>>
>> It's done but no-one was interested in it and as I haven't received any
>> answers from Dave if he's going to merge it, I did not bring it to
>> attention again. After all it was for a specific use-case SUSE has/had
>> and I left the company.
> 
> I'm thinking of a way to verify that a non-encrypted generic
> boot+startup data hasn't been tampered with. That is, a generic,
> possibly read-only boot, can be authenticated on the fly. Basically,
> it's fs-verity for Btrfs, correct?
> 

Correct, example deployments would be embedded devices, or container 
images. I've written a paper [1] for the 2019 SUSE Labs Conference 
describing some of the scenarios, if you're interested.

> Other use cases?
> 
> 
>> If there is still interest in this work I can re-base my branches [1][2]
>> and add blake2b as well, this /should/ be trivially done.
>>
>> [1]
>> https://git.kernel.org/pub/scm/linux/kernel/git/jth/linux.git/log/?h=btrfs-integrity
>> [2] https://github.com/morbidrsa/btrfs-progs/tree/mkfs-hmac
> 
> I think 'btrfs check' also needs to be fed the hmac in order to verify
> checksums and also rewrite out a new csum or extent tree and do
> repairs?

Check yes, I'm not so much with you with repairs. If a hmac of a block 
is corrupt, something altered the on-disk data, somehow. Either it's a 
bad block on disk or an attack. You can't be sure the data is still trusted.

> 
>> I just don't want to spend time on it again when it's not going to be
>> merged in the end (for what ever reason).
> 
> Sure. Seems reasonable.
> 

Let me see if I can carve out some time for this end of next week to 
re-base what I had.

Maybe having someone in the community being interested in this work can 
accelerate it's upstream acceptance.

[1] https://github.com/morbidrsa/btrfs-integrity-paper

Byte,
	Johannes

Re: authenticated file systems using HMAC(SHA256)

[Chris Murphy]

On Thu, Apr 9, 2020 at 2:50 AM Johannes Thumshirn
<Johannes.Thumshirn@wdc.com> wrote:
>
> On 09/04/2020 02:18, Chris Murphy wrote:
> > On Wed, Apr 8, 2020 at 5:17 AM Johannes Thumshirn
> > <Johannes.Thumshirn@wdc.com> wrote:
> >>
> >> On 07/04/2020 20:02, Chris Murphy wrote:
> >>> Hi,
> >>>
> >>> What's the status of this work?
> >>> https://lore.kernel.org/linux-btrfs/20191015121405.19066-1-jthumshirn@suse.de/
> >>
> >> It's done but no-one was interested in it and as I haven't received any
> >> answers from Dave if he's going to merge it, I did not bring it to
> >> attention again. After all it was for a specific use-case SUSE has/had
> >> and I left the company.
> >
> > I'm thinking of a way to verify that a non-encrypted generic
> > boot+startup data hasn't been tampered with. That is, a generic,
> > possibly read-only boot, can be authenticated on the fly. Basically,
> > it's fs-verity for Btrfs, correct?
> >
>
> Correct, example deployments would be embedded devices, or container
> images. I've written a paper [1] for the 2019 SUSE Labs Conference
> describing some of the scenarios, if you're interested.

"downside to this is, on every unmount, the new hash value needs to be
stored safely" [in e.g. a TPM]

Could this make the file system not crash safe? As in, would you use
authenticated btrfs in a read-only context, like seed-device? Or some
industrial application where you're very, very certain, that the use
case never calls for unplanned power failure or forced power off by a
user? Seems difficult to use it in a desktop or laptop use case.


-- 
Chris Murphy

Re: authenticated file systems using HMAC(SHA256)

[Chris Murphy]

On Thu, Apr 9, 2020 at 6:31 PM Chris Murphy <lists@colorremedies.com> wrote:
>
> On Thu, Apr 9, 2020 at 2:50 AM Johannes Thumshirn
> <Johannes.Thumshirn@wdc.com> wrote:
> >
> > On 09/04/2020 02:18, Chris Murphy wrote:
> > > On Wed, Apr 8, 2020 at 5:17 AM Johannes Thumshirn
> > > <Johannes.Thumshirn@wdc.com> wrote:
> > >>
> > >> On 07/04/2020 20:02, Chris Murphy wrote:
> > >>> Hi,
> > >>>
> > >>> What's the status of this work?
> > >>> https://lore.kernel.org/linux-btrfs/20191015121405.19066-1-jthumshirn@suse.de/
> > >>
> > >> It's done but no-one was interested in it and as I haven't received any
> > >> answers from Dave if he's going to merge it, I did not bring it to
> > >> attention again. After all it was for a specific use-case SUSE has/had
> > >> and I left the company.
> > >
> > > I'm thinking of a way to verify that a non-encrypted generic
> > > boot+startup data hasn't been tampered with. That is, a generic,
> > > possibly read-only boot, can be authenticated on the fly. Basically,
> > > it's fs-verity for Btrfs, correct?
> > >
> >
> > Correct, example deployments would be embedded devices, or container
> > images. I've written a paper [1] for the 2019 SUSE Labs Conference
> > describing some of the scenarios, if you're interested.
>
> "downside to this is, on every unmount, the new hash value needs to be
> stored safely" [in e.g. a TPM]
>
> Could this make the file system not crash safe? As in, would you use
> authenticated btrfs in a read-only context, like seed-device? Or some
> industrial application where you're very, very certain, that the use
> case never calls for unplanned power failure or forced power off by a
> user? Seems difficult to use it in a desktop or laptop use case.

Nevermind... :D

\subsubsection{HMAC}

I'm just gonna read the whole thing.


-- 
Chris Murphy

Re: authenticated file systems using HMAC(SHA256)

[Chris Murphy]

On Thu, Apr 9, 2020 at 6:32 PM Chris Murphy <lists@colorremedies.com> wrote:
>
> On Thu, Apr 9, 2020 at 6:31 PM Chris Murphy <lists@colorremedies.com> wrote:
> >
> > On Thu, Apr 9, 2020 at 2:50 AM Johannes Thumshirn
> > <Johannes.Thumshirn@wdc.com> wrote:
> > >
> > > On 09/04/2020 02:18, Chris Murphy wrote:
> > > > On Wed, Apr 8, 2020 at 5:17 AM Johannes Thumshirn
> > > > <Johannes.Thumshirn@wdc.com> wrote:
> > > >>
> > > >> On 07/04/2020 20:02, Chris Murphy wrote:
> > > >>> Hi,
> > > >>>
> > > >>> What's the status of this work?
> > > >>> https://lore.kernel.org/linux-btrfs/20191015121405.19066-1-jthumshirn@suse.de/
> > > >>
> > > >> It's done but no-one was interested in it and as I haven't received any
> > > >> answers from Dave if he's going to merge it, I did not bring it to
> > > >> attention again. After all it was for a specific use-case SUSE has/had
> > > >> and I left the company.
> > > >
> > > > I'm thinking of a way to verify that a non-encrypted generic
> > > > boot+startup data hasn't been tampered with. That is, a generic,
> > > > possibly read-only boot, can be authenticated on the fly. Basically,
> > > > it's fs-verity for Btrfs, correct?
> > > >
> > >
> > > Correct, example deployments would be embedded devices, or container
> > > images. I've written a paper [1] for the 2019 SUSE Labs Conference
> > > describing some of the scenarios, if you're interested.
> >
> > "downside to this is, on every unmount, the new hash value needs to be
> > stored safely" [in e.g. a TPM]
> >
> > Could this make the file system not crash safe? As in, would you use
> > authenticated btrfs in a read-only context, like seed-device? Or some
> > industrial application where you're very, very certain, that the use
> > case never calls for unplanned power failure or forced power off by a
> > user? Seems difficult to use it in a desktop or laptop use case.
>
> Nevermind... :D
>
> \subsubsection{HMAC}
>
> I'm just gonna read the whole thing.


"the used key has to be deployed at File System creation time and
cannot easily be modified afterwards"

Could a new HMAC be defined when adding a rw sprout device to a seed?
i.e. in this case you'd need two HMACs, until the seed device is
removed. Hmmm, maybe difficult. I don't think data checksums are
recomputed on seed being removed; the balance replicated metadata
block groups fairly intact including the csum tree.

Regarding the key being stored in the TPM. I know the Windows 10
hardware requirements say a TPM 2.0 must be present and enabled. But I
don't know to what degree such hardware is prevalent and supported by
the kernel.


-- 
Chris Murphy

Re: authenticated file systems using HMAC(SHA256)

[Johannes Thumshirn]

On 10/04/2020 03:35, Chris Murphy wrote:
> Regarding the key being stored in the TPM. I know the Windows 10
> hardware requirements say a TPM 2.0 must be present and enabled. But I
> don't know to what degree such hardware is prevalent and supported by
> the kernel.

In the end, btrfs doesn't care where the key is stored, it just needs to 
be accessible from the kernel's keyring.

Re: authenticated file systems using HMAC(SHA256)

[Christoph Anton Mitterer]

On Thu, 2020-04-09 at 08:50 +0000, Johannes Thumshirn wrote:
> Maybe having someone in the community being interested in this work
> can 
> accelerate it's upstream acceptance.

I think it would be great having something like this in btrfs.


If this was to be merged, it would perhaps make sense to have it
audited by a number of crypto experts.


And also, to clearly specify what it can to and what not:
- like how it behaves with other features of btrfs (compression, raid,
  repair, etc.)
- limitations (e.g. fs-verity was just read-only, wasn't it?!)
- what exactly does it protect?
  - "just" the content of files (i.e. a file with invalid HMAC will be 
    detected)
  - file metadata (dates, names, permissions, owners, xattrs, etc)
  - the file hirarchy (location of the files in the tree)
  - would files removed/added (by an attacker) be detected



Cheers,
Chris.

Re: authenticated file systems using HMAC(SHA256)

[Johannes Thumshirn]

On 14/04/2020 06:06, Christoph Anton Mitterer wrote:
> On Thu, 2020-04-09 at 08:50 +0000, Johannes Thumshirn wrote:
>> Maybe having someone in the community being interested in this work
>> can
>> accelerate it's upstream acceptance.
> 
> I think it would be great having something like this in btrfs.
> 
> 
> If this was to be merged, it would perhaps make sense to have it
> audited by a number of crypto experts.

Sure.

> And also, to clearly specify what it can to and what not:
> - like how it behaves with other features of btrfs (compression, raid,
>    repair, etc.)
> - limitations (e.g. fs-verity was just read-only, wasn't it?!)

Yes fs-verify is read-only, this btrfs version of it is read-write if 
you have the key as it (ab)uses btrfs' internal checksums for the 
protection information and does not relay on merkle trees in extended 
attributes or other additional on-disk data.

> - what exactly does it protect?
>    - "just" the content of files (i.e. a file with invalid HMAC will be
>      detected)
>    - file metadata (dates, names, permissions, owners, xattrs, etc)
>    - the file hirarchy (location of the files in the tree)
>    - would files removed/added (by an attacker) be detected

It protects the file's contents as well as the metadata. Btrfs uses 
'struct btrfs_header' as a start of every tree block. This header starts 
with a checksum, so the contents of every tree block are verified. The 
super-block also has a checksum, which is generated by the same scheme. 
Furthermore every data block (file content) is added to the checksum 
tree which also uses this checksum scheme. By exchanging the checksum to 
a keyed hash, one would need the key to make any modification to the 
file-system and as checksums are a first class citizen in btrfs no 
changes are needed to other features. If you mount your file system with 
nodatasum, you loose data verification though, but that's kind of obvious.

Byte,
	Johannes

Re: authenticated file systems using HMAC(SHA256)

[David Sterba]

On Tue, Apr 07, 2020 at 12:02:30PM -0600, Chris Murphy wrote:
> Hi,
> 
> What's the status of this work?
> https://lore.kernel.org/linux-btrfs/20191015121405.19066-1-jthumshirn@suse.de/
> 
> Also I'm curious if it could use blake2b as an option? It's a bit
> faster I guess.

I don't have any objections against the feature but I don't find the
specification complete enough, and there was no response when it was
first sent. The feature itself is not something trivial or small-size so
feedback is always welcome. It's happening now, which is great, and once
we have the missing bits I'll go and merge it.

My checklist so far:

- blake2b needs to be supported as well
- the HMAC must match the kernel implementation
- naming of the new checksums (hmac-sha256 or hmac-blake2 should be ok)
- key specification via mount option
- all progs must work with filesystems with the keyed hash, so how to
  specify the auth key in a consistent way

Usecase questions:

- what to do if the key is not available, allow read-only mount, or
  provide rescue= option to ignore checksum failures?
- support seeding device?

And also document the the expected usecase and guarantees in case we ask
somebody to do the crypto/security audit. As long as we use sandard
primitives or components (eg. keyctl interface) it's the high-level
usage that needs to be checked. The paper
https://github.com/morbidrsa/btrfs-integrity-paper covers that, so that
helps.

Re: authenticated file systems using HMAC(SHA256)

[Johannes Thumshirn]

On 08/04/2020 13:17, Johannes Thumshirn wrote:
>> Also I'm curious if it could use blake2b as an option? It's a bit
>> faster I guess.
> Probably yes, I haven't researched if blake2b can be used in a HMAC
> context, but from what I can see there should be no problem. SHA-256 was
> chooses because SUSE Product Management needed SHA for their use-case.
> 
> If there is still interest in this work I can re-base my branches [1][2]
> and add blake2b as well, this/should/  be trivially done.

So I've re-based my kernel and btrfs-progs branches and saw that David 
added support for libgcrypt and libsodium as optional crypto 
implementations (awesome btw, thanks David!).

I've provided a libsodium based hmac(sha256) version in progs as well 
now. But a hmac(blake2b) is neither implemented in libgcrypt nor in 
libsodium and I think we don't want to roll our own crypto in btrfs-progs.

Re: authenticated file systems using HMAC(SHA256)

[Nikolay Borisov]

On 16.04.20 г. 17:24 ч., David Sterba wrote:
> naming of the new checksums (hmac-sha256 or hmac-blake2 should be ok)> - key specification via mount option

But the key shouldn't really be visible in /proc/mounts since it's
readable by ordinary users, god knows how many more pseudo files there
are which can provide the same situation. If the specification of the
key is a reference to a loaded key then yes but otherwise I think that's
a security risk, unless it's possible to hide passed options from
/proc/mounts i.e pass it but make it internal to the filesystem ?


> - all progs must work with filesystems with the keyed hash, so how to
>   specify the auth key in a consistent way

Re: authenticated file systems using HMAC(SHA256)

[Johannes Thumshirn]

On 24/04/2020 11:37, Nikolay Borisov wrote:
> 
> 
> On 16.04.20 г. 17:24 ч., David Sterba wrote:
>> naming of the new checksums (hmac-sha256 or hmac-blake2 should be ok)> - key specification via mount option
> 
> But the key shouldn't really be visible in /proc/mounts since it's
> readable by ordinary users, god knows how many more pseudo files there
> are which can provide the same situation. If the specification of the
> key is a reference to a loaded key then yes but otherwise I think that's
> a security risk, unless it's possible to hide passed options from
> /proc/mounts i.e pass it but make it internal to the filesystem ?

No the key won't ever be passed to the mount command, only the key id:

keyctl add logon btrfs:foo 0123456 @u
mount -t btrfs -o auth_key=btrfs:foo /dev/disk /mnt/point

So /proc/mounts would only show the key id anyways.

I think this is fine.

Re: authenticated file systems using HMAC(SHA256)

[Nikolay Borisov]

On 24.04.20 г. 12:46 ч., Johannes Thumshirn wrote:
> On 24/04/2020 11:37, Nikolay Borisov wrote:
>>
>>
>> On 16.04.20 г. 17:24 ч., David Sterba wrote:
>>> naming of the new checksums (hmac-sha256 or hmac-blake2 should be ok)> - key specification via mount option
>>
>> But the key shouldn't really be visible in /proc/mounts since it's
>> readable by ordinary users, god knows how many more pseudo files there
>> are which can provide the same situation. If the specification of the
>> key is a reference to a loaded key then yes but otherwise I think that's
>> a security risk, unless it's possible to hide passed options from
>> /proc/mounts i.e pass it but make it internal to the filesystem ?
> 
> No the key won't ever be passed to the mount command, only the key id:
> 
> keyctl add logon btrfs:foo 0123456 @u
> mount -t btrfs -o auth_key=btrfs:foo /dev/disk /mnt/point
> 
> So /proc/mounts would only show the key id anyways.
> 
> I think this is fine.
> 

That's fine, yes.