Re: [PATCH v2 5/6] ima: support fs-verity file digest based signatures

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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



[Index of Archives]     [linux Cryptography]     [Asterisk App Development]     [PJ SIP]     [Gnu Gatekeeper]     [IETF Sipping]     [Info Cyrus]     [ALSA User]     [Fedora Linux Users]     [Linux SCTP]     [DCCP]     [Gimp]     [Yosemite News]     [Deep Creek Hot Springs]     [Yosemite Campsites]     [ISDN Cause Codes]

  Powered by Linux