MEP 2
Title Use CurveZMQ for encryption and authentication
Status Accepted
Created 2014-11-18
Author Otto Allmendinger

Use CurveZMQ for encryption and authentication

Abstract

If you have to type the letters “A-E-S” into your source code, you’re doing it wrong.

-- Thomas Ptacek, 2009

All the crypto code you’ve ever written is probably broken

-- Tony Ariceri, 2012

This document describes replacing the custom, unaudited transport layer encryption used in Open-Transactions Client and Notary with a off-the-shelf implementation that is tailored to our use case.

Doing so will reduce the amount of code which needs to be maintained, documented and audited. The new code can be expected to have better security characteristics than our custom implementation.

Current status

Encryption and decryption are currently implemented using the classes OTEnvelope and OTCrypto. Outside the implementation, there is no documentation of the crypto scheme being used.

The class OTEnvelope is used for secure local persistence, secure Client-To-Client communication and secure Client-To-Notary communication. This MEP only concerns the use of OTEnvelope for the last application.

There are some efforts to replace the old, unaudited code with new, unaudited code ([opentxs issue #50] (https://github.com/Open-Transactions/opentxs/pull/50/files)).

Drawbacks

The current custom implementation is not well-document nor audited. Cursory review reveals that the Notary does not use authenticated encryption and is likely vulnerable to a chosen-ciphertext attack.

Flaws in the encryption and authentication systems will be exploited to compromise personal data and steal funds from users of Open-Transactions, severely damaging the reputation of the product and the company.

Enhancement

The right tools must be chosen for the task. The recommended solution for providing authentication and confidentiality on top of ZeroMQ is CurveZMQ:

This document describes CurveZMQ, a protocol for secure messaging across the Internet. CurveZMQ is closely based on Daniel J. Bernstein's CurveCP, adapted for use in ZeroMQ over TCP. A reference implementation of CurveZMQ is provided at curvezmq.org. This document describes version 1.0 of CurveZMQ.

The system also provides important features that are currently not available, like Perfect Forward Security and built-in protection against replay attacks.

Impact

Comparison to TLS

There are many other transport level security mechanism to choose from. CurveZMQ is the one that has built-in support by ZeroMQ.

Another candidate worth looking at is TLS, which is widely used and well-audited. The lead developer of ZeroMQ, Peter Hintjens, has this to say about TLS/SSL:

One of the biggest user requests for ØMQ is a good security layer. Mainstream options like TLS/SSL are complex, slow and designed for web browsing, not high-speed messaging.

-- Securing ZeroMQ: CurveCP and NaCl

In face of this statement, using CurveZMQ instead of TLS is a justified decision.

(The "complexity" Hintjens refers to can be seen in the Certificate Authority system used by OpenSSL and vulnerabilities like Heartbleed. The dissatisfaction with the OpenSSL implementation has led to efforts like LibreSSL.)

New Dependencies

The class OTEnvelope depends on cryptographic primitives that are currently provided by the OpenSSL library. CurveZMQ however depends on libsodium.

The libsodium library is well-supported on many different platforms:

Sodium supports a variety of compilers and operating systems, including Windows (with MingW or Visual Studio, x86 and x64), iOS and Android.

-- https://github.com/jedisct1/libsodium

The API methods for using CurveZMQ are available for the Go language bindings:

This requires ZeroMQ version 4.0.1 or above. To use CURVE security, ZeroMQ must be installed with libsodium enabled.

-- https://github.com/pebbe/zmq4

Necessary Code Changes

The introduction of CurveZMQ happens in three steps:

  1. Clean up the transport code on the client, including a separation of the transport security layer from the rest of the code. Code for local secure storage will be separated from the transport code.
  2. Add support for the key formats used in CurveZMQ (ed25519).
  3. Replace the existing transport crypto system (OTEnvelope) by CurveZMQ.

Side Benefits

  1. The cleanup of the transport code is a large benefit in itself.

  2. There are efforts to use ed25519 as the digital signature scheme for documents as a replacement for the current RSA signatures. The key format used in that scheme is the same as the one used for CurveZMQ. The libsodium library, which CurveZMQ depends on, provides support for ed25519 signatures. This allows Open-Transactions to only depend on libsodium for all signature verification and transport encryption.