Score:0

What encryption system to use if the parts of the message are known?

be flag

I want to encrypt a system firmware, and future firmware updates will use the same encryption system. Because this firmware isn't fully from scratch but rather is based on an existing framework, it is highly likely that parts of the original firmware code are known, in other words, that long sequences of the message to encrypt would be known to any attacker (some of which are known to be full 1 and full 0s)

Considering this, can I merely use, say, AES, that preserves the sequence of the 128 bit blocks ? Or must I use a specific encryption tailored to such a use case ? I don't know if it's still robust against an attacker that has unencrypted/crypted block pairs, and I'm having trouble finding information on that use case.

I would guess that it is, but I'd rather verify. Thanks.

forest avatar
vn flag
It really depends on your security goals and how you implement the encryption. Do you want to detect modified firmware and refuse to execute it, or prevent the firmware from being readable? What mode of operation are you using AES in? Where does the key come from? What is doing the decrypting? How are you verifying integrity? The simple question as to whether or not AES is vulnerable to a known plaintext attack (an attack that is made possible when you have plaintext/ciphertext pairs), the answer is no.
kelalaka avatar
in flag
And, how do you keep the encryption key? You have a long way to go. Even [Xilinx had mistakes](https://crypto.stackexchange.com/a/88822/18298)
Julien BERNARD avatar
be flag
@forest I'm in the annoying position of having to use a non-secure external flash for that device, yet still care about the firmware not being analyzed. So the key... has to be in the flash too (itself encrypted in some ways). So it's really about making it as hard as possible to analyze rather than impossible. I guess there are two separate problems: making it so firmware updates can't be analyzed on their own and making it as difficult as possible to analyze the firmware/clone the device once you reach the flash. Thanks for your answer, I didn't know it was called a plain text attack.
Julien BERNARD avatar
be flag
For firmware update integrity checks, my first thought is to embed some CRC inside the firmware updates pre-encryption. Are there concerns to be had about this ?
forest avatar
vn flag
@JulienBERNARD What you're describing is simply impossible. If the key is stored along with the firmware, it can be analyzed, usually quite easily, no matter how much you attempt to obfuscate the key. As for integrity checks, a CRC is fine if you just want to detect accidental corruption. If you don't have hardware which supports verification (i.e. the system will _refuse_ to execute the code if it doesn't have a valid signature, with the public key being burnt into the CPU itself), you can't verify it either.
Score:-1
gy flag

Regardless of the symmetric encryption schema (3DES, AES,...), I suggest you to use an Encryption Mode that can hide data patterns. If you use CBC as encryption mode your cipher text will be randomized by using a random IV (Initialization Vector). Then you can pass the IV to the receiver in plaintext.

forest avatar
vn flag
This really isn't a good answer because it doesn't address the hardware-specific concerns, and is a bit misleading anyway (using an IND-CPA construction isn't a solution to OP's problem).
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.