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.htmlhttps://www.heise.de/security/meldung/Externe-Festplatten-mit-Verschluesselung-knackbar-3289530.html
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...
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.
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.
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
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
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.
Knut B. schrieb:> Eigene Verschlüsselungsalgorithmen haben halt genau den Vorteil,> dass> sie keiner kennt.
Das hat seinerzeit Alan Turing in Frage gestellt.
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.
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 ...
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
