Our software uses pieces of data generated using a Yubico HSM (hardware security module) and signed using EDCSA with a private key on the HSM. I want my C# code to be able to validate these signatures against the public part of the root certificate from the HSM. (The public key can be extracted from the HSM; the private key cannot.)
The files come in pairs: A JSON file (whose contents are unimportant for this discussion) and a file with extension .signature
which contains the ECDSA signature (generated using the sign-ecdsa
command on the Yubico HSM).
Our C# validation code used to work, but it fails on the last couple of signatures that have come out of the HSM, and I do not understand why.
I used to be able to parse the signatures as base-64 and validate it like using the C# code snippet below. This worked for all files generated in 2022 and 2023, but it no longer works on the files generated by the HSM in 2024, because the .signature
file is no longer valid base-64. When I attempt to parse/decode it as base-64 I get a FormatException (from System.Convert.FromBase64String).
private static bool IsValidIeeeP1363FixedFieldConcatenationSignature(
ECDsa signingPublicKey, byte[] dataToBeSigned, byte[] signature) =>
signingPublicKey.VerifyData(
dataToBeSigned,
signature,
HashAlgorithmName.SHA384);
The signatures started being “bad” when we made the HSM generate a new root certificate. (It is this root that it uses to sign the JSON files.) All signatures generated by this new root are “bad” in the sense that they are not base-64 and fail our validation algorithm.
How can I debug this?
The signatures are generated using the following Bash code, which has not changed in years (the important bits to notice are sign-ecdsa
and ecdsa-sha384
):
test_signing_intermediate_revocation=$(yubihsm-shell
--authkey=${input_yubico_auth_key_id}
--password=${input_yubico_auth_key_password}
--action=sign-ecdsa
--algorithm=ecdsa-sha384
--domain=${yubico_domain}
--object-id=${yubico_root_key_id}
--in=${output_intermediate_revocation_data_file}
--out=${output_intermediate_revocation_signature_file}
2>&1)
Here is an example of a valid signature which our validation algorithm accepts:
MGUCMEfo9xFTuDoB3yrTqKljW8npPaz5lVpeO42vVccF3PnI5CoZKqQHlM2IctQ7kkHbcQIxAOjd5fUKM6CpCDrR7JOiYXAG02Q0/vOqPChrzIWsbdsjMs9quQqIJ6BiyUzZzuDmjQ==
Here is an example of a bad signature which we cannot validate because it is not valid base-64 as our algorithm expects:
MGUCMQCMT6pFGHALJ0kfZ2RxC/CyupJzRGGTm2lcgXKJ5t3bnPCfp0APIpbJdXh8FrPXZVQCMDlDQNH7W37YpchHtfTVuVD7z+bCaQkIY0LiqDK7JpsnsiRE9ksiFhVz3APFvy1XhQ==MGQCMHu6Zis/kBdVFfPG2kcIlhSyrM0DYbTovFOuA/S2XuAOSvypmCgOWPIIF72iGYyk9gIwYm6Wb3AKfvpUjBG3EaKc1OqVpAbzCMRYeLqDdURbc6qWhlKBtMt9NJlhnAUa5NCc
Note that the bad signature is much longer (276 characters) than the good signature (140 characters). The first 140 characters are valid base-64 but still fail the validation algorithm (ECDsa.VerifyData returns false
).
1