Prev: Keil C51/ 8051 port of uIP v0.9 TCP/IP stack.
Next: TCP/IP stack for GPRS
From: R Adsett on 18 Feb 2005 14:38
In article <111cdmi6nld3e4(a)corp.supernews.com>, Guy Macon
<http://www.guymacon.com/> says...
> Oliver Betz wrote:
> >I'm talking about a microcontroller flash loader with encryption to
> >allow SW updates in the field without disclosure of the code.
> >
> >If somebody can break the microcontroller's security, it's no more
> >important to keep the key secret because he can access the protected
> >stuff directly (without using the key). That's what I wanted to write
> >in my last posting.
> >
> >So why shouldn't the key be stored in this internal, more or less
> >"protected" memory?
>
> Why encrypt then? Why not just store whatever you were planning
> to encrypt in this internal, more or less "protected" memory?
> The result is the same.

I think he wants to encrypt it to protect it during the period from when
it leaves his hands until it's loaded internally in the micro. Think of
it as sneaker-ssl.

Robert
From: Oliver Betz on 18 Feb 2005 14:51
"Wim Ton" <wimton(a)blueyonder.co.uk> wrote:

[known plaintext attack for executables]

>Executables have a lot of redundancy. (An Intel .exe can be zipped to 35% of
>the original)
>Most executables have pedictable parts, like the startup code and push/pop
>everything

Maybe message strings are worst if not runtime descrambled (which
would cause annoying coding). Startup code must not be known (for
example, I don't use the startup code provided by the compiler
manufacturer). push/pop sequences are short. After all, the positions
of all these code portions are unknown, therefore a noticeable part of
the code has to be tested - likely much more than twice the length of
the LFSR possible with known plaintext at known position.

>The key of a LFSR is the initial condition.

And the polynomial.

>So try all initial conditions and see when the output entropy drops below
>0.5, you do not even have to know the plaintext.

A brute force attack is always possible but can be made enough
expensive, I guess.

Oliver
--
Oliver Betz, Muenchen (oliverbetz.de)
From: Oliver Betz on 18 Feb 2005 14:51
Guy Macon <http://www.guymacon.com/> wrote:

[...]

>>So why shouldn't the key be stored in this internal, more or less
>>"protected" memory?
>
>Why encrypt then? Why not just store whatever you were planning
>to encrypt in this internal, more or less "protected" memory?

as I wrote: field updates. Done by "untrusted" people.

>The result is the same.

The result is certainly the same, but the method is not feasible since
I can't access the controller "in the field".

Oliver
--
Oliver Betz, Muenchen (oliverbetz.de)
From: Guy Macon on 18 Feb 2005 17:07



Oliver Betz wrote:

>A brute force attack is always possible but can be made enough
>expensive, I guess.

Make the key 128 bits that you downloaded from hotbits and it
will always be too expensive - the universe is too small and
too young to do the computation in. Make it 256 bits and
it will be too hard to ever do squared. That's only 32 bytes
of ROM to hold your key. but its 2^256 (roughly 10^77) guesses
to do a brute force attack.

--
Guy Macon <http://www.guymacon.com/>

From: Guy Macon on 18 Feb 2005 17:14



Oliver Betz wrote:
>
>Guy Macon <http://www.guymacon.com/> wrote:
>
>>>So why shouldn't the key be stored in this internal, more or less
>>>"protected" memory?
>>
>>Why encrypt then? Why not just store whatever you were planning
>>to encrypt in this internal, more or less "protected" memory?
>
>as I wrote: field updates. Done by "untrusted" people.
>
>>The result is the same.
>
>The result is certainly the same, but the method is not feasible since
>I can't access the controller "in the field".

Got it. That will work. Is your hardware such that the untrusted
people doing the field updates can overwrite the key inside the
contoller? I think not if you write the updating code - which you
would have to do anyway to add encryption.

Take a look at my post about AES, RC4 and ciphersaber. Let me know
if any of it doesn't make sense.

BTW, roughly how much RAM, ROM, and cycles can you afford to use
up during the update? (the RAM can be used for other things
afterwards, of course, and flash will work as RAM for the algos
I am talking about - with the usual speed penalty).

--
Guy Macon <http://www.guymacon.com/>

First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: Keil C51/ 8051 port of uIP v0.9 TCP/IP stack.
Next: TCP/IP stack for GPRS