[10.9 Mavericks] Ist der iCloud-Schlüsselbund sicher?

[Mathek]

@FrankR
Du hast in einigen Punkten Recht. Ich werde mich bemühen meinen Schreibstil zu verbessern.

 

[FrankR]

@FrankR
Du hast in einigen Punkten Recht. Ich werde mich bemühen meinen Schreibstil zu verbessern.

Kein Problem - lies Dir doch auch mal die Artikel vom Bieger oben durch und überlege dann, ob Du ein Dementi verfasst .

 

[MacAlzenau]

Wenn die Argumentation stimmt - vorausgesetzt, daß ich sie richtig verstehe - kann doch jeder Betreiber eines Shops, eines Forums usw. das Login-Paßwort "kurz" im Klartext mitlesen.
Erstaunlich, daß das bisher noch niemand öffentlich gemacht hat.

Was jetzt nicht bedeutet, daß ich Apple nicht zutrauen würde, mitzulesen, nur bezweifle ich, daß es auf diesem Weg erfolgt. Wenn, dann wäre es doch viel bequemer für die Firma, ganz ohne Nutzung des Paßwortes zugreifen zu können. Was kaum ein Problem sein dürfte, wenn man die Mechanismen nicht veröffentlicht.

 

[Bananenbieger]

Wenn die Argumentation stimmt - vorausgesetzt, daß ich sie richtig verstehe - kann doch jeder Betreiber eines Shops, eines Forums usw. das Login-Paßwort "kurz" im Klartext mitlesen.

Ja, das kann er, aber der Betreiber eines Shops, Forums etc. braucht das Passwort eh nicht, da er ja bereits uneingeschränkten Zugriff auf das System hat.

Der Endnutzer sollte aber genau aus diesem Grund pro Website/Webservice ein anderes Passwort verwenden. Daran halten sich leider nur die wenigsten Nutzer.

 

[Mathek]

Was nützt es mir wenn die Geräte ein Passwort generieren wenn meine AppleID weiterhin das Masterpasswort ist?

Ein Gedankenexperiment: Mac2 kann auf die Keys von Mac1 allein durch die Eingabe des AppleID-Passworts zugreifen/entschlüsseln.

Ich behaupte nicht, dass jeder an eueren Schlüsselbund kommen kann. Es geht mir nur darum, dass Apple selbst alle nötigen Passwörter/hashes (und wie auch immer man sie nen mag) besitzt.
Und ein Statement von Apple, das besagt, dass sie keinen Zugriff auf die Daten haben. Bedeutet in Bürokraten Englisch, dass sie es in der Praxis nicht machen.

Bei führenden Holstern wie z.B. Lacie gibt es auch Cloud-Lösungen, aber dort gibt es keine Kompromisse bei der Sicherheit. Alle Daten werden lokal auf ein Verschlüsseltes Medium gespeichert und erst nach der Verschlüsselung an die Server geschickt. Lacie Kennt das Passwort für die Verschlüsselung nicht, da es nicht das Account-Passwort ist. Das ist eine Sichere Lösung.

 

[Bananenbieger]

Die AppleID ist nicht das Masterpasswort. Und die auf die Keys hat Apple keinen Zugriff, weil sie erst gar nicht in den Machtbereich von Apple kommen.

Also uses elliptic curve asymmetric cryptography and key wrapping.

Was das heißt: http://de.wikipedia.org/wiki/Diffie-Hellman-Schlüsselaustausch

 

[echo.park]

Wenn die Argumentation stimmt - vorausgesetzt, daß ich sie richtig verstehe - kann doch jeder Betreiber eines Shops, eines Forums usw. das Login-Paßwort "kurz" im Klartext mitlesen. Erstaunlich, daß das bisher noch niemand öffentlich gemacht hat.

Um zu klären, ob das wirklich so ist, müsste sich hier mal ein Experte zu dem Thema äußern. Ich glaube ja nicht so dran.

 

[Mathek]

Die AppleID ist nicht das Masterpasswort. Und die auf die Keys hat Apple keinen Zugriff, weil sie erst gar nicht in den Machtbereich von Apple kommen.


Was das heißt: http://de.wikipedia.org/wiki/Diffie-Hellman-Schlüsselaustausch

Und weil Apple der Man-In-The_Middle ist und das AppleID-Passwort kennt, welches zur Authentifizierung dient, könnte es sich den beiden Geräten gegenüber als vertrauenswürdig authentifizieren?

//EDIT:
Demzufolge wäre aber schonmal geklärt, dass die AppleID nicht das Masterpasswort des Schlüsselbundes ist. Danke für die Info. Wir kommen der Wahrheit näher

 

[Bananenbieger]

Ja, genau. Für MitM ist diese Lösung natürlich anfällig. Aber genauso könnte Apple beispielsweise eine versteckte Funktion in OSX implementieren, die ~/.ssh/* irgendwo auf einen geheimen Server läd.

 

[Mathek]

So wenig Vertrauen würde ich Apple nicht zusprechen wollen.
Die Lösung des Problems wäre, also ein separates Passwort für den iCloud-Keychain, das der User einmal beim Einrichten eingeben würde. Stattdessen hat man auf kosten der Sicherheit zu Gunsten der Bequemlichkeit ein Verfahren dazwischen geklemmt.

 

[FelixMacintosh]

Ja, genau. Für MitM ist diese Lösung natürlich anfällig. Aber genauso könnte Apple beispielsweise eine versteckte Funktion in OSX implementieren, die ~/.ssh/* irgendwo auf einen geheimen Server läd.

Was denke ich sowieso wahrscheinlicher wäre. Liest man die aktuelle Tagespresse könnte sich einem der Gedanke aufdrängen, dass mittlerweile alles was auf PCs an Daten liegt mitgelesen werden kann. In Echtzeit (Juchhe)
Ich betone das kann ...

 

[Bananenbieger]

Die Lösung des Problems wäre, also ein separates Passwort für den iCloud-Keychain, das der User einmal beim Einrichten eingeben würde. Stattdessen hat man auf kosten der Sicherheit zu Gunsten der Bequemlichkeit ein Verfahren dazwischen geklemmt.

Ich weiß nicht, wo Du überhaupt ein Problem siehst. Kannst Du bitte mal genau darstellen, was Du meinst?

 

[gKar]

Die Lösung des Problems wäre, also ein separates Passwort für den iCloud-Keychain, das der User einmal beim Einrichten eingeben würde.

Ähm, was würde das für einen Vorteil bringen?
Im Moment stelle ich mir das so vor (nur eine Mutmaßung), dass der Schlüssel für die User-Keychain (ganz unabhängig davon, ob nur lokal benutzt oder über iCloud synchronisiert) aus dem lokalen OS-X-Login (Usernamen und Passwort) gebildet oder zumindest mit diesem verschlüsselt wird – ähnlich wie beim Dateisystemschlüssel für FileVault 2. Warum sollte ein getrenntes, separates Passwort für die Keychain so viel sicherer sein?

Die eigentliche Unsicherheit, die ich sehe, ist, dass wir alle eher raten. Bei 1Password z.B. ist das Keychain-Format offengelegt. Da kann man sich eher ein Bild machen. Ebenfalls ist mir wohler bei dem Gedanken, dass die Cloud, in der ich die 1Password-Keychain verschlüsselt ablege, und die zugehörige Software (1Password) nicht aus derselben Hand stammen. Ich bin mir nicht sicher, wie sehr ich der iCloud-Keychain trauen soll, und nutze sie schon deshalb und angesichts der gut funktionierenden, bewährten und flexibleren Alternative nicht. Aber dieses reißerische „Ich habe Schnee gesehen und daraus folgt, dass die Nacht dunkel ist und Apple ein Betrüger ist, ihr müsst dies unbedingt lesen!“-Niveau halte ich für extrem unpassend.

 

[Mathek]

Ähm, was würde das für einen Vorteil bringen?
Im Moment stelle ich mir das so vor (nur eine Mutmaßung), dass der Schlüssel für die User-Keychain (ganz unabhängig davon, ob nur lokal benutzt oder über iCloud synchronisiert) aus dem lokalen OS-X-Login (Usernamen und Passwort) gebildet oder zumindest mit diesem verschlüsselt wird – ähnlich wie beim Dateisystemschlüssel für FileVault 2. Warum sollte ein getrenntes, separates Passwort für die Keychain so viel sicherer sein?

In diesem Thread haben wir schonmal herausgefunden, dass der iCloud-Keychain nicht mit der AppleID oder dem OSX-Login verschlüsselt wird, sondern durch einen zufällig (von den Geräten) erzeugten Code. iPhones haben z.B. gar keinen OSX Login .

@Bananenbieger
Mein Problem ist, dass durch die Verwendung von "elliptic curve asymmetric cryptography and key wrapping" eine Autehtifizierung mit dem AppleID Kennwort ausreicht um einen Mitm-Angriff durchzuführen. Und da die Verbindungen über die Apple Server laufen, kann Apple selbst diese Schwachstelle ausnutzen indem es sich mit dem AppleID-Kennwort authentifiziert.
Es geht mir nicht darum das Apple das tut. Aber es wäre praktisch möglich.
Und allein diese Tatsache, macht den Dienst für mich persönlich unbrauchbar.

 

[echo.park]

Wer hier hat einen Clean Install gemacht, und wer wurde dabei gefragt, ob er den Schlüsselbund verwenden möchte? Bei mir kam keine Abfrage.

 

[gKar]

In diesem Thread haben wir schonmal herausgefunden, dass der iCloud-Keychain nicht mit der AppleID oder dem OSX-Login verschlüsselt wird, sondern durch einen zufällig (von den Geräten) erzeugten Code.

Haben wir das? Ich bin alles andere als ein Verschlüsselungsspezialist, aber ich sehe doch einen gravierenden Unterschied zwischen der Erzeugung des symmetrischen Schlüssels, der dauerhaft zur Ver- und Entschlüsselung der Keychain genutzt wird (und der irgendwie von den Logindaten des Users abhängen muss, wenn tatsächlich dieser – und nur dieser – User ohne extra Passworteingabe an die Daten kommen soll) sowie einem Schlüsseltausch-Verfahren, mit dem entweder ein symmetrischer Schlüssel „verpackt“(wrapped) und über eine Leitung übertragen wird oder (à la Deffie-Hellman) sich zwei Parteien parallel denselben symmetrischen Schlüssel (typischerweise einen temporären Situngsschlüssel, mit dem anschließend gesichert kommuniziert werden soll) selbst erzeugen, ohne dass er übertragen werden muss.

Und falls die Keychaindaten – wie es sich gehört – lokal auf dem Rechner verschlüsselt werden, der Schlüssel den Rechner niemals verlässt und nur die verschlüsselten Daten übers Internet übertragen und entfernt gespeichert werden, was soll dann ein Man in the Middle ausrichten? Und warum soll es für Apple einen großen Vorteil bringen, sich selbst in die Kommunikation zwischen sich selbst und einem User einzuklinken?

Sicher werden bei jedem Loginvorgang mit der Apple-ID sowohl die ID als auch das Passwort an Apple gesendet. Der Kommunikationskanal sollte stets TLS-geschützt sein, aber der empfangende Server von Apple erhält beide Angaben im Klartext. Normalerweise sollte daraus dann ein Hash generiert und nur der gespeichert werden, aber kein User kann sich darauf verlassen, dass Apple nicht sein Apple-ID-Passwort im Klartext gespeichert haben könnte. Somit könnte Apple jederzeit auch ohne MITM-Angriff an die Apple-ID-Daten seiner Kunden kommen und an alle deren Daten, die nur damit geschützt in der iCloud liegen. Wenn nun die iCloud-Keychain nur mit der Apple-ID gesichert wäre, deren Kenntnis (samt Passwort) also zum Entschlüsseln reichte, wäre tatsächlich der Inhalt für Apple zugänglich. Käme das heraus, wäre Apple aber als sowas von unvertrauenswürdig enttarnt, dass ich mir kaum vorstellen kann, dass sie die iCloud-Keychain derart stümperhaft designed haben. Es sollte vielmehr so sein, dass man eben nicht nur die Apple-ID und deren Passwort zur Entschlüsselung der Keychain benötigt, sondern einen Schlüssel, der niemals den Rechner des Kunden verlässt. Das Problem dann ist aber, dass ja mehrere Rechner des Kunden auf die Keychain zugreifen sollen, der Schlüssel also irgendwie von einem zum anderen Rechner transportiert werden muss. Eine Möglichkeit dazu wäre ein spezielles Masterpasswort (siehe z.B. 1Password). Der „Transport“ des Schlüssels von einem zum anderen Rechner erfolgte dann nur über das Gedächtnis des Users und dessen Eingabe des Masterpassworts am anderen Rechner. Das ist offensichtlich bei der iCloud-Keychain anders, und ich verstehe noch nicht ganz, wie es abläuft.

iPhones haben z.B. gar keinen OSX Login .

Das wiederum ist wahr. Der Schlüssel kann also nicht direkt aus dem OS-X-Login gewonnen werden (dann wäre die Keychain ja auch gar nicht an anderen Macs nutzbar, wenn man dort einen anderen Login benutzte), aber er kann dennoch lokal auf dem Rechner gespeichert und dort mit dem User-Login und -Passwort seinerseits gesichert abgelegt sein, so dass der User sich nur am System einloggen muss, um Zugriff auf seine Keychain zu haben (was ja der Fall ist). Der Knackpunkt bleibt also, wie der auf einem Rechner erzeugte Schlüssel auf die anderen Geräte gelangt, ohne dass er in Apples Besitz gelangt.

 

[ndadi84]

Hab das ganze mal etwas überflogen, ist natürlich schon seltsam weshalb es dann ein Master Kennwort benötigt...!! Muss mich doch mal bei Gelegenheit genauer damit befassen! Allerdings... geht mal in eure safari Einstellungen, dort könnt ihr wie am Mac Schlüsselbund auch eure Passwörter gut einsehen! Einfach entsprechend freigeben, war über manche Infos überrascht, Foren die ich vor einem Jahr mal besucht habe oder ähnliches werden noch immer angezeigt!

 

[ImperatoR]

Mod Info

Ich habe den reißerischen Titel entschärft und angepasst.

 

[Bananenbieger]

Mein Problem ist, dass durch die Verwendung von "elliptic curve asymmetric cryptography and key wrapping" eine Autehtifizierung mit dem AppleID Kennwort ausreicht um einen Mitm-Angriff durchzuführen. Und da die Verbindungen über die Apple Server laufen, kann Apple selbst diese Schwachstelle ausnutzen indem es sich mit dem AppleID-Kennwort authentifiziert.

Nein und nein. Für Mitm bräuchte Apple sich nicht mit Kennwörtern authentifizieren. Außerdem merkt man wie bei iMessage auch, wenn neue Geräte in den Circle of Trust aufgenommen werden.
Werden Gerätesignaturen verwendet, ist sogar ein Mitm-Angriff durch Dritte im Allgemeinen und seitens Apple im Speziellen praktisch ausgeschlossen.

Es geht mir nicht darum das Apple das tut. Aber es wäre praktisch möglich.

Praktisch ist nach gegenwärtigen Wissensstand nichts möglich.

[...]der dauerhaft zur Ver- und Entschlüsselung der Keychain genutzt wird (und der irgendwie von den Logindaten des Users abhängen muss, wenn tatsächlich dieser – und nur dieser – User ohne extra Passworteingabe an die Daten kommen soll) [...]

Der Schlüssel hängt nicht von den Logindaten des Users ab, sondern wird nur durch diese geschützt. Daher kann man auch z.B. die Login-Daten ändern, ohne dass die gesamten Daten neu verschlüsselt werden müssen.

 

[gKar]

Der Schlüssel hängt nicht von den Logindaten des Users ab, sondern wird nur durch diese geschützt. Daher kann man auch z.B. die Login-Daten ändern, ohne dass die gesamten Daten neu verschlüsselt werden müssen.

Yup, genau das meinte ich (vgl. auch Ende meines letzten Posts). Das Wort „Abhängigkeit“ war vielleicht suboptimal gewählt; ich meinte damit ganz allgemein eine Relation, die eben auch eine „ist-geschützt-mit“-Relation sein kann und sich hier darin äußert, dass der User nur seine Logindaten kennen muss, um an den Schlüsselbund zu gelangen.