Yubico
How to retrieve audit log *signature*
Hi,
According to the https://www.yubico.com/ro/product/yubihsm-2/ page:
Tamper evident Audit Logging The YubiHSM 2 internally stores a log of all management and crypto operation events that occur in the device and that log can be exported for monitoring and reporting. Each event (row) in the log is hash chained with the previous row and signed so that it’s possible to determine if any events are modified or deleted.
I would like to retrieve that signature that is mentioned on the website. I want to make my audit log publicly verifiable without access to the device, but for that I need the latest hash (or latest log entry or something) digitally signed by the device. The GET LOGS command seem to only return the hash linked logs, but there's no mention on how to retrieve a signature.
Thanks
I'm afraid that is a documentation error, the logs are only hash-chained, not signed. I have initiated an update of the docs. Thank you for the notification !.
Hmm. I assume there's also no command that could attest a log entry? Maybe that could be added to a future firmware version as a feature request?
That sounds like a good idea, let me bring that to product managements attention. Thank you !
Sigh, so there is no way to prove to a 3rd party - without them having live access to the HSM - that the audit logs are authentic?
Well if you manually sign the first log entry and publish it then someone with the full list of log entries can verify the whole chain
What I mean is that I can just make up an arbitrary fake audit chain that I just keep adding commands to and nobody without access to the real HSM will be able to ever tell it's fake. I can have the HSM do arbitrary bad stuff and keep reporting a clean history publicly.
Thats true. The only thing the hash chain proves is that you have the whole chain.
How insane would it be to have the HSM publicly accessible with a publicly known log auditor private key? That would allow cross-verifying the identity of the HSM when establishing a session and retrieving the audit log head by anyone to verify the chain.
That would work I suppose. Maybe making it less than world-accessible through https with client certificates or a vpn, and possibly also with a number of separate auditor private keys ? It does increase the risks if a more capable key gets in the wrong hands.
You could also use YubiHSM-auth, i.e. using a YubiKey to authenticate to the HSM. Then you could created a number of them with a single symmetric key for instance. Or the same scheme as above but with the private key protected.
I'm actually trying to create a fully public transparency log of the operations. That's why a signature would have solved everything and without it I'm in quite a bit of a pickle here.
I'd assume that even if such a feature lands, it would take an unknown amount of time to become available and even after the firmware is done, using it would require purchasing new devices?
Hmm, I think I hit yet another issue with the log authentication. The device has it's own identity signed by Yubico. But the key used for asymmetric authentication into the HSM is not the device identity, rather a completely unrelated key. As such, it seems impossible to even prove I'm talking to a real YubiHSM and not a fake one. Am I missing something here, this surely cannot be true.
With asymmetric authentication both parties have their own key pair. Each party can trust they are talking to the party they intend to by using the public key of the other party. For the YubiHSM the public key it trusts is the authentication key stored under the id specified in the authentication request. For the client it is the device public key, which can be retrieved from the YubiHSM (without authentication). To enable trust on the client side you need to configure this public key in the configuration file (or just visually verify it's the right one, as it's printed out if no configured key is found). There is only one device key pair (and hence device public key) regardless of which authentication key is used. It is regenerated when the device is reset. So if you verify that the device public key is the same then you know it's the same YubiHSM, and that it hasn't been reset. To verify that the device public key is genuine you can create an attestation for it.
So in short, the authentication key is the public key of the client, that the YubiHSM trusts. The device public key is what the client trusts. As long as the YubbiHSM is not reset the device public key remains the same, and can be used to identify it. Yuu can get an attestation (an X.509 certificate signed by the attestation key) for the device public key at any time.
I can also attest an arbitrary other public key and have the client talk to a fake YubiHSM. I cannot prove to the client that the public key I give them originated from a specific YubiHSM (or any YubiHSM at all).
The attestation (certificate) will contain the key id of the key that was attested, so that can be used to verify that the attestation is for the device public key of some yubihsm. You would have to have a register of device public keys to identify specific YubiHSMs. By verifying the certificate chain back to the Yubico YubiHSM attestation root you could tell that it is in fact from a YubiHSM.
But you cannot attest the device public key as it stands by default. It is not in any specific key slot which would allow you to have the "locally generated" tag. You can export the public key, import it back in and attest it like that, but then the attestation will state that this key was imported from the outside, so it's useless, I can import any other key and attest it.
Ah, I see. Is that attestable 0 key id documented anywhere? Indeed I can generate an attestation for that public key this way and I do have the object id of 0 in the cert:
1.3.6.1.4.1.41482.4.6:
0000 - 02 01 00 ...
I guess that is indeed enough to certify that the pubkey belongs to a specific yubihsm.
Thank you!
I will double check the documentation and ensure it is there if it isn't already. Thanks for your feedback.