RFD 169 Encrypted kernel crash dump

[bcantrill]

This is an issue to discuss RFD 169 Encrypted kernel crash dump; comments welcome!

[danmcd]

You have an HMAC but only over the first N bytes to reject bad keys. Using a cipher without some sort of packet integrity may enable self-healing block-splicing attacks. Now ChaCha20 isn't CBC, it's CTR, BUT even CTR-mode ciphers need some sort of integrity protection. In SSL, ChaCha20 is paired with Poly1305. Poly1305 has ChaCha20 properties, as it comes from DJB as well.

[bcantrill]

Is the concern that the dump might be tampered with? We're definitely not trying to make the dump tamperproof -- we're trying to prevent it from being seen in cleartext by the attacker.

[rmustacc]

Thanks for putting this together, in general, it all looks good. I agree that the treat vector that we're worried about isn't the dump on the dump device being rewritten right now, but one of just the security of the data. If someone else has maliciously changed the dump device contents, that seems much more problematic. However, we do have the algorithm version in the header, so that allows us to deal with that as necessary. One question that I have is do we have to have it be the case that if we have an older dump header version we can't compress this? It seems like if we have systems that are in that case, rather than have to find the old savecore, the new savecore could know how to handle the differences between the two versions as they don't seem that big. While it does complicate the userland implementation, it shouldn't impact the actual dump path.

[danmcd]

If tamper-proofing is not a concern, that needs to be documented as such. Others will notice encryption-with-no-integrity and get their reflexes triggered. Please be ready to address it. I may even be missing reasons why it's important beyond tamper-resistance, but I'm pretty sure you don't have to worry about it for tampering reasons (at least in the short-and-medium-term).

[rzezeski]

(there is currently no way to disable dump encryption once enabled).

I don't follow this sentence. If I enable encrypted dump on my machine with dumpadm -k ..., I can never disable it in the future? I understand that once a particular core is encrypted the only way I'm reading it is by decrypting it with the correct key; but it seems you are saying that once you enable encrypted dump on a box there is no going back. That is, I can't later disable encrypted dump for future crashes. If that's the case, I don't understand the reasoning.

Also, what about changing the key? I imagine you can just rerun dumpadm -k? If so, might want to call that out explicitly.

[bcantrill]

I have updated the RFD to address @danmcd's concerns (calling out that this is not to prevent tampering) as well as to change the implementation to allow for spontaneous upgrades.

[bcantrill]

@rzezeski: There is no way to disable encryption without rebooting -- I'll clarify both the RFD and the docs.