feature: use keyed HMAC for checksum

[jowagner]

Overview

The inclusion of cryptographic-strength hash functions as checksum algorithms suggests that (some) users want maximum protection of filesystem metadata against manipulation. The current support for key-less/unseeded hash functions improves protection compared to CRC32C and 64-bit XXHASH but cannot detect specific, malicious manipulation that adjusts the checksum to match the manipulated payload.

Suggestion

The next logical step is to allow users to use a keyed HMAC for checksum calculation such that an adversary without access to the key cannot manipulate metadata blocks without corrupting the checksum, other than replaying a different metadata block recorded in the past, see issue #451.

The key must be provided for mkfs.btrfs, mount and tools that work with unmounted filesystem such as btrfs check.

Questions:

• Does the fact that filesystem UUID and virtual block address are part of every node mean that there is no gain from adding them to the key as well or would this have an advantage?
• The transid provides some protection against replaying old blocks. Could this be improved, e.g. should all log_2(N) ancestor blocks be updated on each modification of a node such that each node on the path knows what transid values its children are supposed to have?

TODO

This feature request probably needs to go into the kernel bugzilla and/or the btrfs project ideas page.

[Zygo]

Is this reinventing authenticated btrfs?

[kdave]

It's among planned 'as time permits' features, the remaining work is in the interface of progs and the way the key material is supposed to be used from kernel. The initial implementation was limited only to the 'login:' keyring which is not very flexible, I have a prototype that can use other keyrings, or fd, or raw bytes, possibly extensible with other key types like encrypted key (that the linux crypto subsystem supports with TPM modules).