Incorrect use of AES backup encryption

[Morgan Fainberg]

-- NOTE(morganfainberg) --------------------------------------
This bug has been split from the original bug #1606407 ; this split has been done since the concerns between Shell injection and wrong use of AES CBC are fundamentally different concerns.
---------------------------------------------------------------

AES CBC is intended as a stream cipher rather than encryption and decryption of static data, this could potentially lead to more complex crypto issues.

This was originally reported by Tim Suter and Travis Scheponik

[Morgan Fainberg (mdrnstm)]

As stated by Jeremy Stanley (fungi) in the previous bug #1606407 :

Concerns over the underlying cryptographic transformation used for securing Trove's guest agent backups. Unless it can be shown that these choices definitely lead to a weakening of the at-rest security, fixing this can be handled as a hardening opportunity (VMT class D).

[Tristan Cacqueray (tristan-cacqueray)]

According to commit 4eef8d9, the backup process is streamed to/from Swift, perhaps using cbc was actually intended... Though I'm not a crypto expert and someone more knowledgeable should confirm this is a correct use-case.

Perhaps this can be done publicly ? (I've subscribed ossg-coresec to weight on this)

[Robert Clark (robert-clark)]

The statement that "CBC is intended as a stream cipher" is contrary to my understanding. CFB, OFB and CTR are all typically used as stream modes with AES. CBC is a block cipher mode, it is often used with network technologies like TLS which is why it is sometimes miss-identified as a stream cipher, however TLS using AES-CBC still has to transmit entire blocks, even if the data does not fill a block. This results in padding of the block which can in some implementations results in issues like Poodle.

I'd agree that this is a class D issue. I was once told that "There is no encryption without authentication" which in this context basically means that "AES-GCM" might be a better solution, it's hard to say without knowing a lot more about Trove.

Authentication (which could be done with CBC-MAC) aside, I don't see any significant issues with using CBC here I do not believe it puts users at any significant risk.

[Amrith Kumar (amrith)]

<disclaimer>I'm no expert on security, I don't play one on TV.</disclaimer>

But, I agree with Robert's first statement; that "CBC is intended as a stream cipher" isn't exactly my understanding.

Still, the reporter claims "AES CBC is intended as a stream cipher rather than encryption and decryption of static data, this could potentially lead to more complex crypto issues".

If there are in fact more complex crypto issues, I don't want to lose sight of them in the focus on the first part of the sentence. So, let's accept as stipulated that Trove is using AES CBC in some manner that is inappropriate; what are these more complex crypto issues that you speak of?

[Robert Clark (robert-clark)]

I'm happy to have more clarity provided by the reporters but based on the information available at present I see no serious security issues in using AES-CBC for data at rest encryption with Trove. As I pointed out, there may be more secure alternatives such as using GCM mode, however that would fall firmly into class D territory, as Morgan points out in the comment above.

[Tristan Cacqueray (tristan-cacqueray)]

Closing the OSSA task and marking this bug public, reason: D type of bug according to VMT taxonomy ( https://security.openstack.org/vmt-process.html#incident-report-taxonomy ).