| e4d3a4a6 | 16-Dec-2014 |
SY Chiu <sy.chiu@linaro.org> |
SE API: hide private interfaces
- Split each headers into module.h and module_priv.h, move the methods that is only used internally by SE implementation to module_priv.h, and export module_priv.
SE API: hide private interfaces
- Split each headers into module.h and module_priv.h, move the methods that is only used internally by SE implementation to module_priv.h, and export module_priv.h to rest of TEE Core - Added new include path to se_api_self_tests.c for which needs to include private headers - Split aid.c and apdu.c from iso7816.c. Originally they have to be wriiten in the same file since they share some private data structures. Now, the private data structure can be shared via private headers. - Split reader.c from manager.c for the same reason above.
Signed-off-by: SY Chiu <sy.chiu@linaro.org> Reviewed-by: Jens Wiklander <jens.wiklander@linaro.org> Reviewed-by: Joakim Bech <joakim.bech@linaro.org> Tested-by: SY Chiu <sy.chiu@linaro.org> (Modified QEMU + jcardsim)
show more ...
|
| e022f121 | 25-Nov-2014 |
SY Chiu <sy.chiu@linaro.org> |
SE API: Session, Protocol and Channel implementation
- Implement Session which maintains the connection between TA and a specific SE Reader - Implement ISO7816 transport layer protocol, and Channe
SE API: Session, Protocol and Channel implementation
- Implement Session which maintains the connection between TA and a specific SE Reader - Implement ISO7816 transport layer protocol, and Channel management - Implement Utilities to handle AID(ISO7816-3) and APDU(ISO7816-4) - Brunch of self tests to velidate functionality of each module
Signed-off-by: SY Chiu <sy.chiu@linaro.org> Reviewed-by: Jens Wiklander <jens.wiklander@linaro.org> Reviewed-by: Joakim Bech <joakim.bech@linaro.org> Tested-by: SY Chiu <sy.chiu@linaro.org> (Modified QEMU + jcardsim)
show more ...
|
| 0f2293b7 | 11-Dec-2014 |
Jerome Forissier <jerome.forissier@linaro.org> |
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 ...
|
| cdb198a7 | 04-Dec-2014 |
Jerome Forissier <jerome.forissier@linaro.org> |
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 ...
|
| 51835057 | 10-Nov-2014 |
Jerome Forissier <jerome.forissier@linaro.org> |
Fix memory leak in tee_svc_cryp_obj_copy()
The following Trusted App would lead to a memory leak in the TEE core:
TEE_ObjectHandle o1, o2; TEE_AllocateTransientObject(TEE_TYPE_RSA_KEYPAIR, 256,
Fix memory leak in tee_svc_cryp_obj_copy()
The following Trusted App would lead to a memory leak in the TEE core:
TEE_ObjectHandle o1, o2; TEE_AllocateTransientObject(TEE_TYPE_RSA_KEYPAIR, 256, &o1); TEE_GenerateKey(o1, 256, NULL, 0); TEE_AllocateTransientObject(TEE_TYPE_RSA_KEYPAIR, 256, &o2); TEE_CopyObjectAttributes(o2, o1); TEE_FreeTransientObject(o1); TEE_FreeTransientObject(o2);
The leak was introduced by commit ffe040395b13 ("Add crypto provider internal API").
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> Tested-by: Pascal Brand <pascal.brand@linaro.org> (STM platform)
show more ...
|