Apple-Plattformsicherheit (Januar 2026) [PDF]

 (help.apple.com)
2 Punkte von GN⁺ 2026-02-02 | 1 Kommentare | Auf WhatsApp teilen
  • Der Apple-Plattformsicherheitsleitfaden beschreibt die Sicherheitsarchitektur, in der Hardware, Software und Dienste auf allen Geräten wie iPhone, iPad, Mac und Apple Watch integriert zusammenwirken
  • Apple Silicon (SoC) und die Secure Enclave bilden die zentrale Grundlage und schaffen vom Bootvorgang über die Datenverschlüsselung bis zur biometrischen Authentifizierung eine durchgängige Vertrauenskette
  • Die Hardwaresicherheit besteht aus Boot ROM, AES-Engine, Sicherheits-Coprozessoren und weiteren Komponenten und gewährleistet den Schutz kryptografischer Schlüssel sowie sicheres Booten
  • Biometrische Authentifizierung wie Face ID, Touch ID und Optic ID wird in der Secure Enclave verarbeitet, sodass persönliche Daten nicht nach außen offengelegt werden
  • Apple stärkt die Reaktion auf Schwachstellen und die Plattformsicherheit kontinuierlich durch das Security Research Bounty Program und den Betrieb dedizierter Sicherheitsteams

Überblick über die Apple-Plattformsicherheit

  • Apple integriert Sicherheit als zentrales Designelement in alle Plattformen
    • Hardware, Software und Dienste arbeiten zusammen, um den Schutz persönlicher Daten an erste Stelle zu setzen
    • Apple Silicon und Sicherheitshardware unterstützen die Schutzfunktionen des Betriebssystems und von Drittanbieter-Apps
  • Bereitstellung einer Service-Infrastruktur für Sicherheitsupdates, den Schutz des App-Ökosystems sowie sichere Kommunikation und Zahlungen
    • Geschützt werden nicht nur die Geräte selbst, sondern auch Netzwerke und zentrale Internetdienste
  • Die wichtigsten Sicherheitsbereiche gliedern sich in die folgenden acht Felder
    • Hardware und biometrische Authentifizierung, Systemsicherheit, Verschlüsselung und Datenschutz, App-Sicherheit, Dienstesicherheit, Netzwerksicherheit, Sicherheit von Entwickler-Kits, Sicherheit der Geräteverwaltung

Apples Sicherheitsphilosophie und Betrieb

  • Apple betrachtet Datenschutz als Menschenrecht und bietet vielfältige Einstellungen, mit denen Nutzer den Zugriff von Apps auf Informationen direkt steuern können
  • Über das Programm Apple Security Bounty erhalten Forschende Belohnungen für das Auffinden von Schwachstellen
    • Details sind unter security.apple.com/bounty verfügbar
  • Dedizierte Sicherheitsteams führen Sicherheitsprüfungen auch nach Produktentwicklung und Markteinführung durch und überwachen Bedrohungen
    • Apple ist Mitglied von FIRST (Forum of Incident Response and Security Teams)
  • Apple Silicon dient als Grundlage für sicheres Booten, biometrische Authentifizierung und Datenschutz
    • Funktionen wie Kernel Integrity Protection, Pointer Authentication Codes und Fast Permission Restrictions minimieren die Auswirkungen von Angriffen
  • Unternehmen sollten ihre IT-Richtlinien überprüfen, um die mehrschichtigen Sicherheitstechnologien der Apple-Plattformen bestmöglich zu nutzen

Hardwaresicherheit und biometrische Authentifizierung

  • Sicherheit beginnt auf Hardware-Ebene; Apple-Geräte sind mit Silizium ausgestattet, in das Sicherheitsfunktionen integriert sind
    • Neben der CPU gibt es dedizierte Sicherheitssilizium-Komponenten, um die Angriffsfläche zu minimieren
  • Wichtige Komponenten
    • Boot ROM: die Wurzel des Hardware-Vertrauens und Ausgangspunkt des sicheren Bootvorgangs
    • AES-Engine: führt beim Lesen und Schreiben von Dateien Verschlüsselung und Entschlüsselung in Echtzeit aus; Schlüsselinformationen werden über die Secure Enclave übermittelt
    • Secure Enclave: zuständig für die Erzeugung und Speicherung kryptografischer Schlüssel sowie den Schutz biometrischer Authentifizierungsdaten
  • Secure Boot beschränkt den Start auf Betriebssysteme, denen Apple vertraut
    • Das Boot ROM wird bei der Herstellung des SoC in die Hardware integriert und kann nicht verändert werden
    • Beim Mac dient der T2-Chip als Vertrauensbasis für sicheres Booten

Sicherheitsarchitektur des Apple-SoC

  • Apple entwirft SoCs mit einer gemeinsamen Architektur für die gesamte Produktpalette
    • iPhone, iPad, Mac, Apple Watch, Apple TV, Vision Pro und HomePod nutzen dieselbe Sicherheitsgrundlage
  • Sicherheitsfunktionen je nach SoC-Generation
    • Kernel Integrity Protection, Pointer Authentication Codes, Page Protection Layer, Secure Page Table Monitor und weitere
    • Bei SoCs ab A15 sowie ab M2 ersetzt SPTM die PPL
  • Die Data-Protection-Funktion wurde bei SoCs ab A12 sowie ab M1 verstärkt
    • Sealed Key Protection (SKP) sowie Datenschutz auch im Wiederherstellungsmodus und Diagnosemodus bleiben erhalten

Secure Enclave

  • Die Secure Enclave ist ein unabhängiges Sicherheits-Subsystem, das in Apple-SoCs integriert ist
    • Sie ist vom Hauptprozessor getrennt, sodass sensible Daten auch bei einem kompromittierten Kernel geschützt bleiben
    • Sie verfügt über Boot ROM, AES-Engine und eine geschützte Speicherarchitektur
  • Sie besitzt keinen eigenen Speicher, kann Daten jedoch verschlüsselt sicher auf externem Speicher ablegen
  • Biometrische Daten für Optic ID, Face ID und Touch ID werden ausschließlich in der Secure Enclave verarbeitet
    • Während der Authentifizierung werden persönliche biometrische Informationen weder dem System noch Apps offengelegt
    • Das ermöglicht schnelle Authentifizierung bei gleichzeitig beibehaltener Verwendung komplexer Passwörter

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2026-02-02
Hacker-News-Kommentare

  • Es ist erstaunlich, dass der Teil darüber, C speichersicher gemacht zu haben, nur in einem einzigen Absatz erwähnt wird.
    Seit iOS 14 hat Apple offenbar die C-Compiler-Toolchain angepasst, die beim Bauen des iBoot-Bootloaders verwendet wird, um die Sicherheit zu erhöhen.
    An Pointer werden dabei Grenzinformationen und Typinformationen angehängt, um Schwachstellen wie Buffer Overflows, Heap-Exploits, Type Confusion und Use-after-free zu verhindern.

    • Was Apple gebaut hat, ist keine völlig neue Sprache, sondern ein C-Dialekt mit zusätzlicher bounds safety.
      Relevante Dokumentation: Clang Bounds Safety Overview
    • Das ist offenbar ein schon länger existierendes Projekt namens Firebloom.
      Es scheint aus einer ähnlichen Linie wie Fil-C zu stammen.
      Weiterer Link: iBoot Firebloom
    • So wie ich es verstehe, nutzt Apple die fbounds-Checks von clang sehr konsequent und fügt Prüfungen auf Funktionsebene ein.
      Auch die Memory Tagging-Funktion neuer Prozessoren hilft dabei, Overflow-Angriffe zu verhindern.
    • Am Ende ist es aber trotzdem nur eine abgewandelte Version von C, und eines der Ziele der Swift Embedded-Roadmap ist es, diesen Dialekt zu ersetzen.

  • Beeindruckend ist, wie ernst Apple es mit Privatsphäre und Sicherheit meint.
    Google oder Meta können wegen ihres werbefinanzierten Geschäftsmodells Privatsphäre nur schwer glaubhaft versprechen, während Apple als hardwarezentriertes Unternehmen diese Strategie offenbar bewusst wählen kann.

    • Wenn man sich diesen Artikel zur iMessage-Verschlüsselung ansieht,
      setzt Google standardmäßig sowohl für Nachrichten-Backups als auch für die Übertragung E2E-Verschlüsselung ein,
      während Apple nur die Nachrichtenübertragung E2EE absichert und Backups standardmäßig so aufgebaut sind, dass Apple darauf zugreifen kann.
      Mit ADP (Advanced Data Protection) lässt sich das verhindern, aber weil die meisten Nutzer es nicht aktivieren, bedeutet das praktisch, dass Apple auf alle Nachrichten zugreifen kann.
    • Aus Verbrauchersicht frage ich mich, worin genau der reale Unterschied zwischen iPhone, Pixel und Samsung besteht.
      Beide Unternehmen speichern die Verschlüsselungsschlüssel, und wenn ADP nicht aktiviert ist, hat auch Apple Zugriff.
      Pixel bietet Funktionen wie 2G-Sperre oder IMEI-Tracking-Benachrichtigungen, mit denen sich Sicherheit feiner steuern lässt.
    • Sehr empfehlenswert ist auch dieses Video zur iCloud-Sicherheitsarchitektur, präsentiert vom Leiter von Apples Security-Team.
      Dort werden reale Schutzmechanismen wie HSMs und Rate Limiting ausführlich erklärt.
    • Das Problem bleibt aber letztlich, dass Apple kontrolliert, welche Apps und Funktionen auf dem Gerät erlaubt sind.
      Das hat auch aus bürgerrechtlicher Sicht zunehmend größere Auswirkungen.
    • Außerdem betreibt Apple inzwischen selbst ein Werbegeschäft.

  • Schade ist, dass Apple Nutzer daran hindert, Software ihrer Wahl frei zu installieren.
    Als Begründung wird Sicherheit genannt, tatsächlich ist es aber eine Struktur, die die Kontrolle der Nutzer einschränkt.
    Am Ende bleibt die Wahl zwischen (A) einem trackingbasierten OS und (B) einem OS, das schon die Installation selbst monetarisiert — beides ist nicht wirklich zufriedenstellend.

    • Auf macOS lassen sich weiterhin externe Apps installieren, und es gibt trotzdem kein großes Malware-Problem.
      Auch im App Store gibt es viele Betrugs-Apps, deshalb ist „Store = sicher, extern = gefährlich“ eine falsche Dichotomie.
      Der eigentliche Grund, warum Apple das verhindert, ist, die 30-%-Gebührenstruktur aufrechtzuerhalten.
      Die Bemühungen zur Verbesserung der Sicherheit erkenne ich trotzdem an.
    • Schade, dass eine Diskussion über Sicherheit wieder in eine App-Store-Debatte abdriftet.

  • Unter https://privacy.apple.com kann man eine Kopie der Daten anfordern, die Apple über einen gespeichert hat.
    Auch iCloud-Fotos lassen sich dort in festgelegten Größenpaketen herunterladen, was deutlich effizienter ist, als sie über die Weboberfläche langsam in 1000er-Blöcken zu laden.

  • Da Apples gesamte Software proprietär ist, gibt es kaum eine Möglichkeit, die Sicherheitsbehauptungen zu überprüfen.
    Auch die Verschlüsselungsschlüssel liegen nicht beim Nutzer, also gibt es faktisch keine echte Datenkontrolle.
    Als Beispiel für gut umgesetzte Sicherheit wird GrapheneOS genannt.

    • Allerdings kann auch bei GrapheneOS der Nutzer die Verschlüsselungsschlüssel nicht direkt selbst handhaben.
      In offiziellen Builds ist ein Datenexport unmöglich, wenn die App ihn nicht erlaubt.
      Auch die Backup-Funktionen sind eingeschränkter als bei Apple.
      Außerdem erlauben die Entwickler Apps, den Vertrauensstatus des Geräts zu prüfen, was in eine Richtung geht, die die Freiheit der Nutzer einschränkt.
      Relevante Dokumentation: Attestation Compatibility Guide
    • Oft wird übersehen, dass das „AOSP-Sicherheitsmodell“ Apps vor dem Nutzer schützt.
    • Es bleibt auch die Frage: „Wie kann man solche Sicherheitsbehauptungen überhaupt verifizieren?“

  • Trotzdem ist es beruhigend, dass es noch Tech-Unternehmen gibt, die persönliche Sicherheit und opsec ernst nehmen.

  • Die Webversion von Apples Sicherheitsleitfaden ist hier zu finden.

    • Der Stand des Dokuments ist Dezember 2024.

  • Interessant ist die Formulierung, Apple behaupte, der Mac habe den stärksten DMA-Schutz unter den PCs.
    Schon witzig, dass Apple den Mac inzwischen selbst als PC bezeichnet.

  • Ich frage mich, wie stark die neu eingeführte MIE(EMTE)-Funktion der A19- und M5-Prozessoren tatsächlich genutzt wird.
    Ob sie schon jetzt spürbar wirkt oder erst in einigen Jahren, ist schwer zu sagen.

    • Ich habe dieses Video gesehen, und dort heißt es,
      Apples MTE-Implementierung sei weniger breit eingesetzt als bei GrapheneOS oder Android.
      Der Grund seien die hohen Performance-Einbußen.
      Wünschenswert wäre, wenn Lockdown Mode MTE global erzwingen würde.
    • In iOS 26 ist MIE bereits im Kernel-Allocator, in den meisten Systemprozessen und in libpas (WebKit allocator) aktiviert.

  • Ich frage mich, wie viel Performance-Overhead diese Sicherheitsfunktionen verursachen.
    Ich würde gern Benchmarks mit aktivierten und deaktivierten Sicherheitsfunktionen sehen.

    • Allerdings sind viele dieser Funktionen auf Hardware-Ebene implementiert, sodass ein direkter Vergleich schwierig sein soll.
    • Typische Beispiele mit Auswirkungen auf die Performance sind Speicherinitialisierung, Spectre-/Meltdown-Patches, App-Signaturprüfung und vollständige Festplattenverschlüsselung.
      Vor allem das frühere FileVault war wegen seines disk-image-basierten Ansatzes deutlich langsamer.