Navigation

[Patrick McDermott <patrick DОТ mcdermott АТ libiquity DОТ 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 DОТ mcdermott АТ libiquity DОТ com>
key, signed by my 0xFCDF9F3FB5D73216 <pj АТ pehjota DОТ 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/