Datenschutz: Neue Ende-zu-Ende-Verschlüsselung für Safari-Lesezeichen

Privatsphäre ausgeweitet

Apple baut Datenschutz und Privatsphäre in den eigenen Diensten weiter aus und bietet nun für noch mehr Nutzerdaten eine verbesserte Verschlüsselung an. In diesem Fall geht es um eine Ende-zu-Ende-Verschlüsselung für Lesezeichen im Apple-Browser Safari, die in der iCloud gesichert sind und auf verschiedene Geräte synchronisiert werden.

Schon in der Vergangenheit hatte Apple bereits den Safari-Verlauf und -Tabs mit einer Ende-zu-Ende-Verschlüsselung versehen – nun kommen auch die Lesezeichen hinzu. Für Nutzer und Nutzerinnen bedeutet dies, dass niemand, nicht einmal Apple selbst, auf die Lesezeichen des Browsers zugreifen kann.


Viele andere Apple-Dienste noch ohne Ende-zu-Ende-Verschlüsselung

Entdeckt wurde die Neuerung bei Reddit: Dort wurde darauf aufmerksam gemacht, dass es in Apples „iCloud Security Overview“ ein Update gegeben hat und angegeben wurde, dass nun auch Safari-Lesezeichen Ende-zu-Ende-verschlüsselt seien.

Damit ist aber noch lange nicht alles auf diesem Weg abgesichert: iCloud-Backups, ebenso wie Fotos, Erinnerungen, Notizen und mehr verfügen lediglich über eine 128 Bit-AES-Verschlüsselung. In den letzten Monaten ist Apple vor allem aufgrund der fehlenden Ende-zu-Ende-Verschlüsselung für iCloud Fotos und Backups in die Kritik geraten. Ein solche Änderung steht bislang noch immer aus.

Anzeige

Kommentare 8 Antworten

  1. @mel: „…verfügen lediglich über eine 128 Bit-AES-Verschlüsselung.“
    AES128 ist meines Wissens nach wie vor sehr schwierig zu knacken. Gab es da kürzlich einen Durchbruch, der das „lediglich“ rechtfertigt?

  2. @zeroG: Dein Nickname bezieht sich hoffentlich nicht auf dein Verstand. 😉

    Nein, das war ein fieser Scherz, also bitte nicht ernst nehmen.

    @mel hat vollkommen Recht. Es geht nicht um Verschlüsselungsstärke, wobei wir auch nicht wissen, ob dies weitestgehend fehlerlos implementiert wurde (ist ja closed source). Aber davon gehe ich aus, weil dies sonst den Ruf stark beschädigen würde und macOS (X) auf FreeBSD Unix basiert (nein, es basiert nicht auf NeXtStep OS, sondern ist eine Weiterentwicklung davon)).

    „lediglich“ ist vollkommen richtig, da es keine Ende-zu-Ende-Verschlüsselung ist. Dies bedeutet, die Verschlüsselung ist nicht vom Endgerät mit einer Apple ID zum eigenen oder anderen Endgerät mit gleicher Apple ID (wozu man 2FA aktivieren muss – steht auch in Apple Dokument about security) durchgängig ohne Unterbrechung verschlüsselt. D.h., Apple besitzt den privaten Schlüssel. Durch NSLs können Dreibuchstabenbehörden von Apple fordern, dass diesen die mit nur 128 Bit AES Verschlüsselung versehenen Daten zum Teil oder alle Daten unverschlüsselt an sie übergeben werden. Bei Ende-zu-Ende-Verschlüsselung, die evtl. auch die 128 Bit Verschlüsselung als Verschlüsselungsmethode verwendet, könnte Apple ohne den zwingend notwendigen privaten Schlüssel die Daten zumindest nicht in kurzer Zeit entschlüsseln und dann wären die NSLs quasi sinnlos.

    Wenn du meinen Kommentar nicht verstehst, dann heißt es nicht, dass meiner falsch ist, sondern du noch sehr viel Nachholbedarf an technischem Wissen hast.

    Stichwörter zum Nachholen: NSL, Ende-zu-Ende-Verschlüsselung, Verschlüsselungsmethoden im Public-Private-Key-Verfahren (mit letztem Stichwort anfangen, damit man die Erläuterungen zum zweiten Stichwort nachvollziehen kann – ist zwar eigentlich nicht schwer, aber dein Kommentar weist auf eine riesige Wissenslücke hin)

    1. @z: Danke Dir für Deine ausführliche Erklärung. Wenn das „lediglich“ sich auf das fehlende e2e bezieht, ist es natürlich richtig. Der Satz für sich alleine genommen ist unglücklich formuliert, da AES128 nicht schwach ist, aber der Kontext mit e2e ist schon vorhanden (Überschrift etc.), da hast Du Recht. Da hätte ich aufmerksamer lesen sollen.
      Ansonsten hast Du Dich „leicht“ verschätzt, alle von Dir genannten Begriffe (und noch viel mehr) sind mein tägliches Brot. Menschen fragen nicht nur nach, wenn sie keine Ahnung haben, sondern auch, wenn sie über „unglückliche“ Formulierungen stolpern, gerade weil sie sich „ein bisschen“ auskennen 😉
      Wenn Du nach meinem Namen hier suchst, wirst Du sehen, dass ich im Laufe der Jahre zu solchen Dingen wie e2e, WPA3, PKI, NSL und Papageien* ab und zu was geschrieben habe.
      Macht aber nichts, denn gemäß den Herren Dunning und Kruger neigt Mensch dazu, seine eigene Kompetenz zu über- und die der anderen zu unterschätzen, insofern sei Dir verziehen.
      *Was haben eigentlich „nationale Sicherheitsbriefe“ mit buntem Federvieh zu tun? 😉

      1. @zeroG: Ja, ich bin hier fast nie und daher kenne ich die anderen Beiträge von dir nicht. Allerdings habe ich mit einem fiesen Scherz auf deinen Nicknamen angespielt und davor gebeten dies nicht als ernst werten, weshalb indirekt bekannt worden sein sollte, dass ich deine älteren Beiträge sicherlich nicht kenne. Aber diese Denkleistung kann ich wohl nicht bei jedem erwarten (<= Retourkutsche zu deiner misslungenen Retourkutsche 😉 ). Die daraus folgende fehlerhafte Schlussfolgerung dies mit der Aussage der Herren Dunning und Kruger bzgl. Selbstüberschätzung gleichzusetzen, zeigt nur den krampfhaften Versuch mich in einem schlechten Licht zu zeigen. Aber dies verzeihe ich dir.

        Dass du mich lächerlich machen willst bzgl. NSLs, sagt eigentlich nicht gutes über dich aus, aber ich hoffe, dein ";)" war richtig gesetzt. 😉

        PS: Was soll angeblich dein täglich Brot sein?

        1. @z: Sorry buddy, du laberst zu viel. Hast du inhaltlich auch etwas zum eigentlichen Thema beizutragen oder beschränkst du dich auf schlechte name puns und völlig falsche Einschätzungen? Dass man irgendwo neu ist und sich dort nicht auskennt, sich aber gleich aufmacht anderen ans Bein zu pinkeln, ist nämlich keine Auszeichnung. 😉
          Im übrigen war das mit den NSL und dem Vogel zwar witzig gemeint, dennoch ist es wahr und wenn du wirklich die Ahnung hättest, die du vorgibst, hättest du das gewusst:
          en.wikipedia.org/wiki/Warrant_canary
          Hast du wohl unfreiwillig bestätigt, dass die Herren D und K doch Recht haben? 😉
          Mir egal, melde dich, wenn du noch Fragen zu Security hast, ansonsten überlasse ich dir für weiteres Gelaber gerne das letzte Wort.

          1. @zeroG: Typisch für einen Infokrieger, den anderen einfach beleidigen und Dämliches zu unterstellen, wenn man nicht mehr weiter weiß. Auch noch zu unterstellen, dass NSLs nur in Bezug auf bunte Vögel bekannt sind, zeigt nur, dass dir vorher NSLs nicht geläufig waren, eine Suche in der Maschine dies als häufiges Egebnis ergibt und du nun unterstellst, es sei angeblich fast nur dafür bekannt. Das ist auch typisch für die Infokrieger, zu etwas, was man nicht wusste, abzulenken. Daraus eine Bestätigung abzuleiten, weist auf ein nicht gerade hohes Intellekt. 😉

          2. @zeroG:

            Was ich nicht vergessen wollte:

            Du hast es wie diese dummen Infokrieger herumgedreht:

            Ich habe nur einen etwas fiesen Scherz gemacht, was ich aber sagte. Danach habe ich nicht (um bei deinen Worten zu bleiben) „angepisst“! Sondern ich habe die Autorin Mel verteidigt und nur deinen unsinnigen Protest aufgezeigt, der von einem fanatischen Apple-Fanboy (keinem gesunden Apple-Fanboy) sein könnte. So viel zu deinem dämlichen Herumdrehen mich plötzlich als „Anpisser“ darzustellen!

            Und deine Erwähnung vom bunten Vogel, zeigt nicht, dass du irgendetwas mit Sicherheit im virtuellen Raum verstanden hast. Es ist lediglich ein evtl. heiterer, aber nutzloser Nebenaspekt, der hiermit fast nichts zu tun hat. Dies war nur eine minimale Absicherung, die aber fast nutzlos ist. Denn der echte bunte Vogel half zu vermeiden beim Arbeiten zu sterben. Beim virtuellen Vogel ist die Warnung nutzlos, wenn man bereits zu kompromittierende Informationen hochgeladen hatte.

            (Das mit dem Vogel hatte ich irgendwann gelesen, aber wieder vergessen, weil unsinnig, wenn ein Sicherheitsbruch nie geschehen darf.)

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Copyright © 2021 appgefahren.de