mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Machbarkeit einer Diplomarbeit: Kryptofestplatte. Bitte um Eure Meinung.


Autor: Michael G. (linuxgeek) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Εrnst B✶ (ernst)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Tishima (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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,...

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

Autor: Michael G. (linuxgeek) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: mops (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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??

Autor: Michael G. (linuxgeek) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Frank (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Frank (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Michael G. (linuxgeek) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Εrnst B✶ (ernst)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Michael G. (linuxgeek) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Arc Net (arc)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gibt's mehr oder weniger fertig...
http://www.enovatech.net/products/mx_info.htm

Autor: Marian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Εrnst B✶ (ernst)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Outi Outlaw (outlaw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ....

Autor: Εrnst B✶ (ernst)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Michael G. (linuxgeek) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ;)

Autor: Michael G. (linuxgeek) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Εrnst B✶ (ernst)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Michael G. (linuxgeek) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Michael G. (linuxgeek) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Jens (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Uhu Uhuhu (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: chilipower (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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.

Autor: Michael G. (linuxgeek) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Michael G. (linuxgeek) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Michael G. (linuxgeek) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Arc Net (arc)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mal ein anderer Vorschlag:

Controller mit integriertem Full/Hi-Speed USB Controller und EMI. Am EMI 
hängt dann eine gewöhnliche CompactFlash-Karte...

Autor: Michael G. (linuxgeek) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Uhu Uhuhu (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Michael G. (linuxgeek) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Arc Net (arc)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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?...

Autor: Michael G. (linuxgeek) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Arc Net (arc)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sind die Vorteile gegenüber einer softwareseitigen Verschlüsselung den 
Aufwand denn wert?

Autor: Gast2 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Edward Cardew (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Warum dann nicht eine Krypto SD Karte? Passt ohne Aufwand an einem 
Controller?
Freier Spielraum fuer die "Software" ...

Autor: Red Sector loves Quartex (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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 ?

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Gast2 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: H. P. (h-p)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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.

Autor: Ulrich P. (uprinz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Michael G. (linuxgeek) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Michael G. (linuxgeek) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Michael G. (linuxgeek) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: coldtobi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Michael G. (linuxgeek) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
http://en.wikipedia.org/wiki/Disk_encryption_theory

Du siehst, es gibt auch ohne SATA-Interface noch genug zu tun.

Autor: Michael G. (linuxgeek) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ein embedded System welches du als Storage-Device anbinden kannst sollte 
IMHO fürs erste ausreichen.

Autor: Ulrich P. (uprinz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>> 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

Autor: H. P. (h-p)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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.

Autor: Michael G. (linuxgeek) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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" ;)

Autor: Michael G. (linuxgeek) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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-ge...
http://www.heise.de/security/Verschusselt-statt-ve...

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.