Skip to content

[v2] Komprimierung bei Verschlüsselung verbieten

Warum

Nachdem bekannt wurde, dass von der Komprimierung bei der Verschlüsselung aus Sicherheitsgründen abgeraten wurde, wurde diese Forderung mit Epic #1811 (closed) entfernt. In diesem Follow-Up soll nun die Verschlüsselung verboten werden.

Ziel

Als Sicherheitsverantwortlicher möchte ich keine unsicheren Vorgehensweisen zulassen. Als Softwarehersteller möchte ich möglichst wenige Varianten, die ich alle unterstützen muss.

Links, Hinweise, Bemerkungen

In den Vorgaben für kryptographische Verfahren war explizit eine Kompression gefordert.

Der JSON Web Encryption Header "zip" muss auf den Wert "DEF" (DEFLATE) gesetzt werden.

Die JavaScript-Bibliothek jose hat den "zip" Header unter Verweis auf RFC 8725, Sec. 3.6 als "deprecated" markiert:

Von https://github.com/panva/jose/blob/main/docs/interfaces/types.JWEHeaderParameters.md#zip:

Deprecated: Compression of data SHOULD NOT be done before encryption, because such compressed data often reveals information about the plaintext.

Aus RFC 8725, Sec. 3.6:

Compression of data SHOULD NOT be done before encryption, because such compressed data often reveals information about the plaintext.

Stories

  • Dokumentation anpassen team::Doku
  • Änderung kommunizieren team::AM
  • Der Zustelldienst weist verschlüsselte Artefakte (Metadatensatz, Fachdatensatz, Anlagen) zurück, die den Header zip gesetzt haben. team::ZSD

Akzeptanzkriterien

  1. In Submission-API v2 können keine verschlüsselten Artefakte mit gesetztem zip Header hochgeladen werden.
  2. Die Änderung wurde an die Anbindungsprojekte kommuniziert
  3. Der Major Release Guide wurde angepasst
  4. Definition of Done wurde überprüft.

Mögliche Folgeaktivitäten

Offene Fragen

Edited by Andreas Aschauer