wolfSSL has added support for handling “Raw Public Keys (RPK)”. This blog post provides an overview of the RPK and explains how to use it with wolfSSL.
Who Needs Raw Public Keys
Embedded devices that implement TLS are increasing, but certificate chain verification is a heavy load for devices with severe resource (MCU power and memory) constraints. There is a need for a simple method to obtain the public key of the peer.
RFC7250 specifies how “Raw Public Keys (RPK)” can be used with TLS or DTLS. And it specifies the use of a subset (ie RPK) containing only public key information in place of the commonly used X.509v3 certificate.
The purpose of using certificates is to authenticate communication between peers. A PKI infrastructure is usually used for that purpose. Signature verification is performed on the entire chain of certificates from the trust anchor, called the root CA, to the leaf certificate. In TLS with RPK, on the other hand, there is no such certificate chain, just the public key is sent to the peer. Clearly, authentication using PKI is not applicable and requires a different authentication method. RFC7250 recommends the introduction of ”DNS-Based Authentication of Named Entities (DANE)” as one of these methods.
TLS Extensions for RPK
RPKs are used in TLS as a replacement for commonly used X.509 certificates. However, since the information they carry is different from X509, their handling requires negotiation at both ends of the session. New extensions have been added to ClientHello and ServerHello to handle RPKs: client_certificate_type and server_certificate_type.
A client that supports RPK will send a ClientHello with a client_certificate_type extension if it can send an RPK, plus a server_certificate_type extension if it can accept an RPK from the server. In this diagram the client will send the xxxx_certificate_type extensions to the server in order of preference: RPK,X.509:
----- Client ----- ----- Server -----
ClientHello ------------------->
+ client_certificate_type(RPK > X509)
+ server_certificate_type(RPK > X509)
At this time, xxxx_certificate_type specifies the types of certificates that can be sent or accepted in order of priority. If the client does not include the RPK in its specification, the extension itself MUST NOT be included in the ClientHello. Also, if the client wants to send the RPK as a client certificate, but the only server certificate it wants to receive is the same X.509 as before, there is no need to include the server_certificate_type extension.
The server side that receives this xxxx_certificate_type extension will reply to ServerHello specifying only one certificate type (RPK in this example) determined by these servers.
----- Client ----- ----- Server -----
ClientHello ------------------->
+ client_certificate_type(RPK > X509)
+ server_certificate_type(RPK > X509)
<------------ ServerHello
+ client_certificate_type(RPK) (*1)
+ server_certificate_type(RPK) (*2)
<----------- Certificate + RPK(*2) Certificate_request, ... certificate + RPK(*1) --------------->
...
The server then sends a certificate of server_certificate_type in ServerHello to the client with a certificate message. Also, when the server sends a Certificate_request to request a client certificate, the client side must send a certificate of client_certificate_type of ServerHello.
Thus, there is no difference in the TLS handshake between using RPK and using traditional X.509 certificates, except for the addition of two extensions to ClientHello and ServerHello, and the change in content of the certificate sent.
How does wolfSSL support RPK?
To enable RPK support in wolfSSL build with the “HAVE_RPK” macro definition. The RPK handling logic is incorporated and the following functions can be used regardless of the client side or server side.
Certificate Type Negotiation
wolfSSL provides several functions for negotiating the xxxx_certificate_type extension to add to ClientHello and ServerHello. The following functions are some of them and should be called before starting a TLS handshake. Sets the certificate types that can be sent or accepted in the buffer in order of preference.
int wolfSSL_set_client_cert_type(WOLFSSL* ssl, const char* buf, int len); int wolfSSL_set_server_cert_type(WOLFSSL* ssl, const char* buf, int len);
For example, on the client side, if the client certificate that can be sent is RPK, and the server certificate that can be accepted is RPK and X509, the code would be as follows:
int ret;
char ctype[] = {WOLFSSL_CERT_TYPE_RPK};
char stype[] = {WOLFSSL_CERT_TYPE_RPK, WOLFSSL_CERT_TYPE_X509};
ret = wolfSSL_set_client_cert_type(ssl, ctype, sizeof(ctype)/sizeof(byte));
ret = wolfSSL_set_server_cert_type(ssl, stype, sizeof(stype)/sizeof(byte));
The setting method for the above functions are the same on the server side. A certificate type that matches the two new extensions sent from the client and the content of the above two functions set on the server is selected and sent to the client in ServerHello.
Load RPK
RPK can be loaded by specifying either DER format file or binary data. The function for that can be the one used to load traditional X.509 certificates:
WOLFSSL_CTX* ctx;
...
ret = wolfSSL_CTX_use_certificate_file(ctx, "./certs/rpk/server-cert-rpk.der",
WOLFSSL_FILETYPE_ASN1 );
-- or --
ret = wolfSSL_CTX_use_certificate_buffer(ctx, buf, bufSz,
WOLFSSL_FILETYPE_ASN1 );
RPK Verification
Verification of received RPKs is not provided by TLS. The user should do the verification outside of TLS. wolfSSL provides a way to invoke the user’s certificate verification callback for this purpose. The user can do the verification inside that callback function.
To enable this user callback, in addition to the HAVE_RPK macro definition shown above, Build with the WOLFSSL_ALWAYS_VERIFY_CB macro defined.
Additionally, implement a certificate verification callback with the following function prototype and pass it to the wolfSSL_set_verify function.
typedef int (*WOLFSSL_X509_STORE_CTX_verify_cb)(int, WOLFSSL_X509_STORE_CTX *);
static int MyRpkVerifyCb(int mode, WOLFSSL_X509_STORE_CTX* strctx)
{
// get RPK stored in strctx->certs->buffer
// then perform own authentication.
// return WOLFSSL_SUCCESS when authenticated successfully.
}
...
wolfSSL_CTX_set_verify(ctx , WOLFSSL_VERIFY_PEER, MyRpkVerifyCb);
Handshake with RPK
Here are the results of TLS1.3 communication using the wolfSSL sample client with RPK support enabled and the GnuTLS server. On the gnutls server side, specify the RPK certificate and the private key corresponding to the public key to listen for HTTPS connections. When the connection from the wolfSSL client is successful, information such as the received RPK, cipher suite, etc. will be output.
gnutls-serv --http --x509fmtder --priority NORMAL:+CTYPE-CLI-RAWPK:+CTYPE-SRV-RAWPK --rawpkfile ../Server-cert-RPK.der --rawpkkeyfile ../server-key.der HTTP Server listening on IPv4 0.0.0.0 port 5556...done HTTP Server listening on IPv6 :: port 5556...done * Accepted connection from IPv4 127.0.0.1 port 50420 on Thu Jun 29 15:59:24 202 - Peer's certificate was NOT verified. - Description: (TLS1.3-Raw Public Key)-(ECDHE-SECP521R1)-(RSA-PSS-RSAE-SHA512)-(AES-128-GCM) - Session ID: CF:8C:E9:38:D6:5B:E9:D7:58:DF:29:6C:D9:6E:F1:CA:70:36:13:DD:75:80:1E:6B:0C:3C:1C:32:7A:52:FE:A2 - Certificate type: Raw Public Key - Got 1 Raw public-key(s). - Raw pk info: - PK algo: RSA -----BEGIN PUBLIC KEY----- MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwwPRK/45pDJFO1PIhCsq fHSavaoqUgdH1qY2sgcyjtC6aXvGw0Se1IFI/S1oootnu6F1yDYsStIb94u6zw35 7+zxgR57mwNHmr9lzH9lJGmm6BSJW+Q098WwFJP1Z3s6enjhAVZWkaYTQo3SPECc TO/Rht83URsMoTv18aNKNeThzpbfG36/TpfQEOioCDCBryALQxTFdGe0MoJvjYbC iECZNoO6HkByIhfXUmUkc7DO7xnNrv94bHvAEgPUTnINUG07ozujmV6dyNkMhbPZ itlUJttt+qy7/yVMxNF59HHThkAYE7BjtXJOMMSXhIYtVi/XFfd/wK71/Fvl+6G6 0wIDAQAB -----END PUBLIC KEY----- - Ephemeral EC Diffie-Hellman parameters - Using curve: SECP521R1 - Curve size: 528 bits - Version: TLS1.3 - Server Signature: RSA-PSS-RSAE-SHA512 - Client Signature: RSA-PSS-RSAE-SHA256 - Cipher: AES-128-GCM - MAC: AEAD - Options: - Channel binding 'tls-unique': Scheduling inactive connection for close
Here is also the packet captured with Wireshark:
You can see that ClientHello contains server_certificate_type and client_certificate_type extensions.
If you have questions on any of the above, please contact us at facts@wolfssl.com, or call us at +1 425 245 8247 to learn more.