Live Webinar: Espressif
Commercial-grade encryption tools are essential in every developer’s programming toolbox. We are excited to announce a live webinar presented by Jim aka gojimmypi, wolfSSL Engineer, where he will discuss Espressif products.
Watch the webinar here: Getting Started with wolfSSL on the Espressif ESP32
Recently, we announced the first availability of the wolfSSL embedded encryption libraries in the ESP Registry located at components.espressif.com. If you are looking to enhance the security system in your projects or products, this is your opportunity to learn the fundamentals of our security solutions and how they integrate seamlessly with Espressif’s tech. Watch it now!
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.
Download wolfSSL
wolfSSL Support for Renesas SCE Crypt Only Use
We have extended wolfSSL’s Renesas Secure Crypto Engine (SCE) support to include a crypt-only build for the Renesas RA6M4. wolfSSL already supports Renesas SCE for TLS communication. In addition to our existing TLS support, the SCE driver can be used for standalone cryptographic operations. Using this mode, users are able to gain not only the performance benefit but also a smaller footprint by enabling only necessary cryptography operations. This use case was added for RA6M4 support in wolfBoot.
To enable this use case, define the macro:
WOLFSSL_RENESAS_SCEPROTECT_CRYPTONLY
wolfSSL crypt-only SCE mode currently supports SHA2-256, RSA 1024/2048 bit encryption/decryption, and RSA 1024/2048 bit sign/verify.
Please contact us at facts@wolfssl.com, or call us at +1 425 245 8247 with any questions, or for help integrating wolfSSL products into your project!
Download wolfSSL
MLS (Messaging Layer Security) is on Track
There is a common theme in all wolfSSL products which is that they basically involve two parties. For wolfSSL, wolfSSH, wolfMQTT and cURL libraries there is a server and a client. For wolfBoot, you have the boot loader and firmware provider. For wolfTPM you have the user and the TPM. For wolfSentry you have the system and the intruder.
Soon, things are going to be different. With the new MLS (Messaging Layer Security) there will be multiple parties (Alice, Bob, Carol, Dean, Emily, etc., etc.). We’re talking decentralized (serverless) end-to-end security that scales with forward secrecy and post-compromise security. It is widely acknowledged that wolfSSL is a leader in cryptographic protocols, so with the new RFC 9420 finally set to “Standards Track” status we’re starting to see some interest!
With our new implementation of Encrypted ClientHello (ECH), we have implemented Hybrid Public Key Encryption (HPKE) and so we are well on our way to an implementation for MLS which also requires HPKE.
MLS is a natural choice for suppliers of communications infrastructure to governments because it scales! That makes wolfCrypt’s FIPS certification a potential game changer. With our tried and tested FIPS 140-2 as well as our impending FIPS 140-3 certification, wolfCrypt FIPS can make an MLS implementation attractive to government vendors today and well into the future.
But wait, how far into the future? Until a cryptographically relevant quantum computer comes into existence. Do you have requirements to keep your communications protected for several years into the future? Then you must have been thinking about post-quantum algorithms. The NSA has. They’ve come out with their CNSA 2.0 guidance and wolfSSL is listening. We already support LMS, Dilithium, Kyber and all the symmetric ciphers and hash algorithms required by it. Would you like to see a post-quantum MLS?
Here is a short list of open source implementations that we know about:
What if wolfCrypt is the cryptographic implementation underneath these libraries? We even have a golang wrapper.
Do you have a use case for MLS? Do you need FIPS? How long do you need to keep your communications confidential? Please reach out to us here at facts@wolfssl.com, or call us at +1 425 245 8247 to help us understand your needs!
Download wolfSSL
wolfBoot support for Renesas RA6M4
We’re happy to announce that we have added wolfBoot support for the Renesas RA6M4! The Renesas RA6M4 group uses a high-performance Arm Cortex-M33 core with TrustZone. The RA6M4 is supported by an open and flexible ecosystem concept – the Flexible Software Package (FSP), built on FreeRTOS – and is expandable to use other RTOS and middleware.
wolfBoot is a portable secure bootloader solution that offers firmware authentication and firmware update mechanisms. Due to its minimalistic design and tiny HAL API, wolfBoot is completely independent from any OS or bare-metal application.
By adding wolfBoot support for the RA6M4, it demonstrates how simple secure firmware updates can be accomplished on this target with wolfBoot, and in doing so can also leverage the Renesas SCE. A sample application has been developed which securely updates firmware v1 to new image v2. Both sample firmware versions behave the same except displaying the version of the image (v1 or v2). This example is compiled with Renesas e2Studio and runs on the RA6M4 target board. Detailed steps to run the example can be found here: https://github.com/wolfSSL/wolfBoot/blob/master/IDE/Renesas/e2studio/RA6M4/Readme.md
To run the example with SCE support enabled, you can find the Readme located here: https://github.com/wolfSSL/wolfBoot/blob/master/IDE/Renesas/e2studio/RA6M4/Readme_wSCE.md
wolfBoot currently supports Renesas SCE crypto acceleration for SHA256 and RSA.
If you are interested in trying wolfBoot on the RA6M4, or are interested in having us expand algorithm support, please contact us at facts@wolfssl.com, or call us at +1 425 245 8247.
Announcing Ada binding to the wolfSSL library
Today we are happy to announce the availability of an Ada/SPARK binding that enables Ada applications to use post-quantum TLS 1.3 encryption through the wolfSSL embedded SSL/TLS library.
It opens the door to obtaining FIPS 140-3 and DO-178C certifications for Ada and Spark applications that use TLS for their encrypted communications and also makes them quantum-safe.
Check out the Ada/SPARK binding on GitHub here: https://github.com/wolfSSL/wolfssl/tree/master/wrapper/Ada
The Ada port is suitable for anything from IoT, embedded systems to Desktop and Cloud systems.
Contact us at facts@wolfssl.com, or call us at +1 425 245 8247 with any questions, comments, or suggestions.
wolfBoot v1.16 released
wolfBoot v1.16 has been released. This version introduces a key component to facilitate staging on microprocessor-based embedded systems: an optional safe ELF format parser. The support for PowerPC architecture has been improved, now allowing the complete staging from RAM. The support for NXP P1021 has been extended, as well as for Renesas RA6M4 and RX72N.
Here is a summary of the most relevant changes:
Support for ELF parsing
By default, wolfBoot handles binary files, which allow the execution in place (XIP), on constrained embedded systems, and avoids copying the code in RAM. On large systems, however, it is now possible to sign and transfer executable files in ELF32 or ELF64 format, allowing for a more complex structure of symbols being mapped on different regions, or relocated at runtime.
Improvements on PowerPC architecture support
The support for PowerPC systems has been extended to allow complete boot from volatile memory using a first stage loader. The bare metal application or OS image can be compiled into a position-independent binary file which will be loaded to RAM by wolfBoot to complete the verification and run from RAM. The DDR memory initialization has also been re-engineered so that the bootloader can remap its stack at runtime immediately after the DDR RAM is initialized.
Extended support for NXP P1021
The support for NXP P1021 platform has been extended to support the drivers necessary to access TPM 2.0 devices, via wolfTPM, through the eSPI bus. Furthermore, it is now possible to use the TPM device as the root of trust for this target. Support for the QUICC Engine and multi-processor spin table. Fixed some minor issues on the eLBC NAND driver.
Extended support for Renesas microcontroller bases devices
Both RA6M4 and RX72N ports and example projects have been updated, and the documentation has been extended to cover the new features. In particular, we added the possibility to enable hardware acceleration using SCE and TSIP drivers from wolfCrypt.
Find out more about wolfBoot! Download the source code and documentation from our download page], or clone the repository from github. If you have any questions, comments or suggestions, send us an email at facts@wolfssl.com, or call us at +1 425 245 8247.
wolfSentry Dynamic Port Scanning Defenses and Stateful Rules
The latest wolfSentry release, version 1.4, adds advanced traffic attribute filters and controls, allowing field-configurable stateful routes for DNS and other connectionless protocols, and transparent port scanner detection and defenses.
Event handlers can be configured to restrict matches to traffic with specified attributes, such as inbound or outbound connection initiation or closure, binding of a socket, or attempt to send to an unreachable destination. An event handler can furthermore designate attributes to be set or cleared whenever a match implicates the event – “derogatory” or “commendable” flags, a “port_reset” flag to explicitly generate a reset reply, or any of 8 available user-defined flags in any combination.
An auxiliary event handler can now be associated with a primary event handler, for use when a new rule is dynamically added. The aux event can specify rule flags to be set and/or cleared in the newly generated rule, including wildcarding of any combination of match fields, designation of the traffic direction(s) to which the new rule will apply, and initial penalty boxing or green-listing.
Finally, a new built-in action handler, “%track-peer-v1”, creates new rules according to the filters and directives in the event definitions, as described above.
With these facilities, in concert with the fine-grained integration with lwIP, wolfSentry field configuration now has the expressive power to define port scan detection and defenses, automatic pinhole rule insertions, and other flexible stateful tracking use cases. All of these capabilities are available through JSON configuration, and can be updated, extended, or removed, at any time without system restart.
The latest wolfSentry release is available at https://github.com/wolfSSL/wolfsentry, with native in-tree support for FreeRTOS-newlib-nano on ARM with full lwIP integration. Other ports include POSIX (e.g. Linux), DeOS, and MacOS X. Let us know if you would like it on another platform. Our current porting plans include Green Hills IntegrityOS, VxWorks, LynxOS, PetaLinux,TRON/ITRON/µITRON, QNX, PikeOS and NuttX. Clone it now, and make test!
Contact us at facts@wolfssl.com, or call us at +1 425 245 8247 with any questions or for help getting started with wolfSentry in your project!
Jenkins ‘rerun failed tests’
We needed a way to reproduce GitHub Actions’ ability to only rerun those tests that failed in Jenkins. This is to speed up the re-testing in addition to reducing costs. Looking around no one really had a solution for this. So we wrote our own. This is the declarative pipeline that calls multiple jobs on a pull request from GitHub using the GHPRB (GitHub Pull Request Builder) plugin:
// declare our vars outside the pipeline
def tests = [:]
def jobRuns = [
['GroupName',[
'Test-Name'
,'Test2-Name'
]]
]
def cleanupName(name) {
return name.replaceAll("/","_").replaceAll("-","_").replaceAll(" ","_")
}
def getJobResultName(stepName) {
return "RESULT_" + cleanupName(env.JOB_NAME) + cleanupName(stepName)
}
@NonCPS
def commitHashForBuild(build) {
return build.rawBuild.getEnvironment().ghprbActualCommit
}
@NonCPS
def getLastBuild(curBuild, curHash) {
def lastBuild = curBuild.getPreviousBuild()
if ( lastBuild ) {
def lastHash = commitHashForBuild(lastBuild)
if ( lastHash == curHash ) {
return lastBuild
} else return getLastBuild(lastBuild, curHash)
}
return null
}
def checkIfPassed(lastBuild,jobName) {
if ( lastBuild ) {
def buildResults = lastBuild.getBuildVariables()
if ( (buildResults[getJobResultName(jobName)] != null) && ( buildResults[getJobResultName(jobName)] == "SUCCESS" ) ) {
return true
}
}
return false
}
pipeline {
agent { label 'agent_name_or_group' }
// options {
// timeout(time: 30, unit: 'MINUTES')
// }
stages {
stage('Run Tests') {
steps {
echo "Start check on "+currentBuild.getDisplayName()
script {
def lastBuild = getLastBuild(currentBuild, commitHashForBuild(currentBuild))
echo "Commit: " + env.ghprbActualCommit
echo "Commit2: " + currentBuild.buildVariableResolver.resolve("ghprbActualCommit")
if ( lastBuild ) {
echo "Found build "+lastBuild.getDisplayName()
} else {
echo "No previous build"
}
jobRuns.each { f ->
tests[f[0]] = {
// when running parallel build jobs, it is unnecessary to put in a 'node' block since the job itself will specify a node
f[1].each { j ->
echo "Has passed "+j+":"+checkIfPassed(lastBuild,j)
if (checkIfPassed(lastBuild,j)) { // preserve previous passed state
env[getJobResultName(j)] = "SUCCESS"
} else { // run last failed job
final buildJob = build job: j, parameters: [
string(name: 'sha1', value: env.sha1)
,string(name: 'ghprbActualCommit', value: env.ghprbActualCommit)
,string(name: 'ghprbActualCommitAuthor', value: env.ghprbActualCommitAuthor)
,string(name: 'ghprbActualCommitAuthorEmail', value: env.ghprbActualCommitAuthorEmail)
,string(name: 'ghprbAuthorRepoGitUrl', value: env.ghprbAuthorRepoGitUrl)
,string(name: 'ghprbTriggerAuthor', value: env.ghprbTriggerAuthor)
,string(name: 'ghprbTriggerAuthorEmail', value: env.ghprbTriggerAuthorEmail)
,string(name: 'ghprbTriggerAuthorLogin', value: env.ghprbTriggerAuthorLogin)
,string(name: 'ghprbTriggerAuthorLoginMention', value: env.ghprbTriggerAuthorLoginMention)
,string(name: 'ghprbPullId', value: env.ghprbPullId)
,string(name: 'ghprbTargetBranch', value: env.ghprbTargetBranch)
,string(name: 'ghprbSourceBranch', value: env.ghprbSourceBranch)
,string(name: 'ghprbPullAuthorEmail', value: env.ghprbPullAuthorEmail)
,string(name: 'ghprbPullAuthorLogin', value: env.ghprbPullAuthorLogin)
,string(name: 'ghprbPullAuthorLoginMention', value: env.ghprbPullAuthorLoginMention)
,string(name: 'ghprbPullDescription', value: env.ghprbPullDescription)
,string(name: 'ghprbPullTitle', value: env.ghprbPullTitle)
,string(name: 'ghprbPullLink', value: env.ghprbPullLink)
,string(name: 'ghprbPullLongDescription', value: env.ghprbPullLongDescription)
,string(name: 'ghprbCommentBody', value: env.ghprbCommentBody)
,string(name: 'ghprbGhRepository', value: env.ghprbGhRepository)
,string(name: 'ghprbCredentialsId', value: env.ghprbCredentialsId)
,string(name: 'random_string', value: env.random_string)
]
env[getJobResultName(j)] = buildJob.getResult()
}
}
}
}
// Still within the 'Script' block, run the parallel array object
parallel tests
}
}
}
}
}
The major drawback here is that you have to give in-script process approvals for the following things:
- method hudson.model.Run getEnvironment
- method org.jenkinsci.plugins.workflow.support.steps.build.RunWrapper getRawBuild
- staticMethod org.codehaus.groovy.runtime.DefaultGroovyMethods putAt java.lang.Object java.lang.String java.lang.Object
It shouldn’t be a terrible thing, considering your Jenkins should only have things in it that are approved by multiple sets of eyes, but still an important thing to note.
If you have questions on any of the above, please contact us at facts@wolfssl.com, call us at +1 425 245 8247 , or visit FAQ page.
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.