Das Urmel 10 Geschrieben 31. August 2005 Melden Teilen Geschrieben 31. August 2005 Korrekt. Das war einer der Kritikpunkte an EFS bei W2k, was Microsoft eben bei XP behoben hat. Das ist auch das, was manche in ihrer Ahnungslosigkeit meinen, nachdem sie es irgendwo manl gelesen haben, wenn sie immer pauschal behaupten, EFS bei Windows sei generell unsicher, blabla usw. Ich meine jetzt nicht dich, sondern ich habe solche Pauschal-Sätze hier im Board in Diskussionen schon gelesen. Aber ich sage mir, Herr vergib ihnen, denn sie wissen nicht .......... :D grizzly999 Das ist doch mal ein Wort :) Vorweg: Rekonstruieren ist derzeit nicht möglich - aber es gibt andere Wege. Hat man die HD in der Hand, ist auch bei XP EFS nicht mehr die ultimative Bremse. EFS ist so sicher wie jedes andere Verfahren, Zugriff auf die Hardware selbst und es ist max. eine Frage der Zeit. Zitieren Link zu diesem Kommentar
grizzly999 11 Geschrieben 31. August 2005 Melden Teilen Geschrieben 31. August 2005 o.k es geht um 2000. Die Unterschiede würden mich auch einmal interessieren. Die Unterschiede bei EFS zwischen XP und W2k sind klein aber fein. Die Verschlüsselung ist bei 2000 eine DESX-Verschlüsselung mit 56 Bit, ab SP2 mit 128 Bit. Bei XP ist es DESX mit 56 Bit, ab SP1 AES mit 256 Bit, und wenn die Richtlinie für FIPS (140-1) konforme Verschlüsselung aktiviert sein sollte, 3DES mit 168 Bit. Bei W2k wird der private Schlüssel mit einem Masterkey verschlüsselt und der Masterkey in der Registry (HKCU) abgelegt. Bei XP wird der private Schlüssel mit einem Masterkey verschlüsselt und der Masterkey dann mit dem Kennwort des Benutzers verschlüsselt und in der Registry (HKCU) abgelegt (irgendwo stand mal "in der Registry verstreut"). Wenn das kennwort von aussen zurückgesetzt wird, kann der Masterkey nicht mehr entschlüsselt werden und damit der private Schlüssel auch nicht. Wenn der Benutzer selber sein Kennwort ändert, wird beim Ändern automatisch mit dem alten Kennwort der Masterkey entschlüsselt und mit dem neuen Kennwort erneut verschlüsselt und wieder in der Registry verstreut. Deshalb auch das übergroße Warnfenster bei alleinstehenden XPs, wenn ein Admin ein Kennwort zurücksetzt. grizzly999 Zitieren Link zu diesem Kommentar
Candy 27 Geschrieben 31. August 2005 Melden Teilen Geschrieben 31. August 2005 Hi, thx grizzly, das macht Sinn! Also kann ein User(nicht Admin bzw. Wiederherstellungsagent) unter XP doch sein eigenes PW ändern, ohne vorher die Daten entschlüsseln zu müssen. Das wusste ich auch noch nicht. Mensch, ich werde immer schlauer :D THX Zitieren Link zu diesem Kommentar
Candy 27 Geschrieben 31. August 2005 Melden Teilen Geschrieben 31. August 2005 Kleiner Nachtrag/ Frage... Wenn der User sein PW vergessen sollte, muss der Admin aber zuerst mit dem Wiederherstellungsagenten und seinem Login die Daten entschlüsseln und dann erst das PW zurück setzen? Zitieren Link zu diesem Kommentar
grizzly999 11 Geschrieben 31. August 2005 Melden Teilen Geschrieben 31. August 2005 Kleiner Nachtrag/ Frage... Wenn der User sein PW vergessen sollte, muss der Admin aber zuerst mit dem Wiederherstellungsagenten und seinem Login die Daten entschlüsseln und dann erst das PW zurück setzen? Ob er es vorher oder nachher macht, würde keine Rolle spielen, er müsste es halt nur machen ;) grizzly999 Zitieren Link zu diesem Kommentar
Das Urmel 10 Geschrieben 31. August 2005 Melden Teilen Geschrieben 31. August 2005 Da gibt es Fallstricke die sich mit den Versionen geändert haben, hat Grizzly999 ja auch schon in aller gebotenen Kürze gut skizziert. Hier mal die offiziellen Bekanntgaben zu dem Thema EFS und XP Zitieren Link zu diesem Kommentar
Candy 27 Geschrieben 31. August 2005 Melden Teilen Geschrieben 31. August 2005 Hi, o.k. das hat er auch verstanden :) . Also mit der Rücksetzung des PWs des Users und mit der danach Entschlüsselung seiner Daten, kann denn der User es wieder neu verschlüsseln. Aber dann benötigt der Admin auch den neuen Wiederherstellungsagentenschlüssel? Der alte ist denn unbrauchbar? Oder kann er den alten Schlüssel weiter nutzen? Thx grizzly, ist die letzte Frage! :) Zitieren Link zu diesem Kommentar
grizzly999 11 Geschrieben 31. August 2005 Melden Teilen Geschrieben 31. August 2005 Nein, wieso sollte der Wiederherstellungsagent danach einen neuen Schlüssel brauchen? Der ist solange gültig, wie sein Zertifikat gültig ist. P.S: Muss nicht die letzet Frage gewesen sein, dazu ist das Board ja da ;) grizzly999 Zitieren Link zu diesem Kommentar
Candy 27 Geschrieben 31. August 2005 Melden Teilen Geschrieben 31. August 2005 P.S: Muss nicht die letzet Frage gewesen sein, dazu ist das Board ja da ;) O.k., ich nehme dich beim Wort. :) Ich bin bis dato davon ausgegangen, dass wenn ein User Daten verschlüsselt zwei Schlüssel iniziiert werden. Der Admin nimmt den Wiederherstellungsagentenschlüssel und sichert sich diesen extern. Wenn jetzt aber der gleiche User zwei Wochen später wieder Daten mit Hilfe von EFS verschlüsselt, dachte ich das der admin diesen neuen WDH schlüssel sichern muss und der alte hinfällig ist. Kann der Admin denn mit seinem ersten Schlüssel alle Daten entschlüsseln, wenn der User z.B. in einem Zeitraum von 6Monaten Daten verschlüsselt hat? Oder muss der WDH Schlüssel immer erneuert werden? Denn davon bin ich bis jetzt immer ausgegangen(Wurde mir vom Dozenten eigentlich auch so erklärt :suspect: ) THX... Zitieren Link zu diesem Kommentar
grizzly999 11 Geschrieben 31. August 2005 Melden Teilen Geschrieben 31. August 2005 Ja, es werden zwei Schlüssel für den Benutzer (und auch zwei für den DRA) generiert, ein Schlüsselpaar. Das eine ist der öffentliche Schlüssel, das andere der zugehörige private Schlüssel, für eien asymetrische Verschlüsselung. Die haben aber nichts mit der Verschlüsselung der Datei zu tun. Die Datei selber wird mit einem Dateiverschlüsselungsschlüssel (FEK File Encryption Key) in einem symetrischen Verschlüsselungsverfahren verschlüsselt, der für jeden einzelnen Verschl.-Vorgang vom System zufallsmäßig neu generiert wird. Dieser FEK wird dann mit dem öffentlichen Schlüssel des Benutzers verschlüsselt und dieser nun verschlüsselte Dateiverschlüsselungsschlüssel an die Datei im DDF (Data Decryption Field) angehängt. Ist ein Wiederherstellungsagent (DRA Data Recovery Agent) per GPO definiert, hat dieser wie o.a. auch ein Schlüsselpaar. In diesem Fall holt sich das System beim Verschlüsseln der Datei auch noch dessen öffentlichen Schlüssel aus dem zertifikat in der GPO raus und verschlüsselt damit gleich nochmal den FEK, ganz genauso wie eben mit dem öff. Schlüssels des Benutzers. Diesen zweiten verschlüsselten FEK hängt das OS in einem weiteren Feld an die Datei, den DRF (Data Recovery Field) an. An der verschlüsselten Datei hängt jetzt also zwei mal der verschlüsselte FEK. Eine mit einem öffentlichen Schlüssel verschlüsselte Datei (in dem Fall der FEK) kann man nur mit dem zugehörigen privaten Schlüssel wieder entschlüsseln. Das bedeutet, zwei unterschiedliche private Schlüssel, der des benutzers und der des DRA können den den eigentlichen Dateiverschlüsselungsschlüssel für diese Datei wieder entschlüsseln und damit die Datei entschlüsseln, nämlich der Benutzer und der DRA. Das Schlüsselpaar bestehend aus öff. und priv. Schlüssel ändert sich aber nicht, außer das Zertifikat geht verloren oder läuft ab und muss neu ausgestellt werden. Was sich bei jeder verschlüsselung ändert, ist der FEK, der selber verschlüsselt an die Datei angehängt wird. HTH grizzly999 Zitieren Link zu diesem Kommentar
Candy 27 Geschrieben 31. August 2005 Melden Teilen Geschrieben 31. August 2005 Hi, also auf deutsch gesagt, nimmt der Admin seinen ersten Schlüssel und muss sich über Weiteres verschlüsseln von Daten der User kein Kopf mehr machen?! Er kann mit seinem "General" Schlüssel alles wieder entschlüsseln? Zitieren Link zu diesem Kommentar
grizzly999 11 Geschrieben 31. August 2005 Melden Teilen Geschrieben 31. August 2005 Jjj......a (zögerlich) Ist vom Fakt her richtig, aber die Begriffe implementieren möglicherweise was Falsches. Der Wiederherstellungsagent (z.B. Admin) hat nicht einen ersten Schlüssel, was implizit nahelegen würde: .. und seinen zweiten Schlüssel und dritten Schlüssel, und.... Er halt halt ein Schlüsselpaar bestehnd aus zwei Schlüsseln, so wie jeder User auch, der verschlüsselt. Da sind beide, User und Admin exakt gleich. Das gilt auch für den Begriff "general Schlüssel". Der DRA hat keinen Generalschlüssel. Dass er alle verschlüsselten Dateien von allen Usern entschlüsseln kann, liegt schlichtweg daran, dass für jede verschlüsselte Datei der FEK zusätzlich auch mit seinem öffentlichen Schlüssel verschlüsselt wird. Er ist sozusagen immer dabei. Aber wie gesagt, die Quintessenz stimmt: Der DRA kann mit seinem Schlüssel jederzeit alle verschlüsselten Datein entschlüsseln, egal wie oft er oder ein User die ver- und wieder entschlüsselt haben, solange nur sein Zertifikat auch gültig ist, und an der sonstigen Konfiguration ichts geändert wird (GPOs) grizzly999 Zitieren Link zu diesem Kommentar
Candy 27 Geschrieben 31. August 2005 Melden Teilen Geschrieben 31. August 2005 THANKS grizzly999 :) Zitieren Link zu diesem Kommentar
Das Urmel 10 Geschrieben 31. August 2005 Melden Teilen Geschrieben 31. August 2005 @Grizly999 wenn ich deine Aussage, die verklausuliert bis zum geht nicht mehr ist auf einen einfachen verständlichen Nenner bringen darf: der DRA kann die Dateine lesen, besitzt also den Public Key. Deswegen kan er die Dateien auch unverschlüsselt wieder ablegen. Das ist die Quintesssenz aus der {deiner} verklausulierten Beschreibung, oder hast du da einspruchsgerechte Anmerkungen,die ich in der Kurzfassung nicht berücksichtigt habe? ;) Zitieren Link zu diesem Kommentar
grizzly999 11 Geschrieben 1. September 2005 Melden Teilen Geschrieben 1. September 2005 Das ist korrekt, bis auf: "der DRA kann die Dateine lesen, besitzt also den Public Key" müsste heißen: " ......., besitzt also einen private key" Ich werde mich bemühen längere Ausführungen in kürzere Satze zu fassen ;) grizzly999 Zitieren Link zu diesem Kommentar
Empfohlene Beiträge
Schreibe einen Kommentar
Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.