Secure Messaging for the Internet

1. CurveZMQ, ZMTP and other
Dubious Characters
Secure Messaging for the Internet
by
Pieter Hintjens, CEO, iMatix
Berlin Buzzwords 2013, 4 June, 2013

2. What's the Problem?
● ZeroMQ (ØMQ) defined a new product
category
● Message queuing & routing stacks
● JeroMQ, NullMQ, Nano, netty-zmtp, ezmtp
● All have the same problem: clear-text
● Not safe to use on public infrastructure

3. What do People Do?
● Many apps just use clear text
● Clearly not acceptable for sensitive data
● Salt Stack has its own security system
● Already cracked (chicken-salt)
● IPython uses SSH + HMAC digests
● Has several plausible vulnerabilities

4. Works in Progress
● TLS encryption above libzmq (Barber)
● TLS transports for libzmq (Young, Naudé)
● DTLS transport for libzmq (Cocagne)
● May deliver, but...
● What about interoperability?

5. The Right Solution
● Security at the protocol level (ZMTP)
● Extensible security (like SASL)
● Several example mechanisms
● Easy to plug new ones into libzmq
● Perhaps exposed as e.g. dtls://

6. What's SASL?
● IETF's solution for extensible security
● We used this when designing AMQP
● Client and server negotiate a "mechanism"
● Mechanism does the actual security
● IETF as usual makes it... complex
● We can do it somewhat simpler

7. The Security Handshake
● Client: HELLO
● Server: WELCOME (mechanism M)
● Client: INITIATE (mechanism M)
● Server: READY
● Client: MESSAGE | Server: MESSAGE

8. What is "Secure" in 2013?
● Data cannot be tapped (encrypted)
● or created fraudulently (authentic)
● or altered
● or replayed
● Keys cannot be stolen

9. Basic State of the Art
● Mechanisms must be open ended
● Allows evolution of security over time
● Processing HELLO command must be cheap
● Prevents denial-of-CPU attacks
● HELLO must be larger than WELCOME
● Prevents amplification attacks
● Send no metadata until INITIATE/READY
● Prevents leak of knowledge about peer

10. Advanced State of the Art
● Perfect forward security
● Data cannot be decrypted even with private keys
● Resists man-in-the-middle manipulation of keys
● Clients cannot be identified
● Client public keys are sent encrypted
● Resists traffic-analysis attacks
● Randomize message sizes & frequencies

11. Meet CurveCP (Bernstein)
● "Usable Security for the Internet"
● From author of NaCl (=> libsodium)
● Encryption and authentication over UDP
● Also does recovery from packet loss
● Also does a bunch of other stuff
● http://curvecp.org

12. Some CurveCP Internals
● Elliptic curve encryption, very fast
● Creates short-term keys for each connection
● Unique nonces for each command
● Achieves "advanced state of the art"
● Except defeating traffic analysis
● Which we can add ourselves

13. Why NaCl is Wonderful
● Perfectly simple API
● Fast and robust
● Preselected key sizes & algorithms
● Packaged as libsodium
● Easy to install, learn, and use

14. Why CurveCP won't happen
● Tries to do too much, too soon
● The software is complex to use
● Does not "play nice" with existing standards
● Utterly incompatible with SASL, TCP
● Remixed into more plausible MinimalT

15. Apart from that, Very Nice!
● I took CurveCP's security handshake
● Simplified it and cleaned it up
● Made it transport neutral
● Wrote down as a single protocol document
● http://rfc.zeromq.org/spec:26/CURVEZMQ

16. Meet CurveZMQ
● An Abstract Security Mechanism
● Specified as a client-server protocol
● Any transport (even avian carrier)
● TCP if we build this into ZMTP
● Or ZeroMQ tcp://, at application level
● http://curvezmq.org

17. Meet ZMTP
● The ZeroMQ Message Transport Protocol
● Wire protocol for ZeroMQ over TCP
● Fifth RFC now in drafting stage
● In ZeroMQ, JeroMQ, NetMQ, netty-zmtp, ...
● Version 3.0 is quite a big deal
● http://rfc.zeromq.org/spec:23/ZMTP

18. What's New in ZMTP 3.0?
● Extensible security mechanisms
● Extensible connection metadata
● Endpoint resources (for port sharing)
● Better backwards version detection
● Explicit socket type semantics

19. ZMTP's security mechanisms
● NULL is just that, empty
● PLAIN does clear-text authentication
● Test clients vs. production systems
● CURVE does CurveZMQ security
● Fully encrypted and authenticated
● <Insert your own here>

20. libzmq already runs ZMTP 3.0
● Git master does NULL and PLAIN
● Full backwards compatibility
● Supports extensible mechanisms
● We're now working on CURVE
● Next: DTLS, ...?

21. Meet ZAP
● The ZeroMQ Authentication Protocol
● Extensible authentication services
● Using ZeroMQ request-reply protocol
● PAM, LDAP, Kerberos, passwd, etc.
● libzmq implements ZAP 1.0
● http://rfc.zeromq.org/spec:27/ZAP

22. Get involved
● Read the RFCs on http://rfc.zeromq.org
● Come to Brussels on 21 & 22 June 2013
● For ZeroMQ Developers' Meetup
● http://zero.mq/bxl
● Talk to us on the zeromq-dev list

23. Who are we?
● ZeroMQ community including iMatix
● iMatix makes messaging products
● Distributed systems since 1991
● Original designers of AMQP (2004-07)
● Backers of ZeroMQ community (2007-)
● Authors of most ZeroMQ RFCs

24. Thanks!
● Buy the O'Reilly ZeroMQ book
● Email me: ph@imatix.com
● Twitter: @hintjens
● Blog: hintjens.com