Introducing PQGo, experimental post-quantum cryptography in Go

TL;DR: We published cgo wrappers for post-quantum crypto at https://github.com/Teserakt-io/PQGo.

Post-quantum cryptography is about public-key algorithms that wouldn’t be broken by a quantum computer—unlike RSA, Diffie-Hellman, and elliptic curve cryptography, which all rely on the hardness of problems that are hard with a classical computer but become easy for quantum algorithms. For more on this topic, we refer to our presentation at BSides Lisbon 2017.

Quantum computers that would break our crypto aren’t coming anytime soon, but as an insurance against a breakthrough in quantum engineering, NIST is running a public competition to standardize post-quantum crypto in the next five years. This project sparked greater interest from researchers and industry, who see the opportunities from the publicity and investments around the quantum computer threat—often blatantly exaggerated.

To respond to the demand from customers and as a research interest, we at Teserakt investigated the integration of post-quantum crypto in our products. Our products’ reference code is in Go, whereas implementations of post-quantum crypto are in C. We therefore wrote a Go package using cgo to call the C code, which we adapted from reference implementations of some NIST submissions.

Our package github.com/Teserakt-io/PQGo currently supports the signature scheme Dilithium and the KEMs Kyber and Round5. As explained in the README, this choice isn’t a general endorsement nor a recommendation, but is based on some of our functional and performance requirements.

We tried to simplify the API and to hide some of its quirks, such as the fact that the C signature verification function will sometimes write at the message pointer’s address more data than the message’s actual length. Our package includes benchmark routines, but remember that we took the reference implementations rather than the optimized implementation, so an algorithm’s measured performance may be far from its optimal performance.

Please let us know your feedback by reporting issues on GitHub, submitting PRs, or writing us! We’d be happy to integrate more algorithms, please let us know your requests.

WARNING: Experimental code, don’t use in production or for anything that matters. (We know from experience that such statements don’t stop people from using the code in production or in their blockchain, but don’t say we didn’t warn you.)

 

Teserakt partners with VerneMQ

We’re happy to announce our partnership with Octavo Labs AG, the company behind the open-source MQTT broker VerneMQ. At Teserakt we have reviewed part of VerneMQ’s internals and source code, and also tested it in combination with our MQTT encryption solution. We really liked VerneMQ for reasons including its:

  • Security: Although Teserakt’s E4 solution aims to protect against compromised brokers, we prefer to use a secure broker. VerneMQ follows best security practices, minimizes the risk of memory corruption bugs, and is one of the few brokers with secure-by-default settings.
  • Scalability: Thanks to its Erlang-based design, VerneMQ easily scale horizontally and vertically by fully utilizing multicore architectures.
  • Ease of use: VerneMQ is simple to build, run, and configure, and offer lots of options as well as a comprehensive documentation.

As described in more detail in our slide deck, the partnership consists in the following actions:

  • Octavo Labs includes Teserakt’s encryption technology in their MQTT offering, to allow their customers to directly deploy end-to-end secure MQTT in their infrastructure.
  • Teserakt selects VerneMQ as its first approved broker, which concretely means that VerneMQ will be part of our continuous integration process and test suites, and will be recommended to Teserakt customers (other brokers may be approved after a technical assessment from our team).

We’d like to thank the VerneMQ team for this collaboration! For any questions, please get in touch at [email protected].

 

Teserakt partners with P3KI

We’re happy to join forces with P3KI GmbH, provider of the P3KI Core decentralized PKI solution for access delegation applications. We like what P3KI is doing because we think that it’s useful, well-engineered, and developed with security in mind.

The P3KI Core product can be seen as a kind of PKI but with more decentralization, and with precise expression of permission levels thanks to a mathematically-verified language, which adresses most authorization and authentication challenges.

Concretely, this partnership consists in bundling the P3KI’s authorization management and Teserakt’s key management services in a single appliance, simplifying and reducing the cost of integration of these two complementary products. More details are available in our slide deck.

For any questions, please get in touch at [email protected]. See also P3KI’s announcement.

Express fuzzing of MQTT brokers

MQTT brokers seem to lend themselves well to fuzzing because they often implement their own versions of the MQTT protocol, which includes parsing of MQTT control packets. These packets often include length–value encodings, a typical source of bugs if not carefully implemented. For example, a PUBLISH packet’s control header encodes the topic length over two bytes; if the parser naively attempts to read as many bytes as specified regardless of the packet’s actual length, an out-of-bound memory access could occur—the same kind of bug that caused Heartbleed.

With the intuition that such bugs and other parsing bugs could exist, we set out to run some dumb fuzzing on MQTT brokers. We started by manually crafting malformed packets but quickly discovered mqtt_fuzz, a small project from F-Secure that does exactly what we wanted, namely blind fuzzing of common MQTT control packets.

We started fuzzing brokers written in C—more sensitive to memory corruption bugs—Mosquitto and Bevywise. The former is the most popular open-source broker, and unsurprisingly our straightforward methodology didn’t yield any result. But we got several Bevywise crashes after running the fuzzer for about 20 seconds, apparently caused by the above length–value pattern (thanks to zx2c4 for helping us reverse engineering the binaries). A debugger would for example show the following:

* thread #15, stop reason = EXC_BAD_ACCESS (code=1, address=0x0)
    frame #0: 0x000000010b6e3bc0 libmqttbroker.so`on_recv_publish_func + 368
libmqttbroker.so`on_recv_publish_func:
->  0x10b6e3bc0 <+368>: movzbl (%r15,%rax), %edx
    0x10b6e3bc5 <+373>: movb   %dl, (%rbx,%rax)
    0x10b6e3bc8 <+376>: movslq %ecx, %rax
    0x10b6e3bcb <+379>: incl   %ecx
Target 0: (Broker) stopped.

We didn’t investigate further and can’t tell whether these specific bugs are exploitable for more than remotely crashing a broker. But being able to crash a remote broker by sending a string such as 8206000200e0bfadf3a081f3a0812b2f762fa9bdcb90f3a0819001cd2b2f762f8523cab000 is already a problem.

We quickly looked at some other brokers, found to be resilient to our basic fuzzer: In EMQ and VerneMQ, both written in Erlang, certain malformed packets would crash session processes (by design), without interrupting the service. In HiveMQ, written in Java, we spotted an uncaught index-out-of-bound exception, which did not interrupt the service (HiveMQ directly fixed and credited us for the observation). In Mosca, written in JavaScript, we didn’t notice any abnormal behavior.

The largest part of this project was done in a Geneva–Lausanne train ride (~40min), so there’s probably much more to find, starting with using a less dumb fuzzer (afl, libFuzzer?) and looking at other brokers. Feel free to let us know your findings!

 

Introduction to MQTT

You’ll read on our homepage that Teserakt’s first product brings end-to-end encryption to the MQTT protocol. But before describing our solution, let’s find out how MQTT works and where it’s used.

The MQTT site describes it as “a machine-to-machine (M2M)/’Internet of Things’ connectivity protocol”, although the Message Queue Telemetry Transport existed long before the term IoT was coined, namely since the late 90’s. Today MQTT is for example used for cloud infrastructure telemetry, in critical infrastructure systems such as dams or power plants, in connected cars, and in Facebook messenger.

One reason behind the success of MQTT is its simplicity. MQTT involves three types of entities:

  • Publishers, which create messages, tag them with a topic, and send them to a broker.
  • Subscribers, which subscribe to one or more topics, and then receive all messages tagged with these topics from a broker.
  • Broker servers, which dispatch messages from publishers to subscribers, and manage clients’ authentication and authorizations.

A client device can act as both publisher and subscriber. Publishers are for example sensors sending telemetry data to a back-end that runs the business logic (analytics, reporting, and so on). The broker and the back-end sometimes run on the same infrastructure.

In the example below, the clients on the left publish messages and the client on the right subscribes to the topics associated to these messages. After requesting the broker to subscribe to a topic, a client receives a SUBACK message from the broker, which confirms that the broker has registered the subscription.

You’ll notice that in the PUBLISH messages, we’ve set the “retain” flag to true, which means that the broker will retain the last message associated with a given topic, and will send it to a client even if it subscribes after the message was published. The diagram can thus be read in different ways: with the PUBLISH messages happening before the SUBSCRIBE messages, or the other way around.

You can play with MQTT by installing the mosquitto open-source broker and its suite of tools. First, start the broker locally by running the mosquitto command (add -d to run it as a background process). This will start an MQTT broker instance listening on port 1883. Then you can start a client instance that will connect to this broker and subscribe to topic mqttest:

mosquitto_sub -h localhost -p 1883 -t mqttest

In another terminal, publish a message to this topic:

mosquitto_pub -h localhost -p 1883 -t mqttest -m hello

The message hello will then appear on the first terminal running the subscribed client instance. You can try first publishing the message with the flag -r (telling the broker to retain the message) and subscribe afterwards. Don’t forget to stop your broker after running this test.

Mosquitto is a popular open-source broker, but if you use MQTT in production environments and need high availability and/or technical support, several options are available. Vendors such as HiveMQ and VerneMQ offer enterprise-ready broker software, and cloud platforms of AWS, Google, and IBM offer hosted MQTT brokers (note that MQTT is the only non-web protocol supported by their IoT platforms).

MQTT is super simple, but not very secure by default. Most deployment will (at best) run client–broker connections in TLS tunnels, for example in order to protect authentication credentials from eavesdropping. In subsequent posts we’ll show you how our technology addresses MQTT’s inherent security limitations, and we’ll also talk about brokers’ software security.