[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4734.81.207.0.53.1174427010.squirrel@secure.samage.net>
Date: Tue, 20 Mar 2007 22:43:30 +0100 (CET)
From: "Indan Zupancic" <indan@....nu>
To: "Tasos Parisinos" <t.parisinos@...ensis.com>
Cc: "Francois Romieu" <romieu@...zoreil.com>,
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)
On Tue, March 20, 2007 15:11, Tasos Parisinos wrote:
> 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.
I'll summarize/rephrase what I've already said in the thread James Morris linked to:
You need a way to protect your kernel binary, or else this whole thing becomes a joke.
(Modify kernel, reboot...)
Assuming you have a secure kernel binary that is tamper proof, why do you need
slow and complex asymmetric encryption again? If you can write protect the kernel,
you can also read protect it (or let the boot loader pass the key to the kernel).
So what stops you from using a simple symmetric key cipher for signing?
Regards,
Indan
-
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