linux-kernel - Re: [PATCH RESEND 1/1] crypto API: RSA algorithm patch (kernel version 2.6.20.1)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <2565.81.207.0.53.1174482054.squirrel@secure.samage.net>
Date:	Wed, 21 Mar 2007 14:00:54 +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 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...

Greetings,

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/