Prev: Keil C51/ 8051 port of uIP v0.9 TCP/IP stack.
Next: TCP/IP stack for GPRS
From: Guy Macon on 17 Feb 2005 20:43



Oliver Betz wrote:
>
>"Wim Ton" <wimton(a)blueyonder.co.uk> wrote:
>
>>Guy Macon has a very sensible point: where to store the key securely,
>
>Has the key to be stored more secure than the data to be protected? If
>somebody can access the key, he can access the whole protected
>program, can't he?

Yes. It's like shipping someone a case-hardened steel box with
a high security lock and taping the key to the lid.

So forget about XBox attacks, lsfr attacks, etc. The whole scheme
is hosed.

If someone does figure out how to solve the key problem, using AES
or RC4 encryption will make it resistant to all known attacks.
Note the "If".





From: Chris Hills on 17 Feb 2005 19:40
In article <421446cc.1009409(a)z1.oliverbetz.de>, Oliver Betz
<OBetz(a)despammed.com> writes
>
>And I have to buy (and read) Bruce Schneier's book after all to avoid
>asking more stupid questions in newsgroups <g>.
>
>Oliver

Then, if you are outside the US go to my web site and get the sources.

If you are inside the US you can get a CD with all the sources (it used
to be in the book). However they won't ship the CD outside the US for
"security reasons".



/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/\
/\/\/ chris(a)phaedsys.org www.phaedsys.org \/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
From: Oliver Betz on 18 Feb 2005 09:27
Guy Macon <http://www.guymacon.com/> wrote:

>>>Guy Macon has a very sensible point: where to store the key securely,
>>
>>Has the key to be stored more secure than the data to be protected? If
>>somebody can access the key, he can access the whole protected
>>program, can't he?
>
>Yes. It's like shipping someone a case-hardened steel box with
>a high security lock and taping the key to the lid.

Maybe I'm a bit slow, maybe there is a misunderstanding.

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?

Oliver
--
Oliver Betz, Muenchen (oliverbetz.de)
From: Wim Ton on 18 Feb 2005 13:28
> >You can guess it, if you know more or less what the plaintext will look
> >like.
>
> "less" in usual executables. There are known sequences, but sparse and
> at unknown places. So most times, one has to check large ortions of
> the encrypted data making a brute force attack slower.
>
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
The key of a LFSR is the initial condition.
So try all initial conditions and see when the output entropy drops below
0.5, you do not even have to know the plaintext.

Wim


From: Guy Macon on 18 Feb 2005 13:32



Oliver Betz wrote:
>
>Guy Macon <http://www.guymacon.com/> wrote:
>
>>>>Guy Macon has a very sensible point: where to store the key securely,
>>>
>>>Has the key to be stored more secure than the data to be protected? If
>>>somebody can access the key, he can access the whole protected
>>>program, can't he?
>>
>>Yes. It's like shipping someone a case-hardened steel box with
>>a high security lock and taping the key to the lid.
>
>Maybe I'm a bit slow, maybe there is a misunderstanding.
>
>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.

--
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