Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Authentication and access control support #237

Open
mkravchik opened this issue Jan 6, 2025 · 1 comment
Open

Authentication and access control support #237

mkravchik opened this issue Jan 6, 2025 · 1 comment
Labels
Crypto API Issue or PR related to the Cryptography API enhancement New feature or request

Comments

@mkravchik
Copy link

mkravchik commented Jan 6, 2025

Hi,

Are there any plans to add authentication and access control to the Crypto API? If yes, are there any drafts on how they will be integrated? If not, why aren't they included?

Best regards

@athoelke
Copy link
Contributor

There are no plans to do this at the moment.

The original incentive for the API design was to support applications in the emerging IoT market, with a crypto API that implemented the best practices in API design and cryptography engineering (see the Design Goals).

In the context of an embedded/IoT system, giving separate applications identity and authentication credentials to access their keystore is actively unhelpful, given the threat models associated with this type of device (see the first assumption in the Security Risk Assessment).

Instead, for systems that provide caller isolation (separate keystores for isolated applications within the system), it is expected that the system provides a secure identity provider service which the cryptoprocessor implementation can use to identify each of the callers, and thus ensure that separate callers have separate views of the keys within the cryptoprocessor.

Finally, there is a difficulty in presenting a generic API in C that expects the caller to provide identity and authentication credentials: what form do these items take, in order to be applicable to a wide range of systems and implementations? - if this was the definition of a specific crypto implementation, then choosing one such format may be acceptable; but this Crypto API expects to be provided by multiple distinct implementations, for which there is no common agreement on what constitutes a caller identity or an authentication/authorisation credential.

@athoelke athoelke added enhancement New feature or request Crypto API Issue or PR related to the Cryptography API labels Mar 13, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Crypto API Issue or PR related to the Cryptography API enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants