Forum: Mikrocontroller und Digitale Elektronik Echtzeitdatenverschlüsselung


von Martin K. (mkmannheim) Benutzerseite


Lesenswert?

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?

von Noch nicht Rentner (Gast)


Lesenswert?

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.

von Josef S. (josef2)


Lesenswert?

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.

von Daniel H. (Firma: keine) (commander)


Lesenswert?

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
von Dergute W. (derguteweka)


Lesenswert?

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

von Marc V. (Firma: Vescomp) (logarithmus)


Lesenswert?

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
von Volle (Gast)


Lesenswert?

kauf dir eine Samsung T3 SSD

von c.m. (Gast)


Lesenswert?

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?

von Alexander T. (Firma: Arge f. t. abgeh. Technologie) (atat)


Lesenswert?

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.

von Markus F. (mfro)


Lesenswert?

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.

von Planlos (Gast)


Lesenswert?

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.

von Kaj (Gast)


Lesenswert?

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

von Daniel H. (Firma: keine) (commander)


Lesenswert?

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.

von jannyboy (Gast)


Lesenswert?

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

von Anonymous (Gast)


Lesenswert?

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.

von Axel S. (a-za-z0-9)


Lesenswert?

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.

von Daniel H. (Firma: keine) (commander)


Lesenswert?

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
von Peter II (Gast)


Lesenswert?

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.

von Axel S. (a-za-z0-9)


Lesenswert?

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.

von Philipp K. (philipp_k59)


Lesenswert?

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.

von Peter II (Gast)


Lesenswert?

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.

von Martin K. (mkmannheim) Benutzerseite


Lesenswert?

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.

von Andreas H. (ahz)


Lesenswert?

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

von Peter M. (barrelshifter)


Lesenswert?

Schau Dir einmal dieses Dokument an:
http://www.ti.com/lit/an/swra172c/swra172c.pdf

von Nop (Gast)


Lesenswert?

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.

von (prx) A. K. (prx)


Lesenswert?

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.

von Dergute W. (derguteweka)


Lesenswert?

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

von Arc N. (arc)


Lesenswert?

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

von Jobst M. (jobstens-de)


Lesenswert?

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

von Andy (Gast)


Lesenswert?

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.

von Peter II (Gast)


Lesenswert?

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.

von Jobst M. (jobstens-de)


Lesenswert?

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

von Eric B. (beric)


Lesenswert?

Noch 'ne Frage ist wo denn das vom Benutzer einzugebene Password landen 
soll, wenn nicht im RAM.

von Dergute W. (derguteweka)


Lesenswert?

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

von Lars R. (lrs)


Lesenswert?

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.

von Der Andere (Gast)


Lesenswert?

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?

von Knut B. (Firma: TravelRec.) (travelrec) Benutzerseite


Lesenswert?

Eigene Verschlüsselungsalgorithmen haben halt genau den Vorteil, dass 
sie keiner kennt.

von D. V. (mazze69)


Lesenswert?

Knut B. schrieb:
> Eigene Verschlüsselungsalgorithmen haben halt genau den Vorteil,
> dass
> sie keiner kennt.

Das hat seinerzeit Alan Turing in Frage gestellt.

von Knut B. (Firma: TravelRec.) (travelrec) Benutzerseite


Lesenswert?

Mag sein, aber der Entschlüsselnde hat bedeutend mehr Arbeit, wenn er 
nicht weiß, wonach er suchen soll ;-).

von Alexander T. (Firma: Arge f. t. abgeh. Technologie) (atat)


Lesenswert?

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.

von Andy (Gast)


Lesenswert?

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)

von Andy (Gast)


Lesenswert?

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.

von Blechbieger (Gast)


Lesenswert?

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/

von Daniel H. (Firma: keine) (commander)


Lesenswert?

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.

von B. B. (Firma: 3B LED) (waflija)


Lesenswert?

> 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.

von Alexander T. (Firma: Arge f. t. abgeh. Technologie) (atat)


Lesenswert?

> 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 
:-)

von Frank E. (Firma: Q3) (qualidat)


Lesenswert?

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 ...

von Dr. Ötte (Gast)


Lesenswert?

Was fürn TO noob. Da fällt einem echt nix mehr ein.

von Philipp K. (philipp_k59)


Lesenswert?


von Kaj G. (Firma: RUB) (bloody)


Lesenswert?

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.

von Jobst M. (jobstens-de)


Lesenswert?

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
Noch kein Account? Hier anmelden.