wolfSSL supports Raw Public Keys
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.
wolfSSL now supports hitch
We are excited to announce that wolfSSL has added support for the hitch project!
Hitch is a scalable TLS/SSL proxy developed by Varnish software. It’s designed to handle tens of thousands of connections efficiently on multicore machines. wolfSSL has recently added support for hitch as part of our open source support efforts. This means you get to use all of the features of wolfSSL like full TLS 1.3 support, FIPS certification and QUIC support with hitch.
To build hitch with the wolfSSL lightweight SSL/TLS library, you will currently need to use the master branch of wolfSSL, and our patch for hitch found here: https://github.com/wolfSSL/osp/tree/master/hitch
First, build wolfSSL as follows:
./autogen.sh ./configure --enable-hitch make sudo make install
Then, apply the hitch patch from above and build hitch as follows:
patch -p1 < /hitch/hitch_1.7.3.patch autoreconf -ivf ./configure --with-wolfssl make
If you have any questions or run into any issues, contact us at facts@wolfssl.com, or call us at +1 425 245 8247.
Live Webinar: SM Cipher
Please join us for an informative webinar about the release of wolfSSL’s SM cipher implementations.
As many people know, Chinese government regulators are now mandating use of SM2, SM3 and SM4 in critical systems, including automobiles, avionics, power systems, and communication systems. Since many of our customers are multi-nationals that do business in China, they have been requesting the addition of these algorithms in wolfSSL products.
We recently released our supported versions of SM2, SM3, and SM4, with the intention to release the ZUC stream cipher at some point this year to completely satisfy SM9. We are also in contact with labs regarding support of OSCCA certification at some point in the future. This is really great news for our customers in Chinese markets!
For those readers considering using wolfSSL products, here’s some additional notes:
- The SM Ciphers are fully supported in wolfSSL’s TLS 1.3 and DTLS 1.3 implementations.
- wolfSSH, wolfBoot and our other products will support ShangMi ciphers.
- ARM, Intel, and RiscV assembly is in the works for our SM implementations for maximum performance
- We support bare metal for SM2, SM3, and SM4.
- We have maximized performance and minimized size, so the ShangMi algorithms will work well for embedded systems use cases on a wide variety of microcontrollers (MCU’s). They will be available for all of the MCU silicon that we currently support, including STM32, NXP i.MX, RISC-V, Renesas RA, RX, and Synergy, Nordic NRF32, Microchip PIC32, Infineon Aurix, TI MSP, and many others.
- Our GPLv2 versions of the SM ciphers are available on GitHub and for download here: https://github.com/wolfSSL/wolfssl/tree/master/wolfcrypt/src
Commercially licensed versions are available.
Watch the webinar here: SM Ciphers are now implemented in wolfSSL
As always, our webinars will include Q&A sessions throughout the webinar.
If you have questions on any of the above, please contact us at facts@wolfssl.com, or call us at +1 425 245 8247.
ARIA Cipher Support via MagicCrypto
We have with the merge of our PR#6400 integrated the ARIA cipher for customers who sell into the South Korean market. The ARIA cipher has been adopted as the national standard in South Korea in various software and hardware products. We now have support for ARIA_128 and ARIA_256 in GCM mode. This pull request also contains crypto callback usage of the MagicCrypto library (from Dream Security) for signature, hashing and key agreement.
To get started, simply place the MagicCrypto library and header files in a folder called MagicCrypto in the root of the wolfSSL repository. To build, run the following:
./configure –enable-aria –enable-cryptocb –enable-all && make all
The following is an example using our own sample programs. To start a daemon server run:
./examples/server/server -i -x -v 3 -A ./certs/ca-ecc-cert.pem -k ./certs/ecc-key.pem -c ./certs/intermediate/server-chain-ecc.pem -V -l ECDHE-ECDSA-ARIA128-GCM-SHA256:ECDHE-ECDSA-ARIA256-GCM-SHA384
The client can be run as follows:
./examples/client/client -v 3 -l ECDHE-ECDSA-ARIA128-GCM-SHA256 -A ./certs/ca-ecc-cert.pem -k ./certs/ecc-client-key.pem -c ./certs/intermediate/client-chain-ecc.pem -C
If you have questions on any of the above, please contact us at facts@wolfssl.com, or call us at +1 425 245 8247.
wolfCrypt Support for LMS and HSS Signatures
wolfSSL is excited to announce we are adding support for the LMS and HSS post-quantum stateful hash-based signature schemes to our wolfCrypt embedded crypto engine. This will be achieved by experimental integration with the hash-sigs LMS/HSS library, similar to our previous libOQS integration.
Leighton-Micali Signatures (LMS), and its multi-tree variant, the Hierarchical Signature System (HSS), is a post-quantum, stateful hash-based signature scheme. It is noted for having small public and private keys, and fast signing and verifying. Its signature sizes are larger, but are tunable via its Winternitz parameter. Furthermore, stateful hash-based signature schemes are founded on the security of their underlying hash functions and Merkle trees (typically implemented with SHA-256), which are not expected to be broken by the advent of cryptographically-relevant quantum computers. For these reasons they have been recommended by NIST SP 800-208 and the NSA’s CNSA 2.0 suite.
Because of their unique strengths and characteristics, and NIST and NSA backing, LMS and HSS are of particular interest for offline firmware authentication and signature verification, especially on embedded or constrained systems that are expected to have a long operational lifetime and thus need to be resilient against a quantum-enabled future. Furthermore, the CNSA 2.0 timeline has specified that stateful hash-based signature schemes should be used exclusively by 2030, and adoption should begin immediately. In fact, adoption of LMS is the earliest requirement in the CNSA 2.0 suite timeline.
If you’re curious and want to learn more, see the following pull request links:
- https://github.com/wolfSSL/wolfssl/pull/6564
- https://github.com/wolfSSL/wolfssl-examples/pull/390
- https://github.com/wolfSSL/documentation/pull/101
If the podcast sparks some further questions that you have, you can reach out to facts@wolfssl.com, or call us at +1 425 245 8247 to continue the conversation with us here at wolfSSL!
wolfSSL Support for Microchip TA100 Crypto Coprocessor
wolfSSL has tested and provides support for a range of public key cryptographic algorithms on the Microchip Trust Anchor (TA100) – Automotive Grade security IC. This includes RSA with 2048-bit key size as well as ECC with 256 key size, supporting both NIST Prime and Brainpool curves. It’s worth noting that the TA100 is a more recent addition compared to the previously supported ATECC508 or ATECC608. To enable this specific configuration, you can use either the Autoconf option by running “./configure –enable-microchip=100” or set the preprocessor define CFLAGS=”-DWOLFSSL_MICROCHIP_AT100″.
The TA100 is a secure element from Microchip portfolio of CryptoAutomotive™ security ICs.The module offers various security features such as code authentication (secure boot), MAC generation for message authentication, support for secure firmware updates, authentication for Qi 1.3 wireless charging, and multiple key management protocols including TLS. It is a highly secure solution offering features such as key agreement and sign-verify authentication. It supports various asymmetric, symmetric, and hashing security protocols to ensure robust protection.
The TA100 is compatible with a range of microprocessors (MPUs) and microcontrollers (MCUs), including our AVR® and ARM® processor-based MCUs and MPUs. Its versatility allows for seamless integration into different system architectures.
For more details on TA100, see https://www.microchip.com/en-us/product/ta100
If you have questions on any of the above, please contact us at facts@wolfssl.com, or call us at +1 425 245 8247
Using cURL with wolfSSL and TLS 1.3
wolfSSH With X.509 Support
wolfSSH can make use of X.509 certificates when verifying the peer! Both on the client side and on the server side. The implementation follows RFC 6187 and adds x509v3-ecdsa-sha2-* and x509v3-ssh-rsa to the key exchange algorithms. Instead of the public key, the whole certificate is passed along during authentication and then verified by the peer using a CA or an authorized key file. Having the option to verify the client’s certificate using a CA allows for any clients with a valid, signed certificate, to connect without needing to update an authorized key file. This includes the support for verifying certificate chains!
To build wolfSSH with X.509 support the enable option (–enable-certs) can be used. For example “./configure –enable-certs”. One thing to note is that wolfSSH also has FPKI support. If the wolfSSL being linked to has been built with FPKI support (happens with –enable-all) then the macro WOLFSSH_NO_FPKI can be used to turn off the FPKI certificate checks in wolfSSH. (–enable-certs CPPFLAGS=”-DWOLFSSH_NO_FPKI”). The example echoserver has some X.509 support but if wanting to leverage X.509 verification in multiple parts of the SSH handshake then the wolfSSHd application should be used on the server side, enabled with (–enable-sshd) or the wolfSSH library API themselves in your own application.
This is an example of what X509 certificate use looks like with wolfSSH!
Configure wolfSSH library:
./configure --enable-sshd --enable-certs CPPFLAGS=-DWOLFSSH_NO_FPKI && make
Create sshd config file that reads in certificates:
cat sshd_config
Port 22222 Protocol 2 LoginGraceTime 600 TrustedUserCAKeys /path/to/wolfssh/keys/ca-cert-ecc.pem HostKey /path/to/wolfssh/keys/server-key.pem HostCertificate /path/to/wolfssh/keys/server-cert.pem
Run wolfSSHd application:
./apps/wolfsshd/wolfsshd -D -f ./sshd_config
Connect to wolfSSHd using the wolfSSH client:
./examples/client/client -u fred -i ./keys/fred-key.der -J ./keys/fred-cert.der -A ./keys/ca-cert-ecc.der
Note that the wolfSSHd application will check that ‘fred’ is a valid user on the system and the client will check the IP of the host.
The example certificate has a host IP set to 127.0.0.1 :
server-cert.pem:
X509v3 Subject Alternative Name: DNS:example, IP Address:127.0.0.1
The example user certificate fred-cert.der specifies the user name “fred” in a UPN (User Principal Name) extension. This is an Other type subject alternative name which has the format <user>@<domain>. Having the user name set here in the certificate binds the certificate to the user “fred” and makes it so that it can not be used by other user names.
If you have any questions or run into any issues, contact us at facts@wolfssl.com, or call us at +1 425 245 8247.
wolfSSL Supports Keil v6 Compiler
Looking to add SSL/TLS to your Keil project?
The wolfSSL embedded SSL/TLS library is a lightweight SSL/TLS library written in ANSI C and targeted for embedded, RTOS, and resource-constrained environments – primarily because of its small size, speed, and feature set. For Keil MDK and uVision users we provide a CMSIS pack that enables them to utilize the library on their platform. The pack is integrated into the Keil MDK and includes wolfCrypt and TLS examples which allow for quick adoption of our library into embedded targets.
It’s now possible to compile wolfSSL with Keil’s v6 compiler. We tested the wolfSSL v5.6.3 Keil pack with the v6.19 compiler and were able to get it building without making a single code change.
Follow the guide below to try the pack out on your target.
Guide: https://github.com/wolfSSL/wolfssl/blob/master/IDE/MDK5-ARM/README.md
If you have any questions or run into any issues, contact us at facts@wolfssl.com, or call us at +1 425 245 8247.
Better ASN.1 Support with Templates
wolfSSL has significant improvements on how we parse and encode ASN.1 data like certificates and keys.
Parsing X.509 certificates, and RSA and ECC keys is important to do correctly. In fact, vulnerabilities come from not checking the validity of the encoding correctly! Reading outside the encoded data can result in crashing of your application or device.
To simplify the code and to make it as safe as possible, templates have been introduced that describe the format of data to be parsed or encoded. Using common functions that validity check the ASN.1 structure on parsing means fewer places for bugs. It also means less code!
Extensive testing has been performed on the new code including external fuzz testing. We are now confident the new code works just as well as the original implementation.
When using configure.ac to produce a Makefile, the new template code is compiled by default. For embedded customers, you will need to define: WOLFSSL_ASN_TEMPLATE.
To use the original code, either configure with —enable-asn=original or remove the WOLFSSL_ASN_TEMPLATE define. This code will be removed in future releases for reasons of maintenance so we encourage you to try out the new template code.
If you have any questions or run into any issues, contact us at facts@wolfssl.com, or call us at +1 425 245 8247.