Securing CAN bus with TLS 1.3

One of the greatest security issues facing the automotive and aviation worlds is securing connections over CAN bus and its derivative protocols.  The big issue with these protocols is that they do not have a method for authenticating who or what they are communicating with, and don’t encrypt the traffic.  This leaves them open to a variety of well known attacks, like MITM, replay, and of course eavesdropping.

As many of our users are aware, wolfSSL is transport agnostic.  As such, we do TLS 1.3 grade security, complete with authentication and encryption, over any number of transports, such as Bluetooth, BTLE, Zigbee, Zwave, serial, etc.  Our transport agnostic strategy brings great benefit to environments where the transport protocol does not include security, or has poor security, because of its design or history.

We are now embarking on the mission to secure CAN bus with TLS 1.3!  Are you curious or interested? If you have questions on any of the above, contact us at facts@wolfssl.com, or call us at +1 425 245 8247.

wolfMQTT Features

The wolfMQTT library is an implementation of the MQTT Client written in C for embedded use, which supports SSL/TLS via the wolfSSL library. This library was built from the ground up to be multi-platform, space conscious and extensible. And most importantly it integrates with wolfSSL to provide TLS support, for a secure solution out of the gate!

Specifications supported

  • MQTT v3.1.1
  • MQTT v5.0
  • MQTT-SN (Sensor Network) v1.2

Application architecture

  • Non-blocking support for baremetal apps
  • Multithread for OS/RTOS supporting threads

Callbacks

  • Publish messages that are received can trigger a registered function
  • Broker disconnect for easily handling reconnects
  • Networking for simple integration with any I/O
  • MQTTv5 properties can be handled with a registered function

Supported build environments:

  • Mac/Linux/Unix with make files
  • Visual Studio solution
  • Arduino
  • MinGW
  • Cross-compile for any target

If you have any questions or run into any issues, contact us at facts@wolfssl.com, or call us at +1 425 245 8247.

While you’re there, show us some love and give the wolfMQTT project a Star!

You can download the latest release here: https://www.wolfssl.com/download/ Or clone directly from our GitHub repository: https://github.com/wolfSSL/wolfMQTT

Post-Quantum Research Results from the pq-wolfssl Team

The pq-wolfssl development team have done an excellent  experimental post-quantum integration.  We applaud their efforts and wanted to summarize and share some fascinating things that they published in their paper.  First we will discuss their scenario and then their conclusions.

The team’s objective was to study the possibility of a two-step migration strategy for post-quantum signature schemes.  In their scenario, initially, only long lived root certificates would use public keys associated with stateful hash-based signature algorithms while the intermediate and end entity certificates continue to have public keys associated with conventional algorithms such ECDSA. It is important to note here (as is done in the paper as well), that stateful hash-based signature algorithms are already specified as IETF RFCs and are generally accepted to be secure as their building blocks are well trusted hash algorithms and Merkle trees and do not depend on new or exotic mathematical constructs.

Eventually, as the other post-quantum algorithms are standardized and trust builds, intermediate certificates can be issued with public keys associated with them.  At this step end-entity certificates would then be issued with public keys associated with the new post-quantum algorithms as well. This finishes the migration process.

This begs the question, why not use stateful hash-based signature algorithms all throughout the chain from the beginning? The answer lies in the state.  End entity certificates hold public keys that are associated with private keys that will be used during the handshake phase of the TLS 1.3 connection.  The management of this state during on-line signing operations is ill advised for reasons that are not within the scope of this blog post. More detailed explanations can be found at NIST’s website.

They found that the first step of the migration could be done practically and with very little impact on connection establishment parameters. In their final migration step where the whole certificate chain and key establishment were all under post-quantum algorithms, they found that the best case scenario was feasable in all respects except RAM usage. They found that RAM usage was significantly higher.

In the paper, the team says “Therefore, we selected the open source TLS library wolfSSL (v4.7.0) for our integrations of PQC, because it is suitable for embedded systems and supports TLS 1.3.”

If you have any questions or run into any issues, contact us at facts@wolfssl.com, or call us at +1 425 245 8247.

Integration of the Falcon Signature Scheme into wolfSSL

A little while ago we announced support for post-quantum KEM groups and then hybrid groups. We are now proud to announce support for the PQC NIST round 3 finalist signature scheme FALCON. With this announcement, customers can now experiment with fully quantum-safe TLS 1.3 handshakes.

From a high level perspective, for every TLS 1.3 connection, authentication and confidentiality are the two main goals that protect each connection. Authentication is maintained via signature schemes such as ECDSA. Confidentiality is maintained by key establishment algorithms such as ECDHE and then using the established key with symmetric encryption algorithms such AES to encrypt a communication stream. We can thus decompose the security of the TLS 1.3 protocol into 3 types of cryptographic algorithms:

– authentication algorithms
– key establishment algorithms
– symmetric cipher algorithms

When a cryptographically relevant quantum computer is finally developed, Shor’s algorithm completely breaks the security of modern authentication and key establishment algorithms while Grover’s algorithm reduces the security of modern symmetric cipher algorithms by half. So, we must replace our modern authentication and key establishment algorithms with quantum-safe ones and double the strength of our symmetric cipher algorithms to maintain the security of our communications.

Now that wolfSSL has integrated FALCON, we can use it for authentication. We can use any one of our new KEMs and just in case, we can hybridize it with NIST-approved ECDSA groups. And finally, since the strength of AES-128 is generally accepted to be sufficient, we can double our strength by using AES-256 by using the AES_256_GCM_SHA384 TLS 1.3 ciphersuite. To get a connection that has such a handshake, you would run the following commands:

$ examples/server/server -v 4 -l TLS_AES_256_GCM_SHA384 \ 
 -A certs/falcon_level5_root_cert.pem \ 
 -c certs/falcon_level5_server_cert.pem \ 
 -k certs/falcon_level5_server_key.pem \ 
 --oqs P521_KYBER_LEVEL5 
 
 $ examples/client/client -v 4 -l TLS_AES_256_GCM_SHA384 \ 
 -A certs/falcon_level5_root_cert.pem \ 
 -c certs/falcon_level5_cleint_cert.pem \ 
 -k certs/falcon_level5_client_key.pem \ 
 --oqs P521_KYBER_LEVEL5 

You can then use a modified wireshark that recognizes our algorithms to monitor the connection and see what is really going over the wire:

The merge request for the wireshark modifications can be found here:
https://gitlab.com/wireshark/wireshark/-/merge_requests/4924/

The pull request for instructions for making a docker image with the wireshark modifications can be found here:

https://github.com/open-quantum-safe/oqs-demos/pull/104

The integration of FALCON has made it onto our wolfSSL master branch, and will be part of the next release of wolfSSL.

One last word on the threat model and why it is important to consider post-quantum authentication sooner rather than later. Due to your application parameters or use case, it might not be cost effective or even possible to update software components. In these cases, you must carefully evaluate the lifetime of your product. If you project that we will see a cryptographically relevant quantum computer within the lifetime of your product, but it can’t be updated, then perhaps you need to start thinking about a strategy for moving to post-quantum algorithms today.

If you have any questions or run into any issues, contact us at facts@wolfssl.com, or call us at +1 425 245 8247.

wolfMQTT Release v1.10.0

The fall release of wolfMQTT, v1.10.0, is now available! This release has several bug fixes and optimizations including:

  • Improve FALL_THROUGH macro logic for XC32. (PR #227)
  • Fix potential NULL printf in MqttSocket_Connect with verbose debug enabled. (PR #229)
  • Fix non-block chunked transfer. (PR #230)
  • Fix QoS responses (PR #231, 240)
  • Fix MQTTv5 property handling (PR #232, 233, 234, 236, 238, 241)
  • Fix fuzzing test issues (PR #242)

If you have any questions or run into any issues, contact us at facts@wolfssl.com, or call us at +1 425 245 8247.

https://github.com/wolfSSL/wolfMQTT/blob/master/ChangeLog.md

While you’re there, show us some love and give the wolfMQTT project a Star!

You can download the latest release here: https://www.wolfssl.com/download/

Or clone directly from our GitHub repository: https://github.com/wolfSSL/wolfMQTT

What’s the difference between TLS vs DTLS?

The main difference is DTLS uses UDP and TLS uses TCP. DTLS stands for Datagram Transport Layer Security and is a communications protocol designed to protect data privacy and prevent eavesdropping/tampering. It is based on TLS protocol and used across web browsing, mail, and instant messaging.

Using the DTLS library of wolfSSL, sensor data is protected all the way from the client to the gateway, and then from the gateway on to the broker using standard TLS.

You can download our latest wolfSSL release here: https://www.wolfssl.com/download/

Or clone directly from our GitHub repository: https://github.com/wolfSSL/wolfssl

While you’re there, show us some love and give the wolfSSL project a Star!

If you have any questions or run into any issues, contact us at facts@wolfssl.com, or call us at +1 425 245 8247.

wolfSSL Cisco CJOSE Port

The wolfSSL embedded SSL/TLS library has maintained support for the Cisco CJOSE library since version 4.4.0. CJOSE implements Javascript Object Signing and Encryption (JOSE) in C/C++. JOSE is a framework that allows parties to exchange transfer claims in a secure way. The CJOSE library has been ported to work with wolfSSL, the best tested crypto library on the market.

To build wolfSSL for CJOSE:

  • ./configure --enable-opensslall --enable-aeskeywrap CPPFLAGS='-DHAVE_EX_DATA -DWOLFSSL_KEY_GEN'
  • make
  • make install

To build CJOSE for wolfSSL:

  • Download the appropriate patch from https://github.com/wolfSSL/osp/tree/master/cjose. Choose a patch that corresponds or is closest to your version of cjose.
  • patch -p1 < <path/to/downloaded/patch>
  • autoreconf
  • ./configure --with-wolfssl=/usr/local
  • make

To verify that this build passes the tests, run:

  • make check

wolfSSL currently supports CJOSE version 0.6.1, the most recent release. For details on CJOSE, visit https://github.com/cisco/cjose.
This feature has been added in commit 0cfde0794b9c5ab1c01171745b800140ee4f8662.

If you have any questions or run into any issues, contact us at facts@wolfssl.com, or call us at +1 425 245 8247.

Posts navigation

1 2 3