[OM Cooker] Trusted RPM packages
Jeff Johnson
n3npq at mac.com
Mon Jan 18 17:57:00 EST 2016
On Jan 18, 2016, at 9:21 AM, Tomasz Gajc wrote:
> Jeff thanks for your explanation. I have feeling i've understood it like this way, so please confirm:
>
> 1. Before release and repository freeze a list of gpg keys needs to be generated from each rpm file in repository
> 2. This list must be uploaded to virtual-notary.org
> 3. List is signed by virtual-notary
> 4. List is placed on repository with a public certificate from virtual-notary
> 5. Done
>
That's close to the procedure I suggested, but you are missing some essential steps.
The virtual-notary provides a confirmation that a document on the internet existed
(as in could be fetched) at a certain time and location. With a one-time non-repudiable
signature, the notarization is a guarantee of uniqueness: i.e. rpm hasn't "cheated" and
saved the private key in order to resign additional, possibly tampered/altered content.
The procedure above could use other trust chains, like signing the manifest with gpg/openssl,
to securely distribute content. In fact, you could sign the manifest before sending to virtual-notary.
SKS keyservers, or X.509 CA's, establish that trust chain for packages signed by the "official" keys,
and would provide a similar form of trust for a manifest.
It's the trusted timestamp provided by a digital notary that publishes the fact that the key
used by rpm to sign packages is unique (and hence non-repudiable). The attestation of the
location from which the manifest was retrieved starts to establish the origin (and validity)
of the mirrored content.
The other important points of a non-repudiable rpm signature are:
1) There is no need to manage/protect private keys on the build system. rpmbuild
handles the non-repudiable signing, and publishing a manifest through a notary
starts to guarantee the uniqueness.
2) There is no need to distribute "official" pubkeys to end-users, the non-repudiable
pubkey is in every rpm package and will be installed when the package is installed.
3) Using multiple non-repudiable signatures instead of an "official" key for securing
package content greatly reduces the risk of the "official" key being compromised.
Everything signed by a compromised "official" key would need to be republished,
while a compromised non-repudiable signature is limited to republishing only the
packages produced in a single build.
Security protocols are a huge PITA: simple procedures make it easier to Get It Right! JMHO ...
> BTW: idea is very interesting :)
>
> I have a couple of questions/ideas:
> 1. Would be nice if urpmi could verify a gpg key from a signed list taken from mirror.
urpmi has no crypto inside, all package verification is through rpmlib. Using the non-repudiable
signature guarantees that rpm always has the pubkey needed to verify package integrity
no matter whether users have imported or distros have uploaded their pubkey or whether
rpm is permitted access to SKS key servers on build systems (by configuring a network) or
by configuring rpm to retrieve pubkeys on client machines.
> 2. What about /updates directory on mirror? This directory is not frozen after release, so this means new packages will be arriving there. How to handle these packages with above solution ? IMHO recreating list each rpm got published and then upload it to virtual-notary and generate new certificate is a big effort. I wonder how virtual-notary will react if we will upload couple of lists per day.
The official release and official updates likely should be signed by the "official" key
because that is the least surprising.
Yes free services like virtual-notary (and SKS keyservers) should not be abused.
(aside)
rpm could easily use SKS key servers as a notary with rpmbuild publishing the pubkey. The problem
there is that network access is routinely prohibited to rpm while building, and Yet More Network Access
to retrieve needed pubkeys that depend on distro security procedures is usually controversial.
Note that I have asked and received permission to use SKS keyservers, and anticipate having a similar
conversation with virtual-notary about load factors as well as discussing the security protocol.
> Maybe update 1 time per day ? You know, user can install update just couple a seconds just after it got published on repository.
>
Yes, basically *Mandriva could collect manifests and publish daily/weekly to taste. virtual-notary is
doing similarly, where all the attestations are collected, and then published into the bitcoin chain
periodically (or as needed).
(aside)
Exposing fresh builds to mirrors for users to "install update just couple of seconds after ... published"
has its own problems, including that there is only a couple of seconds of QA possible.
But let's not digress ...
> 3. Is there any API for virtual-notary.org ?
>
There is a REST API at virtual-notary iirc.
hth
73 de Jeff
>
>
> 2016-01-18 12:43 GMT+01:00 Jeff Johnson <n3npq at mac.com>:
>
> On Jan 18, 2016, at 5:56 AM, Jeff Johnson wrote:
>
> >>
> >> I do not understand what non-repudiable means :(
> >>
> >
> > Apologies for the techno jargon (but I am reluctant to invent newer! better! bestest! terms)
> >
> > A repudiation is a statement denying some claim like this:
> > Q: Did you modify anything in the package?
> > A: No.
> >
> > So a non-repudiable signature is a public/global assertion that nothing whatsoever is changed.
>
> Here is perhaps a better (i.e. more explicit) example of repudiation(s):
>
> Claim: My machine was rooted by installing a *Mandriva rpm package from this mirror.
> Repudiation #1: That package wasn't downloaded from this mirror.
> Repudiation #2: That is not a *Mandriva package because its not signed with a Mandriva key.
> Repudiation #3: That is not a package produced by rpm because (various reasons, like the
> package might have been altered after being built).
>
> By including a non-repudiable signature, #3 provides a stronger/transparent mechanism that a
> package was not altered after being built.
>
> By registering a manifest with virtual-notary, *Mandriva would be providing some means to resolve
> the issues associated with #1 and #2, and avoiding issues related to "official" key compromises.
>
> hth
>
> 73 de Jeff
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://ml.openmandriva.org/pipermail/om-cooker_ml.openmandriva.org/attachments/20160118/814c20a5/attachment.html>
More information about the OM-Cooker
mailing list