Ich suche nach einer Möglichkeit, Daten, vom PC auf Platte geschrieben werden, in Echtzeit zu verschlüsseln. Dies soll nicht in Software geschehen und programmierbar sein, damit jeder Nutzer seine eigene Codierung verwenden kann. Es soll mehr oder weniger nicht zu knacken sein, wenn die Platten verloren gehen. Daher müsste das Dateformat auch einstellbar und nicht erratbar sind. Ich habe mich mit AES-Codierung befasst und würde gerne eine Hardware haben, die es gestattet, eine externe Festplatte auszulesen, sobald man einen Code eingegeben hat. Jeder User kann damit SEINE Platte mit SEINEM Code schützen. Gibt es dafür Lösungen, Chips oder müsste man das bauen? Wie könnte das aussehen?
Ja, eine tolle Idee. Mach mal. Wo lagen die Probleme ? Eine Frage der Skalierbarkeit. Du kannst mit einem Arduino anfahren und ein paar kByte pro Sekunde durchlassen. Oder mit etwas dickerem. Eine Frage der Ansprueche. Nach oben offen.
Nette Idee! Und wem gehören dann die Verwaltungsinformationen, die so eine Festplatte benötigt, um Ihre Sektoren/Inodes/Files/Partitionen zu verwalten? Wer verschlüsselt diese Infos? Nichts desto trotz - möglich ist's bestimmt. Bin sehr auf die Antworten der "Wissenden" gespannt.
Martin K. schrieb: > Ich suche nach einer Möglichkeit, Daten, vom PC auf Platte geschrieben > werden, in Echtzeit zu verschlüsseln. Gibt es schon, nennt sich TrueCrypt, VeraCrypt, BitLocker etc. Martin K. schrieb: > Dies soll nicht in Software geschehen und programmierbar sein, damit jeder > Nutzer seine eigene Codierung verwenden kann. Warum nicht in Software? Was meinst du mit "Codierung"? Martin K. schrieb: > Es soll mehr oder weniger nicht zu knacken sein, wenn die Platten > verloren gehen. 100%ige Sicherheit gibt es nicht. > Daher müsste das Dateformat auch einstellbar und nicht erratbar sind. Wieso? Wenn man eine geeignete Chiffre einsetzt sind die verschlüsselten Daten von Zufall nicht mehr zu unterscheiden, damit ist das Datenformat implizit nicht erratbar. Martin K. schrieb: > Ich habe mich mit AES-Codierung befasst AES ist keine Kodierung, AES ist eine Blockchiffre mit 128, 192 oder 256 Bit Schlüsseln, die noch dazu in diversen Modi arbeiten kann (ECB, CBC, CTR, GCM, OFB, XTS etc.). > und würde gerne eine Hardware haben, die es gestattet, eine externe > Festplatte auszulesen sobald man einen Code eingegeben hat. Jeder User > kann damit SEINE Platte mit SEINEM Code schützen. Was soll ein "Code" sein? Davon ab, genau das bieten dir BitLocker, VeraCrypt und TrueCrypt. Ganz im ernst, ich kann nur dazu raten etablierte Lösungen zu verwenden. Nur weil man mal irgendwo aufgeschnappt hat, dass AES sicher sei heißt das noch lange nicht, dass man nun einfach die Chiffre implementieren kann und damit ist alles in Butter. Das haben in der Vergangenheit schon genügend Leute und Firmen versucht und sind damit gewaltig auf die Nase gefallen. https://www.heise.de/security/artikel/Verschusselt-statt-verschluesselt-270058.html https://www.heise.de/security/meldung/Externe-Festplatten-mit-Verschluesselung-knackbar-3289530.html
:
Bearbeitet durch User
Moin, Martin K. schrieb: > Wie könnte das aussehen? Du nimmst ein FPGA mit entsprechenden SerDes-Links nach aussen, die konfigurierst du als SATA Links, implementierst dein AES und was Festplatten sonst noch so sprechen und haengst das zwischen deinen schwindeligen, Viren- und Malwareverseuchten PC und deine Festplatte - schon isses fertig. Duerfte etwas komplexer werden, als ein 555-Blinker oder ein Badewannenfuellstandsmelder, aber hey: Viel Feind - viel Ehr'. Gruss WK
Martin K. schrieb: > Ich suche nach einer Möglichkeit, Daten, vom PC auf Platte geschrieben > werden, in Echtzeit zu verschlüsseln. Dies soll nicht in Software > geschehen und programmierbar sein, damit jeder Nutzer seine eigene > Codierung verwenden kann. LOL. Mindestens 100MB/s sollen verschlüsselt werden: 1. Zwei Zugriffe, XOR. 2. Zwei Zugriffe, auswechseln. 3. Shift, vier Zugriffe. 4. Zwei Zugriffe, combine. 5. Zwei Zugriffe, addieren. Und noch einmal Schritte 2, 3 und 5. Vorausgesetzt, der Rest geht mit DMA. Wie und womit willst du das schaffen, wenn du nicht mal genau weisst, was AES ist ? Vergiss es ruhig, ohne spezielle Chips wird das nichts vernünftiges. Oder man macht es trotzdem mit einem geeignetem Programm, wie es auch Tausende von Leuten tun. P.S. Der obige Text hat etwa 500 Bytes, XOR jeden beliebigen Text damit (nur XOR, ohne schieben, auswechseln und sonstigem Kram) und lass die Experten diesen Text entschlüsseln. Was glaubst du, wie lange es dauert, wenn überhaupt? Und wenn du von dem obigen Text nur die Hälfte nimmst, XOR damit und dann noch einmal XOR mit der zweiten Hälfte...
:
Bearbeitet durch User
der wunsch des TO ist wahrscheinlich umsetzbar - wenn ich richtig verstanden habe was er will - nur glaube ich nicht, das es sowas fertig am markt gibt. quasi ein proxy zwischen rechner und platte, mit "code" (/passwort) eingabefeld, der r/w datenblockoperationen zwischen rechner und platte ver- und entschlüsselt. ohne zu wissen wie, halte ich das für machbar, aber wie gesagt: geben wirds sowas nicht. eine lösung wäre ein extra rechner, quasi sowas wie eine NAS, selbst aufzusetzen. der übernimmt dann das ver- und entschlüsseln, und gibt die daten via netzwerk weiter (nicht USB, da kein USB-client anschluss). problem ist, das kleine einplatinenrechner zwar wegen ihrer größe geeignet wären, aber (afaik) kein AES-NI unterstützen, was sich negativ auf die verschlüsselungsleistung auswirkt. mäh… alles mist. ich würde den einfachsten weg gehen: LUKS und/oder encfs - was soll das eigentlich heißen, "soll nicht in software geschehen"? warum denn nicht?
Hinweis zur Terminologie: Verschlüsseln: Information (Klartext) nach einem festgelegten Algorithmus (cipher) parametrisiert durch einen Schlüssel so verwürfeln (ergibt cipher text) , daß dieser nur mit einem passenden Schlüssel (bei symmetrischer Verschlüsselung ist das der selbe wie zum Verschlüsseln) wieder in den Klartext umgewandelt werden kann. Code: Abbildung von Sschverhalten oder Information in einem Zeichensystem. Beispielsweise ASCII zur Abbildung von Buchstaben, Ziffern etc. in Bitmustern. Bruce Schneier (ehemals der große Cryptoguru) empfiehlt nicht, sich diese Dinge selbst zu entwickeln, weil dabei regelmäßig Mist rauskommt. Gute Verfahren sind demnach solche, die von der Community ausgiebig geprüft wurden. Regelmäßig ist die Schwachstelle, an der Verschlüsselung in der Praxis scheitert, nicht dei Verschlüsselung (-shardware, -software, ...) sondern die Schlüsselverwaltung und die Umgebung der Verschlüsselung. Zur Echtzeit: Ich habe noch nie Echtzeitanforderungen im Zusammenhang mit Kryptographie gesetzt gesehen. Wenn's um weiche Echtzeitanforderungen geht, würde ich eigentlich erwarten, daß gängige Implementierungen hinreichend deterministisch sind. Wenn's dazu Erkenntnisse gibt, ganz besonders falls harte Echtzeit gefordert ist, bitte unbedingt posten.
Wenn Du das erfinden willst, mußt Du dich (mindestens) um dieses https://www.google.com/patents/US7386734 Patent rumarbeiten. Da sind schon andere draufgekommen.
Kauf einfach jedem User eine SSD. Die machen schon AES in Hardware mit vollen 600MB/sec. Ohne extra Software. Sata-passwörter vergeben, fertig. Der Firmware muss man halt Vertrauen. Und Echtzeit ist mit SSD schwierig, wegen GC.
Ich werf hier erstmal die Vorlesungen zu "Einfuehrung in die Kryptographie" der RUB von Prof. Paar in den Raum. Vielleicht sollte sich der TO erstmal damit beschaeftigen. Die Vorlesungen gibt es auf Youtube. Introduction to Cryptography https://youtu.be/HuKT-_PzTIc?list=PLoJC20gNfC2gAB-eg7oaUTheB_JgQY4-q
Kaj schrieb: > Ich werf hier erstmal die Vorlesungen zu "Einfuehrung in die > Kryptographie" der RUB von Prof. Paar in den Raum. Vielleicht sollte > sich der TO erstmal damit beschaeftigen. Die Vorlesungen gibt es auf > Youtube. Selbst das wird nicht viel bringen, denn: Alexander T. schrieb: > Regelmäßig ist die Schwachstelle, an der Verschlüsselung in der Praxis > scheitert, nicht dei Verschlüsselung (-shardware, -software, ...) > sondern die Schlüsselverwaltung und die Umgebung der Verschlüsselung.
Martin K. schrieb: > Dies soll nicht in Software > geschehen Dann benutze doch die AES-Hardwareengine deines CPUs. jeder moderne CPU kann das heute schon. http://www.golem.de/1007/76583.html
Auch die bekannten Softwares machen heutzutage keine Softwareverschlüsselung mehr.. Es ist Softwaregersteuerte Hardwareverschlüsselung mit allen Vorteilen einer Hardwareverschlüsselung. Ich sehe da keinen Vorteil wieso man das Hardwaretecnisch haben möchte, okay vielleicht embedded.. dann muss man aber sowieso tief eingreifen. Ich habe mal eine PCIToSata Karte gefunden als zuerst nur wenige CPUs Instruktionen für Hardwareverschlüsselung bereitstellten.
Marc V. schrieb: > Mindestens 100MB/s sollen verschlüsselt werden (schnipp) > Wie und womit willst du das schaffen, wenn du nicht mal genau > weisst, was AES ist ? > > Vergiss es ruhig, ohne spezielle Chips wird das nichts vernünftiges. Ein Glück, daß mein PC das nicht weiß:
1 | ~ $cryptsetup benchmark |
2 | ... |
3 | # Algorithm | Key | Encryption | Decryption |
4 | aes-cbc 128b 749.1 MiB/s 3242.0 MiB/s |
5 | serpent-cbc 128b 103.1 MiB/s 640.1 MiB/s |
6 | twofish-cbc 128b 209.6 MiB/s 407.1 MiB/s |
7 | aes-cbc 256b 552.9 MiB/s 2481.5 MiB/s |
8 | serpent-cbc 256b 104.2 MiB/s 641.0 MiB/s |
9 | twofish-cbc 256b 210.9 MiB/s 406.5 MiB/s |
10 | aes-xts 256b 2838.3 MiB/s 2807.7 MiB/s |
11 | serpent-xts 256b 635.1 MiB/s 616.6 MiB/s |
12 | twofish-xts 256b 394.7 MiB/s 402.6 MiB/s |
13 | aes-xts 512b 2183.7 MiB/s 2174.9 MiB/s |
14 | serpent-xts 512b 638.6 MiB/s 622.0 MiB/s |
15 | twofish-xts 512b 395.9 MiB/s 402.6 MiB/s |
Keiner der Algorithmen ergibt weniger als 100MB/s. Natürlich verwendet die AES-Implementierung die Hardware-AES Einheit in der Core-i7 CPU. (wer es nicht kennt: cryptsetup ist das Admin-Tool für den dm-crypt Layer, der die Plattenverschlüsselung unter Linux besorgt) @TE: das macht man heutzutage selbstverständlich in Software. Ist flexibler, sicherer und am Ende sogar schneller.
Axel S. schrieb: > @TE: das macht man heutzutage selbstverständlich in Software. Ist > flexibler, sicherer und am Ende sogar schneller. Nicht zu vergessen: bei einem sicherheitsrelevanten Bug kann man die Software in der Regel schneller aktualisieren als die Hardware.
:
Bearbeitet durch User
Axel S. schrieb: > @TE: das macht man heutzutage selbstverständlich in Software. Ist > flexibler, sicherer und am Ende sogar schneller. ist es dann noch in Software? > Natürlich verwendet > die AES-Implementierung die Hardware-AES Einheit in der Core-i7 CPU. also ist es doch in Hardware.
Peter II schrieb: > Axel S. schrieb: >> Natürlich verwendet >> die AES-Implementierung die Hardware-AES Einheit in der Core-i7 CPU. > > ist es dann noch in Software? > also ist es doch in Hardware. Bestimmte Grundfunktionen sind immer in Hardware. Ganz früher konnten CPU bloß addieren und immer nur um ein Bit schieben. Dann kamen Barrel-Shifter und Multiplikation in Hardware. Und CRC und nun halt auch AES. Aber von allein tut die AES-Einheit nichts. Ganz davon abgesehen, daß die Verschlüsselung selber nur ein kleiner Baustein ist.
Am besten wäre doch mal ein ähnliches Beispiel.. Videos konvertieren.. Früher haben Rechner mehrere Stunden gebraucht um über die CPU Große Videos zu konvertieren. Dann hat sich ein Grafikkartenhersteller gedacht "Eigentlich ist unsere GPU garnicht soweit davon entfernt bzw. praktischer" Also noch nen paar Instruktionen in die GPU eingebaut welche sonst die Software über die CPU rechnet. Glaub AMD war das, die haben dazu noch ein "Konverter Tool" das die Grafikkarte vernünftig bedient hat entwickelt.. letztendlich schickt man fast nur das Video Byte für Byte rein und am anderen Ende kommt es Byte für Byte fertig raus. Das ganze halt damals 10 mal schneller als die CPUs und nicht so Ressourcen fressend. Das gleiche ist die AES Erweiterung in den CPUs. Daten rein -> Daten fertig raus, quasi ohne CPU Leistung.
Axel S. schrieb: > Bestimmte Grundfunktionen sind immer in Hardware. Ganz früher konnten > CPU bloß addieren und immer nur um ein Bit schieben. Dann kamen > Barrel-Shifter und Multiplikation in Hardware. Und CRC und nun halt auch > AES. Aber von allein tut die AES-Einheit nichts. Ganz davon abgesehen, > daß die Verschlüsselung selber nur ein kleiner Baustein ist. schon klar, aber dann darf man nicht schreiben das die Verschlüsselung in Software gemacht wird - das stimmt so nicht.
Dergute W. schrieb: > Du nimmst ein FPGA mit entsprechenden SerDes-Links nach aussen, die > konfigurierst du als SATA Links, implementierst dein AES und was > Festplatten sonst noch so sprechen und haengst das zwischen deinen > schwindeligen, Viren- und Malwareverseuchten PC und deine Festplatte - > schon isses fertig. Du wirst lachen, sowas hatte ich im Sinn. Die anderen Ratschläge Bitlocker etc sind alle Software und scheiden aus. Die Idee ist, bei USB 3.0 auf ein FPGA-board zu gehen, in das der user nach dem Hochfahren seinen Code eingibt, um es aktiv zu machen. Die Daten werden geprüft, ob sie den Kriterien entsprechen, wodurch sichergestellt wird, dass es sich um plausible Werte handelt und nicht etwa um Viren oder verfälschte Werte. Die Daten liegen im Übrigen an mehreren Stellen im Quellsystem vor und können so plausibilisert werden, ob sie zuvor verändert wurden. Das wäre der Hauptaspekt. Die Frage bliebe noch, wie man ein RAID-System aufzieht, damit nicht eine defekte Platten den Vorgang unterbricht.
Martin K. schrieb: > Dergute W. schrieb: > >> Du nimmst ein FPGA mit entsprechenden SerDes-Links nach aussen, die >> konfigurierst du als SATA Links, implementierst dein AES und was >> Festplatten sonst noch so sprechen und haengst das zwischen deinen >> schwindeligen, Viren- und Malwareverseuchten PC und deine Festplatte - >> schon isses fertig. > > Du wirst lachen, sowas hatte ich im Sinn. Die anderen Ratschläge > Bitlocker etc sind alle Software und scheiden aus. Welches (heutige) Betriebssystem hat den zu einem Zeitpunkt nur EINEN Benutzer, der auf die Platte zugreift? Und da Du ja keine SW-Lösung willst muss Deine HW wissen welcher Benutzer gerade zugreift. Das aber auch noch OS-unabhängig, sonst fallen z.B. alle VMs mit anderen OS schon mal hinten runter. Wie willst Du anstellen? /regards
Wenn man einen 256bit-XOR-Schlüssel nimmt und sicherheitshalber in zwei Runden verschlüsselt, reicht auch ein simples USB-Kabel für 100MB/s aus.
Etwas spannender wird es, wenn man es mit Arbeitsgruppen unterschiedlicher Mitgliedschaft zu tun hat. Also Files so verschlüsselt werden sollen, dass mehrere Leute darauf Zugriff haben - aber je nach File/Verzeichnis/Share nicht immer die gleichen.
Moin, Klingt alles supi. Martin K. schrieb: > Die Frage bliebe noch, wie man ein RAID-System aufzieht, damit nicht > eine defekte Platten den Vorgang unterbricht. Was ist das fuer 'ne Frage? Das ist doch der Witz am RAID - das R steht doch fuer redundant iirc. Musst halt ein etwas dickeres FPGA nehmen mit mehr SerDes-Links, dann kannst du auch mehrere SATA-Platten anflanschen. Daran wirds doch sicher nicht scheitern. Gruss WK
Martin K. schrieb: > Die Idee ist, bei USB 3.0 auf ein FPGA-board zu gehen, in das der user > nach dem Hochfahren seinen Code eingibt, um es aktiv zu machen. Die > Daten werden geprüft, ob sie den Kriterien entsprechen, wodurch > sichergestellt wird, dass es sich um plausible Werte handelt und nicht > etwa um Viren oder verfälschte Werte. TPM, UEFI, Secure Boot. FPGA: Würde ich mir noch mal überlegen... und ob die heutigen besser sind https://www.emsec.rub.de/research/projects/BitEnc/ > Die Frage bliebe noch, wie man ein RAID-System aufzieht, damit nicht > eine defekte Platten den Vorgang unterbricht. Ansonsten: Gibt's fertig von bspw. Enova: http://www.enovatech.net/mx+_info.php Davor oder dahinter dann einen üblichen RAID-Controller
Martin K. schrieb: > Die Frage bliebe noch, wie man ein RAID-System aufzieht, damit nicht > eine defekte Platten den Vorgang unterbricht. http://www.reichelt.de/?ARTICLE=111287 Bis zu 5 Platten dran, Raid 1 oder 5 einstellen und los. Gruß Jobst
Also ich hab den Eindruck, hier haben viele nur mal was von Kryptografie in der Tageszeitung gelesen. ein Beispiel: Anonymous schrieb: > Es ist Softwaregersteuerte > Hardwareverschlüsselung mit allen Vorteilen einer > Hardwareverschlüsselung. Hat denn außer dem TO k(aum )einer begriffen, daß ein HW-crypter weder das Passwort noch die Rundenschlüssel in den Hauptspeicher kippen muß, sondern den einfach dediziert in eigener Hardware behält, unabhängig vom PC? Habt ihr nach über zehn Jahren Truecrypt, Bitblocker, SGE... noch immer nicht gelesen wie diese Systeme erfolgreich(!) geknackt werden? (ein Suchtipp gebe ich euch: "Stoned", den Rest googlet selbst) Grundsätzlich gilt: liegt der Schlüssel im RAM, ist das eine Softwarelösung. Da kann noch soviel Hardware rundrum sein, letztlich kommt man als Admin/root mit nem Debugger einfach so ran. @To: Jeder User hat seine Platte. Jeder User hat seinen Schlüssel. Daß die Ver-/Entschlüsselung für alle User mit demselben Werkzeug geht, liegt auf der Hand. Wenn mehrere User gleichzeitig arbeiten wollen, müssen auch gleichzeitig mehrere dieser Werkzeuge da sein. Jedes Werkzeug kann mit genau einem Code arbeiten. Achja: der XWall hatte ein paar Probleme mit Portmultipliern. Dem ein RAID per Multiplier anzuhängen, ist nicht gesund für die Daten. Aber das liegt nicht an der Idee, sondern am Xwall. Mal sehen was der neue MX+ so macht, wenn er mal gebaut wird.
Andy schrieb: > Grundsätzlich gilt: liegt der Schlüssel im RAM, ist das eine > Softwarelösung. Da kann noch soviel Hardware rundrum sein, letztlich > kommt man als Admin/root mit nem Debugger einfach so ran. spielt überhaupt keine Rolle. ein externen Gerät kann dafür nicht erkennen wer darauf zugreift. Es kann auch ein "böser" sein, dann entschlüsselt die Hardware für Ihn die Daten. Damit ist die Hardwarelösung auch nur sicher, wenn sie offline ist. Es gibt auch ansäte für den PC, wo der Schlüssel nicht im Ram ist. Da kommt man auch als Root nicht ran.
SATA ist einfach das falsche Protokoll. Du benötigst einen Fileserver. Dort können sich die User authentifizieren und der Server legt die Dateien verschlüsselt auf einer Platte ab. Wenn Dir eine SW-Lösung im RAM zu angreifbar erscheint, dann wirst Du SW und ein System entwickeln müssen, welches im ROM arbeitet. Gruß Jobst
Noch 'ne Frage ist wo denn das vom Benutzer einzugebene Password landen soll, wenn nicht im RAM.
Eric B. schrieb: > Noch 'ne Frage ist wo denn das vom Benutzer einzugebene Password landen > soll, wenn nicht im RAM. Na, aufm Post-It, das am Monitor bappt. Oder unter der Schreibtischauflage. SCNR, WK
Bei einer "externen" Entschlüsselung ist das Password nur im Moment der Eingabe und der Übergabe an das externe Gerät abgreifbar. Einen eventuellen Masterkey sieht der PC gar nicht, so dass dieser auch nicht kompromittiert werden kann. Zur Erhöhung der Sicherheit kann man TAN-/Token-Verfahren hinzufügen. Ein Abfangen der Passworteingabe zwecks späterer Verwendung ist somit nicht möglich. Eine ähnliche Wirkung hat es, wenn das externe Verschlüsselungsgerät vom PC entfernt wird. Alternativ kann ein Teil der Passworteingabe am externen Gerät erfolgen. Dies kann man beliebig komfortabel gestalten. Zugriffe könnte man externen Gerät visualisieren. Falls ein kompromittiertes Userprogramm alle Daten ausliest, wäre dies sichtbar. Dem kann man auch im externen Gerät auf Basis des Zugriffsmusters entgegen wirken. Mit Ausschalten (Stromlos) geht das externe Gerät in den gelockten Zustand und es ist zwingend eine neue Passworteingabe notwendig. Das ist mit einer Ver/Entschlüsselung auf dem PC nicht sicher erreichbar. Schwierigkeiten könnten eventuell gemountete Dateisysteme sein, falls der PC in den Standby geht. Auf freigeschaltete Daten können immer alle Userprogamme zugreifen. Letztlich ist das Sinn der Sache. Falls dies ein Problem ist, muss die Freischaltung/Entschlüsselung selektiver erfolgen. Selbes gilt für temporäre Files auf dem PC. Falls erforderlich, müsste auch temp über das externe Gerät laufen. Der Arbeitsspeicher ist theoretisch nach dem Ausschalten auch noch auslesbar und im Standby ohnehin. Das kann man kaum mehr über ein separates Gerät leiten, denn davon wird der PC zu langsam. Aber auch hier gilt eine ggf. selektive Freischaltung. Ebenfalls sind lediglich die gerade bearbeiteten Daten zugänglich und nicht alles zu jeder zukünftigen Zeit. Realisierbar ist das mit einem FPGA-Board im SD-Kartenformat oder als USB-Stick. Letztlich aber auch mit einem performanten Mikrocontroller. Wichtig ist, dass sich die Konfiguration/Flash im Package des uC/FPGA fabric befindet. Je nach verschwendeter Technologie können die Geräte an dieser Stelle mit weniger oder mehr Aufwand kompromittiert werden.
Die eigentliche Frage ist doch: Was soll diese ganze Gehinrakrobatik besser können als das was frei verfügbar ist? Welchen Vorteil soll sie bieten?
Eigene Verschlüsselungsalgorithmen haben halt genau den Vorteil, dass sie keiner kennt.
Knut B. schrieb: > Eigene Verschlüsselungsalgorithmen haben halt genau den Vorteil, > dass > sie keiner kennt. Das hat seinerzeit Alan Turing in Frage gestellt.
Mag sein, aber der Entschlüsselnde hat bedeutend mehr Arbeit, wenn er nicht weiß, wonach er suchen soll ;-).
Andy schrieb: > Also ich hab den Eindruck, hier haben viele nur mal was von Kryptografie > in der Tageszeitung gelesen. bei so viel Impetus fehlt mir immer noch das Threat Modelling. Ohne zu wissen, wovor man sich fürchtet, kann man nur religiös entscheiden, welche Maßnahmen relevant sind.
Peter II schrieb: > ein externen Gerät kann dafür nicht > erkennen wer darauf zugreift. Es kann auch ein "böser" sein, dann > entschlüsselt die Hardware für Ihn die Daten. Kannst du auch nicht erkennen. du kannst nur ein paar Mauern davorstellen. Dennoch kommt bei heute üblichen Systemen zur multiuserverwaltung praktisch immer ein Superuser mit vollständigen Zugriff über alles vor. Wenn du dessen PW kennst... Selbst wenn du den Aufwand betreibst, dir ein System ohne Superuser zu bauen, gibts da immer noch das Problem der zuverlässigen Userabschottung. Nein, das haben schon andere erkannt, daß das ein Holzweg ist. Das Problem ist: es gibt nicht mal ein theoretisch denkbares Prinzip, das exakt erkennen kann, ob derjenige, der da grad Zugriff hat, das auch wirklich darf. Wer das nicht versteht: hier nochmal aus den Grundlagen Kryptografie: damit das aber wenigstens risikoarm erkannt werden kann, gibt es die bekannten Authentifizierungsmöglichkeiten: Biometrie, Wissen, Besitz. Aber selbst, wenn man mittels DNA-test zweifelsfrei (zwillingsfrei) nachweisen kann: "die Person hier ist Adam und nicht Mallory", kann es immer noch sein, daß das System nicht weiß, daß Adam doch keinen Zugriff (mehr) haben darf. Beispiel: "eifersüchtiger Polizist ortet das Handy seiner Frau" Ergo: das ist ein organisatorisches Problem, das von der Kryptografie nicht gelöst werden kann. > > Damit ist die Hardwarelösung auch nur sicher, wenn sie offline ist. Das ist seine primäre Aufgabe. Das ist die Aufgabe einer jeden Festplattenverschlüsselung. Eine Festplattenverschlüsselung als Zugriffsbeschränkung zu benutzen ist genauso bescheuert, wie ein RAID als Backupersatz zu sehen: Nur weil mit zugekniffenen Augen eine Schraube einem Nagel ähnelt nimmt trotzdem niemand einen Hammer zum Schrauben. > Es gibt auch ansäte für den PC, wo der Schlüssel nicht im Ram ist. Da > kommt man auch als Root nicht ran. Nein, gibt es per se nicht. Egal was du auch versuchst, solange das Verschlüsselungswerkzeug nicht datentechnisch vollständig vom PC getrennt ist, musst du den Schlüssel in welcher Form auch immer zum verschlüsseln/entschlüsseln in die CPU bringen. Egal was du versuchst, auf die Register kann man auch - sagen wir mal per IRQ/NMI-Routine - Zugriff erhalten. Du musst quasi sowas ähnliches wie eine Haward-Architekur benutzen. Eric B. schrieb: > Noch 'ne Frage ist wo denn das vom Benutzer einzugebene Password landen > soll, wenn nicht im RAM. "passwort eingeben" ? per Tastatur? - wie rückständig.. um mal ein altes Filmzitat zu bemühen. Lars R. schrieb: > Bei einer "externen" Entschlüsselung ist das Password nur im > Moment der > Eingabe und der Übergabe an das externe Gerät abgreifbar. Einen > eventuellen Masterkey sieht der PC gar nicht, so dass dieser auch nicht > kompromittiert werden kann. dann schau mal nach dem Link von ArcNet: der Xwall hat zum Schlüsselaustausch zwischen (Hardware-)Schlüssel und CrypoChip ordentliche Verfahren zur Absicherung. - inkl OTP-Programmierung für Kommunikationsauthetisierung. Damit kannst du den Key z.b. in eine SmartCard packen und dir jede Authentisierung des elektronischen Passwortdialogs basteln, die dir die Paranoia vorgibt. D. V. schrieb: > Knut B. schrieb: >> Eigene Verschlüsselungsalgorithmen haben halt genau den Vorteil, >> dass >> sie keiner kennt. > > Das hat seinerzeit Alan Turing in Frage gestellt. Wenn ich präzisieren darf: er hat es erfolgreich(!) in Frage gestellt. Wegen sowas wurden schon Kriege verloren. Nur Narren ziehen daraus keine Lehren. (und die sitzen auch in Firmen, die deutsche Behörden beliefern :D)
Alexander T. schrieb: > Ohne zu > wissen, wovor man sich fürchtet... Da hast du recht. Doch das vom TO vorgestellte Szenario grenzt die Angriffsvektoren doch relativ scharf ein. Normalerweise würden in einem ordentlichen Beratungsgespäch jetzt Rückfragen zur Risikobetrachtung folgen. Aber erstens macht man so eine individuelle Beratung nicht öffentlich und zweitens: der TO hat mich nicht engagiert.
Wenn ich den TO richtig verstanden habe erfüllen selbstverschlüsselnde Festplatten mit Keypad mit Ausnahme RAID alle Anforderungen. Allerdings sind manche schon mit Implementierungsfehler aufgefallen. Beispiele: https://www.startech.com/de/HDD/Gehause/Verschluesseltes-Festplattengehaeuse-portabel-extern-HDD-Gehaeuse-SATA-auf-USB-3~S2510BU3PW https://datalocker.com/product/datalocker-dl3/
Knut B. schrieb: > Eigene Verschlüsselungsalgorithmen haben halt genau den Vorteil, dass > sie keiner kennt. Heutzutage noch "security by obscurity" zu propagieren halte ich mindestens für grob fahrlässig wenn nicht sogar vorsätzlich. Dieser "Vorteil" den du nennst ist spätstens dann hinfällig wenn das so gesicherte System (am besten noch weit verbreitet) im Einsatz ist und es dann jemandem gelingt gravierende Sicherheitslücken in dem selbstgestrickten Gemurkse zu finden. Knut B. schrieb: > Mag sein, aber der Entschlüsselnde hat bedeutend mehr Arbeit, wenn er > nicht weiß, wonach er suchen soll ;-). Das ist irrelevant. Wenn die verschlüsselten Daten es wert sind wird ein Angreifer auch entsprechend Zeit und Geld investieren, selbst wenn er weiß, dass etablierten Algorithmen zum Einsatz kommen. Im Zweifelsfall wird am Ende ohnehin nicht der Algorithmus selber sondern die Implementierung, das Host-System oder sogar die benutzer (Stichwort: Phishing) attackiert.
> Das ist irrelevant. Wenn die verschlüsselten Daten es wert sind wird ein > Angreifer auch entsprechend Zeit und Geld investieren, selbst wenn er > weiß, dass etablierten Algorithmen zum Einsatz kommen. Im Zweifelsfall > wird am Ende ohnehin nicht der Algorithmus selber sondern die > Implementierung, das Host-System oder sogar die benutzer (Stichwort: > Phishing) attackiert. Oder wie diverse 3-Buchstaben Vereine es nennen: Rubber-hose cryptanalysis.
> das vom TO vorgestellte Szenario grenzt die > Angriffsvektoren doch relativ scharf ein. Für mich bleiben wichtige Fragen offen. Zuvorderst: Soll das System in einer kontrollierten Umgebung eingesetzt werden? Wenn ja, dann gibt es keinen Anlaß zur Befürchtung, daß jemand einen Key aus dem RAM ausliest oder sonstwie manipuliert -- dann kann man erfolgreich ein beliebiges embedded system à la Raspberry nehmen. Wenn nicht, täte ich mich vor allem davor fürchten, daß mir jemand das Keyboard manipuliert und abhört, Eingaben mit Kamera filmt etc. oder die Daten bei der Einlieferung in das System abgereift. Ich frage mich auch, welche Merkfähigkeit die Bedienmannschaft hat, die es erlaubt, einen sinnvollen Key zur Verschlüsselung über ein Keypad einzugeben (oder war das alphanumerisch gemeint?) Auf der anderen Ebene des Subjects fehlt mir noch jeder Hinweis darauf, ob harte oder weiche Echtzeitanforderungen gelten und wie die gestaltet sind. Bei all dem geht's aber letztlich um meine Neugier. Da der TO seine Entscheidung getroffen hat und ich ihm leider nicht dabei helfen kann, sein Vorhaben zu implementieren, ist's wohl besser, die Klappe zu halten :-)
Einfach ein dummer "Alles-Verschlüssler" zwischen PC und Platte wird nicht gehen, denn wie soll dann die Kommuniktion mit der Platten-Elektronik laufen? Der "Zwischenstecker" müsste also zumindest die Steuerkommados für den Controller erkennen und aussparen können, ebenso wie die Statusmeldungen von der Platte zum PC ...
Gibt es doch schon fertig.. https://www.all-about-security.de/wirtschaftsnachrichten/artikel/15911-mehr-schutz-fuer-personenbezogene-und-sensible-unternehmensd/
Daniel H. schrieb: > Heutzutage noch "security by obscurity" zu propagieren halte ich > mindestens für grob fahrlässig wenn nicht sogar vorsätzlich. Oder ganz einfach: dumm! Es ist einfach nur dumm und zeigt, dass sich der TO nicht eine Sekunde mit Kryptographie beschaeftigt hat. Aber sei es drum... Der TO will was wirklich sicheres? Dann soll er doch ein OTP nehmen. Okay, das muss solang wie die Daten und nicht wiederholend sein, aber es ist sicher. Selbst mit unendlicher Rechenleistung ist ein OTP nicht zu knacken (genauer gesagt: es ist knackbar, nur kann man nicht feststellen, ob man es geknackt hat oder nicht). Und ein OTP hat den Vorteil, dass man praktisch nichts falsch machen kann... zumindestens faellt mir spontant nicht ein, was man bei einem XOR falschen machen koennte.
Kaj G. schrieb: > zumindestens faellt mir spontant nicht ein, was man bei > einem XOR falschen machen koennte. Naja, bei einer guten Verschlüsselung ändert sich eben nicht nur das korrespondierende Bit sondern eben wahllos einige bits. Es muss wie Zufall wirken. Gruß Jobst
Bitte 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.