ta: Add Application Secrets TA - #7769
Merged
Merged
Conversation
|
This pull request has been marked as a stale pull request because it has been open (more than) 30 days with no activity. Remove the stale label or add a comment, otherwise this pull request will automatically be closed in 5 days. Note, that you can always re-open a closed issue at any time. |
Contributor
Author
|
Related optee_test PR now open OP-TEE/optee_test#815, this PR can be reopened, I cannot reopen myself |
jforissier
reviewed
Jun 2, 2026
Contributor
|
|
Application Secrets TA is a general purpose secret protector that
provides an API for sealing secrets.
Sealing refers to encrypting the client-provided confidential payload
and protecting the integrity of the TA-specific header inserted to
sealed blobs.
AES-256-GCM is used as the crypto algorithm as it provides authenticated
encryption, i.e. strong encryption for the secret payload and integrity
protection for the header at the same time. The key is derived from HUK
in order to base the security on hardware. This is also what the trusted
keys TA does.
IV is (only) 12 bytes (a sufficiently good random number generator is
assumed) as 96 bits is the recommended length (vs. 16 in the trusted
keys TA):
For IVs, it is recommended that implementations restrict support to
the length of 96 bits, to promote interoperability, efficiency, and
simplicity of design [1].
The blob includes magic and version fields to facilitate easy detection
of the format and compatibility. These are included from the very
beginning for forward compatibility even though the implementation
currently only supports a single blob type and version. The magic and
version fields are included in the AAD for integrity protection but IV
and tag are not as they are implicitly verified by AES-GCM (i.e.
changing them would fail decryption / integrity verification).
The blob also includes identity of the client that sealed the blob, i.e.
the TEE login type and client UUID. These are compared by the unseal
operation to those of the calling client in order to decide whether the
client is one that sealed the provided blob and thus authorized to
unseal it. The login type and the client UUID are stored in the
encrypted payload in order to avoid exposing the credentials
unnecessarily in plain text to anybody who might have access to the data
e.g. at rest. This adds an extra layer of security even though the login
type and client UUID are not necessarily secret (for login type only few
options exist in the first place, and UUID is UUIDv5 based client UID or
GID).
The unseal operation compares the client identity only after decrypting
the blob so that the integrity of the client identity stored in the blob
is verified before the authorization.
Inputs are first copied into locally allocated (non-shared) buffers
before any processing and results to the shared output buffers only
after all processing has been completed in order to isolate the TA and
its internal processing from clients, and to allow clients only see
final, complete results.
The implementation borrows ideas from the pre-existing trusted_keys TA,
but is a separate TA and a new implementation as the trusted_keys TA is
purpose-built for kernel usage, and cannot utilized as is since
considerable changes would be needed to accommodate userspace clients.
[1] https://doi.org/10.6028/NIST.SP.800-38D
Co-developed-by: Katariina Lounento <katariina.lounento@vaisala.com>
Signed-off-by: Katariina Lounento <katariina.lounento@vaisala.com>
Co-developed-by: Vesa Jääskeläinen <vesa.jaaskelainen@vaisala.com>
Signed-off-by: Vesa Jääskeläinen <vesa.jaaskelainen@vaisala.com>
Signed-off-by: Tuomas Salokanto <tuomas.salokanto@vaisala.com>
Acked-by: Jerome Forissier <jerome.forissier@arm.com>
tusal-vaisala
force-pushed
the
appsecrets-upstream-pr
branch
from
June 8, 2026 12:35
6100dfb to
163caa0
Compare
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.
We propose a new TA for use by user space applications for protecting secrets like private keys, passphrases, authentication tokens, etc similarly to the
trusted_keysused by kernel.If the TA looks conceptually good for inclusion in
optee_os, we are planning to implement tests for it inoptee_testAddresses issue #7768
Related
optee_clientPR: OP-TEE/optee_client#413Related
optee_testPR: OP-TEE/optee_test#815