2
$\begingroup$

We have the following settings in our system: TLS 1.2 using legacy cipher suite - OFB mode (using 64 bit block cipher) and trunkated CBC-MAC (32 bit). The goal is to achieve authenticated encryption for some message $D$.

The problem here is definitely the MAC length. But we cannot change neither the algorithm, nor tag length. Also we cannot get the access to the TLS session keys. So we need a dirty hack to ensure authenticity, without introducing new shared keys.

The idea was to generate some random key $k_m$ at the client side and send the following message: $$m=HMAC_{k_m}(D)||k_m||D$$ via our TLS. So The resulting ciphertext looks like $$c=E_{k_s}(m||TCBCMAC_{k_a}(m))$$ where $E_{k_s}(m)$ is OFB ciphertext (including IV) of $m$ under the key $k_s$; $k_s$ and $k_a$ are TLS session keys.

At server side the receiver just receives and decrypts TLS packet, gets the the message $m$ and $HMAC$ key $k_m$ and validates the $HMAC$ for message $D$.

What we are trying to achieve is:

  • Do not change the way how TLS works, do not introduce new session keys.
  • Ensure something close to authenticated encryption without relying on the security of $TCBCMAC$.
  • Ensure something close to message integrity if the adversary knows the entire content of $D$.
  • While CPA security relays on TLS encryption, integrity is mainly depends on security of HMAC.

Yet we realize this solution is a just a garbage (and should be avoided in all possible cases) and this is not the way crypto should be implemented, but we could not come up with something better than this. And it is probably better than just rely on 32 bit CBC-MAC. I also could not come up with any attack on this or formal reduction to anything.

The equivalent scheme is: client generate some random $k_m$, encrypts it and sends to the server without authentication. Then this key is used for MAC-then-Encrypt construction.

The intuition of why this can ever works in case of ensuring message integrity is as follows: since $E$ provides CPA security the adversary cannot learn anything useful about $k_m$ even getting both $c$ and $D$. So the adversary cannot produce valid message-tag pair $(D', HMAC_{k_m}(D')$, so there is no way he can win in MAC message integrity game. Kind of.

So the questions are:

  • Is there a better solution to this problem?
  • Is there any advice on proving security / building attacks on this scheme?
| improve this question | |
$\endgroup$
  • 1
    $\begingroup$ Can you just do TLS 1.3 or something on top of whatever immutable system of toothpicks and duct tape you have that uses 32-bit CBC-MAC, instead of doing toothpick surgery? $\endgroup$ – Squeamish Ossifrage Aug 28 '19 at 14:29
  • $\begingroup$ Unfortunately no. That increase computation complexity and the number of messages for too much, and even this is the right solution we can not do this here. I need some kind to secure the authenticity of the payload without extra messages or shared keys. $\endgroup$ – zma Aug 29 '19 at 5:03
  • $\begingroup$ Also we have no access to the Public/Private keys inside application. TLS part is performed in other layer we have no access to. We can only form and pass payloads to it. $\endgroup$ – zma Aug 29 '19 at 5:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.