Category: Uncategorized

wolfSSL FIDO Compliance: Implementing FIDO Authentication Standards with wolfCrypt

wolfSSL FIDO Compliance

As organizations move away from traditional password-based authentication, FIDO (Fast Identity Online) has emerged as one of the leading standards for strong authentication. wolfSSL is positioned to support this transition with our robust cryptography library, wolfCrypt, which implements many of the core algorithms required for FIDO compliance. This blog outlines how wolfSSL can serve as a foundation for FIDO-compliant authentication solutions.

FIDO and Why It Matters

FIDO (Fast Identity Online) Alliance maintains strict standards for cryptographic implementations in authentication systems with a mission to reduce the reliance of passwords. With wolfCrypt implementing most of the FIDO-approved algorithms, this means wolfSSL can provide developers with a compliant cryptographic foundation for their FIDO authentication solutions for both large, web-connected systems as well as embedded microcontrollers.

Existing FIDO-Approved Algorithms

wolfSSL already implements many of the cryptographic algorithms from FIDO’s allowed cryptography list[1], including:

  • SHA-256, SHA-384, SHA-512, SHA3-256, SHA3-384 and SHA3-512
  • HMAC capabilities with the allowed hash functions
  • HMAC implementation for secure message authentication
  • AES-CMAC support for lightweight authentication
  • AES-GCM for authenticated encryption
  • RSA PSS and PKCS#1 v1.5 signature support
  • Ed25519 signatures

The only missing algorithms in wolfSSL are the implementation of ED256, ED256-2, ED512 and ED638.

wolfSSL also meets FIDO’s deterministic random number/bit generator requirements as wolfCrypt is NIST FIPS 140-2/3 compliant which uses NIST SP800-90A HASH_DRBG as well as NIST SP800-90B compliant entropy generation.

Potential Integration with FIDO2 Applications and Libraries

FIDO2 is the latest authentication standard that enables passwordless and strong two-factor authentication through the Web Authentication (WebAuthn) API and Client-to-Authenticator Protocol (CTAP). With there already being FIDO2 applications on the market wolfSSL can easily be implemented directly or automatically with the compatibility layer or engine/provider OpenSSL replacement. For instance Yubico’s libfido2 library which uses OpenSSL could be ported to use wolfCrypt instead.

A wolfSSL employee has also been working on a project that uses 2FA with wolfCrypt on a Raspberry Pi Pico called Fidelio.

FIPS 140-3 and FIDO2

Organizations requiring both FIDO2 and FIPS 140-3 compliance can leverage wolfCrypt’s FIPS 140-3 validated module, which provides CAVP and FIPS validated implementations of essential FIDO algorithms. This dual compliance ensures solutions meet both authentication standards and regulatory requirements.

Looking Forward

Contact us at facts@wolfSSL.com or +1 425 245 8247 for question about comprehensive support for integrating wolfCrypt into your FIDO2 applications, including:

  • Technical consultation for implementation
  • Documentation and example code
  • Integration with hardware security modules
  • Optimization for embedded systems
  • Custom builds for specific platforms

Resources

[1] “FIDO Authenticator Allowed Cryptography List,” FIDO Alliance, 2023.

Download wolfSSL Now

Dilithium Support in wolfCLU

We have added the Dilithium command to wolfCLU. Dilithium (referred to as ML-DSA by NIST) is a post-quantam cryptography (PQC) algorithm for signing and verification. This blog post provides an overview of how to use the Dilithium command in wolfCLU.

To use the Dilithium command, you must first build wolfSSL with the appropriate configuration options: `–enable-wolfclu` and `–enable-dilithium`.

Building wolfSSL:

$ cd wolfssl
$ ./autogen.sh
$ ./configurte –enable-wolfclu –enable-dilithium
$ make && make check
$ sudo make install

Once wolfSSL is built and installed, you can build wolfCLU. No additional macros are required for this step. After installing, you can check wolfssl command version.

Building wolfCLU:

$ cd wolfclu
$ ./autogen.sh
$ ./configure
$ make && make check
$ sudo make install
$ wolfssl -v

Key Generation:

To generate a Dilithium key pair, use the “-genkey” command. Dilithium supports different security levels (2, 3, and 5) as defined by NIST. You can specify the security level using “-level” and the output filename using “-out”.

$ wolfssl -genkey dilithium -level 2 -out dilithium_key -outform der -output keypair

Sign:

To sign a file with the Dilithium private key, use the “-sign” command. Specify the private key with “-inkey”, the file to be signed with “-in”, and the output signature file with “-out”.

$ wolfssl dilithium -sign -inkey dilithium_key.priv -inform der -in test.txt -out signature.sig

Verify:

To verify a signed file, use the “-verify” command. Provide the public key using “-inkey”, the file to verify with “-in”, and the signature file with “-sigfile”. If the signature is valid, the output will display “Valid Signature”. If not, it will display “Invalid Signature”.

$ wolfssl dilithium -verify -inkey dilithium_key.pub -inform der -in test.txt -sigfile signature.sig

With these steps, you can easily generate keys, sign files and verify signatures using the Dilithium command in wolfCLU.

If you have questions about any of the above, please contact us at facts@wolfSSL.com or +1 425 245 8247.

Download wolfSSL Now

Renesas RX TSIP with ECDSA and Crypto Callbacks

wolfSSL now has support for Renesas RX TSIP with ECDSA and crypto callbacks. This update provides broader flexibility and security for embedded systems with Renesas RX TSIP. Below is a summary of the key changes and updates that were added in PR# 7685:

Key Changes and Features

  1. Renesas RX TSIP with ECDSA Support
    WolfSSL now fully supports ECDSA on Renesas RX TSIP, which adds greater functionality when generating signatures. The update also adds support for raw R+S signatures.
  2. ECC with NO_ASN
    You can now use ECC support without ASN.1 encoding by using the configuration:
    ‘./configure –enable-cryptonly –disable-rsa –disable-asn –disable-examples’
    This can decrease the overhead in environments where you don’t need ASN.1 support.
  3. RX TSIP Crypt Configuration Fixes
    These changes also fixes issues with WOLFSSL_RENESAS_TSIP_CRYPTONLY and NO_WOLFSSL_RENESAS_TSIP_CRYPT_HASH macros, allowing for builds to complete smoothly when there is only a requirement for cryptography operations.
  4. Reverted wc_GenerateSeed Support
    wc_GenerateSeed on the RX TSIP was reverted. This ensures compatibility with the updated RNG on RX TSIP.
  5. Updated Client Authentication Key Data
    Example key data with private key for client authentication has been updated.

Testing

These changes were tested using the e2Studio IDE, and tests were verified including client and server examples.

Conclusion

These updates extend wolfSSL’s support of the Renesas RX TSIP to include ECDSA and Raw R+S signature support, greatly improving flexibility and optimizing the build for embedded systems. If you have questions about any of the above, please contact us at facts@wolfSSL.com or +1 425 245 8247.

Download wolfSSL Now

wolfSSL Enhances PowerPC Support on Darwin

At wolfSSL, we are committed to supporting a wide range of platforms and architectures, ensuring that our SSL/TLS library can be used across various environments. One of the platforms we continue to support is PowerPC, both in 32-bit and 64-bit configurations.

The latest updates to our PowerPC support primarily focus on resolving compatibility issues with Darwin (macOS) systems. The recent changes in the pull request https://github.com/wolfSSL/wolfssl/pull/7931 do not introduce any new features or modify existing functionality. These updates include:

  • PowerPC Macros: Adjustments ensure compatibility with Darwin, allowing smooth builds on macOS.
  • Assembler Compatibility: We’ve addressed issues with how registers are prefixed in the Darwin ABI ensuring compatibility with PowerPC systems.

Instead of adding register prefixes via a simple macro, we’ve opted for a more robust approach. This helps prevent potential issues in the future.

If you have questions about any of the above, please contact us at facts@wolfSSL.com or +1 425 245 8247.

Download wolfSSL Now

Extended Key Update for Transport Layer Security (TLS) 1.3

The Extended Key Update extension for (D)TLS 1.3 is a draft proposal for a new key update mechanism. (D)TLS 1.3 lacks perfect forward secrecy (PFS) for long-lived sessions, leaving them vulnerable to key exfiltration attacks. The proposed Extended Key Update mechanism addresses this by incorporating minimal key exchanges during key updates. This safeguards connections by ensuring that even if session keys are compromised, past and future communications remain confidential.

This extension is ideal for environments where long uninterrupted secure connections are critical. By introducing PFS into key updates without requiring establishing new connections, it enhances security while maintaining availability. Its design also supports hybrid key exchanges, ensuring post-quantum readiness with a fallback to classical cryptography.

wolfSSL strives to provide the best security, and that is why we monitor new developments closely. If this extension is a feature you would be interested in, please write to us at facts@wolfSSL.com or call us at +1 425 245 8247.

Download wolfSSL Now

wolfSSL DTLS 1.2 Connection ID

wolfSSL release 5.7.4 includes an exciting new feature. We have implemented Connection ID (CID) support for DTLS 1.2 (RFC 9146). CID is a new feature in DTLS 1.2 that allows for better handling of connection migration. Without it, DTLS connections are tied to the IP 5-tuple making it unable to recover the connection if one of the peers changes their address. This is where CID comes in. This feature is used to associate DTLS records from a new IP address to an existing connection. This is especially useful for mobile devices that may switch between Wi-Fi and cellular networks, or for any device that may change IP addresses during a connection.

Using CID’s in wolfSSL is easy. Just setup your connection as usual, but call wolfSSL_dtls_cid_use() to enable the CID feature on the connection. This will enable the CID on your side of the connection. To request the peer to use a CID, use wolfSSL_dtls_cid_set().

If you have any questions regarding CID’s in DTLS 1.2 or 1.3, please contact us at facts@wolfssl.com or +1 425 245 8247.

Download wolfSSL Now

wolfSSL libspdm Support

wolfSSL has added support for libspdm 3.3.0. libspdm is the reference implementation of the DMTF’s Security Protocols and Data Models (SPDM specifications). The goal of the SPDM specifications is to provide device attestation and authentication as well as secure communication over any transport. Both wolfSSL and SPDM are designed to operate on any transport.

Our wolfCrypt library is the underlying cryptographic library used by wolfSSL. wolfCrypt is a lightweight, embeddable, and easy-to-configure crypto library. It supports all the algorithms used by SPDM such as AES, CHACHA, POLY-1305, SHA-3, RSA, ECC. wolfCrypt is FIPS 140-3 validated and is available under both open source and commercial licenses. wolfCrypt also supports the Chinese SM ciphers SM2, SM3, and SM4.

If you have questions about the libspdm port or any other port, please contact us at facts@wolfSSL.com or +1 425 245 8247.

Download wolfSSL Now

AI-automated fuzz testing uncovered a vulnerability in wolfSSL

Code Intelligence is happy to announce the discovery of a heap-based use-after-free vulnerability in wolfSSL, identified through a fuzz test automatically generated by an AI Test Agent. This marks another milestone in advancing automated security testing and demonstrates the power of AI-driven tools to improve software reliability and safety.

Discovery and Resolution

The vulnerability was identified during the final week of October 2024.

Remarkably, the discovery required no manual intervention—beyond setting up the project and typing “cifuzz spark” into the command line. This fuzz test, automatically generated and executed by Spark, the AI Test Agent, uncovered the critical data that exposed the flaw.

Spark, the AI Test Agent, is an enhancement to ?ode Intelligence’s fuzz testing product CI Fuzz. Leveraging LLMs and advanced static analysis, it autonomously identifies the most critical functions in the codebase to fuzz, generates and runs fuzz tests, and thus, finds bugs and vulnerabilities.

Spark will be publicly demonstrated to the security and software development community on January 28, 2025. Secure your free spot here.

Spark uncovered the vulnerability in wolfSSL during its final beta testing. Code Intelligence reported the issue to the wolfSSL team immediately, and they responded with exceptional efficiency, resolving the vulnerability within 3 days.

The fix was officially included in release wolfSSL 5.7.6 on 31 December 2024.

In the only manual step, Peter Samarin from Code Intelligence has assessed and confirmed that the vulnerability exists and is exploitable under specific conditions.

We encourage developers to update to the latest version of wolfSSL to mitigate any potential risks.

What Is a Heap-Based Use-After-Free?

A heap-based use-after-free vulnerability occurs when a program continues to access memory on the heap after it has been freed.

In a typical scenario, a program allocates memory, uses it, and then frees it. However, if there is a mistake in memory management, such as a dangling pointer, a subsequent access attempt may interact with memory that has already been reallocated for another use.

This can lead to unexpected behavior, crashes, or—more worryingly—security exploits that allow attackers to execute arbitrary code or manipulate program behavior maliciously.

We are grateful to the Code Intelligence team for uncovering and reporting the vulnerability to us. You can explore the technical details of the issue in Code Intelligence’s blog post.

If you have questions about any of the above, please contact us at facts@wolfSSL.com or +1 425 245 8247.

Download wolfSSL Now

wolfSSL SSSD Support

We have ported the System Security Services Daemon (SSSD) to use wolfSSL for its SSL/TLS support. SSSD provides a set of daemons that allow access to identity and authentication providers. SSSD is used to connect to remote directories and authentication mechanisms such as LDAP, Kerberos, or FreeIPA. The wolfSSL SSSD port allows organizations to leverage the performance and size advantages of wolfSSL for their SSSD deployments.

wolfSSL is a lightweight and portable SSL/TLS library written in C. It supports industry standards up to the current TLS 1.3 and DTLS 1.3 levels, is far smaller than OpenSSL, offers a simple API, an OpenSSL compatibility layer, and includes FIPS 140-3 validated cryptography. By integrating wolfSSL with SSSD, organizations can benefit from enhanced performance, reduced memory footprint, and robust security features, making it an ideal choice for secure identity and authentication services.

The patch and installation instructions for SSSD are available here. If you have any questions regarding this or any other port, please contact us at facts@wolfssl.com or +1 425 245 8247.

Download wolfSSL Now

wolfSSL Support for STM32G4

wolfSSL now has support for STM32G4 microcontrollers. With new features that enable better performance and flexibility for cryptographic operations on STM32G4 hardware. Below is a summary of the key changes and updates that were made in PR #7997:

Key Changes and Features

  1. User Settings Synchronization:
    The `user_settings_stm32.h` configuration file has been synchronized with the STM32Cube IDE’s `default_conf.ftl`. This ensures that the configurations are up to date and consistent with the STM32G4 environment.
  2. New Configuration Options:
    WOLF_CONF_IO: This option allows the user to select the network stack to use.
    Options include:

    • 1 = User IO (custom)
    • 2 = LWIP (POSIX)
    • 3 = LWIP (native )

    WOLF_CONF_RESUMPTION: This option controls session caching and session ticket functionality.

    • 0 = No session cache
    • 1 = Session cache / Session tickets

    WOLF_CONF_TPM: Enables TPM support, which adds Crypto Callbacks, Public MP, and AES CFB support.
    WOLF_CONF_PK: TLS Key Callbacks fir better key management in cryptographic operations.
    WOLF_CONF_AESGCM: Support for AES GCM encryption modes with:

    • 1 = GCM_SMALL
    • 2 = GCM_TABLE_4BIT

Testing

The code was compiled in STM32CubeIDE for STM32G491x, but no hardware was available for testing at the time. Tests have been run with essential hardware features, including:

  • – RTC
  • – RNG
  • – LPUART1
  • – ARM ASM

Conclusion

wolfSSL now supports STM32G4 microcontrollers, which has custom IO, session caching, TPM support, and AES GCM support. If you have any further questions about any of the above, please contact us at facts@wolfSSL.com or +1 425 245 8247.

Download wolfSSL Now

Posts navigation

1 2 3 4 5 6 … 193 194 195