[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <000601c76af9$a0ce3ce0$0864a8c0@scs1>
Date: Tue, 20 Mar 2007 16:11:11 +0200
From: "Tasos Parisinos" <t.parisinos@...ensis.com>
To: "Francois Romieu" <romieu@...zoreil.com>
Cc: <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)
Francois Romieu wrote:
> RSA is slow. syscalls are fast.
>
> Which part of the kernel is supposed to benefit from this code ?
The main purpose behind the development of this module was to create an in-kernel
system of signed modules. The scenario applies most in embedded systems that are running linux
where the kernel is physically secure but its filesystem is not, so one may tamper executable code.
In such systems we need to detect the tampering in a centralized way (e.g without using hash databases e.t.c).
So what you need to do is sign the executable (or the library) with a private key and have a kernel that will
use the public key part to authenticate the executable againts its digital signature.
Of course the signing and the authentication is not done against the whole executable but against its
secure hash, and this takes milliseconds to complete before loading the code onto memory.
You see, in such a usage scenario most of the time the kernel will spend will be on hashing (sha1 module) and not in
modular exponentiation. Of course this will not produce any soft lockups
Such a system cannot depend on userland to do the authentication for obvious security reasons, it
must be in kernel.
Of course sha1 is slow as well but there is an sha1 module for anyone who may need it.
That was my idea, we developed it for our own security needs, why not make it available for
others that may want to use it?
Furthermore one can use the API to do multi-precision arithmetics, if any kernel module may need it
--
Tasos Parisinos
-
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