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

Bug #1930454 reported by Dimitri John Ledkov
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Launchpad itself
New
Undecided
Unassigned
sbsigntool (Ubuntu)
New
Undecided
Unassigned

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.

Revision history for this message
Dimitri John Ledkov (xnox) wrote :

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.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.