Skip to content

Proposals

Jump to bottom
Luís Tonicha edited this page Nov 27, 2022 · 4 revisions

This page lists feature proposals for cpackget. It's dedicated to bigger features that might require additional discussion/documentation, and not just bound to an Issue.

Signed Packs

Objective

Allows cpackget to digitally sign packs and create pack checksums, offering an added layer of security by providing integrity and authenticity mechanisms.

Context

Currently, packs are installed as-is, with no way of verifying their legitimacy and origin, other than trusting the publishing source (a.k.a the vendor's index.pidx). Even though this source is commonly behind an SSL connection, this just protects the download channel and not the origin. A malicious actor might still compromise it and publish packs containing malware or other threats.

By introducing Public Key Infrastructure (what is behind SSL) and Digital Signatures, it's possible to mitigate these threats.

In essence, a developer/vendor should be able to create a signature based on the contents of the pack, tie that to its entity according to an authority body, and publish the pack. On the user side, cpackget would silently verify these signed packs and block the installation of any packs failing these checks.

Required implementation

Since cpackget v0.8.3 it's possible to create this signature and embed it on a pack, either using X.509 public key certificates (signature-create) or a PGP key (signature-create --pgp). These packs can also be verified manually using signature-verify. However, other than checking the pack's integrity through the signed digest, nothing is enforced regarding the origin or validity of the X.509 certificate, other than the validity date. It does not have to be signed by any specific CA, which does not establish any chain of trust. With PGP, which uses a different trust model but still serves the same purpose, the user needs to provide the public PGP to check against the signature, which requires a trusted distribution channel.

To avoid this, two viable options are proposed, each with its implementation cost & required infrastructure:

Dedicated Certificate Authority

A stakeholder gets chosen to act as the "Root" CA (Certificate Authority) and signs vendor certificates so they can be recognized as legitimate by cpackget - done by shipping its root certificate alongside it. Vendors are responsible for creating their own certificates, requesting a signature to the Root CA and then start signing and distributing the packs. Example:

  • Vendor X asks the IT department to create a X.509 public key certificate
  • Communicates to the Root CA that it wants to use this certificate
  • Root CA signs it, sends the signed certificate back (essentially a CSR)
  • Vendor X uses cpackget signature-create with the signed certificate, signing the pack which is ready to be published

Regarding PGP, vendors/developers share their public keys in the public index file/index.pidx which cpackget would automatically fetch and use. This can be achieved by adding a tag to the PDSC url:

  <pdsc url="http://www.keil.com/pack/" vendor="ARM" name="CMSIS" version="5.9.0" />

Turns into

  <pdsc url="http://www.keil.com/pack/" vendor="ARM" pgp="arm.com/Open-CMSIS/key.pgp" name="CMSIS" version="5.9.0" />

(just an example, not to be interpreted literally)

Public index file as source of truth

Vendors create their certificates (preferably signed by their intermediate CA of choice) and request the public index file maintainer to add the URL where the certificate is hosted (much like the PGP example above). The difference here is that the required trust is placed on the public index and not on a specific entity acting as a CA. This also takes some weight off of the pack developers/vendors, as no additional process other than hosting the certificate is required.

For PGP it would be exactly the same.

Links

Clone this wiki locally