des/aes bootloaders revisited

Go To Last Post
66 posts / 0 new

Pages

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Exactly.
I didn't mention a couple of 'details'...

I use the SiLabs 2101 USB to serial bridge (same as the FTDI). This allows me to connect the RTS & DTR lines to the micro. I use one line to tell the micro to enter/stay in bootloader mode and the other to reset the micro.

By asserting the appropriate handshaking lines the 'distribution app' can always get control of the micro - (provided the bootloader is present - of course)

HTH
Ivan

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
I didn't mention a couple of 'details'...
The devil IS in the details.. :)
So, I will make provisions for the unused RTS & DTR signals from the FTDI chip to make their way to the reset line and the bootloader select input pin via diodes...just in case.

Some people are SOooo sneakerly clever and seeing that both pins are easily controllable with VB2005 who knows where this can go.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

js

Don't forget that VB2005 code is easily disassembled. You can run an obfuscator on it, which may help.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I worked on the AES port GCC a little last night. We're well under the 2K mark now if anyone wants to be the guinea pig let me know ;)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Who else...

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
We're well under the 2K mark
with or without the buffer overrun feature?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
with or without the buffer overrun feature?

Which one ;) The one that really stuck out was indexing the buffer straight from a serial stream without any boundary checks! yikes!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

That's the one (frameSize/rxBuffer).

I still have a couple things I think are possible weaknesses, but I'm still in 'Encryption Preschool' so what do I know.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
That's the one (frameSize/rxBuffer).

I still have a couple things I think are possible weaknesses, but I'm still in 'Encryption Preschool' so what do I know.

Consider me a fellow classmate.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Don't know if it's any useful for anyone, but I came across this complete port of app note AVR231 with windows utilities on the ImageCraft website.

here

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
I came across this complete port...
St. John had mentioned it above:
Quote:
"USB carrying members" of the middle class people's compiler can download the ported version from the download page of that company.

but it's nice to have the link. Thanks!

Chuck Baird

"I wish I were dumber so I could be more certain about my opinions. It looks fun." -- Scott Adams

http://www.cbaird.org

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I scan-read this whole thread for a reference to the link I found, but I missed it apparently :)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well on the subject of DES or AES for a bootloader.
The issue of the bootloder is that it is as small as possible.
And for des decrypt I will need 1780 bytes, and for AES decrypt small flash 904 bytes.
Some people think that 2 k is small for AES, in that size you will get RSA included for free. :wink:
For the code and timing see emsign.nl

On the security part AES is better then DES or triple des, so that is also not an issue.
But as descried the problem in real security is that the AVR are not secure devices and that you can get the Key out of a locked AVR.
But it will stop someone making small modifications to your code and downloading it.

What a more secure way is to use RSA to make a bootloader.
This is because DES and AES used the same key to encrypt and decrypt and that you will need to have this key in the device at the customer site.
In RSA you have a key pair, and you will have only the decrypt key ( Public key ) at the customer site.
And the RSA decrypt is only 690 bytes in code size, but it will take up a 3 times the key size in ram.

What also is an option is Skipjack as this only used 520 bytes of code,

My Conclusion
1) RSA
2) AES
3) Skipjack
4) DES

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
In RSA you have a key pair, and you will have only the decrypt key ( Public key ) at the customer site.
I have said before, I'm in 'Encryption Preschool', but I don't see what benefit RSA would have over symmetric encryption. Either way, once they can decrypt the firmware updates (with the key, or 'getting' the bootloader code), its over. With the symmetric key, the only advantage is you can keep using the existing bootloader. But it doesn't matter, since you can just do a chip erase and forget about the bootloader. Which means in the case of RSA, there is no need to encrypt any modified firmware, so there is no need to acquire the private key. Whoever can decrypt, wins.

Unless I'm missing something.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

any progress?

Pages