RECENT BLOG NEWS
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:
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.
Weekly updates
Archives
- December 2024 (16)
- November 2024 (29)
- October 2024 (18)
- September 2024 (21)
- August 2024 (24)
- July 2024 (27)
- June 2024 (22)
- May 2024 (28)
- April 2024 (29)
- March 2024 (21)
- February 2024 (18)
- January 2024 (21)
- December 2023 (20)
- November 2023 (20)
- October 2023 (23)
- September 2023 (17)
- August 2023 (25)
- July 2023 (39)
- June 2023 (13)
- May 2023 (11)
- April 2023 (6)
- March 2023 (23)
- February 2023 (7)
- January 2023 (7)
- December 2022 (15)
- November 2022 (11)
- October 2022 (8)
- September 2022 (7)
- August 2022 (12)
- July 2022 (7)
- June 2022 (14)
- May 2022 (10)
- April 2022 (11)
- March 2022 (12)
- February 2022 (22)
- January 2022 (12)
- December 2021 (13)
- November 2021 (27)
- October 2021 (11)
- September 2021 (14)
- August 2021 (10)
- July 2021 (16)
- June 2021 (13)
- May 2021 (9)
- April 2021 (13)
- March 2021 (24)
- February 2021 (22)
- January 2021 (18)
- December 2020 (19)
- November 2020 (11)
- October 2020 (3)
- September 2020 (20)
- August 2020 (11)
- July 2020 (7)
- June 2020 (14)
- May 2020 (13)
- April 2020 (14)
- March 2020 (4)
- February 2020 (21)
- January 2020 (18)
- December 2019 (7)
- November 2019 (16)
- October 2019 (14)
- September 2019 (18)
- August 2019 (16)
- July 2019 (8)
- June 2019 (9)
- May 2019 (28)
- April 2019 (27)
- March 2019 (15)
- February 2019 (10)
- January 2019 (16)
- December 2018 (24)
- November 2018 (9)
- October 2018 (15)
- September 2018 (15)
- August 2018 (5)
- July 2018 (15)
- June 2018 (29)
- May 2018 (12)
- April 2018 (6)
- March 2018 (18)
- February 2018 (6)
- January 2018 (11)
- December 2017 (5)
- November 2017 (12)
- October 2017 (5)
- September 2017 (7)
- August 2017 (6)
- July 2017 (11)
- June 2017 (7)
- May 2017 (9)
- April 2017 (5)
- March 2017 (6)
- January 2017 (8)
- December 2016 (2)
- November 2016 (1)
- October 2016 (15)
- September 2016 (6)
- August 2016 (5)
- July 2016 (4)
- June 2016 (9)
- May 2016 (4)
- April 2016 (4)
- March 2016 (4)
- February 2016 (9)
- January 2016 (6)
- December 2015 (4)
- November 2015 (6)
- October 2015 (5)
- September 2015 (5)
- August 2015 (8)
- July 2015 (7)
- June 2015 (9)
- May 2015 (1)
- April 2015 (4)
- March 2015 (12)
- January 2015 (4)
- December 2014 (6)
- November 2014 (3)
- October 2014 (1)
- September 2014 (11)
- August 2014 (5)
- July 2014 (9)
- June 2014 (10)
- May 2014 (5)
- April 2014 (9)
- February 2014 (3)
- January 2014 (5)
- December 2013 (7)
- November 2013 (4)
- October 2013 (7)
- September 2013 (3)
- August 2013 (9)
- July 2013 (7)
- June 2013 (4)
- May 2013 (7)
- April 2013 (4)
- March 2013 (2)
- February 2013 (3)
- January 2013 (8)
- December 2012 (12)
- November 2012 (5)
- October 2012 (7)
- September 2012 (3)
- August 2012 (6)
- July 2012 (4)
- June 2012 (3)
- May 2012 (4)
- April 2012 (6)
- March 2012 (2)
- February 2012 (5)
- January 2012 (7)
- December 2011 (5)
- November 2011 (7)
- October 2011 (5)
- September 2011 (6)
- August 2011 (5)
- July 2011 (2)
- June 2011 (7)
- May 2011 (11)
- April 2011 (4)
- March 2011 (12)
- February 2011 (7)
- January 2011 (11)
- December 2010 (17)
- November 2010 (12)
- October 2010 (11)
- September 2010 (9)
- August 2010 (20)
- July 2010 (12)
- June 2010 (7)
- May 2010 (1)
- January 2010 (2)
- November 2009 (2)
- October 2009 (1)
- September 2009 (1)
- May 2009 (1)
- February 2009 (1)
- January 2009 (1)
- December 2008 (1)