Join Log in
Score:2
avatar Crypto

What can an attacker do with this in-secure usage of AES-CFB8?

in flag
katoriw701

I believe I have found insecure usage of AES-CFB8 in an application I am working on and would hope someone could explain how and why this is insecure and what an attacker could do such as key recovery as that would be the worse result for this protocol.

Basically AES-CFB8(explicitly without padding) is used to encrypt a stream of data and the IV/key are reused between the server and client streams and the IV is the same as the key. How in-secure is this and is it possible for an attack to recover the iv/key from this. The key used for AES is a shared secret that could compromise more then just the original packet stream as the stream that has this possible in-secure usage is not as sensitive but it would be a bigger problem if the key used was be compromised.

public static SecretKey generateSharedSecret() {
   final KeyGenerator gen = KeyGenerator.getInstance("AES");
   gen.init(128); // AES-128
   return gen.generateKey();
}

// Decided by client and sent in a secure way to server via RSA and validated via a trusted source.
final SecretKey sharedSecret = generateSharedSecret();

 // This is done on both the server and client after the server has received the shared secret. 
 final Cipher aesCFBEncrypt = Cipher.getInstance("AES/CFB8/NoPadding");
 aesCFBEncrypt.init(Cipher.ENCRYPT_MODE, sharedSecret, new IvParameterSpec(sharedSecret.getEncoded()));

 final Cipher aesCFBDecrypt = Cipher.getInstance("AES/CFB8/NoPadding");
 aesCFBDecrypt.init(Cipher.DECRYPT_MODE, sharedSecret, new IvParameterSpec(sharedSecret.getEncoded()));

 this.enableStreamEncryption(aesCFBEncrypt, aesCFBDecrypt);

I have looked around for similar issues but none I have found fit the criteria I am interested about that is usage of the cipher as a stream with different instances for RX/TX on the client and server and usage of key as iv without having a different key for the server and client.

80
0 + 0
aes
SAI Peregrinus avatar
si flag
SAI Peregrinus
Why CFB? That's not a commonly available mode, and it's not AE-secure, so the answer is "no" even ignoring the other issues with this.
0
Reply
in flag
katoriw701
@sai-peregrinus I have no idea why CFB was used, this code was written over a decade ago but someone who is not me. I am aware the stream itself can be manipulated but the underlying protocol has mechanisms to make this hard or impossible in real time. Assume the underlying protocol is using MAC-then-Encrypt for authentication. This is code analysis of a legacy program, not self rolling bad crypto usage for a new protocol if you are assuming that. Many mistakes and bad practices have been made here and may only work due to luck but I am wondering about any practical attacks.
0
Reply
in flag
katoriw701
@SAIPeregrinus I am more interested in if the shared secret used with the cipher and if that can be recovered rather then attempts to manipulate the plain-text if that makes sense as those are not an issue unless someone has full control and can read and write the plain-texts in both directions of the stream. The only reason why encryption is used at all is because of previous MITM attempts via social engineering that never caused any real harm.
0
Reply
Score:2
Maarten Bodewes avatar Crypto
in flag
Maarten Bodewes

If the key and IV are identical then the first intermediate value after the block encrypt that is XOR'ed with the first byte is also identical between two encryption operations. That means that if the first byte of plaintext is identical then this will result in identical ciphertext, leaking information to a possible attacker.

Of course, this ciphertext is also propagated into the shift register that currently holds the IV. One byte of the IV is shifted out to the left (MSB), and ciphertext byte is placed at the right (LSB). So now the next encryption will again result in identical intermediate value. This means that the next identical plaintext byte will also directly leak data, and so on and so forth. Of course, if you have many messages then you can make many pairs, so the leakage of data is more likely.

Only if the plaintext bytes differ between messages then the propagation stops. However, these final bytes form a problem in themselves. The differing plaintext have been XOR'ed with identical intermediate values to create the ciphertext bytes. That means that the XOR of the ciphertext bytes results in the XOR of the plaintext bytes. This may well directly leak data, and again, the more ciphertext bytes are known, the more combinations can be made.

On the bright side: the IV stored in the shift register. As it is only used as input to the block cipher it is likely that the value of the IV and thus key is relatively well protected.

If low level side channel attacks are possible then it may be possible to identify some key bits during the shift operation, but you'd probably need a lot of operations before any IV / key data could be extracted. As I've been surprised by side channel attacks before I think it should be considered though.

Not only shouldn't you use key data as IV (using a hash over the IV would already have been better), but you should also not re-use the key for different purposes.

I would be very skeptical to the security of the protocol you've described due to these cryptographic bad practices - although the use of CFB-8 mode is probably already enough indication that the designers of the protocol didn't know what they were doing.

0 + 0
Maarten Bodewes avatar
in flag
Maarten Bodewes
In other words: ?REDO FROM START...
0
Reply
Score:-1
SAI Peregrinus avatar Crypto
si flag
SAI Peregrinus

No, this is not secure. The IV is sent unencrypted. Since the IV is also used as the key, this is essentially the same as sending unencrypted data. It might stop a casual attacker, but it won't stop anyone determined.

It also seems like you might be re-using the same IV for multiple messages. That voids the security claims of CFB, even if it were kept secret. You may want a misuse-resistant mode like AES-GCM-SIV, if you can't guarantee a new IV for every message.

0 + 0
in flag
katoriw701
The IV is never sent, the IV is the same as the key unless this is an implementation detail of AES-CFB that it includes the IV in the cipher text but I doubt that. "It also seems like you might be re-using the same IV for multiple messages. That voids the security claims of CFB, even if it were kept secret." This is the explanation I want to know more about and how does it break down? I am more interested in why it is bad rather then it is bad because I am aware of IV reuse and IV as key (IV is never generated randomly per msg or sent).
0
Reply
ธงชาติไทย
Elon Musk
I sit in a Tesla and translated this thread with Ai:

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.