core: crypto: fix AES-GCM in-place decryption order

Fix AES-GCM in-place decryption to ensure GHASH always uses the original
ciphertext. Previously, plaintext could overwrite ciphertext before GHASH

core: crypto: fix AES-GCM in-place decryption order

Fix AES-GCM in-place decryption to ensure GHASH always uses the original
ciphertext. Previously, plaintext could overwrite ciphertext before GHASH,
causing authentication failures. Now GHASH is processed before decryption,
so in-place and non in-place decryption both work correctly without extra
buffering or conditional checks.

Tested with both in-place and non in-place decryption; all cases now
produce correct authentication tags.

Fixes: 1fca7e269b13 ("core: crypto: add new AES-GCM implementation")
Signed-off-by: Rayan Hu <rayan.hu@mediatek.com>
Reviewed-by: Menson Chen <menson.chen@mediatek.com>
Reviewed-by: ChingMing Chen <chingming.chen@mediatek.com>
Reviewed-by: Jens Wiklander <jens.wiklander@linaro.org>

show more ...

shdr: add check for weak key sizes

Add a function is_weak_key_size(...), which checks whether a given key
size (in bits) complies with current security standards. If the key size
is lower than 2048,

shdr: add check for weak key sizes

Add a function is_weak_key_size(...), which checks whether a given key
size (in bits) complies with current security standards. If the key size
is lower than 2048, then it's considered deprecated and will make
signature verification fail. Note that this only affects verifying TA
and subkey signatures.

This change aligns with GlobalPlatform's decision, influenced by
feedback from ANSSI, BSI, SOGIS, and NIST. For further details on the
GlobalPlatform's cryptographic algorithm recommendations, see [1].

Link: https://globalplatform.org/specs-library/globalplatform-technology-cryptographic-algorithm-recommendations/ [1]
Signed-off-by: Joakim Bech <joakim.bech@linaro.org>
Reviewed-by: Jens Wiklander <jens.wiklander@linaro.org>

show more ...

shdr: add SHA-224 to the deprecated algorithms

GlobalPlatform have based on feedback from different national body
organizations, such as ANSSI, BSI, SOGIS and NIST deprecated SHA-224.
Add TEE_ALG_SH

shdr: add SHA-224 to the deprecated algorithms

GlobalPlatform have based on feedback from different national body
organizations, such as ANSSI, BSI, SOGIS and NIST deprecated SHA-224.
Add TEE_ALG_SHA224 to the list of weak signature algorithms.

Signed-off-by: Joakim Bech <joakim.bech@linaro.org>
Reviewed-by: Jens Wiklander <jens.wiklander@linaro.org>

show more ...

core: pass TEE_ATTR_RSA_OAEP_MGF_HASH to RSA-OAEP implementations

OP-TEE currently doesn't support using a different hash for MGF1
with RSA-OAEP. However, this is required for AOSP compatibility
(e.

core: pass TEE_ATTR_RSA_OAEP_MGF_HASH to RSA-OAEP implementations

OP-TEE currently doesn't support using a different hash for MGF1
with RSA-OAEP. However, this is required for AOSP compatibility
(e.g. in EncryptionOperationsTest.RsaOaepWithMGFDigestSuccess [1]).

Pass the MGF1 attribute to crypto implementations. Note that
only libtomcrypt supports this feature at the moment, so other
implementations will either fail or fall back to libtomcrypt when
passed a different MGF1 hash.

Link: https://android.googlesource.com/platform/hardware/interfaces/+/refs/heads/main/security/keymint/aidl/vts/functional/KeyMintTest.cpp#5552 [1]
Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
Reviewed-by: Jens Wiklander <jens.wiklander@linaro.org>

show more ...

core: fix possible overflow in shdr_alloc_and_copy()

Prior to this patch, if SHDR_GET_SIZE() overflows it will return 0 and
further down in the function lead to an out-of-bounds access. So fix
this

core: fix possible overflow in shdr_alloc_and_copy()

Prior to this patch, if SHDR_GET_SIZE() overflows it will return 0 and
further down in the function lead to an out-of-bounds access. So fix
this with an explicit test before using shdr_size in
shdr_alloc_and_copy().

Fixes: 064663e8bd27 ("core: crypto: add struct shdr helper functions")
Signed-off-by: Jens Wiklander <jens.wiklander@linaro.org>
Reviewed-by: Jerome Forissier <jerome.forissier@linaro.org>

show more ...

core: crypto: fix internal AES-GCM counter implementation

We have several AES-GCM implementations in crypto libraries and
internal. The internal implementation comes in two flavours, with Arm
crypto

core: crypto: fix internal AES-GCM counter implementation

We have several AES-GCM implementations in crypto libraries and
internal. The internal implementation comes in two flavours, with Arm
crypto extensions (CFG_CRYPTO_WITH_CE=y) and a pure software
implementation.

Each block to be encrypted is xored with an encrypted counter block of
equal size (16 bytes). For each block the counter is increased.

Prior to this patch the entire counter block was increased as a 128-bit
integer, but that's not how AES-GCM is defined. In AES-GCM only the
least significant 32 bits of the counter block are increased, leaving
the rest untouched. The difference is only noticeable when the 32 bits
has reached 0xffffffff and wraps to 0x00000000 on next increment. With a
128-bit integer this would propagate into other parts of the block.

Fix this by only incrementing the last 32-bit word in the counter block,
both in the pure software implementation and when using Arm crypto
extensions.

Link: https://github.com/OP-TEE/optee_os/issues/6659
Fixes: 1fca7e269b13 ("core: crypto: add new AES-GCM implementation")
Signed-off-by: Jens Wiklander <jens.wiklander@linaro.org>
Acked-by: Jerome Forissier <jerome.forissier@linaro.org>
Acked-by: Etienne Carriere <etienne.carriere@foss.st.com>

show more ...

core: remove unnecessary includes

Remove unnecessary includes.

Signed-off-by: Clement Faure <clement.faure@nxp.com>
Acked-by: Jerome Forissier <jerome.forissier@linaro.org>
Acked-by: Jens Wiklander

core: remove unnecessary includes

Remove unnecessary includes.

Signed-off-by: Clement Faure <clement.faure@nxp.com>
Acked-by: Jerome Forissier <jerome.forissier@linaro.org>
Acked-by: Jens Wiklander <jens.wiklander@linaro.org>
Acked-by: Etienne Carriere <etienne.carriere@foss.st.com>

show more ...

core: initialize buffer with calloc()

Allocate out_tmp buffer with calloc() instead of malloc()
This relates to a Coverity issue where out_tmp is reported to be
potentially used as uninitialized in

core: initialize buffer with calloc()

Allocate out_tmp buffer with calloc() instead of malloc()
This relates to a Coverity issue where out_tmp is reported to be
potentially used as uninitialized in memcpy().

Signed-off-by: Clement Faure <clement.faure@nxp.com>
Reviewed-by: Etienne Carriere <etienne.carriere@foss.st.com>
Reviewed-by: Jens Wiklander <jens.wiklander@linaro.org>
Reviewed-by: Jerome Forissier <jerome.forissier@linaro.org>

show more ...

core: crypto: sm3: fix undefined behavior on right shifting operation

In the expression ROTL(T[j], j), with j=0, we right shift by more than
31 bits (32 in this case). This behavior is undefined acc

core: crypto: sm3: fix undefined behavior on right shifting operation

In the expression ROTL(T[j], j), with j=0, we right shift by more than
31 bits (32 in this case). This behavior is undefined according to the
C99 standard:

6.5.7 Bitwise shift operators
The integer promotions are performed on each of the operands. The type
of the result is that of the promoted left operand. If the value of
the right operand is negative or is greater than or equal to the width
of the promoted left operand, the behavior is undefined.

Skip the shift operation if the shift value is 0.

Signed-off-by: Clement Faure <clement.faure@nxp.com>
Reviewed-by: Etienne Carriere <etienne.carriere@foss.st.com>
Reviewed-by: Jens Wiklander <jens.wiklander@linaro.org>
Reviewed-by: Jerome Forissier <jerome.forissier@linaro.org>

show more ...

crypto: add X448 support

Refer to the X25519 algorithm, add the X448 algorithm framework code.

Signed-off-by: loubaihui <loubaihui1@huawei.com>
Acked-by: Jerome Forissier <jerome.forissier@linaro.o

crypto: add X448 support

Refer to the X25519 algorithm, add the X448 algorithm framework code.

Signed-off-by: loubaihui <loubaihui1@huawei.com>
Acked-by: Jerome Forissier <jerome.forissier@linaro.org>
Acked-by: Jens Wiklander <jens.wiklander@linaro.org>

show more ...

crypto: rename struct x25519_keypair

Since X25519 and X448 have the same key pair structure,
so we rename struct x25519_keypair as struct montgomery_keypair.

Signed-off-by: loubaihui <loubaihui1@hu

crypto: rename struct x25519_keypair

Since X25519 and X448 have the same key pair structure,
so we rename struct x25519_keypair as struct montgomery_keypair.

Signed-off-by: loubaihui <loubaihui1@huawei.com>
Reviewed-by: Jerome Forissier <jerome.forissier@linaro.org>
Acked-by: Jens Wiklander <jens.wiklander@linaro.org>

show more ...

core: crypto_bignum_free(): add indirection and set pointer to NULL

To prevent human mistake, crypto_bignum_free() sets the location of the
bignum pointer to NULL after freeing it.

Signed-off-by: J

core: crypto_bignum_free(): add indirection and set pointer to NULL

To prevent human mistake, crypto_bignum_free() sets the location of the
bignum pointer to NULL after freeing it.

Signed-off-by: Jihwan Park <jihwp@amazon.com>
Signed-off-by: Jens Wiklander <jens.wiklander@linaro.org>
Reviewed-by: Jerome Forissier <jerome.forissier@linaro.org>
Reviewed-by: Joakim Bech <joakim.bech@linaro.org>
Reviewed-by: Etienne Carriere <etienne.carriere@foss.st.com>

show more ...

core: arm64: SM4-AESE optimization for ARMv8

Enabled with CFG_CRYPTO_SM4_ARM_AESE=y, set by default if
CFG_CRYPTO_WITH_CE=y.

Signed-off-by: Xu Yizhou <xuyizhou1@huawei.com>
Acked-by: Tianjia Zhang

core: arm64: SM4-AESE optimization for ARMv8

Enabled with CFG_CRYPTO_SM4_ARM_AESE=y, set by default if
CFG_CRYPTO_WITH_CE=y.

Signed-off-by: Xu Yizhou <xuyizhou1@huawei.com>
Acked-by: Tianjia Zhang <tianjia.zhang@linux.alibaba.com>
Acked-by: Jens Wiklander <jens.wiklander@linaro.org>

show more ...

core: crypto: fix memory leak in Ed25519 support

The software implementation of ED25519 algorithm has a memory leak in the
key and key pair allocation. Upon every public key allocation, a key pair
i

core: crypto: fix memory leak in Ed25519 support

The software implementation of ED25519 algorithm has a memory leak in the
key and key pair allocation. Upon every public key allocation, a key pair
is allocated (public and private components). When freeing the public
key, only the public component is freed. To reproduce the issue:

$ while xtest 4016; do :; done

Until the following error:

* regression_4016 Test TEE Internal API ED25519 sign/verify
E/LD: copy_section_headers:1124 sys_copy_from_ta_bin
E/TC:? 0 ldelf_init_with_ldelf:131 ldelf failed with res: 0xffff000c /usr/src/debug/optee-test/master.imx-r0/host/xtest/regression_4000.c:6062: xtest_teec_open_session(&session, &crypt_user_ta_uuid, ((void *)0), &ret_orig) has an unexpected value: 0xffff000c = TEEC_ERROR_OUT_OF_MEMORY, expected 0x0 = TEEC_SUCCESS
regression_4016 FAILED

To fix the memory leak, a separate public key allocation function must
be defined along a ED25519 public key structure.

Fixes: 0aaad418ac8b ("core: crypto: add Ed25519 support")
Signed-off-by: Clement Faure <clement.faure@nxp.com>
Reviewed-by: Jens Wiklander <jens.wiklander@linaro.org>

show more ...

core: crypto: add API for SHA-3

Adds an API for the SHA-3 [1] algorithms SHA3-224, SHA3_256, SHA3_384,
SHA3_512, SHAKE128, and SHAKE256. SHAKE128 and SHAKE256 are
Extendable-Output Functions (XOF),

core: crypto: add API for SHA-3

Adds an API for the SHA-3 [1] algorithms SHA3-224, SHA3_256, SHA3_384,
SHA3_512, SHAKE128, and SHAKE256. SHAKE128 and SHAKE256 are
Extendable-Output Functions (XOF), but handled as hashes in the API.

Adds API for SHA-3 based HMAC functions.

For XOF algorithms crypto_hash_final() can be called multiple times and
generate an arbitrary amount of data. Note that this data will have a
common prefix if done over the same input (see A.2 in [1]).

[1] https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.202.pdf

Acked-by: Etienne Carriere <etienne.carriere@linaro.org>
Signed-off-by: Jens Wiklander <jens.wiklander@linaro.org>

show more ...

core: use SM3 crypto accelerated function

Uses the recently provided accelerated SM3 function in the SM3
implementation.

Acked-by: Jerome Forissier <jerome.forissier@linaro.org>
Signed-off-by: Jens

core: use SM3 crypto accelerated function

Uses the recently provided accelerated SM3 function in the SM3
implementation.

Acked-by: Jerome Forissier <jerome.forissier@linaro.org>
Signed-off-by: Jens Wiklander <jens.wiklander@linaro.org>

show more ...

core: crypto: implement SM4 XTS

In this patch, we add software computing support for sm4-xts.

Signed-off-by: Pingan Xie <xiepingan3@huawei.com>
Reviewed-by: Xiaoxu Zeng <zengxiaoxu@huawei.com>
Acke

core: crypto: implement SM4 XTS

In this patch, we add software computing support for sm4-xts.

Signed-off-by: Pingan Xie <xiepingan3@huawei.com>
Reviewed-by: Xiaoxu Zeng <zengxiaoxu@huawei.com>
Acked-by: Jens Wiklander <jens.wiklander@linaro.org>
Reviewed-by: Jerome Forissier <jerome.forissier@linaro.org>

show more ...

core: add fault mitigations to shdr_verify_signature*()

Adds fault mitigations to shdr_verify_signature() and
shdr_verify_signature2(). shdr_verify_signature() and
shdr_verify_signature2() are calle

core: add fault mitigations to shdr_verify_signature*()

Adds fault mitigations to shdr_verify_signature() and
shdr_verify_signature2(). shdr_verify_signature() and
shdr_verify_signature2() are called using the wrapper FTMN_CALL_FUNC()
which verifies that the correct function was called and that the return
value hasn't been tampered with.

Acked-by: Jerome Forissier <jerome.forissier@linaro.org>
Signed-off-by: Jens Wiklander <jens.wiklander@linaro.org>

show more ...

core: shdr: check that hash algorithm is strong enough

Until now shdr_verify_signature() accepted any hash GP algorithm known
to OP-TEE. A few of those (MD5 and SHA-1) are known to be weak. So add
a

core: shdr: check that hash algorithm is strong enough

Until now shdr_verify_signature() accepted any hash GP algorithm known
to OP-TEE. A few of those (MD5 and SHA-1) are known to be weak. So add
an extra check to only allow algorithms strong enough.

Reviewed-by: Jerome Forissier <jerome.forissier@linaro.org>
Reviewed-by: Etienne Carriere <etienne.carriere@linaro.org>
Suggested-by: Asaf Modelevsky <amodele@amazon.com>
Reported-by: Asaf Modelevsky <amodele@amazon.com>
Signed-off-by: Jens Wiklander <jens.wiklander@linaro.org>

show more ...

core: support loading TAs signed with a subkey

Adds support to load TAs signed with subkey or a chain of subkeys. This
allows delegation of TA signing without distributing the root key. TAs
signed w

core: support loading TAs signed with a subkey

Adds support to load TAs signed with subkey or a chain of subkeys. This
allows delegation of TA signing without distributing the root key. TAs
signed with a subkey are confined to the UUID-V5 namespace of the subkey
to avoid TA UUID clashes with different subkeys.

SHDR_SUBKEY is a type of header which enables chains of public keys.
The public root key is used to verify the first public subkey, which
then is used to verify the next public subkey and so on.

The TA is finally verified using the last subkey. All these headers are
added in front of the TA binary so everything needed to verify the TA is
available when it's loaded into memory.

For example:
Subkey
struct shdr
magic: 0x4f545348
img_type: 3 (SHDR_SUBKEY)
img_size: 320 bytes
algo: 0x70414930 (TEE_ALG_RSASSA_PKCS1_PSS_MGF1_SHA256)
hash_size: 32 bytes
sig_size: 256 bytes
hash: f573f329fe77be686ce71647909c4ea35b5e1cd7de86369bd7d9fca31f6a4d65
struct shdr_subkey
uuid: f04fa996-148a-453c-b037-1dcfbad120a6
name_size: 64
subkey_version: 1
max_depth: 4
algo: 0x70414930 (TEE_ALG_RSASSA_PKCS1_PSS_MGF1_SHA256)
attr_count: 2
next name: "mid_level_subkey"
Next header at offset: 692 (0x2b4)
Subkey
struct shdr
magic: 0x4f545348
img_type: 3 (SHDR_SUBKEY)
img_size: 320 bytes
algo: 0x70414930 (TEE_ALG_RSASSA_PKCS1_PSS_MGF1_SHA256)
hash_size: 32 bytes
sig_size: 256 bytes
hash: 233a6dcf1a2cf69e50cde8e20c4129157da707c76fa86ce12ee31037edef02d7
struct shdr_subkey
uuid: 1a5948c5-1aa0-518c-86f4-be6f6a057b16
name_size: 64
subkey_version: 1
max_depth: 3
algo: 0x70414930 (TEE_ALG_RSASSA_PKCS1_PSS_MGF1_SHA256)
attr_count: 2
next name: "subkey1_ta"
Next header at offset: 1384 (0x568)
Bootstrap TA
struct shdr
magic: 0x4f545348
img_type: 1 (SHDR_BOOTSTRAP_TA)
img_size: 84576 bytes
algo: 0x70414930 (TEE_ALG_RSASSA_PKCS1_PSS_MGF1_SHA256)
hash_size: 32 bytes
sig_size: 256 bytes
hash: ea31ac7dc2cc06a9dc2853cd791dd00f784b5edc062ecfa274deeb66589b4ca5
struct shdr_bootstrap_ta
uuid: 5c206987-16a3-59cc-ab0f-64b9cfc9e758
ta_version: 0
TA offset: 1712 (0x6b0) bytes
TA size: 84576 (0x14a60) bytes

Acked-by: Jerome Forissier <jerome.forissier@linaro.org>
Tested-by: Jerome Forissier <jerome.forissier@linaro.org> (vexpress-qemu_virt)
Acked-by: Etienne Carriere <etienne.carriere@linaro.org>
Signed-off-by: Jens Wiklander <jens.wiklander@linaro.org>

show more ...

core: add offset argument to shdr_alloc_and_copy()

Adds an offset argument to shdr_alloc_and_copy() to make it easier to
copy a signed header located further into a non-secure buffer.

Reviewed-by:

core: add offset argument to shdr_alloc_and_copy()

Adds an offset argument to shdr_alloc_and_copy() to make it easier to
copy a signed header located further into a non-secure buffer.

Reviewed-by: Jerome Forissier <jerome.forissier@linaro.org>
Acked-by: Etienne Carriere <etienne.carriere@linaro.org>
Signed-off-by: Jens Wiklander <jens.wiklander@linaro.org>

show more ...

crypto: se050: updates to the crypto object deletion interface

Keys created on the Secure Element NVM via the PKCS#11 TA are removed
by scanning the data buffer holding the reference to the key duri

crypto: se050: updates to the crypto object deletion interface

Keys created on the Secure Element NVM via the PKCS#11 TA are removed
by scanning the data buffer holding the reference to the key during
the release of the object.

The storage allocated to hold those keys (ECC/RSA) is always below the
page size length which seems like a reasonable figure to use for future
extensions.

- This commit avoids scanning objects larger than that length.

This commit also updates the interface to delegate the actual handling
of the object to the crypto driver instead of passing just the raw data
contained in the object.

The cryptographic layer is also being allowed to block the deletion of
the object. This is to cover the scenario where the I2C device is not
accessible while a reference to the key is being removed from the secure
storage in the filesystem.

Incidentally also fixes regression 6018: this test releases an object
of size 0xA0000 which can't be scanned due to this part of the code
hitting an Out of Memory condition.

Signed-off-by: Jorge Ramirez-Ortiz <jorge@foundries.io>
Acked-by: Etienne Carriere <etienne.carriere@linaro.org>
Acked-by: Jens Wiklander <jens.wiklander@linaro.org>

show more ...

core: libtomcrypt: add Ed25519 support

Enable Ed25519 implementation of libtomcrypt and add the OP-TEE wrappers.

Signed-off-by: Valerii Chubar <valerii_chubar@epam.com>
Signed-off-by: Sergiy Kibrik

core: libtomcrypt: add Ed25519 support

Enable Ed25519 implementation of libtomcrypt and add the OP-TEE wrappers.

Signed-off-by: Valerii Chubar <valerii_chubar@epam.com>
Signed-off-by: Sergiy Kibrik <Sergiy_Kibrik@epam.com>
Reviewed-by: Jerome Forissier <jerome.forissier@linaro.org>
Acked-by: Etienne Carriere <etienne.carriere@linaro.org>
Acked-by: Jens Wiklander <jens.wiklander@linaro.org>

show more ...