1=pod 2 3=head1 NAME 4 5provider-base 6- The basic OpenSSL library E<lt>-E<gt> provider functions 7 8=head1 SYNOPSIS 9 10 #include <openssl/core_dispatch.h> 11 12 /* 13 * None of these are actual functions, but are displayed like this for 14 * the function signatures for functions that are offered as function 15 * pointers in OSSL_DISPATCH arrays. 16 */ 17 18 /* Functions offered by libcrypto to the providers */ 19 const OSSL_ITEM *core_gettable_params(const OSSL_CORE_HANDLE *handle); 20 int core_get_params(const OSSL_CORE_HANDLE *handle, OSSL_PARAM params[]); 21 22 typedef void (*OSSL_thread_stop_handler_fn)(void *arg); 23 int core_thread_start(const OSSL_CORE_HANDLE *handle, 24 OSSL_thread_stop_handler_fn handfn, 25 void *arg); 26 27 OPENSSL_CORE_CTX *core_get_libctx(const OSSL_CORE_HANDLE *handle); 28 void core_new_error(const OSSL_CORE_HANDLE *handle); 29 void core_set_error_debug(const OSSL_CORE_HANDLE *handle, 30 const char *file, int line, const char *func); 31 void core_vset_error(const OSSL_CORE_HANDLE *handle, 32 uint32_t reason, const char *fmt, va_list args); 33 34 int core_obj_add_sigid(const OSSL_CORE_HANDLE *prov, const char *sign_name, 35 const char *digest_name, const char *pkey_name); 36 int core_obj_create(const OSSL_CORE_HANDLE *handle, const char *oid, 37 const char *sn, const char *ln); 38 39 /* 40 * Some OpenSSL functionality is directly offered to providers via 41 * dispatch 42 */ 43 void *CRYPTO_malloc(size_t num, const char *file, int line); 44 void *CRYPTO_zalloc(size_t num, const char *file, int line); 45 void CRYPTO_free(void *ptr, const char *file, int line); 46 void CRYPTO_clear_free(void *ptr, size_t num, 47 const char *file, int line); 48 void *CRYPTO_realloc(void *addr, size_t num, 49 const char *file, int line); 50 void *CRYPTO_clear_realloc(void *addr, size_t old_num, size_t num, 51 const char *file, int line); 52 void *CRYPTO_secure_malloc(size_t num, const char *file, int line); 53 void *CRYPTO_secure_zalloc(size_t num, const char *file, int line); 54 void CRYPTO_secure_free(void *ptr, const char *file, int line); 55 void CRYPTO_secure_clear_free(void *ptr, size_t num, 56 const char *file, int line); 57 int CRYPTO_secure_allocated(const void *ptr); 58 void OPENSSL_cleanse(void *ptr, size_t len); 59 60 unsigned char *OPENSSL_hexstr2buf(const char *str, long *buflen); 61 62 OSSL_CORE_BIO *BIO_new_file(const char *filename, const char *mode); 63 OSSL_CORE_BIO *BIO_new_membuf(const void *buf, int len); 64 int BIO_read_ex(OSSL_CORE_BIO *bio, void *data, size_t data_len, 65 size_t *bytes_read); 66 int BIO_write_ex(OSSL_CORE_BIO *bio, const void *data, size_t data_len, 67 size_t *written); 68 int BIO_up_ref(OSSL_CORE_BIO *bio); 69 int BIO_free(OSSL_CORE_BIO *bio); 70 int BIO_vprintf(OSSL_CORE_BIO *bio, const char *format, va_list args); 71 int BIO_vsnprintf(char *buf, size_t n, const char *fmt, va_list args); 72 73 void OSSL_SELF_TEST_set_callback(OSSL_LIB_CTX *libctx, OSSL_CALLBACK *cb, 74 void *cbarg); 75 76 size_t get_entropy(const OSSL_CORE_HANDLE *handle, 77 unsigned char **pout, int entropy, 78 size_t min_len, size_t max_len); 79 size_t get_user_entropy(const OSSL_CORE_HANDLE *handle, 80 unsigned char **pout, int entropy, 81 size_t min_len, size_t max_len); 82 void cleanup_entropy(const OSSL_CORE_HANDLE *handle, 83 unsigned char *buf, size_t len); 84 void cleanup_user_entropy(const OSSL_CORE_HANDLE *handle, 85 unsigned char *buf, size_t len); 86 size_t get_nonce(const OSSL_CORE_HANDLE *handle, 87 unsigned char **pout, size_t min_len, size_t max_len, 88 const void *salt, size_t salt_len); 89 size_t get_user_nonce(const OSSL_CORE_HANDLE *handle, 90 unsigned char **pout, size_t min_len, size_t max_len, 91 const void *salt, size_t salt_len); 92 void cleanup_nonce(const OSSL_CORE_HANDLE *handle, 93 unsigned char *buf, size_t len); 94 void cleanup_user_nonce(const OSSL_CORE_HANDLE *handle, 95 unsigned char *buf, size_t len); 96 97 /* Functions for querying the providers in the application library context */ 98 int provider_register_child_cb(const OSSL_CORE_HANDLE *handle, 99 int (*create_cb)(const OSSL_CORE_HANDLE *provider, 100 void *cbdata), 101 int (*remove_cb)(const OSSL_CORE_HANDLE *provider, 102 void *cbdata), 103 int (*global_props_cb)(const char *props, void *cbdata), 104 void *cbdata); 105 void provider_deregister_child_cb(const OSSL_CORE_HANDLE *handle); 106 const char *provider_name(const OSSL_CORE_HANDLE *prov); 107 void *provider_get0_provider_ctx(const OSSL_CORE_HANDLE *prov); 108 const OSSL_DISPATCH *provider_get0_dispatch(const OSSL_CORE_HANDLE *prov); 109 int provider_up_ref(const OSSL_CORE_HANDLE *prov, int activate); 110 int provider_free(const OSSL_CORE_HANDLE *prov, int deactivate); 111 112 /* Functions offered by the provider to libcrypto */ 113 void provider_teardown(void *provctx); 114 const OSSL_ITEM *provider_gettable_params(void *provctx); 115 int provider_get_params(void *provctx, OSSL_PARAM params[]); 116 const OSSL_ALGORITHM *provider_query_operation(void *provctx, 117 int operation_id, 118 const int *no_store); 119 void provider_unquery_operation(void *provctx, int operation_id, 120 const OSSL_ALGORITHM *algs); 121 const OSSL_ITEM *provider_get_reason_strings(void *provctx); 122 int provider_get_capabilities(void *provctx, const char *capability, 123 OSSL_CALLBACK *cb, void *arg); 124 int provider_self_test(void *provctx); 125 126=head1 DESCRIPTION 127 128All "functions" mentioned here are passed as function pointers between 129F<libcrypto> and the provider in L<OSSL_DISPATCH(3)> arrays, in the call 130of the provider initialization function. See L<provider(7)/Provider> 131for a description of the initialization function. They are known as "upcalls". 132 133All these "functions" have a corresponding function type definition 134named B<OSSL_FUNC_{name}_fn>, and a helper function to retrieve the 135function pointer from a L<OSSL_DISPATCH(3)> element named 136B<OSSL_FUNC_{name}>. 137For example, the "function" core_gettable_params() has these: 138 139 typedef OSSL_PARAM * 140 (OSSL_FUNC_core_gettable_params_fn)(const OSSL_CORE_HANDLE *handle); 141 static ossl_inline OSSL_NAME_core_gettable_params_fn 142 OSSL_FUNC_core_gettable_params(const OSSL_DISPATCH *opf); 143 144L<OSSL_DISPATCH(3)> arrays are indexed by numbers that are provided as 145macros in L<openssl-core_dispatch.h(7)>, as follows: 146 147For I<in> (the L<OSSL_DISPATCH(3)> array passed from F<libcrypto> to the 148provider): 149 150 core_gettable_params OSSL_FUNC_CORE_GETTABLE_PARAMS 151 core_get_params OSSL_FUNC_CORE_GET_PARAMS 152 core_thread_start OSSL_FUNC_CORE_THREAD_START 153 core_get_libctx OSSL_FUNC_CORE_GET_LIBCTX 154 core_new_error OSSL_FUNC_CORE_NEW_ERROR 155 core_set_error_debug OSSL_FUNC_CORE_SET_ERROR_DEBUG 156 core_vset_error OSSL_FUNC_CORE_VSET_ERROR 157 core_obj_add_sigid OSSL_FUNC_CORE_OBJ_ADD_SIGID 158 core_obj_create OSSL_FUNC_CORE_OBJ_CREATE 159 CRYPTO_malloc OSSL_FUNC_CRYPTO_MALLOC 160 CRYPTO_zalloc OSSL_FUNC_CRYPTO_ZALLOC 161 CRYPTO_free OSSL_FUNC_CRYPTO_FREE 162 CRYPTO_clear_free OSSL_FUNC_CRYPTO_CLEAR_FREE 163 CRYPTO_realloc OSSL_FUNC_CRYPTO_REALLOC 164 CRYPTO_clear_realloc OSSL_FUNC_CRYPTO_CLEAR_REALLOC 165 CRYPTO_secure_malloc OSSL_FUNC_CRYPTO_SECURE_MALLOC 166 CRYPTO_secure_zalloc OSSL_FUNC_CRYPTO_SECURE_ZALLOC 167 CRYPTO_secure_free OSSL_FUNC_CRYPTO_SECURE_FREE 168 CRYPTO_secure_clear_free OSSL_FUNC_CRYPTO_SECURE_CLEAR_FREE 169 CRYPTO_secure_allocated OSSL_FUNC_CRYPTO_SECURE_ALLOCATED 170 BIO_new_file OSSL_FUNC_BIO_NEW_FILE 171 BIO_new_mem_buf OSSL_FUNC_BIO_NEW_MEMBUF 172 BIO_read_ex OSSL_FUNC_BIO_READ_EX 173 BIO_write_ex OSSL_FUNC_BIO_WRITE_EX 174 BIO_up_ref OSSL_FUNC_BIO_UP_REF 175 BIO_free OSSL_FUNC_BIO_FREE 176 BIO_vprintf OSSL_FUNC_BIO_VPRINTF 177 BIO_vsnprintf OSSL_FUNC_BIO_VSNPRINTF 178 BIO_puts OSSL_FUNC_BIO_PUTS 179 BIO_gets OSSL_FUNC_BIO_GETS 180 BIO_ctrl OSSL_FUNC_BIO_CTRL 181 OPENSSL_cleanse OSSL_FUNC_OPENSSL_CLEANSE 182 OSSL_SELF_TEST_set_callback OSSL_FUNC_SELF_TEST_CB 183 ossl_rand_get_entropy OSSL_FUNC_GET_ENTROPY 184 ossl_rand_get_user_entropy OSSL_FUNC_GET_USER_ENTROPY 185 ossl_rand_cleanup_entropy OSSL_FUNC_CLEANUP_ENTROPY 186 ossl_rand_cleanup_user_entropy OSSL_FUNC_CLEANUP_USER_ENTROPY 187 ossl_rand_get_nonce OSSL_FUNC_GET_NONCE 188 ossl_rand_get_user_nonce OSSL_FUNC_GET_USER_NONCE 189 ossl_rand_cleanup_nonce OSSL_FUNC_CLEANUP_NONCE 190 ossl_rand_cleanup_user_nonce OSSL_FUNC_CLEANUP_USER_NONCE 191 provider_register_child_cb OSSL_FUNC_PROVIDER_REGISTER_CHILD_CB 192 provider_deregister_child_cb OSSL_FUNC_PROVIDER_DEREGISTER_CHILD_CB 193 provider_name OSSL_FUNC_PROVIDER_NAME 194 provider_get0_provider_ctx OSSL_FUNC_PROVIDER_GET0_PROVIDER_CTX 195 provider_get0_dispatch OSSL_FUNC_PROVIDER_GET0_DISPATCH 196 provider_up_ref OSSL_FUNC_PROVIDER_UP_REF 197 provider_free OSSL_FUNC_PROVIDER_FREE 198 199For I<*out> (the L<OSSL_DISPATCH(3)> array passed from the provider to 200F<libcrypto>): 201 202 provider_teardown OSSL_FUNC_PROVIDER_TEARDOWN 203 provider_gettable_params OSSL_FUNC_PROVIDER_GETTABLE_PARAMS 204 provider_get_params OSSL_FUNC_PROVIDER_GET_PARAMS 205 provider_query_operation OSSL_FUNC_PROVIDER_QUERY_OPERATION 206 provider_unquery_operation OSSL_FUNC_PROVIDER_UNQUERY_OPERATION 207 provider_get_reason_strings OSSL_FUNC_PROVIDER_GET_REASON_STRINGS 208 provider_get_capabilities OSSL_FUNC_PROVIDER_GET_CAPABILITIES 209 provider_self_test OSSL_FUNC_PROVIDER_SELF_TEST 210 211=head2 Core functions 212 213core_gettable_params() returns a constant array of descriptor 214L<OSSL_PARAM(3)>, for parameters that core_get_params() can handle. 215 216core_get_params() retrieves parameters from the core for the given I<handle>. 217See L</Core parameters> below for a description of currently known 218parameters. 219 220The core_thread_start() function informs the core that the provider has stated 221an interest in the current thread. The core will inform the provider when the 222thread eventually stops. It must be passed the I<handle> for this provider, as 223well as a callback I<handfn> which will be called when the thread stops. The 224callback will subsequently be called, with the supplied argument I<arg>, from 225the thread that is stopping and gets passed the provider context as an 226argument. This may be useful to perform thread specific clean up such as 227freeing thread local variables. 228 229core_get_libctx() retrieves the core context in which the library 230object for the current provider is stored, accessible through the I<handle>. 231This function is useful only for built-in providers such as the default 232provider. Never cast this to OSSL_LIB_CTX in a provider that is not 233built-in as the OSSL_LIB_CTX of the library loading the provider might be 234a completely different structure than the OSSL_LIB_CTX of the library the 235provider is linked to. Use L<OSSL_LIB_CTX_new_child(3)> instead to obtain 236a proper library context that is linked to the application library context. 237 238core_new_error(), core_set_error_debug() and core_vset_error() are 239building blocks for reporting an error back to the core, with 240reference to the I<handle>. 241 242=over 4 243 244=item core_new_error() 245 246allocates a new thread specific error record. 247 248This corresponds to the OpenSSL function L<ERR_new(3)>. 249 250=item core_set_error_debug() 251 252sets debugging information in the current thread specific error 253record. 254The debugging information includes the name of the file I<file>, the 255line I<line> and the function name I<func> where the error occurred. 256 257This corresponds to the OpenSSL function L<ERR_set_debug(3)>. 258 259=item core_vset_error() 260 261sets the I<reason> for the error, along with any addition data. 262The I<reason> is a number defined by the provider and used to index 263the reason strings table that's returned by 264provider_get_reason_strings(). 265The additional data is given as a format string I<fmt> and a set of 266arguments I<args>, which are treated in the same manner as with 267BIO_vsnprintf(). 268I<file> and I<line> may also be passed to indicate exactly where the 269error occurred or was reported. 270 271This corresponds to the OpenSSL function L<ERR_vset_error(3)>. 272 273=back 274 275The core_obj_create() function registers a new OID and associated short name 276I<sn> and long name I<ln> for the given I<handle>. It is similar to the OpenSSL 277function L<OBJ_create(3)> except that it returns 1 on success or 0 on failure. 278It will treat as success the case where the OID already exists (even if the 279short name I<sn> or long name I<ln> provided as arguments differ from those 280associated with the existing OID, in which case the new names are not 281associated). 282 283The core_obj_add_sigid() function registers a new composite signature algorithm 284(I<sign_name>) consisting of an underlying signature algorithm (I<pkey_name>) 285and digest algorithm (I<digest_name>) for the given I<handle>. It assumes that 286the OIDs for the composite signature algorithm as well as for the underlying 287signature and digest algorithms are either already known to OpenSSL or have been 288registered via a call to core_obj_create(). It corresponds to the OpenSSL 289function L<OBJ_add_sigid(3)>, except that the objects are identified by name 290rather than a numeric NID. Any name (OID, short name or long name) can be used 291to identify the object. It will treat as success the case where the composite 292signature algorithm already exists (even if registered against a different 293underlying signature or digest algorithm). For I<digest_name>, NULL or an 294empty string is permissible for signature algorithms that do not need a digest 295to operate correctly. The function returns 1 on success or 0 on failure. 296 297CRYPTO_malloc(), CRYPTO_zalloc(), CRYPTO_free(), CRYPTO_clear_free(), 298CRYPTO_realloc(), CRYPTO_clear_realloc(), CRYPTO_secure_malloc(), 299CRYPTO_secure_zalloc(), CRYPTO_secure_free(), 300CRYPTO_secure_clear_free(), CRYPTO_secure_allocated(), 301BIO_new_file(), BIO_new_mem_buf(), BIO_read_ex(), BIO_write_ex(), BIO_up_ref(), 302BIO_free(), BIO_vprintf(), BIO_vsnprintf(), BIO_gets(), BIO_puts(), 303BIO_ctrl(), OPENSSL_cleanse() and 304OPENSSL_hexstr2buf() correspond exactly to the public functions with 305the same name. As a matter of fact, the pointers in the L<OSSL_DISPATCH(3)> 306array are typically direct pointers to those public functions. Note that the BIO 307functions take an B<OSSL_CORE_BIO> type rather than the standard B<BIO> 308type. This is to ensure that a provider does not mix BIOs from the core 309with BIOs used on the provider side (the two are not compatible). 310OSSL_SELF_TEST_set_callback() is used to set an optional callback that can be 311passed into a provider. This may be ignored by a provider. 312 313get_entropy() retrieves seeding material from the operating system. 314The seeding material will have at least I<entropy> bytes of randomness and the 315output will have at least I<min_len> and at most I<max_len> bytes. 316The buffer address is stored in I<*pout> and the buffer length is 317returned to the caller. On error, zero is returned. 318 319get_user_entropy() is the same as get_entropy() except that it will 320attempt to gather seed material via the seed source specified by a call to 321L<RAND_set_seed_source_type(3)> or via L<config(5)/Random Configuration>. 322 323cleanup_entropy() is used to clean up and free the buffer returned by 324get_entropy(). The entropy pointer returned by get_entropy() 325is passed in B<buf> and its length in B<len>. 326 327cleanup_user_entropy() is used to clean up and free the buffer returned by 328get_user_entropy(). The entropy pointer returned by get_user_entropy() 329is passed in B<buf> and its length in B<len>. 330 331get_nonce() retrieves a nonce using the passed I<salt> parameter 332of length I<salt_len> and operating system specific information. 333The I<salt> should contain uniquely identifying information and this is 334included, in an unspecified manner, as part of the output. 335The output is stored in a buffer which contains at least I<min_len> and at 336most I<max_len> bytes. The buffer address is stored in I<*pout> and the 337buffer length returned to the caller. On error, zero is returned. 338 339get_user_nonce() is the same as get_nonce() except that it will attempt 340to gather seed material via the seed source specified by a call to 341L<RAND_set_seed_source_type(3)> or via L<config(5)/Random Configuration>. 342 343cleanup_nonce() is used to clean up and free the buffer returned by 344get_nonce(). The nonce pointer returned by get_nonce() 345is passed in B<buf> and its length in B<len>. 346 347cleanup_user_nonce() is used to clean up and free the buffer returned by 348get_user_nonce(). The nonce pointer returned by get_user_nonce() 349is passed in B<buf> and its length in B<len>. 350 351provider_register_child_cb() registers callbacks for being informed about the 352loading and unloading of providers in the application's library context. 353I<handle> is this provider's handle and I<cbdata> is this provider's data 354that will be passed back to the callbacks. It returns 1 on success or 0 355otherwise. These callbacks may be called while holding locks in libcrypto. In 356order to avoid deadlocks the callback implementation must not be long running 357and must not call other OpenSSL API functions or upcalls. 358 359I<create_cb> is a callback that will be called when a new provider is loaded 360into the application's library context. It is also called for any providers that 361are already loaded at the point that this callback is registered. The callback 362is passed the handle being used for the new provider being loadded and this 363provider's data in I<cbdata>. It should return 1 on success or 0 on failure. 364 365I<remove_cb> is a callback that will be called when a new provider is unloaded 366from the application's library context. It is passed the handle being used for 367the provider being unloaded and this provider's data in I<cbdata>. It should 368return 1 on success or 0 on failure. 369 370I<global_props_cb> is a callback that will be called when the global properties 371from the parent library context are changed. It should return 1 on success 372or 0 on failure. 373 374provider_deregister_child_cb() unregisters callbacks previously registered via 375provider_register_child_cb(). If provider_register_child_cb() has been called 376then provider_deregister_child_cb() should be called at or before the point that 377this provider's teardown function is called. 378 379provider_name() returns a string giving the name of the provider identified by 380I<handle>. 381 382provider_get0_provider_ctx() returns the provider context that is associated 383with the provider identified by I<prov>. 384 385provider_get0_dispatch() gets the dispatch table registered by the provider 386identified by I<prov> when it initialised. 387 388provider_up_ref() increments the reference count on the provider I<prov>. If 389I<activate> is nonzero then the provider is also loaded if it is not already 390loaded. It returns 1 on success or 0 on failure. 391 392provider_free() decrements the reference count on the provider I<prov>. If 393I<deactivate> is nonzero then the provider is also unloaded if it is not 394already loaded. It returns 1 on success or 0 on failure. 395 396=head2 Provider functions 397 398provider_teardown() is called when a provider is shut down and removed 399from the core's provider store. 400It must free the passed I<provctx>. 401 402provider_gettable_params() should return a constant array of 403descriptor L<OSSL_PARAM(3)>, for parameters that provider_get_params() 404can handle. 405 406provider_get_params() should process the L<OSSL_PARAM(3)> array 407I<params>, setting the values of the parameters it understands. 408 409provider_query_operation() should return a constant L<OSSL_ALGORITHM(3)> 410that corresponds to the given I<operation_id>. 411It should indicate if the core may store a reference to this array by 412setting I<*no_store> to 0 (core may store a reference) or 1 (core may 413not store a reference). 414 415provider_unquery_operation() informs the provider that the result of a 416provider_query_operation() is no longer directly required and that the function 417pointers have been copied. The I<operation_id> should match that passed to 418provider_query_operation() and I<algs> should be its return value. 419 420provider_get_reason_strings() should return a constant L<OSSL_ITEM(3)> 421array that provides reason strings for reason codes the provider may 422use when reporting errors using core_put_error(). 423 424The provider_get_capabilities() function should call the callback I<cb> passing 425it a set of L<OSSL_PARAM(3)>s and the caller supplied argument I<arg>. The 426L<OSSL_PARAM(3)>s should provide details about the capability with the name given 427in the I<capability> argument relevant for the provider context I<provctx>. If a 428provider supports multiple capabilities with the given name then it may call the 429callback multiple times (one for each capability). Capabilities can be useful for 430describing the services that a provider can offer. For further details see the 431L</CAPABILITIES> section below. It should return 1 on success or 0 on error. 432 433The provider_self_test() function should perform known answer tests on a subset 434of the algorithms that it uses, and may also verify the integrity of the 435provider module. It should return 1 on success or 0 on error. It will return 1 436if this function is not used. 437 438None of these functions are mandatory, but a provider is fairly 439useless without at least provider_query_operation(), and 440provider_gettable_params() is fairly useless if not accompanied by 441provider_get_params(). 442 443=head2 Provider parameters 444 445provider_get_params() can return the following provider parameters to the core: 446 447=over 4 448 449=item "name" (B<OSSL_PROV_PARAM_NAME>) <UTF8 ptr> 450 451This points to a string that should give a unique name for the provider. 452 453=item "version" (B<OSSL_PROV_PARAM_VERSION>) <UTF8 ptr> 454 455This points to a string that is a version number associated with this provider. 456OpenSSL in-built providers use OPENSSL_VERSION_STR, but this may be different 457for any third party provider. This string is for informational purposes only. 458 459=item "buildinfo" (B<OSSL_PROV_PARAM_BUILDINFO>) <UTF8 ptr> 460 461This points to a string that is a build information associated with this provider. 462OpenSSL in-built providers use OPENSSL_FULL_VERSION_STR, but this may be 463different for any third party provider. 464 465=item "status" (B<OSSL_PROV_PARAM_STATUS>) <unsigned integer> 466 467This returns 0 if the provider has entered an error state, otherwise it returns 4681. 469 470=back 471 472provider_gettable_params() should return the above parameters. 473 474 475=head2 Core parameters 476 477core_get_params() can retrieve the following core parameters for each provider: 478 479=over 4 480 481=item "openssl-version" (B<OSSL_PROV_PARAM_CORE_VERSION>) <UTF8 string ptr> 482 483This points to the OpenSSL libraries' full version string, i.e. the string 484expanded from the macro B<OPENSSL_VERSION_STR>. 485 486=item "provider-name" (B<OSSL_PROV_PARAM_CORE_PROV_NAME>) <UTF8 string ptr> 487 488This points to the OpenSSL libraries' idea of what the calling provider is named. 489 490=item "module-filename" (B<OSSL_PROV_PARAM_CORE_MODULE_FILENAME>) <UTF8 string ptr> 491 492This points to a string containing the full filename of the providers 493module file. 494 495=back 496 497Additionally, provider specific configuration parameters from the 498config file are available, in dotted name form. 499The dotted name form is a concatenation of section names and final 500config command name separated by periods. 501 502For example, let's say we have the following config example: 503 504 config_diagnostics = 1 505 openssl_conf = openssl_init 506 507 [openssl_init] 508 providers = providers_sect 509 510 [providers_sect] 511 foo = foo_sect 512 513 [foo_sect] 514 activate = 1 515 data1 = 2 516 data2 = str 517 more = foo_more 518 519 [foo_more] 520 data3 = foo,bar 521 522The provider will have these additional parameters available: 523 524=over 4 525 526=item "activate" 527 528pointing at the string "1" 529 530=item "data1" 531 532pointing at the string "2" 533 534=item "data2" 535 536pointing at the string "str" 537 538=item "more.data3" 539 540pointing at the string "foo,bar" 541 542=back 543 544For more information on handling parameters, see L<OSSL_PARAM(3)> as 545L<OSSL_PARAM_int(3)>. 546 547=head1 CAPABILITIES 548 549Capabilities describe some of the services that a provider can offer. 550Applications can query the capabilities to discover those services. 551 552=head3 "TLS-GROUP" Capability 553 554The "TLS-GROUP" capability can be queried by libssl to discover the list of 555TLS groups that a provider can support. Each group supported can be used for 556I<key exchange> (KEX) or I<key encapsulation method> (KEM) during a TLS 557handshake. 558TLS clients can advertise the list of TLS groups they support in the 559supported_groups extension, and TLS servers can select a group from the offered 560list that they also support. In this way a provider can add to the list of 561groups that libssl already supports with additional ones. 562 563Each TLS group that a provider supports should be described via the callback 564passed in through the provider_get_capabilities function. Each group should have 565the following details supplied (all are mandatory, except 566B<OSSL_CAPABILITY_TLS_GROUP_IS_KEM>): 567 568=over 4 569 570=item "tls-group-name" (B<OSSL_CAPABILITY_TLS_GROUP_NAME>) <UTF8 string> 571 572The name of the group as given in the IANA TLS Supported Groups registry 573L<https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-8>. 574 575=item "tls-group-name-internal" (B<OSSL_CAPABILITY_TLS_GROUP_NAME_INTERNAL>) <UTF8 string> 576 577The name of the group as known by the provider. This could be the same as the 578"tls-group-name", but does not have to be. 579 580=item "tls-group-id" (B<OSSL_CAPABILITY_TLS_GROUP_ID>) <unsigned integer> 581 582The TLS group id value as given in the IANA TLS Supported Groups registry. 583 584It is possible to register the same group id from within different 585providers. Users should note that if no property query is specified, or 586more than one implementation matches the property query then it is 587unspecified which implementation for a particular group id will be used. 588 589=item "tls-group-alg" (B<OSSL_CAPABILITY_TLS_GROUP_ALG>) <UTF8 string> 590 591The name of a Key Management algorithm that the provider offers and that should 592be used with this group. Keys created should be able to support I<key exchange> 593or I<key encapsulation method> (KEM), as implied by the optional 594B<OSSL_CAPABILITY_TLS_GROUP_IS_KEM> flag. 595The algorithm must support key and parameter generation as well as the 596key/parameter generation parameter, B<OSSL_PKEY_PARAM_GROUP_NAME>. The group 597name given via "tls-group-name-internal" above will be passed via 598B<OSSL_PKEY_PARAM_GROUP_NAME> when libssl wishes to generate keys/parameters. 599 600=item "tls-group-sec-bits" (B<OSSL_CAPABILITY_TLS_GROUP_SECURITY_BITS>) <unsigned integer> 601 602The number of bits of security offered by keys in this group. The number of bits 603should be comparable with the ones given in table 2 and 3 of the NIST SP800-57 604document. 605 606=item "tls-group-is-kem" (B<OSSL_CAPABILITY_TLS_GROUP_IS_KEM>) <unsigned integer> 607 608Boolean flag to describe if the group should be used in I<key exchange> (KEX) 609mode (0, default) or in I<key encapsulation method> (KEM) mode (1). 610 611This parameter is optional: if not specified, KEX mode is assumed as the default 612mode for the group. 613 614In KEX mode, in a typical Diffie-Hellman fashion, both sides execute I<keygen> 615then I<derive> against the peer public key. To operate in KEX mode, the group 616implementation must support the provider functions as described in 617L<provider-keyexch(7)>. 618 619In KEM mode, the client executes I<keygen> and sends its public key, the server 620executes I<encapsulate> using the client's public key and sends back the 621resulting I<ciphertext>, finally the client executes I<decapsulate> to retrieve 622the same I<shared secret> generated by the server's I<encapsulate>. To operate 623in KEM mode, the group implementation must support the provider functions as 624described in L<provider-kem(7)>. 625 626Both in KEX and KEM mode, the resulting I<shared secret> is then used according 627to the protocol specification. 628 629=item "tls-min-tls" (B<OSSL_CAPABILITY_TLS_GROUP_MIN_TLS>) <integer> 630 631=item "tls-max-tls" (B<OSSL_CAPABILITY_TLS_GROUP_MAX_TLS>) <integer> 632 633=item "tls-min-dtls" (B<OSSL_CAPABILITY_TLS_GROUP_MIN_DTLS>) <integer> 634 635=item "tls-max-dtls" (B<OSSL_CAPABILITY_TLS_GROUP_MAX_DTLS>) <integer> 636 637These parameters can be used to describe the minimum and maximum TLS and DTLS 638versions supported by the group. The values equate to the on-the-wire encoding 639of the various TLS versions. For example TLSv1.3 is 0x0304 (772 decimal), and 640TLSv1.2 is 0x0303 (771 decimal). A 0 indicates that there is no defined minimum 641or maximum. A -1 indicates that the group should not be used in that protocol. 642 643=back 644 645=head3 "TLS-SIGALG" Capability 646 647The "TLS-SIGALG" capability can be queried by libssl to discover the list of 648TLS signature algorithms that a provider can support. Each signature supported 649can be used for client- or server-authentication in addition to the built-in 650signature algorithms. 651TLS1.3 clients can advertise the list of TLS signature algorithms they support 652in the signature_algorithms extension, and TLS servers can select an algorithm 653from the offered list that they also support. In this way a provider can add 654to the list of signature algorithms that libssl already supports with 655additional ones. 656 657Each TLS signature algorithm that a provider supports should be described via 658the callback passed in through the provider_get_capabilities function. Each 659algorithm can have the following details supplied: 660 661=over 4 662 663=item "iana-name" (B<OSSL_CAPABILITY_TLS_SIGALG_IANA_NAME>) <UTF8 string> 664 665The name of the signature algorithm as given in the IANA TLS Signature Scheme 666registry as "Description": 667L<https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-signaturescheme>. 668This value must be supplied. 669 670=item "iana-code-point" (B<OSSL_CAPABILITY_TLS_SIGALG_CODE_POINT>) <unsigned integer> 671 672The TLS algorithm ID value as given in the IANA TLS SignatureScheme registry. 673This value must be supplied. 674 675It is possible to register the same code point from within different 676providers. Users should note that if no property query is specified, or 677more than one implementation matches the property query then it is 678unspecified which implementation for a particular code point will be used. 679 680=item "sigalg-name" (B<OSSL_CAPABILITY_TLS_SIGALG_NAME>) <UTF8 string> 681 682A name for the full (possibly composite hash-and-signature) signature 683algorithm. 684The provider may, but is not obligated to, provide a signature implementation 685with this name; if it doesn't, this is assumed to be a composite of a pure 686signature algorithm and a hash algorithm, which must be given with the 687parameters "sig-name" and "hash-name". 688This value must be supplied. 689 690=item "sigalg-oid" (B<OSSL_CAPABILITY_TLS_SIGALG_OID>) <UTF8 string> 691 692The OID of the "sigalg-name" algorithm in canonical numeric text form. If 693this parameter is given, OBJ_create() will be used to create an OBJ and 694a NID for this OID, using the "sigalg-name" parameter for its (short) name. 695Otherwise, it's assumed to already exist in the object database, possibly 696done by the provider with the core_obj_create() upcall. 697This value is optional. 698 699=item "sig-name" (B<OSSL_CAPABILITY_TLS_SIGALG_SIG_NAME>) <UTF8 string> 700 701The name of the pure signature algorithm that is part of a composite 702"sigalg-name". If "sigalg-name" is implemented by the provider, this 703parameter is redundant and must not be given. 704This value is optional. 705 706=item "sig-oid" (B<OSSL_CAPABILITY_TLS_SIGALG_SIG_OID>) <UTF8 string> 707 708The OID of the "sig-name" algorithm in canonical numeric text form. If 709this parameter is given, OBJ_create() will be used to create an OBJ and 710a NID for this OID, using the "sig-name" parameter for its (short) name. 711Otherwise, it is assumed to already exist in the object database. This 712can be done by the provider using the core_obj_create() upcall. 713This value is optional. 714 715=item "hash-name" (B<OSSL_CAPABILITY_TLS_SIGALG_HASH_NAME>) <UTF8 string> 716 717The name of the hash algorithm that is part of a composite "sigalg-name". 718If "sigalg-name" is implemented by the provider, this parameter is redundant 719and must not be given. 720This value is optional. 721 722=item "hash-oid" (B<OSSL_CAPABILITY_TLS_SIGALG_HASH_OID>) <UTF8 string> 723 724The OID of the "hash-name" algorithm in canonical numeric text form. If 725this parameter is given, OBJ_create() will be used to create an OBJ and 726a NID for this OID, using the "hash-name" parameter for its (short) name. 727Otherwise, it's assumed to already exist in the object database, possibly 728done by the provider with the core_obj_create() upcall. 729This value is optional. 730 731=item "key-type" (B<OSSL_CAPABILITY_TLS_SIGALG_KEYTYPE>) <UTF8 string> 732 733The key type of the public key of applicable certificates. If this parameter 734isn't present, it's assumed to be the same as "sig-name" if that's present, 735otherwise "sigalg-name". 736This value is optional. 737 738=item "key-type-oid" (B<OSSL_CAPABILITY_TLS_SIGALG_KEYTYPE_OID>) <UTF8 string> 739 740The OID of the "key-type" in canonical numeric text form. If 741this parameter is given, OBJ_create() will be used to create an OBJ and 742a NID for this OID, using the "key-type" parameter for its (short) name. 743Otherwise, it's assumed to already exist in the object database, possibly 744done by the provider with the core_obj_create() upcall. 745This value is optional. 746 747=item "sec-bits" (B<OSSL_CAPABILITY_TLS_SIGALG_SECURITY_BITS>) <unsigned integer> 748 749The number of bits of security offered by keys of this algorithm. The number 750of bits should be comparable with the ones given in table 2 and 3 of the NIST 751SP800-57 document. This number is used to determine the security strength of 752the algorithm if no digest algorithm has been registered that otherwise 753defines the security strength. If the signature algorithm implements its own 754digest internally, this value needs to be set to properly reflect the overall 755security strength. 756This value must be supplied. 757 758=item "tls-min-tls" (B<OSSL_CAPABILITY_TLS_SIGALG_MIN_TLS>) <integer> 759 760=item "tls-max-tls" (B<OSSL_CAPABILITY_TLS_SIGALG_MAX_TLS>) <integer> 761 762These parameters can be used to describe the minimum and maximum TLS 763versions supported by the signature algorithm. The values equate to the 764on-the-wire encoding of the various TLS versions. For example TLSv1.3 is 7650x0304 (772 decimal), and TLSv1.2 is 0x0303 (771 decimal). A 0 indicates that 766there is no defined minimum or maximum. A -1 indicates that the signature 767algorithm should not be used in that protocol. 768Presently values representing anything other than TLS1.3 mean that the 769complete algorithm is ignored. 770 771=back 772 773=head1 NOTES 774 775The core_obj_create() and core_obj_add_sigid() functions were not thread safe 776in OpenSSL 3.0. 777 778=head1 EXAMPLES 779 780This is an example of a simple provider made available as a 781dynamically loadable module. 782It implements the fictitious algorithm C<FOO> for the fictitious 783operation C<BAR>. 784 785 #include <malloc.h> 786 #include <openssl/core.h> 787 #include <openssl/core_dispatch.h> 788 789 /* Errors used in this provider */ 790 #define E_MALLOC 1 791 792 static const OSSL_ITEM reasons[] = { 793 { E_MALLOC, "memory allocation failure" }. 794 OSSL_DISPATCH_END 795 }; 796 797 /* 798 * To ensure we get the function signature right, forward declare 799 * them using function types provided by openssl/core_dispatch.h 800 */ 801 OSSL_FUNC_bar_newctx_fn foo_newctx; 802 OSSL_FUNC_bar_freectx_fn foo_freectx; 803 OSSL_FUNC_bar_init_fn foo_init; 804 OSSL_FUNC_bar_update_fn foo_update; 805 OSSL_FUNC_bar_final_fn foo_final; 806 807 OSSL_FUNC_provider_query_operation_fn p_query; 808 OSSL_FUNC_provider_get_reason_strings_fn p_reasons; 809 OSSL_FUNC_provider_teardown_fn p_teardown; 810 811 OSSL_provider_init_fn OSSL_provider_init; 812 813 OSSL_FUNC_core_put_error *c_put_error = NULL; 814 815 /* Provider context */ 816 struct prov_ctx_st { 817 OSSL_CORE_HANDLE *handle; 818 } 819 820 /* operation context for the algorithm FOO */ 821 struct foo_ctx_st { 822 struct prov_ctx_st *provctx; 823 int b; 824 }; 825 826 static void *foo_newctx(void *provctx) 827 { 828 struct foo_ctx_st *fooctx = malloc(sizeof(*fooctx)); 829 830 if (fooctx != NULL) 831 fooctx->provctx = provctx; 832 else 833 c_put_error(provctx->handle, E_MALLOC, __FILE__, __LINE__); 834 return fooctx; 835 } 836 837 static void foo_freectx(void *fooctx) 838 { 839 free(fooctx); 840 } 841 842 static int foo_init(void *vfooctx) 843 { 844 struct foo_ctx_st *fooctx = vfooctx; 845 846 fooctx->b = 0x33; 847 } 848 849 static int foo_update(void *vfooctx, unsigned char *in, size_t inl) 850 { 851 struct foo_ctx_st *fooctx = vfooctx; 852 853 /* did you expect something serious? */ 854 if (inl == 0) 855 return 1; 856 for (; inl-- > 0; in++) 857 *in ^= fooctx->b; 858 return 1; 859 } 860 861 static int foo_final(void *vfooctx) 862 { 863 struct foo_ctx_st *fooctx = vfooctx; 864 865 fooctx->b = 0x66; 866 } 867 868 static const OSSL_DISPATCH foo_fns[] = { 869 { OSSL_FUNC_BAR_NEWCTX, (void (*)(void))foo_newctx }, 870 { OSSL_FUNC_BAR_FREECTX, (void (*)(void))foo_freectx }, 871 { OSSL_FUNC_BAR_INIT, (void (*)(void))foo_init }, 872 { OSSL_FUNC_BAR_UPDATE, (void (*)(void))foo_update }, 873 { OSSL_FUNC_BAR_FINAL, (void (*)(void))foo_final }, 874 OSSL_DISPATCH_END 875 }; 876 877 static const OSSL_ALGORITHM bars[] = { 878 { "FOO", "provider=chumbawamba", foo_fns }, 879 { NULL, NULL, NULL } 880 }; 881 882 static const OSSL_ALGORITHM *p_query(void *provctx, int operation_id, 883 int *no_store) 884 { 885 switch (operation_id) { 886 case OSSL_OP_BAR: 887 return bars; 888 } 889 return NULL; 890 } 891 892 static const OSSL_ITEM *p_reasons(void *provctx) 893 { 894 return reasons; 895 } 896 897 static void p_teardown(void *provctx) 898 { 899 free(provctx); 900 } 901 902 static const OSSL_DISPATCH prov_fns[] = { 903 { OSSL_FUNC_PROVIDER_TEARDOWN, (void (*)(void))p_teardown }, 904 { OSSL_FUNC_PROVIDER_QUERY_OPERATION, (void (*)(void))p_query }, 905 { OSSL_FUNC_PROVIDER_GET_REASON_STRINGS, (void (*)(void))p_reasons }, 906 OSSL_DISPATCH_END 907 }; 908 909 int OSSL_provider_init(const OSSL_CORE_HANDLE *handle, 910 const OSSL_DISPATCH *in, 911 const OSSL_DISPATCH **out, 912 void **provctx) 913 { 914 struct prov_ctx_st *pctx = NULL; 915 916 for (; in->function_id != 0; in++) 917 switch (in->function_id) { 918 case OSSL_FUNC_CORE_PUT_ERROR: 919 c_put_error = OSSL_FUNC_core_put_error(in); 920 break; 921 } 922 923 *out = prov_fns; 924 925 if ((pctx = malloc(sizeof(*pctx))) == NULL) { 926 /* 927 * ALEA IACTA EST, if the core retrieves the reason table 928 * regardless, that string will be displayed, otherwise not. 929 */ 930 c_put_error(handle, E_MALLOC, __FILE__, __LINE__); 931 return 0; 932 } 933 pctx->handle = handle; 934 return 1; 935 } 936 937This relies on a few things existing in F<openssl/core_dispatch.h>: 938 939 #define OSSL_OP_BAR 4711 940 941 #define OSSL_FUNC_BAR_NEWCTX 1 942 typedef void *(OSSL_FUNC_bar_newctx_fn)(void *provctx); 943 static ossl_inline OSSL_FUNC_bar_newctx(const OSSL_DISPATCH *opf) 944 { return (OSSL_FUNC_bar_newctx_fn *)opf->function; } 945 946 #define OSSL_FUNC_BAR_FREECTX 2 947 typedef void (OSSL_FUNC_bar_freectx_fn)(void *ctx); 948 static ossl_inline OSSL_FUNC_bar_freectx(const OSSL_DISPATCH *opf) 949 { return (OSSL_FUNC_bar_freectx_fn *)opf->function; } 950 951 #define OSSL_FUNC_BAR_INIT 3 952 typedef void *(OSSL_FUNC_bar_init_fn)(void *ctx); 953 static ossl_inline OSSL_FUNC_bar_init(const OSSL_DISPATCH *opf) 954 { return (OSSL_FUNC_bar_init_fn *)opf->function; } 955 956 #define OSSL_FUNC_BAR_UPDATE 4 957 typedef void *(OSSL_FUNC_bar_update_fn)(void *ctx, 958 unsigned char *in, size_t inl); 959 static ossl_inline OSSL_FUNC_bar_update(const OSSL_DISPATCH *opf) 960 { return (OSSL_FUNC_bar_update_fn *)opf->function; } 961 962 #define OSSL_FUNC_BAR_FINAL 5 963 typedef void *(OSSL_FUNC_bar_final_fn)(void *ctx); 964 static ossl_inline OSSL_FUNC_bar_final(const OSSL_DISPATCH *opf) 965 { return (OSSL_FUNC_bar_final_fn *)opf->function; } 966 967=head1 SEE ALSO 968 969L<provider(7)> 970 971=head1 HISTORY 972 973The concept of providers and everything surrounding them was 974introduced in OpenSSL 3.0. 975 976=head1 COPYRIGHT 977 978Copyright 2019-2023 The OpenSSL Project Authors. All Rights Reserved. 979 980Licensed under the Apache License 2.0 (the "License"). You may not use 981this file except in compliance with the License. You can obtain a copy 982in the file LICENSE in the source distribution or at 983L<https://www.openssl.org/source/license.html>. 984 985=cut 986
