User:Robbat2/Infra GPG keys process steps

From Gentoo Wiki
Jump to:navigation Jump to:search

Infra-managed GnuPG

Commands

These are commands to help with the Infra-managed GnuPG keys; esp. in an airgap environment.

Ideally the scripts would be baked into a custom verifiable image, but failing that, it should be possible to retype them.

Command args

 cat >gpg-helper.sh <<EOF
 #!/bin/sh
 gpg \
 --cert-policy-url https://www.gentoo.org/glep/glep-0079.html \
 --no-ask-cert-level --default-cert-level 3 \
 --no-ask-cert-expire --default-cert-expire 2026-07-01 \
 --default-keyserver-url hkps://keys.gentoo.org \
 --allow-weak-key-signatures \
 --expert \
 "$@"
 EOF

Update Expiry

Do this for all keys BEFORE updating signatures. 

 # primary key
 gpg-helper --quick-set-expire $FPR 2026-07-01
 # subkey
 gpg-helper --quick-set-expire $FPR 2026-07-01 '*'

Resign from L1 -> L2, from L2 -> other

 gpg-helper --local-user $SIGNING_KEY_FPR \
 --edit-key $FPR_TO_SIGN

 tsign

 2 # fully
 1 # depth
 gentoo.org # domain
 y # YES

Export new signatures

 gpg-helper --export-options export-clean --armor --export $FPR >$FPR.asc
 # and then review the file!

Airgap design notes

  1. Take some system with *NO* local storage, *NO* networking.
    1. User:Robbat2 previously used Dell Wyse terminals for this: no WIFI or bluetooth hardware present at all; secure boot enabled on EFI w/ signed firmware (somewhat verifiable)
    2. RPi might be options as well, but watch out for onboard wireless networking / RF access [1]
  2. media:
    1. Boot media
      1. If the media is implicitly writable by nature, should support cached boot to enable removing the media after boot. If the boot media is physically read-only (e.g. CDROM), the cachable boot is not required.
      2. Required tooling: `gnupg` plus any extra packages (cryptsetup, lvm2, mdadm, filesystem tools, par2) for the secure key media.
    2. Secure data media
      1. This media should be marked to avoid ANY accidental insertion into the non-airgap system (but the disk encryption should also provide defense in depth)
      2. This needs to be SECURE against compromise by physical access, but also resilient against corruption while in an offline state (e.g. flash degradation)
      3. Example designs:
        1. RAID over multiple devices, with dm-crypt layered
        2. Encrypted files w/ PAR2 added, enabling recovery from block device
      4. Some failure modes to consider
        1. Entire device fails to work
        2. Corruption to part of device, possibly silent
        3. Direct corruption of data (device "intact", but cosmic ray bit flips etc, NAND decay, magnetic decay etc)
        4. Corruption of metadata (device "intact", but cosmic ray bit flips etc, NAND decay, magnetic decay etc)
        5. Loss of media encryption key - don't store them in the same place, but DO ensure you have continuity and backups of the media encryption key!
        6. Rubber hose attack - cannot be protected against trivially
  3. Public key export design
    1. This is oddly one of the hardest design parts: how to enable export of the updated public key portions, while making it really hard to accidental export the private keys.
    2. For the purposes of the airgap key management system; it should be *easy* to review the exported data as it comes out, and be able to clearly say "this is clean of secret material", before inserting back into the public system
    3. Possible solutions
      1. Print & Scan w/ OCR. Most auditable solution, but consider evil in the print/scan path (secret export via tracking dots). Buggy as the data size grows: ~5KiB as of 2024/04/20.
      2. Onscreen OCR or QR codes: less auditable [e.g. if the generator & scanner have hidden evil code]
      3. Data diode - more expensive, not cost-effective for a system used once or twice per year
  4. Overall process
    1. Validate physical security of airgap system and components
    2. Boot from trusted boot media - ideally preserved media, not fresh media
    3. Remove boot media if applicable (see note about cached vs read-only)
    4. Insert Secret Media
    5. Load secrets (may required copying)
    6. Interact w/ Secrets:
      1. Refresh expiry
      2. Update certification signatures (tsign)
      3. Export signed public keys to ephemeral storage
      4. If secrets were copied, ensure they are backed up again on the secret media
    7. Remove secret media!
    8. Wipe secrets from ephemeral storage if required
    9. Review signed public key export
      1. gpg --list-packets is good, but how do you ensure that it isn't ALSO hiding data from you?
    10. Exfiltrate freshly signed public keys
      1. See possible solution discussion above.
Retrieved from "https://wiki.gentoo.org/index.php?title=User:Robbat2/Infra_GPG_keys_process_steps&oldid=1294912"