On 1/10/22 17:45, Eric Biggers wrote:
On Sun, Jan 09, 2022 at 01:55:16PM -0500, Mimi Zohar wrote:
+ case IMA_VERITY_DIGSIG:
+ set_bit(IMA_DIGSIG, &iint->atomic_flags);
+
+ algo = iint->ima_hash->algo;
+ hash = kzalloc(sizeof(*hash) + hash_digest_size[algo],
+ GFP_KERNEL);
+ if (!hash) {
+ *cause = "verity-hashing-error";
+ *status = INTEGRITY_FAIL;
+ break;
+ }
+
+ rc = calc_tbs_hash(IMA_VERITY_DIGSIG, iint->ima_hash->algo,
+ iint->ima_hash->digest, hash);
+ if (rc) {
+ *cause = "verity-hashing-error";
+ *status = INTEGRITY_FAIL;
+ break;
+ }
+
+ rc = integrity_digsig_verify(INTEGRITY_KEYRING_IMA,
+ (const char *)xattr_value,
+ xattr_len, hash->digest,
+ hash->length);
This is still verifying a raw hash value, which is wrong as I've explained
several times. Yes, you are now hashing the hash algorithm ID together with the
original hash value, but at the end the thing being signed/verified is still a
raw hash value, which is ambigious.
I think I see where the confusion is. If rsa-pkcs1pad is used, then the
asymmetric algorithm is parameterized by a hash algorithm, and this hash
algorithm's identifier is automatically built-in to the data which is
signed/verified. And the data being signed/verified is assumed to be a hash
value of the same type. So in this case, the caller doesn't need to handle
disambiguating raw hashes.
However, asymmetric_verify() also supports ecdsa and ecrdsa signatures. As far
as I can tell, those do *not* have the hash algorithm identifier built-in to the
data which is signed/verified; they just sign/verify the data given. That
The signatures are generated by evmctl by this code here, which works
for RSA and ECDSA and likely also ECRDSA:
https://sourceforge.net/p/linux-ima/ima-evm-utils/ci/master/tree/src/libimaevm.c#l1036
if (!EVP_PKEY_sign_init(ctx))
goto err;
st = "EVP_get_digestbyname";
if (!(md = EVP_get_digestbyname(algo)))
goto err;
st = "EVP_PKEY_CTX_set_signature_md";
if (!EVP_PKEY_CTX_set_signature_md(ctx, md))
goto err;
st = "EVP_PKEY_sign";
sigsize = MAX_SIGNATURE_SIZE - sizeof(struct signature_v2_hdr) - 1;
if (!EVP_PKEY_sign(ctx, hdr->sig, &sigsize, hash, size))
goto err;
len = (int)sigsize;
As far as I know, these are not raw signatures but generate the OIDs for
RSA + shaXYZ or ECDSA + shaXYZ (1.2.840.10045.4.1 et al) and prepend
them to the hash and then sign that.
creates an ambiguity if the hash algorithm identifier is not included. For
example, someone might have intended to sign the SHA-256 hash
01ba4719c80b6fe911b091a7c05124b64eeece964e09c058ef8f9805daca546b. However, the
Streebog or SM3 hash
01ba4719c80b6fe911b091a7c05124b64eeece964e09c058ef8f9805daca546b would also pass
the signature check too. That's wrong; to have a valid cryptosystem, you
mustn't let the adversary choose the crypto algorithms for you.
There's a hash algorithm identifier in the xattr in the header, which is
prepended to the bytes of the actual signature. This hash algo identifer
tells IMA which hash to use on the file data so that subsequent
signature verification with the same hash works. That same hash
identifier is then again embedded in the signature using the OID and
thus has to match on the signature verification level.
The effectively double hashed data via calc_tbs_hash() above is not
good. calc_tbs_hash() is unnecessary.
On the evmctl level the signature should be created from the digest
retrieved via ioctl() [or similar I suppose] from fsverity on the file
and fsverity presumably then also says what type of hash this is. So,
fsverity ioctl response of hash + size of hash and hash_algo become
input to the evmctl snippet above. On the kernel level the data from
fsverity_get_digest() should be all it takes to verify against an xattr
created by evmctl as described.
I'm not sure how this can be reconciled, given the differences between
rsa-pkcs1pad and ecdsa and ecrdsa. Could you just use the lowest common
denominator and prepend the hash algorithm ID to the hash value, or would that
cause issues with rsa-pkcs1pad? In any case, to move forward you're going to
need to solve this problem.
- Eric
