mirror/openssl
2
0
Fork 0
mirror of https://github.com/openssl/openssl.git synced 2024-12-09 05:51:54 +08:00
Code Issues Packages Projects Releases Wiki Activity
660c534435
openssl/crypto/evp/pmeth_check.c

176 lines
4.4 KiB
C
Raw Normal View History

Add RSA key validation to default provider Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/10780)
2020-01-29 18:32:32 +08:00
/*
* Copyright 2006-2020 The OpenSSL Project Authors. All Rights Reserved.
*
* 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
* https://www.openssl.org/source/license.html
*/
#include <stdio.h>
#include <stdlib.h>
#include "internal/cryptlib.h"
#include <openssl/objects.h>
#include <openssl/evp.h>
#include "crypto/bn.h"
#include "crypto/asn1.h"
#include "crypto/evp.h"
#include "evp_local.h"
int EVP_PKEY_public_check(EVP_PKEY_CTX *ctx)
{
EVP_PKEY *pkey = ctx->pkey;
void *key;
EVP_KEYMGMT *keymgmt;
if (pkey == NULL) {
EVPerr(EVP_F_EVP_PKEY_PUBLIC_CHECK, EVP_R_NO_KEY_SET);
return 0;
}
Rethink the EVP_PKEY cache of provider side keys The role of this cache was two-fold: 1. It was a cache of key copies exported to providers with which an operation was initiated. 2. If the EVP_PKEY didn't have a legacy key, item 0 of the cache was the corresponding provider side origin, while the rest was the actual cache. This dual role for item 0 made the code a bit confusing, so we now make a separate keymgmt / keydata pair outside of that cache, which is the provider side "origin" key. A hard rule is that an EVP_PKEY cannot hold a legacy "origin" and a provider side "origin" at the same time. Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/11148)
2020-02-21 03:26:16 +08:00
keymgmt = pkey->keymgmt;
key = pkey->keydata;
Add RSA key validation to default provider Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/10780)
2020-01-29 18:32:32 +08:00
if (key != NULL && keymgmt != NULL)
Redesign the KEYMGMT libcrypto <-> provider interface - the basics The KEYMGMT libcrypto <-> provider interface currently makes a few assumptions: 1. provider side domain parameters and key data isn't mutable. In other words, as soon as a key has been created in any (loaded, imported data, ...), it's set in stone. 2. provider side domain parameters can be strictly separated from the key data. This does work for the most part, but there are places where that's a bit too rigid for the functionality that the EVP_PKEY API delivers. Key data needs to be mutable to allow the flexibility that functions like EVP_PKEY_copy_parameters promise, as well as to provide the combinations of data that an EVP_PKEY is generally assumed to be able to hold: - domain parameters only - public key only - public key + private key - domain parameters + public key - domain parameters + public key + private key To remedy all this, we: 1. let go of the distinction between domain parameters and key material proper in the libcrypto <-> provider interface. As a consequence, functions that still need it gain a selection argument, which is a set of bits that indicate what parts of the key object are to be considered in a specific call. This allows a reduction of very similar functions into one. 2. Rework the libcrypto <-> provider interface so provider side key objects are created and destructed with a separate function, and get their data filled and extracted in through import and export. (future work will see other key object constructors and other functions to fill them with data) Fixes #10979 squash! Redesign the KEYMGMT libcrypto <-> provider interface - the basics Remedy 1 needs a rewrite: Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Shane Lontis <shane.lontis@oracle.com> Reviewed-by: Paul Dale <paul.dale@oracle.com> (Merged from https://github.com/openssl/openssl/pull/11006)
2020-02-03 01:56:07 +08:00
return evp_keymgmt_validate(keymgmt, key,
OSSL_KEYMGMT_SELECT_PUBLIC_KEY);
Add RSA key validation to default provider Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/10780)
2020-01-29 18:32:32 +08:00
EVP: Clarify the states of an EVP_PKEY EVP_PKEY is rather complex, even before provider side keys entered the stage. You could have untyped / unassigned keys (pk->type == EVP_PKEY_NONE), keys that had been assigned a type but no data (pk->pkey.ptr == NULL), and fully assigned keys (pk->type != EVP_PKEY_NONE && pk->pkey.ptr != NULL). For provider side keys, the corresponding states weren't well defined, and the code didn't quite account for all the possibilities. We also guard most of the legacy fields in EVP_PKEY with FIPS_MODE, so they don't exist at all in the FIPS module. Most of all, code needs to adapt to the case where an EVP_PKEY's |keymgmt| is non-NULL, but its |keydata| is NULL. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/11375)
2020-03-21 13:03:39 +08:00
if (pkey->type == EVP_PKEY_NONE)
goto not_supported;
Rename FIPS_MODE to FIPS_MODULE This macro is used to determine if certain pieces of code should become part of the FIPS module or not. The old name was confusing. Fixes #11538 Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org> (Merged from https://github.com/openssl/openssl/pull/11539)
2020-04-14 04:34:56 +08:00
#ifndef FIPS_MODULE
Add RSA key validation to default provider Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/10780)
2020-01-29 18:32:32 +08:00
/* legacy */
/* call customized public key check function first */
if (ctx->pmeth->public_check != NULL)
return ctx->pmeth->public_check(pkey);
/* use default public key check function in ameth */
EVP: Clarify the states of an EVP_PKEY EVP_PKEY is rather complex, even before provider side keys entered the stage. You could have untyped / unassigned keys (pk->type == EVP_PKEY_NONE), keys that had been assigned a type but no data (pk->pkey.ptr == NULL), and fully assigned keys (pk->type != EVP_PKEY_NONE && pk->pkey.ptr != NULL). For provider side keys, the corresponding states weren't well defined, and the code didn't quite account for all the possibilities. We also guard most of the legacy fields in EVP_PKEY with FIPS_MODE, so they don't exist at all in the FIPS module. Most of all, code needs to adapt to the case where an EVP_PKEY's |keymgmt| is non-NULL, but its |keydata| is NULL. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/11375)
2020-03-21 13:03:39 +08:00
if (pkey->ameth == NULL || pkey->ameth->pkey_public_check == NULL)
goto not_supported;
Add RSA key validation to default provider Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/10780)
2020-01-29 18:32:32 +08:00
return pkey->ameth->pkey_public_check(pkey);
EVP: Clarify the states of an EVP_PKEY EVP_PKEY is rather complex, even before provider side keys entered the stage. You could have untyped / unassigned keys (pk->type == EVP_PKEY_NONE), keys that had been assigned a type but no data (pk->pkey.ptr == NULL), and fully assigned keys (pk->type != EVP_PKEY_NONE && pk->pkey.ptr != NULL). For provider side keys, the corresponding states weren't well defined, and the code didn't quite account for all the possibilities. We also guard most of the legacy fields in EVP_PKEY with FIPS_MODE, so they don't exist at all in the FIPS module. Most of all, code needs to adapt to the case where an EVP_PKEY's |keymgmt| is non-NULL, but its |keydata| is NULL. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/11375)
2020-03-21 13:03:39 +08:00
#endif
not_supported:
EVPerr(0, EVP_R_OPERATION_NOT_SUPPORTED_FOR_THIS_KEYTYPE);
return -2;
Add RSA key validation to default provider Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/10780)
2020-01-29 18:32:32 +08:00
}
int EVP_PKEY_param_check(EVP_PKEY_CTX *ctx)
{
EVP_PKEY *pkey = ctx->pkey;
void *key;
EVP_KEYMGMT *keymgmt;
if (pkey == NULL) {
EVPerr(EVP_F_EVP_PKEY_PARAM_CHECK, EVP_R_NO_KEY_SET);
return 0;
}
Rethink the EVP_PKEY cache of provider side keys The role of this cache was two-fold: 1. It was a cache of key copies exported to providers with which an operation was initiated. 2. If the EVP_PKEY didn't have a legacy key, item 0 of the cache was the corresponding provider side origin, while the rest was the actual cache. This dual role for item 0 made the code a bit confusing, so we now make a separate keymgmt / keydata pair outside of that cache, which is the provider side "origin" key. A hard rule is that an EVP_PKEY cannot hold a legacy "origin" and a provider side "origin" at the same time. Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/11148)
2020-02-21 03:26:16 +08:00
keymgmt = pkey->keymgmt;
key = pkey->keydata;
Add RSA key validation to default provider Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/10780)
2020-01-29 18:32:32 +08:00
if (key != NULL && keymgmt != NULL)
Redesign the KEYMGMT libcrypto <-> provider interface - the basics The KEYMGMT libcrypto <-> provider interface currently makes a few assumptions: 1. provider side domain parameters and key data isn't mutable. In other words, as soon as a key has been created in any (loaded, imported data, ...), it's set in stone. 2. provider side domain parameters can be strictly separated from the key data. This does work for the most part, but there are places where that's a bit too rigid for the functionality that the EVP_PKEY API delivers. Key data needs to be mutable to allow the flexibility that functions like EVP_PKEY_copy_parameters promise, as well as to provide the combinations of data that an EVP_PKEY is generally assumed to be able to hold: - domain parameters only - public key only - public key + private key - domain parameters + public key - domain parameters + public key + private key To remedy all this, we: 1. let go of the distinction between domain parameters and key material proper in the libcrypto <-> provider interface. As a consequence, functions that still need it gain a selection argument, which is a set of bits that indicate what parts of the key object are to be considered in a specific call. This allows a reduction of very similar functions into one. 2. Rework the libcrypto <-> provider interface so provider side key objects are created and destructed with a separate function, and get their data filled and extracted in through import and export. (future work will see other key object constructors and other functions to fill them with data) Fixes #10979 squash! Redesign the KEYMGMT libcrypto <-> provider interface - the basics Remedy 1 needs a rewrite: Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Shane Lontis <shane.lontis@oracle.com> Reviewed-by: Paul Dale <paul.dale@oracle.com> (Merged from https://github.com/openssl/openssl/pull/11006)
2020-02-03 01:56:07 +08:00
return evp_keymgmt_validate(keymgmt, key,
OSSL_KEYMGMT_SELECT_ALL_PARAMETERS);
Add RSA key validation to default provider Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/10780)
2020-01-29 18:32:32 +08:00
EVP: Clarify the states of an EVP_PKEY EVP_PKEY is rather complex, even before provider side keys entered the stage. You could have untyped / unassigned keys (pk->type == EVP_PKEY_NONE), keys that had been assigned a type but no data (pk->pkey.ptr == NULL), and fully assigned keys (pk->type != EVP_PKEY_NONE && pk->pkey.ptr != NULL). For provider side keys, the corresponding states weren't well defined, and the code didn't quite account for all the possibilities. We also guard most of the legacy fields in EVP_PKEY with FIPS_MODE, so they don't exist at all in the FIPS module. Most of all, code needs to adapt to the case where an EVP_PKEY's |keymgmt| is non-NULL, but its |keydata| is NULL. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/11375)
2020-03-21 13:03:39 +08:00
if (pkey->type == EVP_PKEY_NONE)
goto not_supported;
Rename FIPS_MODE to FIPS_MODULE This macro is used to determine if certain pieces of code should become part of the FIPS module or not. The old name was confusing. Fixes #11538 Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org> (Merged from https://github.com/openssl/openssl/pull/11539)
2020-04-14 04:34:56 +08:00
#ifndef FIPS_MODULE
EVP: Clarify the states of an EVP_PKEY EVP_PKEY is rather complex, even before provider side keys entered the stage. You could have untyped / unassigned keys (pk->type == EVP_PKEY_NONE), keys that had been assigned a type but no data (pk->pkey.ptr == NULL), and fully assigned keys (pk->type != EVP_PKEY_NONE && pk->pkey.ptr != NULL). For provider side keys, the corresponding states weren't well defined, and the code didn't quite account for all the possibilities. We also guard most of the legacy fields in EVP_PKEY with FIPS_MODE, so they don't exist at all in the FIPS module. Most of all, code needs to adapt to the case where an EVP_PKEY's |keymgmt| is non-NULL, but its |keydata| is NULL. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/11375)
2020-03-21 13:03:39 +08:00
/* legacy */
Add RSA key validation to default provider Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/10780)
2020-01-29 18:32:32 +08:00
/* call customized param check function first */
if (ctx->pmeth->param_check != NULL)
return ctx->pmeth->param_check(pkey);
/* use default param check function in ameth */
EVP: Clarify the states of an EVP_PKEY EVP_PKEY is rather complex, even before provider side keys entered the stage. You could have untyped / unassigned keys (pk->type == EVP_PKEY_NONE), keys that had been assigned a type but no data (pk->pkey.ptr == NULL), and fully assigned keys (pk->type != EVP_PKEY_NONE && pk->pkey.ptr != NULL). For provider side keys, the corresponding states weren't well defined, and the code didn't quite account for all the possibilities. We also guard most of the legacy fields in EVP_PKEY with FIPS_MODE, so they don't exist at all in the FIPS module. Most of all, code needs to adapt to the case where an EVP_PKEY's |keymgmt| is non-NULL, but its |keydata| is NULL. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/11375)
2020-03-21 13:03:39 +08:00
if (pkey->ameth == NULL || pkey->ameth->pkey_param_check == NULL)
goto not_supported;
Add RSA key validation to default provider Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/10780)
2020-01-29 18:32:32 +08:00
return pkey->ameth->pkey_param_check(pkey);
EVP: Clarify the states of an EVP_PKEY EVP_PKEY is rather complex, even before provider side keys entered the stage. You could have untyped / unassigned keys (pk->type == EVP_PKEY_NONE), keys that had been assigned a type but no data (pk->pkey.ptr == NULL), and fully assigned keys (pk->type != EVP_PKEY_NONE && pk->pkey.ptr != NULL). For provider side keys, the corresponding states weren't well defined, and the code didn't quite account for all the possibilities. We also guard most of the legacy fields in EVP_PKEY with FIPS_MODE, so they don't exist at all in the FIPS module. Most of all, code needs to adapt to the case where an EVP_PKEY's |keymgmt| is non-NULL, but its |keydata| is NULL. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/11375)
2020-03-21 13:03:39 +08:00
#endif
not_supported:
EVPerr(0, EVP_R_OPERATION_NOT_SUPPORTED_FOR_THIS_KEYTYPE);
return -2;
Add RSA key validation to default provider Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/10780)
2020-01-29 18:32:32 +08:00
}
int EVP_PKEY_private_check(EVP_PKEY_CTX *ctx)
{
EVP_PKEY *pkey = ctx->pkey;
void *key;
EVP_KEYMGMT *keymgmt;
if (pkey == NULL) {
EVPerr(0, EVP_R_NO_KEY_SET);
return 0;
}
Rethink the EVP_PKEY cache of provider side keys The role of this cache was two-fold: 1. It was a cache of key copies exported to providers with which an operation was initiated. 2. If the EVP_PKEY didn't have a legacy key, item 0 of the cache was the corresponding provider side origin, while the rest was the actual cache. This dual role for item 0 made the code a bit confusing, so we now make a separate keymgmt / keydata pair outside of that cache, which is the provider side "origin" key. A hard rule is that an EVP_PKEY cannot hold a legacy "origin" and a provider side "origin" at the same time. Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/11148)
2020-02-21 03:26:16 +08:00
keymgmt = pkey->keymgmt;
key = pkey->keydata;
Add RSA key validation to default provider Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/10780)
2020-01-29 18:32:32 +08:00
if (key != NULL && keymgmt != NULL)
Redesign the KEYMGMT libcrypto <-> provider interface - the basics The KEYMGMT libcrypto <-> provider interface currently makes a few assumptions: 1. provider side domain parameters and key data isn't mutable. In other words, as soon as a key has been created in any (loaded, imported data, ...), it's set in stone. 2. provider side domain parameters can be strictly separated from the key data. This does work for the most part, but there are places where that's a bit too rigid for the functionality that the EVP_PKEY API delivers. Key data needs to be mutable to allow the flexibility that functions like EVP_PKEY_copy_parameters promise, as well as to provide the combinations of data that an EVP_PKEY is generally assumed to be able to hold: - domain parameters only - public key only - public key + private key - domain parameters + public key - domain parameters + public key + private key To remedy all this, we: 1. let go of the distinction between domain parameters and key material proper in the libcrypto <-> provider interface. As a consequence, functions that still need it gain a selection argument, which is a set of bits that indicate what parts of the key object are to be considered in a specific call. This allows a reduction of very similar functions into one. 2. Rework the libcrypto <-> provider interface so provider side key objects are created and destructed with a separate function, and get their data filled and extracted in through import and export. (future work will see other key object constructors and other functions to fill them with data) Fixes #10979 squash! Redesign the KEYMGMT libcrypto <-> provider interface - the basics Remedy 1 needs a rewrite: Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Shane Lontis <shane.lontis@oracle.com> Reviewed-by: Paul Dale <paul.dale@oracle.com> (Merged from https://github.com/openssl/openssl/pull/11006)
2020-02-03 01:56:07 +08:00
return evp_keymgmt_validate(keymgmt, key,
OSSL_KEYMGMT_SELECT_PRIVATE_KEY);
Add RSA key validation to default provider Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/10780)
2020-01-29 18:32:32 +08:00
/* not supported for legacy keys */
EVP: Clarify the states of an EVP_PKEY EVP_PKEY is rather complex, even before provider side keys entered the stage. You could have untyped / unassigned keys (pk->type == EVP_PKEY_NONE), keys that had been assigned a type but no data (pk->pkey.ptr == NULL), and fully assigned keys (pk->type != EVP_PKEY_NONE && pk->pkey.ptr != NULL). For provider side keys, the corresponding states weren't well defined, and the code didn't quite account for all the possibilities. We also guard most of the legacy fields in EVP_PKEY with FIPS_MODE, so they don't exist at all in the FIPS module. Most of all, code needs to adapt to the case where an EVP_PKEY's |keymgmt| is non-NULL, but its |keydata| is NULL. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/11375)
2020-03-21 13:03:39 +08:00
EVPerr(0, EVP_R_OPERATION_NOT_SUPPORTED_FOR_THIS_KEYTYPE);
Add RSA key validation to default provider Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/10780)
2020-01-29 18:32:32 +08:00
return -2;
}
int EVP_PKEY_pairwise_check(EVP_PKEY_CTX *ctx)
{
EVP_PKEY *pkey = ctx->pkey;
void *key;
EVP_KEYMGMT *keymgmt;
if (pkey == NULL) {
EVPerr(0, EVP_R_NO_KEY_SET);
return 0;
}
Rethink the EVP_PKEY cache of provider side keys The role of this cache was two-fold: 1. It was a cache of key copies exported to providers with which an operation was initiated. 2. If the EVP_PKEY didn't have a legacy key, item 0 of the cache was the corresponding provider side origin, while the rest was the actual cache. This dual role for item 0 made the code a bit confusing, so we now make a separate keymgmt / keydata pair outside of that cache, which is the provider side "origin" key. A hard rule is that an EVP_PKEY cannot hold a legacy "origin" and a provider side "origin" at the same time. Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/11148)
2020-02-21 03:26:16 +08:00
keymgmt = pkey->keymgmt;
key = pkey->keydata;
Add RSA key validation to default provider Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/10780)
2020-01-29 18:32:32 +08:00
if (key != NULL && keymgmt != NULL)
Redesign the KEYMGMT libcrypto <-> provider interface - the basics The KEYMGMT libcrypto <-> provider interface currently makes a few assumptions: 1. provider side domain parameters and key data isn't mutable. In other words, as soon as a key has been created in any (loaded, imported data, ...), it's set in stone. 2. provider side domain parameters can be strictly separated from the key data. This does work for the most part, but there are places where that's a bit too rigid for the functionality that the EVP_PKEY API delivers. Key data needs to be mutable to allow the flexibility that functions like EVP_PKEY_copy_parameters promise, as well as to provide the combinations of data that an EVP_PKEY is generally assumed to be able to hold: - domain parameters only - public key only - public key + private key - domain parameters + public key - domain parameters + public key + private key To remedy all this, we: 1. let go of the distinction between domain parameters and key material proper in the libcrypto <-> provider interface. As a consequence, functions that still need it gain a selection argument, which is a set of bits that indicate what parts of the key object are to be considered in a specific call. This allows a reduction of very similar functions into one. 2. Rework the libcrypto <-> provider interface so provider side key objects are created and destructed with a separate function, and get their data filled and extracted in through import and export. (future work will see other key object constructors and other functions to fill them with data) Fixes #10979 squash! Redesign the KEYMGMT libcrypto <-> provider interface - the basics Remedy 1 needs a rewrite: Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Shane Lontis <shane.lontis@oracle.com> Reviewed-by: Paul Dale <paul.dale@oracle.com> (Merged from https://github.com/openssl/openssl/pull/11006)
2020-02-03 01:56:07 +08:00
return evp_keymgmt_validate(keymgmt, key, OSSL_KEYMGMT_SELECT_KEYPAIR);
Add RSA key validation to default provider Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/10780)
2020-01-29 18:32:32 +08:00
/* not supported for legacy keys */
EVP: Clarify the states of an EVP_PKEY EVP_PKEY is rather complex, even before provider side keys entered the stage. You could have untyped / unassigned keys (pk->type == EVP_PKEY_NONE), keys that had been assigned a type but no data (pk->pkey.ptr == NULL), and fully assigned keys (pk->type != EVP_PKEY_NONE && pk->pkey.ptr != NULL). For provider side keys, the corresponding states weren't well defined, and the code didn't quite account for all the possibilities. We also guard most of the legacy fields in EVP_PKEY with FIPS_MODE, so they don't exist at all in the FIPS module. Most of all, code needs to adapt to the case where an EVP_PKEY's |keymgmt| is non-NULL, but its |keydata| is NULL. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/11375)
2020-03-21 13:03:39 +08:00
EVPerr(0, EVP_R_OPERATION_NOT_SUPPORTED_FOR_THIS_KEYTYPE);
Add RSA key validation to default provider Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/10780)
2020-01-29 18:32:32 +08:00
return -2;
}
int EVP_PKEY_check(EVP_PKEY_CTX *ctx)
{
EVP_PKEY *pkey = ctx->pkey;
void *key;
EVP_KEYMGMT *keymgmt;
if (pkey == NULL) {
EVPerr(EVP_F_EVP_PKEY_CHECK, EVP_R_NO_KEY_SET);
return 0;
}
Rethink the EVP_PKEY cache of provider side keys The role of this cache was two-fold: 1. It was a cache of key copies exported to providers with which an operation was initiated. 2. If the EVP_PKEY didn't have a legacy key, item 0 of the cache was the corresponding provider side origin, while the rest was the actual cache. This dual role for item 0 made the code a bit confusing, so we now make a separate keymgmt / keydata pair outside of that cache, which is the provider side "origin" key. A hard rule is that an EVP_PKEY cannot hold a legacy "origin" and a provider side "origin" at the same time. Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/11148)
2020-02-21 03:26:16 +08:00
keymgmt = pkey->keymgmt;
key = pkey->keydata;
Redesign the KEYMGMT libcrypto <-> provider interface - the basics The KEYMGMT libcrypto <-> provider interface currently makes a few assumptions: 1. provider side domain parameters and key data isn't mutable. In other words, as soon as a key has been created in any (loaded, imported data, ...), it's set in stone. 2. provider side domain parameters can be strictly separated from the key data. This does work for the most part, but there are places where that's a bit too rigid for the functionality that the EVP_PKEY API delivers. Key data needs to be mutable to allow the flexibility that functions like EVP_PKEY_copy_parameters promise, as well as to provide the combinations of data that an EVP_PKEY is generally assumed to be able to hold: - domain parameters only - public key only - public key + private key - domain parameters + public key - domain parameters + public key + private key To remedy all this, we: 1. let go of the distinction between domain parameters and key material proper in the libcrypto <-> provider interface. As a consequence, functions that still need it gain a selection argument, which is a set of bits that indicate what parts of the key object are to be considered in a specific call. This allows a reduction of very similar functions into one. 2. Rework the libcrypto <-> provider interface so provider side key objects are created and destructed with a separate function, and get their data filled and extracted in through import and export. (future work will see other key object constructors and other functions to fill them with data) Fixes #10979 squash! Redesign the KEYMGMT libcrypto <-> provider interface - the basics Remedy 1 needs a rewrite: Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Shane Lontis <shane.lontis@oracle.com> Reviewed-by: Paul Dale <paul.dale@oracle.com> (Merged from https://github.com/openssl/openssl/pull/11006)
2020-02-03 01:56:07 +08:00
if (key != NULL && keymgmt != NULL)
return evp_keymgmt_validate(keymgmt, key, OSSL_KEYMGMT_SELECT_ALL);
Add RSA key validation to default provider Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/10780)
2020-01-29 18:32:32 +08:00
EVP: Clarify the states of an EVP_PKEY EVP_PKEY is rather complex, even before provider side keys entered the stage. You could have untyped / unassigned keys (pk->type == EVP_PKEY_NONE), keys that had been assigned a type but no data (pk->pkey.ptr == NULL), and fully assigned keys (pk->type != EVP_PKEY_NONE && pk->pkey.ptr != NULL). For provider side keys, the corresponding states weren't well defined, and the code didn't quite account for all the possibilities. We also guard most of the legacy fields in EVP_PKEY with FIPS_MODE, so they don't exist at all in the FIPS module. Most of all, code needs to adapt to the case where an EVP_PKEY's |keymgmt| is non-NULL, but its |keydata| is NULL. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/11375)
2020-03-21 13:03:39 +08:00
if (pkey->type == EVP_PKEY_NONE)
goto not_supported;
Rename FIPS_MODE to FIPS_MODULE This macro is used to determine if certain pieces of code should become part of the FIPS module or not. The old name was confusing. Fixes #11538 Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org> (Merged from https://github.com/openssl/openssl/pull/11539)
2020-04-14 04:34:56 +08:00
#ifndef FIPS_MODULE
Add RSA key validation to default provider Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/10780)
2020-01-29 18:32:32 +08:00
/* legacy */
/* call customized check function first */
if (ctx->pmeth->check != NULL)
return ctx->pmeth->check(pkey);
/* use default check function in ameth */
EVP: Clarify the states of an EVP_PKEY EVP_PKEY is rather complex, even before provider side keys entered the stage. You could have untyped / unassigned keys (pk->type == EVP_PKEY_NONE), keys that had been assigned a type but no data (pk->pkey.ptr == NULL), and fully assigned keys (pk->type != EVP_PKEY_NONE && pk->pkey.ptr != NULL). For provider side keys, the corresponding states weren't well defined, and the code didn't quite account for all the possibilities. We also guard most of the legacy fields in EVP_PKEY with FIPS_MODE, so they don't exist at all in the FIPS module. Most of all, code needs to adapt to the case where an EVP_PKEY's |keymgmt| is non-NULL, but its |keydata| is NULL. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/11375)
2020-03-21 13:03:39 +08:00
if (pkey->ameth == NULL || pkey->ameth->pkey_check == NULL)
goto not_supported;
Add RSA key validation to default provider Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/10780)
2020-01-29 18:32:32 +08:00
return pkey->ameth->pkey_check(pkey);
EVP: Clarify the states of an EVP_PKEY EVP_PKEY is rather complex, even before provider side keys entered the stage. You could have untyped / unassigned keys (pk->type == EVP_PKEY_NONE), keys that had been assigned a type but no data (pk->pkey.ptr == NULL), and fully assigned keys (pk->type != EVP_PKEY_NONE && pk->pkey.ptr != NULL). For provider side keys, the corresponding states weren't well defined, and the code didn't quite account for all the possibilities. We also guard most of the legacy fields in EVP_PKEY with FIPS_MODE, so they don't exist at all in the FIPS module. Most of all, code needs to adapt to the case where an EVP_PKEY's |keymgmt| is non-NULL, but its |keydata| is NULL. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/11375)
2020-03-21 13:03:39 +08:00
#endif
not_supported:
EVPerr(0, EVP_R_OPERATION_NOT_SUPPORTED_FOR_THIS_KEYTYPE);
return -2;
Add RSA key validation to default provider Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/10780)
2020-01-29 18:32:32 +08:00
}
Reference in New Issue Copy Permalink