core: crypto: add support MD5 hashes in RSA sign/verify/cipher

Introduce support of using MD5 hashes in RSA sign/verify/cipher
operations, which is required by AOSP Keymaster.

This is verified in

core: crypto: add support MD5 hashes in RSA sign/verify/cipher

Introduce support of using MD5 hashes in RSA sign/verify/cipher
operations, which is required by AOSP Keymaster.

This is verified in VerificationOperationsTest.RsaSuccess VTS Test [1],
which checks usage of such digests: NONE, MD5, SHA1, SHA_2_224, SHA_2_256,
SHA_2_384, SHA_2_512.

This patch has been inspired by commit[2]:

Link: [1] https://android.googlesource.com/platform/hardware/interfaces/+/master/keymaster/3.0/vts/functional/keymaster_hidl_hal_test.cpp
Link: [2] https://github.com/OP-TEE/optee_os/commit/199d0b7310d1705661a106358f1f0b46e4c5c587 ("core: crypto: add support MD5 hashes in RSA sign/verify")
Signed-off-by: Julien Masson <jmasson@baylibre.com>
Signed-off-by: Safae Ouajih <souajih@baylibre.com>
Acked-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 ...

GP131: Update HKDF defines

OP-TEE provides an HKDF implementation as an extension to the TEE
Internal Core API which predates version 1.3 of the specification where
HKDF was officially introduced.

GP131: Update HKDF defines

OP-TEE provides an HKDF implementation as an extension to the TEE
Internal Core API which predates version 1.3 of the specification where
HKDF was officially introduced.

Update with the official defines and resolve name clashes. With this
OP-TEE supports both the old extension and the new official API.

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

show more ...

core, libutee: introduce TEE_ALG_SM4_XTS

In this patch, The sm4-xts algorithm is supported in the GP process.

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

core, libutee: introduce TEE_ALG_SM4_XTS

In this patch, The sm4-xts algorithm is supported in the GP process.

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: dt_driver: Add support for disabled devices

In systems where there are multiple instances of the devices like two TRNGs
where one is reserved for REE environment and one is for TEE environment

core: dt_driver: Add support for disabled devices

In systems where there are multiple instances of the devices like two TRNGs
where one is reserved for REE environment and one is for TEE environment
those can be defined in device tree in following way:

ree-trng {
status = "okay";
secure-status = "disabled";
...
}

tee-trng {
status = "disabled";
secure-status = "okay";
...
}

If OP-TEE has driver enabled for the device both devices will be probed.

Driver can detect device's 'status' and 'secure-status' settings and return
TEE_ERROR_NODE_DISABLED value for one that is not for its use.

This will indicate to device driver probing to continue without an error.

Signed-off-by: Vesa Jääskeläinen <vesa.jaaskelainen@vaisala.com>
Acked-by: Jens Wiklander <jens.wiklander@linaro.org>

show more ...

libutee: define error core TEE_ERROR_DEFER_DRIVER_INIT

Define TEE_Result implementation specific error code
TEE_ERROR_DEFER_DRIVER_INIT intended to be used when a driver instance
fails to initialize

libutee: define error core TEE_ERROR_DEFER_DRIVER_INIT

Define TEE_Result implementation specific error code
TEE_ERROR_DEFER_DRIVER_INIT intended to be used when a driver instance
fails to initialize because another device driver it depends on is not
yet initialized.

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

show more ...

Add 3DES CMAC implementation

CMAC is a Cipher-Based MAC that improves some of the security deficiencies
found in CBC-MAC. It is described in NIST SP800-38B as a mode of operation
for approved symmet

Add 3DES CMAC implementation

CMAC is a Cipher-Based MAC that improves some of the security deficiencies
found in CBC-MAC. It is described in NIST SP800-38B as a mode of operation
for approved symmetric block chipers, namely AES and TDEA.

CMAC has similar use cases and security guarantees as HMAC, with the
difference that it uses a different primitive (symmetric cipher instead
of hash function).
CMAC may be appropriate for information systems in which an approved block
cipher is more readily available than an approved hash function.

Commonly it is used for symmetric key diversification (ASC X9 TR 31-2018),
data integrity assurance (ICV).

CMAC is public domain.

OP-TEE core already supports for AES CMAC, but not TDEA CMAC. This commit
adds TDEA CMAC support.

Signed-off-by: Alexander Zakharov <uglym8@gmail.com>
Reviewed-by: Jerome Forissier <jerome@forissier.org>
Acked-by: Etienne Carriere <etienne.carriere@linaro.org>
[jf: wrap commit description at 75 characters]
Signed-off-by: Jerome Forissier <jerome@forissier.org>

show more ...

core: add TEE_LOGIN_REE_KERNEL login method

Add private login method for REE kernel clients to invoke TAs. It allows
a TA to distinguish among normal world clients whether its a REE kernel
client or

core: add TEE_LOGIN_REE_KERNEL login method

Add private login method for REE kernel clients to invoke TAs. It allows
a TA to distinguish among normal world clients whether its a REE kernel
client or a REE user-space client.

Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
Reviewed-by: Jerome Forissier <jerome@forissier.org>

show more ...

utee: support prehashed RSA sign/ver without ASN.1

Add TEE Core Internal API extension TEE_ALG_RSASSA_PKCS1_V1_5 to
sign/verify pre-hashed PKCS#1 v1.5 EMSA without ASN.1 around the hash.
This relies

utee: support prehashed RSA sign/ver without ASN.1

Add TEE Core Internal API extension TEE_ALG_RSASSA_PKCS1_V1_5 to
sign/verify pre-hashed PKCS#1 v1.5 EMSA without ASN.1 around the hash.
This relies on libtomcrypt LTC_PKCS_1_V1_5_NA1. The extension can be
turned on with CFG_CRYPTO_RSASSA_NA1.

Reviewed-by: Jens Wiklander <jens.wiklander@linaro.org>
Signed-off-by: Gabor Szekely <szvgabor@gmail.com>

show more ...

Remove 'All rights reserved' from Linaro files

The text 'All rights reserved' is useless [1]. The Free Software
Foundation's REUSE Initiative best practices document [2] does not
contain these words

Remove 'All rights reserved' from Linaro files

The text 'All rights reserved' is useless [1]. The Free Software
Foundation's REUSE Initiative best practices document [2] does not
contain these words. Therefore, we can safely remove the text from the
files that are owned by Linaro.

Generated by:
spdxify.py --linaro-only --strip-arr optee_os/

Link: [1] https://en.wikipedia.org/wiki/All_rights_reserved
Link: [2] https://reuse.software/practices/
Link: [3] https://github.com/jforissier/misc/blob/f7b56c8/spdxify.py
Signed-off-by: Jerome Forissier <jerome.forissier@linaro.org>
Acked-by: Joakim Bech <joakim.bech@linaro.org>

show more ...

Remove license notice from Linaro files

Now that we have added SPDX identifiers, we can safely remove the
verbose license text from the files that are owned by Linaro.

Generated by [1]:
spdxify.p

Remove license notice from Linaro files

Now that we have added SPDX identifiers, we can safely remove the
verbose license text from the files that are owned by Linaro.

Generated by [1]:
spdxify.py --linaro-only --strip-license-text optee_os/

Link: [1] https://github.com/jforissier/misc/blob/f7b56c8/spdxify.py
Signed-off-by: Jerome Forissier <jerome.forissier@linaro.org>
Acked-by: Joakim Bech <joakim.bech@linaro.org>

show more ...

Add SPDX license identifiers

Adds one SPDX-License-Identifier line [1] to each source files that
contains license text.

Generated by [2]:
spdxify.py --add-spdx optee_os/

The scancode tool [3] wa

Add SPDX license identifiers

Adds one SPDX-License-Identifier line [1] to each source files that
contains license text.

Generated by [2]:
spdxify.py --add-spdx optee_os/

The scancode tool [3] was used to double check the license matching
code in the Python script. All the licenses detected by scancode are
either detected by spdxify.py, or have no SPDX identifier, or are false
matches.

Link: [1] https://spdx.org/licenses/
Link: [2] https://github.com/jforissier/misc/blob/f7b56c8/spdxify.py
Link: [3] https://github.com/nexB/scancode-toolkit
Signed-off-by: Jerome Forissier <jerome.forissier@linaro.org>
Acked-by: Joakim Bech <joakim.bech@linaro.org>

show more ...

Remove SQL-FS

With recent developments in REE-FS SQL-FS has become redundant. This
patch removes SQL-FS.

Reviewed-by: Joakim Bech <joakim.bech@linaro.org>
Acked-by: Jerome Forissier <jerome.forissi

Remove SQL-FS

With recent developments in REE-FS SQL-FS has become redundant. This
patch removes SQL-FS.

Reviewed-by: Joakim Bech <joakim.bech@linaro.org>
Acked-by: Jerome Forissier <jerome.forissier@linaro.org>
Tested-by: Jens Wiklander <jens.wiklander@linaro.org> (QEMU)
Signed-off-by: Jens Wiklander <jens.wiklander@linaro.org>

show more ...

libutee extension: check-access-right for secure/nonsec permissions

Define TEE_MEMORY_ACCESS_NONSECURE and TEE_MEMORY_ACCESS_SECURE are
extensions of the flag bitfield argument of TEE_CheckMemoryAcc

libutee extension: check-access-right for secure/nonsec permissions

Define TEE_MEMORY_ACCESS_NONSECURE and TEE_MEMORY_ACCESS_SECURE are
extensions of the flag bitfield argument of TEE_CheckMemoryAccessRights().
Once one of these is set, core checks the secure mapping attribute.

Note: if both are set, it's obviously an caller error. Implementation
will return a TEE_ERROR_ACCESS_DENIED.

Include tee_api_defines_extensions.h from tee_internal_api_extensions.h
so that TAs only have to include tee_internal_api_extensions.h to access
extensions resources.

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

show more ...

secure storage: add SQL filesystem

This commit adds a new container type for trusted storage: SQL FS.
Data are stored in the non-secure world, just like the REE FS
(CFG_REE_FS). But, unlike REE FS w

secure storage: add SQL filesystem

This commit adds a new container type for trusted storage: SQL FS.
Data are stored in the non-secure world, just like the REE FS
(CFG_REE_FS). But, unlike REE FS which manipulates several files for
each secure object, this implementation needs only one container in a
SQLite database per secure object. We rely on the transaction-based
nature of the database to provide atomicity.

A storage identifier is added to the TA API: TEE_STORAGE_PRIVATE_SQL.
Trusted applications can use it to select this filesystem. The value
TEE_STORAGE_PRIVATE defined by GlobalPlatform will also select the
SQL FS if all other implementations are disabled.

This feature is enabled with CFG_SQL_FS=y. It depends on SQL support
in tee-supplicant [1].

[1] https://github.com/OP-TEE/optee_client/pull/50

Signed-off-by: Jerome Forissier <jerome.forissier@linaro.org>
Tested-by: Jerome Forissier <jerome.forissier@linaro.org> (HiKey)
Reviewed-by: Joakim Bech <joakim.bech@linaro.org>
Reviewed-by: David Brown <david.brown@linaro.org>
Reviewed-by: Etienne Carriere <etienne.carriere@linaro.org>

show more ...

core: secure storage: dual filesystems support

Adds support for multiple filesystems by keeping a pointer to
tee_file_operations in the tee_pobj and tee_storage_enum structures.

Two identifiers are

core: secure storage: dual filesystems support

Adds support for multiple filesystems by keeping a pointer to
tee_file_operations in the tee_pobj and tee_storage_enum structures.

Two identifiers are added to the API to be used as the storage_id
parameter, so that TAs may dynamically choose the filesystem:
- TEE_STORAGE_PRIVATE_REE (requires CFG_REE_FS=y)
- TEE_STORAGE_PRIVATE_RPMB (requires CFG_RPMB_FS=y)
The value TEE_STORAGE_PRIVATE will select the REE FS if available,
otherwise RPMB. At least one FS has to be enabled at build time. Only
the REE filesystem is enabled by default.

Signed-off-by: Jerome Forissier <jerome.forissier@linaro.org>
Reviewed-by: Jens Wiklander <jens.wiklander@linaro.org>
Reviewed-by: Pascal Brand <pascal.brand@linaro.org>

show more ...

Add PKCS #5 v2.0 key derivation function 2 (PBKDF2)

This commit implements a crypto extension to support the key derivation
function defined in section 5.2 of RFC 2898
(https://www.ietf.org/rfc/rfc2

Add PKCS #5 v2.0 key derivation function 2 (PBKDF2)

This commit implements a crypto extension to support the key derivation
function defined in section 5.2 of RFC 2898
(https://www.ietf.org/rfc/rfc2898.txt), which is a re-publish of PKCS #5 v2.0.
The underlying pseudorandom function is HMAC-SHA1, which is the default PRF
specified in the RFC. It would be trivial to support the other HMAC functions
already implemented in OP-TEE.

See documentation/extensions/crypto_pbkdf2.md for details.

Tested on PLATFORM=vexpress-qemu_virt with the test vectors from RFC 6070
(https://www.ietf.org/rfc/rfc6070.txt).

Signed-off-by: Jerome Forissier <jerome.forissier@linaro.org>
Signed-off-by: Xiaoqiang Du <xiaoqiang.du@linaro.org>
Reviewed-by: Jens Wiklander <jens.wiklander@linaro.org>
Reviewed-by: Pascal Brand <pascal.brand@linaro.org>
Tested-by: Pascal Brand <pascal.brand@linaro.org> (STM platform)

show more ...

Add HMAC-based extract-and-expand key derivation function (HKDF)

HKDF (http://tools.ietf.org/html/rfc5869) is a key derivation algorithm.
As per the RFC:

A key derivation function (KDF) is a bas

Add HMAC-based extract-and-expand key derivation function (HKDF)

HKDF (http://tools.ietf.org/html/rfc5869) is a key derivation algorithm.
As per the RFC:

A key derivation function (KDF) is a basic and essential component of
cryptographic systems. Its goal is to take some source of initial
keying material and derive from it one or more cryptographically
strong secret keys.
[...]
HKDF follows the "extract-then-expand" paradigm, where the KDF
logically consists of two modules.
[...]
The goal of the "extract" stage is to "concentrate" the possibly
dispersed entropy of the input keying material into a short, but
cryptographically strong, pseudorandom key.
[...]
The second stage "expands" the pseudorandom key to the desired
length; the number and lengths of the output keys depend on the
specific cryptographic algorithms for which the keys are needed.

Since HKDF is not covered by the GlobalPlatform Internal API specification
v1.0/v1.1, this commit introduces extensions to the specification.
More specifically: it defines new algorithms, a new object type and new
object attributes. This implementation supports all the usual hash
functions (MD5, SHA-1, SHA-224, SHA-256, SHA-384, SHA-512) and may
produce output keys of length up to 4096 bits (currently limited only by
the maximum size allowed for an object of type TEE_TYPE_GENERIC_SECRET).
Aside from minor updates to object manipulation functions to support
the new data, the function TEE_DeriveKey() is mostly impacted.

The file documentation/extensions/crypto_hkdf.md contains the modifications
to the GP Internal API v1.0 spec in order to support HKDF.

Signed-off-by: Jerome Forissier <jerome.forissier@linaro.org>
Signed-off-by: Xiaoqiang Du <xiaoqiang.du@linaro.org>
Reviewed-by: Pascal Brand <pascal.brand@linaro.org>
Tested-by: Pascal Brand <pascal.brand@linaro.org> (STM platform)
Reviewed-by: Jens Wiklander <jens.wiklander@linaro.org>
Reviewed-by: Joakim Bech <joakim.bech@linaro.org>

show more ...

Add Concat KDF (Concatenation Key Derivation Function, NIST SP 800-56A R1)

Concat KDF is a key derivation algorithm defined in section 5.8.1 of
the NIST Special Publication 800-56A Revision 1, "Reco

Add Concat KDF (Concatenation Key Derivation Function, NIST SP 800-56A R1)

Concat KDF is a key derivation algorithm defined in section 5.8.1 of
the NIST Special Publication 800-56A Revision 1, "Recommendation for Pair-Wise
Key Establishment Schemes Using Discrete Logarithm Cryptography"
(http://csrc.nist.gov/publications/nistpubs/800-56A/SP800-56A_Revision1_Mar08-2007.pdf)

This is a TEE implementation of the function, which supports the following
hash algorithms: SHA-1, SHA-224, SHA-256, SHA-384 and SHA-512.
The actual key derivation is implemented in TEE_DeriveKey() thanks to
custom extensions to the GlobalPlatform API v1.0. Please refer to
documentation/extensions/crypto_concat_kdf.md for details.

Signed-off-by: Jerome Forissier <jerome.forissier@linaro.org>
Signed-off-by: Xiaoqiang Du <xiaoqiang.du@linaro.org>
Reviewed-by: Jens Wiklander <jens.wiklander@linaro.org>
Reviewed-by: Pascal Brand <pascal.brand@linaro.org>
Tested-by: Pascal Brand <pascal.brand@linaro.org> (STM platform)

show more ...