Searching \ for '[PIC] How secure are bootloaders?' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/devices.htm?key=pic
Search entire site for: 'How secure are bootloaders?'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] How secure are bootloaders?'
2008\11\14@030119 by Vitaliy

flavicon
face
How secure are the "out of the box" bootloaders available from Microchip? In
particular, I'm interested in a secure bootloader for the 16-bit PICs.

Obviously, I would want to protect both the bootloader and the application
code. So I'm guessing it comes down to two things:

   1. Protecting the bootloader code on the PIC
   2. Using strong encryption for the app code

I'm assuming I don't have much control over #1, the protection is only as
strong as Microchip makes it. But what about #2? Which encryption scheme
would be reasonably sufficient to protect the code?

Vitaliy

2008\11\14@035137 by Danny Miller

flavicon
face
Look up CodeGuard feature of 16-bit PICs:
http://techtrain.microchip.com/webseminars/documents/CodeGuard_100906.pdf

The tech stuff is in document DS70180 but I couldn't find the link to it
right off the bat.

Danny

Vitaliy wrote:
{Quote hidden}

2008\11\14@092353 by Harold Hallikainen

face
flavicon
face

> Look up CodeGuard feature of 16-bit PICs:
> http://techtrain.microchip.com/webseminars/documents/CodeGuard_100906.pdf
>
> The tech stuff is in document DS70180 but I couldn't find the link to it
> right off the bat.
>
> Danny


I wrote a bootloader for the 24H. CodeGuard is interesting. Once code
protect is enabled for the bootloader, the general segment can only call
code in the first 32 words (or something like that) of the boot segment.
Anything else will cause a fault. Also, interrupt vectors are redirected
when the processor is executing in the boot segment. My bootloader is a
web post bootloader, so it uses the TCP/IP stack to put the new code in
external flash, then copy the external flash to internal. The code to deal
with internal and external flash are in the boot segment. Since it would
be possible to bootload bad code into the general segment that would then
keep the TCP/IP stack from running (and preventing further bootloads), I
have another copy of the original code (factory installed) in the external
flash. Inside the box, you short two pins on a header and power the unit
up to reload that original code.

So, CodeGuard is interesting. A bit of a pain to work with if you have to
call the boot segment from outside or are using interrupts.

Harold

--
FCC Rules Updated Daily at http://www.hallikainen.com - Advertising
opportunities available!

2008\11\14@142514 by Vitaliy

flavicon
face
Harold Hallikainen wrote:
> I wrote a bootloader for the 24H. CodeGuard is interesting. Once code
> protect is enabled for the bootloader, the general segment can only call
> code in the first 32 words (or something like that) of the boot segment.
> Anything else will cause a fault. Also, interrupt vectors are redirected
> when the processor is executing in the boot segment. My bootloader is a
> web post bootloader, so it uses the TCP/IP stack to put the new code in
> external flash, then copy the external flash to internal. The code to deal
> with internal and external flash are in the boot segment. Since it would
> be possible to bootload bad code into the general segment that would then
> keep the TCP/IP stack from running (and preventing further bootloads), I
> have another copy of the original code (factory installed) in the external
> flash. Inside the box, you short two pins on a header and power the unit
> up to reload that original code.
>
> So, CodeGuard is interesting. A bit of a pain to work with if you have to
> call the boot segment from outside or are using interrupts.

So does this mean that you don't encrypt the updates? This was the second
part of my original question. :)

Vitaliy

2008\11\14@150857 by Harold Hallikainen

face
flavicon
face

{Quote hidden}

Yes, this means I don't encrypt updates. Updates are emailed to individual
technicians in the field instead of being put on a website. There is the
danger of them being passed around, but I don't think it's worth while for
someone to reverse engineer our hardware. I may want to do some sort of
encryption in the future. I know Microchip has a library for that, but
have not looked at it.

Harold


FCC Rules Updated Daily at http://www.hallikainen.com - Advertising
opportunities available!

2008\11\14@162714 by Bob Axtell

face picon face
I have written several bootloaders, two were VERY secure. Access was
easy, but the data
is very scrambled, and the keys are subtle (Kids, can you say "square roots"?).

I think you can write your own pretty easily...

--Bob

On Fri, Nov 14, 2008 at 1:01 AM, Vitaliy <spam_OUTspamTakeThisOuTspammaksimov.org> wrote:
{Quote hidden}

> -

2008\11\15@165510 by Vitaliy

flavicon
face
Bob Axtell wrote:
>I have written several bootloaders, two were VERY secure. Access was
> easy, but the data
> is very scrambled, and the keys are subtle (Kids, can you say "square
> roots"?).
>
> I think you can write your own pretty easily...

Thanks for the vote of confidence, but I am new to bootloaders, and think
that it may actually make business sense to contract out this part of the
project. I would like to understand my options, though.

I know I would like to avoid "securty by obscurity", in other words I'd like
it to be difficult to crack the code even if the attacker understands the
encryption mechanism. However, I am not at all sure where to begin. The only
good news is, I have plenty of time to do the research. :)

Vitaliy

2008\11\17@040048 by Alan B. Pearce

face picon face
>Thanks for the vote of confidence, but I am new to bootloaders, and
>think that it may actually make business sense to contract out this
>part of the project. I would like to understand my options, though.
>
>I know I would like to avoid "securty by obscurity", in other words
>I'd like it to be difficult to crack the code even if the attacker
>understands the encryption mechanism. However, I am not at all sure
>where to begin. The only good news is, I have plenty of time to do
>the research. :)

Having just done a university unit that included error correcting codes, I
get the impression that one could use an error correcting code to obfusicate
the downloadable data.

Using a code that can correct multiple bit errors in a block, and ALWAYS
send each block with an error, in such a manner that a repeated sequence has
the error in different places would seem to provide a reasonable modicum of
security.

2008\11\17@042654 by Wouter van Ooijen

face picon face
>> I know I would like to avoid "securty by obscurity", in other words
>> I'd like it to be difficult to crack the code even if the attacker
>> understands the encryption mechanism. However, I am not at all sure
>> where to begin. The only good news is, I have plenty of time to do
>> the research. :)
>
> Having just done a university unit that included error correcting codes, I
> get the impression that one could use an error correcting code to obfusicate
> the downloadable data.

Which is exactly *not* what is asked for. Obfuscating works - if at all
- only when the opponent does not know the algorithm.

--

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu

2008\11\17@044214 by Xiaofan Chen

face picon face
On Fri, Nov 14, 2008 at 4:01 PM, Vitaliy <.....spamKILLspamspam@spam@maksimov.org> wrote:
> How secure are the "out of the box" bootloaders available from Microchip? In
> particular, I'm interested in a secure bootloader for the 16-bit PICs.
>
> Obviously, I would want to protect both the bootloader and the application
> code. So I'm guessing it comes down to two things:
>
>    1. Protecting the bootloader code on the PIC
>    2. Using strong encryption for the app code
>
> I'm assuming I don't have much control over #1, the protection is only as
> strong as Microchip makes it. But what about #2? Which encryption scheme
> would be reasonably sufficient to protect the code?

This blog post has some links about bootloader.
http://mcuee.blogspot.com/2007/11/i-am-trying-to-collect-list-of.html

Maybe you can find some ideas from the links. Some of
them have encryption support.

Xiaofan

2008\11\17@065434 by Isaac Marino Bavaresco

flavicon
face
Wouter van Ooijen escreveu:
>> I use AES (128-bit symmetric key cryptography) with authentication, so
>> nobody else can upload anything to my hardware.
>>    
>
> This might be a good choice, but
>
> - is "nobody else can upload anything to my hardware" the real issue? I
>  
To me, yes. If somebody can upload anything to my hardware, then he/she
may read the boot-loader and transmit it to a PC where it can be
analyzed (not true for dsPICS with CodeGuard, but for most PICs this is
a concern).

With the boot-loader in hands, they defeat any other mechanism I add to
protect the firmware.

> would guess most people are more concerned about a third party copying
> their software to cloned hardware.
>  
This is the main concern, of course.
> - don't be too firm about your statement. two PICs with the bootloaders,
> a few $1000 (or $10k's, I have no first-hand experience) will get me the
> dump of your chips. Illegal, and costly, but not difficult.
>  
Unfortunately this is a risk everybody is subjected to. Just hope the
benefit is not worth the cost for the attacker.

There are lines of 'secure' micro-controllers that may be used for
projects that are worth the cost of physically hacking the chip. Not
perfect, but much more costly to crack.

__________________________________________________
Faça ligações para outros computadores com o novo Yahoo! Messenger
http://br.beta.messenger.yahoo.com/

2008\11\17@072740 by Wouter van Ooijen

face picon face
> There are lines of 'secure' micro-controllers that may be used for
> projects that are worth the cost of physically hacking the chip. Not
> perfect, but much more costly to crack.

Philips/NXP Mayfair classic? :)

--

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu

2008\11\17@074207 by Alan B. Pearce

face picon face
>Which is exactly *not* what is asked for.

Well, it is really.

>Obfuscating works - if at all - only when the
>opponent does not know the algorithm.

Which is true of any secure bootloader.

Realistically all the OP is looking for is a way of distributing a software
update without anybody between the software provider and the destination
hardware being able to disassemble it to get at the IP. Precisely how this
is done is up to the bootloader writer.

2008\11\17@080521 by Wouter van Ooijen

face picon face
Alan B. Pearce wrote:
>> Which is exactly *not* what is asked for.
>
> Well, it is really.

Only when asuming you know better than the one who asked...

>I know I would like to avoid "securty by obscurity", in other words
>I'd like it to be difficult to crack the code even if the attacker
>understands the encryption mechanism.

--

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu

2008\11\17@080955 by Isaac Marino Bavaresco

flavicon
face
Alan B. Pearce escreveu:
>> Which is exactly *not* what is asked for.
>>    
>
> Well, it is really.
>
>  
>> Obfuscating works - if at all - only when the
>> opponent does not know the algorithm.
>>    
>
> Which is true of any secure bootloader.
>
> Realistically all the OP is looking for is a way of distributing a software
> update without anybody between the software provider and the destination
> hardware being able to disassemble it to get at the IP. Precisely how this
> is done is up to the bootloader writer.
>  

Just 'obfuscation' is not a good approach. It is not secure to rely just
on 'secret algorithms'. It is much better to use a proven algorithm
(like AES, a very strong - until now- and light-weight one) with the
'secret' being the key.


It turns out that most 'home-made' algorithms are not as good as the
author thinks, and a bit of cryptanalysis break them easily (I have seen
several, some ridiculous). Just stick with the modern industry-standard
algorithms.


Everybody uses AES and it is resisting well, and 128-bit keys are good
enough to make physical attack to the chip a better approach.


__________________________________________________
Faça ligações para outros computadores com o novo Yahoo! Messenger
http://br.beta.messenger.yahoo.com/

2008\11\18@140522 by Bob Axtell

face picon face
I can write a bootloader for you at a reasonable cost, including the
WinXP application to convert and encrypt the hex file.

Let me know what PIC you are using (and its schematic) and I will give you
a quote. I'm just down here in Tucson (really Green Valley).  think you
are in Phoenix, right?

--Bob A


On Sat, Nov 15, 2008 at 2:55 PM, Vitaliy <spamspamKILLspammaksimov.org> wrote:
{Quote hidden}

> -

2008\11\20@024021 by Tamas Rudnai

face picon face
Just come across to this page, and I thought it somewhat related to this
subject:

http://www.cl.cam.ac.uk/~sps32/mcu_lock.html

Tamas



On Tue, Nov 18, 2008 at 7:05 PM, Bob Axtell <.....bob.axtellKILLspamspam.....gmail.com> wrote:

{Quote hidden}

2008\11\20@053057 by Isaac Marino Bavaresco

flavicon
face
Tamas Rudnai escreveu:
> Just come across to this page, and I thought it somewhat related to this
> subject:
>
> http://www.cl.cam.ac.uk/~sps32/mcu_lock.html
>
> Tamas
>  

This page is very instructional: <http://www.flylogic.net/blog/>

Isaac
__________________________________________________
Faça ligações para outros computadores com o novo Yahoo! Messenger
http://br.beta.messenger.yahoo.com/

2008\11\20@064040 by Vitaliy

flavicon
face
Bob Axtell wrote:
>I can write a bootloader for you at a reasonable cost, including the
> WinXP application to convert and encrypt the hex file.
>
> Let me know what PIC you are using (and its schematic) and I will give you
> a quote. I'm just down here in Tucson (really Green Valley).  think you
> are in Phoenix, right?

Bob, thank you for your reply, I will contact you off-list.

You're right, our company is located in north Phoenix.

Vitaliy

2008\11\20@072148 by Xiaofan Chen

face picon face
On Thu, Nov 20, 2008 at 7:30 PM, Isaac Marino Bavaresco
<isaacbavarescospamspam_OUTyahoo.com.br> wrote:
>> http://www.cl.cam.ac.uk/~sps32/mcu_lock.html
>>
>
> This page is very instructional: <http://www.flylogic.net/blog/>

Nice one.

But in the end, not many people have access to the
equipment they have. And I am not so sure if they
can legally provide services to others who want to
peek through the chips.

Xiaofan


'[PIC] How secure are bootloaders?'
2009\01\04@204551 by Matthew Mucker
flavicon
face
>
> It turns out that most 'home-made' algorithms are not as good as the
> author thinks, and a bit of cryptanalysis break them easily (I have
> seen
> several, some ridiculous). Just stick with the modern industry-standard
> algorithms.
>
>
> Everybody uses AES and it is resisting well, and 128-bit keys are good
> enough to make physical attack to the chip a better approach.
>
>

This is very true. Don't write your own crypto; use the time-tested crypto
that's out there.

AN1044 includes an AES library.
www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&
dDocName=en020158 includes an asymmetric library (but costs $$).

With crypto, protecting the data is no longer your primary concern; rather,
protecting the KEY is your primary concern. You can even put the decryption
code in non-code protected areas of RAM if you'd like, as long as you can
protect the key.

If you use asymmetric crypto in your bootloader, you can even guarantee that
a bad guy can't run his code on your device, because he'd need your private
key with which to encrypt the code.  Assuming you can keep that safe and you
put the public key in code-protected areas of the chip, you're reasonably
assured that bad guys can't read your code, nor can they put their code on
your device.




2009\01\05@093735 by Vitaliy

flavicon
face
>> Everybody uses AES and it is resisting well, and 128-bit keys are good
>> enough to make physical attack to the chip a better approach.

More on this subject:

http://www.seagate.com/staticfiles/docs/pdf/whitepaper/tp596_128-bit_versus_256_bit.pdf

Vitaliy

2009\01\06@115914 by M.L.

flavicon
face
On Mon, Jan 5, 2009 at 9:36 AM, Vitaliy <@spam@spamKILLspamspammaksimov.org> wrote:
>>> Everybody uses AES and it is resisting well, and 128-bit keys are good
>>> enough to make physical attack to the chip a better approach.
>
> More on this subject:
>
> http://www.seagate.com/staticfiles/docs/pdf/whitepaper/tp596_128-bit_versus_256_bit.pdf
>
> Vitaliy
>

I've implemented DES and RC5 in hardware if anyone needs help.
-
ML

2009\01\06@125447 by Vitaliy

flavicon
face
"M.L." wrote:
> I've implemented DES and RC5 in hardware if anyone needs help.

What do you mean, "in hardware"?


2009\01\07@170350 by M.L.

flavicon
face
On Tue, Jan 6, 2009 at 12:53 PM, Vitaliy <KILLspamspamKILLspamspammaksimov.org> wrote:
> "M.L." wrote:
>> I've implemented DES and RC5 in hardware if anyone needs help.
>
> What do you mean, "in hardware"?
>

Verilog, FPGA
if anyone needs help [with the algorithms]

2009\01\07@171223 by Marcel Birthelmer

picon face
On Wed, Jan 7, 2009 at 1:52 PM, M.L. <RemoveMEmTakeThisOuTspamlkeng.net> wrote:

> On Tue, Jan 6, 2009 at 12:53 PM, Vitaliy <spamBeGonespamspamBeGonespammaksimov.org> wrote:
> > "M.L." wrote:
> >> I've implemented DES and RC5 in hardware if anyone needs help.
> >
> > What do you mean, "in hardware"?
> >
>
> Verilog, FPGA
> if anyone needs help [with the algorithms]


I implemented MD5 in VHDL recently, if anyone's interested.
- Marcel

2009\01\07@195008 by Jake Anderson

flavicon
face
Marcel Birthelmer wrote:
> On Wed, Jan 7, 2009 at 1:52 PM, M.L. <TakeThisOuTmEraseMEspamspam_OUTlkeng.net> wrote:
>
>  
>> On Tue, Jan 6, 2009 at 12:53 PM, Vitaliy <RemoveMEspamspamTakeThisOuTmaksimov.org> wrote:
>>    
>>> "M.L." wrote:
>>>      
>>>> I've implemented DES and RC5 in hardware if anyone needs help.
>>>>        
>>> What do you mean, "in hardware"?
>>>
>>>      
>> Verilog, FPGA
>> if anyone needs help [with the algorithms]
>>    
>
>
> I implemented MD5 in VHDL recently, if anyone's interested.
> - Marcel
>  
Just a word to the wise, MD5 is pretty weak now cryptographically, If
your developing a new product you might want to look into SHA1 or some such.

2009\01\07@201828 by Marcel Birthelmer

picon face
> >
> > I implemented MD5 in VHDL recently, if anyone's interested.
> > - Marcel
> >
> Just a word to the wise, MD5 is pretty weak now cryptographically, If
> your developing a new product you might want to look into SHA1 or some
> such.
>

This was just for a school project. Of course you're right, there are better
algorithms around these days for use in the real world. In fact, here is a
rather neat demonstration of what a hash weakness implies:
http://th.informatik.uni-mannheim.de/People/lucks/HashCollisions/

- Marcel

More... (looser matching)
- Last day of these posts
- In 2009 , 2010 only
- Today
- New search...