Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.debian.kernel > #81948 > unrolled thread

Bug#1064839: Consider not using an ephemeral key or document its security model

Started byJulian Andres Klode <jak@debian.org>
First post2024-02-26 14:50 +0100
Last post2024-02-26 17:00 +0100
Articles 2 — 2 participants

Back to article view | Back to linux.debian.kernel


Contents

  Bug#1064839: Consider not using an ephemeral key or document its security model Julian Andres Klode <jak@debian.org> - 2024-02-26 14:50 +0100
    Bug#1064839: Consider not using an ephemeral key or document its security model Luca Boccassi <bluca@debian.org> - 2024-02-26 17:00 +0100

#81948 — Bug#1064839: Consider not using an ephemeral key or document its security model

FromJulian Andres Klode <jak@debian.org>
Date2024-02-26 14:50 +0100
SubjectBug#1064839: Consider not using an ephemeral key or document its security model
Message-ID<IbJwJ-cLxd-3@gated-at.bofh.it>
Source: linux
Severity: normal
X-Debbugs-Cc: jak@debian.org

In https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1040901 I asked you
to switch to an ephemeral key which was a misunderstanding from a
discussion with xnox, which we still need to sort out fully.

Please either document how the buildds ensure that

- private key generation has enough, and high quality enough, entropy
- private keys are safely erased after not being needed anymore

or revert to signing modules with the CA key and use MODVERSIONS
and co to ensure that modules built for one ABI cannot be used
with another.

I need to update the question in shim-review accordingly, I think
I never reverted it or adjusted it, but it will likely take the
form of the previous three paragraphs.

I sincerely apologize for causing this misunderstanding.

-- System Information:
Debian Release: trixie/sid
  APT prefers noble
  APT policy: (500, 'noble'), (500, 'mantic-security')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.8.0-11-generic (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to C.UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer                              i speak de, en

[toc] | [next] | [standalone]


#81953

FromLuca Boccassi <bluca@debian.org>
Date2024-02-26 17:00 +0100
Message-ID<IbLyx-cMIf-7@gated-at.bofh.it>
In reply to#81948

[Multipart message — attachments visible in raw view] — view raw

On Mon, 26 Feb 2024 14:45:19 +0100 Julian Andres Klode <jak@debian.org>
wrote:
> Source: linux
> Severity: normal
> X-Debbugs-Cc: jak@debian.org
> 
> In https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1040901 I asked
you
> to switch to an ephemeral key which was a misunderstanding from a
> discussion with xnox, which we still need to sort out fully.
> 
> Please either document how the buildds ensure that
> 
> - private key generation has enough, and high quality enough, entropy
> - private keys are safely erased after not being needed anymore
> 
> or revert to signing modules with the CA key and use MODVERSIONS
> and co to ensure that modules built for one ABI cannot be used
> with another.
> 
> I need to update the question in shim-review accordingly, I think
> I never reverted it or adjusted it, but it will likely take the
> form of the previous three paragraphs.
> 
> I sincerely apologize for causing this misunderstanding.

Are those really that hard of a problem to solve? Running any modern
kernel entropy shouldn't be an issue, certainly not on controlled
environment like the buildds - if an attacker has complete control of
the buildds environment, then we can pack up and go home, given the
kernel build is not reproducible. And likewise key handling could be
done in a non-swappable tmpfs tied to the lifetime of the build process
via a namespace, that ought to be enough for peace of mind?

Using an ephemeral key makes things so much simpler and nicer and
quicker at signing time, and so much simpler to reason about. One
kernel, one set of modules, and that's it.

-- 
Kind regards,
Luca Boccassi

[toc] | [prev] | [standalone]


Back to top | Article view | linux.debian.kernel


csiph-web