1

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.

nyholku
  • 13
  • 2
  • 3
    How do you plan to keep the key XTEA_KEY secret? It's going to be right in the bootloader. – fgrieu Jul 19 '17 at 20:09
  • 1
    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. – nyholku Jul 20 '17 at 05:37
  • 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. – fgrieu Jul 20 '17 at 11:34
  • The bootloader/host protocol is here: http://usb-pic.org/bootloader-commands – nyholku Oct 04 '17 at 12:44
  • 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. – fgrieu Oct 04 '17 at 12:49
  • Located a 2008 version of the source code of the encoder in a subfolder in there. There's a 686kB configure, 270kB m4 script, 182kB shellscript, 80kB in 26 C/C++ header files, and 70kB in 20 C/C++ source files. There's no doc on the protocol that I could find; NEWS and README are empty for the encoder, and what I glanced at elsewhere documents use, not internals. That's way too much to be quickly auditable, and I run away in a self-preservation gut instinct. – fgrieu Oct 04 '17 at 13:06

1 Answers1

1

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.

Maarten Bodewes
  • 92,551
  • 13
  • 161
  • 313