Skip to content

MANIFEST_ENCRYPTION_ANALYSIS

Jump to bottom Edit New page
makr-code edited this page Nov 30, 2025 · 1 revision

Manifest-Verschlüsselung: Sinnhaftigkeit & Best Practices

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!

ThemisDB Documentation - auto-synced from /docs on 2025-11-30

ThemisDB Wiki

Getting Started

SDKs and Clients

Query Language (AQL)

Search and Retrieval

Storage and Indexes

Security and Compliance

Enterprise Features

Performance and Optimization

Features and Capabilities

Geo and Spatial

Content and Ingestion

Sharding and Scaling

APIs and Integration

Admin Tools

Observability

Development

Architecture

Deployment and Operations

Exporters and Integrations

Reports and Status

Compliance and Governance

Testing and Quality

Source Code Documentation

Reference

Updated: 2025-11-30

Clone this wiki locally