Hi Eric- I'm trying to construct a viable IMA metadata format (ie, what goes into security.ima) to support Merkle trees. Rather than storing an entire Merkle tree per file, Mimi would like to have a metadata format that can store the root hash of a Merkle tree. Instead of reading the whole tree, an NFS client (for example) would generate the parts of the file's fs-verity Merkle tree on-demand. The tree itself would not be exposed or transported by the NFS protocol. Following up with the recent thread on linux-integrity, starting here: https://lore.kernel.org/linux-integrity/1597079586.3966.34.camel@xxxxxxxxxxxxxxxxxxxxx/t/#u I think the following will be needed. 1. The parameters for (re)constructing the Merkle tree: - The name of the digest algorithm - The unit size represented by each leaf in the tree - The depth of the finished tree - The size of the file - Perhaps a salt value - Perhaps the file's mtime at the time the hash was computed - The root hash 2. A fingerprint of the signer: - The name of the digest algorithm - The digest of the signer's certificate 3. The signature - The name of the signature algorithm - The signature, computed over 1. Does this seem right to you? There has been some controversy about whether to allow the metadata to be unsigned. It can't ever be unsigned for NFS files, but some feel that on a physically secure local-only set up, signatures could be unnecessary overhead. I'm not convinced, and believe the metadata should always be signed: that's the only way to guarantee end-to-end integrity, which includes protection of the content's provenance, no matter how it is stored. -- Chuck Lever
