LKML Archive on
help / color / mirror / Atom feed
From: "Indan Zupancic" <>
To: "Tasos Parisinos" <>
Cc: "Francois Romieu" <>,,
Subject: Re: [PATCH RESEND 1/1] crypto API: RSA algorithm patch (kernel      version
Date: Wed, 21 Mar 2007 14:00:54 +0100 (CET)	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Wed, March 21, 2007 13:34, Tasos Parisinos wrote:
> Indan Zupancic wrote:
>>> Protecting a TripleDES key in high security standards is not as simple as making the kernel
>>> read protected, you need a whole lot and that also means hardware (cryptomemories e.t.c)
>>> So you forget about all this overhead when you use assymetric
>> You need to protect your kernel binary already, adding a key to that doesn't increase the
>> complexity or safety requirements, so all that hardware safety is already in place.
>> (And I'd use AES instead of TripleDES.)
> Well, lets assume you have a trapped casing that prevents a flash chip
> (which holds
> the kernel) from being tamperred. Then you have write protection of the
> bzimage

Not sure what you mean with "trapped casing", I thought we were talking about
the security from the software side, not the physical one?

> When this thing will run, and it will need to check an executable using
> AES for example
> (which is a lot better than TripleDes, i agree) then the key will be for
> a time window
> onto buses and memory. Then it can be probed and retrieved by someone.
> Then you need cryptomemory
> While with asymmetric you don't. There are no high-risk data anywhere,
> only a public
> key

Our emails crossed eachother, but if you read kernel RAM you can in general
also modify it, in which case the signature checking can be disabled.

The moment someone with advanced hardware cracking knowledge puts his hands
on your stuff you're screwed anyway. If you don't believe me, try getting
hard security guarantees from hardware vendors. ;-)

> Of course if you have other data that need to be secured, and you
> already run
> on a trusted platform, including all these crypto hardware modules, then
> you can use
> a symmetric scheme

How do you want to get the thing secure with asymmetric encryption when you
can't protect the kernel? That "other data" is your kernel binary, on flash
or in RAM. So if you can't protect that adequately, then who are you kidding
with signed modules? And the moment you've covered that, you can as well use
symmetric encryption...



  reply	other threads:[~2007-03-21 13:01 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 [this message]
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
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).