Validate ECDH peer public key before shared secret derivation#7828
Closed
sahilnxp wants to merge 4 commits into
Closed
Validate ECDH peer public key before shared secret derivation#7828sahilnxp wants to merge 4 commits into
sahilnxp wants to merge 4 commits into
Conversation
Extend struct crypto_ecc_public_ops with an optional validate_public_key callback. This enables crypto backends to register a function that validates a peer's ECC public key point lies on the expected curve before performing ECDH shared secret derivation. Without this callback, there is no generic mechanism for the TEE service layer to invoke public key validation across different crypto backends (libtomcrypt, mbedTLS, hardware accelerators like CAAM), leaving them potentially vulnerable to invalid-curve attacks. The callback is optional (like verify, encrypt) so backends that do not support standalone key validation can leave it unset. Signed-off-by: Sahil Malhotra <sahil.malhotra@nxp.com>
Implement _ltc_ecc_validate_public_key() to validate that a peer's ECC public key point lies on the expected curve before ECDH shared secret derivation. This prevents invalid-curve attacks where a crafted point on a weaker curve could leak the private key. The implementation reuses the existing ecc_populate_ltc_public_key() helper to convert the OP-TEE key structure into a libtomcrypt ecc_key, then delegates to ltc_ecc_verify_key() which performs three checks: 1. Coordinates are within the field (0 <= x, y < prime, not both zero) 2. Point satisfies the curve equation y^2 = x^3 + ax + b (mod p) 3. Scalar multiplication n*Q != O (order times point is not infinity) Register the callback as .validate_public_key in ecc_public_key_ops so it is invoked from the TEE service layer during ECDH derivation. Add ltc_ecc_verify_key.c to sub.mk so the symbol is compiled and linked into libtomcrypt.a. Signed-off-by: Sahil Malhotra <sahil.malhotra@nxp.com>
…bkey Implement validate_ecdh_public_key() to validate that a peer's ECC public key point (X, Y) lies on the expected curve before ECDH shared secret derivation. This prevents invalid-curve attacks where an attacker supplies a crafted point on a weaker curve to progressively recover the private key. Register the callback as .validate_public_key in ecc_public_key_ops. Supported curves: NIST P-192, P-224, P-256, P-384 and P-521. Signed-off-by: Sahil Malhotra <sahil.malhotra@nxp.com>
…t derivation Add public key validation in the ECDH shared secret derivation path in tee_svc_cryp.c to reject invalid peer public keys before they reach any crypto backend. Hardware accelerators such as CAAM may not perform on-curve validation internally, making them susceptible to invalid-curve attacks where an attacker supplies a crafted point on a weaker curve to progressively recover the private key. By validating at the TEE service layer, all backends (CAAM, libtomcrypt, mbedTLS) are uniformly protected. The validation is performed by retrieving the ECC public key ops via crypto_asym_get_ecc_public_ops() and invoking the validate_public_key callback, which checks that the peer's (X, Y) coordinates satisfy the curve equation and the point is not at infinity. Signed-off-by: Sahil Malhotra <sahil.malhotra@nxp.com>
Contributor
Author
|
Corresponding PR in optee_test to validate this: OP-TEE/optee_test#816 |
Contributor
|
From the PR description it is not clear to me whether we are missing validation only for hardware backed crypto backends or if mbetls/libtomcrypt are also deficient. For the first case would that not introduce double validation when not working with a hardware backed crypto backend? |
Contributor
Author
|
@Emantor From my understanding, mbedTLS already performs this validation, whereas TomCrypt/CAAM do not check it before executing ECDH. To ensure consistent behavior across all backends, I added this validation at the core level so it is enforced before delegating the operation to either software or hardware crypto implementations. This helps guarantee correctness and strengthens security regardless of backend-specific behavior. It also helps in reducing the risk of missing such validations when integrating new crypto backends. I do agree that this could be redundant in cases where the underlying crypto implementations already perform the check. |
Contributor
|
c2d64e1 has been merged. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR adds ECDH peer public key validation to prevent invalid-curve attacks in OP-TEE.
Problem: Hardware accelerators like CAAM may not validate that peer public keys lie on the expected curve, making them vulnerable to attacks where crafted points on weaker curves can leak private keys.
Solution:
validate_public_keycallbackltc_ecc_verify_key) and mbedTLS (usingmbedtls_ecp_check_pubkey) backendsResult: All crypto backends (CAAM, libtomcrypt, mbedTLS) are now uniformly protected against invalid-curve attacks through centralized validation in
tee_svc_cryp.c.