SSD Disk Encryption (Truecrypt vs Bitlocker vs DiskCryptor)

[MadRobot]

Doch TC bremst leider sehr.
Siehe hier

Vergleiche einfach mal die zwei Screens der C300 mit und ohne TC.

 

[stw500]

DC? Wie sehr bremst TC denn aus, wenn man schnelle Hardware hat? Nur beim Benchmark oder auch in der Praxis? Mindestens bei einem Sandy Bridge mit AES-Ni sollte das doch kein Problem sein?

AES-NI bringt überhaupt nichts im 4k Bereich, da kann man auch eine schnelle CPU (z.B. i5-750@4Ghz) ohne AES-NI haben und keinen Unterschied (nicht mal beim benchen) merken. Das wurde hier im Forum schon mehrfach besprochen und getestet.

DC ist im Gegensatz zu TC auch für SSDs programmiert und verbessert worden. Aus diesem Grunde gibt es im 4k Bereich im Gegensatz zu TC fast keinen Einbruch mehr. Und JA, man merkt den Unterschied auch im realen Einsatz. Hatte vorher jahrelang (und davon rund 1 Jahr lang mit SSD) TC im Einsatz und habe mich immer geärgert, warum meine SSD so langsam war. Dann habe ich DC eingesetzt und mittlerweile kann ich im Grunde keine Einbußen mehr feststellen.

 

[Doktor]

Wieso wird TC nicht weiterentwickelt, damit es auch mit SSD gut funktioniert?

 

[Whistl0r]

Wer sagt, dass an TC nicht weiterentwickelt wird? Die Entwicklung war noch nie öffentlich... irgendwann kommt einfach eine neue Version.

 

[Los]

Ist es bei DC auch möglich eine Partition zu TRIMen, die nicht zur Systemverschlüsselung gehört?

---------- Beitrag hinzugefügt um 20:04 ---------- Vorheriger Beitrag war um 19:44 ----------

Ah, und noch etwas: Gibt es irgendwo einen vollständige Dokumentation von DC? Die Seite ist irgendwie total unübersichtlich, teilweise kann man in Deutsch umstellen, andere Teile sind nur in Russisch vorhanden...

 

[Los]

@*******: Das beantwortet meine Frage leider nicht so ganz - funktioniert TRIM nun auch auf einer verschlüsselten Nicht-OS-SSD? Bei TC funktioniert es auf jeden Fall NICHT (steht auch in der TC-Dokumentation). Wie sieht es bei DC aus?
Und weißt du, wo man eine aktuelle Dokumentation zu DC herbekommt?

 

[randfee]

Jungs, was denkt ihr....

neuer Firmenlaptop gefällig, wird wohl ein Lenovo X220. Eigentlich wäre die Sache klar, SSD rein und gas, aber bei uns (Forschungseinrichtung, 1200 Mitarbeiter) ist Safeboot (=McAfee Endpoint Encryption) nicht aus den IT-Köpfen in Bezug auf Mobilrechner wegzudenken.
Der Kram verschlüsselt ja jeden Sektor und macht doch somit die SSD nicht nur performance-mäßig fertig, sondern drückt auch noch gehörig die Lebensdauer, so wie ich das sehe. Jede SSD sucht sich doch dann dämlich nach freiem Platz!?

Ich versuche zur Zeit die IT zu bearbeiten einfach die Hardwareverschlüsselung der Intel (320) SSD zu nutzen statt Safeboot, weiß aber nicht ob die sich darauf einlassen (vermute mal nein).
Falls ich mit Safeboot kaum einen Performance-Vorteil mehr durch die SSD hätte bzw. gar einen Nachteil, dann würde ich mir auch eher eine große normale HDD geben lassen...
Hat einer Erfahrungswerte was die aktuellen Safeboot-Versionen angeht, bremsen die die SSD ungemein aus oder kommt das mitlerweile der Performance ohne Encryption gleich?

... wenn auch völlig widerwillig, ich möchte nämlich die eklatanten Performancevorteile meiner Privat-SSDs auch endlich auf der Arbeit sehen.

danke

 

[Los]

@randfee: Für Firmensicherheit ist die Hardwareverschlüsselung der SSD ebensowenig zu gebrauchen wie die Softwareverschlüsselung von McAfee. Selbst wenn ihr absolute Cracks bei euch habt, was Kryptografie und Programmieren angeht, möchte ich doch sehr bezweifeln, dass ihr den Sourcecode von Safeboot vorliegen habt (und niemand wird jemals wissen, ob Intel nicht einen Masterschlüssel für die Hardware-FDE der 320er besitzt). Und ohne den kann man unmöglich alle Sicherheitslücken finden. Insofern sind beide Lösungen Security by Obscurity und eigentlich ein No-Go!
Bei TC und dc liegt der sourcecode vor und daher kann ein des Programmierens Mächtiger hier seine eigenen Binaries machen - das ist die einzige Methode, die dem Prädikat "sicher" nahe kommt (wenn man davon absieht, dass das größte Sicherheitsrisiko immer vor dem PC sitzt ).
edit: Du wirst immer einen eklatanten Vorteil von einer SSD haben: Die Zugriffszeiten. Wenn der x220 einen sandybridge mit AES-NI bekommt, dann kannst du auch die Geschwindigkeit voll nutzen ohne Einbußen zu haben. Was TRIM-Support angeht musst du das wohl leider selbst prüfen, da kein sicherheitsbewusster Mensch Safeboot wählen würde...

@*******: Darum ging es in meiner Frage in dem anderen Thread ja - ich hab eine SSD gesucht, die klein genug ist, um preislich noch einigermaßen ins Budget zu passen (meine System-SSD hab ich schon mit der Intel G2) und trotzdem ordentliche Transferleistung bietet, dass ich damit einen i7-2600k unter Volldampf befüttern kann (momentan für Stapelumwandlung unter Photoshop gedacht, evlt HD-Videoencoding). Eine HDD würde hier einen üblen Flaschenhals darstellen, mit der Samsung 470 Series 64GB mit ihren 160-175MB/s sequentieller Schreibleistung wäre ich da schon sehr gut aufgestellt.
Allerdings bin ich momentan eher am überlegen, einfach den möglichen RAM bis zum Maximum aufzustocken und dann in einer 16-32GB (wenn denn endlich 8GB-Module mal verfügbar wären) RAM-Disk zu arbeiten - an die Transferleistungen (siehe Anhang) kommt keine SSD heran.
Wenn ich jedenfalls die Samsung nehmen sollte, will ich natürlich trotzdem in einem verschlüsselten System arbeiten, und daher müsste die SSD auch geTRIMt werden können

---------- Beitrag hinzugefügt um 22:59 ---------- Vorheriger Beitrag war um 22:24 ----------

edit: 8GB RAM IST verfügbar Somit ist die Samsung wohl gar nicht notwendig

 

[Whistl0r]

@randfee: Für Firmensicherheit ist die Hardwareverschlüsselung der SSD ebensowenig zu gebrauchen wie die Softwareverschlüsselung von McAfee. Selbst wenn ihr absolute Cracks bei euch habt, was Kryptografie und Programmieren angeht, möchte ich doch sehr bezweifeln, dass ihr den Sourcecode von Safeboot vorliegen habt (und niemand wird jemals wissen, ob Intel nicht einen Masterschlüssel für die Hardware-FDE der 320er besitzt). Und ohne den kann man unmöglich alle Sicherheitslücken finden. Insofern sind beide Lösungen Security by Obscurity und eigentlich ein No-Go!

Irgendwo muss man beginnen zu vertrauen. Man sollte auch heute darauf setzen können, dass man davon wüsste, wenn es hier Wege gäbe.

Was wichtiger ist: Für Firmen muss so etwas zentral verwaltbar sein. Es muss via HelpDesk bspw. Challenge&Response Verfahren geben. Daran scheitern die ganzen "freien" Lösungen. Sie sind absolut nicht Enterprise-tauglich vom Handling.

Bei TC und dc liegt der sourcecode vor und daher kann ein des Programmierens Mächtiger hier seine eigenen Binaries machen - das ist die einzige Methode, die dem Prädikat "sicher" nahe kommt (wenn man davon absieht, dass das größte Sicherheitsrisiko immer vor dem PC sitzt ).
edit: Du wirst immer einen eklatanten Vorteil von einer SSD haben: Die Zugriffszeiten. Wenn der x220 einen sandybridge mit AES-NI bekommt, dann kannst du auch die Geschwindigkeit voll nutzen ohne Einbußen zu haben.

Wie kommt es, dass du der AES-Implementierung von Intel vertraust?

Paranoia schön und gut, aber man kann es wirklich übertreiben. Ohne irgendwo zu vertrauen, geht es nicht.

Zu glauben bei kommerziellen Lösungen könnte man nie sicher sein hat doch nichts mehr mit Realismus zu tun: Wenn du es für möglich hältst, dass Firmen wie McAfee, Sophos oder Symantec in ihren Lösungen Hintertüren haben, von denen bislang noch niemand gehört hat, dann musst du es auch für möglich halten, dass in TC und Co. Hintertüren sind, nur die Leute die sie entdeckt haben schweigen (weil sie das Wissen bspw. gewinnbringend für sich einsetzen).

Und nicht vergessen, dass Intel dir eine CPU verkauft hat, wo die AES-Implementierung bei jeder Operation noch einen NSA-Generalschlüssel einfügt... weißt ja: Intel... amerikanisches Unternehmen, Patriot Act...


@ randfee:
Kaufe dir eine ordentliches SSD, welches auch komplett gefüllt volle Geschwindigkeit garantiert und mit 5j Garantie aufwartet. Fängt bei ~400€ an...

 

[Los]

Was hat das mit Paranoia zu tun? Wirtschaftsspionage kostet Milliarden. Wer hier irgendjemandem vertraut, lebt jenseits der Realität. Je mehr man vertraut, desto verwundbarer ist man.
Denn was hat Vertrauen bitteschön mit Sicherheit zu tun? Genau: Nichts. Sicher ist nur, was man zu 100% nachprüfen kann. Kann man closed-source (Bitlocker, McAfee EE und wie sie alle heißen) nachprüfen? Nein - also sind sie per Definition nicht sicher Open-source (oder bei TC: offenliegenden Quellcode) kannst du nicht nur nachprüfen, sondern auch entsprechend deinen Anforderungen anpassen (bei TC nicht möglich, bei dc sehr wohl). Du brauchst eine zentrale Überprüfungsroutine? Dann programmiere sie dir. Nur so musst du niemandem außer deinen eigenen Fähigkeiten vertrauen.
AES-NI ist nur eine Kryptoengine des Prozessors, die speziell für die Berechnung der mathematischen Operationen von AES programmiert sind. Mit den Schlüsseln hat das nichts zu tun. Außerdem verringert es die Gefahr von Seitenkanalattacken.

 

[Poddy]

Dem Betriebssystem und diversen Programmen musst du doch auch vertrauen, oder? Wenn ich etwas von Spionage mitbekommen habe, lag es immer entweder an internen Mitarbeitern die für Geld Daten raus schaffen, an falschem Umgang mit dem PC/ Netzwerk (z.B. Emails) oder an zu lascher Überwachung der Betriebsräume, wodurch dann auch mal fremde in den Betrieb gelangt sind und sich an einen PC gesetzt haben. Ich würd mir eher Sorgen um diese Sachen machen oder hast du etwa schonmal etwas von geknackten Verschlüsselungen oder deren Hintertürchen gehört? Von demher geht das was manche sich hier zum Teil für Sorgen machen schon Richtung Paranoia.

 

[Whistl0r]

Verstehe mich bitte nicht falsch, aber du scheinst ein sehr naives Weltbild ohne praktische Erfahrung zu haben.

In deiner Kernaussage möchte ich dir nicht widersprechen - Vertrauen und Sicherheit passt (auf den ersten Blick) nicht zusammen.

Doch wenn man auf dem Gebiet etwas Wissen und Erfahrung hat sammeln dürfen, so wird man feststellen, dass die beiden Begriffe doch irgendwie etwas miteinander zu tun haben (Stichwort "Totale Sicherheit gibt es nicht", was ist dann Überhaupt Sicherheit? Wogegen kann ich mich überhaupt schützen? In welcher Form? Was sind meine Möglichkeiten? Was sind meine Grenzen?). Diese Erfahrung habe ich zumindest bisweilen gemacht.


Das ist jetzt etwas allgemeiner, eventuell auch philosophischer Natur, aber uns allen sollte bewusst sein, dass es ohne ein so genanntes "Grundvertrauen" nicht geht. Das ist übrigens ein definierter Begriff.
Du kannst nicht alles selber machen. Es gibt immer den Punkt, wo du auf andere vertrauen musst. Ohne Vertrauen in andere ist für uns Menschen kein Leben möglich.
Wenn wir davon jetzt die Kurve zurück zum Thema "Sicherheit bei Computern" schlagen wird hoffentlich klarer was ich meine: Du sprichst davon, dass du nicht Quell-offenen Produkten nicht vertraust. Gar ein Hintertürchen vermutest bzw. für möglich hältst. Als sichere Alternative empfiehlst du dann TC, weil du hiervon den Quellcode glaubst einsehen zu können (das "glaubst" ist hier bewusst gewählt!).
Ich hoffe du selber behauptest von dir nicht, Kryptographie zu durchblicken - also bspw. den Algorithmus zu begreifen und selber implementieren zu können. Ist es dann nicht ein völliger Widerspruch zu glauben, dass TC daher sicherer ist? Du hast den Quellcode nicht überprüft. Du hast wie jeder andere Mensch die theoretische Möglichkeit, aber am Ende des Tages zählt was wirklich geschehen ist... Du, der behauptet Vertrauen und Sicherheit passe nicht zusammen, vertraut nun also darauf, dass andere den Quellcode überprüft und mögliche Fundstellen brav der Allgemeinheit gemeldet hätten. Klingelt es?

Das ist in meinen Augen einfach schizophren. Vor allem aber führt das dazu, dass man sich in falscher Sicherheit wiegt. OpenSource ist toll und hat angenehme Vorteile. Aber nur weil etwas quelloffen ist, ist es dadurch nicht automatisch sicherer. Gerade bei Community-Produkten ist es das beispielsweise nicht...

AES-NI ist nur eine Kryptoengine des Prozessors, die speziell für die Berechnung der mathematischen Operationen von AES programmiert sind. Mit den Schlüsseln hat das nichts zu tun. Außerdem verringert es die Gefahr von Seitenkanalattacken.

Das ist so völlig falsch und ein prima Beispiel dafür, wie fehlendes Wissen gepaart mit Halbwissen zu einer richtigen Gefahr werden kann: Sobald du auf die AES-Hardwarebeschleunigung des Prozessors setzt, läuft die gesamte AES-Verschlüsselung im Prozessor ab und verwendet somit die AES-Implementierung des Prozessors. Diese ist ClosedSource! Ich hoffe also für dich, dass du kein Hardwarebeschleunigung verwendest, denn dann müsstest du ja bspw. Intel vertrauen... aber Vertrauen und Sicherheit...

Es ist wirklich möglich und vor allem auch locker vorstellbar, wenn man schon Hintertürchen in BitLocker, SafeBoot, SafeGuard, PGP WDE usw. vermutet, dass dort getrickst wird: Es reicht doch schon, dass ähnlich bei der Debian SSH-Anpassung ~2009 derart etwas verändert wird, so dass nun Angriffe möglich sind. Wie viele Leute werden daran wohl mitgearbeitet haben? Leben die alle noch oder hat so ein Superhirn nach Fertigstellung plötzlich ein tödlichen Unfall ereilt (Mitwisser sind gefährlich!).

Nicht ohne Grund erwähnt TC ja deshalb, dass es selbstverständlich möglich ist, auf die Beschleunigung zu verzichten, dafür dann auf eine offene Implementierung zurück zugreifen, welche du natürlich zuvor überprüft hast

Also: Wenn wirklich derart Paranoia an den Tag gelegt wird, dann erwarte ich auch, dass du sie komplett und konsequent auslebst. Dazu gehört es dann wirklich auf jegliches ClosedSource und Annehmlichkeiten wie bspw. Hardwarebeschleunigung zu verzichten...

 

[Los]

Mir ging es in meiner ersten Aussage oben ganz einfach um die Tatsache, dass die Hardwareverschlüsselung der 320er von Intel genauso sicher oder unsicher sein mag wie McAfee EE oder wie die Programme alle heißen mögen - man wird es nie herausfinden (gesetzt den Fall, es findet kein funktionierender Angriff statt oder geheime CIA-Protokolle finden niemals ihren Weg an die Öffentlichkeit).
Würden die Hersteller von Verschlüsselungssoftware ihren Quellcode offenlegen, dann könnte jeder mit dem entsprechenden Fachwissen nachprüfen, ob er sicher ist. Was hätten die Unternehmen zu befürchten - dass jemand das Programm nachbaut? Solange der Quellcode patentiert ist, wird auf dem legalen Markt nichts passieren - jeder Codedieb würde verklagt. Im Endeffekt könnten sie nur gewinnen, da eine sichere Implementierung zu kaufen wesentlich einfacher/kostengünstiger ist, als sie selbst zu schreiben.
Firmenabteilungen, die an Multimillionen$-Projekten arbeiten werden aber mit Sicherheit auch hier ihre eigene Software entwickeln.

Dein Link zu Truecrypt ist eigentlich ein schönes Gegenargument zu dem, was du schreibst - hast du gelesen, was in der TC-Dokumentation drinnen steht? Mit

e.g. because you want TrueCrypt to use only a fully open-source implementation of AES

wird nur der open-source-Gedanke angesprochen, mit sicherheitskritischen Aspekten hat das nichts zu tun. Wenn es aus Sicht der TC-Entwickler auch nur die kleinsten Bedenken bezüglich der Sicherheit geben würde, würden sie es nicht nutzen. So werden von TC z.B. nicht die AES-NI Schlüsseloperationen genutzt:

TrueCrypt does not use any of the AES-NI instructions that perform key generation.

AES-NI ist closed-source. Stimmt. Sag ich ja auch nichts gegen. Nur wenn man aus AES-NI die Schlüsselerzeugung rausnimmt (was bei TC der Fall ist), führt die Kryptoengine einzig und allein noch mathematischen Berechnungen durch, ohne jemals mit dem Schlüssel in Berührung zu kommen. Was ich aber auch weiter oben schon geschrieben hatte
Wenn du einen Gegenbeweis hast, immer her damit! Aber einfach eine Behauptung in den Raum zu stellen, reicht mir nicht

---------- Beitrag hinzugefügt um 14:35 ---------- Vorheriger Beitrag war um 14:21 ----------

@Poddy: Warum sollte ich irgendwelchen Programmen vertrauen? Ich habe nichts davon selbst geschrieben und auch kein Bekannter von mir, dem ich vertraue. Davon abgesehen muss ich den Programmen aber auch nicht vertrauen, weil ich mit ihnen kein Geld verdiene. Die Diskussion hier ist eher theoretischer Natur - wem kann eine Firmensecurity (mit entsprechenden Möglichkeiten) vertrauen?

Eine Kette ist immer nur so stark wie ihr schwächstes Glied. Sind alle Systeme komplett verschlüsselt, wird man sich für die Wirtschaftsspionage ein schwächeres Glied suchen. Und da Mitarbeiter ein viel schwächeres Glied sind, als einen multinationalen Konzern dazu zu bringen, seine Hintertürchen offenzulegen, wird man natürlich zuerst hier ansetzen. Du hast also vollkommen Recht

---------- Beitrag hinzugefügt um 14:48 ---------- Vorheriger Beitrag war um 14:21 ----------

Letzten Endes geht es immer darum, wieviel einem die Daten wert sind. Das ist im privaten Bereich ein rein subjektiver Aspekt und deswegen muss jeder selbst entscheiden, wieviel Vertrauen er irgendwelchen Programmen entgegen bringt.
1. Jemand, dem seine Daten nichts wert sind, der hat außer der einen Version auf seinem Rechner keine weitere.
2. Jemand, dem seine Daten wichtig sind, der legt von der Version auf dem Rechner noch eine Kopie auf externen Platten oder wer-weiß-wo sonstnoch an.
3. Jemand, der nicht möchte, dass jemand anderes auf die Daten zugreifen kann, der verschlüsselt seine Daten.
4. Je nachdem, wie wichtig die privat zu verbleibenden Daten sind, wird ein entsprechend kundiger Mensch dann auch noch das Verschlüsselungsprogramm selbst überprüfen. Jemand, der zu soetwas in der Lage ist, wird vermutlich auch sein OS selbst zusammengebastelt haben

Ich persönlich befinde ich auf der dritten Stufe - mehr sind mir meine Daten nicht wert, würde ich mich lange und intensiv genug mit dem Thema beschäftigen, könnte ich es auch auf Stufe vier bringen, aber wie gesagt, soviel sind mir meine Daten nicht wert. Wenn Firmen genauso an Sicherheit herangehen wie ich, dann sagt das deutlich etwas über den Wert ihrer Daten aus...

 

[HLmurphy]

Ich hoffe ihr kommt bzgl. Intel AES-NI noch auf einen gemeinsamen Nenner, denn in dem Punkt würde mich das Ergebnis der Diskussion schon interessieren

 

[stw500]

Naja, zumindest aus Performance-Sicht kann man wohl sagen (siehe entsprechende Screenshots in diesem Thread), dass man bei einem leistungsfähigen Prozessor und DC kein AES-NI benötigt, da die Limitierung dann jedenfalls nicht in der Verschlüsselung liegt.

Bei TC ist das etwas anderes...und da bringt im Übrigen auch AES-NI nicht mehr Leistung.

Aber die Frage, ob man mit AES-NI ein Sicherheitsrisiko eingeht, mit TC und/oder DC, die finde ich schon sehr interessant. Also Quellen bitte, Jungs!

 

[Los]

Quelle für TC bezüglich AES-NI: TrueCrypt - Free Open-Source Disk Encryption - Documentation - Hardware Acceleration

 

[stw500]

Danke für die Quelle. Zutreffend ist wohl, dass AES-NI nicht zur Schlüsselgenerierung genutzt wird. Das sagt m.E. aber noch nichts darüber aus, ob man hierdurch tatsächlich geschützt wäre, wenn durch die AES-NI ein schädliches Verhalten bewirkt werden würde. Auch weiß man nicht, ob der Schlüssel - ist er erstmal generiert - nicht doch in den Bereich AES-NI "geschoben" werden muss, um die Beschleunigung zu gewährleisten.

Ich würde auch nicht so weit gehen, aus dem sechsten Absatz herauslesen zu können, dass nur der idealistische Open-source-Gedanke der Sinn dieser Abschaltung ist. Für mich klingt es eher so, dass TC keine Ahnung hat, was AES-NI tatsächlich ist bzw. was alles darin programmiert wurde, und sie eine Möglichkeit haben wollten, zur eigenen Sicherheit diese Funktion komplett auszuschließen.

 

[Los]

Ich denke zwar, dass das unser "Laienwissen" übersteigt - wie die meisten Dinge, die wir hier schreiben, aber da ich sehr gerne philosophiere, warum nicht? -, aber es gibt zu AES-NI mit Sicherheit genaue Dokumentationen, was die einzelnen Befehle genau machen. Und ich traue den Jungs von Truecrypt vollkommen zu, dass sie wissen, was sie machen. Bevor jetzt jemand wieder damit anfängt: "traue ihnen zu"="halte sie für fähig genug, die Dokumentation von AES-NI zu lesen und zu entscheiden, was davon von Nutzen für eine Verschlüsselung ist und was man als grenzwertig wegschneiden sollte" - die TC-Entwickler hätten nicht den geringsten Nutzen davon, eine potentiell unsichere Methode in ihr Sicherheitskonzept einzubinden.

Davon mal abgesehen ist dieses Szenario mehr als unwahrscheinlich - für ein im eigenen Haus entwickeltes Verschlüsselungsverfahren (die Hardware-FDE der 320er) kann man sich auch ohne viel Fantasie noch ausmalen, dass dort ein Masterschlüssel existieren kann (weil das sehr einfach wäre!). Wenn man sich jetzt aber mal überlegt, dass jedes Verschlüsselungsprogramm unterschiedlich mit seinen Schlüsseln umgeht (Behauptung von mir, das einzige, was ich dazu gelesen habe, ist, dass Truecrypt als einziges Programm den Masterkey verschlüsselt im RAM ablegt und daher gegen Firewireangriffe geschützt ist, Bitlocker z.B. ist es nicht, weil es den Masterkey unverschlüsselt im RAM ablegt), dann müsste hier eine in Hardware eingegossene Routine existieren, die mit jedem von diesen Programmen umgehen kann (-> sehr viel Code von Nöten, der von irgendwo abgerufen werden muss). Und wo sollte diese Routine den Schlüssel abspeichern? Längst nicht alle verschlüsselten PCs sind mit dem Internet verbunden, also müsste ein Laufwerk herhalten - in der Routine sind also auch noch sämtliche Laufwerkstreiber enthalten? Oder, wenn die Routine über das OS läuft, sind sämtliche OS-Datenspeicherungsmethoden enthalten? Und wie soll ein solcher Laufwerkszugriff der Routine ablaufen, wenn er dazu keine Berechtigungen hat (für die irgendwelche Einträge im Kern des OS - also bei Windows z.B. der Registry - angelegt werden müssten)? Wie verhindert die Routine, dass sie den in unserer Fantasie von ihr erzeugten/gesnifften Key in ein paar Bytes speichert, die zum Header des Volumes gehören und dadurch das Volume inoperabel schädigt, und wie um alles in der Welt soll irgendjemand später diese paar Bytes wiederfinden?

Zusätzlich sollte man noch bedenken, dass von Kryptologen die Gefahr von Seitenkanalattacken (der einzigen theoretischen Angriffsmethode außer Brute-Force) bei der Nutzung von AES-NI als niedriger eingestuft wird - hier macht AES-NI den ganzen Prozess also sogar noch sicherer!

 

[HLmurphy]

Mich eher nicht, jeder hat so seine Vorstellungen und dabei sollte man es belassen.

Ich habe auch meine Vorstellungen, aber nichts dagegen, wenn diese möglichst auf gesicherten Fakten basieren. Deshalb danke für die weiteren Beiträge

Schade jedoch, dass Whistl0r sich nicht mehr dazu meldet.

 

[Los]

@HLmurphy: Woher willst du diese gesicherten Fakten denn nehmen? Nichts für ungut, aber eine Garantie wirst du einfach auf nichts bekommen, dass du selbst nicht nachgeprüft hast - was du irgendwo im Internet liest, kann zu 100% erstunken und erlogen sein!
Beispiel: Es macht zwar wie gesagt absolut keinen Sinn, aber der Eintrag bezüglich der Nutzung des AES-NI Befehls AESKEYGENASSIST könnte rein hypothetisch schlichtweg gelogen sein und dieser Befehl trotzdem von TC genutzt werden, obwohl es auf der Seite anders steht. So lang man das nicht selbst nachgeprüft hat (oder es von jemandem überprüft wurde, dem man trauen kann), weiß man einfach nicht, ob es stimmt.

 

[Whistl0r]

Die Antwort hat etwas länger gedauert, weil ich erst noch ein paar Dinge nachgeprüft habe.

AES-NI ist closed-source. Stimmt. Sag ich ja auch nichts gegen. Nur wenn man aus AES-NI die Schlüsselerzeugung rausnimmt (was bei TC der Fall ist), führt die Kryptoengine einzig und allein noch mathematischen Berechnungen durch, ohne jemals mit dem Schlüssel in Berührung zu kommen. Was ich aber auch weiter oben schon geschrieben hatte

Kann ich nun bestätigen. TC greift lediglich auf die HW-Funktionen "AES[DEC|ENC]" bzw. "AES[DEC[ENC]last" (siehe TC-Source\Crypto\Aes_hw_cpu.asm).

Nur ist das ausschlaggebend? TC übergibt den Datenblock mit dem KS an entsprechende Funktion und erwartet grob gesagt die verschlüsselte bzw. entschlüsselte Version des Datenblocks zurück.

Es findet hier keinerlei Verifikation statt (logisch... wenn ich eine Aufgabe auslagere und sie dann trotzdem selber zur Kontrolle löse, habe ich nicht wirklich etwas gewonnen). Anders gesagt: Ob wirklich verschlüsselt wurde und mit welchem Key, weiß niemand. Es könnte sein, dass er intern den ks-Parameter ignoriert und quasi immer mit dem gleichen Wert arbeitet. Das kann nur auffallen, wenn man sich die Datenblöcke roh anschaut und selber einmal versucht zu entschlüsseln.

Klar, AES-NI ist getestet... es lieferte in Tests Bit-identische Resultate. Sprich man hat bekannte Daten reingegeben wovon man weiß, wie sie wieder rauskommen müssen. Aber das ist der Punkt: Wer garantiert, dass das noch immer der Fall ist? Es kann nicht ausgeschlossen werden, dass

• es einen "Schalter" gibt, der von der getesteten Implementierung auf eine andere Implementierung, welche den Key ignoriert, umschaltet
• der Befehl abgegriffen wird. Denn auch Assembler ist noch Software - somit ist und bleibt es möglich, dass sich hier irgendetwas einklinkt.

Wer Aufgaben überträgt, müsste den ausführenden Auftragnehmer (in dem Falle also AES-NI) permanent überwachen. Tut man es nicht, so kann man auch nicht mehr sicher sein, dass der Auftragnehmer wie geplant seiner Aufgabe nachgekommen ist.


P.s.: Habe ich noch gar nicht getestet... mit AES-NI ein Volumen in TC verschlüsseln und woanders ohne AES-NI mit TC mounten. Ich erwarte, dass das geht (sofern an dem von mir verwendeten Rechner mit AES-NI nicht der NSA-Schalter umgelegt war ).

aber es gibt zu AES-NI mit Sicherheit genaue Dokumentationen, was die einzelnen Befehle genau machen. Und ich traue den Jungs von Truecrypt vollkommen zu, dass sie wissen, was sie machen. Bevor jetzt jemand wieder damit anfängt: "traue ihnen zu"="halte sie für fähig genug, die Dokumentation von AES-NI zu lesen und zu entscheiden, was davon von Nutzen für eine Verschlüsselung ist und was man als grenzwertig wegschneiden sollte" - die TC-Entwickler hätten nicht den geringsten Nutzen davon, eine potentiell unsichere Methode in ihr Sicherheitskonzept einzubinden.

Dazu zwei Dinge:

Ja genau, irgendjemand bewertet Dinge. So wie du für dich geschlossene Sicherheitslösungen als unsicher wertest (ohne es belegen zu können), scheinen die TC-Entwickler der Meinung zu sein, der Sache zu trauen. Solche Bewertungen erfolgen immer auf dem aktuellen Wissensstand. Sollten sich neue Erkenntnisse ergeben, kann sich das Bild völlig drehen. Wer hätte bspw. früher an Timing-Angriffe gedacht? Heute ist man schlauer..

Ich finde es sehr gefährlich, wenn für dich unvorstellbare Dinge (in dem Falle also ein für dich nicht erkennbares Motiv) ausscheiden. Vor 9/11 hätte ich persönlich auch nicht geglaubt, dass Menschen drei Personenflugzeuge an einem Tag in drei Gebäude steuern könnten - heute wissen wir es (leider).

Es läuft alles auf die Bewertung zurück. Ich möchte dir deine Haltung grundsätzlich ja gar nicht ausreden (hoffe das ist klar), ich möchte nur verdeutlichen wie schizophren sie in Teilen ist. Du hast absolut keine Beweise dafür, dass in SafeBoot, SafeGuard, PGP WDE, BitLocker und wie die ganzen geschlossenen Lösungen heißen Hintertüren enthalten sind (oder doch? ) und dennoch lehnst du sie ab. Bei deiner Argumentation kommst du dann mit scheinbar völlig offenen Lösungen, wo ich halt nun versuche aufzuzeigen, dass du dich auch da irgendwo auf geschlossene Bereiche einlassen musst. Das ist ja alles auch nicht schlimm... es sollte halt nur jedem bewusst sein

Wer potentielle Schwachstellen kennt, kann im Zweifel handeln. Jemand der glaubt gar keine Schwachstellen zu haben, der hat schon längst verloren.

Davon mal abgesehen ist dieses Szenario mehr als unwahrscheinlich - für ein im eigenen Haus entwickeltes Verschlüsselungsverfahren (die Hardware-FDE der 320er) kann man sich auch ohne viel Fantasie noch ausmalen, dass dort ein Masterschlüssel existieren kann (weil das sehr einfach wäre!). Wenn man sich jetzt aber mal überlegt, dass jedes Verschlüsselungsprogramm unterschiedlich mit seinen Schlüsseln umgeht (Behauptung von mir, das einzige, was ich dazu gelesen habe, ist, dass Truecrypt als einziges Programm den Masterkey verschlüsselt im RAM ablegt und daher gegen Firewireangriffe geschützt ist, Bitlocker z.B. ist es nicht, weil es den Masterkey unverschlüsselt im RAM ablegt), dann müsste hier eine in Hardware eingegossene Routine existieren, die mit jedem von diesen Programmen umgehen kann (-> sehr viel Code von Nöten, der von irgendwo abgerufen werden muss). Und wo sollte diese Routine den Schlüssel abspeichern? Längst nicht alle verschlüsselten PCs sind mit dem Internet verbunden, also müsste ein Laufwerk herhalten - in der Routine sind also auch noch sämtliche Laufwerkstreiber enthalten?

Du hattest noch nie mit Hardware-FDE zu tun, oder?

Bzgl. BitLocker verbreitest du hier jetzt ein falsches Bild. Du solltest das System komplett verstehen, bevor du darüber urteilst. Ein guter Einstieg kann http://www.securityresearch.at/publications/windows7_firewire_physical_attacks.pdf sein. Siehe auch http://technet.microsoft.com/en-us/library/cc722487.aspx:

Wenn irgendjemand physikalischen Zugriff auf deine Kiste hat, hast du unabhängig von TC, BitLocker oder sonstigen Lösungen verloren. Das ist einfach so.

Ich würde sogar soweit gehen und behaupten, dass von den genannten Produkten eigentlich BitLocker in Verbindung mit TPM noch am sichersten wäre, denn hier würde das TPM BitLocker zerstören, bevor du deine Passphrase und damit den Key offengelegt hast, weil du die Manipulation nicht bemerkt hast (imho heißt es noch immer irgendwo in der TC Dokumentation, dass eigentlich empfohlen wird immer von einer CD zu starten. Der dortige Loader kann nicht verändert werden, ohne dass die CD sich verändert hat. Jetzt bleibt nur noch die Eingabe als Einfallstor...).

 

[HLmurphy]

@HLmurphy: Woher willst du diese gesicherten Fakten denn nehmen?

Nicht ohne Grund schrieb ich möglichst gesichert, eben gerade in Erwartung absehbarer Einwände wie diesem ...

Nichts für ungut, aber eine Garantie wirst du einfach auf nichts bekommen, dass du selbst nicht nachgeprüft hast

... und von einer "Garantie" war schon gar nicht die Rede.

[ sich an dieser Stelle bitte den bekannten MediaMarkt-Slogan hinzudenken ]

Beispiel: Es macht zwar wie gesagt absolut keinen Sinn, aber der Eintrag bezüglich der Nutzung des AES-NI Befehls AESKEYGENASSIST könnte rein hypothetisch schlichtweg gelogen sein und dieser Befehl trotzdem von TC genutzt werden, obwohl es auf der Seite anders steht.

Eben deshalb ist es umso wichtiger, möglichst viele verschiedene An- und Einsichten zu einem Thema wie diesem zu hören, denn nur dadurch werden Zusammenhänge und Möglichkeiten wie diese aufgedeckt – wenn auch dein Beispiel nicht wirklich greift, da wie von dir selbst mehrfach erwähnt bei Open Source Software solche Möglichkeiten prinzipell nachprüfbar sind – natürlich den entsprechenden Aufwand vorausgesetzt.

Weil jedoch die Wahrscheinlichkeit sehr gering ist, dass von all denen, die sich die Sources komptetent zur Brust nehmen, alle jene mundtot gemacht werden, die darin Zweifelhaftes entdecken, ist wiederum die Wahrscheinlichkeit, dass solche Sicherheitsmängel publiziert würden, hier sehr viel größer als bei nicht quelloffener Software. Allein die potentielle Gefahr der Aufdeckung solcher Hintertüren lässt die Wahrscheinlichkeit gegen Null gehen, dass sie implementiert werden. Das ist der Grundgedanke von Open Source, wie ich ihn verstehe.

So lang man das nicht selbst nachgeprüft hat (oder es von jemandem überprüft wurde, dem man trauen kann), weiß man einfach nicht, ob es stimmt.

Wenn man 100%ige Sicherheit will (die es de facto eh nicht gibt), dann stimmt das so. In der Praxis leben wir allerdings von gesunder Risikoabschätzung – und da es mir sowohl an Zeit als auch an Wissen fehlt, solche Überprüfungen selbst vorzunehmen, bleibt mir nichts anderes übrig als Diskussionen wie diese zu verfolgen und mir darauf basierend eine Meinung zu bilden. Das ist allemal mehr wert als das Thema komplett zu ignorieren, wie ein anderer Unbeteiligter andeutete, denn schon jetzt habe ich dadurch einiges dazugelernt, was ich vorher noch nicht wirklich wusste – auch was gesundes Misstrauen betrifft, von dem Whistl0r ebenfalls sprach.

So funktioniert Internet ... wenn man damit richtig umzugehen weiß. Und glaub mir, nach fast
zwanzig Jahren aktiver Beteiligung sowie beruflicher Aus- und Verwertung der so gewonnenen Informationen weiß ich das

Wer Aufgaben überträgt, müsste den ausführenden Auftragnehmer (in dem Falle also AES-NI) permanent überwachen. Tut man es nicht, so kann man auch nicht mehr sicher sein, dass der Auftragnehmer wie geplant seiner Aufgabe nachgekommen ist.

Das wäre doch mal eine nette Idee an die TC-Entwickler, sofern sie sowas nicht eh schon implementiert haben. Falls nicht (was wohl wahrscheinlicher ist), bleibt nur noch die Frage,
ob sie paranoid genug sind, es zu tun

 

[Los]

Ich glaube nicht, dass es in irgendeiner Software/Hardware nicht potentiell Schwachstellen geben kann. So etwas wäre sehr dämlich Interessant und diskutabel ist allerdings, wie wahrscheinlich eine solche Schwachstelle ist.
AES-NI als Schläfer?
Theoretisch denkbar: Ja. Praktisch machbar: Am Rande der Unmöglichkeit und ohne jeglichen Sinn (Argumente hatte ich schon weiter oben aufgeführt).
Zur reinen Denkbarkeit: Ebenso gut könnte jedes Windowssystem ein schlafender Teil des größten möglichen Bot-Netzwerkes sein, dass auf der Welt existiert - es wartet nur darauf, von M$ geweckt zu werden, die damit die Weltherrschaft übernehmen

Dein technet-link funktioniert leider nicht.
Was Firewire angeht: Nichts für ungut, aber all das, was in dem Firewiredokument steht, hatte ich doch weiter oben schon ganz kurz zusammengefasst! Bitlocker läd den Masterkey in den RAM. Von dort aus kann der Key mit einer Software per Firewire ausgelesen werden (warm boot-attack) oder der RAM entfernt, geeißt und dann ausgelesen werden (cold-boot-attack). Der gleiche Angriff hat auch auf TC stattgefunden, ist aber jetzt nicht mehr möglich. Warum? TC läd den Masterkey mittlerweile nur noch verschlüsselt in den RAM - ein Auslesen ist damit nicht mehr möglich
TPM mag dir bei einer Firewire-Attacke helfen (habe leider wirklich keine Ahnung von TPM). Wird der RAM nach einer cold-boot-Attacke nach dem Auslesen der Informationen aber wieder eingesetzt, dann sieht es für das TPM so aus, als ob nichts verändert worden ist.
ps: Dieser Artikel ist sehr alt, wenn M$ einigermaßen vernünftig war, haben sie das Problem ebenso wie TC gelöst.

 

[HLmurphy]

... wenn Du dafür dein überbreites Bild in deiner Signature, das immer den ganzen Thread auseinanderballert, schmaler machst ...

 

[Los]

Er hat ja Recht.
Sry.

 

[HLmurphy]

Ja, natürlich hatter ... ich aber auch

 

[Whistl0r]

So, nach der Diskussion will ich noch etwas zum eigentlichen Thema beitragen.

Das SSD habe ich hier bereits ausführlich vorgestellt. Hier die Tests:







TrueCrypt ist mit Abstand die schlechteste Lösung. Würde ich für SSD derzeit nicht mehr empfehlen.
DiskCryptor wäre wohl meine Wahl, wenn kein TPM verfügbar wäre. Man merkt aber, dass einiges an der Software zusammen gehackt ist. Auch stellt mich die verfügbare Dokumentation nicht zufrieden (von fehlenden Kenntnissen der russischen Sprache ganz abgesehen).
Somit ist meine Wahl also auf BitLocker gefallen. Trotz WDE gute Performance, kombiniert mit den BitLocker-Funktionen (ich mag es bspw. PBA deaktivieren zu können, ohne gleich entschlüsseln zu müssen) (m)ein Traum.

 

[stw500]

Ich denke vielen von uns wäre wohler, wenn TC auch in SSD-Hinsicht, demnächst wieder einen Sprung machen würde und aufschließen würde. Leider kann ich mangels Kompetenz nicht selber beurteilen, wie sicher und wie professionell DC programmiert worden ist.

Wenn Ihr (Whistl0r + Bob) der Meinung seid, hier sei etwas "zusammen gehackt", dann würde ich Euch darum bitten mal detaillierter darzustellen, was Ihr damit meint und inwiefern dies ein Problem darstellen könnte.

Schade finde ich neben der nicht so ausführlichen Dokumentation, dass lange Zeit zwischen den Versionssprüngen vergeht und angesprochene Sicherheitsaspekte im Forum nicht zeitnah oder überhaupt implementiert werden, obgleich es sich um im Verhältnis relativ einfache Dinge handelt, wie beispielsweise dass DC sich leider "merkt", welches Verzeichnis zuletzt für ein Keyfile verwendet wurde und dieses beim erneuten Versuch ein Volume einzubinden automatisch zuerst öffnet. Auch nach einem reboot. Das sind wirklich Kleinigkeiten, die schnell geändert werden könnten...

Andererseits muss ich für DC aber auch mal eine Lanze brechen. Ich nutze die Software in den letzten beiden Beta-Varianten jetzt schon einige Monate und weder konnte ich bei meiner SSD einen Performance-Einbruch feststellen noch war das System durch die Software jemals instabil. Im Gegenteil musste ich feststellen, dass die Stabilität mindestens genauso hoch ist, wie bei TC. Datenfehler oder ähnliches, auch beim versehentlichen Resetten des Rechners bei gleichzeitiger FSE (in Windows) und geöffneter verschlüsselter Datenpartition sind NIE aufgetreten. Ebenfalls nie Ärger bei der pre-auth (Vorsicht, Tastenlayout-Beschränkung beachten!).

Angesichts des offenen Source-Codes und der Tatsache, dass so einige Leute auf der Welt des Verstehens solcher Software mächtig sind, gehe ich schon davon aus, dass irgendwer publik machen würde, wenn da grobe Schnitzer im Programm wären, die die Sicherheit einschränken würden. Hab insoweit aber bislang nichts gelesen.

 

[Whistl0r]

Schaue dir die Software einfach an:

Schon das Programmfenster wirkt sehr einfach. Du siehst dann eine Liste aller verfügbaren Partitionen. Bei mir gab es nur ein Laufwerk (das SSD) mit zwei Partitionen (die 100MB Boot-Partition und den Rest). Du musst dann eben eine Partition anklicken und kannst dann rechts "Encrypt" klicken. Es öffnet sich ein einfaches Fenster was nach einem Kennwort fragt und dann geht es schon los. Dann ist die erste Partition verschlüsselt.

Du klickst die zweite Partition an und wählst auch hier "Encrypt" - gleiches Spiel.

Hoffentlich hast du zuvor im Menü den Bootloader manuell installiert. Andernfalls gibt es wartet eine Überraschung beim nächsten Reboot auf dich.

Keine Aufforderung bzgl. Rescue-CD. Du fragst dich, weil du für jede Partition ein anderes Kennwort wählen kannst, wie das denn funktionieren soll, dass bei der PBA das Boot-LW freigeschaltet wird... wie zum Teufel wird dann das eigentliche Daten-LW freigeschaltet, damit Windows wirklich booten kann? Naja, du startest dann doch irgendwann neu und Magie passiert - das System ist doch noch fähig zu booten.

Nach meinen Tests habe ich es deinstalliert. Dazu habe ich erst jede Partition entschlüsselt: Ausgewählt, Decrypt angeklickt, Kennwort eingeben, gewartet, fertig.

Neu gestartet: Der will noch immer ein Kennwort von mir! Schock, denn das zuvor gewählte Kennwort nimmt er nicht mehr... irgendwann drückt man "Enter" (also leere Eingabe) und er startet doch wieder (Glück gehabt!). In der software stellt man fest, dass man den Bootloader ja auch wieder manuell entfernen muss ;-)

Im Vergleich dazu TC/BL: Da passt einfach alles. Du hast erst einmal einen Haufen an Dokumentationen. Du weist wie es ablaufen wird. Jeder Schritt ist offiziell beschrieben. Die Software selber arbeitet sicher: Es gibt im Vorfeld Tests, inkl. Reboots - nur wenn das klappt, lässt die Lösung dich verschlüsseln.


Ich behaupte ja nicht, dass DC nicht funktioniert. Man sieht halt wirklich nur, wie es entstanden ist.. zusammen gehackt
Ich rate ja derzeit auch dazu, bei Systemen ohne TPM zu DC zu greifen... aber sobald TC hier nachgebessert hat, werde ich in dem Falle wohl wieder zu TC raten (TC ist wie BL eben wirklich getestet. Liest man im aktuellen DC Beta Thread, dann findet man aktuell Diskussionen über die Größe von ACPI-Tabellen... ein Problem was TC vor langer Zeit mal hatte, betraf vor allem Notebooks). DC ist ein zusammen gehacktes nicht komplett/weitreichend getestetes Programm im Beta-Stadium ohne richtige Dokumentation und Community. Das merkt man in meinen Augen bei der Nutzung auch sehr deutlich.

 

[Poddy]

Deshalb würde ich auch nie mein komplettes System mit DC verschlüsseln. Meine Backups bleiben bei TC, da ist es auch egal wenn die 4k Performance einbricht. Desweiteren hat man eine Absicherung sollte es nach einem Programm-Update eins von beiden zerhauen.

Ich denke vielen von uns wäre wohler, wenn TC auch in SSD-Hinsicht, demnächst wieder einen Sprung machen würde und aufschließen würde.

Dass sich bei TC in Sachen Performance noch was verbessern wird, schließe ich aus. Denn der Umfang des Programms ist einfach zu groß um da noch grundlegens ändern zu können ohne immesen Aufwand, da wäre eine Neuprogrammierung sinnvoller.