Hi developers, Our customers, as well as community users, have asked for encryption of control channel packets to hide their certificate (containing perhaps the users' name or organisation), or to provide some basic form of post-quantum security (see e.g. trac #633).
We've been thinking about this for a while, and would like to implement such a feature. I've attached a proposal for an extension of tls-auth to achieve this in OpenVPN. Comments and/or questions are very welcome. I hope to be able to start implementing this soon. -SteffanTitle: Control channel encryption (--tls-crypt)
Control channel encryption (--tls-crypt)
This is a proposal for a --tls-crypt option, which uses a pre-shared static key (like the --tls-auth key) to encrypt control channel packets.
Encrypting control channel packets has three main advantages:
- It provides more privacy by hiding the certificate used for the TLS connection.
- It is harder to identify OpenVPN traffic as such.
- It provides "poor-man's" post-quantum security, against attackers who will never know the pre-shared key.
Control channel packet encryption
We propose to use the following encryption method, based on the SIV construction [0], to achieve nonce misuse-resistant authenticated encryption:
msg = control channel plaintext header = opcode (1 byte) || session_id (8 bytes) || packet_id (4 bytes) Ka = authentication key (256 bits) Ke = encryption key (256 bits) (Ka and Ke are pre-shared keys, like with --tls-auth) auth_tag = HMAC-SHA256(Ka, header || msg) IV = 128 most-significant bits of auth_tag ciph = AES256-CTR(Ke, IV, msg) output = Header || Tag || Ciph
This boils down to the following on-the-wire packet format:
-opcode- || -session_id- || -packet_id- || auth_tag || * payload * Where - XXX - means authenticated, and * XXX * means authenticated and encrypted.
Which is very similar to the current tls-auth packet format, and has the same overhead as --tls-auth with --auth SHA256.
The use of a nonce misuse-resistant authenticated encryption scheme allows us to worry less about the risks of nonce collisions. This is important, because in contrast with the data channel in TLS mode, we will not be able to rotate tls-crypt keys often or fully guarantee nonce uniqueness. For non misuse-resistant modes such as GCM [1], [2], the data channel in TLS mode only has to ensure that the packet counter never rolls over, while tls-crypt would have to provide nonce uniqueness over all control channel packets sent by all clients, for the lifetime of the tls-crypt key.
Unlike with tls-auth, no --key-direction has to be specified for tls-crypt. TLS servers always use key direction 1, and TLS clients always use key direction 2, which means that client->server traffic and server->client traffic always use different keys, without requiring configuration.
Using fixed, secure, encryption and authentication algorithms makes both implementation and configuration easier. If we ever want to, we can extend this to support other crypto primitives. Since tls-crypt should provide privacy as well as DoS protection, these should not be made negotiable.
Security considerations:
tls-crypt is a best-effort mechanism that aims to provide as much privacy and security as possible, while staying as simple as possible. The following are some security considerations for this scheme.
- The same tls-crypt key is potentially shared by a lot of peers, so it is quite likely to get compromised. Once an attacker acquires the tls-crypt key, this mechanism no longer provides any security against the attacker.
- Since many peers potentially use the tls-crypt key for a long time, a lot of
data might be encrypted under the tls-crypt key. This leads to two potential
problems:
- The opcode || session id || packet id combination might collide. This is quite likely to happen in larger setups, because the session id contains just 64 bits or random. Using the uniqueness requirement from the GCM spec [3] (a collision probability of less than 2^(-32)), uniqueness is achieved when using the tls-crypt key for at most 2^16 (65536) connections. Large setups are likely to violate this constraint. When a collision happens, an attacker can learn whether colliding packets contain the same plaintext. Attackers will not be able to learn anything else about the plaintext (unless the attacker knows the plaintext of one of these packets, of course). Since the impact is limited, I consider this an acceptable remaining risk.
- The IVs used in encryption might collide. When two IVs collide, an attacker can learn the xor of the two plaintexts by xorring the ciphertexts. This is a serious loss of confidentiality. The IVs are 128-bit, so when HMAC-SHA256 is a secure PRF (an assumption that must also hold for TLS), and we use the same uniqueness requirement from [3], this limits the total amount of control channel messages for all peers in the setup to 2^48. Assuming a large setup of 2^16 (65536) clients, and a (conservative) number of 2^16 control channel packets per connection on average, this means that clients may set up 2^16 connections on average. I think these numbers are reasonable.
(I have a follow-up proposal to partially mitigate these issues, but let's tackle this proposal first.)
References:
| [0] | Rogaway & Shrimpton, A Provable-Security Treatment of the Key-Wrap Problem, 2006 (https://www.iacr.org/archive/eurocrypt2006/40040377/40040377.pdf) |
| [1] | Ferguson, Authentication weaknesses in GCM, 2005 (http://csrc.nist.gov/groups/ST/toolkit/BCM/documents/comments/CWC-GCM/Ferguson2.pdf) |
| [2] | Joux, Authentication Failures in NIST version of GCM, 2006 (http://csrc.nist.gov/groups/ST/toolkit/BCM/documents/comments/800-38_Series-Drafts/GCM/Joux_comments.pdf) |
| [3] | (1, 2) Dworking, Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC, 2007 (http://csrc.nist.gov/publications/nistpubs/800-38D/SP-800-38D.pdf) |
Control channel encryption (--tls-crypt)
========================================
This is a proposal for a ``--tls-crypt`` option, which uses a pre-shared
static key (like the ``--tls-auth`` key) to encrypt control channel packets.
Encrypting control channel packets has three main advantages:
* It provides more privacy by hiding the certificate used for the TLS
connection.
* It is harder to identify OpenVPN traffic as such.
* It provides "poor-man's" post-quantum security, against attackers who will
never know the pre-shared key.
Control channel packet encryption
---------------------------------
We propose to use the following encryption method, based on the SIV
construction [0]_, to achieve nonce misuse-resistant authenticated
encryption::
msg = control channel plaintext
header = opcode (1 byte) || session_id (8 bytes) || packet_id (4 bytes)
Ka = authentication key (256 bits)
Ke = encryption key (256 bits)
(Ka and Ke are pre-shared keys, like with --tls-auth)
auth_tag = HMAC-SHA256(Ka, header || msg)
IV = 128 most-significant bits of auth_tag
ciph = AES256-CTR(Ke, IV, msg)
output = Header || Tag || Ciph
This boils down to the following on-the-wire packet format::
-opcode- || -session_id- || -packet_id- || auth_tag || * payload *
Where
- XXX - means authenticated, and
* XXX * means authenticated and encrypted.
Which is very similar to the current tls-auth packet format, and has the
same overhead as ``--tls-auth`` with ``--auth SHA256``.
The use of a nonce misuse-resistant authenticated encryption scheme allows us
to worry less about the risks of nonce collisions. This is important, because
in contrast with the data channel in TLS mode, we will not be able to rotate
tls-crypt keys often or fully guarantee nonce uniqueness. For non
misuse-resistant modes such as GCM [1]_, [2]_, the data channel in TLS mode
only has to ensure that the packet counter never rolls over, while tls-crypt
would have to provide nonce uniqueness over all control channel packets sent by
all clients, for the lifetime of the tls-crypt key.
Unlike with tls-auth, no ``--key-direction`` has to be specified for tls-crypt.
TLS servers always use key direction 1, and TLS clients always use key
direction 2, which means that client->server traffic and server->client traffic
always use different keys, without requiring configuration.
Using fixed, secure, encryption and authentication algorithms makes both
implementation and configuration easier. If we ever want to, we can extend this
to support other crypto primitives. Since tls-crypt should provide privacy as
well as DoS protection, these should not be made negotiable.
Security considerations:
------------------------
tls-crypt is a best-effort mechanism that aims to provide as much privacy and
security as possible, while staying as simple as possible. The following are
some security considerations for this scheme.
1. The same tls-crypt key is potentially shared by a lot of peers, so it is
quite likely to get compromised. Once an attacker acquires the tls-crypt
key, this mechanism no longer provides any security against the attacker.
2. Since many peers potentially use the tls-crypt key for a long time, a lot of
data might be encrypted under the tls-crypt key. This leads to two potential
problems:
* The ``opcode || session id || packet id`` combination might collide. This
is quite likely to happen in larger setups, because the session id
contains just 64 bits or random. Using the uniqueness requirement from
the GCM spec [3]_ (a collision probability of less than 2^(-32)),
uniqueness is achieved when using the tls-crypt key for at most 2^16
(65536) connections. Large setups are likely to violate this constraint.
When a collision happens, an attacker can learn whether colliding packets
contain the same plaintext. Attackers will not be able to learn anything
else about the plaintext (unless the attacker knows the plaintext of one
of these packets, of course). Since the impact is limited, I consider this
an acceptable remaining risk.
* The IVs used in encryption might collide. When two IVs collide, an
attacker can learn the xor of the two plaintexts by xorring the
ciphertexts. This is a serious loss of confidentiality. The IVs are
128-bit, so when HMAC-SHA256 is a secure PRF (an assumption that must also
hold for TLS), and we use the same uniqueness requirement from [3]_, this
limits the total amount of control channel messages for all peers in the
setup to 2^48. Assuming a large setup of 2^16 (65536) clients, and a
(conservative) number of 2^16 control channel packets per connection on
average, this means that clients may set up 2^16 connections on average.
I think these numbers are reasonable.
(I have a follow-up proposal to partially mitigate these issues, but let's
tackle this proposal first.)
References:
-----------
.. [0] Rogaway & Shrimpton, A Provable-Security Treatment of the Key-Wrap
Problem, 2006
(https://www.iacr.org/archive/eurocrypt2006/40040377/40040377.pdf)
.. [1] Ferguson, Authentication weaknesses in GCM, 2005
(http://csrc.nist.gov/groups/ST/toolkit/BCM/documents/comments/CWC-GCM/Ferguson2.pdf)
.. [2] Joux, Authentication Failures in NIST version of GCM, 2006
(http://csrc.nist.gov/groups/ST/toolkit/BCM/documents/comments/800-38_Series-Drafts/GCM/Joux_comments.pdf)
.. [3] Dworking, Recommendation for Block Cipher Modes of Operation:
Galois/Counter Mode (GCM) and GMAC, 2007
(http://csrc.nist.gov/publications/nistpubs/800-38D/SP-800-38D.pdf)
