Erklärung der internen Struktur von iMessage

• iMessage nutzt APNs nicht nur als einfachen Benachrichtigungskanal, sondern als bidirektionale Übertragungsbasis und bündelt über IDS die Registrierung und Abfrage öffentlicher Schlüssel sowie die Vorbereitung der Nachrichtenübermittlung
• Nach der Verbindung mit APNs erhält ein Gerät ein push token und filtert über das iMessage-Topic com.apple.madrid, welche eingehenden Nachrichten zugestellt werden sollen
• Für die IDS-Registrierung sind ein Apple-ID-Authentifizierungstoken, ein langlebiges Zertifikat, das Hochladen öffentlicher Verschlüsselungs- und Signaturschlüssel sowie die Übermittlung von validation data erforderlich, wodurch die Nutzung auf Nicht-Apple-Geräten bewusst erschwert wird
• Die Nachrichtenverschlüsselung ist in das ältere pair und das neuere pair-ec unterteilt; pair-ec bietet auf Basis von pre-keys eine Forward Secrecy ähnlich wie bei Signal
• Absender können verschlüsselte Payloads pro Empfänger einzeln oder gebündelt senden, für die Entschlüsselung auf aktuellen Geräten muss der AES-Schlüssel jedoch ein HMAC-Tag enthalten

---

APNs als Übertragungsbasis von iMessage

• Eine der Basisschichten von iMessage ist der Apple Push Notification Service (APNs)
• APNs ist dieselbe Schicht, die App-Store-Apps nutzen, um auch dann Echtzeitbenachrichtigungen und Updates zu erhalten, wenn sie geschlossen sind
• Bei iMessage dient APNs nicht nur zum Empfang von Benachrichtigungen, sondern arbeitet als bidirektionaler Dienst auch für die Nachrichtenübertragung
• Wenn sich ein Gerät mit APNs verbindet, erhält es ein push token
  • Dieses Token wird verwendet, um Benachrichtigungen an ein bestimmtes Gerät weiterzuleiten
  • Technisch unterscheidet es sich von dem Token aus der API application:didRegisterForRemoteNotificationsWithDeviceToken:
  • Das Token dieser API ist app-spezifisch und wird für die Bundle-ID der Anwendung angefordert, der Zweck ist jedoch ähnlich
• Beim Senden einer Push-Benachrichtigung an ein Gerät muss auch das topic der Nachricht angegeben werden
  • Das Topic sieht in der Regel wie eine Bundle-ID aus
  • Das Topic von iMessage ist com.apple.madrid
• Wenn sich ein Gerät mit APNs verbindet, sendet es eine filter message, um dem Server mitzuteilen, welche Nachrichten zugestellt werden sollen
  • Der APNs-Server wird auch APNs Courier genannt
  • Eine filter message kann eine Liste von Topics mit Status enthalten
  • Ein Topic-Status kann enabled, opertunistic, paused oder disabled sein

IDS-Abfragen auf APNs

• APNs wird nicht nur für die eigentliche Nachrichtenübermittlung von iMessage verwendet
• Über eine pseudo-HTTP-Schicht auf APNs kann IDS Abfragen senden und Antworten empfangen
• Für die Verbindung zu APNs ist ein vom Albert activation server ausgestelltes Client-Zertifikat erforderlich

IDS und der Apple-ID-Authentifizierungsablauf

• IDS dient als Schlüsselserver von iMessage und wird auch für andere Dienste wie FaceTime verwendet
• IDS scheint für IDentity Services zu stehen, eine offizielle Bestätigung gibt es laut Beschreibung jedoch nicht
• Da iMessage Ende-zu-Ende-Verschlüsselung verwendet, müssen die öffentlichen Schlüssel aller Teilnehmer sicher ausgetauscht werden
• Der erste Schritt der IDS-Registrierung ist das Erhalten eines Authentifizierungstokens
  • Dafür müssen der API Apple-ID-Benutzername und Passwort übergeben werden
• 2FA wurde erst später in die IDS-API eingepasst
  • Beim Legacy-Verfahren wird der 2FA-Code direkt an das Passwort angehängt
  • Das GrandSlam-Verfahren weist mit „Anisette data“ nach, dass es sich um dasselbe Gerät handelt, sodass der 2FA-Code nicht erneut eingegeben werden muss
  • Danach kann ein Password Equivalent Token (PET) bezogen werden, das wie Passwort und 2FA-Code verwendet werden kann
• Nach Erhalt des Authentifizierungstokens muss es sofort gegen ein länger gültiges Zertifikat getauscht werden
  • Dieses Zertifikat ermöglicht zwar die IDS-Registrierung, reicht aber für sich genommen nicht aus, um Schlüsselabfragen durchzuführen

IDS-Registrierung und validation data

• Der wichtigste Schritt bei der IDS-Einrichtung ist die registration
• Bei der Registrierung werden öffentliche Verschlüsselungs- und Signaturschlüssel auf den Schlüsselserver hochgeladen
• Ebenfalls hochgeladen werden verschiedene client data zu den vom Gerät unterstützten Funktionen
• Eine IDS-Registrierungsanfrage benötigt einen binären Blob namens „validation data“
  • Das ist Apples Prüfmechanismus, der verhindern soll, dass Nicht-Apple-Geräte iMessage nutzen können
• Zur Erzeugung der validation data werden Informationen wie serial number, Modell und Disk-UUID des Geräts verwendet
  • Nicht alle validation data können gleich behandelt werden
  • Ähnlich wie bei Hackintosh beeinflussen Kontoalter und ein „score“, ob fehlerhafte Seriennummern nutzbar sind oder ob Fehler beim „customer code“ auftreten
• Das Binärprogramm zur Erzeugung der validation data ist stark obfuskiert
  • pypush umgeht dieses Problem, indem es das obfuskierte Binärprogramm mit einem benutzerdefinierten mach-o loader und der Unicorn Engine emuliert
  • pypush stellt dem emulierten Binärprogramm Geräteeigenschaften wie die serial number über eine Datei data.plist bereit

Schlüsselabfrage und session token

• Nach der IDS-Registrierung erhält man ein identity keypair
• Mit diesem keypair können Abfragen öffentlicher Schlüssel durchgeführt werden
• Gibt man das gewünschte Konto an, erhält man eine Liste von „identities“
  • Jede identity entspricht einem auf diesem Konto registrierten Gerät
  • Sie enthält wichtige Informationen wie public key, push token und session token
• Das session token wird benötigt, um Nachrichten an ein Gerät zu senden
  • Es dient als Nachweis, dass kürzlich eine Abfrage durchgeführt wurde
  • Das session token läuft ab
  • Es kann nicht geteilt werden, da es nur vom Konto verwendet werden kann, das die Abfrage ausgeführt hat

Empfangene Nachrichten und Verschlüsselungsformate

• Um Nachrichten zu empfangen, genügt es, die APNs-Verbindung auf com.apple.madrid zu filtern und ein active state packet zu senden
• Das Verschlüsselungsformat eingehender Nachrichten hängt von den bei der IDS-Registrierung gemeldeten capabilities und der iOS-Version des sendenden Geräts ab
  • Das ältere Format vor iOS 13 ist pair
  • Das neuere Format ist pair-ec
• Das Format pair ist besser dokumentiert und einfacher zu implementieren
• Im Gegensatz zum neueren pair-ec bietet pair keine Forward Secrecy auf Basis von „pre-keys“
• Nachrichten lassen sich anhand mehrerer wissenschaftlicher Arbeiten und der pypush-Implementierung entschlüsseln
• Die Verifikation von Nachrichtensignaturen ist optional, aber wichtig, wenn man einen sicheren Client bauen will

Versandmethoden und Hinweise für die Implementierung

• Das Senden von Nachrichten ist weitgehend der umgekehrte Prozess des Empfangs
• Nachrichten können für jeden Empfänger einzeln versendet werden
• Es ist auch möglich, mehrere Empfänger und die jeweils für sie verschlüsselten Payloads in einem großen Bundle zusammenzufassen
  • In diesem Fall trennt APNs diese wieder auf
• Nachrichten werden an alle Teilnehmer einer Unterhaltung zugestellt
  • Auch an andere Geräte des eigenen Kontos
• Ein oft übersehener Punkt beim Senden ist, dass der AES-Schlüssel nicht vollständig zufällig ist
  • An den AES-Schlüssel ist ein HMAC als Tag angehängt
  • Verwendet man einen vollständig zufälligen AES-Schlüssel, schlägt die Nachrichtenentschlüsselung auf aktuellen Geräten fehl

Verwandte Implementierungen und Referenzmaterial

• pypush: Open-Source-Projekt zur Reimplementierung von iMessage
• IMFreedom Knowledge Base: iMessage: Wissensdatenbank zu iMessage
• M. Frister: pushproxy: Verwandte Implementierung
• Nicolás: apns-dissector: Analysewerkzeug für APNs
• QuarkSlab: iMessage Privacy: Material zum Datenschutz von iMessage
• Garman et al. Chosen Ciphertext Attacks on Apple iMessage: Facharbeit zu Chosen-Ciphertext-Angriffen auf Apple iMessage
• NowSecure: Reverse Engineering iMessage: Material zum Reverse Engineering von iMessage
• Elcomsoft: iMessage Security and Attachments: Material zu iMessage-Sicherheit und Anhängen
• Eric Rabil’s open-imcore: Verwandtes Projekt
• The Apple Wiki: Apple Push Notification Service: Dokumentation zu APNs
• Mihir Bellare and Igors Stepanovs: Security under Message-Derived Keys: Signcryption in iMessage: Facharbeit zu Signcryption in iMessage
• Apple Platform Security: How iMessage sends and receives messages securely: Apples Erklärung zur iMessage-Sicherheit
• Nicolás: Apple IDS payload keys: Material zu Apple-IDS-Payload-Schlüsseln

[GN⁺]

Meinungen auf Hacker News

• Apple dürfte damit beginnen, iMessage per Attestation (DeviceCheck) abzuriegeln.
  Allerdings gibt es dabei das Problem, dass ältere Geräte ein Software-Update benötigen.

  • Zum Teil macht Apple das bereits.
    Beim Erzeugen der „validation data“ werden Informationen wie die Seriennummer des Geräts, das Modell und die Disk-UUID verwendet. Wie bei Hackintosh entscheidet sich je nach Alter des Kontos und „Score“, ob man eine ungültige Seriennummer verwenden kann oder ob ein „customer code“-Fehler erscheint.
    Der „customer code“-Fehler ist praktisch Apples Prompt für eine fehlgeschlagene Attestation; wenn man einmal davon betroffen ist, muss man den Apple Support kontaktieren, um die Apple-ID entsperren zu lassen.
    Normale Kunden kommen leicht hindurch, indem sie den Login auf einem legitimen Gerät bestätigen, während Hackintosh-Nutzer diesen Prozess mit Umgehungstechniken austricksen.
    https://old.reddit.com/r/hackintosh/comments/gij9rt/getting_...
  • Apple liefert ohnehin bereits Sicherheitsupdates für iOS-Geräte der letzten etwa 5 Jahre, daher dürfte es nicht allzu lange dauern, bis ein Update auf fast allen tatsächlich genutzten iOS-Geräten ausgerollt ist.
  • Für ältere Geräte, also Geräte ohne TPM, bräuchte es wohl kein Software-, sondern ein Hardware-Update.
  • Ich glaube, BBM funktionierte auf diese Weise, bin mir aber nicht sicher.
    Es klingt weniger nach etwas, das Teil der Sicherheit des gesamten Betriebssystems sein sollte, sondern eher nach einer Funktion, die zumindest in Apples Lockdown Mode gehören würde.
  • Möglich, aber Apple hat gerade auch RCS-Unterstützung angekündigt: https://9to5mac.com/2023/11/16/apple-rcs-coming-to-iphone/
    Vielleicht sieht Apple den jetzigen Zeitpunkt als gute Gelegenheit, in Richtung Öffnung umzuschwenken.

• Dass der Vertrag nachvollzogen wurde, ist großartig, aber mich würde auch der iMessage-Infrastruktur-Stack interessieren.
  Er ist enorm groß und funktioniert trotzdem so gut, während andere Webdienste von Apple, etwa die Foren oder das Entwicklerportal, voller Bugs sind und unfertig wirken — das macht es umso erstaunlicher.

  • Der wirklich erstaunliche Maßstab liegt darin, dass der Apple Push Notification service nicht nur iMessage transportiert.
    Auch die Push-Benachrichtigungen aller Messenger-Apps von Drittanbietern laufen darüber, ebenso Nicht-Messenger-Apps mit Benachrichtigungen.
    Interne stille Benachrichtigungen sind ebenfalls dabei. Wenn man auf dem Mac einen Termin zum Kalender hinzufügt, geht ein Push ans iPhone, dass sich iCloud-Daten geändert haben und es aktualisieren soll; wenn man eine Datei in iCloud Drive ändert, wird für die Synchronisierung anderer Geräte ein Push verschickt.
    Wenn ein Anruf eingeht, klingelt per Continuity auch der Mac; auch das ist, wie iMessage, eine verschlüsselte Push-Benachrichtigung.
    Da fragt man sich, wie viele Nachrichten pro Sekunde durch diesen Dienst laufen.

• Das ist genau das richtige Material für Hack Club. Es wäre schön, wenn du mitmachen würdest: https://hackclub.com/

• Wirklich beeindruckende Arbeit.
  Es wäre auch interessant, wenn du kurz schreiben würdest, wie du in diesen Bereich gekommen bist.
  Auf Reddit gibt es viele Schüler und Studierende, die sich fragen, wie man technisch gut wird, Programmieren lernt und einen Tech-Job bekommt; diese Perspektive wäre ziemlich hilfreich.

  • Es wirkt weniger wie ein geheimes Erfolgsrezept, sondern eher nach enorm viel konsequenter Übung, fast unbegrenzter Energie in jungen Jahren für Dinge, die man liebt, und wahrscheinlich wachen Eltern oder Rollenvorbildern.
  • In der Highschool hatte ich praktisch den ganzen Tag Zeit, an meinen eigenen Projekten zu arbeiten.
    Durch frühes Fertigwerden, Freistunden und heimliches Arbeiten an eigenen Dingen, obwohl ich es eigentlich nicht sollte, konnte ich in etwa 6 Monaten eine App bauen und veröffentlichen und war extrem produktiv.

• Ich bin wirklich neugierig, ob das Thema tatsächlich opertunistic sein kann oder ob es ein Tippfehler des Autors ist.
  Solche Tippfehler wie referer, die über Generationen hinweg fossilisiert werden, sind interessant.

  • Leider enthält mein Code viele Tippfehler :P
    Ich weiß allerdings nicht, ob das ein Tippfehler auf Apples Seite ist, aber merkwürdig ist es definitiv. Hier muss man WindowSerial verwenden, nicht eine Variante mit zusätzlichem s wie WindowsSerial.
    https://github.com/JJTech0130/pypush/blob/8b33c0ee5d540d8ac7...
  • Im Code scheint dieser Wert nicht verwendet zu werden, aber da es vermutlich ein Integer-Code ist, wirkt es eher wie ein Rechtschreibfehler des Autors.

• Dazu gibt es mehr Kontext: https://news.ycombinator.com/item?id=38531759

• Das Open-Source-Projekt pypush, das die Grundlage der heutigen iMessage-Reversing-News bildet, wird unter MongoDBs Server Side Public License veröffentlicht, Eigentümer ist Beeper.
  Laut JJTech auf Discord hat er die Rechte an Beeper verkauft.
  Die Library ist großartig, aber da es eine sehr starke Copyleft-Lizenz ist, dürfte das beeinflussen, wofür sie eingesetzt werden kann.

  • Jetzt ist es Zeit für Reverse Reverse Engineering.

• Die „validation data“, die zum Erstellen einer IDS-Registrierungsanfrage nötig sind, sollen Apples Mechanismus sein, um sicherzustellen, dass Nicht-Apple-Geräte iMessage nicht nutzen können. Ich frage mich, ob das gegen den DSA oder DMA verstößt, sobald sie in der EU durchgesetzt werden.

  • DSA und DMA verleihen niemandem auf magische Weise das Recht, beliebige Requests an Apple-Server zu stellen, und zwingen Apple auch nicht dazu, bestimmte gültige Antworten zu liefern.
    Wie auch immer Apple DSA und DMA einhalten wird: Auf diese Weise wird es nicht passieren.
  • Erst recht nicht, da iOS jetzt RCS unterstützen wird.
    Ein plattformübergreifendes First-Party-iMessage ist im Grunde nur ein Wunschtraum von Technik-Nerds, und persönlich finde ich das völlig in Ordnung.

• In der Ankündigung von Beeper Mini [1] steht ausdrücklich, dass Nutzer ihre Telefonnummer registrieren und iMessages senden und empfangen können, ohne eine Apple-ID zu haben.
  Außerdem wird erklärt, dass das Gerät direkt mit Apple kommuniziert.
  Dieser Artikel sagt jedoch, dass IDS als Schlüsselserver für iMessage verwendet wird, dass man im ersten Schritt der IDS-Registrierung mit Apple-ID-Benutzername und Passwort ein Authentifizierungstoken holen muss und dass nach der Registrierung öffentliche Schlüssel mit dem erhaltenen Identity-Keypair abgefragt werden.
  Damit stellt sich die Frage, wie die Beeper-Mini-App eine beliebige Android-Telefonnummer mit einem öffentlichen Schlüssel bei IDS registriert und sogar die öffentlichen Schlüssel von Empfängern ohne Apple-ID abfragt.
  Die Antwort scheint ein SMS Gateway zu sein, das weder im Originaltext noch in [1] wirklich erklärt wird, und genau das wirkt wie die geheime Zutat.
  [1] https://blog.beeper.com/i/139416474/security-and-privacy

  • Ich habe Beeper Mini auf einem Android-Smartphone installiert; nachdem beim Versuch, für die Telefonnummernregistrierung eine SMS an Apple zu senden, ein Fehler auftrat, erschien ein Dialog, der nach einer Apple-ID fragte.

• Wirklich erstaunliche Arbeit.
  Allerdings stört mich die Stelle, an der der Artikel sagt, das ältere pair-Format sei besser dokumentiert und einfacher zu implementieren, biete aber im Gegensatz zum neuen pair-ec-Format keine Forward Secrecy durch Signal-ähnliche „pre-keys“.
  Ich weiß nicht, ob es Belege dafür gibt, dass aktuelles iMessage, also die Variante mit ECIES, tatsächlich pre-keys verwendet.
  Für mich sieht es eher so aus, als sei bei der Verschlüsselung und vielleicht beim Signieren ECIES anstelle von RSA eingesetzt worden; allein dadurch entsteht keine Forward Secrecy.
  Wenn es dafür keine Belege gibt, könnte es sich um eine Fehlinterpretation des Zusammenhangs zwischen RSA, elliptischen Kurven und Forward Secrecy handeln.
  Der Wikipedia-Artikel zu iMessage scheint denselben Fehler weiterzuverbreiten, und die zitierte Quelle behauptet das tatsächlich nicht.