[Bug 1930454] Re: support for .ko.hash signatures or .o -> ko -> detached signatures

[Dimitri John Ledkov]

Investigating this further....

.ko signatures are CMS signatures, which are ANS.1 structures. THey are
tested, such that SignedData is a wrapper, around DigestedData, which is
a wrapper around ContentInfo, which is a warapper around raw binary
input.

The nice property of DigestedData is that it contains version, hash
algo, and digest fields, and the raw binary data is actually optional.

Meaning, one can Create CMS ANS.1 DER encoded DigestedData object, with
raw binary data discarded. Transfer that to the signing service, which
should be able to produce detached signatures.

Original desire to make large data optional, is in case the data to be
signed is a very large stream / tape, which is impossible or impractical
to hold in memory; and yet one still wants to generate signatures for
it.

None of the existing APIs to work CMS appear to trivially support
creating / serializing DigestedData, then deserialize it to sign it and
produce detached signatures. Ideally this should be done in DER encoding
such that it is platform/architecture independent.

I am pondering to add more APIs to OpenSSL or extend some of the
available CMS golang or rust libraries.

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to sbsigntool in Ubuntu.
https://bugs.launchpad.net/bugs/1930454

Title:
  support for .ko.hash signatures  or .o -> ko -> detached signatures

Status in Launchpad itself:
  New
Status in sbsigntool package in Ubuntu:
  New

Bug description:
  support for .ko.hash signatures

  Sometimes we would like to sign .ko kernel modules, that we cannot
  redistribute (i.e. linked nvidia .ko).

  At the moment we attempt to sign them in private ppa builds only, then
  extract detached signatures and whip those along with unlinked .o
  object files that one can put together into a signed .ko.

  It would be nice, if we could generate a signing tarball with just
  hashes of the .ko objects we'd like to sign without including .ko
  objects themselves.

  something like module.ko.sha512 which is simply the sha512 hash of the
  ko module to sign. Then do openssl API gymnastics in kmodsign to
  convince it to produce a CMS signature without being able to actually
  the has the file, just sign the hash we ask for and produce detached
  signature.

  Alternatively we could put .o objects in the signing tarball and then
  ask kmodsign to link them all, then sign, then detach signature, throw
  away the .ko.

  The above things are complicated, but if implemented, it would greatly
  simplify signing non-redistributable kernel modules in launchpad.

To manage notifications about this bug go to:
https://bugs.launchpad.net/launchpad/+bug/1930454/+subscriptions