3

I have worries about security defined in BACnet protocol (ASHRAE/ANSI Standard 135, ISO 16484-5). Full text of security is here: http://bacnet.org/Addenda/Add-135-2008g.pdf and here is my summary:

In my message I have header containing unique message ID and timestamp (along with some other data) and payload. I sign whole message using HMAC with first key and MD5 or SHA-256 as hash algorythm. Then i use first 16 bytes of signature as IV for encrypting payload with CBC AES with second key. I attach signature to the message.

Is My IV unpredictable enough? Is signing a plain payload making my security vulnerable?

Luis Casillas
  • 14,468
  • 2
  • 31
  • 53
kiciek
  • 131
  • 3
  • 1
    It doesn't matter, because you are doing MAC-then-encrypt which runs afoul of the cryptographic doom principle. Designing your own cryptographic transport is dangerous. Unless you have an overwhelming need for something custom, please just use TLS. – Stephen Touset Nov 11 '16 at 22:48
  • I am not defining my own cryptgraphic transoprt. I had worries about security defined in BACnet protocol (ASHRAE/ANSI Standard 135, ISO 16484-5). Full text of security is here: http://www.bacnet.org/Addenda/Add-135-2008g.pdf There is possibility I failed to understand addenda, but if I summarised it correctly you tell me it is unsafe. (i am impressed they worked on security a lot of years and it fail.) – kiciek Nov 11 '16 at 23:07
  • I second Stephen, but I'd add that if you really insist in going your own way, you should consider using a misuse-resistant AEAD like SIV. But you're on your own. – Luis Casillas Nov 11 '16 at 23:08
  • 1
    @kiciek: I would suggest then editing your question to reflect that you're not proposing to use this construction, but rather that you encountered it in a protocol. – Luis Casillas Nov 11 '16 at 23:10
  • 1
    In this case the output of HMAC can be considered random from the perspective of a third party who doesn't know the key, so it is unpredictable to an attacker. That said, MAC-then-encrypt is a serious design error, and leads me to assume other parts of the protocol are likely to have security problems. – Stephen Touset Nov 12 '16 at 00:15

1 Answers1

5

I have not looked in detail at the standard you linked to, but in general, applying a PRF (such as HMAC) to the plaintext (plus associated data and/or a nonce, if any) to derive a message authentication tag, and then using the same authentication tag as the IV to a conventional IND\$-secure length-preserving IV-based encryption scheme, is an instance of the "SIV construction" (Rogaway & Shrimpton 2007, pp. 6–9). Thus, if the assumptions of Rogaway & Shrimpton's proof are met, this construction yields a secure deterministic authenticated encryption scheme (if used without a nonce) or a misuse-resistant authenticated encryption scheme (if used with a nonce) in the sense defined in the paper.

However, a notable issue in applying the SIV proof to the BACnet scheme (as you describe it) is that basic CBC mode (without ciphertext stealing) is not length-preserving. In particular, the scheme you describe appears potentially vulnerable to the CBC padding oracle attack if an attacker can distinguish a CBC padding error from an HMAC mismatch. Even if the recipient is specified to return the exact same error in both cases, it might still be possible to distinguish the two cases by timing how long it takes the recipient to reject the message.

A simple solution to this issue would be to replace CBC with a length-preserving encryption mode, such as CTR, CFB or even CBC with ciphertext stealing.

Ps. I thought this question seems vaguely familiar, and while searching for references I stumbled across an earlier very similar question about HMAC + CBC in an SIV-like construction that I'd previously answered:

Also, for general information about the security of the MAC-and-encrypt structure of SIV mode, see the following question:

as well as the paper "Reconsidering Generic Composition" by Namprempre, Rogaway and Shrimpton (Cryptology ePrint Archive, Report 2014/206, 2014) which I cite in my answer there.

Community
  • 1
Ilmari Karonen
  • 46,120
  • 5
  • 105
  • 181
  • 1
    I was also writing a similar answer, but I found that this uses a very strange two byte padding mode, with "random data" before the padding size indicator. That might alleviate the issue - but maybe not fully, I'm not sure. The fact that there is no mention of "padding oracle" in the spec. probably means that any protection against oracle attacks is purely coincidental. – Maarten Bodewes Nov 12 '16 at 10:29
  • It will take some time for me to study and understand Ilmari's answer. Maarten - I am impressed you found "random data" padding, becouse documentation itself state only "The values of all remaining [padding] octets are unspecified.", but (not full) implementation of bacnet-stack for linux indeed fills padding with random data. – kiciek Nov 14 '16 at 14:12