RECENT BLOG NEWS
wolfSSH on Green Hills INTEGRITY RTOS
wolfSSH now runs on Green Hills Software's INTEGRITY RTOS. Rejoice! wolfSSH will build and run almost out of the box. You will have to do a little integration work to get INTEGRITY to start the server appropriately, but at that point it plays nice with the shell application and allows for SFTP. Users can log in using password or public key authentication. Because Green Hills' compiler is more strict about certain code constructs, wolfSSH has been updated to build cleanly without warnings. We look to make wolfSSH the most portable SSH solution for any platform, even bare metal. wolfSSH takes advantage of AEAD ciphers like AES-GCM and maintains a small code size.
wolfSSH is lovingly crafted by wolfSSL Inc in the Pacific Northwest.
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 Support for NXP SE050 with SCP03
wolfSSL has supported the NXP SE050 since wolfSSL 5.0.0 (November 1, 2021), giving wolfSSL and wolfCrypt users the ability to use cryptography and secure key generation/storage inside the SE050 while using wolfSSL’s own APIs from the application level. We recently made some substantial additions and enhancements to wolfSSL’s SE050 support, including the following. These are currently in our master branch on GitHub, and will be included in the next stable release of wolfSSL.
- SE050 RSA support (sign/verify/encrypt/decrypt, PKCS#1v1.5/PSS/OAEP padding, up to 4096-bit)
- Allowing use of larger key IDs, fully utilizing SE050’s key ID range
- Ability to get or set SE050 key IDs to/from wolfCrypt
RsaKey
orecc_key
structures - New APIs to store and get binary objects from SE050
- New API to erase SE050 objects at a specified key ID
- New API to get the object size at a specified key ID
- New define
WOLFSSL_SE050_NO_TRNG
to fall back to usage of/dev/random
and/dev/urandom
instead of SE050 TRNG - Additional documentation (README_SE050.md)
- Install
se050_port.h
withmake install
for public API use on Linux hosts - Fix default library and include paths with “
--with-se050
” configure option - Fix for ECC P-521 where curve size can be larger than SHA-512 digest size
- Fixes to SE050 message digest support
- Fixes for wolfCrypt test compatibility with SE050 enabled
wolfSSL SE050 Examples
To help users get going easier and more quickly, we have published example applications designed to be integrated into the SE05x Middleware on Linux (tested on Raspbian with a Raspberry Pi). This examples are located in our wolfssl-examples repository on GitHub, along with documentation on how to integrate and build. Examples include:
- wolfCrypt test application
- wolfCrypt benchmark application
- wolfCrypt SE050 key and certificate insertion and use
- wolfCrypt CSR generation
wolfSSL HostCrypto support for SCP03 Authentication
wolfSSL can be used on the host side (HostCrypto) for secure SCP03 (Secure Channel Protocol ’03’) authentication, in place of either OpenSSL or mbedTLS. To make this possible, wolfSSL has written a HostCrypto layer that can be applied as a patch to the NXP SE05x Middleware. Using wolfSSL HostCrypto will use wolfSSL’s software cryptography on the host side to establish the SCP03 channel. After secure channel establishment, wolfSSL can then be used while offloading crypto and key operations to the SE050.
A patch for the SE05x Middleware for adding wolfSSL HostCrypto support can be found in our osp repository (Open Source Ports) on GitHub, along with documentation on how to patch and build on a Raspberry Pi / Raspbian environment.
Support and More Details
For more details on wolfSSL’s SE050 support, or 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 JSSE Provider and JNI Wrapper 1.11.0 Now Available
Version 1.11.0 of the wolfSSL JSSE Provider and JNI wrapper is now available for download!
wolfSSL JNI/JSSE provide Java-based applications with an easy way to use the native wolfSSL SSL/TLS library. The thin JNI wrapper can be used for direct JNI calls into native wolfSSL, or the JSSE provider (wolfJSSE) can be registered as a Java Security provider for seamless integration underneath the Java Security API. wolfSSL JNI/JSSE provides TLS 1.3 support and also can work with wolfCrypt FIPS 140-2 (and upcoming 140-3).
Release 1.11.0 has bug fixes and new features including:
JNI and JSSE Changes:
- Add support for system properties: keyStore, keyStoreType, keyStorePassword (PR 74)
- Add support for secure renegotiation if available in native wolfSSL (PR 75)
- Fix compilation against newer wolfSSL versions that have dtls.c (PR 107)
- Fixes and cleanup to SSLEngine implementation (PR 108)
- Fixes for SSLEngine synchronization issues (PR 108)
- Add non-standard X509TrustManager.checkServerTrusted() for use on Android (PR 109)
- Add RPM packaging support (PR 110)
- Fix SSLSocketFactory.createSocket() to allow for null host (PR 111)
- Remove @Override on SSLEngine.getHandshakeSession() for older Java versions (PR 114)
Version 1.11.0 can be downloaded from the wolfSSL download page, and an updated version of the wolfSSL JNI/JSSE User Manual can be found here. If you have any questions or run into any issues, contact us at facts@wolfssl.com, or call us at +1 425 245 8247.
Support for MAXQ1065 in wolfSSL
Do you want to use the Analog Devices Inc./Maxim Integrated MAXQ1065 ultra-low-power secure authenticator? If so, then you'll be interested to know that wolfSSL now supports it! You can use the MAXQ1065 to accelerate your TLS 1.2 connections in your applications by taking advantage of wolfSSL's integration into the MAXQ10xx SDK.
With this new addition, you get wolfSSL's full source code and build instructions for building wolfSSL with a client-only configuration so that when it comes time to go to production, all code that is not required for building the TLS client is compiled out thus reducing your binary footprint significantly.
To make it as easy as possible for you to get started, we support the maxq10xx SDK with the MAXQ1065 evaluation board plugged into the 40-pin GPIO headers of a RaspberryPi. The SDK and example application are built and executed on the RaspberryPi while the cryptographic operations are done by the evaluation board.
In summary, here is what is accelerated in TLS 1.2:
- PSK
- ECC P-256 Authentication and Key Exchange
- AES CCM and GCM Record Processing
- Cipher Suites
- TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
- TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8
- TLS_ECDHE_ECDSA_WITH_AES_256_CCM_8
- TLS_PSK_WITH_AES_128_GCM_SHA256
- TLS_PSK_WITH_AES_128_CCM
- TLS_PSK_WITH_AES_256_CCM
- TLS_PSK_WITH_AES_128_CCM_8
- TLS_PSK_WITH_AES_256_CCM_8
If you have any questions or run into any issues, contact us at facts@wolfssl.com, or call us at +1 425 245 8247.
DTLS 1.3 Benchmarks
wolfSSL has support for the new DTLS 1.3 protocol. You can learn more about this protocol in our “What’s new in DTLS 1.3” blog post (https://www.wolfssl.com/whats-new-dtls-1-3/) and how to use it in our “DTLS 1.3 Examples and Use Cases” blog post (https://www.wolfssl.com/dtls-1-3-examples-use-cases/). In this post we will compare some benchmarks between DTLS 1.2 and 1.3. The biggest differentiators will be the decreased round trips and the use of acknowledgements.
The same ciphers were used for all connections. TLS_AES_256_GCM_SHA384 for DTLS 1.3 and TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 for DTLS 1.2. SECP256R1 was the curve used in both cases.
In all cases, 10 samples were taken and the average of the results was graphed. The error bars represent the standard deviation of the samples.
The first graph shows the time it takes to send 15 MB of data in 500 byte packets and the second graph is the time it took to complete the handshake from the client’s perspective. This benchmark was run on one machine without any latency. The throughput of DTLS 1.3 remains very similar to the throughput of DTLS 1.2. There is a slight performance gain that is the result of a more streamlined implementation. The time to complete the handshake remains the same due to the lack of latency. We are glad that the increased security of DTLS 1.3 has not negatively impacted throughput or connection speeds.
The third graph shows the same time to complete a handshake in the same setup but with a 100 ms latency introduced. The DTLS 1.3 handshake completes in half the time due to the fewer round trips required. After the handshake completes, the peers can start exchanging application data.
The fourth graph shows the total bandwidth used when a packet is lost. DTLS 1.3 uses about half as much bandwidth when compared to DTLS 1.2. This is achieved by using small acknowledgements to let the peer know what messages were received. The DTLS 1.2 connection needs to resend its entire previous flight to notify the peer that a message was lost and the peer needs to resend its entire previous flight as well because it doesn’t know which packet was dropped.
The improved security parameters of DTLS 1.3 also translate to an increase in performance and efficiency. This is good news for everyone and we are looking forward to moving users from DTLS 1.2 to 1.3! Additionally, DTLS 1.3 gains access to TLS 1.3 features like key updates, post handshake authentication, and post quantum cryptography.
If you have any questions or run into any issues, contact us at facts@wolfssl.com, or call us at +1 425 245 8247.
DTLS 1.3 Examples and Use Cases
wolfSSL has support for the new DTLS 1.3 protocol. You can learn more about this protocol in our “What’s new in DTLS 1.3” blog post (https://www.wolfssl.com/whats-new-dtls-1-3/). Using DTLS 1.3 in wolfSSL is almost as easy as using DTLS 1.2! Client implementations only need to change their existing wolfDTLSv1_2_client_method() calls into wolfDTLSv1_3_client_method(). If you are using wolfSSL’s built-in network I/O, then you don’t need to worry about anything else! You can already start enjoying the benefits of TLS 1.3 in DTLS.
Server implementations need to start by changing their wolfDTLSv1_2_server_method() calls into wolfDTLSv1_3_server_method(). It is also recommended to use the cookie exchange with DTLS 1.3. Cookie exchange is enabled and the cookie secret is set using the wolfSSL_send_hrr_cookie() API.
If you are using custom network I/O callbacks in wolfSSL, there is one more new feature you need to be aware of. The wolfSSL_dtls13_use_quick_timeout() API should be used to set a quicker timeout. To allow for out-of-order delivery of handshake messages, wolfSSL will sometimes ask the user to set a quick timeout. The recommended timeout duration for a quick timeout is wolfSSL_dtls_get_current_timeout() / 4.
This new API is presented in these examples:
- https://github.com/wolfSSL/wolfssl-examples/blob/master/dtls/client-dtls13.c
Basic client example - https://github.com/wolfSSL/wolfssl-examples/blob/master/dtls/server-dtls13.c
Basic server example - https://github.com/wolfSSL/wolfssl-examples/blob/master/dtls/server-dtls13-event.c
Event driven server example with custom I/O callbacks using libevent
The examples can be compiled with make. The Basic Client example loop can be quit by sending “end” into the prompt.
If you have any questions or run into any issues, contact us at facts@wolfssl.com, or call us at +1 425 245 8247.
What’s new in DTLS 1.3
The DTLS 1.3 standard has recently been published in April 2022 in RFC 9147. It features many improvements and additions to increase security and efficiency of the DTLS protocol. At wolfSSL, we like to be very quick adopters of new standards which is why initial support for DTLS 1.3 was merged in June and appeared in wolfSSL release 5.4.0. In this blog post we will go through the list of changes from DTLS 1.2 described in sections 12 and 13 of RFC 9147 and expand on what they mean for your security.
Another exciting feature of DTLS 1.3 is post quantum cryptography! It is available in wolfSSL using the same interface as for TLS 1.3. See this blog post for more details.
- New handshake pattern, which leads to a shorter message exchange.
In TLS 1.3, the handshake protocol has been simplified to 1 round trip from the previous 2 round trips. DTLS 1.2 and 1.3 both add an extra round trip for the stateless cookie exchange.
Old DTLS 1.2 handshake
Client Server ------ ------ ClientHello --------> Flight 1 <------- HelloVerifyRequest Flight 2 ClientHello --------> Flight 3 ServerHello \ Certificate* \ ServerKeyExchange* Flight 4 CertificateRequest* / <-------- ServerHelloDone / Certificate* \ ClientKeyExchange \ CertificateVerify* Flight 5 [ChangeCipherSpec] / Finished --------> / [ChangeCipherSpec] \ Flight 6 <-------- Finished /
New DTLS 1.3 handshake
Client Server +--------+ ClientHello | Flight | --------> +--------+ +--------+ <-------- HelloRetryRequest | Flight | + cookie +--------+ +--------+ ClientHello | Flight | + cookie --------> +--------+ ServerHello {EncryptedExtensions} +--------+ {CertificateRequest*} | Flight | {Certificate*} +--------+ {CertificateVerify*} {Finished} <-------- [Application Data*] {Certificate*} +--------+ {CertificateVerify*} | Flight | {Finished} --------> +--------+ [Application Data] +--------+ <-------- [ACK] | Flight | [Application Data*] +--------+
- Only AEAD ciphers are supported. Additional data calculation has been simplified.
AEAD ciphers provide a unified encryption and authentication operation. Before (D)TLS 1.3, authentication would be accomplished using a technique called MAC-then-Encrypt. This would use an HMAC to compute an authenticated code of the data and then encrypt the concatenation of the plaintext and the code into ciphertext. The recipient can check the authenticity of the data by computing the HMAC code and comparing with the one received. AEAD ciphers simplify this into one operation.
- Removed support for weaker and older cryptographic algorithms.
All legacy ciphersuites have been removed and are no longer valid with DTLS 1.3. This improves security by only allowing peers to communicate using strong ciphersuites.
- HelloRetryRequest of TLS 1.3 used instead of HelloVerifyRequest.
The HelloRetryRequest replaces the DTLS 1.2 HelloVerifyRequest. This allows peers to negotiate security parameters and perform a cookie exchange at the same time.
- More flexible cipher suite negotiation.
Ciphersuite negotiation has been separated into different extensions. Previous versions of (D)TLS had included all possible permutations of symmetric and asymmetric ciphers in the ciphersuite list. In (D)TLS 1.3 the ciphersuites only contain the AEAD and hash algorithms that will be used for the connection. Other security parameters are negotiated in extensions like supported_groups, signature_algorithms, key_share, or pre_shared_key.
- New session resumption mechanism. PSK authentication redefined.
In (D)TLS 1.3, session resumption and PSK have been combined into one mechanism. To resume a session, the server sends NewSessionTicket messages to the client containing tickets that can be used in subsequent connections. "session IDs" and "session tickets" are now obsolete.
Additionally, when resuming a session, the client can immediately send “early data” in its first flight of the handshake. This is also called 0-RTT Data since it allows peers to exchange data in the first round trip. This is useful to drastically cut down on the latency of a new connection and speed up the initial round of communication between the peers.
- New key derivation hierarchy utilizing a new key derivation construct.
TLS 1.3 has introduced a new key schedule for deriving secrets using the HMAC-based Extract-and-Expand Key Derivation Function (HKDF) primitive. This separates the multiple secrets used in the TLS connection. See this section for the specifics.
- Improved version negotiation.
Version negotiation no longer uses the value found in the Record header. Now an extension is used to advertise all supported (D)TLS versions. This new mechanism is to overcome some middleboxes failing when presented with a new (D)TLS version value.
- Optimized record layer encoding and thereby its size. Sequence numbers are encrypted.
DTLS 1.3 introduces a very efficient “unified header”. This new header format also obfuscates the epoch and sequence numbers to make traffic analysis harder.
0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |0|0|1|C|S|L|E E| +-+-+-+-+-+-+-+-+ | Connection ID | Legend: | (if any, | / length as / C - Connection ID (CID) present | negotiated) | S - Sequence number length +-+-+-+-+-+-+-+-+ L - Length present | 8 or 16 bit | E - Epoch |Sequence Number| +-+-+-+-+-+-+-+-+ | 16 bit Length | | (if present) | +-+-+-+-+-+-+-+-+
Figure 3: DTLS 1.3 Unified Header
- Added CID functionality.
RFC 9146 has introduced connection identifiers in DTLS 1.2. A similar mechanism is defined in DTLS 1.3. Users of CID’s can mark packets so that they are multiplexed according to the CID instead of the IP 4-tuple allowing records to be sent through multiple paths at once!
If you have any questions or run into any issues, contact us at facts@wolfssl.com, or call us at +1 425 245 8247.
Customized ad-hoc secure boot with wolfBoot
wolfBoot is known for being the universal secure bootloader for all types of embedded systems.
While initially targeting 32-bit microcontrollers, wolfBoot has grown into a full framework to implement secure boot solutions on a wide range of different systems and architectures.
This is mostly due to wolfBoot modularity and flexibility, which makes our solution easy to reshape and adapt to the most peculiar use cases. Here are a few examples of customizations we have facilitated in the past, taken from real-life use cases.
Update images stored on external devices
This type of customization is perhaps the most popular. wolfBoot offers an interface to interact with external storage devices or anything that can be abstracted as such: the “ext_flash” interface.
Ext_flash is an interface that connects wolfBoot to a driver that implements the following function calls, to access the content of specific storage devices:
ext_flash_lock() ext_flash_write() ext_flash_read() ext_flash_erase() ext_flash_unlock()
On microprocessor-based embedded systems, ‘external’ devices are often the only solution, requiring specific drivers to access the kernel images on different supports (USB, SD, eMMC, SSD, etc.). Microcontroller architectures often integrate external NOR SPI/QSPI flash memories that can be used as persistent storage, where generally it’s not possible to execute code in place.
wolfBoot has an additional layer directly supporting several types of SPI flash memory chips. The SPI support is also implemented on top of the ext_flash API interface, and provides another level of abstraction. In this case porting to a new target with an SPI controller only requires to implement the following single SPI transfer functions, and the SPI layer will link the required functions to access the flash through this interface:
spi_init() spi_cs_on() spi_cs_off() spi_read() spi_write() spi_release()
SPI access is just one of the possibilities available in wolfBoot to extend the support to any non-volatile memory, and beyond.
Update images downloaded on-demand from neighbor systems
By design choice, wolfBoot does not include any network stack or communication capabilities besides the access to storage devices and internal flash memory. This is an advantage both in terms of security because it makes the attack surface very small, and from the safety point of view keeping all the structures and code flow simple to follow and predictable.
In some cases it’s required to communicate with other systems during the boot stage, because the firmware image or the updates received may be stored elsewhere, avoiding to split the flash memory to make room for a second partition. In these cases, wolfBoot may be required to open a communication channel (usually through a serial bus such as UART or SPI) to retrieve the firmware images from a neighbor system. This is in fact a rather common requirement when wolfBoot is securing the boot procedure on asymmetric multiprocessor systems or in general systems with multiple heterogeneous cores.
The recommended way to access remote content from wolfBoot consists in defining a custom ext_flash driver that abstracts a virtual addressable memory space. wolfBoot codebase contains an example of ext_uart driver running the client endpoint connecting to the uart_flash_server POSIX application provided, that can export signed and encrypted files for wolfBoot to handle and stage. EXT_UART is yet again one of the possible modes to extend the external flash support to both physical storage supports and virtualized abstractions.
Third-party key provisioning
Provisioning keys is a process that may involve third party tools and entities that generate, store and use the main private key to sign the firmware images. Thanks to the flexibility of the key tools distributed with wolfBoot, keypairs can be both generated or imported (in their public format) within the signing process. While the public keys must all be available and accessible by wolfBoot at run time, the private keys are used to sign the header of each authentic firmware.
The actual signature operation can be detached from the manifest header composition, by splitting the two phases. This way the signing is performed by an external tool, and the private key does not need to be accessed during the operation.
For more information on the possibilities of customizing the signing procedure, please see wolfBoot signing tools documentation.
Storing keys in a secure vault
Storing the public keys used to authenticate the firmware in a secure, write-protected area of persistent memory is the most important security requirement for proper secure-boot mechanism. In many cases it is sufficient to execute wolfBoot from a write-protected area, and keep the keys stored along with the bootloader code, in a C array. This is the default mechanism implemented in wolfBoot.
When the keygen tool generates or imports public keys, it creates two copies of the local archive of the public keys needed at runtime for signature verification, in two different formats. The C array (keystore.c), to be built in the bootloader image, and a binary file (keystore.der) containing the same structure in binary format.
By excluding keystore.c, it is possible to upload the content of keystore.der into a dedicated secure or write-protected storage. A driver to access the secure vault at runtime must be provided, through an API exporting three functions for wolfBoot to retrieve the public keys, their sizes and their permissions mask. Using a separate abstraction layer for the keystore provides an interface that can be customized beyond classic secure element or TPM interactions, to design a more complex structure to handle keys at runtime. More information available in the wolfBoot documentation page about keystore structure.
Unique partition/images and keys combination
Multiple-stage boot layouts can get very complex. Our development team has learned a lot when designing the boot process involving a set of partitions and firmware images with different levels of access permissions for the first time. Since then, we have dealt with several scenarios where multiple actors had to be capable of updating only one subset of partitions with firmware authenticated with specific subsets of public keys.
Consider the following scenario: an embedded device with a secure bootloader and two partitions: a “system” partition (perhaps running in secure mode from a TEE) and an “application” partition, containing configurable software that can be uploaded by a registered user that owns or has access to the device. Two separate keys are needed in this case: the user should only be able to send signed updates for the application partition, while the manufacturer must be able to update the system software (and the bootloader itself, if needed). The two levels of privilege in this case require two separate keypairs, the first one can be associated with the user, and the second with more powers should be kept by the manufacturer.
The latest wolfBoot, thanks to the keystore structure, supports up to 15 target partitions, and each one of these can be authenticated using one or more public keys from the keystore.
A firmware package in wolfBoot is always associated with an identification number (id) from 0 to 15, indicating the partition where the firmware must be installed. In the scenario described above, the ‘system’ would have id=1 and the ‘application’ software is associated with id=2. wolfBoot reserves id=0 for self-update procedure, i.e. update packages containing a new (signed) version of wolfBoot itself.
This mechanism allows the update mechanism to use the same update partition as temporary storage for all the updates, because wolfBoot will parse the incoming package and parse the manifest header to process the package using the right keys. The public key object elements in the keystore described earlier contain a bit mask that associates each key to the single target partition ids.
“Non-secure” boot
wolfBoot supports many different combinations of public key algorithms and key sizes. However, In some cases, authenticating the firmware is not a requirement. wolfBoot works properly when compiled with SIGN=NONE, excluding only the signature verification part, and keeping all the other features to facilitate the update, roll back in case of failure and verify the integrity of the firmware image after the transfer using SHA. That is, wolfBoot can be used as a non-secure bootloader, with a footprint of a few KB and very little impact on boot time. Especially useful in very small low-power systems with a tight amount of resources and CPU cycles.
wolfBoot as library: adding secure boot to legacy bootloaders
Among our customers, many have been upgrading older products and devices, reusing legacy software from previous versions, while stepping ahead with the security requirements which usually means adding a secure boot solution.
While starting a new bootloader from scratch is often an underestimated task from the development and testing point of view, many development teams rely on existing solutions that have been maintained and deployed on the field for years. Some custom bootloader solutions include network communication, sometimes with proprietary protocols and data links which would require a major effort to integrate into a vanilla wolfBoot. On the other hand, most of these legacy solutions lack the needed security features to implement cryptographic secure boot.
For this reason we have introduced the possibility to build wolfBoot as a library. Instead of providing the entire bootloader implementation, including build-up, staging, specific hardware access and customized flows, ‘wolfBoot as library’ is completely portable anywhere and provides easy interfaces to parse the manifest header, check versioning, verify an image loaded or mapped in memory for integrity and authenticity against the provided keystore. The key tools on the hosts can be used exactly in the same way as with the full wolfBoot installation, as the format remains the same and it is completely independent from the hardware or the architecture. To learn more about using wolfBoot as a library, check the documentation page about the library API.
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 or run into any issues, contact us at facts@wolfssl.com, or call us at +1 425 245 8247.
wolfCrypt JCE Provider and JNI Wrapper 1.5.0 Now Available
Version 1.5.0 of the wolfCrypt JCE Provider and JNI wrapper is now available for download!
wolfCrypt JNI/JCE provide Java-based applications with an easy way to use the native wolfCrypt cryptography library. The thin JNI wrapper can be used for direct JNI calls into native wolfCrypt, or the JCE provider (wolfJCE) can be registered as a Java Security provider for seamless integration underneath the Java Security API. wolfCrypt JNI/JCE can work with wolfCrypt FIPS 140-2 (and upcoming 140-3) as well!
Release 1.5.0 of wolfCrypt JNI has bug fixes and new features including:
- Add build compatibility for Java 7 (PR 38)
- Add support for “SHA” algorithm string in wolfJCE (PR 39)
- Add rpm package support (PR 40)
- Add wolfJCE MessageDigest.clone() support (PR 41)
- Improve error checking of native Md5 API calls (PR 41)
- Add unit tests for com.wolfssl.wolfcrypt.Md5 (PR 41)
Version 1.5.0 can be downloaded from the wolfSSL download page, and an updated version of the wolfCrypt JNI/JCE User Manual can be found here. If you have any questions or run into any issues, contact us at facts@wolfssl.com, or call us at +1 425 245 8247.
Announcing New Capabilities in wolfSentry
As wolfSentry gets ever closer to its first production release, we are introducing some exciting new capabilities, among them:
- Mature dynamic rule management, with automatic peer tracking, penalty boxing, O(1) release from penalty box, and realtime-safe (O(1)) limits on resource usage.
- Robust support in the configuration file and public API for user-defined data (key-value pairs) with freeform JSON values, to arbitrary (user-limited) depth, with a fully integrated API for processing and exporting JSON in DOM (random-access) mode.
- An API for setting user-defined configuration nodes as read-only.
- Improvements and extensions to the API for use by user plugins (action handlers) streamlining typical use cases involving dynamic rule insertion and update.
- Added examples/notification-demo/log_server
- A standalone web server demonstrating HTTPS with dynamic insertion of limited-lifespan wolfSentry rules blocking (penalty boxing) abusive peers.
- Mutual authentication using TLS, role-based authorizations pivoting on client certificate issuer (certificate authority), and wolfSentry event log retrieval, as a dynamically generated JSON array.
All of these and more are featured in wolfSentry preview release 7. For more details, clone wolfSentry from https://github.com/wolfSSL/wolfsentry, review ChangeLog.md and README.md, and “make test”. If you have any questions or run into any issues, contact us at facts@wolfssl.com, or call us at +1 425 245 8247.
Weekly updates
Archives
- December 2024 (17)
- 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)