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:59:09 +0100 (CET)	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Wed, March 21, 2007 14:07, Tasos Parisinos wrote:
>> On Wed, March 21, 2007 10:15, Tasos Parisinos 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
>> Ah, you're talking about fishing the key out of RAM here, right?
>> My point stays the same for that: If you can't read protect the
>> kernel RAM, small chance you can write protect it. And then they
>> can just bypass all signature checking you put in it anyway.
> How can one tamper (write) the kernel memory of a booted and running kernel
> without using an exploitable bug?
> I mean, you can't mess with the bzImage on flash, the secure bootloader
> boots it without
> letting someone alter the (non crypto-) memory while loading the bzImage
> on it, and then
> no-one can run something that will tamper the system or write anywhere
> on kernel memory
> without exploiting a bug
> I mean, am i missing something here?

Depends on what you consider an exploitable bug. Does getting root access count?
If not, then you must make very sure that all possible ways to modify kernel
memory from userspace are thwarted (I don't know what those are, hopefully
loading modules is the only one, but maybe there are smart other ways).

Assuming one can't write kernel memory, it's also safe to assume kernel memory
can be protected against reads (else the whole keys infrastructure is useless).

But instead of only reading the bus traffic also modifying it doesn't seem so
far fetched to me. That modification can be reduced to swapping one bit which
tells whether the modules being loaded has a valid signature or not.
Timing it might be tricky, but that can be automated.

When someone has the hardware in his hands and really want to exploit it, you
lose no matter what you do. At best you can make it harder and more expensive.

In the end my point is that you might think that you can get away with less
security when using RSA, but perhaps in reality you don't. At least when using
symmetric key encryption you're forced to secure the whole thing more.

So design it for symmetric keys. If it turns out that using asymmetric keys is
more practical for whatever reason, fine, use those. But they won't give you
added security.



P.S. The whole argument of secure bootloader checks the kernel can be
extrapolated to a secure kernel checking a user space program. Why not
letting the kernel check the signature of a monolithic modprobe program,
and let it do all the (RSA) checking. The expected hash of the modprobe
program can be hardcoded in the kernel.

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