Verschlüsselung: Dateiinhalt, Schlüssel und Signaturen
Welche Standardverfahren eine von Gerät zu Gerät gesendete Datei schützen, was jedes tut und was das Profil nicht zusagt.
Das beschreibt Übertragungen von Gerät zu Gerät, direkt oder über das Relay (Serverweg). Dateien, die du in der pipeit Cloud behältst, werden so gespeichert, dass der Dienst mit ihnen arbeiten kann, und nutzen dieses Ende-zu-Ende-Profil nicht; siehe Sicherheit und häufige Fragen.
Das Datei-Cryptoprofil kombiniert Standardverfahren mit unterschiedlichen Aufgaben:
| Verfahren | Aufgabe im Dateiprofil |
|---|---|
| AES-256-GCM mit 128-Bit-Tag | Inhalt und verschlüsseltes Manifest authentifiziert verschlüsseln |
| RSA-OAEP-3072 mit SHA-256 | Den zufälligen Dateischlüssel für das konkrete Empfangsgerät verpacken |
| ECDSA P-256 mit SHA-256 | Exakte Envelopebytes und kontextgebundene Geräte- und Transferbelege signieren |
| SHA-256 | Fingerprints sowie Ciphertext- und Klartextintegrität prüfen |
Wische seitwärts, um die ganze Tabelle zu sehen.
Pro neuer Dateivorbereitung entstehen ein zufälliger 256-Bit-Dateischlüssel und ein zufälliges 64-Bit-Noncepräfix. Für jeden Verschlüsselungsschritt wird daraus eine 96-Bit-GCM-Nonce: Präfix plus 32-Bit-Chunkindex in Big-Endian-Reihenfolge. Index 0 ist für das verschlüsselte Manifest reserviert, Daten beginnen bei Index 1. Der reguläre Kryptochunk enthält bis zu 4 MiB Klartext. Die Profilgrenzen verhindern einen unbegrenzten Indexraum.
Zusätzliche authentifizierte Daten, kurz AAD, binden die Verschlüsselung unter anderem an Protokollversion, Transfer und Geräte sowie Chunkindex. Damit sind gültige Bytes aus einer anderen Sendung nicht einfach als passende Chunks einsetzbar. Auch die RSA-Verpackung verwendet eine zum Auftrag und Empfänger passende Kennzeichnung. Die Signatur prüft die ursprünglichen Envelopebytes; beliebiges Parsen und erneutes JSON-Serialisieren wäre kein Ersatz für diese Bytebindung.
- In Chunks bis 4 MiB zerlegenDateidaten
- Jeden Chunk verschlüsselnDateidaten
- Schlüssel für Inhalt und ManifestSteuerung und Berechtigungen
- Verschlüsseltes ManifestDateidaten
- Schlüssel für das Empfangsgerät verpackenSteuerung und Berechtigungen
- CiphertextDateidaten
- Verpackter SchlüsselSteuerung und Berechtigungen
- Der Absender signiert die exakten EnvelopebytesSteuerung und Berechtigungen
Der ursprüngliche Dateiname und der Klartext-Dateihash liegen im verschlüsselten Manifest. Sichtbar bleiben für die Steuerung benötigte Metadaten wie Beteiligte, Größen, Zeitpunkte, Profil und Status. pipeit-Clients halten Dateinamen und Schlüssel aus Diagnose und lokalen Logs heraus.
Transportverschlüsselung und Ende-zu-Ende-Verschlüsselung erfüllen verschiedene Zwecke
Das Relay sieht TLS-Verkehr, nie Dateiinhalte. TLS schützt eine Verbindung. Beim HTTPS- und WebSocket-Relay (Serverweg) endet diese TLS-Verbindung an der Plattform; die zusätzliche Dateiverschlüsselung endet erst beim Empfänger. Das Relay benötigt dafür keinen privaten Dateischlüssel. Ein gekoppeltes Gerät muss aber tatsächlich der beabsichtigte Empfänger sein: Eine beliebige vom Server gelieferte öffentliche Schlüsselzeichenfolge ersetzt keinen vertrauenswürdigen Geräteabgleich.
Was das Profil nicht zusagt
Das Dateiprofil verspricht keine Forward Secrecy und keine Post-Compromise-Sicherheit. Die Eigenschaften eines TLS-Kanals dürfen nicht auf langfristig verschlüsselte Dateischlüssel übertragen werden. Ein kompromittiertes Endgerät oder bösartig ausgelieferter Webcode liegt außerdem innerhalb einer anderen Vertrauensgrenze als ein passiv mitlesender Relayserver.
Verwandte Anleitungen
Vom Senden bis zum verifizierten Empfang
Die fachliche Reihenfolge eines Onlineauftrags: Auftrag, Annahme, verschlüsselte Frames, Prüfung und ein signierter Empfangsbeleg.
Sicherheit und häufige Fragen
Was pipeit schützt, wo Dateien gespeichert werden, was ein Empfangsbeleg bestätigt und wo die Grenzen liegen.
Authentisierung und MCP: Anmeldung ist kein Dateischlüssel
Kontositzung, Geräteidentität und MCP-Zustimmung sind drei verschiedene Dinge; so greifen sie ineinander.