In a well-designed modular system there is a dedicated component that performs cryptographic operations. It can be a discrete physical chip, a software library or a mix. Whenever a system component needs a cryptographic operation like hashing, signature verification, encryption, key creation, etc. it delegates the operation to the “cryptographic provider”.
But how to interact with the cryptographic provider?
Ideally, with a (good) standardized application programming interface (API). Having a common interface for cryptographic providers has several advantages: the provider becomes interchangeable, the software is more maintainable and easier to audit, and as a consequence, it’s safer. Unfortunately, designing a good API is an overwhelming task: the abstraction has to be clean and easy to use and read, but at the same time flexible and secure.
Public Key Cryptographic Standard 11 (PKCS#11) and Platform Security Architecture (PSA) Crypto API specifications try to accomplish this daunting task: defining a common API for cryptographic providers.
What about Trusted Platform Module (TPM) 2.0?
The TPM2.0 is aimed at a specific category of cryptographic devices, quoting from the TPM 2.0 specification: “…a device that enables trust in computing platforms in general”. A TPM is a device that, besides normal cryptographic functions, provides the necessary foundation to enable device identification and overall system integrity reporting. Very early stages of software typically use it in a platform to establish a Root of Trust and allow secure boot and remote attestation features. So while PSA and PKCS#11 both define only an API to access cryptographic providers, TPM2.0 has a much larger scope, as it defines the system architecture to achieve the “trust” of the platform alongside the interface with the TPM device. Moreover, the interface to the TPM is described in terms of commands and responses that a compliant TPM device will understand, unlike PKCS#11 and PSA where the interface is described using C function prototypes and data structure.
But even if PKCS#11 and PSA are both C-based, they show several differences in how they model the cryptographic operations and the terminology used. As an example, PKCS#11 uses a hierarchical sophisticated object model to represent keys, algorithms (called mechanisms), devices (called tokens), etc, while PSA Crypto aims for a more flat and simpler model, where algorithms and keys are just a typedef of an integer type.
wolfSSL support for TPM2.0, PKCS#11 and PSA
Regarding TPM 2.0, wolfTPM library abstracts away the details of the communication with the device and exposes a 1:1 mapping of the TPM commands defined in the specification, plus wrappers that hide away the complexity of using the commands directly.
For PKCS#11 and PSA Crypto API wolfSSL can both expose its functionality using the defined interface and consume cryptographic functions from a provider of the interface.
This not only means that wolfSSL can use cryptographic providers that expose one of the three interfaces, not only that wolfSSL can be used by any software that uses one of the three interfaces, but that wolfSSL can also act as a sort of polyglot translator between software components!
You can refer to here as an example of this, where an application can use wolfPKCS11 to talk with a TPM, thanks to wolfCrypt using wolfTPM to talk with the latter. I report here a diagram of the article as a reference:
So no matter what interfaces you need, wolfSSL has you covered! Do you need more info about a specific use-case? Do you have any suggestions? or if you have questions about any of the above, feel free to drop a line at facts@wolfSSL.com or call us at +1 425 245 8247.
wolfTPM v3.2.0 is here, and among the new features is support for pre-provisioned device identity keys and certificates for the ST33, following the specification of the Trusted Computing Group’s TPM 2.0 Keys for Device Identity and Attestation. This feature allows you to read pre-provisioned certificates and keys that are tied to the device’s identity, which can then be used for TLS mutual authentication, for example. We’ve updated our tls_client example to show an example of this, and you can read more about it in our PR here if you’re curious about the details.
Anthony will delve into the differences between wolfEngine and wolfProvider and guide you on which product is suitable for your use cases. Both wolfEngine and wolfProvider offer the best solutions for achieving FIPS compatibility in a timely manner for OpenSSL users.
You can expect to learn about:
Optimal alternatives: OpenSSL compat layer
Understanding the OpenSSL 1.0.2, 1.1.1, and 3.x.y branch releases
Determining suitable branches for engines and providers
Utilizing wolfEngine and wolfProvider with the openssl app
Integrating wolfEngine and wolfProvider with the OpenSSL API
Available algorithms and cryptographic primitives
Insights on FIPS compatibility
Don’t miss this opportunity to deepen your understanding of how wolfEngine and wolfProvider can efficiently meet the OpenSSL requirements. Anthony will showcase how wolfEngine and wolfProvider act as connectors between OpenSSL and wolfCrypt FIPS, saving you time and effort. Don’t miss this opportunity to deepen your understanding of how wolfEngine and wolfProvider can efficiently meet the OpenSSL requirements. Anthony will showcase how wolfEngine and wolfProvider act as connectors between OpenSSL and wolfCrypt FIPS, saving you time and effort. Watch it now!
As always, our webinars will include Q&A sessions throughout. If you have questions about any of the above, please contact us at facts@wolfSSL.com or call us at +1 425 245 8247.
It may not be as glamorous as the new ESP32 RISC-V chipsets with all the various hardware acceleration capabilities, but the ESP8266 is a well established device which has a large codebase available with an even larger user community.
Due to high customer demand, we’ve enhanced the wolfSSL libraries for the ESP8266. The recent changes have improved both the ESP-IDF CMake and traditional Makefile builds. This new capability allows for specification of the wolfSSL component source code as an alternative to using the setup script to copy everything locally.
For make, set the WOLFSSL_ROOT value in components/wolfssl/component.mk
For cmake, there are more options:
Set the WOLFSSL_ROOT value in components/wolfssl/CMakeLists.txt
Set the WOLFSSL_ROOT environment variable.
Have the components/wolfssl/CMakeLists.txt as a subdirectory in wolfSSL.
When a project is in a subdirectory of wolfSSL, the cmake file will search parent directories, up to the root, looking for wolfSSL.
The ability to specify the wolfSSL component source code ensures consistent versioning across projects and facilitates easy updates via GitHub.
You may have seen our recent announcement regarding wolfCrypt hardware acceleration for the ESP32 series. There’s no such capability on the ESP8266. However, there’s still a noticeable difference between debug and release optimizations, as shown at the end of this blog.
Once the Espressif ESP8266 RTOS SDK is installed, it is easy to get the wolfSSL examples working (see the README for more details):
# Set your path to RTOS SDK,
# shown here for default from WSL with VisualGDB
WRK_IDF_PATH=/mnt/c/SysGCC/esp8266/rtos-sdk/v3.4
# or
WRK_IDF_PATH=~/esp/ESP8266_RTOS_SDK
# Setup the environment
. $WRK_IDF_PATH/export.sh
# Optional: install as needed / prompted
# /mnt/c/SysGCC/esp8266/rtos-sdk/v3.4/install.sh
# Fetch wolfssl from GitHub if needed:
cd /workspace
git clone https://github.com/wolfSSL/wolfssl.git
# change directory to wolfssl client example.
cd wolfssl/IDE/Espressif/ESP-IDF/examples/wolfssl_client
# Adjust settings as desired
# Set IP address and wifi SSID name & password
idf.py menuconfig
# Build, flash and monitor
idf.py build flash -p /dev/ttyS70 -b 115200
idf.py monitor -p /dev/ttyS70 -b 74880
Are you interested in using the ESP8266 or ESP32 in your next project? Let us know! We love to hear about how wolfSSL is being used, and can optionally help promote your project on social media, with your approval.
On April 18th, 2024, the NSA released updates and clarifications to their CNSA 2.0 (Commercial National Security Algorithm Suite 2.0) advisory in the form of an FAQ. This is the fifth and final in a series of postings about the questions and answers that we feel are most interesting and our reactions to them.
Q: Can I mitigate the quantum threat by using a pre-shared key?
A: Many commercial protocols allow a pre-shared key option that may mitigate the quantum threat, and some allow the combination of pre-shared and asymmetric keys in the same negotiation. However, this issue can be complex. Customers who wish to explore this option should contact NSA or follow guidance the CSfC program provides.
This is great news for our customers as this means they can enable our PSK (pre-shared key) support in wolfSSL and start their post-quantum journey today! If you’re using Sneakernet (avoiding network transmission) then you’re golden! The knowledge of the pre-shared key takes care of both authentication and key establishment so there is no need for public key cryptography and therefore thwarts Shor’s algorithm.
That said, the NSA is correct, this issue is complicated. Here are just a few points to think about:
How is the key shared? If it was sent over a data connection that was negotiated with non-quantum-safe algorithms, then this is not considered mitigating the quantum threat.
How is the key generated? If it was done using an entropy source and/or PRNG (Pseudo-Random Number Generator) that is not approved then you are going to run into problems.
Do you require PFS (Perfect Forward Secrecy)? Then you might have to think about how you’re going to achieve that very carefully.
How are you storing and protecting the pre-shared keys? If your efforts to protect it are insufficient then you leave yourself vulnerable to other attack vectors.
Let our experts help you sort out these details. Get started on your journey into a world with quantum computers by downloading wolfSSL now.
Security is paramount in the automotive industry to protect the integrity, confidentiality, and authenticity of data. Automotive HSMs (Hardware Security Modules) play a crucial role. It enhances the security of cryptographic keys and cryptographic processing.
During this webinar, Bill will explore a wide range of topics from the functionality and design of wolfHSM to its application in AUTOSAR/SHE/PKCS11, and provide a demonstration on the Infineon Aurix Tricore TC375.
You can expect to learn:
The Essentials of Hardware Security Modules
Functional design insights of wolfHSM
Application of wolfHSM in AUTOSAR, SHE, and PKCS11
Hardware porting and support strategies for wolfHSM
A demonstration using the Infineon Aurix Tricore TC375
And much more…
Watch now to learn how wolfHSM can boost your security, offering a portable and open-source abstraction to hardware cryptography, non-volatile memory, and isolated secure processing.
As always, our webinars will include Q&A sessions throughout. If you have questions on any of the above, please contact us at facts@wolfSSL.com or call us at +1 425 245 8247.
On April 18th, 2024, the NSA released updates and clarifications to their CNSA 2.0 (Commercial National Security Algorithm Suite 2.0) advisory in the form of an FAQ. This is the fourth in a multipart series of postings about the questions and answers that we feel are most interesting and our reactions to them.
Q: When should deployment of CNSA 2.0 algorithms in mission systems begin?
A: When validated products become available they should be deployed in mission systems. Meanwhile, NSA encourages responsible testing in vendor and government research environments now to understand the effects of deployment of the new algorithms on particular systems given the increased sizes used in these algorithms.
Translation: time to “get cracking” and build post-quantum cryptographic implementations you plan to use. You need to understand that while performance for Kyber/ML-KEM won’t be an issue, (see our benchmarks) artifact sizes are increasing!
If you are used to the tiny artifacts in ECDHE then this should be a real eye opener. We’re talking kilobytes going over the wire and taking up memory.
How will this affect you? First of all, if your transmission medium is slow then more bytes going over the wire during the protocol handshake will naturally increase the time to your first application data being sent. Secondly, if your current application is already memory constrained, you might need to re-evaluate how you use your memory or even increase the amount of memory available to your application.
Considering these things takes time and planning, now is the time to start. Download now!
On April 18th, 2024, the NSA released updates and clarifications to their CNSA 2.0 (Commercial National Security Algorithm Suite 2.0) advisory in the form of an FAQ. This is the third in a multipart series of postings about the questions and answers that we feel are most interesting and our reactions to them.
But first, some clarifications on terms and acronyms:
LMS: Leighton-Micali Signatures; a stateful hash-based signature scheme
HSS: Hierarchical Signature Scheme; the hyper-tree algorithm that is on top of LMS
XMSS: eXtended Merkle Signature Scheme; a stateful hash-based signature scheme
XMSS^MT: eXtended Merkle Signature Scheme – Multi-Tree; the hyper-tree algorithm that is on top of XMSS
Q: Can I use HSS or XMSSMT from NIST SP 800-208?
A: From NIST SP 800-208, NSA has only approved LMS and XMSS for use in NSS. The multitree algorithms HSS and XMSSMT are not allowed.
Essentially what this means is that only the actual stateful hash-based signature schemes are approved for usage in NSS. The hyper-tree (colloquially known as “tree of trees”) components specified in NIST SP 800-208 are not approved.
Our implementation supports the hyper-tree components with the actual stateful hash-based signature schemes. More specifically, HSS/LMS and XMSS/XMSS^MT.
It is quite simple to transform an LMS public key into an HSS/LMS public key by putting 4 bytes of zeros in front of the LMS public key. The same is true of the signature.
In addition to the hyper-tree components, we allow for XMSS by supporting the following specifications in our API:
XMSS-SHA2_10_256
XMSS-SHA2_16_256
XMSS-SHA2_20_256
Note the lack of MT.
Here at wolfSSL we are looking forward to the future of post-quantum algorithms. If you need LMS or XMSS that is performant, capable of running in bare metal environments like pre-boot, or resource constrained environments, contact us at facts@wolfSSL.com or call us at +1 425 245 8247.
Security is paramount in the automotive industry to protect the integrity, confidentiality, and authenticity of data. Automotive HSMs (Hardware Security Modules) play a crucial role. It enhances the security of cryptographic keys and cryptographic processing.
During this webinar, Bill will explore a wide range of topics from the functionality and design of wolfHSM to its application in AUTOSAR/SHE/PKCS11, and provide a demonstration on the Infineon Aurix Tricore TC375.
You can expect to learn:
The essentials of Hardware Security Modules
Functional design insights of wolfHSM
Application of wolfHSM in AUTOSAR, SHE, and PKCS11
Hardware porting and support strategies for wolfHSM
A demonstration using the Infineon Aurix Tricore TC375
And much more…
Watch now and learn how wolfHSM can boost your security, offering a portable and open-source abstraction to hardware cryptography, non-volatile memory, and isolated secure processing.
As always, our webinars will include Q&A sessions throughout. If you have questions on any of the above, please contact us at facts@wolfSSL.com or call us at +1 425 245 8247.
On April 18th, 2024, the NSA released updates and clarifications to their CNSA 2.0 (Commercial National Security Algorithm Suite 2.0) advisory in the form of an FAQ. This is the second in a multipart series of postings about the questions and answers that we feel are most interesting and our reactions to them.
But first, some clarifications on terms and acronyms:
NIAP: National Information Assurance Partnership: A United States government organization that oversees evaluations of commercial information technology products for use in national security systems
LMS: Leighton-Micali Signatures; a stateful hash-based signature scheme
XMSS: eXtended Merkle Signature Scheme; a stateful hash-based signature scheme
CAVP: The Cryptographic Algorithm Validation Program; provides guidelines for validation testing which is a pre-requisite for CMVP testing
CMVP: Cryptographic Module Validation Program; security accreditation program for cryptographic modules.
Q: As a commercial vendor, how do I know if my NIST SP 800-208 implementation meets CNSA 2.0?
A: NIAP validates products against its published Protection Profiles, which will start including quantum-resistant signatures in line with our published transition timelines. For commercial vendors, we do not anticipate NIAP Protection Profiles will perform signature generation within the Target of Evaluation (TOE) boundary, only signature verification. As signature generation is the component of LMS/XMSS that requires state management, if only signature verification is being performed, only CAVP validation (not CMVP) will be expected for such products.
Anyone who has been following wolfSSL’s progress with post-quantum algorithms knows we have our own implementations of LMS/HSS and XMSS/XMSS^MT and they are integrated into the wolfBoot product! wolfBoot only uses them to verify the signature of the firmware, therefore one only needs to build these algorithms with verification functionalities. Check out sections 17 and 20 of our wolfSSL INSTALL file.
Requiring only CAVP validation is an excellent bonus for our customers. It means that validation will be a simpler and easier process for our team to help you achieve. You can count on fast turnaround times and little if any paperwork.
Preparing for NIAP and need the best cryptography? If you have questions about any of the above, please contact us at facts@wolfSSL.com or call us at +1 425 245 8247.
