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: Wed, 21 Mar 2007 17:50:26 +0200	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

>> I agree that you have no more security that using symmetric
>> but we believe you have lower costs, simpler key management
>> (which is a big headache alone), tougher to break through
>> (not unbreakable) and more centralization
> It depends a bit on who you want to give control over what can and what
> can't be loaded whether centralization is an advantage or not. It might
> be a bit easier and simpler for the vendor, but if users have control
> over their hardware and thus the keys, it doesn't make any difference.
> Even for the vendor it isn't very hard to keep a database with all keys
> and signing modules with the right key when needed.
> I don't see where the lower cost or the increased toughness comes from.
> Don't forget that you need to protect the stored public key against
> modification as well (As well as the boot loader).
We developed this for an embedded device that runs Linux in which
it is crucial to reach the highest point of security possible
having in mind previous experience on signed executable code
developing under WindowsCE. The end user has nothing to do with the 
system, no logons

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)

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)
>> 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 
secure the whole filesystem, and that is difficult, costs more, and it 
is cumbersome
(difficult to update)
>> About time:
>> In my pc system running (2.66 GHz P4, 1G mem) the computation of
>> modular exponentiation of 1Kbit (with a 32bit exponent all bits set and
>> a 1024 bit key)
>> took almost 3ms. That's the time needed to check the signature of any
>> code loaded
>> in ram using this module, after having it hashed (sha1) and signature
>> extracted from elf.
> Time was never the problem, the extra code bloat and complexity is.
> (Though if you're going to check all binaries it probably is.)
> Greetings,
> Indan
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

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?

Best Regards
Tasos Parisinos

  reply	other threads:[~2007-03-21 15:50 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 [this message]
2007-03-21 16:36                     ` Indan Zupancic
2007-03-22  7:47                       ` Tasos Parisinos
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).