1
$\begingroup$

I'm using this bootloader that implements XTEA encryption for uploading an encrypted firmware to small MCU:

https://github.com/nyholku/diolan-plus2

the actual XTEA code is here:

https://github.com/nyholku/diolan-plus2/blob/master/fw/xtea.asm

It is not my code but to me it looks like it uses 16 byte key and 64 iterations and seems to be pretty much equivalent to the wikipedia XTEA C-implementation.

Now my questions is, is my encryption key safe if I publish my firmware both as plain object code i.e. plain text and encrypted?

The firmware size if max 48kB out of which several kilobytes at the end will be 0xFF.

How about if over the years I publish number of ( <50 ) such plain text / encrypted text pairs?

I've read from the interweb that this should be safe but because the subject is so complex I would like to make sure I don't make a rookie blunder.

$\endgroup$
  • 3
    $\begingroup$ How do you plan to keep the key XTEA_KEY secret? It's going to be right in the bootloader. $\endgroup$ – fgrieu Jul 19 '17 at 20:09
  • 1
    $\begingroup$ the bootloader is programmed by me to the chip PIC18F45K50 which has fuses that can be set so that the code cannot be read back. As it is single chip I think that part of the solution is pretty safe. $\endgroup$ – nyholku Jul 20 '17 at 5:37
  • $\begingroup$ I second Maarten Bodewes that there is not strong fear to have that the key could be recovered from plaintext/ciphertext pairs. I would fear extraction of the key from the bootloader e.g. by glitching the power supply during reset to make the CPU believe that the security "fuse" (probably some Flash/EEPROM memory bit) is not blown, then using the built-in debug port. And, independently, abusing the protocol/mode of operation using XTEA as a building block; is that described anywhere? I can't make an interesting answer without this. $\endgroup$ – fgrieu Jul 20 '17 at 11:34
  • $\begingroup$ The bootloader/host protocol is here: usb-pic.org/bootloader-commands $\endgroup$ – nyholku Oct 4 '17 at 12:44
  • $\begingroup$ This describes commands, like BOOT_WRITE_FLASH, but not a protocol. The later page leads to an encoder application, but the link to its source code is broken. What I see is not sufficient to determine if there is integrity, and leaves it doubtful that the protocol is secured against power loss during loading. Sorry, I can't say better than XTEA probably not being the weakest link. $\endgroup$ – fgrieu Oct 4 '17 at 12:49
1
$\begingroup$

What you are describing is called a known plaintext attack. Modern ciphers should be even secure if the adversary chooses the plaintext to encrypt. That would be called a chosen plaintext attack (CPA), and a cipher that protects against is called CPA-secure. Actually, it goes even a bit further than that: IND_CPA means that the ciphertext is indistinguishable from random even if the adversary choses the plaintext.

Basically you can publish any amount of pairs and still be secure. This of course isn't the case anymore if the cipher gets broken. The cipher is completely broken if a key can be retrieved by a CPA attack. Fortunately no such attack is known against XTEA. But note that there are no ciphers that can be proven to be secure.

However, XTEA is a block cipher. A block cipher isn't a generic cipher by itself. It needs a mode of operation to turn into a real cipher. This mode of operation should be initialized using an initialization vector. Without a unique or random initialization vector the ciphertext may leak information about the plaintext. For instance, if you would encrypt two different versions of the same firmware you could see where changes were made.

$\endgroup$
  • $\begingroup$ I've answered directly, you should still heed the comment made by fgrieu directly below your question. $\endgroup$ – Maarten Bodewes Jul 19 '17 at 21:11
  • $\begingroup$ can you elaborate on the initialization vector? I do not readily see how how can I add randomness to the anywhere.. guess I need to google more ;) $\endgroup$ – nyholku Jul 20 '17 at 5:49
  • $\begingroup$ I've added a link to the Wikipedia article about modes of operation. The IV and the properties of the IV (nonce or randomized IV) are part of the mode of operation used. $\endgroup$ – Maarten Bodewes Jul 20 '17 at 7:07

Your Answer

By clicking "Post Your Answer", you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.