[cicm] RFC 5116 (AEAD)

["Novikov, Lev" <[e-mail]>]

On 2011-07-27 14:39, David McGrew wrote:
[...]
> RFC 5116 defines a standard interface to Authenticated Encryption with
> Associated Data (AEAD) algorithms, which is used by TLS 1.2, SSH,
> SRTP, IKE, and SMIME, and is backwards compatible with ESP.   The AEAD
> interface is simple (two defined messages, four inputs and one output
> each), and AEAD is widely regarded as the state of the art in security
> and efficiency (including both OCB and GCM, for instance).  It appears
> that CICM is not compatible with this interface, in which case it
> would be a real step backwards.  (If CICM does support AEAD, it is not
> clear to me how it does.  Am I missing something?)
>
> CICM is intended for use in a high assurance crypto module.
> Considering that AES-GCM is required for Suite B, and the Suite B RFCs
> all cite RFC 5116, the lack of AEAD support appears problematic.
[...]

I've read through RFC 5116 and there doesn't seem to be any reason why
CICM couldn't support AEAD, although it would probably have to be its
own channel type. Here's why:

1. AEAD encryption takes a key (K), a nonce (N), plaintext (P), and
   associated data (A) and outputs ciphertext (C). Decryption takes
   K, N, A, and C and returns P (or FAIL).
   (Simplicity itself!)

2. Since the associated data (A) is sent in the clear, this is similar
   to a CICM::EncryptBypass::Conduit, although the whole bundle is
   authenticated, so it is more like a CICM::Encrypt::WithMACConduit
   --albeit with a single key (K).

   See:
   http://tools.ietf.org/html/draft-lanz-cicm-cm-01#section-9.8
   http://tools.ietf.org/html/draft-lanz-cicm-cm-01#section-14.5

3. Therefore, it seems like the best way to handle AEAD would be to
   create a new channel type. Specifically, we'd need to support
   creating a conduit just like an EncryptBypass::Conduit (one key,
   one algorithm) that behaved like an Encrypt::WithMACConduit
   (supporting the end_get_mac() method).

   CICM::Status create_encrypt_auth_data_conduit(
     in  CICM::RemotePort remote_port,
     in  CICM::SymKey key_ref,
     in  CICM::SymEncrAlgorithmId algorithm,
     out CICM::EncryptBypass::AEADConduit conduit_ref
   );

   The conduit would look exactly like a Encrypt::WithMACConduit,
   except that both key attributes (key, mac_key) would point to the
   same key. For example,

   interface AEADConduit :
      CICM::AbstractMACConduit,
      CICM::Encrypt::Conduit {}

4. The approach above would differ from RFC 5116 in a few ways:
    - There is not a single method with four inputs that returns a
      single output. This is because in CICM channel *creation* is
      separate from channel *usage*.

    - The output is not returned, but is emitted in another domain.
      If necessary, we can add a similar channel type to the
      CICM::Coprocessor namespace as we have for
      Coprocessor::EncryptWithMACConduit. The conduit would no longer
      require a remote port, and the conduit would inherit from
      CICM::Coprocessor::EncryptConduit rather than
      CICM::Encrypt::Conduit.

      See:
      http://tools.ietf.org/html/draft-lanz-cicm-cm-01#section-18
      http://tools.ietf.org/html/draft-lanz-cicm-cm-01#section-18.3
      http://tools.ietf.org/html/draft-lanz-cicm-cm-01#section-18.4

    - Additionally, the nonce (N) parameter would be omitted, but
      could be supplied or generated using the attributes and methods
      inherited from CICM::SetVectorController and
      CICM::GenVectorController.

      See:
      http://tools.ietf.org/html/draft-lanz-cicm-cm-01#section-7.5
      http://tools.ietf.org/html/draft-lanz-cicm-cm-01#section-7.6

** David McGrew:
    - Is my understanding of how AEAD works correct?
    - Would these sorts of additions satisfy the needs of AEAD, or
      would a more explicit conformance to the method signature be
      required?

Lev