Month: May 2024

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

CNSA 2.0 Update Part 1: Today

On April 18th, 2024, the NSA released updates and clarifications to their CNSA 2.0 (Commercial National Security Algorithm Suite 2.0) advisory. They did it in the form of an FAQ document (list of Frequently Asked Questions with answers). The FAQ document was sent to the PQC Forum. This will be the first in a multipart series of postings about the questions and answers that we feel are most interesting and our reactions to them.

Q: Is there a quantum-resistant public-key algorithm that commercial vendors should adopt today?

A: NSA encourages vendors to use CNSA 2.0 approved hash-based signatures for software- and firmware-signing. NSA does not approve using pre-standardized or non-FIPS-validated CNSA 2.0 algorithms (even in hybrid modes) for NSS missions. However, NSA does recommend limited use of pre-standardized or non-FIPS-validated CNSA 2.0 algorithms and modules in research settings to prepare for the transition. NSA requests vendors begin preparing to implement CNSA 2.0 algorithms so they are primed to provide products soon after NIST completes standardization.

The NSA has spoken and they expect the industries from which they purchase to provide products that support the CNSA 2.0 Algorithm Suite upon standardization. That means DO NOT start when standardization is complete; start now.

You need to be prepared with these algorithms already integrated into your products. Here at wolfSSL we have been saying the same message for years. You need to prepare for and understand the impacts that the larger keys, cipher text and signatures are going to have on your systems. Will these larger cryptographic artifacts require more memory resources? Will they slow down your transmissions? Will the answer to those questions cascade into new requirements and trade-offs? Now is the time to find those answers. Contact us at support@wolfssl.com for benchmarking details.

If you haven’t already, go ahead and get started today. See Appendix G of our wolfSSL manual. Have further questions about getting started with CNSA 2.0 using wolfSSL, contact us at support@wolfSSL.com.

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 2: NIAP.

Download wolfSSL Now

wolfEngines for OpenSSL in Yocto

What Is wolfEngine?

Recently added to meta-wolfssl, wolfEngine bridges the gap between OpenSSL 1.x and wolfCrypt’s robust cryptographic functionality. This integration allows OpenSSL 1.x consumers to leverage wolfSSL’s FIPS 140-3 algorithms.

Why Choose wolfEngine?

  • Seamless Integration: Easily combine OpenSSL 1.x with the cryptographic algorithms of wolfCrypt.
  • Enhanced Security: Benefit from advanced, high-performance cryptographic capabilities.
  • FIPS-Ready: Smooth path to FIPS 140-3 compliance, making your project future-proof.

Leveraging wolfEngine

wolfEngine allows wolfCrypts FIPS 140-3 cryptography to be seamlessly integrated in your OpenSSL 1.x projects. Take the steps to prepare for FIPS 140-3 certification by using FIPS-Ready wolfSSL with wolfEngine.

Questions?

For further insights into our Standard and Commercial Bundles or if you have any inquiries, feel free to contact us at facts@wolfSSL.com or call us at +1 425 245 8247.

Download wolfSSL Now

Elevate OpenSSL in Yocto with wolfProvider

What Is wolfProvider?

New to meta-wolfssl, wolfProvider marries OpenSSL 3.x with wolfCrypt’s cutting-edge cryptography, empowering Yocto projects to utilize wolfCrypt’s FIPS 140-3 algorithms seamlessly.

Why Choose wolfProvider?

  • Effortless Integration: Fuse OpenSSL 3.x with wolfSSL’s algorithms swiftly.
  • Superior Security: Access wolfSSL’s lightweight, high-performance cryptography and wide range of supported operating environments.
  • FIPS-Ready: Smooth path to FIPS 140-3 compliance, making your project future-proof.

Leveraging wolfProvider

wolfProvider unlocks the potential to incorporate wolfCrypt’s FIPS 140-3 cryptography within your OpenSSL 3.x applications. Kickstart your project now with wolfProvider and our FIPS-Ready bundle, setting the foundation for FIPS 140-3 compliance in your project.

Questions?

If you have questions about any of the above or wish to explore more about FIPS and commercial bundles, contact us at facts@wolfSSL.com or call us at +1 425 245 8247.

Download wolfSSL Now

Posts navigation

1 2 3