The wolfSSL library includes a useful tool for sniffing TLS traffic. This can be used to capture and decrypt live or recorded PCAP traces when at least one of the keys is known. Typically a static RSA ciphersuite would be used, however with TLS v1.3 only Perfect Forward Secrecy (PFS) ciphers are allowed. For TLS v1.3 all cipher suites use a new ephemeral key for each new session.
In order to solve this we added a “static ephemeral” feature, which allows setting a known key that is used for deriving a shared secret. The key can be rolled periodically and synchronized with the sniffer tool to decrypt traffic. This feature is disabled by default and is only recommended for internal or test environments.
As a proof of concept we added this support to Apache httpd to demonstrate real-time decryption of web traffic. We are also working on a key manager to assist with key rolling and synchronization.
A use case that might be interesting is a company internal web server that requires auditing.
The TLS v1.3 sniffer support was added in PR 3044 and officially supported in v4.6.0.
The Apache httpd branch with sniffer and FIPS ready support is here.
Contact us at firstname.lastname@example.org to learn more!
The Qualcomm Hexagon SDK is used for building code to run on DSP processors. Use of the Hexagon toolchain to offload ECC verify operations has been added to wolfSSL. This can free up the main CPU for other operations or lead to future optimizations with HVX on some algorithms that use vector operations. The Makefile for building with the Hexagon toolchain and a README with more information can be found in the directory wolfssl-4.6.0/IDE/HEXAGON.
For questions about wolfSSL contact email@example.com.
Trusted Platform Modules (TPM) give us a secure vault for storing keys and secrets. We could also use a TPM as root-of-trust for reporting the health and integrity of our servers or bare metal systems (e.g. IoT). However, TPMs are physical devices. The communication between our software and the TPM happens over a physical interface, typically a SPI bus. This physical interface could be attacked maliciously. For example, IoT and Edge devices are exposed at this risk, because they are deployed in the field. An attacker might physically open the device and try to interfere with the communication between our software and the TPM. To protect from this risk, a TPM offers the capability of parameter encryption.
TPM has the ability to receive commands with their first parameter encrypted. If requested, the TPM could also respond with an encrypted first parameter. Usually, the first parameter is where the most sensitive data of a TPM command is stored. For example, during a TPM2_Create for generating a new key pair, the authValue used as password for the new key is stored in a structure called inSensitive that is the very first parameter of a TPM2_Create command request. All of this should be handled by the TPM stack. Because in order to use parameter encryption a TPM session must be set.
wolfTPM recently added parameter encryption support for protection of man-in-the-middle (MITM) attacks and offers new API wrappers to simplify its use. There is now the
wolfTPM2_StartSesssion wrapper to start TPM sessions for parameter encryption and
wolfTPM2_SetAuth to make use of this session. Regardless, if you want to use this extra layer of protection or not, the
wolfTPM2_CreateKey wrapper accepts the same number of parameters. This way the development cycle is not affected, if you want to add MITM protection to your secure application by using wolfTPM.
TPM supports AES CFB and XOR method for parameter encryption, and wolfTPM supports both. All the encryption and decryption of command parameters is handled by the stack. The secure exchange of secrets for setting up the TPM session for parameter encryption also happens seamlessly from the developer’s perspective.
If you have questions about adding wolfTPM to your project, or need tips on getting started with using a TPM, email us at firstname.lastname@example.org.