updates_manifest_encryption

Manifest-Verschlüsselung: Sinnhaftigkeit & Best Practices

Stand: 5. Dezember 2025
Version: 1.0.0
Kategorie: Updates

---

Die kritische Frage

Ist es sinnvoll, das Release-Manifest zu verschlüsseln, wenn der Source Code öffentlich ist?

Analyse

Was das Manifest enthält

{
  "version": "1.2.0",
  "files": [
    {
      "path": "bin/themis_server",
      "sha256_hash": "e3b0c44...",
      "size_bytes": 1024000,
      "download_url": "https://github.com/.../themis_server"
    }
  ],
  "build_commit": "abc123",
  "release_notes": "Security fixes..."
}

Sensible Informationen?

• ❌ Dateinamen - bereits im Source Code sichtbar
• ❌ Hashes - öffentlich prüfbar, kein Geheimnis
• ❌ Build-Commit - öffentliches Git Repository
• ❌ Release Notes - sollten öffentlich sein

Fazit: Das Manifest enthält KEINE geheimen Informationen!

Warum Verschlüsselung NICHT sinnvoll ist

1. Security through Obscurity

Verschlüsselung des Manifests = Security through Obscurity

• ❌ Kein echter Sicherheitsgewinn
• ❌ Verschleiert nur Informationen, die bereits öffentlich sind
• ❌ Komplexität ohne Nutzen

2. Transparency ist besser

Open-Source-Projekt profitiert von Transparenz:

• ✅ Community kann Releases prüfen
• ✅ Security-Forscher können Manifest analysieren
• ✅ Automatische Tools können Updates erkennen
• ✅ Vertrauen durch Offenheit

3. Operationelle Komplexität

Verschlüsselung bedeutet:

• ❌ Key Management für alle Instanzen
• ❌ Komplexere Installation
• ❌ Potenzielle Fehlerquellen
• ❌ Schwierigere Debugging

4. Falsche Sicherheit

Verschlüsselung schützt NICHT vor:

• ❌ Man-in-the-Middle Attacken (HTTPS tut das)
• ❌ Manipulierten Binaries (Signaturen tun das)
• ❌ Kompromittierten Builds (Code-Signing tut das)

Best Practice: Signatur statt Verschlüsselung

✅ Was WIRKLICH wichtig ist: INTEGRITÄT & AUTHENTIZITÄT

┌─────────────────────────────────────────────────────┐
│  GitHub Release (Public & Transparent)              │
├─────────────────────────────────────────────────────┤
│                                                     │
│  ┌────────────────────────────────────────┐        │
│  │  manifest.json (PLAINTEXT)             │        │
│  │  - Öffentlich lesbar                   │        │
│  │  - Vollständig transparent             │        │
│  │  - Community kann prüfen               │        │
│  └────────────────────────────────────────┘        │
│                                                     │
│  ┌────────────────────────────────────────┐        │
│  │  manifest.json.sig (CMS/PKCS#7)        │        │
│  │  - Digitale Signatur                   │        │
│  │  - Beweist: Manifest von ThemisDB Team │        │
│  │  - Verhindert: Manipulation            │        │
│  └────────────────────────────────────────┘        │
│                                                     │
│  ┌────────────────────────────────────────┐        │
│  │  themis_server.sha256                  │        │
│  │  - Hash jeder Datei                    │        │
│  │  - Zusätzliche Integritätsprüfung     │        │
│  └────────────────────────────────────────┘        │
│                                                     │
└─────────────────────────────────────────────────────┘

Empfohlene Architektur

Layer 1: Transport Security (HTTPS)

✅ TLS 1.3
✅ Certificate Pinning (optional)
✅ Verhindert: Man-in-the-Middle

Layer 2: Manifest Authenticity (Digitale Signatur)

manifest.json:
{
  "version": "1.2.0",
  "files": [...],
  "signature": {
    "algorithm": "RSA-SHA256",
    "certificate": "MIIBIjANBgkqhkiG9w0BAQE...",
    "signature": "SGVsbG8gV29ybGQ...",
    "timestamp": "2025-01-20T10:00:00Z"
  }
}

Signiert mit:

• Private Key des ThemisDB Release-Teams
• X.509 Zertifikat von vertrauenswürdiger CA
• RFC 3161 Timestamp (Beweist: Wann signiert)

Verifiziert von:

• Jeder ThemisDB-Instanz
• Certificate Chain bis Root CA
• Optional: Certificate Revocation Check (CRL/OCSP)

Layer 3: File Integrity (SHA-256 Hashes)

{
  "files": [
    {
      "path": "bin/themis_server",
      "sha256": "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855",
      "size": 1024000
    }
  ]
}

Prüft:

• Jede Datei einzeln
• Verhindert: Teilweise Manipulation
• Garantiert: Bit-genaue Übereinstimmung

Layer 4: Code Signing (Optional, für Binaries)

# macOS
codesign -s "Developer ID Application" themis_server

# Windows
signtool sign /f cert.pfx /p password themis_server.exe

# Linux (AppImage)
appimagetool --sign themis_server.AppImage

Zusätzlich:

• OS-Level Verifikation
• Verhindert: Malware-Warnungen
• Vertrauen: OS trusted store

Industry Best Practices

Beispiel 1: Kubernetes

# Kubernetes Release Manifest (öffentlich)
apiVersion: v1
kind: Release
metadata:
  name: v1.28.0
  annotations:
    "release.kubernetes.io/signature": "..."
spec:
  binaries:
    - name: kubectl
      sha256: "abc123..."
      url: "https://..."

✅ Öffentlich ✅ Signiert ❌ NICHT verschlüsselt

Beispiel 2: Docker

// Docker Image Manifest (öffentlich)
{
  "schemaVersion": 2,
  "mediaType": "application/vnd.docker.distribution.manifest.v2+json",
  "config": {
    "digest": "sha256:abc123...",
    "size": 1234
  },
  "layers": [...]
}

✅ Content-Addressable (Hash-basiert) ✅ Signiert mit Docker Content Trust ❌ NICHT verschlüsselt

Beispiel 3: Debian/Ubuntu APT

# Release file (öffentlich)
Origin: Ubuntu
Label: Ubuntu
Suite: jammy
Codename: jammy
Date: Mon, 15 Jan 2024 10:00:00 UTC
Architectures: amd64 arm64
Components: main restricted universe multiverse
SHA256:
 abc123... 12345 main/binary-amd64/Packages

✅ Öffentlich ✅ GPG-signiert ❌ NICHT verschlüsselt

Wann macht Verschlüsselung Sinn?

❌ NICHT für Open-Source Public Releases

Wenn:

• Source Code ist öffentlich
• Binaries sind frei verfügbar
• Community soll prüfen können

✅ NUR für Private/Enterprise Releases

Wenn:

• Closed-Source Produkt
• Lizenz-gebundene Features
• Vertrauliche Kunden-Deployments
• Compliance-Anforderungen (z.B. Export-Kontrolle)

Beispiel: Enterprise Edition

{
  "version": "1.2.0-enterprise",
  "features": ["hsm_support", "geo_replication"],
  "license_required": true,
  "encrypted": true  // Nur für zahlende Kunden
}

Empfohlene Lösung für ThemisDB

1. Öffentliches Manifest mit Signatur

// manifest.json (öffentlich auf GitHub)
{
  "schema_version": 1,
  "version": "1.2.0",
  "tag_name": "v1.2.0",
  "release_date": "2025-01-20T10:00:00Z",
  "is_critical": true,
  "release_notes": "Security fixes and improvements",
  
  "files": [
    {
      "path": "bin/themis_server",
      "type": "executable",
      "platform": "linux",
      "architecture": "x64",
      "sha256": "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855",
      "size_bytes": 1024000,
      "download_url": "https://github.com/makr-code/ThemisDB/releases/download/v1.2.0/themis_server"
    }
  ],
  
  "build_info": {
    "commit": "abc123def456",
    "build_date": "2025-01-20T09:00:00Z",
    "compiler": "gcc 11.4.0"
  },
  
  "signature": {
    "algorithm": "CMS-SHA256",
    "certificate": "-----BEGIN CERTIFICATE-----\n...",
    "signature": "-----BEGIN CMS-----\n...",
    "timestamp": "2025-01-20T10:00:00Z",
    "timestamp_authority": "http://timestamp.themisdb.io"
  }
}

2. Signatur-Workflow

# Build-Zeit (CI/CD)
./generate_manifest.sh --version 1.2.0 > manifest.json

# Signieren
openssl cms -sign \
  -in manifest.json \
  -out manifest.json.sig \
  -signer release-cert.pem \
  -inkey release-key.pem \
  -binary \
  -outform DER

# Signatur ins Manifest einbetten
./embed_signature.sh manifest.json manifest.json.sig

# Upload
gh release upload v1.2.0 manifest.json

3. Verifikation (Runtime)

// In UpdateChecker::verifyManifest()
bool verifyManifest(const ReleaseManifest& manifest) {
    // 1. Verify certificate chain
    if (!verifyCertificateChain(manifest.signature.certificate)) {
        LOG_ERROR("Invalid certificate chain");
        return false;
    }
    
    // 2. Check certificate revocation
    if (!checkCRL(manifest.signature.certificate)) {
        LOG_ERROR("Certificate revoked");
        return false;
    }
    
    // 3. Verify CMS signature
    if (!verifyCMSSignature(manifest, manifest.signature.signature)) {
        LOG_ERROR("Invalid signature");
        return false;
    }
    
    // 4. Verify timestamp
    if (!verifyTimestamp(manifest.signature.timestamp)) {
        LOG_ERROR("Invalid timestamp");
        return false;
    }
    
    // 5. Verify file hashes (during download)
    for (const auto& file : manifest.files) {
        if (!verifyFileHash(file)) {
            LOG_ERROR("File hash mismatch: {}", file.path);
            return false;
        }
    }
    
    return true;
}

Vorteile der offenen Lösung

1. Transparency

✅ Jeder kann Releases auditieren ✅ Security-Forscher können Probleme finden ✅ Community-Vertrauen durch Offenheit

2. Simplicity

✅ Kein Key Management nötig ✅ Einfachere Installation ✅ Weniger Fehlerquellen

3. Compatibility

✅ Standard-Tools funktionieren (curl, wget) ✅ Automatische Update-Checker ✅ CI/CD Integration einfacher

4. Auditability

✅ Vollständiger Audit-Trail ✅ Reproduzierbare Builds ✅ Supply Chain Security

Zusammenfassung

❌ Manifest-Verschlüsselung

NICHT empfohlen für ThemisDB weil:

• Source ist öffentlich
• Keine sensiblen Daten im Manifest
• Security through Obscurity
• Unnötige Komplexität

✅ Manifest-Signatur

Empfohlen für ThemisDB:

• Beweist Authentizität
• Verhindert Manipulation
• Transparenz erhalten
• Industry Best Practice

Finale Empfehlung

Entfernen Sie die Verschlüsselung, fokussieren Sie auf Signaturen:

1. ✅ Öffentliche, lesbare Manifests
2. ✅ CMS/PKCS#7 Signaturen
3. ✅ Certificate Chain Verification
4. ✅ Timestamp Authority
5. ✅ SHA-256 File Hashes
6. ✅ Optional: Code Signing für Binaries

Dies ist der Industrie-Standard und wird von allen großen Open-Source-Projekten verwendet.

Ausnahme: Enterprise Features

Nur wenn ThemisDB Enterprise-Features hat, die lizenz-gebunden sind:

// public_manifest.json (öffentlich)
{
  "version": "1.2.0",
  "edition": "community",
  "files": [...]
}

// enterprise_manifest.json (verschlüsselt, nur für Kunden)
{
  "version": "1.2.0-enterprise",
  "edition": "enterprise",
  "license_key_required": true,
  "encrypted_features": {...}
}

Aber für die Community-Edition: Keine Verschlüsselung!