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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Relevant Pages

  • Re: [PATCH RESEND 1/1] crypto API: RSA algorithm patch (kernel version 2.6.20.1)
    ... that also means hardware (cryptomemories e.t.c) ... My point stays the same for that: If you can't read protect the ... kernel RAM, small chance you can write protect it. ...
    (Linux-Kernel)
  • kernel BUG at mm/slab.c:610
    ... I'm experimenting this kernel panic on 3 different ... I don't think this is related to buggy hardware ... Filesystem "hda1": Disabling barriers, not supported by the ... # ACPI Support ...
    (Linux-Kernel)
  • Re: PROBLEM: cannot get stable system since 2.6.28 kernel (amd64)
    ... Philippe> well, I don't really believe in hardware problem for two ... Philippe> older kernel, everything works like a charm, every time I ... Philippe> I haven't any "overclocking" settings, and every hardware ... # Device Drivers ...
    (Linux-Kernel)
  • BUG: soft lockup in 2.6.25.5
    ... hardware, ... Running CentOS 5.2 with a kernel.org kernel ... # PCI IDE chipsets support ... # Input Device Drivers ...
    (Linux-Kernel)
  • Re: [PATCH] xen: core dom0 support
    ... Despite all the noise made about kvm in kernel circles, ... For example, Xen manages to use new hardware virtualization features pretty quickly, partly because it doesn't need to trade-off against normal kernel functions. ... We end up mapping the event channels back to irqs and they are delivered as normal interrupts as far as the rest of the kernel is concerned. ...
    (Linux-Kernel)
Loading