Apple Mail kann keine S/MIME-Nachrichten mit RSAES-OAEP entschlüsseln

iPhones und iPads laufen nach Schätzungen unabhängiger Marktanalysen weltweit auf weit über 1,5 Milliarden aktiven Geräten. Nach unserer Einschätzung entfällt davon ein Anteil im Bereich von 25 bis 30 Prozent auf Geschäftsumfelder, also Smartphones und Tablets, die im beruflichen Kontext genutzt werden, sei es als reines Diensthandy, als COPE-Gerät oder als BYOD-Hardware mit dienstlicher Mail-Konfiguration. Das ergibt eine Größenordnung von rund 350 bis 450 Millionen Geräten, über die täglich geschäftliche Kommunikation läuft. Apple Mail ist auf jedem dieser Geräte vorinstalliert und nach unserer Beobachtung in Kunden- und Beratungsprojekten weiterhin ein häufig eingesetzter Mail-Client auf iOS und iPadOS, weil er ohne zusätzliche Installation, ohne separates Konto-Onboarding und mit Unterstützung für Exchange Online und IMAP direkt einsatzfähig ist.

Selbst wenn nur ein einstelliger Prozentanteil dieser Apple-Mail-Nutzer im geschäftlichen Umfeld zusätzlich S/MIME einsetzt, also vor allem in Behörden, im Finanz- und Versicherungssektor, in der Pharma- und Medizintechnikbranche sowie in regulierten Beratungsfeldern wie Steuer- und Rechtsberatung, sprechen wir von einer Empfängergruppe in zweistelliger Millionenhöhe weltweit. Genau diese Empfängergruppe ist von dem Verhalten betroffen, das wir in dieser Analyse beschreiben.

Wir haben Apple Mail unter iOS 26.5 darauf untersucht, wie der Client eingehende S/MIME-Nachrichten mit modernem RSA-Key-Transport verarbeitet und die Ergebnisse zusätzlich an der iOS-27.0-Developer-Beta (Build 24A5355q vom 8. Juni 2026) verifiziert. Das Ergebnis lässt sich in einem Satz zusammenfassen. Apple Mail entschlüsselt RSAES-OAEP nicht und zwingt Sender damit auf das ältere PKCS#1 v1.5 zurück, obwohl RFC 3560 bereits 2003 das modernere RSAES-OAEP für CMS spezifiziert und zur Behebung der bekannten Padding-Schwäche von v1.5 empfohlen hat. [1][2][3][8]

Apple Mail auf dem Untersuchungstisch

Aus unserer Analyse ergeben sich sechs zentrale Aussagen, die für jede Organisation relevant sind, die S/MIME mit Apple-Mail-Empfängern einsetzt oder einsetzen möchte.

• Apple Mail unter iOS 26.5 entschlüsselt eingehende S/MIME-Nachrichten ausschließlich, wenn der Content-Encryption-Key per RSA mit PKCS#1 v1.5 oder per ECDH-Key-Agreement übertragen wird. Das modernere RSAES-OAEP nach RFC 3560 wird nicht unterstützt, obwohl die zugehörige Algorithmen-Konstante in der Apple-Codebasis existiert.
• Die Lücke besteht in beiden parallelen CMS-Backends von Apple Mail. Welcher Pfad eine konkrete Nachricht verarbeitet, ist für das Ergebnis irrelevant. Ein Workaround auf Empfänger-Seite, etwa durch Wechsel des Konfigurationsprofils oder der Identity, ist daher nicht möglich.
• Sender werden zu einem Downgrade auf PKCS#1 v1.5 gezwungen, einem Padding-Verfahren aus dem Jahr 1993, das seit dem Bleichenbacher-Angriff von 1998 zu einer praktisch nachgewiesenen und wiederholt reproduzierten Angriffsklasse zählt und für das RFC 3560 bereits 2003 mit RSAES-OAEP einen sichereren Nachfolger für CMS und S/MIME spezifiziert und empfohlen hat.
• Die UI-Fehlermeldung verweist auf ein vermeintlich fehlendes Profil und führt zu Fehldiagnosen am Helpdesk, weil die eigentliche Ursache, eine nicht unterstützte Krypto-Variante, nicht erkennbar gemacht wird.
• Wir haben den Vorgang im Dezember 2025 an Apple gemeldet. Sechs Monate später liegt aus dem Feedback-Kanal keine inhaltliche Antwort vor. Apple Security hat den Fall an das Feedback-Team zurückverwiesen.

E-Mail-Verschlüsselung mit S/MIME

S/MIME (Secure/Multipurpose Internet Mail Extensions) ist der seit Mitte der Neunzigerjahre standardisierte Mechanismus für Ende-zu-Ende-Signatur und -Verschlüsselung von E-Mails. Anders als bei rein transportverschlüsselten Mails über TLS wird der Inhalt einer S/MIME-Nachricht bereits auf dem Sender-Gerät verschlüsselt und erst auf dem Empfänger-Gerät wieder entschlüsselt. Der zugrundeliegende Container ist die Cryptographic Message Syntax (CMS), historisch aus PKCS#7 hervorgegangen und heute in RFC 5652 festgelegt, mit S/MIME 4.0 in RFC 8551 als Anwendungsspezifikation. [9][10]

Verschlüsselt wird der eigentliche Nachrichteninhalt mit einem symmetrischen Sitzungsschlüssel, dem Content-Encryption-Key. Dieser Sitzungsschlüssel wiederum wird mit dem öffentlichen Schlüssel des Empfängers verschlüsselt und an die Nachricht angehängt. Damit kann jeder Empfänger seinen eigenen Sitzungsschlüssel mit dem privaten Schlüssel seines S/MIME-Zertifikats entpacken und den Nachrichteninhalt lesen. Dieser Vorgang heißt Key Transport.

Das alte und das neue Verfahren

Für den RSA-Key-Transport existieren zwei verbreitete Varianten. Die ältere ist PKCS#1 v1.5, definiert 1993 und über lange Zeit das Standardverfahren für RSA-Verschlüsselung. Die jüngere ist RSAES-OAEP, definiert in PKCS#1 v2 und für CMS-Anwendungen mit RFC 3560 im Jahr 2003 spezifisch festgelegt. Beide haben dasselbe Ziel, nämlich den symmetrischen Sitzungsschlüssel sicher zum Empfänger zu transportieren. Sie unterscheiden sich im Padding-Verfahren, das den eigentlichen Schlüsselblock vor der Verschlüsselung mit einem Sicherheitsrahmen umgibt.

PKCS#1 v1.5 nutzt ein einfach strukturiertes Padding mit fester, beim Empfänger auf Wohlgeformtheit prüfbarer Form. Diese Eigenschaft ist 1998 durch Daniel Bleichenbacher als angreifbar nachgewiesen worden und in mehreren späteren Arbeiten als praktisch ausnutzbar bestätigt, zuletzt 2017 mit dem ROBOT-Angriff und 2023 mit der Marvin-Attack. RSAES-OAEP nutzt ein probabilistisches, durch MGF1 maskiertes Padding und ist heute der von IETF und NIST empfohlene Standard für neue Implementierungen. In den meisten modernen CMS-fähigen Mail-Clients und Encryption Gateways ist OAEP die Default-Wahl beim Versand.

Apple Mail kann nach unserer Analyse ausschließlich die ältere Variante. Alle Nachrichten, die ein Sender mit dem modernen OAEP-Verfahren verschickt, bleiben in Apple Mail unter iOS unleserlich.

Hintergrund und Entdeckung

Bei der Bearbeitung mehrerer Kundenprojekte sowie konkreter Störungsmeldungen ist uns wiederholt aufgefallen, dass bestimmte S/MIME-Nachrichten in Apple Mail unter iOS nicht zu öffnen waren. Die Fehlermeldung im Client lautete jedes Mal "Install a profile containing your encryption identity to decrypt this message", obwohl die jeweilige S/MIME-Identity nachweisbar installiert war. Anfangs sah das nach einer banalen Profil- oder Schlüsselbund-Frage aus. Erst eine Korrelationsanalyse über mehrere Vorfälle hinweg machte deutlich, dass die Identity-Theorie nicht trägt, weil das Problem immer nur bei einer Teilmenge der Nachrichten desselben Senders auftrat. Der gemeinsame Nenner aller nicht entschlüsselbaren Nachrichten war der verwendete Key-Transport-Algorithmus. Mails mit RSAES-OAEP scheiterten reproduzierbar, identische Mails desselben Senders mit PKCS#1 v1.5 öffneten sich problemlos.

Um den Verdacht über die reine Empfänger-Beobachtung hinaus zu belegen, haben wir die relevanten iOS-Frameworks analysiert und gegen die öffentlich verfügbaren Apple-Open-Source-Veröffentlichungen abgeglichen.

Architektur des S/MIME-Stacks

Apple Mail betreibt in iOS 26.5 zwei voneinander unabhängige CMS-Backends parallel. Beide kommen je nach Aufrufkette in MobileMail und maild gleichermaßen zum Einsatz, was zur Folge hat, dass eine einzelne Nachricht je nach Verarbeitungspfad in dem einen oder dem anderen Backend landet. Der moderne Pfad leitet die CMS-Verarbeitung von EmailCore.framework an MessageSecurity.framework weiter, dort übernehmen die MSCMS-Klassen die ASN.1-Dekodierung über die Heimdal-Implementierung. Der Legacy-Pfad ist deutlich älter und nutzt Message.framework, das wiederum die NSS-abgeleitete libsecurity_smime aus Security.framework anspricht. Funktional decken beide denselben Aufgabenraum ab, technisch greifen sie auf unterschiedliche Bibliotheken und Code-Pfade zurück.

Beide Pfade enden, sobald es um RSA-Key-Transport geht, am selben Crypto-Primitiv mit fest verdrahtetem PKCS#1 v1.5. Die folgende Übersicht zeigt die vollständigen Aufrufketten und macht deutlich, warum die Lücke nicht durch einen Frontend-Workaround oder ein einzelnes Code-Patch zu schließen wäre.

Der moderne Pfad

Die Dispatch-Logik im modernen Pfad liegt in der Methode -[MSCMSRecipientInfo key:]. Sie übernimmt die Aufgabe, abhängig vom angegebenen Algorithmus den passenden Entschlüsselungs- oder Key-Agreement-Pfad anzustoßen. Apple hat genau zwei Vergleiche vorgesehen. Ist der Algorithmus identisch mit der Konstante MSEncryptionAlgorithmRSA, also der OID 1.2.840.113549.1.1.1 für klassisches rsaEncryption mit PKCS#1 v1.5, ruft die Methode SecKeyCreateDecryptedData mit dem Algorithmus-Parameter kSecKeyAlgorithmRSAEncryptionPKCS1 auf. Stimmt der Algorithmus dagegen mit MSKeyAgreementAlgorithmDHSinglePass_StdDH_SHA1KDF überein, startet sie die ECDH-Key-Agreement-Variante mit anschließendem AES-Key-Unwrap. Trifft keiner der beiden Vergleiche zu, gibt die Methode nil zurück. nil ist in Objective-C und Swift, den Programmiersprachen der Apple-eigenen Frameworks, der Standardwert für "kein Ergebnis", vergleichbar mit null in Java oder None in Python. Für die aufrufende Schicht heißt das, dass keine Entschlüsselung stattgefunden hat und kein Sitzungsschlüssel zur weiteren Verarbeitung vorliegt.

Die RSAES-OAEP-OID 1.2.840.113549.1.1.7 ist in MessageSecurity zwar als Konstante MSEncryptionAlgorithmRSAOAEP definiert und insofern Apple bekannt, sie ist aber an keinen Entschlüsselungspfad gebunden. Die Konstante existiert, wird aber von keinem Vergleich abgefragt und entsprechend nirgendwo zur tatsächlichen Verarbeitung herangezogen. Eine eingehende Nachricht mit OAEP-Key-Transport durchläuft die Methode, schlägt beide Vergleiche fehl und fällt zum nil-Rückgabewert durch.

Der Legacy-Pfad

Im Legacy-Pfad nutzt Message.framework die NSS-abgeleitete CMS-Implementierung der Security.framework. Der RSA-Unwrap des Content-Encryption-Key landet in der Funktion SecCmsUtilDecryptSymKeyRSA, die wiederum intern auf SecKeyDecrypt mit dem Padding-Parameter kSecPaddingPKCS1 abbildet. Diese Festlegung ist im Code hart verdrahtet, der eigentliche RSA-Aufruf besitzt keinen Algorithmus-Verzweigungspunkt. Die Funktion entscheidet nicht situativ anhand der OID der Nachricht, sondern nimmt grundsätzlich an, dass es sich um PKCS#1 v1.5 handelt.

Die Analyse zeigt, dass SecKeyDecrypt in der gesamten Security-CMS-Schicht genau einmal aufgerufen wird, und das mit Padding-Argument 1, also kSecPaddingPKCS1. Die parallel im System vorhandenen OAEP-fähigen APIs SecKeyCreateDecryptedData mit kSecKeyAlgorithmRSAEncryptionOAEPSHA-Varianten werden vom CMS-Code an keiner Stelle aufgerufen. Apple Open Source bestätigt diesen Befund auf Quelltext-Ebene im veröffentlichten Tag Security-61901.101.4. Es handelt sich also nicht um eine Eigenheit einer einzelnen iOS-Version, sondern um eine Eigenschaft des seit Jahren stabilen NSS-abgeleiteten CMS-Codes. [4]

Eine pfadunabhängige Lücke

Beide Backends führen zum selben negativen Ergebnis. Daneben ist im modernen Pfad ECDH-Key-Agreement nach DH-SinglePass mit SHA1KDF implementiert. Der Legacy-Pfad wurde für ECDH nicht im Detail untersucht, weil der Befund zum RSA-Key-Transport bereits pfadunabhängig ist.

Welcher Pfad bei einer konkreten Nachricht zum Einsatz kommt, ist für das Endergebnis irrelevant. Die fehlende OAEP-Unterstützung ist aus unserer Sicht, eine Designentscheidung in beiden Backends und keine Verfehlung an einer einzelnen Code-Stelle. Damit ist auch klar, dass ein Workaround auf Empfänger-Seite, etwa durch Wechsel des Konfigurationsprofils oder der Identity, das Verhalten nicht ändert.

Cross-Version-Bestätigung in iOS 27.0 Beta

Wir haben den Befund zunächst in der freigegebenen iOS-Version 26.5 (Build 23F77) nachgewiesen. Zur Verifikation und um auszuschließen, dass Apple den Fix bereits in einer frühen Beta des nächsten Major-Releases eingepflegt hat, haben wir die zum Zeitpunkt dieser Analyse aktuelle iOS-27.0-Developer-Beta (Build 24A5355q vom 8. Juni 2026) parallel untersucht. [8]

Sämtliche im vorherigen Abschnitt beschriebenen Methoden in MessageSecurity und Security.framework liegen in der 27.0-Beta mit unveränderter Logik vor. Die Dispatch-Methode -[MSCMSRecipientInfo key:] vergleicht weiterhin nur gegen die beiden bekannten Konstanten für PKCS#1 v1.5 und ECDH-Key-Agreement. Im Legacy-Pfad ruft die NSS-abgeleitete CMS-Implementierung weiterhin SecKeyDecrypt mit kSecPaddingPKCS1 auf. Ein systematischer Symbol- und Strings-Vergleich zwischen 26.5 und 27.0-Beta zeigt keine neu eingeführten OAEP-Bindungen, keine zusätzlichen Algorithmus-Vergleiche, keine Hinweise auf eine geplante Implementierung. Apple hat zwischen den beiden Versionen keinen Fix nachgereicht.

Sicherheitsrelevanz

RSAES-OAEP wurde nicht aus Eleganzgründen eingeführt, sondern als gezielte Antwort auf eine konkrete und seit Jahrzehnten produktive Angriffsklasse, die das ältere PKCS#1 v1.5 strukturell betrifft.

Den Ausgangspunkt setzte Daniel Bleichenbacher 1998 mit seinem Padding-Oracle-Angriff. Die Grundidee ist verblüffend einfach. Ein Angreifer, der einen verschlüsselten RSA-Block abgefangen hat und der gleichzeitig beobachten kann, ob ein selbst konstruierter Modifikations-Block beim Empfänger als gültiges PKCS#1-v1.5-Padding interpretiert wird, kann in einer Folge sorgfältig gewählter Anfragen den ursprünglichen Klartext rekonstruieren. Anders gesagt, wer einen verschlüsselten Inhalt besitzt und einen noch so subtilen Hinweis bekommt, ob seine Versuchsanfragen "richtig aussehen" oder nicht, kann den ursprünglichen Inhalt entschlüsseln, ohne jemals den privaten Schlüssel zu kennen.

Die Angriffsklasse galt eine Zeit lang als praktisch überwunden, weil viele Implementierungen ihre Padding-Validierung verschleierten oder konstante Antwortzeiten erzwangen. 2017 belegte der ROBOT-Angriff, dass zahlreiche TLS-Implementierungen großer Hersteller, darunter F5, Citrix, Cisco, Bouncy Castle und WolfSSL, weiterhin verwundbar waren. 2023 zeigte der Marvin-Angriff, dass selbst Timing-Seitenkanäle in vorgeblich abgehärteten Crypto-Bibliotheken wie Mozilla NSS, OpenSSL und GnuTLS ausreichen, um Bleichenbacher in moderner Form zu reproduzieren. Die Angriffsklasse ist nicht historisch, sondern aktiv und gut dokumentiert.

Im S/MIME-Kontext ist die praktische Ausnutzung schwieriger als bei TLS, weil ein Angreifer einen verlässlichen Padding-Oracle aufbauen muss. Beobachtbare Hinweise sind aber denkbar, etwa automatische Antwort-Mails, MDN-Notifications, unterschiedliche Fehlermeldungen oder Latenzunterschiede in der Server-Verarbeitung. In hochwertigen Zielumgebungen, also dort wo S/MIME überhaupt eine Rolle spielt, bei Behörden, Finanzdienstleistern, Gesundheitsversorgern und Forschungseinrichtungen, sind solche Quellen häufig in mindestens einer Form vorhanden. Eine mit PKCS#1 v1.5 verschlüsselte Nachricht lässt sich unter ungünstigen Bedingungen also nachträglich entschlüsseln, ohne dass der Empfänger-Schlüssel jemals kompromittiert wurde.

Apple Mail zwingt Sender heute, im Jahr 2026, zurück auf die Variante, für die mit RFC 3560 schon vor über zwanzig Jahren ein moderner Nachfolger spezifiziert wurde und die heute als veraltet gilt. In gemischten Empfängergruppen, in denen auch nur ein Apple-Mail-Nutzer enthalten ist, muss der Sender entweder den gesamten Empfänger-Verteiler auf PKCS#1 v1.5 herunterstufen oder einen separaten, schwächeren Pfad ausschließlich für Apple-Empfänger konfigurieren. Beide Varianten sind betrieblich aufwendig und sicherheitstechnisch ein Rückschritt, der vollständig vermeidbar wäre, weil das System die zugrundeliegenden OAEP-Primitive bereits mitbringt. Es fehlt lediglich die Anbindung im CMS-Pfad.

Diagnose und UX-Effekt

Die Fehlertexte stammen aus Message.framework und MessageLegacy. Wenn der Unwrap nil zurückgibt, kann die aufrufende UI-Schicht zwei strukturell unterschiedliche Ursachen nicht voneinander trennen. Es ist nicht erkennbar, ob die Identity fehlt oder ob das Key-Transport-Verfahren der Nachricht nicht unterstützt wird. Im Zweifel wird die generische Aufforderung gezeigt, ein Profil mit der Encryption-Identity zu installieren. Das ist nicht nur fachlich falsch, sondern führt Administratoren auf eine falsche Fährte und kostet je nach Setup viel Zeit, bevor der eigentliche Auslöser identifiziert wird. In zwei von uns dokumentierten Fällen wurden zunächst Stunden in die Diagnose vermeintlicher Profil- und Schlüsselbund-Probleme investiert, bevor der Verdacht auf einen Algorithmus-Mismatch fiel.

Anbieter von Encryption-Gateway-Produkten (z.B. SEPPmail) haben das Verhalten inzwischen auch in ihre öffentliche Dokumentation aufgenommen. [11]

Apple-Meldepfad und Status

Wir haben den Vorgang im Dezember 2025 über das Apple-Feedback-Portal gemeldet und parallel beim Apple Security Bounty eingereicht. Aus dem Feedback-Kanal kam bis zum heutigen Tag, sechs Monate später, keine inhaltliche Antwort, der Vorgang steht weiterhin auf "Offen". Apple Security hat den Fall mit dem Hinweis zurückverwiesen, eine Inkompatibilität sei eine Feedback-Angelegenheit. Diese Einordnung ist formal nachvollziehbar, klammert aber den Sicherheitsaspekt aus, den die fehlende OAEP-Unterstützung in der gesamten Empfängergruppe erzeugt.

Allgemeine Empfehlungen

Für Empfänger: Solange Apple den Stack nicht erweitert, lassen sich eingehende OAEP-verschlüsselte Nachrichten in Apple Mail unter iOS nicht öffnen. Für besonders sensible Anwendungsfälle ist ein Wechsel auf einen alternativen Mail-Client mit eigener Crypto-Bibliothek eine Option. Wer ohnehin in einer regulierten Branche arbeitet, sollte die Auswirkungen auf das interne Threat-Modell prüfen und gegebenenfalls eine geräteseitige Ausnahme- oder Quarantäne-Regelung definieren, bis Apple nachzieht.

Für Sender: Wenn die Empfängergruppe Apple-Mail-Nutzer einschließt, bleibt die pragmatische Lösung ein Downgrade auf PKCS#1 v1.5 für diese Empfänger. Die Maßnahme sollte aktiv dokumentiert werden, weil sie den Härtungseffekt von OAEP rückgängig macht und das Threat-Modell der Kommunikation messbar verschiebt. In sicherheitskritischen Kontexten kann der Aufwand für einen empfängerselektiven Pfad geringer ausfallen als der Verzicht auf den Härtungseffekt für die gesamte Empfängergruppe.

Für Apple: Eine Erweiterung beider CMS-Backends um die OAEP-Entschlüsselung schließt die Lücke. Die zugrundeliegenden Crypto-Primitive (SecKeyCreateDecryptedData mit OAEP-SHA-Varianten) sind im System bereits vorhanden und müssten lediglich an die CMS-Pfade angebunden werden. Die Konstante MSEncryptionAlgorithmRSAOAEP ist schon definiert, es fehlt nur die Verdrahtung im Dispatch.

Quellenangaben

• [1] Apple Feedback Assistant | Apple Developer (eingereicht 17.12.2025, Report-ID FB21360843)
• [2] RFC 3560, Use of the RSAES-OAEP Key Transport Algorithm in CMS | IETF
• [3] RFC 8017, PKCS #1 v2.2, RSA Cryptography Specifications | IETF
• [4] apple-oss-distributions/Security, Tag Security-61901.101.4 | GitHub, insbesondere OSX/libsecurity_smime/lib/cmspubkey.c und OSX/libsecurity_smime/lib/crypto-embedded.c
• [5] Bleichenbacher, "Chosen Ciphertext Attacks Against Protocols Based on the RSA Encryption Standard PKCS #1", CRYPTO 1998
• [6] Böck, Somorovsky, Young, "Return Of Bleichenbacher's Oracle Threat (ROBOT)", Offenlegung Dezember 2017, USENIX Security 2018
• [7] Kario, "Everlasting ROBOT: the Marvin Attack", 2023
• [8] Indeno-eigene Analyse der iOS-27.0-Developer-Beta (Build 24A5355q vom 8. Juni 2026)
• [9] RFC 5652, Cryptographic Message Syntax (CMS) | IETF
• [10] RFC 8551, Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 Message Specification | IETF
• [11] SEPPmail Knowledge Base, Apple Mail S/MIME and RSAES-OAEP | SEPPmail