2019-07-18 18:23:23 +08:00
|
|
|
=pod
|
|
|
|
|
|
|
|
=head1 NAME
|
|
|
|
|
|
|
|
provider - OpenSSL operation implementation providers
|
|
|
|
|
|
|
|
=head1 SYNOPSIS
|
|
|
|
|
2019-09-29 23:10:59 +08:00
|
|
|
=for openssl generic
|
2019-07-18 18:23:23 +08:00
|
|
|
|
|
|
|
#include <openssl/provider.h>
|
|
|
|
|
|
|
|
=head1 DESCRIPTION
|
|
|
|
|
|
|
|
=head2 General
|
|
|
|
|
2021-03-26 00:55:51 +08:00
|
|
|
This page contains information useful to provider authors.
|
|
|
|
|
2019-07-18 18:23:23 +08:00
|
|
|
A I<provider>, in OpenSSL terms, is a unit of code that provides one
|
|
|
|
or more implementations for various operations for diverse algorithms
|
|
|
|
that one might want to perform.
|
|
|
|
|
|
|
|
An I<operation> is something one wants to do, such as encryption and
|
|
|
|
decryption, key derivation, MAC calculation, signing and verification,
|
|
|
|
etc.
|
|
|
|
|
|
|
|
An I<algorithm> is a named method to perform an operation.
|
|
|
|
Very often, the algorithms revolve around cryptographic operations,
|
|
|
|
but may also revolve around other types of operation, such as managing
|
|
|
|
certain types of objects.
|
|
|
|
|
2021-03-26 00:55:51 +08:00
|
|
|
See L<crypto(7)> for further details.
|
2019-07-18 18:23:23 +08:00
|
|
|
|
2021-03-26 00:55:51 +08:00
|
|
|
=head2 Provider
|
2019-07-18 18:23:23 +08:00
|
|
|
|
|
|
|
A I<provider> offers an initialization function, as a set of base
|
|
|
|
functions in the form of an B<OSSL_DISPATCH> array, and by extension,
|
|
|
|
a set of B<OSSL_ALGORITHM>s (see L<openssl-core.h(7)>).
|
|
|
|
It may be a dynamically loadable module, or may be built-in, in
|
|
|
|
OpenSSL libraries or in the application.
|
|
|
|
If it's a dynamically loadable module, the initialization function
|
|
|
|
must be named C<OSSL_provider_init> and must be exported.
|
|
|
|
If it's built-in, the initialization function may have any name.
|
|
|
|
|
|
|
|
The initialization function must have the following signature:
|
|
|
|
|
2020-05-07 19:11:44 +08:00
|
|
|
int NAME(const OSSL_CORE_HANDLE *handle,
|
2019-07-18 18:23:23 +08:00
|
|
|
const OSSL_DISPATCH *in, const OSSL_DISPATCH **out,
|
|
|
|
void **provctx);
|
|
|
|
|
2020-05-07 19:11:44 +08:00
|
|
|
I<handle> is the OpenSSL library object for the provider, and works
|
2019-07-18 18:23:23 +08:00
|
|
|
as a handle for everything the OpenSSL libraries need to know about
|
|
|
|
the provider.
|
2020-05-07 19:11:44 +08:00
|
|
|
For the provider itself, it is passed to some of the functions given in the
|
|
|
|
dispatch array I<in>.
|
2019-07-18 18:23:23 +08:00
|
|
|
|
|
|
|
I<in> is a dispatch array of base functions offered by the OpenSSL
|
|
|
|
libraries, and the available functions are further described in
|
|
|
|
L<provider-base(7)>.
|
|
|
|
|
|
|
|
I<*out> must be assigned a dispatch array of base functions that the
|
|
|
|
provider offers to the OpenSSL libraries.
|
|
|
|
The functions that may be offered are further described in
|
|
|
|
L<provider-base(7)>, and they are the central means of communication
|
|
|
|
between the OpenSSL libraries and the provider.
|
|
|
|
|
|
|
|
I<*provctx> should be assigned a provider specific context to allow
|
|
|
|
the provider multiple simultaneous uses.
|
|
|
|
This pointer will be passed to various operation functions offered by
|
|
|
|
the provider.
|
|
|
|
|
|
|
|
One of the functions the provider offers to the OpenSSL libraries is
|
|
|
|
the central mechanism for the OpenSSL libraries to get access to
|
|
|
|
operation implementations for diverse algorithms.
|
|
|
|
Its referred to with the number B<OSSL_FUNC_PROVIDER_QUERY_OPERATION>
|
|
|
|
and has the following signature:
|
|
|
|
|
|
|
|
const OSSL_ALGORITHM *provider_query_operation(void *provctx,
|
|
|
|
int operation_id,
|
|
|
|
const int *no_store);
|
|
|
|
|
|
|
|
I<provctx> is the provider specific context that was passed back by
|
|
|
|
the initialization function.
|
|
|
|
|
|
|
|
I<operation_id> is an operation identity (see L</Operations> below).
|
|
|
|
|
|
|
|
I<no_store> is a flag back to the OpenSSL libraries which, when
|
2019-09-28 01:17:09 +08:00
|
|
|
nonzero, signifies that the OpenSSL libraries will not store a
|
2019-07-18 18:23:23 +08:00
|
|
|
reference to the returned data in their internal store of
|
|
|
|
implementations.
|
|
|
|
|
|
|
|
The returned B<OSSL_ALGORITHM> is the foundation of any OpenSSL
|
|
|
|
library API that uses providers for their implementation, most
|
|
|
|
commonly in the I<fetching> type of functions
|
2021-03-26 00:55:51 +08:00
|
|
|
(see L<crypto(7)/ALGORITHM FETCHING>).
|
2019-07-18 18:23:23 +08:00
|
|
|
|
|
|
|
=head2 Operations
|
|
|
|
|
|
|
|
Operations are referred to with numbers, via macros with names
|
|
|
|
starting with C<OSSL_OP_>.
|
|
|
|
|
|
|
|
With each operation comes a set of defined function types that a
|
|
|
|
provider may or may not offer, depending on its needs.
|
|
|
|
|
|
|
|
Currently available operations are:
|
|
|
|
|
|
|
|
=over 4
|
|
|
|
|
|
|
|
=item Digests
|
|
|
|
|
|
|
|
In the OpenSSL libraries, the corresponding method object is
|
|
|
|
B<EVP_MD>.
|
|
|
|
The number for this operation is B<OSSL_OP_DIGEST>.
|
|
|
|
The functions the provider can offer are described in
|
|
|
|
L<provider-digest(7)>
|
|
|
|
|
|
|
|
=item Symmetric ciphers
|
|
|
|
|
|
|
|
In the OpenSSL libraries, the corresponding method object is
|
|
|
|
B<EVP_CIPHER>.
|
|
|
|
The number for this operation is B<OSSL_OP_CIPHER>.
|
|
|
|
The functions the provider can offer are described in
|
|
|
|
L<provider-cipher(7)>
|
|
|
|
|
|
|
|
=item Message Authentication Code (MAC)
|
|
|
|
|
|
|
|
In the OpenSSL libraries, the corresponding method object is
|
|
|
|
B<EVP_MAC>.
|
|
|
|
The number for this operation is B<OSSL_OP_MAC>.
|
|
|
|
The functions the provider can offer are described in
|
|
|
|
L<provider-mac(7)>
|
|
|
|
|
|
|
|
=item Key Derivation Function (KDF)
|
|
|
|
|
|
|
|
In the OpenSSL libraries, the corresponding method object is
|
|
|
|
B<EVP_KDF>.
|
|
|
|
The number for this operation is B<OSSL_OP_KDF>.
|
|
|
|
The functions the provider can offer are described in
|
|
|
|
L<provider-kdf(7)>
|
|
|
|
|
|
|
|
=item Key Exchange
|
|
|
|
|
|
|
|
In the OpenSSL libraries, the corresponding method object is
|
2019-09-27 19:26:22 +08:00
|
|
|
B<EVP_KEYEXCH>.
|
2019-07-18 18:23:23 +08:00
|
|
|
The number for this operation is B<OSSL_OP_KEYEXCH>.
|
|
|
|
The functions the provider can offer are described in
|
|
|
|
L<provider-keyexch(7)>
|
|
|
|
|
2020-06-17 05:43:24 +08:00
|
|
|
=item Asymmetric Ciphers
|
|
|
|
|
|
|
|
In the OpenSSL libraries, the corresponding method object is
|
|
|
|
B<EVP_ASYM_CIPHER>.
|
|
|
|
The number for this operation is B<OSSL_OP_ASYM_CIPHER>.
|
|
|
|
The functions the provider can offer are described in
|
|
|
|
L<provider-asym_cipher(7)>
|
|
|
|
|
2020-09-19 16:08:46 +08:00
|
|
|
=item Asymmetric Key Encapsulation
|
|
|
|
|
|
|
|
In the OpenSSL libraries, the corresponding method object is B<EVP_KEM>.
|
|
|
|
The number for this operation is B<OSSL_OP_KEM>.
|
|
|
|
The functions the provider can offer are described in L<provider-kem(7)>
|
|
|
|
|
2020-08-17 03:25:08 +08:00
|
|
|
=item Encoding
|
SERIALIZER: New API for serialization of objects through providers
Serialization is needed to be able to take a provider object (such as
the provider side key data) and output it in PEM form, DER form, text
form (for display), and possibly other future forms (XML? JSON? JWK?)
The idea is that a serializer should be able to handle objects it has
intimate knowledge of, as well as object data in OSSL_PARAM form. The
latter will allow libcrypto to serialize some object with a different
provider than the one holding the data, if exporting of that data is
allowed and there is a serializer that can handle it.
We will provide serializers for the types of objects we know about,
which should be useful together with any other provider that provides
implementations of the same type of object.
Serializers are selected by method name and a couple of additional
properties:
- format used to tell what format the output should be in.
Possibilities could include "format=text",
"format=pem", "format=der", "format=pem-pkcs1"
(traditional), "format=der-pkcs1" (traditional)
- type used to tell exactly what type of data should be
output, for example "type=public" (the public part of
a key), "type=private" (the private part of a key),
"type=domainparams" (domain parameters).
This also adds a passphrase callback function type,
OSSL_PASSPHRASE_CALLBACK, which is a bit like OSSL_CALLBACK, but it
takes a few extra arguments to place the result in.
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/10394)
2019-11-18 08:29:06 +08:00
|
|
|
|
|
|
|
In the OpenSSL libraries, the corresponding method object is
|
2020-08-17 03:25:08 +08:00
|
|
|
B<OSSL_ENCODER>.
|
|
|
|
The number for this operation is B<OSSL_OP_ENCODER>.
|
SERIALIZER: New API for serialization of objects through providers
Serialization is needed to be able to take a provider object (such as
the provider side key data) and output it in PEM form, DER form, text
form (for display), and possibly other future forms (XML? JSON? JWK?)
The idea is that a serializer should be able to handle objects it has
intimate knowledge of, as well as object data in OSSL_PARAM form. The
latter will allow libcrypto to serialize some object with a different
provider than the one holding the data, if exporting of that data is
allowed and there is a serializer that can handle it.
We will provide serializers for the types of objects we know about,
which should be useful together with any other provider that provides
implementations of the same type of object.
Serializers are selected by method name and a couple of additional
properties:
- format used to tell what format the output should be in.
Possibilities could include "format=text",
"format=pem", "format=der", "format=pem-pkcs1"
(traditional), "format=der-pkcs1" (traditional)
- type used to tell exactly what type of data should be
output, for example "type=public" (the public part of
a key), "type=private" (the private part of a key),
"type=domainparams" (domain parameters).
This also adds a passphrase callback function type,
OSSL_PASSPHRASE_CALLBACK, which is a bit like OSSL_CALLBACK, but it
takes a few extra arguments to place the result in.
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/10394)
2019-11-18 08:29:06 +08:00
|
|
|
The functions the provider can offer are described in
|
2020-08-17 03:25:08 +08:00
|
|
|
L<provider-encoder(7)>
|
SERIALIZER: New API for serialization of objects through providers
Serialization is needed to be able to take a provider object (such as
the provider side key data) and output it in PEM form, DER form, text
form (for display), and possibly other future forms (XML? JSON? JWK?)
The idea is that a serializer should be able to handle objects it has
intimate knowledge of, as well as object data in OSSL_PARAM form. The
latter will allow libcrypto to serialize some object with a different
provider than the one holding the data, if exporting of that data is
allowed and there is a serializer that can handle it.
We will provide serializers for the types of objects we know about,
which should be useful together with any other provider that provides
implementations of the same type of object.
Serializers are selected by method name and a couple of additional
properties:
- format used to tell what format the output should be in.
Possibilities could include "format=text",
"format=pem", "format=der", "format=pem-pkcs1"
(traditional), "format=der-pkcs1" (traditional)
- type used to tell exactly what type of data should be
output, for example "type=public" (the public part of
a key), "type=private" (the private part of a key),
"type=domainparams" (domain parameters).
This also adds a passphrase callback function type,
OSSL_PASSPHRASE_CALLBACK, which is a bit like OSSL_CALLBACK, but it
takes a few extra arguments to place the result in.
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/10394)
2019-11-18 08:29:06 +08:00
|
|
|
|
2019-07-18 18:23:23 +08:00
|
|
|
=back
|
|
|
|
|
2019-10-04 19:46:33 +08:00
|
|
|
=head3 Algorithm naming
|
2019-07-18 18:23:23 +08:00
|
|
|
|
2019-10-04 19:46:33 +08:00
|
|
|
Algorithm names are case insensitive. Any particular algorithm can have multiple
|
|
|
|
aliases associated with it. The canonical OpenSSL naming scheme follows this
|
|
|
|
format:
|
2019-07-18 18:23:23 +08:00
|
|
|
|
2019-10-04 19:46:33 +08:00
|
|
|
ALGNAME[VERSION?][-SUBNAME[VERSION?]?][-SIZE?][-MODE?]
|
2019-07-18 18:23:23 +08:00
|
|
|
|
2019-10-04 19:46:33 +08:00
|
|
|
VERSION is only present if there are multiple versions of an algorithm (e.g.
|
|
|
|
MD2, MD4, MD5). It may be omitted if there is only one version.
|
2019-07-18 18:23:23 +08:00
|
|
|
|
2019-10-04 19:46:33 +08:00
|
|
|
SUBNAME may be present where multiple algorithms are combined together,
|
|
|
|
e.g. MD5-SHA1.
|
2019-07-18 18:23:23 +08:00
|
|
|
|
2019-10-04 19:46:33 +08:00
|
|
|
SIZE is only present if multiple versions of an algorithm exist with different
|
|
|
|
sizes (e.g. AES-128-CBC, AES-256-CBC)
|
2019-07-18 18:23:23 +08:00
|
|
|
|
2019-10-04 19:46:33 +08:00
|
|
|
MODE is only present where applicable.
|
2019-07-18 18:23:23 +08:00
|
|
|
|
2019-10-04 19:46:33 +08:00
|
|
|
Other aliases may exist for example where standards bodies or common practice
|
|
|
|
use alternative names or names that OpenSSL has used historically.
|
2019-07-18 18:23:23 +08:00
|
|
|
|
2019-10-04 19:46:33 +08:00
|
|
|
=head1 OPENSSL PROVIDERS
|
2019-07-18 18:23:23 +08:00
|
|
|
|
2021-03-26 00:55:51 +08:00
|
|
|
OpenSSL provides a number of its own providers. These are the default, base,
|
|
|
|
fips, legacy and null providers. See L<crypto(7)> for an overview of these
|
|
|
|
providers.
|
2019-07-18 18:23:23 +08:00
|
|
|
|
|
|
|
=head1 SEE ALSO
|
|
|
|
|
|
|
|
L<EVP_DigestInit_ex(3)>, L<EVP_EncryptInit_ex(3)>,
|
2020-10-15 17:55:50 +08:00
|
|
|
L<OSSL_LIB_CTX(3)>,
|
2019-07-18 18:23:23 +08:00
|
|
|
L<EVP_set_default_properties(3)>,
|
|
|
|
L<EVP_MD_fetch(3)>,
|
|
|
|
L<EVP_CIPHER_fetch(3)>,
|
|
|
|
L<EVP_KEYMGMT_fetch(3)>,
|
|
|
|
L<openssl-core.h(7)>,
|
|
|
|
L<provider-base(7)>,
|
|
|
|
L<provider-digest(7)>,
|
|
|
|
L<provider-cipher(7)>,
|
|
|
|
L<provider-keyexch(7)>
|
|
|
|
|
|
|
|
=head1 HISTORY
|
|
|
|
|
|
|
|
The concept of providers and everything surrounding them was
|
|
|
|
introduced in OpenSSL 3.0.
|
|
|
|
|
|
|
|
=head1 COPYRIGHT
|
|
|
|
|
2021-01-28 20:54:57 +08:00
|
|
|
Copyright 2019-2021 The OpenSSL Project Authors. All Rights Reserved.
|
2019-07-18 18:23:23 +08:00
|
|
|
|
|
|
|
Licensed under the Apache License 2.0 (the "License"). You may not use
|
|
|
|
this file except in compliance with the License. You can obtain a copy
|
|
|
|
in the file LICENSE in the source distribution or at
|
|
|
|
L<https://www.openssl.org/source/license.html>.
|
|
|
|
|
|
|
|
=cut
|