RECENT BLOG NEWS

So, what’s new at wolfSSL? Take a look below to check out the most recent news, or sign up to receive weekly email notifications containing the latest news from wolfSSL. wolfSSL also has a support-specific blog page dedicated to answering some of the more commonly received support questions.

Live Webinar: Linux Kernel Mode

Exciting news for Linux Kernel Module developers and developers who are interested in diving into Linux Kernel Module. Join us for a webinar on Linux Kernel Mode hosted by wolfSSL Engineer Daniel Pouzzner.

Watch the webinar here: Linux Kernel Mode

After wolfSSL 4.6.0 introduced initial support for building as a Linux kernel module, and providing native wolfCrypt and wolfSSL APIs to other kernel modules in December 2020, wolfSSL Linux Kernel Module support has grown by leaps and bounds, with new support for public key(PK) cryptographic acceleration, FIPS 140-3, accelerated crypto in IRQ handlers, portability improvements, and overall feature completeness.

wolfSSL engineer, Daniel Pouzzner, will showcase how wolfSSL Linux Kernel Mode can enhance your projects. It is your opportunity to learn knowledge and technical skills. Watch it now!

As always we will have a Q&A Session following 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 Supports TSIP v1.17

wolfSSL 5.6.3 adds support for Renesas TSIP v1.17 and extends some of the TLS handshake operations to use this cryptographic accelerator. TSIP v1.17 adds the ability to handle CertificateVerify messages over TLS. This feature is used for both validation and generation of messages exchanged with the server. Of course, both TLS1.2 and 1.3 can handle both ECC and RSA certificates.

Example applications for Renesas RX series MCUs with Renesas IDE e2studio project files are provided in the wolfSSL package, included in the /IDE/Renesas/e2studio/RXxx folders. Detailed instruction manuals written both in English and Japanese will help you get started with wolfSSL on these platforms quickly.

If you have any questions or want to know more details, lease contact us at facts@wolfssl.com, or call us at +1 425 245 8247.

Download wolfSSL

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:

  • MLSpp (C++) (Status: RFC)
  • OpenMLS (Rust) (Status: RFC)
  • go-mls (Go) (Status: RFC in progress)

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.

Posts navigation

1 2 3 34 35 36 37 38 39 40 189 190 191

Weekly updates

Archives