Message-ID: <3564.81.207.0.53.1174495003.squirrel@secure.samage.net>
Date:	Wed, 21 Mar 2007 17:36:43 +0100 (CET)
From:	"Indan Zupancic" <indan@....nu>
To:	"Tasos Parisinos" <t.parisinos@...ensis.com>
Cc:	"Francois Romieu" <romieu@...zoreil.com>,
	herbert@...dor.apana.org.au, linux-kernel@...r.kernel.org
Subject: Re: [PATCH RESEND 1/1] crypto API: RSA algorithm patch (kernel     
                     version 2.6.20.1)

On Wed, March 21, 2007 16:50, Tasos Parisinos wrote:
> A malicious person may want to alter code on the detachable (and unsafe)
> file system.
> Lots of stuff including the kernel will be in a trapped casing (opening,
> probing it, power
> analyzing it, heating it etc will result in system suicide and erasure)

What happens ift he whole thing is cooled so much that it stops functioning?

What if the part that is supposed to do the system suicide is shot away?

There are all kind of interesting ways of bypassing such protections, I
wouldn't count on covering all of them (which doesn't mean you shouldn't try).


> If one alters one device then he can go on and play with it at home
> But if one finds the key that authenticates the executable code it will
> be possible to
> attack and tamper the non-system software on some of the networked devices
>
> That is why we can't use symmetric, the risk is a lot greater there. And
> of course
> we cant have one key per device (maybe thousands)

How many devices there are doesn't matter, a RSA key is ten times as big
as an AES key anyway. But maybe you've a more complex system where having
multiple keys indeed isn't possible (e.g. the filesystem is shared between
multiple devices).


>>> As for modprobe u are right but we also need to check (apart
>>> from kernel modules) the executables and libraries in the
>>> usage scenario.
>>>
>>
>> What about bytecode programs, self modifying software and mmap?
>> One exploitable bug in any program renders all this checking void.
>>
>> But even then you can move all the checking to a userspace helper program.
>> (Which can be in initramfs, glued to the kernel binary.)
>>
>>
> Of course we are talking about a restricted execution enviroment, no
> user logons
> the system runs what it is supposed to run, and only that
>
> If we where to use a userland program then we would propably have to
> physically
> secure the whole filesystem, and that is difficult, costs more, and it
> is cumbersome
> (difficult to update)

Not if you put it in initramfs included in the kernel binary.
Depending on how much room you have on the secured flash area,
you'd want to put as much as possible there anyway.


> You are not going to check all at once but only on load. I tell you
> again this is
> not going to be running as a web server, but in a restricted environment

Well, as the filesystem isn't restricted you should be prepared for anything.

Is the RAM in restricted area or not? Because if it isn't and they have
access to the bus then it can be tampered with.

> As for the code bloat and complexity... well you know its up to u to use
> it or leave it
> dont include where you don't need it.
> I mean we created for our specific use, other may want to use it to
> (maybe for
> the same reasons, who knows) why not make it available? Isn't that what
> open source
> is about?
>
> And on the bottom line, why not have a module and functionality that Linux
> competitors provide and advertise?

I've nothing against your RSA implementation, it's one of the cleaner and
smaller ones. Merging it is probably a good idea to stop others and to have
a minimalistic reference implementation.

I've problems with the assumed security it brings to many uses of it though.

Depending on the expected lifetime of your product I'd also consider using
something that can't be broken by quantum computers in the (near?) future. ;-)

Good luck,

Indan


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists