Hallo Forum, da für mich die Zeit meiner Diplomarbeit langsam naeherrueckt wollte ich Euch bitte, die Machbarkeit meiner Idee zu beurteilen. Ich bin auch dankbar, wenn z.B. auf fertige Teilloesungen (z.B. CPU-Modul usw.) hingewiesen wird, da ich in erster Linie Informatiker bin und nicht den Totalueberblick ueber diese Loesungen habe. Es geht um eine Kryptofestplatte, genauer gesagt um ein unabhaengiges Modul hierfur, welches man in ein Gehaeuse einbaut und das eine Menuesteuerung zur Initialisierung und Schluesselgenerierung bietet. Dass ich jetzt nicht alles doppelt schreiben muss einfach mal eine Kopie der Mail an die in Frage kommenden Professoren: ---- diese Mail schreibe ich, um die grundsätzliche Machbarkeit einer solchen Arbeit abzuklären. Es handelt sich um folgende Idee: Entwickelt wird ein offenes (Software und Hardware) Modul, an das eine handelsübliche SATA-Festplatte angeschlossen werden kann. Dieses Modul realisiert einen in Hardware bzw. durch Hardware gestützten Verschlüsselungsalgorithmus (Favorit: AES), welcher die Daten ver- und entschlüsselt. Vorteil: Auf dem Rechner wird keinerlei zustätzliche Software bzw. ein Treiber benötigt. Das Modul sollte dann in ein Gehäuse eingebaut werden und ein Menü über ein Display angeboten werden womit sich ein Schlüssel generieren lässt, welcher dann ebenfalls verschlüsselt auf einer SD-Karte oder einem USB-Stick abgespeichert wird. Diese Karte/Stick ist dann zum Aufsperren der Festplatte erforderlich. Bei der Initialisierung der Platte wird intern ein geheimer Schlüssel erzeugt, mit dem alle weiteren Schlüssel verschlüsselt werden. Dieser Schlüssel kann nicht aus dem System herausgebracht werden, aber mit einer "Paniktaste" gelöscht werden, dies macht dann auch sämtliche Schlüsselkarten unbrauchbar, die Daten sind so für immer verloren. Der Schlüssel sollte auch mehrfachredundant hinterlegt sein, um Datenverluste durch defekten Speicher vorzubeugen. Der Algorithmus wird dann entweder mit einem schnellem Mikrocontroller mit Spezialhardware oder direkt in Hardware (FPGA) implementiert und sollte zumindest theoretisch austauschbar sein, d.h. das System sollte ein Firmware-Update z.B. über eine USB-Schnittstelle anbieten, um etwa bekannt gewordene Schwachstellen zu eleminieren. Die besondere Schwierigkeit liegt natürlich auch in der eigentlichen Schnittstelle und dem SATA-Protokoll, da diese Daten analysiert und ausgewertet werden müssen. Das Modul realisiert also eine transparente Zwischenschicht zwischen PC und Festplatte. Zumindest grundlegend habe ich schon eine Vorstellung wie sich dies realisieren lässt, Detailforschung wäre jedoch dennoch nötig. Eventuell müsste man sich auf andere Schnittstellen (etwa dem klassischem IDE) begrenzen, wenn eine Lösung mit SATA zu aufwändig wird. Durch den enormen Umfang der Arbeit wäre es sicherlich hilfreich wenn man zumindest auf z.B. fertige IP-Cores für den FPGA oder Hardware-Lösungen in den Mikrocontrollern zurückgreifen könnte und auch einen besonderen Augenmerk auf Benutzbarkeit und die tatsächliche Sicherheit des Systems zu legen, z.B. Angriffsszenarien zu analysieren. Bei der Verwendung von beispielsweise einem offenen IP-Core könnte man diesen auch auf seine Brauchbarkeit hin untersuchen und die Funktionsweise in der Arbeit schildern. Meine Frage: Ist so eine Arbeit generell denkbar? Ich will sehr wahrscheinlich übernächstes Semester dann damit beginnen. Ist ein Vorarbeiten denn auch möglich? Bisher existiert wirklich nur die Idee. Falls das Thema aus Ihrer sicht unbrauchbar ist lassen Sie es mich bitte wissen. Vielleicht kann man den Rahmen der Diplomarbeit auch auf ein Teilgebiet dieser Aufgabe beschränken bzw. den Fokus auf einen Teilaspekt der Gesamtarbeit begrenzen? Mir ist auch klar dass hier viel Hardware im Spiel ist aber es gibt sicherlich genug Aspekte aus der Informatik, die hier zum Tragen kommen. --- Fuer mich an dieser Stelle wichtig ist vor allem, ob man sich zumindest teilweise einer fertigen Loesung bedienen kann, vor allem der Teil mit dem SATA-Link (1.5GBit reicht natuerlich). Eventuell eine Bridge auf IDE, da ist dann die Frage: Was ist einfacher zu handhaben oder macht es kaum einen Unterschied? Einen passenden Prozessor oder ein FPGA-Board, welches stark genug fuer die Aufgabe ist braeuchte man natuerlich auch noch. Wichtig ist hier halt auch dass das alles langfristig beschaffbar ist und es muss sich um offene Loesungen handeln, sonst gibt es ein Widerspruch. Also bitte keine kommerziellen Loesungen anbieten. Wo seht ihr aus Hardware-Sicht die Hauptprobleme und Fallstricke? Diese muesste ich dann im Vorfeld nochmals genauer beleuchten um die Machbarkeitsfrage zu klaeren. Ich danke fuer Eure Mitarbeit. Und noch ein Hinweis fuer die Miesmacher und Flamer: Nein ich will nicht dass hier mir jemand die Arbeit abnimmt oder sonstwas, das Thema ist auch noch nicht "im Kasten". Wenn ich aber ein offenes Projekt diesem Umfangs schaffe lebt das sicherlich auch von der Beteiligung anderer. Ich bin fuer konstruktive Hinweise also dankbar. Greets, Michael
Ohje... SATA würd ich mir nochmal überlegen. IDE schon eher, aber das ist am aussterben. Kryptofestplatte mit USB wär wahrscheinlich um Faktor 10 einfacher, allerdings gibts die schon...
Hallo! Machbar ist es, kann ich Dir sagen, da es genausoetwas schon für IDE als Massenprodukt gibt. Und damals als ich mir die IDE Version geholt habe, eine SATA Version in Arbeit war. http://www.gamefreax.com/lshop,showdetail,19987,d,1210084473-19993,1051894381.1051917543,10052,,Tshowrub--1051894381.1051917543,.htm Den eigentlichen Hersteller konnte ich jetzt auf Anhieb nicht finden und das Cryptteil finde ich Grade nicht (son Umzug ist wie ein Wohunugsbrand). gruß, Bjoern
Was es alles schon gibt ist nicht von Relevanz, da ja immer wieder uebelste Schwaechen aufgedeckt wurden in den Teilen und die Teile auch immer wieder gebrochen werden. Die Loesung muss offen sein hab ich oben geschrieben, da ein gewisser Teil der Arbeit auch die Analyse der Sicherheit des Gesamtsystems sein wird, wozu auch die Implementierung des Cryptoschemas zaehlt. Software/Firmware und Schaltplan muessen vollstaendig verfuegbar sein, das ist die Mindestanforderung auch an Teilloesungen. Dass ich hier kein komplett fertiges Produkt suche sollte ja wohl klar sein. Ich bitte die, die nichts sinnvolles beisteuern koennen sich bitte ausnahmsweise mal im Hintergrund zu halten. Besonders bitte ich Posts wie "gibt es doch schon" einfach mal zu unterlassen - danke.
wir sind aber sehr empfindlich. "Software/Firmware und Schaltplan muessen vollstaendig verfuegbar sein, das ist die Mindestanforderung auch an Teilloesungen." und keiner darf schreiben, dass es das schon gibt??
Dass es das schon gibt ist eine triviale Tatsache und kann daher getrost weggelassen werden. Danke. Falls ein Admin mitliest: Ich waere dankbar wenn Du diesen Beitrag auf registrierte User beschraenken koenntest - danke.
Ich denke, dass du den zeitlichen Aufwand unterschätzst. Selbst mit fertigen IP-Cores wird sowas kein Zuckerschlecken, da steckt oft der Teufel im Detail. Frank
Nachtrag: Siehe hier: www.opencores.org da findest du IP-cores, die frei verfügbar sind, oft mit einem Wishbone-Interface. Nimm den AES zur Verschlüsselung und dann strick den Rest drumherum ;) frank
Das ist mir vollkommen klar daher war meine Frage ja auch (an den prof) ob ich Vorarbeiten kann und man den Teil der Diplomarbeit auf einen Detailsaspekt begrenzen kann. Ich denke wenn man zumindest gewisse Komponenten fertig benutzt (CPU/FPGA-Modul z.B.) und einen fertigen Core analysiert sollte das Thema soweit beherrschbar werden dass es dem Umfang einer solchen Arbeit entspricht. Das sind aber Dinge, die man noch im Detail klaeren muss.
Mal auf OpenCores geguckt, AES implementierungen gibts haufenweise (http://www.opencores.org/browse.cgi/filter/category_crypto), SATA hab ich nix gefunden, für IDE gibts zumindest einen Master, aber keinen Slave. den Rest wie LCD, Menusteuerung, Key-Gen usw. erledigt ein kleiner µC Softcore im FPGA gleich mit. Wenns SATA werden muss, würd ich zuerst mal schauen ob es bei den diversen FPGA-Herstellern APPnotes dafür gibt, bzw ob das Direkt an den FPGA geht.
Frank wrote: > Nachtrag: Siehe hier: www.opencores.org > da findest du IP-cores, die frei verfügbar sind, oft mit einem > Wishbone-Interface. Nimm den AES zur Verschlüsselung und dann strick den > Rest drumherum ;) Kenne ich schon die Seite, aber danke fuer den Hinweis. Das waere durchaus eine brauchbare Quelle an die ich gedacht habe. Dumme is nur ich hab mit FPGA noch kaum Erfahrung so dass ich als Alternative vielleicht auch einen schnellen Mikrocontroller in Betracht ziehe - oder vielleicht einen Kryptochip als Zusatzkomponente. Fuer Hinweise diesbezueglich waere ich dankbar.
Die Sache mit dem "Gibt es schon" ist nicht zu verachten. Wenn genau diese Idee schon einmal umgesetzt wurde, dann wird die Arbeit wohl von deinem Betreuer oder Gutachter nicht angenommen werden. Allerdings besteht die Möglichkeit, die Arbeit in eine Art Optimierung umzuwandeln. Da du ja erwähnt hast, dass durchaus auch die Sicherheitsaspekte getestet werden sollen, könntest du dir ja genau dieses Thema vornehmen und daraus eine eigenständige Arbeit machen. So könntest du halt versuchen, die vorliegenden Cryptoschemas zu analysieren, beurteilen und gegebenenfalls optimieren. Ich persönlich denke übrigens, dass alles was du vorgeschlagen hast eh zu viel für eine Diplomarbeit ist ( 6 Monate Zeit oder?). Wie du auch schon selbst geschrieben hast, würde ich mich auf Teilaufgaben spezialisieren und diese auf "Machbarkeit", Relevanz sowie "Gibt es schon" ;) untersuchen. Wenn du allerdings eine komplett andere Herangehensweise an das Problem hast, dann kann damit auch eine Arbeit zu stande kommen. Du musst wohl oder übel ersteinmal die Reaktion deines Gutachters abwarten, also ob er es gut und umsetzbar findet. Wenn du ein Ja von ihm bekommst, dann kannst du anfangen mit Ihm zusammen darüber nachzudenken, was genau du denn nun machen willst. Professoren haben meist ziemlich interessante Ansätze und Ideen ;). Gruß, Marian
Mit nem Schnellen µC... direkt ans SATA wird wohl nicht werden, also SATA->parallel->µC->parallel->SATA oder so in der Art? Evtl mal bei Cypress schauen, die haben µCs die normalerweise in USB-Platten verbaut werden, also evtl welche mit SATA-Interface direkt integriert... Mit soeinem wär das ganze Softwaremässig zu erschlagen, aber halt als USB->crypto->SATA Lösung... ggfs. mit FPGA-Koprozessor für AES.
Wenn du mehr bei Controllern zu Hause bist: der AVR Xmega hat einen AES-Modul an Bord. Habe nur keine Ahnung, ob's dir irgendwie gelingen wird, dafür so viele Muster zu erhalten, dass du das wirklich schon benutzen kannst dafür.
Hmmmm, ham die Platten das net schon STandrd integriert ?? Da gab es doch was, zumindest mit Passwortund bisher soll es noch nicht geknackt worden sein. Wer es testen will, gibt in seinem Notebookbios ein Festplattenpasswort ein und versucht die Platte ml in nem anderen Rechner anzusprechen ....
Mal den oben von arc verlinkten Chip angesehen? Evtl. kannst du damit deine Diplomarbeit umsetzen, und das ganze mehr vom Chip-Design zur Informatik schieben. z.B. der Enova-Chip macht die AES-Bulk encryption, dein µC nebendrann macht Key-Management, Key-Gen, evtl. Benutzerauthentifizierung+Verwaltung mit Public/Secret Keys etc. Zusammen mit einer ausführlichen Analyse sollte das auch für ne Diplomarbeit reichen.
Marian wrote: > Die Sache mit dem "Gibt es schon" ist nicht zu verachten. Wenn genau > diese Idee schon einmal umgesetzt wurde, dann wird die Arbeit wohl von > deinem Betreuer oder Gutachter nicht angenommen werden. Allerdings > besteht die Möglichkeit, die Arbeit in eine Art Optimierung umzuwandeln. Es gibt fast alles schon. Ich rede aber hier nicht von kommerziellen Produkten. Und ich denke die meisten von denen werden zusaetzliche Software am Rechner brauchen, genau da unterscheidet sich meiner. Und soviel gibt es in der Hinsicht uebrigens auch nicht, brauchbares noch weniger. > Da du ja erwähnt hast, dass durchaus auch die Sicherheitsaspekte > getestet werden sollen, könntest du dir ja genau dieses Thema vornehmen > und daraus eine eigenständige Arbeit machen. So könntest du halt > versuchen, die vorliegenden Cryptoschemas zu analysieren, beurteilen und > gegebenenfalls optimieren. Dazu versteht sich aber Quelloffenheit. Bei einem kommerziellem Produkt ist das nicht gegeben. > Ich persönlich denke übrigens, dass alles was > du vorgeschlagen hast eh zu viel für eine Diplomarbeit ist ( 6 Monate > Zeit oder?). Wie du auch schon selbst geschrieben hast, würde ich mich > auf Teilaufgaben spezialisieren und diese auf "Machbarkeit", Relevanz > sowie "Gibt es schon" ;) untersuchen. Wenn du allerdings eine komplett > andere Herangehensweise an das Problem hast, dann kann damit auch eine > Arbeit zu stande kommen. Du musst wohl oder übel ersteinmal die Reaktion > deines Gutachters abwarten, also ob er es gut und umsetzbar findet. Wenn > du ein Ja von ihm bekommst, dann kannst du anfangen mit Ihm zusammen > darüber nachzudenken, was genau du denn nun machen willst. Professoren > haben meist ziemlich interessante Ansätze und Ideen ;). So isses geplant. Ich kann ja schonmal die Grundlagen erarbeiten und nen Prototypen schaffen usw. und die eigentliche Arbeit dann sozusagen auf dem Aufbauen, was ich vorher schon geleistet habe. Fuer 6 Monate ist es wirklich zuviel. > Gruß, > > Marian greets ;)
Jörg Wunsch wrote: > Wenn du mehr bei Controllern zu Hause bist: der AVR Xmega hat einen > AES-Modul an Bord. Habe nur keine Ahnung, ob's dir irgendwie > gelingen wird, dafür so viele Muster zu erhalten, dass du das wirklich > schon benutzen kannst dafür. Die sind noch nicht verfuegbar und wer weiss wann sie es werden. Ich fuerchte auch die Dinger sind viel zu langsam. Ich glaub mehr als ein paar MBit sind mit der Engine nich machbar. Thx anyway.
Outi Outlaw wrote: > Da gab es doch was, zumindest mit Passwortund bisher soll es noch nicht > geknackt worden sein. Das ist keine Verschlüsselung, da weigert sich nur die Plattenelektronik... Schick so ne Platte zu ner Datenrettungsfirma, und du kriegst Postwendend deine Files zurück + ne saftige Rechnung. Nur für die normalsterblichen User ist die Platte mit verlorenem Passwort nachher Schrott... Wenn die Daten aber mehr als ein paar hundert € Wert sind, ist der Schutz hinfällig.
Arc Net wrote: > Gibt's mehr oder weniger fertig... > http://www.enovatech.net/products/mx_info.htm Hey cool der schaut echt gut aus auf den ersten Blick, sogar leicht loetbar. Danke ;) Schau's mir genauer an.
Ernst Bachmann wrote: > Mal den oben von arc verlinkten Chip angesehen? > > Evtl. kannst du damit deine Diplomarbeit umsetzen, und das ganze mehr > vom Chip-Design zur Informatik schieben. > > z.B. der Enova-Chip macht die AES-Bulk encryption, dein µC nebendrann > macht Key-Management, Key-Gen, evtl. > Benutzerauthentifizierung+Verwaltung mit Public/Secret Keys etc. > > Zusammen mit einer ausführlichen Analyse sollte das auch für ne > Diplomarbeit reichen. Japs, sieht schonmal sehr gut aus. Danke.
Respekt an den Threadersteller. Hat nach eigener Aussage wenig Ahnung von Elektronik und will ein SATA-Device und einen SATA-Master implementieren. Dazwischen noch etwas Hard- und Software für eine Verschlüsselung und das alles in 6 Monaten (und alleine?). Ok, ich bin auch nicht der große Elektroniker. Aber so aus dem Bauch heraus würde ich sagen 2..3 Leute mit etwas Grundlagenwissen zum Thema sitzen da mindestens 6..9 Monate bis das zuverlässig läuft. Und das nicht als Nebenbeiprojekt. Mal ein Vorschlag um das ganze ein klein wenig zu entschärfen (auch wenn es das sicher auch schon fertig gibt): Wie wäre ein Hostcontroller für SATA/IDE, der die Verschlüsselung eingebaut hat? Da könnte man ein PCI- oder PCIe-Prototypingboard als Grundlage nehmen und hätte 'nur' noch die Verschlüsselung und den Hostcontroller zum Massenspeicher zu implementieren. Jens
Marian wrote: > Die Sache mit dem "Gibt es schon" ist nicht zu verachten. Wenn genau > diese Idee schon einmal umgesetzt wurde, dann wird die Arbeit wohl von > deinem Betreuer oder Gutachter nicht angenommen werden. Das mag für eine Dis zutreffen. Mit einer Diplomarbeit soll nur nachgewiesen werden, daß der Verfasser eigenständig und auf dem Stand des Wissens eine Arbeit verfassen kann. Innovativität ist dabei zwar schön, aber nicht unbedingt notwendig.
>Es geht um eine Kryptofestplatte, genauer gesagt um ein unabhaengiges >Modul hierfur Gibt es schon - z.B. hier: www.xirguard.com >Dieser Schlüssel kann nicht aus >dem System herausgebracht werden, aber mit einer "Paniktaste" gelöscht >werden, dies macht dann auch sämtliche Schlüsselkarten unbrauchbar, die >Daten sind so für immer verloren. Der Schlüssel sollte auch >mehrfachredundant hinterlegt sein, um Datenverluste durch defekten >Speicher vorzubeugen. Absolut tödlich was du da schreibst. >ich hab mit FPGA noch kaum Erfahrung so dass ich als Alternative >vielleicht auch einen schnellen Mikrocontroller in Betracht ziehe - oder >vielleicht einen Kryptochip als Zusatzkomponente. Fuer Hinweise >diesbezueglich waere ich dankbar. Lass es besser bleiben. Du musst den ATA-Standard von 1980 bis heute durcharbeiten um die Protokolle komplett verstanden zu haben. Dafür brauchst du Jahre.
Michael G. wrote: > Arc Net wrote: >> Gibt's mehr oder weniger fertig... >> http://www.enovatech.net/products/mx_info.htm > > Hey cool der schaut echt gut aus auf den ersten Blick, sogar leicht > loetbar. Danke ;) Schau's mir genauer an. OK, hab mir den Chip jetzt angesehen. Der kann ziemlich viel. Sogar meine Idee mit den Tokens realisiert er. Ich fuerchte nur da bleibt ein bisschen sehr wenig fuer die Arbeit uebrig, da die Engine eine Blackbox ist - das ist ja genau das, was ich nicht will. Sonst kann man ueber die Sicherheit des Gesamtsystems ja nur spekulieren. Weiss jemand ob man den Chip nur als SATA-Interface missbrauchen kann und die eigentliche Verschluesselung an anderer Stelle vornehmen kann?
Jens wrote: > Respekt an den Threadersteller. Hat nach eigener Aussage wenig Ahnung > von Elektronik und will ein SATA-Device und einen SATA-Master > implementieren. Wie gesagt an der Stelle waere es fuer mich als nicht-E-Techniker nicht "tragisch" auf eine fertige Loesung zurueckzugreifen. Der eigentliche Cipher sollte aber nicht in einer Blackbox residieren, da will ich dann schon sehr genau hinsehen. Ich denke der Schwerpunkt der Arbeit sollte irgendwo bei der Implementierung zumindest aber der Analyse und evt. Verbesserung des Ciphers liegen. > Dazwischen noch etwas Hard- und Software für eine Verschlüsselung > und das alles in 6 Monaten (und alleine?). Ok, ich bin auch nicht der > große Elektroniker. Aber so aus dem Bauch heraus würde ich sagen 2..3 > Leute mit etwas Grundlagenwissen zum Thema sitzen da mindestens > 6..9 Monate bis das zuverlässig läuft. Und das nicht als > Nebenbeiprojekt. Naja ich hab das so geplant: Anfangen mit der eigentlichen Arbeit uebernaechstes Semester. Insg. hab ich dann ca. 1.5 Jahre Zeit an der gesamten Arbeit zu werkeln. Ich denke da viele Arbeiten auf einem vorhandenen Projekt (Erweiterung/Verbesserung/...) basieren duerfte das kein Ding der Unmoeglichkeit sein. Klar ist es eine Fleissaufgabe aber ich haette in meiner Abschlussarbeit gerne etwas "Besonderes" gemacht. Ich hab ein paar Profis an der Hand (wir haben ne HW-Abteilung in der Firma), die mir sicher mit den ein oder anderen Aspekt behilflich sein koennen. Den Rest werde ich dann halt zusammentragen und mir ggf. anlernen muessen. Aber ich denk das is an der Stelle normal, was? > Mal ein Vorschlag um das ganze ein klein wenig zu entschärfen > (auch wenn es das sicher auch schon fertig gibt): Wie wäre ein > Hostcontroller für SATA/IDE, der die Verschlüsselung eingebaut hat? > Da könnte man ein PCI- oder PCIe-Prototypingboard als Grundlage > nehmen und hätte 'nur' noch die Verschlüsselung und den Hostcontroller > zum Massenspeicher zu implementieren. Jau das waere ein guter Ansatz, da braeucht ich aber die entsprechenden Komponenten noch ;) Obiger Chip tut ja eigentlich gleich alles, also zuviel. Das Zeug mit den Tokens haette ich auch gerne selber realisiert (= > Jens
Uhu Uhuhu wrote: > Marian wrote: >> Die Sache mit dem "Gibt es schon" ist nicht zu verachten. Wenn genau >> diese Idee schon einmal umgesetzt wurde, dann wird die Arbeit wohl von >> deinem Betreuer oder Gutachter nicht angenommen werden. > > Das mag für eine Dis zutreffen. Mit einer Diplomarbeit soll nur > nachgewiesen werden, daß der Verfasser eigenständig und auf dem Stand > des Wissens eine Arbeit verfassen kann. Innovativität ist dabei zwar > schön, aber nicht unbedingt notwendig. Uhu hat es erkannt. Ich finde hier eine sichere und offene Loesung aber durchaus innovativ. Heute noch etwas wirklich neues und dann brauchbares zu erfinden ist als Einzelperson ja wohl ziemlich unmoeglich auf dem Gebiet, man wird immer zu einem Teil auf eine vorhandene Wissensbasis zurueckgreifen muessen, das gilt auch fuer Dissertationen bzw. fuer Wissenschaften allgemein. Eine Arbeit, in dem man detailliert nachlesen kann wie was warum entschieden wurde und alle Implementierungsdetails zugaenglich sind halte ich gegenueber einer geschlossenen Blackboxloesung als kommerzielles Produkt sehr innovativ. Davon abgesehen dass es gerade hier noch ziemlich wenig brauchbares gibt.
Mal ein anderer Vorschlag: Controller mit integriertem Full/Hi-Speed USB Controller und EMI. Am EMI hängt dann eine gewöhnliche CompactFlash-Karte...
Hmmm.... das ist eigentlich auch eine Idee wert. Das Prob is nur dass diese Karten in der Groesse halt teilweise schon ein bisschen duerftig sind. Wuerde die Sache aber durchaus vereinfachen, das ist wohl wahr.
Michael G. wrote: > Das Prob is nur dass diese Karten in der Groesse halt teilweise schon > ein bisschen duerftig sind. Es ist nur eine Frage der Zeit, bis es die in Größen gibt, die für solche Anwendungen keine Wünsche mehr offen lassen.
Hm... aber wie steht es da dann um die Universelle Einsetzbarkeit? Wenn ich fuer jedes Zielsystem einen Treiber erstellen muss ist es dumm. Optimal waere natuerlich eine Mass-Storage-Emulation an dieser Stelle, dann wird man fuer die gaengigen Systeme keinen Treiber benoetigen. Solange dann die Performance OK ist hoert sich das nach einem guten Kompromiss an.
> teilweise schon ein bisschen duerftig sind. ? Dürftig im Sinne von Geschwindigkeit, Speicher, Preis? 32 GB von Transcend gibt's z.B. für 149 € (s.u.) Dann könnte man u.U. entweder gleich mehrere ala RAID 5/6 ansteuern oder man geht einen Schritt weiter und hängt eine USB-Festplatte an den Controller bzw. an einen externen zweiten USB-Host-Controller. http://www.alternate.de/html/categoryListing.html?cat1=081&cat2=130&cat3=999&sorted=true&manufacturer=true&tn=HARDWARE&l1=Speichermedien&l2=CompactFlash+I&criteriasCount=6&column=1&direction=desc
Arc Net wrote: >> teilweise schon ein bisschen duerftig sind. > ? > > Dürftig im Sinne von Geschwindigkeit, Speicher, Preis? > 32 GB von Transcend gibt's z.B. für 149 € (s.u.) Speicher und Preis ;P Festplatten sind halt konkurrenzlos guenstig. Allerdings koennte man auf der Idee natuerlich aufbauen und wie Du schon sagst ein Verbundystem aus mehreren Medien realisieren. Damit ist dann auch ein sehr hoher Implementierungsaufwand fuer die Firmware verbunden, was das ganze schoen infolastig macht. > Dann könnte man u.U. entweder gleich mehrere ala RAID 5/6 ansteuern oder > man geht einen Schritt weiter und hängt eine USB-Festplatte an den > Controller bzw. an einen externen zweiten USB-Host-Controller. Hm Jau aber bedenke: Auf dem Medium selbst duerfen keinerlei Klartextdaten mehr existieren.
> Hm Jau aber bedenke: Auf dem Medium selbst duerfen keinerlei > Klartextdaten mehr existieren. Sollten nicht, bei der Konfiguration PC->USB->Controller->USB->HD laufen ja nur verschlüsselte Daten zur/von der HD. Was vorher da drauf war interessiert nicht, solange man keine schon verwendete HD verschlüsseln will (ala Truecrypt). Im letzteren Fall kann es z.B. aufgrund des Bad-Block-Managements durchaus sein, dass sich rekonstruierbare Klartextdaten finden lassen.
Sind die Vorteile gegenüber einer softwareseitigen Verschlüsselung den Aufwand denn wert?
Meine ersten Gedanken zum OP waren: Was war doch gleich der Durchsatz von SATA - seit 2007 600 MBytes/s Wieviel Rechenarbeit steckt in der Verschluesselung? Super optimistisch mindestens 10 Takte je Byte ---> Taktfrequenz des uC min 6 Ghz Mal ganz abgesehen von irgendwelchen Protokollsachen fuer SATA ... Denk selbst drueber nach. Gast2
Warum dann nicht eine Krypto SD Karte? Passt ohne Aufwand an einem Controller? Freier Spielraum fuer die "Software" ...
> Sind die Vorteile gegenüber einer softwareseitigen Verschlüsselung den > Aufwand denn wert? Schonmal versucht eine softwareseitig verschlüsselte USB-Festplatte an einen Stand-Alone-DVD-Player anzuschließen, um die ganzen DivX-Filme abzuspielen ?
Gast2 wrote:
> Was war doch gleich der Durchsatz von SATA - seit 2007 600 MBytes/s
Das ist doch aber nur auf der Strippe selbst. Kontinuierlich von
der Scheibe runter wirst du froh sein, wenn du auf 100 MiB/s kommst.
Noch, das kann (und wird) sich ja aendern. Wenn der Durchsatz an der Strippe so spezifiziert ist, dann sollte das Kryptoteil das auch verarbeiten koennen. Gast2
>Sind die Vorteile gegenüber einer softwareseitigen Verschlüsselung den >Aufwand denn wert? Kommt drauf an, gute Software-Verschlüsselungen sind schon ziemlich Rechenintensiv, mit halbwegs modernen Rechnern der DualCore-Generation ist die Pre-Boot-Verschlüsselung zwar einigermaßen erträglich geworden, aber wer eine schnelle Festplatte sein eigen nennt, der spürt bei bestimmten Anwendungen mit intensivem Plattenzugriff in der Regel immer noch einen deutlichen Einbruch der Geschwindigkeit und spätestens beim Einsatz von kaskadierter Verschlüsselung wird eine Hardware dann unverzichtbar. Darüber hinaus ist der Schlüssel bzw. das Passwort bei so einer Hardware-Lösung und einer cleveren Implementierung sehr gut vor dem Ausspähen geschützt. Aber so richtig gut durchdacht scheint mir die Ein-Chip-Lösung auch nicht zu sein: ECB oder CBC sind als Chip-Varianten laut Datenblatt für die AES-Modi Verfügbar, wenn ich das richtig überflogen habe. ECB sollte man für Festplattenverschlüsselung auf gar keinen Fall mehr einsetzen, da frage ich mich was die sich dabei gedacht haben, und bei CBC müsste man mal prüfen, in wie weit eine Vorhersagbarkeit der Iitialisierungs-Vektoren für die einzelnen Sektoren auszuschließen ist, damit Wasserzeichen- Angriffe ausgeschlossen werden können. >Im letzteren Fall kann es z.B. aufgrund des Bad-Block-Managements >durchaus sein, dass sich rekonstruierbare Klartextdaten finden lassen. Eine Kontrolle der S.M.A.R.T.-Attribute (z.B. "Reallocated Sector Count" könnte da eventuell hilfreich sein.
Wenn ich Dich, Michael, mal bei Deinen eigenen Worten nehme, dann ist weder Innovation, noch Perfektion erforderlich. Du sollst zeigen, dass Du zu einer selbstständigen Entwicklung fähig bist und diese verständlich dokumentieren kannst. Lass Dir diese Aussage noch einmal genau durch den Kopf gehen, denn sie steht in krassem Widerspruch zu obiger Anforderung: - Deine Diplomarbeit soll beweisen, dass Du alleine fähig bist, eine dir selbst gestellte oder auferlegte Arbeit eine einem zur verfügung stehdenden Zeitrahmen zu bewältigen. Entschuldige bitte, aber das beeinhaltet auch die Fähigkeit einen Arbeitsaufwand vor Arbeitsaufnahme einschätzen zu können. Nach den vielen Ausführungen hier, muss Dir klar sein, dass dies in dem von Dir angedachten Umfang als ausgeschlossen gilt. Es müsste nun der einzig logische Schritt erfolgen: Reduziere die Aufgabe auf das in der zur verfügung stehenden Zeit machbare, oder versuche Komilitonen für die Arbeit zu gewinnen und sie in mehrere Diplomarbeiten aufzuteilen. Natürlich muss davon auch der zuständige Professor / Prüfungsausschuss überzeugt werden. Für den für Dich geplanten Teilaspekt bedeutet das: Reduziere die Arbeit auf ein Szenario, dass technisch einfach realisiert werden kann und Dir genug Zeit lässt für die eigentliche Aufgabe. Meine bescheidene Idee wäre: Such Dir einen Prozessor / Mikrocontroller der eine weite Verbreitung genießt und für den deswegen eine recht gute Unterstützung durch Literatur und Internet besteht. Reduziere die Ansprüche von einem Gigabit Interface auf ein paar wenige Megabit. Halte Dir damit den Kopf frei für die Hauptaufgaben, die da wären: 1) Verschlüsselungsverfahren und deren Nutzbarkeit, siehe oben Vectorproblematik bei CBC 2) Sicherung gegen (unvermeidbare) Fehler ( Vectorproblematik, Angriff durch Redundanzen bei Sektorrellokationen.) 3) Einbindung und Sicherung von (a-)symmetrischen Schlüsseln und deren Verwaltung. Wenn, Du meinem Rat ein wenig geneigt bist, setze bei einem Baustein ala ATmegaXYU4 an, die bereits in Musterstückzahlen verfügbar sind. Nimm als Speicher eine SD-Card und als PC-Interface USB. Implementiere den AES selber in Software, denn eine nicht von Dir gebaute Hardware verhindert einen lückenlosen Beweis Deiner Arbeit und ihrer Funktionsweise. Erst wenn das alles funktioniert, kommt der leichteste Schritt von allen: Suche Dir als bestandener Dipl.-Ing. kompetente Partner, gieße das ganze in eine Hardware und beschleunige es auf xyGHz und steuere damit Terrabyte große Arrays an und verdiene Dir daran eine goldene Nase. Grüße und viel Erfolg Ulrich
Andreas Schwarz wrote: > Sind die Vorteile gegenüber einer softwareseitigen Verschlüsselung den > Aufwand denn wert? Ja: Schneller, weniger CPU-Auslastung am Rechner und vor allem kein OS-spezifischer Treiber notwendig, was das ganze um einiges universeller einsetzbar macht.
H. P. wrote: > Aber so richtig gut durchdacht scheint mir die Ein-Chip-Lösung > auch nicht zu sein: ECB oder CBC sind als Chip-Varianten laut > Datenblatt für die AES-Modi Verfügbar, wenn ich das richtig > überflogen habe. ECB sollte man für Festplattenverschlüsselung > auf gar keinen Fall mehr einsetzen, da frage ich mich was die > sich dabei gedacht haben, und bei CBC müsste man mal prüfen, in > wie weit eine Vorhersagbarkeit der Iitialisierungs-Vektoren für > die einzelnen Sektoren auszuschließen ist, damit Wasserzeichen- > Angriffe ausgeschlossen werden können. Moment... die Operationsmodi sind zur Uebertragung auf der Leitung gedacht. Es ist natuerlich unsinnig, Operationsmodi mit einem IV zu verwenden, dann koennte man die Daten spaeter nicht mehr rekonstruieren. Ebenso wenig Sinn macht das bei Festplatten, da hier die Entschluesselung von den einzelnen Bloecken (und deren Reihenfolge) abhaengt. Teilweise heisst dann Blockverlust bei einem Operationsmodus der nicht selbstsynchronisierend ist Verlust des gesamten Restdatenstroms. Ergo: Auf der Festplatte liegen die Daten "roh", bei der Uebertragung auf einer Leitung setzt man dann einen Operationsmodi ein, auf den sich aber beide Seiten einigen muessen.
Ulrich P. wrote: > Entschuldige bitte, aber das beeinhaltet auch die Fähigkeit einen > Arbeitsaufwand vor Arbeitsaufnahme einschätzen zu können. Wie Du siehst bin ich gerade dabei eine solche Schaetzung vorzunehmen und das Thema bereits einzuschrumpfen. > 1) Verschlüsselungsverfahren und deren Nutzbarkeit, siehe oben > Vectorproblematik bei CBC Fuer die Daten auf einer Festplatte nicht relevant, siehe oben. > 2) Sicherung gegen (unvermeidbare) Fehler ( Vectorproblematik, Angriff > durch Redundanzen bei Sektorrellokationen.) Korrelationen wird es bei AES nicht geben. Fehlerszenarien muesste man noch genauer untersuchen. > 3) Einbindung und Sicherung von (a-)symmetrischen Schlüsseln und deren > Verwaltung. > > Wenn, Du meinem Rat ein wenig geneigt bist, setze bei einem Baustein ala > ATmegaXYU4 an, die bereits in Musterstückzahlen verfügbar sind. Nimm als > Speicher eine SD-Card und als PC-Interface USB. Implementiere den AES > selber in Software, denn eine nicht von Dir gebaute Hardware verhindert > einen lückenlosen Beweis Deiner Arbeit und ihrer Funktionsweise. Hatte ich sowies vor. Aber nicht verfuegbare Mikrocontroller helfen mir dabei reichlich wenig. Zumal diese wohl auch zu langsam waeren. > Erst wenn das alles funktioniert, kommt der leichteste Schritt von > allen: > Suche Dir als bestandener Dipl.-Ing. kompetente Partner, gieße das ganze > in eine Hardware und beschleunige es auf xyGHz und steuere damit > Terrabyte große Arrays an und verdiene Dir daran eine goldene Nase. Wohl eher nicht. Wird wenn dann alles frei verfuegbar sein. Michael
Michael G. wrote: > Ja: Schneller, weniger CPU-Auslastung am Rechner In Zeiten von Dual- und Quadcores kaum noch relevant. > Ergo: Auf der Festplatte liegen die Daten "roh Was soll "roh" heißen? Irgend einen Operationsmodus musst du verwenden.
Ganz andere Idee: Ein NAS mit Crypto-Accelerator. Beispiel: Thecus N2100 mit Soekris VPN Karte (minipci). (http://www.soekris.com/vpn1401.htm) Die ist seit 2.6.25 im Kernel, jedoch ASFAIK könnte man genau an dieser Stelle (Kernel) die Crypto-API noch verbessern.... Also Info wäre doch das vielleicht was für Dich?
Wie wäre es mit einem ARM-Board auf welches du Linux drauf machst. Das Board sollte zwei USB Anschlüsse oder einen USB und IDE oder SD-Card haben. Über einen USB bindest du dein Board als Storage device an, machst dann die Verschlüsselung und schreibst die Daten auf USB Speicher oder SD..... Das ganze wird zwar nur langsam laufen, du kannst unter linux aber viele Verschlüssselungsverfahren implementieren und untersuchen. Für deine DA sollte das mehr als genug sein. Deine Sachen dann schnell zu machen müssen andere übernehmen, wenn du denen schon das ideale Verfahren bereitgestellt hast. Programmierst du deine Verschlüsselung in C, kann sie auf jedes andere System übertragen werden. Nur um die Schnittstellen müssen sich dann andere kümmern. Wie du gesagt hast, du bist Informatiker und solltest dich nicht monatelang mit der schnellen Hardwareanbindung von Speicher beschäftigen.
http://elmicro.com/de/cobra5485.html mit "Hardwareunterstützung für Verschlüsselung" (was auch immer das ist) und PCI-Bus Interface und Secure Digital / Multi Media Card Interface http://elmicro.com/de/stamp9261.html
Andreas Schwarz wrote:
> Was soll "roh" heißen? Irgend einen Operationsmodus musst du verwenden.
Und wenn ich dann Sektor 2 145 234 einlese lese ich natuerlich erst alle
2 145 233 vorhergehenden ein um Sektor 2 145 234 entschluesseln zu
koennen, was? Aeusserst sinnvoll...
http://en.wikipedia.org/wiki/Disk_encryption_theory Du siehst, es gibt auch ohne SATA-Interface noch genug zu tun.
Das mit dem SATA hab ich im Prinzip sowieso schon verworfen. Aber USB waere dann doch recht nett. Ich wollte halt iwie eine Standalone-Loesung haben, die auf dem eingesetzten PC keine weitere Software benoetigt, falls notwendig von mir aus auch mit einem embedded-System. Michael
Ein embedded System welches du als Storage-Device anbinden kannst sollte IMHO fürs erste ausreichen.
>> Entschuldige bitte, aber das beeinhaltet auch die Fähigkeit einen >> Arbeitsaufwand vor Arbeitsaufnahme einschätzen zu können. > Wie Du siehst bin ich gerade dabei eine solche Schaetzung vorzunehmen > und das Thema bereits einzuschrumpfen. Sehr gut, sehr gut, damit ist der Erfolg eindeutig eher erreichbar. >> 3) Einbindung und Sicherung von (a-)symmetrischen Schlüsseln und deren >> Verwaltung. >> >> Wenn, Du meinem Rat ein wenig geneigt bist, setze bei einem Baustein ala >> ATmegaXYU4 an, die bereits in Musterstückzahlen verfügbar sind. Nimm als >> Speicher eine SD-Card und als PC-Interface USB. Implementiere den AES >> selber in Software, denn eine nicht von Dir gebaute Hardware verhindert >> einen lückenlosen Beweis Deiner Arbeit und ihrer Funktionsweise. > Hatte ich sowies vor. Aber nicht verfuegbare Mikrocontroller helfen mir > dabei reichlich wenig. Zumal diese wohl auch zu langsam waeren. Auch wenn die CPU schmalbrüstig ist, zugegeben, aber sie sind bereist in Mustern verfügbar und jeder wirklich interessiert kann sie haben. Bis Deine Diplomarbeit spruchreif ist, werden auch die ATXmega mit eingebauter DES/AES Engine ebenso, wie die *U4 CPUS in großen Stückzahlen verfügbar sein. Aber meine Nachredner haben recht, eine Plattform auf Basis eines AT91SAM9xxx mit USB-Host und USB-Device Interfaces und einem Linux als Betriebssystem bieten dort noch eine ganze Menge Potential. Da Du lobenswerter Weise eine offene Software mit offenen Verfahren entwickeln willst, wäre eine offene Plattform ala Linux sicherlich eine gute Basis. Das würde aber auch gelten, wenn Du Dies auf einem AT91SAM7 mit USB und Basis Nut-OS oder einem anderen Micro-Kernel oder Flat-Memory-Kernel entwickelst. Gruß, Ulrich
>Es ist natuerlich unsinnig, Operationsmodi mit einem IV zu verwenden, >dann koennte man die Daten spaeter nicht mehr rekonstruieren. Da hast Du glaube ich etwas falsch verstanden! Selbstverständlich muss der IV der Krypto-Funktion bekannt sein und dieser Modus war vor nicht allzulanger Zeit sogar die Grundlage von verschiedenen Festplatten-Verschlüsselungs-Programmen wie z.B. Truecrypt. Da wurde wenn ich mich recht erinnere bei CBC zunächst die Funktion... Klartext(Sektornummer) XOR IV(Sektornummer) ...durchlaufen. Für jeden Sektor gab es also einen individuellen IV, der allerdings für einen Angreifer ohne Kentniss des Schlüssels nicht zufälllig, sondern vorhersagbar war und damit rein theoretisch die Möglichkeit bot, mehrere aufeinanderfolgende Klartextblöcke so zu wählen, dass die XOR-Funktion der nachfolgenden Kryptofunktion trotz fortlaufender Sektornummer immer den gleichen Input lieferte. CBC ist nun mal per Definition eine Kryptofunktion, die beim ersten Block mit einem IV arbeitet, da kein vorhergehender Block existiert. >Ebenso wenig Sinn macht das bei Festplatten, da hier die >Entschluesselung von den einzelnen Bloecken (und deren Reihenfolge) >abhaengt. Teilweise heisst dann Blockverlust bei einem >Operationsmodus der nicht selbstsynchronisierend ist Verlust des >gesamten Restdatenstroms. Reines CBC mit einer fortlaufenden Verkettung über die ganze Festplatte wäre in der Tat Schwachsinnig, aber sektorbasiert und nur für den ersten Datenblock eines Sektors macht ein individueller und ohne Authentifizierung nicht vorhersagbarer IV bei CBC im Grunde genommen schon Sinn: damit gleiche Klartext- Blöcke vollkommen unterschiedliche Ciphertext-Blöcke ergeben und ein Angreifer nicht die Möglichkeit hat, durch geschicke Wahl von Klartext-Blöcken identische Ciphertext-Blöcke zu erzeugen. Ich habe das Datenblatt dieses Krypto-Chips wirklich nur kurz überflogen und vermute daher - nein, ich hoffe vielmehr - , dass es irgendeine Krypto-Funktion in diesem Chip geben wird, die sich um derartige Aspekte in Echtzeit kümmert, also z.B. die Sektor- Nummer in Kombination mit einem dem Angreifer unbekannten Salt durch eine sichere Hash-Funktion jagt und dieses Ergebnis (ESSIV) dann als Grundlage für den ersten Block eines Sektors verwendet.
Ulrich P. wrote: >> Wie Du siehst bin ich gerade dabei eine solche Schaetzung vorzunehmen >> und das Thema bereits einzuschrumpfen. > > Sehr gut, sehr gut, damit ist der Erfolg eindeutig eher erreichbar. Ich hoffe es... > Auch wenn die CPU schmalbrüstig ist, zugegeben, aber sie sind bereist > in Mustern verfügbar und jeder wirklich interessiert kann sie haben. Bis > Deine Diplomarbeit spruchreif ist, werden auch die ATXmega mit > eingebauter DES/AES Engine ebenso, wie die *U4 CPUS in großen > Stückzahlen verfügbar sein. Hm hm aber ich hab da bei Atmel welche Anfordern wollen da kam bloss soviel wie "wenden Sie sich an Ihren Distributor". Naja... und dann brauch ich ja auch noch Programmiergeraet und toolchain das is doch alles noch nicht spruchreif. Und nochmal, der AVR (auch mit 32MHz) waere hier zu schwach. Dass er eine Krypto-Engine hat weiss ich das waere aber ohnehin nicht zu verwenden an dieser Stelle da es eine Blackbox ist. > Aber meine Nachredner haben recht, eine Plattform auf Basis eines > AT91SAM9xxx mit USB-Host und USB-Device Interfaces und einem Linux als > Betriebssystem bieten dort noch eine ganze Menge Potential. Da Du > lobenswerter Weise eine offene Software mit offenen Verfahren entwickeln > willst, wäre eine offene Plattform ala Linux sicherlich eine gute Basis. > Das würde aber auch gelten, wenn Du Dies auf einem AT91SAM7 mit USB und > Basis Nut-OS oder einem anderen Micro-Kernel oder Flat-Memory-Kernel > entwickelst. Ich frage mich ob der AVR32 AP7000 genug Power fuer sowas hat... das haengt sicher auch bisschen davon ab wie effizient man den Algorithmus implementiert. Dinge wie z.B. das modulare Inverse kann man sich in Tabellen halten. Selbiges gilt fuer Operationen wie z.B. die Multiplikation, die noch recht rechenaufwaendig sind. Genug Speicher waere auf nem Board wie z.B. dem Grasshopper auf jeden Fall vorhanden, der ist mit seinen 64M ja sehr ueppig ausgestattet. Vorteil am Hopper waere dass er selber auch frei ist und Linux sowieso. H-P: Hab schon bissel hingelesen in die Richtung. Aber nochmal ich denke nicht dass ich fertige oder blackbox-Loesungen verwenden kann, da fehlen mir saemtliche Analysemoeglichkeiten und ueber die Sicherheit koennte man nur spekulieren. Im Ernstfall muesste man fuer sowas z.B. einen FPGA "animieren" ;)
Noch kurz zu dem Thema "offen" im Zusammenhang mit Krypto: http://de.wikipedia.org/wiki/Kerckhoffs_Prinzip Und noch zwei aktuelle Links zu den tollen Loesungen, die es bisher so gibt: http://www.heise.de/security/Sichere-USB-Sticks-geknackt--/artikel/103942 http://www.heise.de/security/Verschusselt-statt-verschluesselt--/artikel/103093
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.