0

I have messages of three pieces:

  1. User name
  2. IV, 16 bytes
  3. 128-bit AES Encrypted payload

Users could be running from several processes/devices on the same network and are exchanging messages via a message bus. Each user has a pre-shared key (they get it via a call to a central server via SSL) which is renewed every X hours and is stored in memory.

If I successfully decrypt the third part of a message with the pre-shared key (e.g. with try..catch(CryptoException)...), am I safe here to assume that it came from the user indicated in the part 1 of the message?

If the network is open (WiFi without encryption), are there any risks of exposing data other than the metadata of user name (which is OK)?

This must be trivial and I now assume it will work, but an assumption is the mother of all mistakes, especially in crypto...

Also (mostly out of curiosity), if several users are in the same process and a rogue user A knows the source code of the app (C# reflected from dll) and could sniff all traffic on the machine, what additional steps I need to protect the shared keys of other users in the same process from the user A? (the app in C#, the rogue user could run anything in addition to the app, e.g. assembler). Should I bother at all, or the game is over if a rogue user has such access?

Update: Week 4 of this wonderful course is the must for such kind of questions: https://class.coursera.org/crypto-010/lecture/preview

What I intuitively expected is called Synthetic IV https://www.rfc-editor.org/rfc/rfc5297 and is very well descrived in one of the lectures in the linked course

Community
  • 1
  • 1
V.B.
  • 6,236
  • 1
  • 33
  • 56
  • 1
    Unauthenticated modes like CBC do not provide secure integrity checks. An attacker might even use the fact that the server accepts some messages and rejects others as a padding oracle, decrypting the whole message. – CodesInChaos Jan 06 '15 at 13:29
  • @CodesInChaos messages are received without reply, and whenever they are relayed they are re-encrypted with another IV. Does this help? – V.B. Jan 06 '15 at 13:33
  • Just use authenticated encryption. – CodesInChaos Jan 06 '15 at 13:36
  • @CodesInChaos so I need another frame with a signature of all three other frames combined? – V.B. Jan 06 '15 at 13:40
  • @CodesInChaos Thank for pointing to the right direction! Have found the answer: http://stackoverflow.com/a/10366194/801189. Will delete the question shortly if no-one answers. – V.B. Jan 06 '15 at 13:51
  • Normally you simply call a function that uses AES-GCM (or AES-CBS together with HMAC-SHA-x) instead of AES-CBC. – CodesInChaos Jan 06 '15 at 13:51
  • This is more something for security.stackexchange.com. Although it's not off topic here because of the exception, the users there are better in picking apart protocols. Good you asked though, you would not have been safe otherwise:) – Maarten Bodewes Jan 06 '15 at 21:52

1 Answers1

1

No, any change to the data by an attacker may lead to such an exception. Basically most modes of operation of ciphers are able to decrypt any ciphertext; there is a 1:1 relation between ciphertext and plaintext. Is is possible that unpadding may fail. Furthermore, there is a chance that (part of) the message will be garbled, without an exception. For this reason you should use authenticated encryption (as already mentioned by CodesInChaos).

Garbled padding exposes you to padding oracle attacks, which requires 128 tries per byte to completely destroy confidentiality (!) for CBC mode, regardless of the block cipher used.

If you use a mode like GCM (if available) then the IV is already protected by the authenticated cipher. The username is not, however, so you should include it in the AAD part of the AEAD cipher. If you use HMAC then be sure to include the full message in the ciphertext. If you use MAC then also use a separate key (this could also be advisable for HMAC, but for e.g. AES-CMAC it is a stronger requirement).

If a user has full control over your machine then yes, the game is over. It doesn't matter if they can get to the key that protects the data if they can also directly access the data.

Maarten Bodewes
  • 90,524
  • 13
  • 150
  • 263
  • Thanks! I now have to spend hours to read about all abbreviations :) Does it matter that most of the plaintext is 16 bytes (matches AES block size or less)? I want to minimize overhead, a signature will add minimum 16 bytes, together with IV it is 2x times plaintext – V.B. Jan 06 '15 at 22:53
  • With AES-GCM you can reduce both IV and authentication tag, although you should be wary about decreasing the auth tag too much. The IV just needs to be unique (a message number could for instance be used, as long as the attacker cannot control it before encryption). And no, the idea that the plaintext is mostly 16 bytes does not help, you need some secure mode of operation for the cipher as well as authentication (otherwise an attacker could change your messages). – Maarten Bodewes Jan 06 '15 at 23:00
  • Good starting point for me. Now I am starting to realize how naive I was, and a rogue user not only could read secrets but could feed garbage to the system and the system could swallow it. I was thinking that AES already works like authenticated, good I asked! – V.B. Jan 06 '15 at 23:12
  • Oh, there is lots more. There is plausible deniability, forward secrecy, there is side channel attacks (timing and message size) etc. etc. :) – Maarten Bodewes Jan 06 '15 at 23:42