Ocz Vertex2 umtauschen & welche Ersatz?

[[W2k]Shadow]

das war mri klar, sorry, aber jetzt reden wir aneinander vorbei

warum sollte dieses trim nicht mit eine rzelle gehen in der vorher ein teil des containers war?

 

[Evilandi666]

Das geht natürlich, nur macht man es eben nicht, weil es theoretisch eine Sicherheitslücke darstellt (das hab ich versucht zu erklären die ganze Zeit).

 

[IronEagle]

Noe, nur mehr verwirrung gestiftet. Mit Trim wird nicht "geloescht", im Sinne von "es werden nullen geschrieben". Es wird nur der Block als "leer" (genauer: direkt ueberschreibbar) markiert. Einige SSDs haben jetzt das Feature das, wenn ein als leer/ueberschreibbar markierter Sektor angefordert wird, nicht wirklich gelesen wird sondern "null" zurueckgegeben wird. Damit kann mal schon - wie du gezeigt hast - testen ob trim greift, aber nicht mehr. Sonst wuerde ja bei jedem Trim-Vorgang ein Write/Erase-Cycle der Zelle verbraten, was auch nicht im Sinne des Erfinders waere.

Dazu kommt - wie ich ja schon in einer PN schrieb - die SSD juckt erstmal gar nicht ob da nen dmcrypt container angelegt, wird, oder nen TC container, welches OS drauf ist, welches Dateisystem - es sieht nur "ich soll X bytes an die logische Adresse schreiben". Das reine Anlegen einer 4 GB Datei (beispiel: ein Torrent-Client legt fedora.iso an, sagt es ist 4 GB gross, aber die Datei hat ja noch keinen Inhalt) heisst nicht das die SSD in dem moment auch direkt 4 GB Flash-Zellen als belegt markiert. Im Gegenteil, es werden nur ein Paar Bytes in die Verwaltungsstrukturen des Dateisystems geschrieben. Erst wenn wirklich Daten in die Datei, den TC Container oder wohin auch immer geschrieben werden sind die entsprechenden Zellen fuer den Controller belegt.

Und wenn man so RICHTIG sicher gehen will das der SSD NIE die freien Bloecke ausgehen: einfach die haelfte der SSD frei lassen Dann kann sie ja maximal zu 50% gefuellt werden, und wenn die 50% komplett ueberschrieben sind (aus Dateisystem-Sicht) weiss die SSD ja wieder das die urspruenglichen 50% wieder frei sind und direkt beschrieben werden koennen. Allerdings ist das heutzutage bei modernen Controllern nicht wirklich noetig.

Und wo ist die Sicherheitsluecke? Ich kriege bei einem getrimmten Bereich der eigentlich zu dem verschluessteltem Container gehoert halt Nullen. Das sagt mir das da nix drinsteht, und ich kann auf den Fuellstand im Container schliessen. Aber auf den Schluessel? Es heisst ja nicht das ich in dem Bereich des Containers Daten habe die verschluesselt zufaellig genau die Nullen ergeben...

 

[Evilandi666]

Noe, nur mehr verwirrung gestiftet. Mit Trim wird nicht "geloescht", im Sinne von "es werden nullen geschrieben". Es wird nur der Block als "leer" (genauer: direkt ueberschreibbar) markiert. Einige SSDs haben jetzt das Feature das, wenn ein als leer/ueberschreibbar markierter Sektor angefordert wird, nicht wirklich gelesen wird sondern "null" zurueckgegeben wird. Damit kann mal schon - wie du gezeigt hast - testen ob trim greift, aber nicht mehr. Sonst wuerde ja bei jedem Trim-Vorgang ein Write/Erase-Cycle der Zelle verbraten, was auch nicht im Sinne des Erfinders waere.

Gut, stimmt, steht auch in Wiki so

Das erklärt eben auch vllt. die Lücke, wenn man weiß das ein Block gelöscht ist (aber dessen Inhalt kennt) und weiß wo er nun steht und wie sein Inhalt ist oder sowas? (nur eine Überlegung)

Und wo ist die Sicherheitsluecke? Ich kriege bei einem getrimmten Bereich der eigentlich zu dem verschluessteltem Container gehoert halt Nullen. Das sagt mir das da nix drinsteht, und ich kann auf den Fuellstand im Container schliessen. Aber auf den Schluessel? Es heisst ja nicht das ich in dem Bereich des Containers Daten habe die verschluesselt zufaellig genau die Nullen ergeben...

Keine Ahnung, das Problem existiert ja, sonst würden sich die dm-crypt devs nicht so querstellen und das Teil hätte es schon längst (und TC hätte es auch für Container aktiviert). Um sowas zu verstehen/zu beurteilen muss man glaube ich ziemlich tief in mathematische/kryptographische Gefilde eindringen

Dazu kommt - wie ich ja schon in einer PN schrieb - die SSD juckt erstmal gar nicht ob da nen dmcrypt container angelegt, wird, oder nen TC container, welches OS drauf ist, welches Dateisystem - es sieht nur "ich soll X bytes an die logische Adresse schreiben". Das reine Anlegen einer 4 GB Datei (beispiel: ein Torrent-Client legt fedora.iso an, sagt es ist 4 GB gross, aber die Datei hat ja noch keinen Inhalt) heisst nicht das die SSD in dem moment auch direkt 4 GB Flash-Zellen als belegt markiert. Im Gegenteil, es werden nur ein Paar Bytes in die Verwaltungsstrukturen des Dateisystems geschrieben. Erst wenn wirklich Daten in die Datei, den TC Container oder wohin auch immer geschrieben werden sind die entsprechenden Zellen fuer den Controller belegt.

Das ist schon klar, ich bin mir nur nicht sicher, ob cryptsetup(Ich weiß, das ist jetzt LUKS+dm-crypt) nicht sogar das Blockdevice erstmal mit Randomzeug überschreiben will oder nicht. (TC macht das ja).

Klar ist, wenn man nur ein dm-crypt block device anlegt, ohne den Bereich komplett zu füllen, sieht ihn die SSD solange als teilweise leer, bis er mal 100% gefüllt wurde.

 

[.Sun]

Um auch mal wieder einen passenden Beitrag zum Thema zu schreiben...

Nach Secure Erase.

 

[Evilandi666]

Ist das gut oder schlecht?

 

[.Sun]

Gut

 

[moronoxyd]

Das erklärt eben auch vllt. die Lücke, wenn man weiß das ein Block gelöscht ist (aber dessen Inhalt kennt) und weiß wo er nun steht und wie sein Inhalt ist oder sowas? (nur eine Überlegung)

Bei einer SSD weisst du das eben nicht.
Wenn du einen Block als leer markierst, und dann später auf denselben logischen Block (aus Sicht des Betriebssystems) zugreifen willst, kann und wird dir der Controller der SSD irgendeinen leeren (bzw. als leer markierten) Block zurückmelden. Wearleveling lässt grüßen.

 

[Evilandi666]

Vllt. kann man aber einen anderen Controller anschließen, der nicht pauschal 0 zurückliefert oder so? (Wie gesagt, das war nur eine Überlegung.)

Wenns euch so brennend interessiert, warum das ein Problem ist in Sachen Sicherheit, fragt doch mal nen dm-crypt dev

 

[moronoxyd]

Der andere Controller weiss auch nicht, wie die logischen Blöcke des OS auf die physischen Blöcke der SSD gemappt werden.

 

[Evilandi666]

Der andere Controller weiss auch nicht, wie die logischen Blöcke des OS auf die physischen Blöcke der SSD gemappt werden.

Aber er kann dir vllt. als gelöscht markierte Blöcke korrekt auslesen, das war die Idee.

Wie gesagt, wenn alles so perfekt funktioniert, setzt euch hin, implementiert trim in dm-crypt, schickt den Patch dorthin.

 

[el-sahef]

Entgegen anderslauender Behauptungen im Thread taugt die Verschlüsselung des Controllers sehr wohl auch zum Schutz der Daten vor unbefugtem Zugriff, wenn man die Funktion auch richtig benutzt. Der Controller verschlüsselt die Daten nämlich immer (!) und zwar mittels eines per Rauschen zufällig generierten Schlüssels. Solange kein ATA-Passwort für die SSD gesetzt wird (auch als HDD-Passwort bezeichnet), kann trotz der Verschlüsselung jeder an die Daten (Auslieferungszustand).

Setzt man jetzt aber ein ATA-Passwort, dann entschlüsselt der Sandforce-Controller erst nach der Eingabe des korrekten ATA-Passworts. Hat man dieses Passwort nicht, kann man nicht auf die Daten zugreifen, weil der Controller sich weigert zu entschlüsseln und dicht macht. Die Zugriffskontrolle erfolgt also durch das ATA-Passwort, aber das ATA-Passwort ist nicht der Schlüssel, der zur Verschlüsselung der Daten verwendet wird.
Diesen Schlüssel kann man nicht selber festlegen, da er wie gesagt ja einmal zufällig durch Rauschen generiert wird. Bei einem Secure-Erase wird dieser Schlüssel gelöscht und aus Rauschen ein neuer generiert, wodurch die Daten in den Flash-Chips für den Controller nicht mehr zu entschlüsseln sind ( = die SSD ist für den Controller wieder komplett leer und die Leistung im Auslieferungszustand wieder hergestellt).

Bei normalen Festplatten ohne FDE-Funktion werden die Daten auch bei gesetztem ATA-Passwort unverschlüsselt auf der Platte abgelegt, so dass Datenrettungsfirmen durch manuelles Auslesen der Platter trotzdem an die Daten kommen. Bei Festplatten mit FDE geht das nicht, weil die Daten auf den Plattern durch die Festplatte verschlüsselt abgelegt sind. Auf SSDs übertragen bedeutet das, dass man bei Sandforce-SSDs nicht durch Umlöten der Flash-Bausteine auf eine baugleiche, aber nicht durch ATA-Passwort gesperrte SSD-Platine die Flash-Speicherchips auslesen kann, da jeder Controller einen eigenen zufällig generierten Schlüssel hat.

Lange Rede kurzer Sinn: In der Theorie kommt kein Unbefugter an die Daten ran, wenn auf ner Sandforce-SSD ein ATA-Paswort gesetzt ist.

Jetzt zur Praxis: Für diverse Festplatten (ich weiß nicht, ob es das mittlerweile auch für FDE-Platten gibt) existieren Tools, die die Firmware manipulieren, so dass die Platten auch bei gesetztem ATA-Passwort ausgelesen werden können, ohne sich die Arbeit zu machen, die Platter auszubauen und manuell auszulesen. Sollten derartige Programme, die die Firmware manipulieren oder umgehen auch für Sandforce-SSDs (oder FDE-Platten) existieren, ist die Verschlüsselung nicht mehr sicher, weil dann ein gesetztes ATA-Passwort mit so einer Firmware-Mainpulation umgangen und der Schlüssel im Controller der Sandforce-SSD (oder der FDE-Platte) auch ohne das ATA-Passwort freigegeben wird, womit die verschlüsselten Daten trotz gesetztem ATA-Paswort auslesbar sind.

Da ein normaler ahnungsloser Dieb so ein Tool aber mit hoher Wahrscheinlichkeit nicht besitzen wird, sofern es eins gibt, dürfte die Verschlüsselung für viele Leute ausreichend sein.

Will man seine Daten aber vor staatlichen Institutionen schützen, dann ist die Verschlüsselung möglicherweise nicht mehr ausreichend, denn gesetzt es gibt solche Tools, so ist die Wahrscheinlichkeit hoch, das staatliche Stellen im Besitz dieser Tools sind.

Ob einem die Sicherheit, die durch die Sandforce-Verschlüsselung geboten oder eben auch nicht geboten wird ausreicht hängt demnach von persönlichen Erwägungen ab .

Edit:

Quelle: Sammelthread zu den SSDS mit Sandforce 1200 und 1500 im Hardwareluxx

Dort stehen dann noch weitere Links drin, aber der Thread hat mehrere Teile, ich such die jetzt also nicht raus, denn da müsste ich erst nen Tag suchen, bis ich die Posts wiederfinde, hatte das alles mal gelesen, bevor ich mir ne Corsair Force F40 gekauft hatte. Glaubt die Infos so, wie sie hier stehen oder lasst es .

 

[Evilandi666]

Genau das hab ich für die Vertex 3 gelesen. Weißt du ob die Vertex 2 das kann? Das wäre ja total gut und wäre ja die Lösung aller Probleme^^

 

[el-sahef]

Die Vertex 2 (bzw. jede SSD mit Sandforce 1200 oder Sandforce 1500) verschlüsselt mit 128 Bit.

 

[Evilandi666]

Ja aber das Feature ist dort nicht gescheit nutzbar .. sie den "meine neuste Erfahrungen"-Thread.

Erst ab Vertex 3 richtig nutzbar.

 

[el-sahef]

Bevor du das hier falsch verstehst, ich will hier nicht klugscheißen, mich interessiert das Thema selber und bisher habe ich immer angenommen, dass es so funktioniert, wie ich oben geschrieben habe und darauf vertraut. Wenn es also jetzt irgendwo eine offizielle Quelle gibt, die das Gegenteil behautptet (= man braucht um jeden Preis die Toolbox), wäre ich davon betroffen.


Von dieser ominösen Toolbox habe ich zwar mal gehört, allerdings wüsste ich gerne, auf welche Quelle du deine Aussage stützt, das Featuer wäre ohne die Toolbox nicht nutzbar.

Hier mal die offizielle Aussage von dem OCZ-Mitarbeiter im Forum, auf die sich die Infos aus dem Luxx beziehen:

http://www.ocztechnologyforum.com/forum/showthread.php?71788-Sandforce-encryption-info

FDE and TCG Opal are different things.

FDE = Full Disk Encryption = Software Encryption

The Vertex 2 and Vertex 2 Pro are SED = Self Encrypting Device = Hardware Encryption

They support ATA Security but not TCG Opal.

Etwas unklar, aber was man herauslesen kann:

Die Vertex 2 / Pro (also die Sandforce 1200/1500) haben Hardwareverschlüsselung (er nennt das SED und den Begriff FDE benutzt er für Softwareverschlüsselungen wie Truecrypt oder ähnliches, ich habe oben den Begriff FDE für das benutzt, was er hier als SDE bezeichnet), aber nicht dieses TCG-Opal-Zeug (was auch immer das sein soll), was wahrscheinlich nur die Enterprise-Modelle haben.

There is no need to use bitlocker or truecrypt (Software encryption on the CPU) as encryption is already done in the SSD automatically...

--> Die Verschlüsselung ist bei den SF1200/1500 immer aktiv (automatically), auch wenn keine Passwort mit irgendeiner Toolbox gesetzt wurde.

and as long as the device password is used the data is protected from unauthorized access. Using these will only limit your system performance.

--> Wenn ein ATA-Passwort benutzt wird (hier device Passwort genannt), dann haben Leute ohne das Passwort keinen Zugriff auf die Daten.

So sicher war er sich aber wohl auch nicht und hat deshalb nochmal bei Sandforce nachgefragt.

I will update this thread as i get more info

EDIT February 22, 2011:

Jetzt kommen die wichtigen Sachen:

1. The controller advertises "AES-128 bit encryption". I understand the controller encrypts all data before it hits the NAND. With what key is this encryption done? Do any two controllers share the same key?
a. The encryption key is internally randomly generated and no two drives share the same key.

--> Habe ich ja schon in meinem ersten Post geschrieben.

2. How is this key stored internally? Is it itself encrypted? Using what algorithm?
a. We do not disclose the internal details of how the key is stored in order to prevent security issues, but we do disclose it is stored in the flash memory.

--> Die Schwachstelle der ganzen Sache: Wenn sich die Firmware manipulieren lässt, kommt man an den Schlüssel auch ohne ATA-Passwort ran und kann die Daten entschlüsseln.

3. If an ATA Security password is given to the controller, does this affect the form in which the key is stored?
a. The encryption key is not directly linked to the ATA Security password (or the BIOS password). When the password is established it is used during the challenge process to ensure the user requesting access is authorized. Once the password is authenticated the drive will decrypt the data on the flash, but again that encryption key is internally stored with the drive and not directly linked with the password.

--> Der Key zur Verschlüsselung ist unabhängig von dem ATA-Passwort, was eingegeben wird und kann vom User nicht geändert werden. Solange an den Controller nicht das richtige ATA-Security-Passwort gesendet wird entschlüsselt dieser die Daten nicht. Zum Entschlüsseln der Daten braucht man also das richtige ATA-Security-Passwort, aber dieses Passwort ist nicht der Key, der vom Controller zum Verschlüssseln verwendet wird.

4. If the ATA Security password does not alter the key, is there another way for a user to restrict access to the encryption key?
a. No one has access to the encryption key, only the SSD controller can access it. The user only has access to the security password.

--> Siehe oben, bestätigt eigentlich nur nochmal die Aussage.

5. Does issuing a secure wipe command affect this key?
a. The ATA Secure Erase command(s) will “zeroize” (erase and forget) the key and generate a new key.

--> Beim Secure-Erase wird der Key, der zur Verschlüsselung benutzt wurde gelöscht und ein neuer generiert. Die Daten sind für den Controller nun nicht mehr zu entschlüsseln, da der alte Key gelöscht wurde.

Angenommen, dieser OCZ-Tony schreib keinen Unfug, dann verhält sich das doch alles ganz genau so, wie ich in meinem ersten Post geschrieben habe? Demnach wäre die Funktion auf die beschriebene Art und Weise für jeden nutzbar, der ein ATA-Passwort setzen kann und dem die gebotene Sicherheit ausreicht, d. h., der darauf vertraut, dass die Firmware nicht geknackt wird und der Schlüssel auch ohne ATA-Passwort ausgelesen werden kann.


Auf welche Quelle stützt du deine Aussage, man benötige für die Funktion unbedingt die Toolbox?

Edit:
Und wo steht, dass bei den neuen Sandforce-SSDs der Schlüssel mit vom ATA-Passwort abhängt?

 

[Rantanplan]

Der Mechanismus ist relativ klar und hört sich sicher an, zumindest scheint Intel bei den 320ern auch so zu handhaben.

Bei Sandforce wurde es zwar nicht erwähnt, aber die auf dem Flash hinterlegten wichtigen Daten (ATA-Passwort und eigentlicher AES-Schlüssel) sollten wohl selbst auch irgendwie verschlüsselt und geschützt sein. Sonst wäre je eine Angriffsmethode, nämlich das direkte Auslesen der Speicherchips, problemlos möglich.

Das mit dieser Vermutung zeigt aber schon das Problem: So richtig kennt keiner die ganze Prozesskette und daher kann auch niemand sagen, wo evtl. eine Schwachstelle liegt. Jein, die Hersteller wissen es, aber ein Schutz scheint ja darin zu bestehen, diese kleinen, aber wichtigen Fakten geheim zu halten. Ergo bleibt uns nix anderes übrig, als den Herstellern zu vertrauen.

Wenn der Sandforce- wie auch der Intelcontroller beim Weg von der ATA-Passwort-Eingabe bis hin zum eigentlichen Entschlüsslungsprozess keine Angriffspunkte bietet, wäre da ja insgesamt eine sichere Lösung.

Problematischer -im Sinne von um Größenordnungen riskanter - dürfte der Faktor User vorm Thinkpad sein: Aus Bequemlichkeit verwendet man ja gerne mal ein Passwort für mehrere Sachen und das Speichern im Thinkpad für mehr Bequemlichkeit soll ja auch nicht so eine gute Idee sein. Aber ich muss gestehen, dass ich lange Zeit auch für Power-On- und HDD-, sowie für Supervisor- und Master-HDD-PW auch nur jeweils ein gemeinsames Passwort hatte ...

 

[Evilandi666]

[...]
Auf welche Quelle stützt du deine Aussage, man benötige für die Funktion unbedingt die Toolbox?

Edit:
Und wo steht, dass bei den neuen Sandforce-SSDs der Schlüssel mit vom ATA-Passwort abhängt?

@el-sahef ich hab im Prinzip nichts anderes als du sagst behauptet, das ist soweit auch richtig alles. Meine Quelle sind die "Mitarbeiter" im OCZ Forum, überwiegend im englischen. Entschuldige dass ich nicht mehr jeden Nachweis einzeln raussuchen mag, was ich "auf die schnelle" finde, füge ich ein.

Es gibt nur folgendes Problem:

1) Es ist nicht klar welchen Schlüssel die Vertex 2 fürs Verschlüsseln benutzt - irgendwo steht er wird generiert von ihr selbst, aber 100% definiert ist es nicht. Es kann halt auch dumm laufen und es ist ein leerer Schlüssel oder überall der gleiche (=fail).
2) Es ist nicht klar, wie sicher der ATA Passwort Lock ist. Hat man diesen (irgendwie) überwunden, ist die Verschlüsselung nicht hilfreich. Im Endeffekt ist es genauso sicher, eine SSD ohne Verschlüsselung zu haben, es ist genau so sicher bei der SSD, wenn man das ATA Passwort setzt, wie bei einer Vertex 2.
3) Angekündigt wurde, dass man mit dem OCZ Toolkit unter Windows (nur Windows) auf Vertex 2 sowie Vertex 2 Pro ein Passwort setzen kann, welches irgendwie mit dem Key verbunden wird. Oder zumindest den Key ändern kann. Das wurde jetzt aber nur für die Vertex 2 Pro eingeführt. (nachdem es ewig mit "es kommt irgendwann" angekündigt wurde).
4) Das "richtige" verbinden zwischen ATA Passwort und Key kann nur die Vertex 3

So jetzt kurz zu den Nachweisen:
#1 -> Das zweite Post ist von einem OCZ MA -> erwähnt das mit der Toolbox

#2 -> Hier erwähnt ein MA explizit dass man dafür die Toolbox braucht

#3 -> hier auch nochmal

Dann das hier von Sandforce dazu:

3. If an ATA Security password is given to the controller, does this affect the form in which the key is stored?
a. The encryption key is not directly linked to the ATA Security password (or the BIOS password). When the password is established it is used during the challenge process to ensure the user requesting access is authorized. Once the password is authenticated the drive will decrypt the data on the flash, but again that encryption key is internally stored with the drive and not directly linked with the password.

(gut das bestätigt ja was wir wissen)

Und das hier noch: #4

Und wenn ich dann so Sachen sehe wie "We do not disclose the internal details of how the key is stored in order to prevent security issues, but we do disclose it is stored in the flash memory." ... Security through obscurity?

#4 -> Das mit den Enterprise Vertex 2 Drives (ich denke mal er meint damit die "Pro" Serie .. oder gibts noch ne andere Enterprise Version?)

Das Bild hier erklärt die Sache mit der Vertex 3: http://img607.imageshack.us/img607/599/vertex2encryption.jpg

Das Post dazu findet sich hier.

Das hab ich auf die schnelle wiedergefunden - im englischen OCZForum finden sich etliche Debatten dazu. Ich hoffe das genügt vorerst

(Ich hoffe ich habe keine wichtigen Punkte vergessen oder so.)

Achja auch von mir: Mir ist es total Latte ob die Vertex 2 das kann, ich dachte bis vor kurzem dass es nur die Vertex 3 kann, und hab das Zeugs oben eben beim "Einlesen" gefunden. Im Prinzip sollte die ATA Passwort Sache schon sicher sein, aber vollkommen unabhängig davon, ob die Platte/SSD Verschlüsselt oder nicht. (Wenn man von der Vertex 2 ausgeht). Es hängt rein von der Sicherheit des ATA Passwort Mechanismus ab. Schwach ist es von OCZ, da die ganze Sache wohl mal für die Vertex 2 angekündigt war. Im Endeffekt hab ich ja nichts anderes als du behauptet - nur ich finde eben nur das "ATA Passwort" als ziemlich schwach. Es reicht wenn zufällig jemand eine Sicherheitslücke entdeckt - schwupps ist das ganze Ding auslesbar - unabhängig ob es intern verschlüsselt oder nicht. Und ich bin mir nicht sicher, ob ich mich auf Sachen verlassen will, die nicht der Öffentlichkeit zugänglich gemacht werden, weil man Angst vor Sicherheitslücken hat... Daher ist es finde ich erst bei der Vertex 3 "richtig" nutzbar.

 

[el-sahef]

Ach so, jetzt habe ich verstanden, was du meinst. Erstmal vielen Dank, dass du dir so viel Mühe gegeben hast mit den ganzen Posts raussuchen usw.

Aber in zwei Punkten stimme ich mit dir nicht überein:

1)"Im Endeffekt ist es genauso sicher, eine SSD ohne Verschlüsselung zu haben,"
Naja, angenommen, die SSD besäße keine Verschlüsselung, dann könnte jemand auch ohne ATA-Passwort die Flashbausteine umlöten auf eine Platine mit entsperrtem Controller, bei dem kein ATA-Passwort gesetzt wurde. Diese Möglichkeit wird durch die Verschlüsselung verhindert. Zwar ist das wahrscheinlich auch schon ein Aufwand, den ein Dieb nur eingehen würde, wenn es sich für ihn richtig lohnen könnte, aber Firmware knacken ist meiner Meinung nach doch nochmal ne höhere Hürde als fix ein paar ICs umlöten.

2) "Und ich bin mir nicht sicher, ob ich mich auf Sachen verlassen will, die nicht der Öffentlichkeit zugänglich gemacht werden, weil man Angst vor Sicherheitslücken hat... Daher ist es finde ich erst bei der Vertex 3 "richtig" nutzbar. "
Mit dem ersten Teil bin ich einverstanden. Aber wenn man diesen Maßstab anlegt, dann dürfte man eigentlich auch die Vertex 3 oder die Intel nicht als vertrauenswürdig oder sicher ansehen. Selbst wenn der Schlüssel nicht mehr in der SSD (Controller oder verschlüsselt im Flash) abgelegt wird ist die Verschlüsselung immer noch durch Schwachstellen in der Firmware angreifbar und da die Firmware nicht offengelegt wird, kann auch niemand unabhängiges die Implementierung überprüfen. Also muss man auch hier auf die Sicherheit der Firmware vertrauen.

Aber gut, Haarspalterei . Jedenfalls dürfte die Frage damit ausgiebig von allen Seiten beleuchtet worden sein .

 

[Evilandi666]

Ja dem stimm ich beides zu, bei Punkt 2 hatte ich beim Schreiben des Posts auch den gleichen Gedanken - aber ich hab irgendwie mehr Vertrauen darauf dass der Schlüssel und die Verschlüsselung sicher ist als nur das ATA Passwort alleine.* Was dir aber wieder bei Punkt 1) recht gibt

*= Aber um das genau zu wissen, müsste man exakt wissen wo der Key für die AES Sache gespeichert wird. Eventuell ist das ja auch auf einem "dritt" Chip, der versiegelt oder schwer auslötbar ist. (was aber niemand wirklich hindert.). Aber das ist reine Spekulation, daher ist sowohl bei Vertex 2 & 3 die Kiste geknackt sobald man das ATA Passwort geschafft hat.