LKML Archive on
help / color / mirror / Atom feed
From: Tasos Parisinos <>
To: Indan Zupancic <>
Cc: Francois Romieu <>,,
Subject: Re: [PATCH RESEND 1/1] crypto API: RSA algorithm patch (kernel   version
Date: Thu, 22 Mar 2007 09:47:26 +0200	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

> 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).
I really can't comment more on these... you understand that in that case 
i would give away some interesting
security details... ;) But i tell you that things have evolved, i am 
even suprised to see these pieces of hardware
work against lots (i mean lots) of kinds of attacks. If you search a 
little you will find lots of hardware security
solutions on the market. Of course having the money to obtain them is 
another issue. Of course it also needs
a lot of paperwork and NDAs

>> 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).
it would be a mess to do desent key management

>> 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.
RAM will be restricted, we try to do the best we can on filesystem.
>> 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
Well in our design the most HOT data will be inside chips that you need 
serious equipment (and money)
to tamper with. But these have our own OS running. Even if someone 
breaks the signed modules system he can do
damage but not to such an extent. We understand that this is not 
unbreakable (yes, no assumed super-security) ,
but we need to do it as hard as we can for others to intrude.
This is going to work as the first security-barrier.

Well with quantum, RSA will be obsolete. Also elliptic curve is now 
becoming more and more popular
But the RSA is nowadays in common use, ranging from payment systems to 
the military. It will take some years
for this to change

Thanks for your interest and usefull comments

Tasos Parisinos

  reply	other threads:[~2007-03-22  7:48 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-03-19 16:22 Tasos Parisinos
2007-03-19 22:58 ` Matt Mackall
2007-03-20 14:44   ` Tasos Parisinos
2007-03-20 15:15     ` Matt Mackall
2007-03-20 16:36       ` Jan Engelhardt
2007-03-20 15:43   ` Paulo Marques
2007-03-20  0:40 ` Francois Romieu
2007-03-20 14:11   ` Tasos Parisinos
2007-03-20 15:09     ` James Morris
2007-03-20 15:40       ` Tasos Parisinos
2007-03-20 21:43     ` Indan Zupancic
2007-03-21  9:15       ` Tasos Parisinos
2007-03-21 12:08         ` Indan Zupancic
2007-03-21 12:34           ` Tasos Parisinos
2007-03-21 13:00             ` Indan Zupancic
2007-03-21 23:31           ` David Schwartz
2007-03-22 13:15             ` Indan Zupancic
2007-03-21 12:36         ` Indan Zupancic
2007-03-21 13:07           ` Tasos Parisinos
2007-03-21 13:59             ` Indan Zupancic
2007-03-21 14:31               ` Tasos Parisinos
2007-03-21 15:10                 ` Indan Zupancic
2007-03-21 15:50                   ` Tasos Parisinos
2007-03-21 16:36                     ` Indan Zupancic
2007-03-22  7:47                       ` Tasos Parisinos [this message]
2007-03-21 14:49               ` Tasos Parisinos

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \
    --subject='Re: [PATCH RESEND 1/1] crypto API: RSA algorithm patch (kernel   version' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).