What’s the difference between TPM 2.0, PKCS#11 and PSA?
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.
Download wolfSSL Now
wolfTPM: support for pre-provisioned device identity key and certificate
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.
If you have questions about any of the above, please contact us at facts@wolfSSL.com or call us at +1 425 245 8247.
Download wolfSSL Now
Join Our Live Webinar: wolfEngine vs. wolfProvider: Discover Solutions for OpenSSL Compatibility
Watch our webinar, “wolfEngine vs. wolfProvider: Discover Solutions for OpenSSL Compatibility” today. This webinar is presented by wolfSSL Senior Software Developer Anthony Hu.
Check it out here: wolfEngine vs. wolfProvider: Discover Solutions for OpenSSL Compatibility
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.
Download wolfSSL Now
wolfSSL on the Espressif ESP8266 – Better than ever!
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.
Get Started with wolfSSL
Additional information on getting Started with wolfSSL on the Espressif environment is available on the wolfSSL GitHub repository as well as this YouTube recording:
Benchmark metrics for the ESP8266, compiler optimization for size (-oS):
Chip is ESP8266 (revision v1), Crystal is 26MHz, cpu freq: 160000000 Hz (160MHz)
I (59) boot: ESP-IDF v3.4 2nd stage bootloader I (59) boot: compile time 13:01:06 I (68) qio_mode: Enabling default flash chip QIO I (68) boot: SPI Speed : 40MHz I (72) boot: SPI Mode : QIO I (78) boot: SPI Flash Size : 2MB I (84) boot: Partition Table: I (89) boot: ## Label Usage Type ST Offset Length I (101) boot: 0 nvs WiFi data 01 02 00009000 00006000 I (112) boot: 1 phy_init RF data 01 01 0000f000 00001000 I (124) boot: 2 factory factory app 00 00 00010000 000f0000 I (136) boot: End of partition table I (142) esp_image: segment 0: paddr=0x00010010 vaddr=0x40210010 size=0x40874 (264308) map I (227) esp_image: segment 1: paddr=0x0005088c vaddr=0x40250884 size=0x13cd4 ( 81108) map I (250) esp_image: segment 2: paddr=0x00064568 vaddr=0x3ffe8000 size=0x004d0 ( 1232) load I (251) esp_image: segment 3: paddr=0x00064a40 vaddr=0x40100000 size=0x00080 ( 128) load I (262) esp_image: segment 4: paddr=0x00064ac8 vaddr=0x40100080 size=0x045a8 ( 17832) load I (279) boot: Loaded app from partition at offset 0x10000 I (299) main: This is ESP8266 chip with 1 CPU cores, WiFi, I (301) main: silicon revision 1, I (303) main: 2MB external flash wolfCrypt Benchmark (block bytes 1024, min 1.0 sec each) RNG 575 KiB took 1.022 seconds, 562.622 KiB/s Cycles per byte = 1.57 AES-128-CBC-enc 125 KiB took 1.247 seconds, 100.241 KiB/s Cycles per byte = 17.25 AES-128-CBC-dec 250 KiB took 1.089 seconds, 229.568 KiB/s Cycles per byte = 12.82 AES-192-CBC-enc 100 KiB took 1.087 seconds, 91.996 KiB/s Cycles per byte = 42.30 AES-192-CBC-dec 225 KiB took 1.019 seconds, 220.805 KiB/s Cycles per byte = 23.32 AES-256-CBC-enc 100 KiB took 1.189 seconds, 84.104 KiB/s Cycles per byte = 64.92 AES-256-CBC-dec 225 KiB took 1.075 seconds, 209.302 KiB/s Cycles per byte = 33.33 AES-128-GCM-enc 75 KiB took 1.001 seconds, 74.925 KiB/s Cycles per byte = 113.90 AES-128-GCM-dec 75 KiB took 1.001 seconds, 74.925 KiB/s Cycles per byte = 126.15 AES-192-GCM-enc 75 KiB took 1.053 seconds, 71.225 KiB/s Cycles per byte = 139.33 AES-192-GCM-dec 75 KiB took 1.053 seconds, 71.225 KiB/s Cycles per byte = 153.21 AES-256-GCM-enc 75 KiB took 1.137 seconds, 65.963 KiB/s Cycles per byte = 168.58 AES-256-GCM-dec 75 KiB took 1.137 seconds, 65.963 KiB/s Cycles per byte = 183.13 GMAC Default 342 KiB took 1.001 seconds, 341.658 KiB/s Cycles per byte = 43.08 3DES 200 KiB took 1.115 seconds, 179.372 KiB/s Cycles per byte = 79.45 MD5 5225 KiB took 1.000 seconds, 5225.000 KiB/s Cycles per byte = 3.22 SHA 2300 KiB took 1.000 seconds, 2300.000 KiB/s Cycles per byte = 7.76 SHA-224 1475 KiB took 1.009 seconds, 1461.843 KiB/s Cycles per byte = 12.71 SHA-256 1475 KiB took 1.008 seconds, 1463.294 KiB/s Cycles per byte = 13.40 SHA-384 475 KiB took 1.014 seconds, 468.442 KiB/s Cycles per byte = 43.79 SHA-512 475 KiB took 1.012 seconds, 469.368 KiB/s Cycles per byte = 45.90 SHA-512/224 475 KiB took 1.012 seconds, 469.368 KiB/s Cycles per byte = 47.99 SHA-512/256 475 KiB took 1.013 seconds, 468.904 KiB/s Cycles per byte = 50.12 SHA3-224 1250 KiB took 1.018 seconds, 1227.898 KiB/s Cycles per byte = 19.77 SHA3-256 1175 KiB took 1.003 seconds, 1171.486 KiB/s Cycles per byte = 21.96 SHA3-384 925 KiB took 1.021 seconds, 905.975 KiB/s Cycles per byte = 28.84 SHA3-512 650 KiB took 1.024 seconds, 634.766 KiB/s Cycles per byte = 42.68 SHAKE128 1450 KiB took 1.011 seconds, 1434.224 KiB/s Cycles per byte = 19.80 SHAKE256 1175 KiB took 1.002 seconds, 1172.655 KiB/s Cycles per byte = 25.22 RIPEMD 4375 KiB took 1.002 seconds, 4366.267 KiB/s Cycles per byte = 7.01 HMAC-MD5 5175 KiB took 1.002 seconds, 5164.671 KiB/s Cycles per byte = 6.11 HMAC-SHA 2325 KiB took 1.009 seconds, 2304.262 KiB/s Cycles per byte = 14.05 HMAC-SHA224 1475 KiB took 1.017 seconds, 1450.344 KiB/s Cycles per byte = 22.83 HMAC-SHA256 1475 KiB took 1.017 seconds, 1450.344 KiB/s Cycles per byte = 23.46 HMAC-SHA384 475 KiB took 1.049 seconds, 452.812 KiB/s Cycles per byte = 74.96 HMAC-SHA512 475 KiB took 1.048 seconds, 453.244 KiB/s Cycles per byte = 77.12 PBKDF2 0 KiB took 1.077 seconds, 0.174 KiB/s Cycles per byte = 201056.28 RSA 1024 key gen 1 ops took 65.685 sec, avg 65685.000 ms, 0.015 ops/sec RSA 2048 key gen 1 ops took 77.480 sec, avg 77480.000 ms, 0.013 ops/sec RSA 2048 public 10 ops took 1.035 sec, avg 103.500 ms, 9.662 ops/sec RSA 2048 private 2 ops took 44.756 sec, avg 22378.000 ms, 0.045 ops/sec ECC [ SECP256R1] 256 key gen 2 ops took 1.662 sec, avg 831.000 ms, 1.203 ops/sec ECDHE [ SECP256R1] 256 agree 2 ops took 1.668 sec, avg 834.000 ms, 1.199 ops/sec ECDSA [ SECP256R1] 256 sign 2 ops took 1.688 sec, avg 844.000 ms, 1.185 ops/sec ECDSA [ SECP256R1] 256 verify 2 ops took 3.212 sec, avg 1606.000 ms, 0.623 ops/sec CURVE 25519 key gen 2 ops took 1.785 sec, avg 892.500 ms, 1.120 ops/sec CURVE 25519 agree 2 ops took 1.326 sec, avg 663.000 ms, 1.508 ops/sec ED 25519 key gen 15 ops took 1.009 sec, avg 67.267 ms, 14.866 ops/sec ED 25519 sign 14 ops took 1.008 sec, avg 72.000 ms, 13.889 ops/sec ED 25519 verify 6 ops took 1.140 sec, avg 190.000 ms, 5.263 ops/sec Benchmark complete
Benchmark metrics for the ESP8266, No Compiler Optimization (debug -Og):
Chip is ESP8266 (revision v1), Crystal is 26MHz, cpu freq: 160000000 Hz (160MHz)
I (60) boot: ESP-IDF v3.4 2nd stage bootloader I (60) boot: compile time 14:00:00 I (69) qio_mode: Enabling default flash chip QIO I (69) boot: SPI Speed : 40MHz I (73) boot: SPI Mode : QIO I (79) boot: SPI Flash Size : 2MB I (85) boot: Partition Table: I (91) boot: ## Label Usage Type ST Offset Length I (102) boot: 0 nvs WiFi data 01 02 00009000 00006000 I (114) boot: 1 phy_init RF data 01 01 0000f000 00001000 I (125) boot: 2 factory factory app 00 00 00010000 000f0000 I (137) boot: End of partition table I (143) esp_image: segment 0: paddr=0x00010010 vaddr=0x40210010 size=0x46e48 (290376) map I (255) esp_image: segment 1: paddr=0x00056e60 vaddr=0x40256e58 size=0x14560 ( 83296) map I (284) esp_image: segment 2: paddr=0x0006b3c8 vaddr=0x3ffe8000 size=0x004dc ( 1244) load I (285) esp_image: segment 3: paddr=0x0006b8ac vaddr=0x40100000 size=0x00080 ( 128) load I (296) esp_image: segment 4: paddr=0x0006b934 vaddr=0x40100080 size=0x046a4 ( 18084) load I (315) boot: Loaded app from partition at offset 0x10000 I (334) main: This is ESP8266 chip with 1 CPU cores, WiFi, I (337) main: silicon revision 1, I (339) main: 2MB external flash wolfCrypt Benchmark (block bytes 1024, min 1.0 sec each) RNG 375 KiB took 1.019 seconds, 368.008 KiB/s Cycles per byte = 2.74 AES-128-CBC-enc 75 KiB took 1.168 seconds, 64.212 KiB/s Cycles per byte = 27.59 AES-128-CBC-dec 475 KiB took 1.045 seconds, 454.545 KiB/s Cycles per byte = 6.43 AES-192-CBC-enc 75 KiB took 1.272 seconds, 58.962 KiB/s Cycles per byte = 57.19 AES-192-CBC-dec 425 KiB took 1.007 seconds, 422.046 KiB/s Cycles per byte = 12.70 AES-256-CBC-enc 75 KiB took 1.362 seconds, 55.066 KiB/s Cycles per byte = 88.98 AES-256-CBC-dec 400 KiB took 1.053 seconds, 379.867 KiB/s Cycles per byte = 19.31 AES-128-GCM-enc 75 KiB took 1.440 seconds, 52.083 KiB/s Cycles per byte = 121.83 AES-128-GCM-dec 75 KiB took 1.440 seconds, 52.083 KiB/s Cycles per byte = 141.40 AES-192-GCM-enc 50 KiB took 1.026 seconds, 48.733 KiB/s Cycles per byte = 230.32 AES-192-GCM-dec 50 KiB took 1.026 seconds, 48.733 KiB/s Cycles per byte = 249.89 AES-256-GCM-enc 50 KiB took 1.076 seconds, 46.468 KiB/s Cycles per byte = 273.47 AES-256-GCM-dec 50 KiB took 1.076 seconds, 46.468 KiB/s Cycles per byte = 294.31 GMAC Default 247 KiB took 1.003 seconds, 246.261 KiB/s Cycles per byte = 63.60 3DES 175 KiB took 1.121 seconds, 156.111 KiB/s Cycles per byte = 95.82 MD5 1100 KiB took 1.008 seconds, 1091.270 KiB/s Cycles per byte = 16.18 SHA 3900 KiB took 1.000 seconds, 3900.000 KiB/s Cycles per byte = 4.82 SHA-224 925 KiB took 1.007 seconds, 918.570 KiB/s Cycles per byte = 21.27 SHA-256 925 KiB took 1.002 seconds, 923.154 KiB/s Cycles per byte = 22.43 SHA-384 850 KiB took 1.009 seconds, 842.418 KiB/s Cycles per byte = 25.58 SHA-512 850 KiB took 1.007 seconds, 844.091 KiB/s Cycles per byte = 26.63 SHA-512/224 850 KiB took 1.004 seconds, 846.614 KiB/s Cycles per byte = 27.75 SHA-512/256 850 KiB took 1.008 seconds, 843.254 KiB/s Cycles per byte = 28.90 SHA3-224 700 KiB took 1.000 seconds, 700.000 KiB/s Cycles per byte = 36.47 SHA3-256 675 KiB took 1.021 seconds, 661.117 KiB/s Cycles per byte = 39.45 SHA3-384 525 KiB took 1.035 seconds, 507.246 KiB/s Cycles per byte = 52.72 SHA3-512 375 KiB took 1.048 seconds, 357.824 KiB/s Cycles per byte = 76.24 SHAKE128 800 KiB took 1.001 seconds, 799.201 KiB/s Cycles per byte = 37.12 SHAKE256 675 KiB took 1.031 seconds, 654.704 KiB/s Cycles per byte = 45.49 RIPEMD 4300 KiB took 1.002 seconds, 4291.417 KiB/s Cycles per byte = 7.35 HMAC-MD5 1100 KiB took 1.017 seconds, 1081.613 KiB/s Cycles per byte = 29.67 HMAC-SHA 4100 KiB took 1.004 seconds, 4083.665 KiB/s Cycles per byte = 8.20 HMAC-SHA224 925 KiB took 1.021 seconds, 905.975 KiB/s Cycles per byte = 37.38 HMAC-SHA256 925 KiB took 1.016 seconds, 910.433 KiB/s Cycles per byte = 38.53 HMAC-SHA384 825 KiB took 1.002 seconds, 823.353 KiB/s Cycles per byte = 44.42 HMAC-SHA512 850 KiB took 1.024 seconds, 830.078 KiB/s Cycles per byte = 44.23 PBKDF2 0 KiB took 1.283 seconds, 0.097 KiB/s Cycles per byte = 311171.78 RSA 1024 key gen 1 ops took 28.932 sec, avg 28932.000 ms, 0.035 ops/sec RSA 2048 key gen 1 ops took 382.088 sec, avg 382088.000 ms, 0.003 ops/sec RSA 2048 public 12 ops took 1.130 sec, avg 94.167 ms, 10.619 ops/sec RSA 2048 private 2 ops took 39.968 sec, avg 19984.000 ms, 0.050 ops/sec ECC [ SECP256R1] 256 key gen 2 ops took 1.591 sec, avg 795.500 ms, 1.257 ops/sec ECDHE [ SECP256R1] 256 agree 2 ops took 1.597 sec, avg 798.500 ms, 1.252 ops/sec ECDSA [ SECP256R1] 256 sign 2 ops took 1.619 sec, avg 809.500 ms, 1.235 ops/sec ECDSA [ SECP256R1] 256 verify 2 ops took 3.093 sec, avg 1546.500 ms, 0.647 ops/sec CURVE 25519 key gen 2 ops took 1.988 sec, avg 994.000 ms, 1.006 ops/sec CURVE 25519 agree 2 ops took 1.529 sec, avg 764.500 ms, 1.308 ops/sec ED 25519 key gen 17 ops took 1.038 sec, avg 61.059 ms, 16.378 ops/sec ED 25519 sign 16 ops took 1.041 sec, avg 65.062 ms, 15.370 ops/sec ED 25519 verify 6 ops took 1.334 sec, avg 222.333 ms, 4.498 ops/sec Benchmark complete
Questions?
If you have questions about any of the above, please contact us at facts@wolfSSL.com or call us at +1 425 245 8247.
Download wolfSSL Now
CNSA 2.0 Update Part 5: PSK
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.
If you have questions about any of the above, please contact us at facts@wolfSSL.com or call us at +1 425 245 8247.
Download wolfSSL Now
Join Our Live Webinar: wolfHSM Design for Automotive Hardware Security Modules
You are invited to register for our upcoming webinar “wolfHSM Design for Automotive Hardware Security Modules” on May 30th at 10am PT. This webinar is presented by wolfSSL Software Engineer, Bill Phipps.
Watch the webinar here : wolfHSM Design for Automotive Hardware Security Modules
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.
Download wolfSSL Now
CNSA 2.0 Update Part 4: Deployment
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!
If you have questions about any of the above, please contact us at facts@wolfSSL.com or call us at +1 425 245 8247.
Check out CNSA 2.0 Update Part 5: PSK.
Download wolfSSL Now
CNSA 2.0 Update Part 3: LMS and XMSS
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:
- NSS: National Security System
- NIST SP 800-208 National Institute of Standard and Technology Special Publication 800-208 titled: Recommendation for Stateful Hash-Based Signature Schemes
- 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.
Check out CNSA 2.0 Update Part 4: Deployment.
Download wolfSSL Now
Join Our Live Webinar: wolfHSM Design for Automotive Hardware Security Modules
You are invited to register for our upcoming webinar “wolfHSM Design for Automotive Hardware Security Modules” on May 30th at 10am PT. This webinar is presented by wolfSSL Software Engineer, Bill Phipps.
Watch the webinar here: wolfHSM Design for Automotive Hardware Security Modules
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.
Download wolfSSL Now
CNSA 2.0 Update Part 2: NIAP
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:
- NIST SP 800-208 National Institute of Standard and Technology Special Publication 800-208 titled: Recommendation for Stateful Hash-Based Signature Schemes
- 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.
Check out CNSA 2.0 Update Part 3: LMS and XMSS.
Download wolfSSL Now