Month: December 2022

Heard of NuttX?  Fresh out of the Apache incubator, it’s a small RTOS with a focus on POSIX and ANSI standards compliance, scales from 8 to 64-bit microcontrollers, is extensively documented, ported to many platforms, and is very easy to get started with! 

 Here at wolfSSL we are hard at work testing wolfSSL with NuttX.  The flexible, efficient nature of NuttX makes it a natural fit for a lean, embedded SSL/TLS implementation like wolfSSL.  

Interested?  Let us know!

For questions please email facts@wolfssl.com

wolfSSL are proud to announce a new incremental update to wolfSSH: v1.4.12!

In this release, we have wolfSSHD running. It seamlessly fits in where other SSHDs are, and is able to parse and make use of existing sshd_config files that are in place.

We are also proud to announce that wolfSSH builds and runs in the Green Hills Software INTEGRITY environment. It takes advantage of INTEGRITY’s POSIX API. You can run a shell through it, or upload files to the local filesystem using SFTP.

For the cutting edge, wolfSSH adds Hybrid ECDH-P256 Kyber-Level1 for post-quantum hybrid key exchange.

The release information from the change log is reposted below:

New Feature Additions and Improvements

• Support for Green Hills Software's INTEGRITY
• wolfSSHd Release (https://github.com/wolfSSL/wolfssh/pull/453 rounds off testing and additions)
• Support for RFC 6187, using X.509 Certificates as public keys
• OCSP and CRL checking for X.509 Certificates (uses wolfSSL CertManager)
• Add callback to the server for reporting userauth result
• FPKI profile checking support
• chroot jailing for SFTP in wolfSSHd
• Permission level changes in wolfSSHd
• Add Hybrid ECDH-P256 Kyber-Level1
• Multiple server keys
• Makefile updates
• Remove dependency on wolfSSL being built with public math enabled

Fixes

• Fixes for compiler complaints using GHS compiler
• Fixes for compiler complaints using GCC 4.0.2
• Fixes for the directory path cleanup function for SFTP
• Fixes for SFTP directory listing when on Windows
• Fixes for large file transfers with SFTP
• Fixes for port forwarding
• Fix for building with QNX
• Fix for the wolfSSHd grace time alarm
• Fixes for Yocto builds
• Fixes for issues found with fuzzing

Vulnerabilities

• The vulnerability fixed in wolfSSH v1.4.8 finally issued CVE-2022-32073

For any questions about using wolfSSH contact us at facts@wolfssl.com

Merry Christmas! The Christmas release of wolfSSL is here, version 5.5.4! This includes some minor feature additions, QUIC related changes for HAProxy use, port to the MAXQ hardware, improvements in performance, as well as additional enhancements and fixes. In this development cycle we also did testing of using wolfSSL with NuttX, and wolfSSL is ready to go for any projects looking for TLS / cryptography with NuttX.

Here are some of the key new features  we added to this new version.

New Feature Additions

•  QUIC related changes for HAProxy integration and config option
•  Support for Analog Devices MAXQ1080 and MAXQ1065
•  Testing and build of wolfSSL with NuttX
•  New software based entropy gatherer with configure option --enable-entropy-memuse
•  NXP SE050 feature expansion and fixes, adding in RSA support and conditional compile of AES and CMAC
•  Support for multi-threaded sniffer

The full list of changes can be found in the ChangeLog.md bundled with wolfSSL or on the website www.wolfssl.com.

Visit our download page or https://github.com/wolfssl for downloading the bundle. Email us at facts@wolfssl.com with any questions.

HPKE (Hybrid Public Key Encryption) is a key encapsulation and encryption standard that allows two parties to derive a common secret and encrypt/decrypt messages using that common secret (https://www.ietf.org/archive/id/draft-irtf-cfrg-hpke-12.txt)

 HPKE has three steps in single-shot mode: 

1. Key encapsulation (KEM) - ECC P256, P384, P521 or X25519
2. Hash based Key Derivation (HKDF) - SHA2-256, SHA2-384, SHA2-512
3. Authenticated Encryption with Associated Data (AEAD). AES-GCM 128/256 bit

Here is an example of how HPKE is used: https://gist.github.com/jpbland1/b2a1c46bc934fd8ee0dc4d148a8b9eab

The `Hpke` struct is used for the HPKE operations and we initialize it with our KEM, KDF and AEAD algorithms using `wc_HpkeInit`. Here we're using X25519, SHA256 and AES128. Then we need to generate keypairs to use, with the `ephemeralKey` being used by the client to seal messages and the `receiverKey` being used by the server to open them. They're both generated using `wc_HpkeGenerateKeyPair` and have a type of `void*` because they can actually be one of many types depending on the KEM algorithm chosen, which wolfCrypt takes care of internally. The client then seals our message using `wc_HpkeSealBase` which takes the client’s private key, the server’s public key, an optional info field, an optional AAD field, the message to encrypt `start_text` and the buffer to put the encrypted message into `ciphertext`. NOTE that `ciphertext` MUST be 16 bytes longer than the message we're trying to encrypt to store the AEAD tag needed to decrypt it. `wc_HpkeSerializePublicKey` will serialize an HPKE public key into a bytestring so it can be shared with the other party. Keys can later be deserialized using `wc_HpkeDeserializePublicKey`. These functions should be used to share the KEM public keys between client and server. Then for the server to decrypt, `wc_HpkeOpenBase` takes the `receiverKey`, the serialized public `ephemeralKey`, an optional info field, an optional AAD field, the ciphertext and tag to decrypt and the buffer to store the decrypted message. When finished the `plaintext` buffer will have the same data in it as the original `start_text` buffer. To free the keys when we're done using them we call `wc_HpkeFreeKey` with the `kem` and key.

Support for ECH and HPKE was added in PR https://github.com/wolfSSL/wolfssl/pull/5623

For questions please email facts@wolfssl.com

ECH (Encrypted Client Hello) is a draft extension for TLS 1.3 that enables a client to encrypt its client_hello in the TLS handshake to prevent leaking sensitive metadata that is sent in the clear during the normal TLS handshake. ECH was originally proposed as ESNI (Encrypted Server Name Indication), since the server name indication is one of the sensitive fields that is visible to a passive observer during the handshake, but was later renamed since it covers the entire Client Hello. ECH uses HPKE (Hybrid Public Key Encryption) to derive a shared secret and encrypt the client_hello.

ECH works by making an inner Client Hello and an outer Client Hello. The outer hello has all sensitive metadata removed and includes a new TLS extension called ECH. The inner hello contains all the sensitive information and is encrypted using HPKE and then placed into the outer hello as the ECH extension. The client sends the outer hello and the server picks up on the use of ECH and decrypts the inner hello using its HPKE key.

Here is an example of how ECH is used:

https://gist.github.com/jpbland1/ad46617fcc40934b252ce031c7aa5969

In this example we connect to the Cloudflare server that has been setup to test different TLS and security settings and then call `wolfSSL_GetEchConfigs` to get the `retry_configs`. We then make a new SSL object, call `wolfSSL_SetEchConfigs` to apply the retry configs and then connect using ECH. We do this connect and reconnect process to get the `retry_configs` by sending what's called a GREASE ECH or a dummy ECH which is sent out in the absence of a set ECH. We can skip this step if we retrieve the ECH configs from a website's DNS records, but DNS is out of the scope of this example. Once we have the ECH configs set we can connect to and use the ssl connection like normal, here we send an http request to `/cdn-cgi/trace/ HTTP/1.1\r\n`, which will send us back information about our TLS connection. In the response that prints we will see `sni=encrypted`, which means that ECH is working.

Support for ECH was added in PR https://github.com/wolfSSL/wolfssl/pull/5623

For questions please email facts@wolfssl.com

In our never-ending quest to have wolfSSL supported and running on all platforms, everywhere, for everyone, we are proud to announce we are now supporting Softcore RISC-V Environments.

What is a Softcore RISC-V CPU? We’re glad you asked! Softcore means the electronics are created on a “soft” and reusable FPGA instead of the one-time, hard silicon manufacturing process. The RISC-V is of course open source; This allows anyone to build their own CPU and not pay any license fees for architecture or buy expensive proprietary development software. Silicon fabrication is expensive and time consuming for hardcore CPUs. 

Open-source toolchains such as those at YosysHQ allow literally anyone with a modern computer to build nearly anything imaginable on the “soft” fabric of an FPGA. This includes a full-blown CPU!  Anyone from the hobbyist building a CPU literally at the kitchen table at home to the most skilled development engineers developing next-generation, state-of-the-art custom CPUs in secret labs can use RISC-V technology. We’re there with you to help secure your data and connections to the outside world.

There are several different open-source RISC-V CPU projects out there. The one we’ve chosen to test with our wolfSSL code targets the Lattice Semiconductor ECP5-85F chip, specifically the FPGA on the Radiona ULX3S from our friends over at Crowd Supply. The soft RISC-V CPU is the Wren6991/Hazard3. This project was chosen as a test environment due to its relative grace and simplicity, as well as including a soft JTAG.

Are you interested in building your own custom CPU with wolfSSL? Contact us to see how we can help:  facts@wolfssl.com