2014-06-20 20:00:00 +01:00
|
|
|
/* Written by Dr Stephen N Henson (steve@openssl.org) for the OpenSSL
|
|
|
|
* project 2006.
|
|
|
|
*/
|
|
|
|
/* ====================================================================
|
|
|
|
* Copyright (c) 2006 The OpenSSL Project. All rights reserved.
|
|
|
|
*
|
|
|
|
* Redistribution and use in source and binary forms, with or without
|
|
|
|
* modification, are permitted provided that the following conditions
|
|
|
|
* are met:
|
|
|
|
*
|
|
|
|
* 1. Redistributions of source code must retain the above copyright
|
|
|
|
* notice, this list of conditions and the following disclaimer.
|
|
|
|
*
|
|
|
|
* 2. Redistributions in binary form must reproduce the above copyright
|
|
|
|
* notice, this list of conditions and the following disclaimer in
|
|
|
|
* the documentation and/or other materials provided with the
|
|
|
|
* distribution.
|
|
|
|
*
|
|
|
|
* 3. All advertising materials mentioning features or use of this
|
|
|
|
* software must display the following acknowledgment:
|
|
|
|
* "This product includes software developed by the OpenSSL Project
|
|
|
|
* for use in the OpenSSL Toolkit. (http://www.OpenSSL.org/)"
|
|
|
|
*
|
|
|
|
* 4. The names "OpenSSL Toolkit" and "OpenSSL Project" must not be used to
|
|
|
|
* endorse or promote products derived from this software without
|
|
|
|
* prior written permission. For written permission, please contact
|
|
|
|
* licensing@OpenSSL.org.
|
|
|
|
*
|
|
|
|
* 5. Products derived from this software may not be called "OpenSSL"
|
|
|
|
* nor may "OpenSSL" appear in their names without prior written
|
|
|
|
* permission of the OpenSSL Project.
|
|
|
|
*
|
|
|
|
* 6. Redistributions of any form whatsoever must retain the following
|
|
|
|
* acknowledgment:
|
|
|
|
* "This product includes software developed by the OpenSSL Project
|
|
|
|
* for use in the OpenSSL Toolkit (http://www.OpenSSL.org/)"
|
|
|
|
*
|
|
|
|
* THIS SOFTWARE IS PROVIDED BY THE OpenSSL PROJECT ``AS IS'' AND ANY
|
|
|
|
* EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
|
|
|
|
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
|
|
|
|
* PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE OpenSSL PROJECT OR
|
|
|
|
* ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
|
|
|
|
* SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
|
|
|
|
* NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
|
|
|
|
* LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
|
|
|
|
* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
|
|
|
|
* STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
|
|
|
|
* ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED
|
|
|
|
* OF THE POSSIBILITY OF SUCH DAMAGE.
|
|
|
|
* ====================================================================
|
|
|
|
*
|
|
|
|
* This product includes cryptographic software written by Eric Young
|
|
|
|
* (eay@cryptsoft.com). This product includes software written by Tim
|
|
|
|
* Hudson (tjh@cryptsoft.com). */
|
|
|
|
|
|
|
|
#include <openssl/evp.h>
|
|
|
|
|
|
|
|
#include <openssl/asn1t.h>
|
|
|
|
#include <openssl/bn.h>
|
Implement new SPKI parsers.
Many consumers need SPKI support (X.509, TLS, QUIC, WebCrypto), each
with different ways to set signature parameters. SPKIs themselves can
get complex with id-RSASSA-PSS keys which come with various constraints
in the key parameters. This suggests we want a common in-library
representation of an SPKI.
This adds two new functions EVP_parse_public_key and
EVP_marshal_public_key which converts EVP_PKEY to and from SPKI and
implements X509_PUBKEY functions with them. EVP_PKEY seems to have been
intended to be able to express the supported SPKI types with
full-fidelity, so these APIs will continue this.
This means future support for id-RSASSA-PSS would *not* repurpose
EVP_PKEY_RSA. I'm worried about code assuming EVP_PKEY_RSA implies
acting on the RSA* is legal. Instead, it'd add an EVP_PKEY_RSA_PSS and
the data pointer would be some (exposed, so the caller may still check
key size, etc.) RSA_PSS_KEY struct. Internally, the EVP_PKEY_CTX
implementation would enforce the key constraints. If RSA_PSS_KEY would
later need its own API, that code would move there, but that seems
unlikely.
Ideally we'd have a 1:1 correspondence with key OID, although we may
have to fudge things if mistakes happen in standardization. (Whether or
not X.509 reuses id-ecPublicKey for Ed25519, we'll give it a separate
EVP_PKEY type.)
DSA parsing hooks are still implemented, missing parameters and all for
now. This isn't any worse than before.
Decoupling from the giant crypto/obj OID table will be a later task.
BUG=522228
Change-Id: I0e3964edf20cb795a18b0991d17e5ca8bce3e28c
Reviewed-on: https://boringssl-review.googlesource.com/6861
Reviewed-by: Adam Langley <agl@google.com>
2015-12-31 02:40:40 +00:00
|
|
|
#include <openssl/bytestring.h>
|
2014-06-20 20:00:00 +01:00
|
|
|
#include <openssl/ec.h>
|
|
|
|
#include <openssl/err.h>
|
|
|
|
#include <openssl/mem.h>
|
|
|
|
#include <openssl/obj.h>
|
|
|
|
#include <openssl/x509.h>
|
|
|
|
|
|
|
|
#include "internal.h"
|
|
|
|
|
|
|
|
|
|
|
|
static int eckey_param2type(int *pptype, void **ppval, EC_KEY *ec_key) {
|
|
|
|
const EC_GROUP *group;
|
|
|
|
int nid;
|
|
|
|
|
|
|
|
if (ec_key == NULL || (group = EC_KEY_get0_group(ec_key)) == NULL) {
|
2015-06-29 05:28:17 +01:00
|
|
|
OPENSSL_PUT_ERROR(EVP, EVP_R_MISSING_PARAMETERS);
|
2014-06-20 20:00:00 +01:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
nid = EC_GROUP_get_curve_name(group);
|
|
|
|
if (nid == NID_undef) {
|
2015-06-29 05:28:17 +01:00
|
|
|
OPENSSL_PUT_ERROR(EVP, EVP_R_NO_NID_FOR_CURVE);
|
2014-06-20 20:00:00 +01:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
*ppval = (void*) OBJ_nid2obj(nid);
|
|
|
|
*pptype = V_ASN1_OBJECT;
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
Implement new SPKI parsers.
Many consumers need SPKI support (X.509, TLS, QUIC, WebCrypto), each
with different ways to set signature parameters. SPKIs themselves can
get complex with id-RSASSA-PSS keys which come with various constraints
in the key parameters. This suggests we want a common in-library
representation of an SPKI.
This adds two new functions EVP_parse_public_key and
EVP_marshal_public_key which converts EVP_PKEY to and from SPKI and
implements X509_PUBKEY functions with them. EVP_PKEY seems to have been
intended to be able to express the supported SPKI types with
full-fidelity, so these APIs will continue this.
This means future support for id-RSASSA-PSS would *not* repurpose
EVP_PKEY_RSA. I'm worried about code assuming EVP_PKEY_RSA implies
acting on the RSA* is legal. Instead, it'd add an EVP_PKEY_RSA_PSS and
the data pointer would be some (exposed, so the caller may still check
key size, etc.) RSA_PSS_KEY struct. Internally, the EVP_PKEY_CTX
implementation would enforce the key constraints. If RSA_PSS_KEY would
later need its own API, that code would move there, but that seems
unlikely.
Ideally we'd have a 1:1 correspondence with key OID, although we may
have to fudge things if mistakes happen in standardization. (Whether or
not X.509 reuses id-ecPublicKey for Ed25519, we'll give it a separate
EVP_PKEY type.)
DSA parsing hooks are still implemented, missing parameters and all for
now. This isn't any worse than before.
Decoupling from the giant crypto/obj OID table will be a later task.
BUG=522228
Change-Id: I0e3964edf20cb795a18b0991d17e5ca8bce3e28c
Reviewed-on: https://boringssl-review.googlesource.com/6861
Reviewed-by: Adam Langley <agl@google.com>
2015-12-31 02:40:40 +00:00
|
|
|
static int eckey_pub_encode(CBB *out, const EVP_PKEY *key) {
|
|
|
|
const EC_KEY *ec_key = key->pkey.ec;
|
|
|
|
const EC_GROUP *group = EC_KEY_get0_group(ec_key);
|
|
|
|
int curve_nid = EC_GROUP_get_curve_name(group);
|
|
|
|
if (curve_nid == NID_undef) {
|
|
|
|
OPENSSL_PUT_ERROR(EVP, EVP_R_NO_NID_FOR_CURVE);
|
2014-06-20 20:00:00 +01:00
|
|
|
return 0;
|
|
|
|
}
|
Implement new SPKI parsers.
Many consumers need SPKI support (X.509, TLS, QUIC, WebCrypto), each
with different ways to set signature parameters. SPKIs themselves can
get complex with id-RSASSA-PSS keys which come with various constraints
in the key parameters. This suggests we want a common in-library
representation of an SPKI.
This adds two new functions EVP_parse_public_key and
EVP_marshal_public_key which converts EVP_PKEY to and from SPKI and
implements X509_PUBKEY functions with them. EVP_PKEY seems to have been
intended to be able to express the supported SPKI types with
full-fidelity, so these APIs will continue this.
This means future support for id-RSASSA-PSS would *not* repurpose
EVP_PKEY_RSA. I'm worried about code assuming EVP_PKEY_RSA implies
acting on the RSA* is legal. Instead, it'd add an EVP_PKEY_RSA_PSS and
the data pointer would be some (exposed, so the caller may still check
key size, etc.) RSA_PSS_KEY struct. Internally, the EVP_PKEY_CTX
implementation would enforce the key constraints. If RSA_PSS_KEY would
later need its own API, that code would move there, but that seems
unlikely.
Ideally we'd have a 1:1 correspondence with key OID, although we may
have to fudge things if mistakes happen in standardization. (Whether or
not X.509 reuses id-ecPublicKey for Ed25519, we'll give it a separate
EVP_PKEY type.)
DSA parsing hooks are still implemented, missing parameters and all for
now. This isn't any worse than before.
Decoupling from the giant crypto/obj OID table will be a later task.
BUG=522228
Change-Id: I0e3964edf20cb795a18b0991d17e5ca8bce3e28c
Reviewed-on: https://boringssl-review.googlesource.com/6861
Reviewed-by: Adam Langley <agl@google.com>
2015-12-31 02:40:40 +00:00
|
|
|
const EC_POINT *public_key = EC_KEY_get0_public_key(ec_key);
|
|
|
|
|
|
|
|
/* See RFC 5480, section 2. */
|
|
|
|
CBB spki, algorithm, key_bitstring;
|
|
|
|
if (!CBB_add_asn1(out, &spki, CBS_ASN1_SEQUENCE) ||
|
|
|
|
!CBB_add_asn1(&spki, &algorithm, CBS_ASN1_SEQUENCE) ||
|
|
|
|
!OBJ_nid2cbb(&algorithm, NID_X9_62_id_ecPublicKey) ||
|
|
|
|
!OBJ_nid2cbb(&algorithm, curve_nid) ||
|
|
|
|
!CBB_add_asn1(&spki, &key_bitstring, CBS_ASN1_BITSTRING) ||
|
|
|
|
!CBB_add_u8(&key_bitstring, 0 /* padding */) ||
|
|
|
|
!EC_POINT_point2cbb(&key_bitstring, group, public_key,
|
|
|
|
POINT_CONVERSION_UNCOMPRESSED, NULL) ||
|
|
|
|
!CBB_flush(out)) {
|
|
|
|
OPENSSL_PUT_ERROR(EVP, EVP_R_ENCODE_ERROR);
|
|
|
|
return 0;
|
2014-06-20 20:00:00 +01:00
|
|
|
}
|
|
|
|
|
Implement new SPKI parsers.
Many consumers need SPKI support (X.509, TLS, QUIC, WebCrypto), each
with different ways to set signature parameters. SPKIs themselves can
get complex with id-RSASSA-PSS keys which come with various constraints
in the key parameters. This suggests we want a common in-library
representation of an SPKI.
This adds two new functions EVP_parse_public_key and
EVP_marshal_public_key which converts EVP_PKEY to and from SPKI and
implements X509_PUBKEY functions with them. EVP_PKEY seems to have been
intended to be able to express the supported SPKI types with
full-fidelity, so these APIs will continue this.
This means future support for id-RSASSA-PSS would *not* repurpose
EVP_PKEY_RSA. I'm worried about code assuming EVP_PKEY_RSA implies
acting on the RSA* is legal. Instead, it'd add an EVP_PKEY_RSA_PSS and
the data pointer would be some (exposed, so the caller may still check
key size, etc.) RSA_PSS_KEY struct. Internally, the EVP_PKEY_CTX
implementation would enforce the key constraints. If RSA_PSS_KEY would
later need its own API, that code would move there, but that seems
unlikely.
Ideally we'd have a 1:1 correspondence with key OID, although we may
have to fudge things if mistakes happen in standardization. (Whether or
not X.509 reuses id-ecPublicKey for Ed25519, we'll give it a separate
EVP_PKEY type.)
DSA parsing hooks are still implemented, missing parameters and all for
now. This isn't any worse than before.
Decoupling from the giant crypto/obj OID table will be a later task.
BUG=522228
Change-Id: I0e3964edf20cb795a18b0991d17e5ca8bce3e28c
Reviewed-on: https://boringssl-review.googlesource.com/6861
Reviewed-by: Adam Langley <agl@google.com>
2015-12-31 02:40:40 +00:00
|
|
|
return 1;
|
2014-06-20 20:00:00 +01:00
|
|
|
}
|
|
|
|
|
Implement new SPKI parsers.
Many consumers need SPKI support (X.509, TLS, QUIC, WebCrypto), each
with different ways to set signature parameters. SPKIs themselves can
get complex with id-RSASSA-PSS keys which come with various constraints
in the key parameters. This suggests we want a common in-library
representation of an SPKI.
This adds two new functions EVP_parse_public_key and
EVP_marshal_public_key which converts EVP_PKEY to and from SPKI and
implements X509_PUBKEY functions with them. EVP_PKEY seems to have been
intended to be able to express the supported SPKI types with
full-fidelity, so these APIs will continue this.
This means future support for id-RSASSA-PSS would *not* repurpose
EVP_PKEY_RSA. I'm worried about code assuming EVP_PKEY_RSA implies
acting on the RSA* is legal. Instead, it'd add an EVP_PKEY_RSA_PSS and
the data pointer would be some (exposed, so the caller may still check
key size, etc.) RSA_PSS_KEY struct. Internally, the EVP_PKEY_CTX
implementation would enforce the key constraints. If RSA_PSS_KEY would
later need its own API, that code would move there, but that seems
unlikely.
Ideally we'd have a 1:1 correspondence with key OID, although we may
have to fudge things if mistakes happen in standardization. (Whether or
not X.509 reuses id-ecPublicKey for Ed25519, we'll give it a separate
EVP_PKEY type.)
DSA parsing hooks are still implemented, missing parameters and all for
now. This isn't any worse than before.
Decoupling from the giant crypto/obj OID table will be a later task.
BUG=522228
Change-Id: I0e3964edf20cb795a18b0991d17e5ca8bce3e28c
Reviewed-on: https://boringssl-review.googlesource.com/6861
Reviewed-by: Adam Langley <agl@google.com>
2015-12-31 02:40:40 +00:00
|
|
|
static int eckey_pub_decode(EVP_PKEY *out, CBS *params, CBS *key) {
|
|
|
|
/* See RFC 5480, section 2. */
|
2014-06-20 20:00:00 +01:00
|
|
|
|
Implement new SPKI parsers.
Many consumers need SPKI support (X.509, TLS, QUIC, WebCrypto), each
with different ways to set signature parameters. SPKIs themselves can
get complex with id-RSASSA-PSS keys which come with various constraints
in the key parameters. This suggests we want a common in-library
representation of an SPKI.
This adds two new functions EVP_parse_public_key and
EVP_marshal_public_key which converts EVP_PKEY to and from SPKI and
implements X509_PUBKEY functions with them. EVP_PKEY seems to have been
intended to be able to express the supported SPKI types with
full-fidelity, so these APIs will continue this.
This means future support for id-RSASSA-PSS would *not* repurpose
EVP_PKEY_RSA. I'm worried about code assuming EVP_PKEY_RSA implies
acting on the RSA* is legal. Instead, it'd add an EVP_PKEY_RSA_PSS and
the data pointer would be some (exposed, so the caller may still check
key size, etc.) RSA_PSS_KEY struct. Internally, the EVP_PKEY_CTX
implementation would enforce the key constraints. If RSA_PSS_KEY would
later need its own API, that code would move there, but that seems
unlikely.
Ideally we'd have a 1:1 correspondence with key OID, although we may
have to fudge things if mistakes happen in standardization. (Whether or
not X.509 reuses id-ecPublicKey for Ed25519, we'll give it a separate
EVP_PKEY type.)
DSA parsing hooks are still implemented, missing parameters and all for
now. This isn't any worse than before.
Decoupling from the giant crypto/obj OID table will be a later task.
BUG=522228
Change-Id: I0e3964edf20cb795a18b0991d17e5ca8bce3e28c
Reviewed-on: https://boringssl-review.googlesource.com/6861
Reviewed-by: Adam Langley <agl@google.com>
2015-12-31 02:40:40 +00:00
|
|
|
/* The parameters are a named curve. */
|
|
|
|
CBS named_curve;
|
|
|
|
if (!CBS_get_asn1(params, &named_curve, CBS_ASN1_OBJECT) ||
|
|
|
|
CBS_len(params) != 0) {
|
Don't allow the specifiedCurve form of ECParameters in SPKIs.
Although RFC 3279 allows both, per RFC 5912, keys must use a named curve
rather than spelling out the curve parameters. Although we do not allow
arbitrary curves, we do have to (pretty hackishly) recognize built-in
curves in ECPrivateKeys.
It seems the cause of this was that OpenSSL, unless you set asn1_flag on
the EC_GROUP, likes to encode keys by spelling out the parameters. This
is in violation of RFC 5915, though probably not in violation of one of
the other redundant ECC specifications. For more fun, it appears
asn1_flag defaults to *off* in the API and *on* in the command-line
tools.
I think the original cause was these defaults meant the pre-BoringSSL
Android/OpenSSL Chromium port wrote out Channel ID keys in this format.
By now this should no longer by an issue, but it'll warrant a bit more
investigation to be sure we can drop it.
For now, keep this logic out of SPKIs by not calling d2i_ECParameters.
d2i_ECParameters is a fairly pointless function when only named curves
are allowed. In testing other implementations, none of Firefox, Safari,
or IE11/Win will parse such certificates (i.e. the error is fatal and
unbypassable). Likewise, because Mac and Windows' underlying libraries
reject this, Chrome on Mac and Windows already rejects such things. Thus
this change should be compatible.
The following is the certificate and key I constructed to test with:
-----BEGIN CERTIFICATE-----
MIICwjCCAmqgAwIBAgIJANlMBNpJfb/rMAkGByqGSM49BAEwRTELMAkGA1UEBhMC
QVUxEzARBgNVBAgMClNvbWUtU3RhdGUxITAfBgNVBAoMGEludGVybmV0IFdpZGdp
dHMgUHR5IEx0ZDAeFw0xNDA0MjMyMzIxNTdaFw0xNDA1MjMyMzIxNTdaMEUxCzAJ
BgNVBAYTAkFVMRMwEQYDVQQIDApTb21lLVN0YXRlMSEwHwYDVQQKDBhJbnRlcm5l
dCBXaWRnaXRzIFB0eSBMdGQwggFLMIIBAwYHKoZIzj0CATCB9wIBATAsBgcqhkjO
PQEBAiEA/////wAAAAEAAAAAAAAAAAAAAAD///////////////8wWwQg/////wAA
AAEAAAAAAAAAAAAAAAD///////////////wEIFrGNdiqOpPns+u9VXaYhrxlHQaw
zFOw9jvOPD4n0mBLAxUAxJ02CIbnBJNqZnjhE50mt4GffpAEQQRrF9Hy4SxCR/i8
5uVjpEDydwN9gS3rM6D0oTlF2JjClk/jQuL+Gn+bjufrSnwPnhYrzjNXazFezsu2
QGg3v1H1AiEA/////wAAAAD//////////7zm+q2nF56E87nKwvxjJVECAQEDQgAE
5itp4r9ln5e+Lx4NlIpM1Zdrt6keDUb73ampHp3culoB59aXqAoY+cPEox5W4nyD
SNsWGhz1HX7xlC1Lz3IiwaNQME4wHQYDVR0OBBYEFKuE0qyrlfCCThZ4B1VXX+Qm
jYLRMB8GA1UdIwQYMBaAFKuE0qyrlfCCThZ4B1VXX+QmjYLRMAwGA1UdEwQFMAMB
Af8wCQYHKoZIzj0EAQNHADBEAiBATB6aVJxDD6YAxEM4vf6Sbg2Ty334ldXpkNwc
TF+SngIgZ/f59kgDLf6YA04iLw1fUv5Wf1nLYJWwgrRFON5+zvw=
-----END CERTIFICATE-----
-----BEGIN EC PARAMETERS-----
MIH3AgEBMCwGByqGSM49AQECIQD/////AAAAAQAAAAAAAAAAAAAAAP//////////
/////zBbBCD/////AAAAAQAAAAAAAAAAAAAAAP///////////////AQgWsY12Ko6
k+ez671VdpiGvGUdBrDMU7D2O848PifSYEsDFQDEnTYIhucEk2pmeOETnSa3gZ9+
kARBBGsX0fLhLEJH+Lzm5WOkQPJ3A32BLeszoPShOUXYmMKWT+NC4v4af5uO5+tK
fA+eFivOM1drMV7Oy7ZAaDe/UfUCIQD/////AAAAAP//////////vOb6racXnoTz
ucrC/GMlUQIBAQ==
-----END EC PARAMETERS-----
-----BEGIN EC PRIVATE KEY-----
MHcCAQEEIAcPCHJ61KBKnN1ZyU2JaHcItW/JXTB3DujRyc4Ki7RqoAoGCCqGSM49
AwEHoUQDQgAE5itp4r9ln5e+Lx4NlIpM1Zdrt6keDUb73ampHp3culoB59aXqAoY
+cPEox5W4nyDSNsWGhz1HX7xlC1Lz3IiwQ==
-----END EC PRIVATE KEY-----
BUG=522228
Change-Id: I3723411a633dc07c4640027de07500293f8f7913
Reviewed-on: https://boringssl-review.googlesource.com/6853
Reviewed-by: Adam Langley <alangley@gmail.com>
2015-12-25 00:38:03 +00:00
|
|
|
OPENSSL_PUT_ERROR(EVP, EVP_R_DECODE_ERROR);
|
|
|
|
return 0;
|
|
|
|
}
|
Implement new SPKI parsers.
Many consumers need SPKI support (X.509, TLS, QUIC, WebCrypto), each
with different ways to set signature parameters. SPKIs themselves can
get complex with id-RSASSA-PSS keys which come with various constraints
in the key parameters. This suggests we want a common in-library
representation of an SPKI.
This adds two new functions EVP_parse_public_key and
EVP_marshal_public_key which converts EVP_PKEY to and from SPKI and
implements X509_PUBKEY functions with them. EVP_PKEY seems to have been
intended to be able to express the supported SPKI types with
full-fidelity, so these APIs will continue this.
This means future support for id-RSASSA-PSS would *not* repurpose
EVP_PKEY_RSA. I'm worried about code assuming EVP_PKEY_RSA implies
acting on the RSA* is legal. Instead, it'd add an EVP_PKEY_RSA_PSS and
the data pointer would be some (exposed, so the caller may still check
key size, etc.) RSA_PSS_KEY struct. Internally, the EVP_PKEY_CTX
implementation would enforce the key constraints. If RSA_PSS_KEY would
later need its own API, that code would move there, but that seems
unlikely.
Ideally we'd have a 1:1 correspondence with key OID, although we may
have to fudge things if mistakes happen in standardization. (Whether or
not X.509 reuses id-ecPublicKey for Ed25519, we'll give it a separate
EVP_PKEY type.)
DSA parsing hooks are still implemented, missing parameters and all for
now. This isn't any worse than before.
Decoupling from the giant crypto/obj OID table will be a later task.
BUG=522228
Change-Id: I0e3964edf20cb795a18b0991d17e5ca8bce3e28c
Reviewed-on: https://boringssl-review.googlesource.com/6861
Reviewed-by: Adam Langley <agl@google.com>
2015-12-31 02:40:40 +00:00
|
|
|
|
|
|
|
EC_KEY *eckey = EC_KEY_new_by_curve_name(OBJ_cbs2nid(&named_curve));
|
Don't allow the specifiedCurve form of ECParameters in SPKIs.
Although RFC 3279 allows both, per RFC 5912, keys must use a named curve
rather than spelling out the curve parameters. Although we do not allow
arbitrary curves, we do have to (pretty hackishly) recognize built-in
curves in ECPrivateKeys.
It seems the cause of this was that OpenSSL, unless you set asn1_flag on
the EC_GROUP, likes to encode keys by spelling out the parameters. This
is in violation of RFC 5915, though probably not in violation of one of
the other redundant ECC specifications. For more fun, it appears
asn1_flag defaults to *off* in the API and *on* in the command-line
tools.
I think the original cause was these defaults meant the pre-BoringSSL
Android/OpenSSL Chromium port wrote out Channel ID keys in this format.
By now this should no longer by an issue, but it'll warrant a bit more
investigation to be sure we can drop it.
For now, keep this logic out of SPKIs by not calling d2i_ECParameters.
d2i_ECParameters is a fairly pointless function when only named curves
are allowed. In testing other implementations, none of Firefox, Safari,
or IE11/Win will parse such certificates (i.e. the error is fatal and
unbypassable). Likewise, because Mac and Windows' underlying libraries
reject this, Chrome on Mac and Windows already rejects such things. Thus
this change should be compatible.
The following is the certificate and key I constructed to test with:
-----BEGIN CERTIFICATE-----
MIICwjCCAmqgAwIBAgIJANlMBNpJfb/rMAkGByqGSM49BAEwRTELMAkGA1UEBhMC
QVUxEzARBgNVBAgMClNvbWUtU3RhdGUxITAfBgNVBAoMGEludGVybmV0IFdpZGdp
dHMgUHR5IEx0ZDAeFw0xNDA0MjMyMzIxNTdaFw0xNDA1MjMyMzIxNTdaMEUxCzAJ
BgNVBAYTAkFVMRMwEQYDVQQIDApTb21lLVN0YXRlMSEwHwYDVQQKDBhJbnRlcm5l
dCBXaWRnaXRzIFB0eSBMdGQwggFLMIIBAwYHKoZIzj0CATCB9wIBATAsBgcqhkjO
PQEBAiEA/////wAAAAEAAAAAAAAAAAAAAAD///////////////8wWwQg/////wAA
AAEAAAAAAAAAAAAAAAD///////////////wEIFrGNdiqOpPns+u9VXaYhrxlHQaw
zFOw9jvOPD4n0mBLAxUAxJ02CIbnBJNqZnjhE50mt4GffpAEQQRrF9Hy4SxCR/i8
5uVjpEDydwN9gS3rM6D0oTlF2JjClk/jQuL+Gn+bjufrSnwPnhYrzjNXazFezsu2
QGg3v1H1AiEA/////wAAAAD//////////7zm+q2nF56E87nKwvxjJVECAQEDQgAE
5itp4r9ln5e+Lx4NlIpM1Zdrt6keDUb73ampHp3culoB59aXqAoY+cPEox5W4nyD
SNsWGhz1HX7xlC1Lz3IiwaNQME4wHQYDVR0OBBYEFKuE0qyrlfCCThZ4B1VXX+Qm
jYLRMB8GA1UdIwQYMBaAFKuE0qyrlfCCThZ4B1VXX+QmjYLRMAwGA1UdEwQFMAMB
Af8wCQYHKoZIzj0EAQNHADBEAiBATB6aVJxDD6YAxEM4vf6Sbg2Ty334ldXpkNwc
TF+SngIgZ/f59kgDLf6YA04iLw1fUv5Wf1nLYJWwgrRFON5+zvw=
-----END CERTIFICATE-----
-----BEGIN EC PARAMETERS-----
MIH3AgEBMCwGByqGSM49AQECIQD/////AAAAAQAAAAAAAAAAAAAAAP//////////
/////zBbBCD/////AAAAAQAAAAAAAAAAAAAAAP///////////////AQgWsY12Ko6
k+ez671VdpiGvGUdBrDMU7D2O848PifSYEsDFQDEnTYIhucEk2pmeOETnSa3gZ9+
kARBBGsX0fLhLEJH+Lzm5WOkQPJ3A32BLeszoPShOUXYmMKWT+NC4v4af5uO5+tK
fA+eFivOM1drMV7Oy7ZAaDe/UfUCIQD/////AAAAAP//////////vOb6racXnoTz
ucrC/GMlUQIBAQ==
-----END EC PARAMETERS-----
-----BEGIN EC PRIVATE KEY-----
MHcCAQEEIAcPCHJ61KBKnN1ZyU2JaHcItW/JXTB3DujRyc4Ki7RqoAoGCCqGSM49
AwEHoUQDQgAE5itp4r9ln5e+Lx4NlIpM1Zdrt6keDUb73ampHp3culoB59aXqAoY
+cPEox5W4nyDSNsWGhz1HX7xlC1Lz3IiwQ==
-----END EC PRIVATE KEY-----
BUG=522228
Change-Id: I3723411a633dc07c4640027de07500293f8f7913
Reviewed-on: https://boringssl-review.googlesource.com/6853
Reviewed-by: Adam Langley <alangley@gmail.com>
2015-12-25 00:38:03 +00:00
|
|
|
if (eckey == NULL) {
|
2014-06-20 20:00:00 +01:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
Implement new SPKI parsers.
Many consumers need SPKI support (X.509, TLS, QUIC, WebCrypto), each
with different ways to set signature parameters. SPKIs themselves can
get complex with id-RSASSA-PSS keys which come with various constraints
in the key parameters. This suggests we want a common in-library
representation of an SPKI.
This adds two new functions EVP_parse_public_key and
EVP_marshal_public_key which converts EVP_PKEY to and from SPKI and
implements X509_PUBKEY functions with them. EVP_PKEY seems to have been
intended to be able to express the supported SPKI types with
full-fidelity, so these APIs will continue this.
This means future support for id-RSASSA-PSS would *not* repurpose
EVP_PKEY_RSA. I'm worried about code assuming EVP_PKEY_RSA implies
acting on the RSA* is legal. Instead, it'd add an EVP_PKEY_RSA_PSS and
the data pointer would be some (exposed, so the caller may still check
key size, etc.) RSA_PSS_KEY struct. Internally, the EVP_PKEY_CTX
implementation would enforce the key constraints. If RSA_PSS_KEY would
later need its own API, that code would move there, but that seems
unlikely.
Ideally we'd have a 1:1 correspondence with key OID, although we may
have to fudge things if mistakes happen in standardization. (Whether or
not X.509 reuses id-ecPublicKey for Ed25519, we'll give it a separate
EVP_PKEY type.)
DSA parsing hooks are still implemented, missing parameters and all for
now. This isn't any worse than before.
Decoupling from the giant crypto/obj OID table will be a later task.
BUG=522228
Change-Id: I0e3964edf20cb795a18b0991d17e5ca8bce3e28c
Reviewed-on: https://boringssl-review.googlesource.com/6861
Reviewed-by: Adam Langley <agl@google.com>
2015-12-31 02:40:40 +00:00
|
|
|
EC_POINT *point = EC_POINT_new(EC_KEY_get0_group(eckey));
|
|
|
|
if (point == NULL ||
|
|
|
|
!EC_POINT_oct2point(EC_KEY_get0_group(eckey), point, CBS_data(key),
|
|
|
|
CBS_len(key), NULL) ||
|
|
|
|
!EC_KEY_set_public_key(eckey, point)) {
|
2014-06-20 20:00:00 +01:00
|
|
|
goto err;
|
|
|
|
}
|
|
|
|
|
Implement new SPKI parsers.
Many consumers need SPKI support (X.509, TLS, QUIC, WebCrypto), each
with different ways to set signature parameters. SPKIs themselves can
get complex with id-RSASSA-PSS keys which come with various constraints
in the key parameters. This suggests we want a common in-library
representation of an SPKI.
This adds two new functions EVP_parse_public_key and
EVP_marshal_public_key which converts EVP_PKEY to and from SPKI and
implements X509_PUBKEY functions with them. EVP_PKEY seems to have been
intended to be able to express the supported SPKI types with
full-fidelity, so these APIs will continue this.
This means future support for id-RSASSA-PSS would *not* repurpose
EVP_PKEY_RSA. I'm worried about code assuming EVP_PKEY_RSA implies
acting on the RSA* is legal. Instead, it'd add an EVP_PKEY_RSA_PSS and
the data pointer would be some (exposed, so the caller may still check
key size, etc.) RSA_PSS_KEY struct. Internally, the EVP_PKEY_CTX
implementation would enforce the key constraints. If RSA_PSS_KEY would
later need its own API, that code would move there, but that seems
unlikely.
Ideally we'd have a 1:1 correspondence with key OID, although we may
have to fudge things if mistakes happen in standardization. (Whether or
not X.509 reuses id-ecPublicKey for Ed25519, we'll give it a separate
EVP_PKEY type.)
DSA parsing hooks are still implemented, missing parameters and all for
now. This isn't any worse than before.
Decoupling from the giant crypto/obj OID table will be a later task.
BUG=522228
Change-Id: I0e3964edf20cb795a18b0991d17e5ca8bce3e28c
Reviewed-on: https://boringssl-review.googlesource.com/6861
Reviewed-by: Adam Langley <agl@google.com>
2015-12-31 02:40:40 +00:00
|
|
|
EC_POINT_free(point);
|
|
|
|
EVP_PKEY_assign_EC_KEY(out, eckey);
|
2014-06-20 20:00:00 +01:00
|
|
|
return 1;
|
|
|
|
|
|
|
|
err:
|
Implement new SPKI parsers.
Many consumers need SPKI support (X.509, TLS, QUIC, WebCrypto), each
with different ways to set signature parameters. SPKIs themselves can
get complex with id-RSASSA-PSS keys which come with various constraints
in the key parameters. This suggests we want a common in-library
representation of an SPKI.
This adds two new functions EVP_parse_public_key and
EVP_marshal_public_key which converts EVP_PKEY to and from SPKI and
implements X509_PUBKEY functions with them. EVP_PKEY seems to have been
intended to be able to express the supported SPKI types with
full-fidelity, so these APIs will continue this.
This means future support for id-RSASSA-PSS would *not* repurpose
EVP_PKEY_RSA. I'm worried about code assuming EVP_PKEY_RSA implies
acting on the RSA* is legal. Instead, it'd add an EVP_PKEY_RSA_PSS and
the data pointer would be some (exposed, so the caller may still check
key size, etc.) RSA_PSS_KEY struct. Internally, the EVP_PKEY_CTX
implementation would enforce the key constraints. If RSA_PSS_KEY would
later need its own API, that code would move there, but that seems
unlikely.
Ideally we'd have a 1:1 correspondence with key OID, although we may
have to fudge things if mistakes happen in standardization. (Whether or
not X.509 reuses id-ecPublicKey for Ed25519, we'll give it a separate
EVP_PKEY type.)
DSA parsing hooks are still implemented, missing parameters and all for
now. This isn't any worse than before.
Decoupling from the giant crypto/obj OID table will be a later task.
BUG=522228
Change-Id: I0e3964edf20cb795a18b0991d17e5ca8bce3e28c
Reviewed-on: https://boringssl-review.googlesource.com/6861
Reviewed-by: Adam Langley <agl@google.com>
2015-12-31 02:40:40 +00:00
|
|
|
EC_POINT_free(point);
|
|
|
|
EC_KEY_free(eckey);
|
2014-06-20 20:00:00 +01:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int eckey_pub_cmp(const EVP_PKEY *a, const EVP_PKEY *b) {
|
|
|
|
int r;
|
|
|
|
const EC_GROUP *group = EC_KEY_get0_group(b->pkey.ec);
|
|
|
|
const EC_POINT *pa = EC_KEY_get0_public_key(a->pkey.ec),
|
|
|
|
*pb = EC_KEY_get0_public_key(b->pkey.ec);
|
|
|
|
r = EC_POINT_cmp(group, pa, pb, NULL);
|
|
|
|
if (r == 0) {
|
|
|
|
return 1;
|
|
|
|
} else if (r == 1) {
|
|
|
|
return 0;
|
|
|
|
} else {
|
|
|
|
return -2;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
Don't allow the specifiedCurve form of ECParameters in SPKIs.
Although RFC 3279 allows both, per RFC 5912, keys must use a named curve
rather than spelling out the curve parameters. Although we do not allow
arbitrary curves, we do have to (pretty hackishly) recognize built-in
curves in ECPrivateKeys.
It seems the cause of this was that OpenSSL, unless you set asn1_flag on
the EC_GROUP, likes to encode keys by spelling out the parameters. This
is in violation of RFC 5915, though probably not in violation of one of
the other redundant ECC specifications. For more fun, it appears
asn1_flag defaults to *off* in the API and *on* in the command-line
tools.
I think the original cause was these defaults meant the pre-BoringSSL
Android/OpenSSL Chromium port wrote out Channel ID keys in this format.
By now this should no longer by an issue, but it'll warrant a bit more
investigation to be sure we can drop it.
For now, keep this logic out of SPKIs by not calling d2i_ECParameters.
d2i_ECParameters is a fairly pointless function when only named curves
are allowed. In testing other implementations, none of Firefox, Safari,
or IE11/Win will parse such certificates (i.e. the error is fatal and
unbypassable). Likewise, because Mac and Windows' underlying libraries
reject this, Chrome on Mac and Windows already rejects such things. Thus
this change should be compatible.
The following is the certificate and key I constructed to test with:
-----BEGIN CERTIFICATE-----
MIICwjCCAmqgAwIBAgIJANlMBNpJfb/rMAkGByqGSM49BAEwRTELMAkGA1UEBhMC
QVUxEzARBgNVBAgMClNvbWUtU3RhdGUxITAfBgNVBAoMGEludGVybmV0IFdpZGdp
dHMgUHR5IEx0ZDAeFw0xNDA0MjMyMzIxNTdaFw0xNDA1MjMyMzIxNTdaMEUxCzAJ
BgNVBAYTAkFVMRMwEQYDVQQIDApTb21lLVN0YXRlMSEwHwYDVQQKDBhJbnRlcm5l
dCBXaWRnaXRzIFB0eSBMdGQwggFLMIIBAwYHKoZIzj0CATCB9wIBATAsBgcqhkjO
PQEBAiEA/////wAAAAEAAAAAAAAAAAAAAAD///////////////8wWwQg/////wAA
AAEAAAAAAAAAAAAAAAD///////////////wEIFrGNdiqOpPns+u9VXaYhrxlHQaw
zFOw9jvOPD4n0mBLAxUAxJ02CIbnBJNqZnjhE50mt4GffpAEQQRrF9Hy4SxCR/i8
5uVjpEDydwN9gS3rM6D0oTlF2JjClk/jQuL+Gn+bjufrSnwPnhYrzjNXazFezsu2
QGg3v1H1AiEA/////wAAAAD//////////7zm+q2nF56E87nKwvxjJVECAQEDQgAE
5itp4r9ln5e+Lx4NlIpM1Zdrt6keDUb73ampHp3culoB59aXqAoY+cPEox5W4nyD
SNsWGhz1HX7xlC1Lz3IiwaNQME4wHQYDVR0OBBYEFKuE0qyrlfCCThZ4B1VXX+Qm
jYLRMB8GA1UdIwQYMBaAFKuE0qyrlfCCThZ4B1VXX+QmjYLRMAwGA1UdEwQFMAMB
Af8wCQYHKoZIzj0EAQNHADBEAiBATB6aVJxDD6YAxEM4vf6Sbg2Ty334ldXpkNwc
TF+SngIgZ/f59kgDLf6YA04iLw1fUv5Wf1nLYJWwgrRFON5+zvw=
-----END CERTIFICATE-----
-----BEGIN EC PARAMETERS-----
MIH3AgEBMCwGByqGSM49AQECIQD/////AAAAAQAAAAAAAAAAAAAAAP//////////
/////zBbBCD/////AAAAAQAAAAAAAAAAAAAAAP///////////////AQgWsY12Ko6
k+ez671VdpiGvGUdBrDMU7D2O848PifSYEsDFQDEnTYIhucEk2pmeOETnSa3gZ9+
kARBBGsX0fLhLEJH+Lzm5WOkQPJ3A32BLeszoPShOUXYmMKWT+NC4v4af5uO5+tK
fA+eFivOM1drMV7Oy7ZAaDe/UfUCIQD/////AAAAAP//////////vOb6racXnoTz
ucrC/GMlUQIBAQ==
-----END EC PARAMETERS-----
-----BEGIN EC PRIVATE KEY-----
MHcCAQEEIAcPCHJ61KBKnN1ZyU2JaHcItW/JXTB3DujRyc4Ki7RqoAoGCCqGSM49
AwEHoUQDQgAE5itp4r9ln5e+Lx4NlIpM1Zdrt6keDUb73ampHp3culoB59aXqAoY
+cPEox5W4nyDSNsWGhz1HX7xlC1Lz3IiwQ==
-----END EC PRIVATE KEY-----
BUG=522228
Change-Id: I3723411a633dc07c4640027de07500293f8f7913
Reviewed-on: https://boringssl-review.googlesource.com/6853
Reviewed-by: Adam Langley <alangley@gmail.com>
2015-12-25 00:38:03 +00:00
|
|
|
static EC_KEY *eckey_type2param(int ptype, void *pval) {
|
|
|
|
EC_KEY *eckey = NULL;
|
|
|
|
|
|
|
|
if (ptype == V_ASN1_SEQUENCE) {
|
|
|
|
ASN1_STRING *pstr = pval;
|
|
|
|
const uint8_t *pm = pstr->data;
|
|
|
|
int pmlen = pstr->length;
|
|
|
|
|
|
|
|
eckey = d2i_ECParameters(NULL, &pm, pmlen);
|
|
|
|
if (eckey == NULL) {
|
|
|
|
OPENSSL_PUT_ERROR(EVP, EVP_R_DECODE_ERROR);
|
|
|
|
goto err;
|
|
|
|
}
|
|
|
|
} else if (ptype == V_ASN1_OBJECT) {
|
|
|
|
ASN1_OBJECT *poid = pval;
|
|
|
|
|
|
|
|
/* type == V_ASN1_OBJECT => the parameters are given
|
|
|
|
* by an asn1 OID */
|
|
|
|
eckey = EC_KEY_new_by_curve_name(OBJ_obj2nid(poid));
|
|
|
|
if (eckey == NULL) {
|
|
|
|
goto err;
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
OPENSSL_PUT_ERROR(EVP, EVP_R_DECODE_ERROR);
|
|
|
|
goto err;
|
|
|
|
}
|
|
|
|
|
|
|
|
return eckey;
|
|
|
|
|
|
|
|
err:
|
|
|
|
if (eckey) {
|
|
|
|
EC_KEY_free(eckey);
|
|
|
|
}
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
2014-06-20 20:00:00 +01:00
|
|
|
static int eckey_priv_decode(EVP_PKEY *pkey, PKCS8_PRIV_KEY_INFO *p8) {
|
|
|
|
const uint8_t *p = NULL;
|
|
|
|
void *pval;
|
|
|
|
int ptype, pklen;
|
|
|
|
EC_KEY *eckey = NULL;
|
|
|
|
X509_ALGOR *palg;
|
|
|
|
|
|
|
|
if (!PKCS8_pkey_get0(NULL, &p, &pklen, &palg, p8)) {
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
X509_ALGOR_get0(NULL, &ptype, &pval, palg);
|
|
|
|
|
|
|
|
eckey = eckey_type2param(ptype, pval);
|
|
|
|
|
2015-02-11 06:17:41 +00:00
|
|
|
if (!eckey) {
|
2014-06-20 20:00:00 +01:00
|
|
|
goto ecliberr;
|
2015-02-11 06:17:41 +00:00
|
|
|
}
|
2014-06-20 20:00:00 +01:00
|
|
|
|
|
|
|
/* We have parameters now set private key */
|
|
|
|
if (!d2i_ECPrivateKey(&eckey, &p, pklen)) {
|
2015-06-29 05:28:17 +01:00
|
|
|
OPENSSL_PUT_ERROR(EVP, EVP_R_DECODE_ERROR);
|
2014-06-20 20:00:00 +01:00
|
|
|
goto ecerr;
|
|
|
|
}
|
|
|
|
|
|
|
|
EVP_PKEY_assign_EC_KEY(pkey, eckey);
|
|
|
|
return 1;
|
|
|
|
|
|
|
|
ecliberr:
|
2015-06-29 05:28:17 +01:00
|
|
|
OPENSSL_PUT_ERROR(EVP, ERR_R_EC_LIB);
|
2014-06-20 20:00:00 +01:00
|
|
|
ecerr:
|
2015-02-11 06:17:41 +00:00
|
|
|
if (eckey) {
|
2014-06-20 20:00:00 +01:00
|
|
|
EC_KEY_free(eckey);
|
2015-02-11 06:17:41 +00:00
|
|
|
}
|
2014-06-20 20:00:00 +01:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int eckey_priv_encode(PKCS8_PRIV_KEY_INFO *p8, const EVP_PKEY *pkey) {
|
|
|
|
EC_KEY *ec_key;
|
|
|
|
uint8_t *ep, *p;
|
|
|
|
int eplen, ptype;
|
|
|
|
void *pval;
|
|
|
|
unsigned int tmp_flags, old_flags;
|
|
|
|
|
|
|
|
ec_key = pkey->pkey.ec;
|
|
|
|
|
|
|
|
if (!eckey_param2type(&ptype, &pval, ec_key)) {
|
2015-06-29 05:28:17 +01:00
|
|
|
OPENSSL_PUT_ERROR(EVP, EVP_R_DECODE_ERROR);
|
2014-06-20 20:00:00 +01:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* set the private key */
|
|
|
|
|
|
|
|
/* do not include the parameters in the SEC1 private key
|
|
|
|
* see PKCS#11 12.11 */
|
|
|
|
old_flags = EC_KEY_get_enc_flags(ec_key);
|
|
|
|
tmp_flags = old_flags | EC_PKEY_NO_PARAMETERS;
|
|
|
|
EC_KEY_set_enc_flags(ec_key, tmp_flags);
|
|
|
|
eplen = i2d_ECPrivateKey(ec_key, NULL);
|
|
|
|
if (!eplen) {
|
|
|
|
EC_KEY_set_enc_flags(ec_key, old_flags);
|
2015-06-29 05:28:17 +01:00
|
|
|
OPENSSL_PUT_ERROR(EVP, ERR_R_EC_LIB);
|
2014-06-20 20:00:00 +01:00
|
|
|
return 0;
|
|
|
|
}
|
2016-02-07 19:36:04 +00:00
|
|
|
ep = OPENSSL_malloc(eplen);
|
2014-06-20 20:00:00 +01:00
|
|
|
if (!ep) {
|
|
|
|
EC_KEY_set_enc_flags(ec_key, old_flags);
|
2015-06-29 05:28:17 +01:00
|
|
|
OPENSSL_PUT_ERROR(EVP, ERR_R_MALLOC_FAILURE);
|
2014-06-20 20:00:00 +01:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
p = ep;
|
|
|
|
if (!i2d_ECPrivateKey(ec_key, &p)) {
|
|
|
|
EC_KEY_set_enc_flags(ec_key, old_flags);
|
|
|
|
OPENSSL_free(ep);
|
2015-06-29 05:28:17 +01:00
|
|
|
OPENSSL_PUT_ERROR(EVP, ERR_R_EC_LIB);
|
2014-06-20 20:00:00 +01:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
/* restore old encoding flags */
|
|
|
|
EC_KEY_set_enc_flags(ec_key, old_flags);
|
|
|
|
|
|
|
|
if (!PKCS8_pkey_set0(p8, (ASN1_OBJECT *)OBJ_nid2obj(NID_X9_62_id_ecPublicKey),
|
|
|
|
0, ptype, pval, ep, eplen)) {
|
2015-06-17 05:02:11 +01:00
|
|
|
OPENSSL_free(ep);
|
2014-06-20 20:00:00 +01:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int int_ec_size(const EVP_PKEY *pkey) {
|
|
|
|
return ECDSA_size(pkey->pkey.ec);
|
|
|
|
}
|
|
|
|
|
|
|
|
static int ec_bits(const EVP_PKEY *pkey) {
|
2015-11-19 03:07:14 +00:00
|
|
|
const EC_GROUP *group = EC_KEY_get0_group(pkey->pkey.ec);
|
|
|
|
if (group == NULL) {
|
2014-06-20 20:00:00 +01:00
|
|
|
ERR_clear_error();
|
|
|
|
return 0;
|
|
|
|
}
|
2015-11-19 03:07:14 +00:00
|
|
|
return BN_num_bits(EC_GROUP_get0_order(group));
|
2014-06-20 20:00:00 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
static int ec_missing_parameters(const EVP_PKEY *pkey) {
|
|
|
|
return EC_KEY_get0_group(pkey->pkey.ec) == NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int ec_copy_parameters(EVP_PKEY *to, const EVP_PKEY *from) {
|
|
|
|
EC_GROUP *group = EC_GROUP_dup(EC_KEY_get0_group(from->pkey.ec));
|
|
|
|
if (group == NULL ||
|
|
|
|
EC_KEY_set_group(to->pkey.ec, group) == 0) {
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
EC_GROUP_free(group);
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int ec_cmp_parameters(const EVP_PKEY *a, const EVP_PKEY *b) {
|
|
|
|
const EC_GROUP *group_a = EC_KEY_get0_group(a->pkey.ec),
|
|
|
|
*group_b = EC_KEY_get0_group(b->pkey.ec);
|
2015-02-24 22:30:15 +00:00
|
|
|
if (EC_GROUP_cmp(group_a, group_b, NULL) != 0) {
|
|
|
|
/* mismatch */
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
return 1;
|
2014-06-20 20:00:00 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
static void int_ec_free(EVP_PKEY *pkey) { EC_KEY_free(pkey->pkey.ec); }
|
|
|
|
|
|
|
|
static int do_EC_KEY_print(BIO *bp, const EC_KEY *x, int off, int ktype) {
|
|
|
|
uint8_t *buffer = NULL;
|
|
|
|
const char *ecstr;
|
|
|
|
size_t buf_len = 0, i;
|
|
|
|
int ret = 0, reason = ERR_R_BIO_LIB;
|
|
|
|
BN_CTX *ctx = NULL;
|
|
|
|
const EC_GROUP *group;
|
|
|
|
const EC_POINT *public_key;
|
|
|
|
const BIGNUM *priv_key;
|
|
|
|
uint8_t *pub_key_bytes = NULL;
|
|
|
|
size_t pub_key_bytes_len = 0;
|
|
|
|
|
|
|
|
if (x == NULL || (group = EC_KEY_get0_group(x)) == NULL) {
|
|
|
|
reason = ERR_R_PASSED_NULL_PARAMETER;
|
|
|
|
goto err;
|
|
|
|
}
|
|
|
|
|
|
|
|
ctx = BN_CTX_new();
|
|
|
|
if (ctx == NULL) {
|
|
|
|
reason = ERR_R_MALLOC_FAILURE;
|
|
|
|
goto err;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (ktype > 0) {
|
|
|
|
public_key = EC_KEY_get0_public_key(x);
|
2014-06-20 20:00:00 +01:00
|
|
|
if (public_key != NULL) {
|
|
|
|
pub_key_bytes_len = EC_POINT_point2oct(
|
|
|
|
group, public_key, EC_KEY_get_conv_form(x), NULL, 0, ctx);
|
|
|
|
if (pub_key_bytes_len == 0) {
|
|
|
|
reason = ERR_R_MALLOC_FAILURE;
|
|
|
|
goto err;
|
|
|
|
}
|
|
|
|
pub_key_bytes = OPENSSL_malloc(pub_key_bytes_len);
|
|
|
|
if (pub_key_bytes == NULL) {
|
|
|
|
reason = ERR_R_MALLOC_FAILURE;
|
|
|
|
goto err;
|
|
|
|
}
|
|
|
|
pub_key_bytes_len =
|
|
|
|
EC_POINT_point2oct(group, public_key, EC_KEY_get_conv_form(x),
|
|
|
|
pub_key_bytes, pub_key_bytes_len, ctx);
|
|
|
|
if (pub_key_bytes_len == 0) {
|
|
|
|
reason = ERR_R_MALLOC_FAILURE;
|
|
|
|
goto err;
|
|
|
|
}
|
|
|
|
buf_len = pub_key_bytes_len;
|
2014-06-20 20:00:00 +01:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (ktype == 2) {
|
|
|
|
priv_key = EC_KEY_get0_private_key(x);
|
2015-02-11 06:17:41 +00:00
|
|
|
if (priv_key && (i = (size_t)BN_num_bytes(priv_key)) > buf_len) {
|
2014-06-20 20:00:00 +01:00
|
|
|
buf_len = i;
|
2015-02-11 06:17:41 +00:00
|
|
|
}
|
|
|
|
} else {
|
2014-06-20 20:00:00 +01:00
|
|
|
priv_key = NULL;
|
2015-02-11 06:17:41 +00:00
|
|
|
}
|
2014-06-20 20:00:00 +01:00
|
|
|
|
|
|
|
if (ktype > 0) {
|
|
|
|
buf_len += 10;
|
|
|
|
if ((buffer = OPENSSL_malloc(buf_len)) == NULL) {
|
|
|
|
reason = ERR_R_MALLOC_FAILURE;
|
|
|
|
goto err;
|
|
|
|
}
|
|
|
|
}
|
2015-02-11 06:17:41 +00:00
|
|
|
if (ktype == 2) {
|
2014-06-20 20:00:00 +01:00
|
|
|
ecstr = "Private-Key";
|
2015-02-11 06:17:41 +00:00
|
|
|
} else if (ktype == 1) {
|
2014-06-20 20:00:00 +01:00
|
|
|
ecstr = "Public-Key";
|
2015-02-11 06:17:41 +00:00
|
|
|
} else {
|
2014-06-20 20:00:00 +01:00
|
|
|
ecstr = "ECDSA-Parameters";
|
2015-02-11 06:17:41 +00:00
|
|
|
}
|
2014-06-20 20:00:00 +01:00
|
|
|
|
2015-02-11 06:17:41 +00:00
|
|
|
if (!BIO_indent(bp, off, 128)) {
|
2014-06-20 20:00:00 +01:00
|
|
|
goto err;
|
2015-02-11 06:17:41 +00:00
|
|
|
}
|
2015-11-19 03:07:14 +00:00
|
|
|
const BIGNUM *order = EC_GROUP_get0_order(group);
|
|
|
|
if (BIO_printf(bp, "%s: (%d bit)\n", ecstr, BN_num_bits(order)) <= 0) {
|
2014-06-20 20:00:00 +01:00
|
|
|
goto err;
|
2015-02-11 06:17:41 +00:00
|
|
|
}
|
2014-06-20 20:00:00 +01:00
|
|
|
|
2015-02-11 06:17:41 +00:00
|
|
|
if ((priv_key != NULL) &&
|
|
|
|
!ASN1_bn_print(bp, "priv:", priv_key, buffer, off)) {
|
2014-06-20 20:00:00 +01:00
|
|
|
goto err;
|
2015-02-11 06:17:41 +00:00
|
|
|
}
|
2014-06-20 20:00:00 +01:00
|
|
|
if (pub_key_bytes != NULL) {
|
|
|
|
BIO_hexdump(bp, pub_key_bytes, pub_key_bytes_len, off);
|
|
|
|
}
|
|
|
|
/* TODO(fork): implement */
|
|
|
|
/*
|
|
|
|
if (!ECPKParameters_print(bp, group, off))
|
|
|
|
goto err; */
|
|
|
|
ret = 1;
|
|
|
|
|
|
|
|
err:
|
2015-02-11 06:17:41 +00:00
|
|
|
if (!ret) {
|
2015-06-29 05:28:17 +01:00
|
|
|
OPENSSL_PUT_ERROR(EVP, reason);
|
2015-02-11 06:17:41 +00:00
|
|
|
}
|
2015-04-22 20:49:27 +01:00
|
|
|
OPENSSL_free(pub_key_bytes);
|
|
|
|
BN_CTX_free(ctx);
|
|
|
|
OPENSSL_free(buffer);
|
2014-06-20 20:00:00 +01:00
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int eckey_param_print(BIO *bp, const EVP_PKEY *pkey, int indent,
|
|
|
|
ASN1_PCTX *ctx) {
|
|
|
|
return do_EC_KEY_print(bp, pkey->pkey.ec, indent, 0);
|
|
|
|
}
|
|
|
|
|
|
|
|
static int eckey_pub_print(BIO *bp, const EVP_PKEY *pkey, int indent,
|
|
|
|
ASN1_PCTX *ctx) {
|
|
|
|
return do_EC_KEY_print(bp, pkey->pkey.ec, indent, 1);
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
static int eckey_priv_print(BIO *bp, const EVP_PKEY *pkey, int indent,
|
|
|
|
ASN1_PCTX *ctx) {
|
|
|
|
return do_EC_KEY_print(bp, pkey->pkey.ec, indent, 2);
|
|
|
|
}
|
|
|
|
|
2014-07-18 23:39:42 +01:00
|
|
|
static int eckey_opaque(const EVP_PKEY *pkey) {
|
|
|
|
return EC_KEY_is_opaque(pkey->pkey.ec);
|
|
|
|
}
|
|
|
|
|
2014-06-20 20:00:00 +01:00
|
|
|
static int old_ec_priv_decode(EVP_PKEY *pkey, const uint8_t **pder,
|
|
|
|
int derlen) {
|
|
|
|
EC_KEY *ec;
|
|
|
|
if (!(ec = d2i_ECPrivateKey(NULL, pder, derlen))) {
|
2015-06-29 05:28:17 +01:00
|
|
|
OPENSSL_PUT_ERROR(EVP, EVP_R_DECODE_ERROR);
|
2014-06-20 20:00:00 +01:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
EVP_PKEY_assign_EC_KEY(pkey, ec);
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
const EVP_PKEY_ASN1_METHOD ec_asn1_meth = {
|
|
|
|
EVP_PKEY_EC,
|
|
|
|
0,
|
|
|
|
"EC",
|
|
|
|
|
|
|
|
eckey_pub_decode,
|
|
|
|
eckey_pub_encode,
|
|
|
|
eckey_pub_cmp,
|
|
|
|
eckey_pub_print,
|
|
|
|
|
|
|
|
eckey_priv_decode,
|
|
|
|
eckey_priv_encode,
|
|
|
|
eckey_priv_print,
|
|
|
|
|
2014-07-18 23:39:42 +01:00
|
|
|
eckey_opaque,
|
2014-11-12 04:47:50 +00:00
|
|
|
0 /* pkey_supports_digest */,
|
2014-07-18 23:39:42 +01:00
|
|
|
|
2014-06-20 20:00:00 +01:00
|
|
|
int_ec_size,
|
|
|
|
ec_bits,
|
|
|
|
|
|
|
|
ec_missing_parameters,
|
|
|
|
ec_copy_parameters,
|
|
|
|
ec_cmp_parameters,
|
|
|
|
eckey_param_print,
|
|
|
|
0,
|
|
|
|
|
|
|
|
int_ec_free,
|
|
|
|
old_ec_priv_decode,
|
2015-10-30 20:43:49 +00:00
|
|
|
|
|
|
|
NULL /* digest_verify_init_from_algorithm */,
|
|
|
|
NULL /* digest_sign_algorithm */,
|
2014-06-20 20:00:00 +01:00
|
|
|
};
|