Hi all, Just thought I'd cross-post this here as an update to my reply to Donald's thread last year, "Help users to verify their downloads".
Tl;dr: ProteanOS now fully supports download verification (with its own certificate authority), which is all automated after users download and verify the installer program "prokit". -------- Forwarded Message -------- Subject: Strong ProteanOS package archive signing complete Date: Sun, 28 Apr 2019 19:06:35 -0400 From: Patrick McDermott <patrick.mcderm...@libiquity.com> To: proteanos-...@lists.proteanos.com ProteanOS now has a public key certificate authority for its package archive. An air-gapped ProteanOS system generates an archive key pair and certifies (signs with an expiration date) the archive public key with a root secret key (which never leaves the air-gapped CA system). The archive secret key and public key certificate are then manually exfiltrated (again from an offline system) and uploaded to the files server so the ProteanOS Archive Manager (pro-archman) can sign the "Packages" files. ProteanOS Development Kit (prokit) version 2.0.0 (or as of Git commit 4fbc7e5 on 2019-04-17) now retrieves the archive certificate and validates it against the included root public key and then checks "Packages" file signatures against the archive public key (extracted from the certificate). The archive public key and certificate and the root public key are left in an installed ProteanOS system for use by future "opkg update" commands. And ProteanOS now uses opkg-lede instead [1] of the original opkg 0.2.x (newer versions of opkg are now maintained under Yocto with new large dependencies). Included with ProteanOS's opkg-lede package is the same certificate/signature verification code as in prokit (a utility I wrote that uses OpenWrt's usign utility for the actual signature checks). As of yesterday, this work is complete and ProteanOS packages are now delivered securely. (prokit's OpenPGP signature is the root of trust in this whole system, so when downloading a prokit tar archive remember to check it against my 0x1A459ECDE4D604BE <patrick.mcderm...@libiquity.com> key, signed by my 0xFCDF9F3FB5D73216 <p...@pehjota.net> key, which in turned is signed by several other people. If you've signed any keys, you should try to find a signature path from them to my keys.) Underlying Cryptography and PKI ------------------------------- All of this is based around the Ed25519 public-key signature system, which is fast, uses small keys and signatures, and is used by OpenBSD and OpenWrt (and derivatives like libreCMC). The certificate system I developed is somewhat similar to X.509 (used by TLS/SSL for example) and OpenWrt's ucert (which is only used for full system image upgrades). The short life of archive keys (similar to Let's Encrypt) should minimize damage resulting from any possible secret key compromise and is used instead of a similarly scheduled certificate revocation list (CRL) as typically used by X.509. I consider a CRL to be an incomplete solution because it's ineffective if a key compromise goes unnoticed or if a secret key is seized by law enforcement under a secret warrant with a gag order. And this certificate system is used instead of a keyring package (as used by most other OS distributions) because, in the event of a compromised secret key, users would have to immediately update their feed lists and keyring package. That package, in a MitM attack, could be a malicious package from a feed signed with the compromised key. This by definition gives an attacker arbitrary code execution with superuser privileges. With certificates, in the event of a key compromise a user can either remove the public key and certificate from "/etc/opkg/keys/" or simply wait for the certificate to expire before running "opkg update". -- [1]: http://www.proteanos.com/dev/pkg/opkg/future/ -- Patrick McDermott, CEO Libiquity Putting customers in control of high-quality technologies http://www.libiquity.com/ _______________________________________________ proteanos-dev mailing list Posting address: <mailto:proteanos-...@lists.proteanos.com> Info and archives: <http://lists.proteanos.com/proteanos-dev/>
