# Package Security: Kryptografie als Schutzschild der Lieferkette

TL;DR / Management Summary Wer Pakete signiert, gibt ein Versprechen ab: “Dieser Code ist von mir und wurde nicht verändert.” In diesem Modul gehen wir unter die Haube der Kryptografie. Wir lernen den Unterschied zwischen dem GPG-Web-of-Trust (Arch) und dem einfacheren RSA-Key-Modell (Alpine) kennen. Ein Senior Admin muss wissen, wie man eine PKI (Public Key Infrastructure) für Pakete aufbaut, Schlüssel sicher rotiert und was zu tun ist, wenn ein privater Schlüssel kompromittiert wurde.

# 1. Einführung & Architektur

GPG vs. RSA.

• Arch Linux (GPG): Nutzt das GNU Privacy Guard Modell. Pakete sind mit individuellen Keys der Maintainer signiert, die wiederum vom Arch-Master-Key beglaubigt werden.
• Alpine Linux (RSA): Nutzt ein einfacheres Modell. Das gesamte Repository ist mit einem RSA-Key signiert. Der öffentliche Teil liegt auf jedem Client unter /etc/apk/keys/.

# Die Vertrauenskette (Mermaid)

graph TD
    A[Root Authority / Admin] -->|Signs| B[Sub-Key: Package Signing]
    B -->|Signs| C[Software Package]
    C --> D[Distribution via HTTP]
    D --> E[Client: SLES/Arch Node]
    F[Public Key Folder] -->|Verify| E
    E -->|Check Signature| G{Match?}
    G -->|Yes| H[Install Package]
    G -->|No| I[Block & Alert]

# 2. GPG Management für Arch (Expert Level)

Den Keyring beherrschen.

Pacman nutzt den archlinux-keyring. Wenn Sie eigene Pakete signieren:

# Eigenen GPG-Key für Pakete erstellen

gpg --full-generate-key
# Wählen Sie (4) RSA and RSA, 4096 bit.

# Key in Pacman importieren

sudo pacman-key --add mykey.pub
sudo pacman-key --lsign-key <KEY_ID>

# 3. RSA Management für Alpine

Einfachheit in der PKI.

In Alpine ist der Public Key ein einfaches File.

# Key-Rotation (Best Practice)

Wenn Sie einen Schlüssel tauschen:

1. Verteilen Sie den neuen Public Key an alle Server (zusätzlich zum alten).
2. Signieren Sie das Repository mit dem neuen Key.
3. Entfernen Sie den alten Public Key nach einer Übergangsfrist.

# 4. Day-2 Operations: Key Revocation

Wenn der Ernstfall eintritt.

Wenn Ihr privater Schlüssel gestohlen wurde, müssen Sie ihn für ungültig erklären.

# Revocation Certificate (GPG)

Erstellen Sie dieses Zertifikat sofort nach der Key-Erstellung und lagern Sie es offline.

gpg --output revoke.asc --gen-revoke <KEY_ID>

Im Ernstfall laden Sie revoke.asc auf einen Key-Server hoch. Pacman wird das Paket beim nächsten --refresh-keys ablehnen.

# 5. Troubleshooting & “War Stories”

Wenn die Kette bricht.

# Story 1: “Der Time-Drift Fail”

Symptom: pacman oder apk melden “Signature is not yet valid”. Ursache: Die Systemzeit des Servers ist falsch (liegt in der Vergangenheit). Der Zeitstempel der Signatur liegt aus Sicht des Servers in der Zukunft. Lösung: Synchronisieren Sie die Zeit via NTP (chronyd oder systemd-timesyncd).

# Story 2: “Das abgelaufene Master-Zertifikat”

Symptom: Plötzlich können auf tausenden Servern keine Updates mehr installiert werden. Das Security-Team stellt fest, dass der Master-Key der Distribution abgelaufen ist. Ursache: Fehlendes Monitoring der Key-Ablaufdaten. Lösung: Bei Arch muss der archlinux-keyring manuell (ohne Signaturprüfung) aktualisiert werden. Prävention: Überwachen Sie gpg --list-keys mit einem Skript, das 30 Tage vor Ablauf warnt.

# 6. Fazit & Empfehlung

• Offline-Speicherung: Lagern Sie den privaten Signaturschlüssel auf einem YubiKey oder einem dedizierten Offline-Rechner (Air-Gapped).
• Automatisierung: Nutzen Sie in der CI/CD nur Sub-Keys mit begrenzter Gültigkeit.
• Transparenz: Veröffentlichen Sie Ihren öffentlichen Key auf einer HTTPS-geschützten Firmenseite oder einem Key-Server.

# Anhang: Cheatsheet