Hi! I have been pointed to the paper "Legacy Encryption Downgrade Attacks against LibrePGP and CMS" at https://eprint.iacr.org/2024/1110.pdf .
I had only the time for brief look at it but it is obviously the final
version of a draft paper I received for commenting last November
"AEAD-to-Legacy-CFB-Encryption Downgrade Attacks on GnuPG AEAD OCB".
The upshot of the paper is that if you disable all protections and get
the target to build an oracle for you you can attack Open/Libre/*/PGP.
The requirement for GPG is to use the strongly deprecated
"--ignore-mdc-error" option which we introduced in the course of the
EFail thing, to still allow the decryption of data created with OpenPGP
software before ~2003.
The other attach option they consider is the attack target provides an
oracle to return decrypted data which has not passed the integrity
check. Many gpg use cases work with gpg in a pipeline and thus for
obvious reasons the data is firs decrypted and processed and the final
status on whether that data is trustworthy will only be available at the
end of processing in the pipeline. Either by making use of the AD (MDC
or OCB) or by the status of the signature. This might not always be
easy to implement but that is how large systems are designed. It takes
some knowledge to properly process data and it does not matter whether
encryption is involved.
Find below my response to a request from the BSI to comment on the draft
of the paper. I wrote in German back then and do not have the time to
translate it for you. Maybe someone else can deepl it. For a reality
check I can't resist to link to one of Peter's slides [1].
Shalom-Salam,
Werner
Please recall that my comment below is on a draft of the paper. I don't
know whether that draft is available somewhere.
--8<---------------cut here---------------start------------->8---
From: Werner Koch [...]
Subject: Re: Sicherheitsschwäche OpenPGP
To: [...]@bsi.bund.de
cc: [...]
Date: Thu, 30 Nov 2023 14:46:11 +0100 (38 weeks, 1 day, 1 hour ago)
Sehr geehrte Damen und Herren,
wir wurden gebeten, Stellung zu einer vermeintlichen Sicherheitsschwäche
in GnuPG und GnuPG VS-Desktop, wie in dem Paper
Falko Strenzke, Johannes Roth:
AEAD-to-Legacy-CFB-Encryption Downgrade Attacks on GnuPG AEAD OCB
beschrieben, zu nehmen:
Zusammenfassung: Wir können hier keine Sicherheitsschwäche erkennen.
Das Paper geht von falschen Voraussetzungen aus da es eine spezielle
Konfiguration der Software benötigt: Die Option „ignore-mdc-error“ wäre
hierzu in eine Konfigurationsdatei einzutragen. Die Dokumentation zu
dieser Option sagt:
This option changes a MDC integrity protection failure into a warning.
It is required to decrypt old messages which did not use an MDC. It
may also be useful if a message is partially garbled, but it is
necessary to get as much data as possible out of that garbled message.
Be aware that a missing or failed MDC can be an indication of an
attack. Use with great caution; see also option --rfc2440.
Der MDC (Manipulation Detection Code) ist die seit 20 Jahren benutzte
Form von Authenticated Encryption (AD) in OpenPGP. Im Zuge des EFail
Papers wurde die bereits damals vorhandene Warnung in eine harte
Fehlermeldung geändert. Es werden damit keine Dateien mehr gespeichert,
die ohne MDC verschlüsselt wurden. Im Paper wird auf Seite 14 unter
„Practical attacks on GnuPG“ als Voraussetzung lediglich:
When running the initial query step against a downgraded GnuPG AEAD
OCB-AES packet using GnuPG 2.2.27 as the decryption oracle, [...]
dies genannt. Die notwendige Konfigurationsänderung „ignore-mdc-error“
wird im gesamten Paper nicht erwähnt.
Auf Seite 6 wird irreführend behauptet:
Table 3 also indicates that both implementations support the
decryption of SED packets. When decrypting SED packet with GnuPG, the
following message is output
gpg: WARNING: message was not integrity protected
gpg: decryption forced to fail!
and the file is still decrypted.
Sofern eine Ausgabedatei angegeben wurde, so wird diese in diesem Fall
auch wieder gelöscht. Ferner, und wesentlich wichtiger, wird auf der
Kommandozeile und auch bei der Verwendung der GPGME Bibliothek ein
Fehlercode zurückgegeben. Die Prüfung von Fehlerrückgabewerten ist eine
essentielle Grundvoraussetzung bei der Verwendung von Software.
Wird „gpg” (das Kommandozeilentool) in einer Pipeline verwendet, so
speichert es keine Daten in temporären Dateien oder im RAM sondern gibt
diese direkt auf der Standardausgabe aus. Dies ermöglicht die
Entschlüsselung beliebig großer Daten und wird vielfach verwendet. Dies
enthebt die übergeordneten Prozeduren aber nicht von der Pflicht die
Fehlerrückgabe am Ende zu prüfen.
Auf Seite 15 wird als mögliche „Countermeasure“ Folgendes angegeben:
A straightforward implementation countermeasure effective for the
current state of GnuPG AEAD is furthermore to not support the
deprecated SED de- cryption. However, this countermeasure has the
drawback that it can only be enforced by the receiving client and for
the sender of a GnuPG AEAD packet it would remain unknown if the
receiving client is vulnerable or not.
Hierzu ist zu sagen, daß dies seit 2018 genauso implementiert ist:
Noteworthy changes in version 2.2.8 (2018-06-08)
* gpg: Decryption of messages not using the MDC mode will now lead
to a hard failure even if a legacy cipher algorithm was used. The
option --ignore-mdc-error can be used to turn this failure into a
warning. Take care: Never use that option unconditionally or
without a prior warning.
Eine Verwendung von noch älteren Versionen muß nicht berücksichtigt
werden, da diese Fehler enthielten, die einen direkten Zugriff auf den
Rechner erlauben würden.
Desweiteren ist anzumerken, daß Systeme Tools für Offline-Protokolle wie
OpenPGP oder CMS einsetzen, grundsätzlich vermeiden sollten als Orakel
einsetzbar zu sein. In automatisierten Systeme ist somit die Rückgabe
eines Fehler daraufhin zu designen und Rückgaben möglichts zeitverzögert
durchzuführen sind um so Angriffe nach dem Bleicherbacherprinzip zu
verhindern. Eine Rückgabe gar von fehlerhaft entschlüsselten Daten, wie
in dem Paper angenommen, sollte niemals vorkommen.
Die vorgeschlagene Schlüsselableitung bei der Verwendung des neuen OCB
Modus wäre sicherlich erwägenswert gewesen. Seit der Vorstellung des
OCB Modus im Herbst 2017 und des Deployments im Frühjahr 2018 wurde dies
aber nie als notwendig erachtet. Erst im Zusammenhang mit der
Spezifizierung eines GCM Modus im „crypto-refresh” (irgendwann zwischen
Herbst 2021 und Frühjahr 2022) wurde eine Schlüsselableitung hierzu
notwendig. Im Übrigen halte ich die Verwendung von GCM, sowie allgemein
die Proliferation von Algorithmen, für eine wesentlich größere
Schwachstelle als den beschriebenen Downgrade Angriff von OCB auf den
Legacy CFB Modus.
Viele Grüße,
Werner Koch
p.s.
Als Autor und Maintainer von GnuPG sehe ich keine Notwendigkeit das
beschriebene Paper unter Verschluss zuhalten. Meine Antwort kann gerne
veröffentlich werden.
--
g10 Code GmbH -=- GnuPG.com -=- AmtsGer. Wuppertal HRB 14459
Bergstr. 3a Geschäftsführung Werner Koch
D-40699 Erkrath https://gnupg.com USt-Id DE215605608
--8<---------------cut here---------------end--------------->8---
[1] http://www.cs.auckland.ac.nz/~pgut001/pubs/bollocks.pdf
--
The pioneers of a warless world are the youth that
refuse military service. - A. Einstein
openpgp-digital-signature.asc
Description: PGP signature
_______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
