[WIP] Securing EVE Logs

[shjala]

---

• secure-logs : add implementation of FssAgg 7151bd48c6a137819bf6b2cfc1231c879ab9f348 Add implementation "Forward-secure sequential aggregate authentication.", this is testable using https://github.com/shjala/adam/commit/478cd64c40e279331f4f8dc0a0dadaab00af3dde

• evetpm : update seal/unseal functions signature 4f2137249d10d7be7327a8a85df796ce1251d6fb Update the Seal/Unseal disk key functions to be generic and accept TPM NV indexes as parameters. These functions are not bound to just store and retrieve disk keys, and this modification makes it obvious.

---

TODO :

• [x] performance cost
• [x] success test with collect logs and verify
• [x] success test with collect logs and verify (multiple gzip files)
• [x] fail test with tampering (content)
• [x] fail test with tampering (delete from the middle)
• [x] fail test with tampering (delete from the tail)
• [x] save num key evolve in the batch metadata
• [x] each log entry in a batch should have seq number so we can verify it.
• [ ] initial key management (PCR bound, read lock, backed up in the controler)
• [ ] will adding delete detection in the next version breaks logging?
• [ ] EVE API changes
• [ ] secure log switch in config
• [ ] enable logging for ssh
• [ ] enable logging for edgeview
• [ ] documentation

[shjala]

The forward chaining to generate a key for block N+1 from content in block N is secure and simple. But it has an issue if a block is missing (for instance due to running out of space for logs while being disconnected). In such a case it would be nice if an admin could validate that it is ok that 1 (or k) blocks where dropped and still have some forward chaining.

I'm not aware of any cryptographic schema that allows that, detecting tampering with the order or breaking the chain in general relies on lost information. If a block is missing, there is nothing to tell us it happened because someone wanted to cover their tracks or disk was full. If we want have the ability to skip logs, then we have to define triggers for certain events that might cause log related failure and then reset the chain from that point on (start a new independently verifiable chain) and then somehow securely tell the verifier this is a new chain, this can quickly lead to a lot of complications.

I'm aware of some cryptographic schemas called seekable key generators which in theory should let us verify each log entry individually, and offers forward secure, but not protection against order or deleting logs from the middle of the chain.

Here the aggregated MAC of log N is based HMAC of content of N-1 past logs. So if just one block is missing, we can't verify the final aggregated MAC. To reduce the issues of missing logs, I'm aiming to add the MAC and chaining related data in the last stage (in doMoveCompressFile) only to the gzipped logs, so we don't end up with missing logs and each gzip file is individually verifiable and any missing or modified logs is an indication of tampering. sure this is not ideal (not yet gzipped logs are not protected) but we can play with the risk factor by gzipping logs more often. https://github.com/lf-edge/eve/blob/e2a67f53647a986861a5173f0dc6ec948e7a7a7e/pkg/newlog/cmd/newlogd.go#L1102C1-L1134

Would we get sufficient forward chaining if we include the block number (N) in how the key is generated? If so, then the verifier can detect that a block N+1 is missing by looking at the sequence numbers, but they calculate the key used to verify block N+2 and following.

As far as I'm aware, no. We can achieve forward security without relying on chaining logs (which we do in this design), but not the log order or intact log chain, as I mentioned for that latter we need to rely on the information that if lost, is cryptographically detectable. Also attacker can modify and lie about everything, including the block number in the logs.

I will add documents about the whole design in the next commits to make it more clear, and we can discuss this in the EVE Community meeting next week.

[codecov[bot]]

Codecov Report

All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 20.93%. Comparing base (05f2182) to head (3ceee84). Report is 17 commits behind head on master.

Additional details and impacted files

@@           Coverage Diff           @@
##           master    #4435   +/-   ##
=======================================
  Coverage   20.93%   20.93%           
=======================================
  Files          13       13           
  Lines        2895     2895           
=======================================
  Hits          606      606           
  Misses       2163     2163           
  Partials      126      126           

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.