Servus, ich bin auf der Suche nach einer Hardwareverschlüsselung für SATA-Festplatten. Ich habe folgendes gefunden http://www.enovatech.net/support/download/X-Wall%20MX_FAQ_v4.pdf also den X-Wall MX-256 das wäre ein IC nach meinen Wünschen. Leider finde ich keine Bezugsquelle. Ich bin aber auch für andere Leistungsstärkere IC's zu haben.
Ein sehr interessantes Thema. Warum gibt es so etwas nicht als Komplettlösung; z.B. eine PCIe-Steckkarte mit SATA-Ports, so dass direkt eine betriebssystemunabhängige Verschlüsselung möglich wäre? Bedarf besteht heutzutage doch genug.
Betriebssystemunabhaengig ? Eher nicht. Denn nur das System weiss was wo ist. Die System- und Verwaltungssektoren zu verschluesseln bringt ja wohl nichts. Und wenn man eine Datei kopiert, bringt's ja nichts nochmals drueber zu gehen.
Doch. Genau das wäre ja der Vorteil gegenüber softwarebasierten Systemen wie Truecrypt und Co.: Die Hardware verhält sich nach außen hin völlig transparent, d.h. das Betriebssystem (egal welches) bemerkt von der Verschlüsselung überhaupt nichts. Es wird einfach alles, was über den Bus kommt ver- und entschlüsselt. So etwas wäre die optimale Verschlüsselungslösung, wenn sie denn im Handel erhältlich wäre.
Und man wird trotzdem einen Treiber brauchen um das Passwort/Key oder sonst irgend eine Authentifikation durchzuführen. Und bis der geladen ist, wird alles unverschlüsselt laufen müssen. Bleib nur die Variante, dass sich die PCI-Karte in das BIOS hängt und vor dem Booten noch eine Abfrage macht. Mit all den Nachteilen die sich daraus ergeben. Ich sehe aber nicht den großen Vorteil gegenüber einer Softwarebasierten Lösung so sie ordentlich gemacht ist. (Booten von einem RO Medium usw.) Der Performanceverlust sollte bei den üblichen Anwendungen nicht ins Gewicht fallen. Und - man ist dem Chipentwickler auf Verdei und Verderb ausgeliefert und muss darauf vertrauen, dass er sein Handwerk versteht. Mal eben den Source angucken (lassen) geht nicht. Viele Grüße, Martin L.
Gleicher Tag schrieb: > Betriebssystemunabhaengig ? Eher nicht. Denn nur das System weiss was wo > ist. Die System- und Verwaltungssektoren zu verschluesseln bringt ja > wohl nichts. Es schadet aber auch nicht. Ausserdem will man einem Angreifer so wenig wie möglich verraten, also z.B. auch nicht den Dateinamen oder die Dateigrösse. > Und wenn man eine Datei kopiert, bringt's ja nichts > nochmals drueber zu gehen. Aber sicher doch. Sonst kann man auch ohne den Dateiinhalt zu kennen z.B. nachweisen, dass sich auf zwei verschiedenen Platten die gleiche Datei befindet. Das kann durchaus relevant sein. Andreas
Martin Laabs schrieb: > Und man wird trotzdem einen Treiber brauchen um das Passwort/Key oder > sonst irgend eine Authentifikation durchzuführen. Und bis der geladen > ist, wird alles unverschlüsselt laufen müssen. nicht ganz, ich hatte einige zeit im einsatz AES128 verschlüsselung mit einem hardware key der beim booten in den AES controller reingesteckt werden müsste (gabs extra "USB" anschluss nach aussen herausgeführt). War mir irgendwann zu umständlich da jeder AES128 controller nur eine HDD verschlüsseln konnte (performance probleme) - seit dem benutze ich StrongDisk mit ikey. Lehrmann Michael schrieb: > also den X-Wall MX-256 das wäre ein IC nach meinen Wünschen. > Leider finde ich keine Bezugsquelle. wie viel stk. brauchst du davon ? 10000 oder nur eins ? Wenn eins, dann kauf doch ein fertiges controller und löte es aus - günstiger bekommst du es nicht (böse menschen würden dann irgendein chip wieder drauf löten und zurückgeben). Wenn du 10000 brauchst wird der hersteller vlt welche haben.
>(böse menschen würden dann irgendein chip wieder drauf löten und zurückgeben)
Nicht vergessen, das falsche Label unkenntlich schleifen...
warum nicht einfach das Festplatten password verwenden? Ich weiss das es keine Verschlüsselung ist und das die Daten auf der Platte damit immer noch im klartext vorliegen aber man normalen mitteln kommt man nicht an die Daten ran. Und das schöne ist, man braucht nichts dazu. auserdem hilft eine Festplatten verschlüsselung auch nicht wenn der rechner einmal an ist. Oder fahrt ihr ständig den Rechner runter wenn ihr mal kurz aufs Klo geht?
Peter schrieb: > auserdem hilft eine Festplatten verschlüsselung auch nicht wenn der > rechner einmal an ist. Oder fahrt ihr ständig den Rechner runter wenn > ihr mal kurz aufs Klo geht? nein, aber weder kripo noch verbrecher laufen mit einer USV, und die ex wird auch nicht schlau genug sein :P
Peter schrieb: > warum nicht einfach das Festplatten password verwenden? Ich weiss das es > keine Verschlüsselung ist und das die Daten auf der Platte damit immer > noch im klartext vorliegen aber man normalen mitteln kommt man nicht an > die Daten ran. Und das schöne ist, man braucht nichts dazu. > > auserdem hilft eine Festplatten verschlüsselung auch nicht wenn der > rechner einmal an ist. Oder fahrt ihr ständig den Rechner runter wenn > ihr mal kurz aufs Klo geht? Was ich mich frage: Wie kann der Rechner dann noch Booten? Steht das Paßwort im Plattencontroller und im BIOS des Mainboards? grübel Geht das also nur bei Platten, von denen nicht gebootet wird? Also mehrere Platten im Rechner notwendig?
Thomas R. schrieb: > nein, aber weder kripo noch verbrecher laufen mit einer USV, Täusch dich mal nicht. Sowas gibt es!
Ich halte nicht viel von so einer Hardwareverschlüsselung. Erstens haben sich die Hersteller von solchen Teilen bisher noch nie mit Ruhm bekleckert was die Sicherheitsstandards angeht; zweitens hat jeder PC mehr als genug Rechenleistung übrig um die Verschlüsselung in Software zu machen; und drittens hat eine Verschlüsselung die nur bei ausgeschaltetem Rechner und abgezogenem USB-Schlüssel "scharf" ist sowieso nur einen sehr begrenzten Nutzen, weil die Disziplin für ein regelmäßiges Herunterfahren und Schlüsselabziehen nicht vorhanden sein wird.
Alexander Schmidt schrieb: > Thomas R. schrieb: >> nein, aber weder kripo noch verbrecher laufen mit einer USV, > > Täusch dich mal nicht. Sowas gibt es! Also ich sehe da ein Problem beim Umstöpseln... Halte das für Unfug... Jedenfalls ginge es durchaus sämtliche Inhalte zu verschlüsseln. Das Medium oder Eingabesystem mit dem Entschlüsselungscode könnte direkt an den Encoder-Chip angeschlossen sein. Insofern ist das durchaus interessant... Allerdings habe ich wg Datensicherheit ein Raid 5. Was mache ich da? ;)
Tajas R. schrieb: >>> nein, aber weder kripo noch verbrecher laufen mit einer USV, >> Täusch dich mal nicht. Sowas gibt es! > Also ich sehe da ein Problem beim Umstöpseln... Halte das für Unfug... Immer mehr Rechner haben doch heute die USV bereits eingebaut. Nennt sich Laptop, Notebook, Netbook oder so ähnlich. Ansonsten: prinzipiell ist es schon möglich, im laufenden Betrieb eine Offline-USV (muss Offline sein, da bei einer Online-USV der Ausgang auch bei vorhandener Netzversorgung nicht mit dem Netz synchron ist!) einzuschleifen, wenn der Rechner an einer Mehrfachsteckdose hängt sogar ohne dass man an Kabeln unter Spannung rumschnibbeln muss. Man muss nur peinlich genau drauf achten, dass Phase und Nullleiter nicht vertauscht werden. Oder man geht direkt auf die Niederspannungsseite des Netzteils, da ist es noch einfacher. Andreas
Tajas R. schrieb: >>> nein, aber weder kripo noch verbrecher laufen mit einer USV, >> Täusch dich mal nicht. Sowas gibt es! > Also ich sehe da ein Problem beim Umstöpseln... Halte das für Unfug... Gibt es tatsächlich. Und zwar synchronisiert sich die USV aufs Netz, ähnlich einem Solar-Wechselrichter. Dann gibt es Adapter die man in eine Mehrfachsteckdose Stecken kann und außerdem Krokodilklemmen. Dazu muss man natürlich das unter Strom stehende Kabel abisolieren. Zusätzlich wird eine Mausattrappe angesteckt, die dem System Aktivität simuliert, damit es nicht in den Standby geht. Jedenfalls habe ich schon Fotos von so einem "Kit" gesehen. Ist im robusten Koffer verstaut. Edit: http://www.wiebetech.com/products/HotPlug.php
-So ganz sicher wird es wohl nie werden, solange die Daten zur CPU unverschlüsselt übertragen werden oden im RAM sein müssen. -Bleiben dann noch die Fragen nach Backups und Virenscanner.... -Man sollte auch damit rechnen, daß bisher nützliche, hardwarenahe Tools dann nicht mehr funktionieren.
Abdul K. schrieb: > Was ich mich frage: Wie kann der Rechner dann noch Booten? Steht das > Paßwort im Plattencontroller und im BIOS des Mainboards? grübel > Geht das also nur bei Platten, von denen nicht gebootet wird? Also > mehrere Platten im Rechner notwendig das Bios fragt das Password ab, danach bootet der rechen wie immer.
Peter schrieb: > Abdul K. schrieb: >> Was ich mich frage: Wie kann der Rechner dann noch Booten? Steht das >> Paßwort im Plattencontroller und im BIOS des Mainboards? grübel >> Geht das also nur bei Platten, von denen nicht gebootet wird? Also >> mehrere Platten im Rechner notwendig > > das Bios fragt das Password ab, danach bootet der rechen wie immer. Du meinst, dsa BIOS reicht das eingegebene Paßwort dann an die Platte resp. Verschlüsselungscontroller weiter? For Jahren gab es mal einen Virus, der das meist nicht gesetzte Paßwort der Platte auf irgendwas setzte. Somit war der Rechner dann unbrauchbar. Geht das noch?
Das Problem mit dem Bezug dieser Teile ist nicht ohne. Ich kenne weltweit nur zwei Anbieter, die sowas in fertige Produkte verbauen und nicht nur irgendwelche Phantasieprodukte auf Papier haben. Der erste nutzt einen älten Xwall-MX128 (AES128-EBC)Chip und der andere entwickelt für die NATO. Lenovo baut ein ähnliches Teil, aber das ist erstens zu langsam (nur USB 2.0 = Max 60MB/s Datendurchsatz), zweitens AES128-EBC und bekommt somit keinerlei Sicherheitsfreigaben. Anfragen unter 1000 Stk sind eher aussichtslos (werden nicht beantwortet). Aber wenn du dir das zutraust, in eine Leiterplatte zu gießen, dann meld dich mal bei mir per mail, da kann ich dir weiterhelfen. Achja, das Teil hat bereits FIPS-140-2 (!) und ist damit schonmal signifikant besser als all die ganzen Sicherheitsspielzeuge, die es bislang gab. Der aktuelle MX256C-Chip ist aber ein TQFP mit 0,4mm Pitch(!) Also nicht solche Monster-TFQP, wie man sie von Atmel und Co. kennt. Da wird Selberätzen schon problematisch (Strukturen von 6mil sind dort angebracht). Hab hier auch z.B. einen älteren MX256 im EBC-Mode laufen und der funktioniert prima. ZUr Sicherheit und Interaktion: Das Teil ist vollständig transparent für alle OS, Partitionsprogramme und Tools, etwa wie ein Sata-Kabel. Damit gibt es keinerlei Kompatibilitätsprobleme, ein beliebiges OS oder eine Kombination aus verschiedenen OS zu installieren. Das Teil speichert keinen Schlüssel, der muß beim Start dem Teil von außen zugeführt werden. Ohne Schlüssel gibts keinen Zugriff auf die Platte. Wei der Schlüssel in den Chip kommt, ist dem (Elektronik-)Anwender freigestellt. Auf der Platte selbst werden alle Daten verschlüsselt sektorweise abgelegt. Inkl MBR, Bootsektoren etc. So gibt es auch keine "rootkits" wie Stoned, die Softwarelösungen wie DriveCrypt oder Tryecrypt aushebeln können.
Andy P. schrieb: > Das Problem mit dem Bezug dieser Teile ist nicht ohne. Ich kenne > weltweit nur zwei Anbieter, die sowas in fertige Produkte verbauen und > nicht nur irgendwelche Phantasieprodukte auf Papier haben. Der erste > nutzt einen älten Xwall-MX128 (AES128-EBC)Chip und der andere entwickelt > für die NATO. > Lenovo baut ein ähnliches Teil, aber das ist erstens zu langsam (nur USB > 2.0 = Max 60MB/s Datendurchsatz), zweitens AES128-EBC und bekommt somit > keinerlei Sicherheitsfreigaben. Statt EBC meinst du vermutlich ECB (electronic codebook)? > Anfragen unter 1000 Stk sind eher aussichtslos (werden nicht > beantwortet). Sowas in der Richtung habe ich befürchtet. > Auf der Platte selbst werden alle Daten verschlüsselt sektorweise > abgelegt. Inkl MBR, Bootsektoren etc. So gibt es auch keine "rootkits" > wie Stoned, die Softwarelösungen wie DriveCrypt oder Tryecrypt aushebeln > können. Klingt tatsächlich brauchbar, auf jeden Fall besser als viele Kindergarten-Lösungen von denen ich bisher (auf Heise o.ä.) gelesen habe. Wenn ich persönlich das für irgendwelche kritischen Sachen einsetzen würde, dann würde ich der Lösung natürlich trotzdem nicht vertrauen sondern die HW-Verschlüsselung zwar benutzen aber zusätlich oben drauf trotzdem noch eine Software-Lösung (mit anderer Passphrase logischerweise) aufsetzen, in meinem Fall wohl dm-crypt/LUKS unter Linux.
ECB (Electronic Code Book) würde mich von diesen Produkten wieder abschrecken. Es gibt nur zwei Gründe ECB zu nutzen, 1. zum Testen der Korrektheit der Implementierung und 2. wenn der benutze Schlüssel pro Datenblock oder der Datenblock selber ständig zufällig geändert wird. Jede andere Verwendung vom ECB ist kryptographisch unsicher und erlaubt ne Menge von Angriffen, egal ob AES oder sonstwas benutzt wird. Wenn es aber statt EBC -> CBC (Cipher Block Chaining) heissen sollte, dann sieht das ganze Produkt schon wieder professioneller aus. Eines der größten Probleme die man mit solchen Technologien aus Sicht der Kryptographie lösen muß ist der wahlfreie Lese/Schreibzugriff auf den kompletten Speicher. Die meisten kryptographischen Primitive bauen in ihrer Sicherheit darauf das man mit kontinuierlichen Streams arbeitet. Gruß Hagen
Ja, das soll tatsächlich ECB heißen, (Wechstabenverbuchsler). In der Tat ist ECB leider bei dem freien Xwall-Produkt und dem "Lenovo Thinkpad secure hard drive" Standard. Es ist aber mit dem Xwall auch CBC möglich (ich bastele grad an sowas), obwohl das noch immer aus kryptografischer Sicht nicht der Stein der Weisen ist. (Aber sicher genug, daß die Nato dem Ganzen bis "TOP SECRET" traut) Bei EBC haben alle gleichen Plaintext-Blöcke (AES = 128 bit Blockgröße =16byte lang) auch den gleichen Chiphertext. Ergo: im MBR, der bekanntlich am Schluß drei, vier 16-Byte-Folgen mit 0x00h hat, erscheint im Chipertext dann drei-viermal ein bestimmter 16-byte-String. Daraus hast du ein known-Plaintext Paar und kannst also ohne Probleme erkennen, wenn es im Plaintext einen 16-ByteBlcok gibt, der nur aus 0x00h besteht. Das sagt erstmal nichts über den Inhalt der anderen Chiperblöcke aus. Wenn nur ein Bit in diesem 0x00h-Plaintext auf 1 kippt, dann ist der Chiphertext ein völlig anderer. Damit kann man gerade mal sowas wie ein grobes statistisches Muster der Datenverteilung erkennen, z.B. das Filesystem (FAT fängt von Vorn an, NTFS in der Mitte etc...) Bei CBC wird das Ergebnis der ersten Blockverschlüsselung auf den Plaintext des nächsten ge-XORt und dann verschlüsselt. Ergo: ohne erfolgreiche Dekodierung des ersten Blocks, braucht man an den zweiten nicht zu denken. Das geht im HDD-Bereich solange, bis der Festplattensektor (=512Byte) fertig ist. Damit sehen aber noch immer alle Festplattensektoren im Chiphertext gleich aus, die im Plaintext auch gleich aussehen. Wer also viele Sektoren hat, deren normaler Inhalt 512x 0x00h ist, wird viele Sektoren finden, die den passenden Chiphertext haben. naja, damit kann man dann statistisch grad noch sowas sagen wie: "Im Durchschnitt ist es in der Jahresmitte wärmer als zum Jahreswechsel". Aber selbst da gibt es Gegenmittel :) Genug der grauen Theorie. Ich brauche mal Rat von Leuten, die sich schonmal an Sata-Interfaces rangemacht haben. laut Sata-Spec sind ja die Leitungen entsprechend zu matchen, also 100R Impedanz, 5mil breit, 10mil Abstand, Längendifferenz max 150mil, 4lagig oder mehr, unter den Leitungen ein Massepotential. Wie sieht das bei Zweilagigen Platinen aus? das wären ja dann sowas wie 8 mil Breite und 5 mil Abstand, oder? Welche Stolpersteine gibt es noch? Andy
>Bei CBC wird das Ergebnis der ersten Blockverschlüsselung auf den >Plaintext des nächsten ge-XORt und dann verschlüsselt. Ergo: ohne >erfolgreiche Dekodierung des ersten Blocks, braucht man an den zweiten >nicht zu denken. Und der erste Block wird, wenn man es richtig macht, immer aus Zufall bestehen. Und schwups hast du auch keine Chance mehr für Known Plain Text Attacks auf komplette Sektoren bezogen. Das Problem mit ECB ist eher das man ohne Probleme Blöcke mit einander austauschen kann und so den Inhalt der Nachricht manipuliert, ohne den Cipher überhaupt knacken zu müssen. Gruß Hagen
>> zweitens hat jeder PC
mehr als genug Rechenleistung übrig um die Verschlüsselung in Software
zu machen
Das ist nicht richtig.
Also ich möchte keine Strafe wegen einem raubkopierten Windows kriegen.
Auch nicht, wenn es nur das Windows ist.
Und ja mit einem 100MBit DSL Anschluß, der nicht mehr als ein
herkömmlicher Telefonanschluß kostet, ist eine 12GB Datei in 15 Min
unten. Es wäre unschön, wenn diese zum entpacken nun 15 Min statt 5 Min
braucht, weil der Verschlüsselung-Algorithmus an irgendwelchen Stellen
nicht ganz optimiert ist oder ich keine Lust habe, den Stromsparmodus
dauerhaft ausgeschaltet zu lassen.
Und ja, wenn Google so doof ist und der Meinung ist, das Datum von
Suchergebnissen habe keine Rolle zu spielen, dann Antworte ich auf
Beiträge. Auch dann wenn sie älter als 7 Jahre sind. Ihr dürft gerne
eine Beschwerde an Google richten, aber die wollen ja sowieso nix
ändern.
Es gibt inzwischen den SED (self encrypting drive) Standard, bei dem der Verschlüsselungsteil in Hardware in den Controller integriert ist. Mittlerweile hat jeder namhafte drive Hersteller SATA Platten im Angebot mit SED. Einfach mal bei den Herstellern suchen. Die Spec dazu ist zu finden unter www.trustedcomputing.org unter SED Amsonsten, auch die Fragen zum sicheren Schlüsselmanagement , zur Initialisierung die hier im Thread angesprochen wurden, sind im Standard beschrieben. Zertifizierungsprogramm ist in Vorbereitung. Viel Spass beim Lesen (m.W. insgesamt ca. 500 Seiten) Hans
Hans Brandl schrieb: > in Hardware in den Controller integriert ist Das mag ja ganz toll sein, schützt aber kaum vor dem Abgreifen der Daten während der Bearbeitung in RAM, CPU und Grafik. Helden brauchen auch keine Backups? (Gilt auch noch 2013.)
oszi40 schrieb: > Das mag ja ganz toll sein, schützt aber kaum vor dem Abgreifen der Daten > während der Bearbeitung in RAM, CPU und Grafik. Datenklau bei laufendem Gerät ist eine andere Baustelle. Es geht bei solchen Massnahmen um Datenklau durch Platten/Geräteklau oder Plattenkopie. Der beste Schutz gegen Trojaner nützt nichts, wenn Grenzer oder die Konkurrenz sich kurz mal die unverschlüsselte Platte deines Notebooks ausleihen.
Ich habe hier noch ein paar Muster "X-Wall MX256C", die ich abgeben kann. Bei Interesse, mail an mich. Zum Thema SED: Es ist sehr bedenklich, daß keines der Unternehmen für Datenrettung von Festplatten irgendwelche Probleme beim Auslesen der Daten hat. Weder das SATA-Passwort noch der AES-Schlüssel sollen die Wiederherstellung (Im Klartext!) irgendwie behindern. Logisch: Bios-PW und AES-Schlüssel werden im EEProm auf der HDD-Platine abgelegt. oszi40 schrieb: > Das mag ja ganz toll sein, schützt aber kaum vor dem Abgreifen der Daten > während der Bearbeitung in RAM, CPU und Grafik. Helden brauchen auch > keine Backups? Was du meinst, sind sog. Tempest-Geräte. Nutzen selbst Geheimdienste nicht, zumal sie als bedienbarer PC technisch nicht machbar sind. Und was haben Backups mit der Festplattenverschlüsselung zu tun? A. K. schrieb: > Datenklau bei laufendem Gerät ist eine andere Baustelle Dazu gibt es eine sehr simple technische Lösung bei obigen Chip: Wird die SmardCard mit dem Schlüssel entfernt, wird der Cryptochip zurückgesetzt. Aus die Maus, kein Zugriff mehr. Ergo: Laptop in den StandBy schicken, Smardcard rausziehen, sicher. Vor Aufwecken des Laptops SmartCard wieder einstecken, und weiter gehts. So simpel kann das sein. Andy P.
Andy P. schrieb: > Zum Thema SED: Es ist sehr bedenklich, daß keines der Unternehmen für > Datenrettung von Festplatten irgendwelche Probleme beim Auslesen der > Daten hat. Weder das SATA-Passwort noch der AES-Schlüssel sollen die > Wiederherstellung (Im Klartext!) irgendwie behindern. Logisch: Bios-PW > und AES-Schlüssel werden im EEProm auf der HDD-Platine abgelegt. > Dass die Datenretter die SED Daten im Klartext erhalten stimmt erstens nicht und solch ein System wäre wohl auch nicht vermittelbar. Wenn verständlicherweise das Lesen des Gesamtstandards für das Verständnis zu grosse Probleme verursacht, so empfehle ich das nachfolgende Whitepaper über die Funktionalität, das zwar immer noch sehr anspruchsvoll ist aber zumindest Meinungen durch Wissen ersetzen kann. SED ermöglicht neben der Verschlüssellung eben wesentlich mehr Dienste im Lebenszyklus einer Platte, aber das wichtigste ist eben das es ein offener Standard ist.
Entschuldigung, URL vergessen : http://www.seagate.com/files/docs/pdf/en-GB/whitepaper/self-encrypting-drives-tp600.1-0903gb.pdf
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.