Verschlüsselung - Angriffsschutz
-
Hallo, ich habe mir ein Dongle-DemoKit gekauft, Die Dongles können 128Bit Ver-/Entschlüsselung, die Ver-/Entschlüsselung findet vollständig in der Hardware statt. Der gewählte Schlüssel kann nicht aus der Hardware ausgelesen werden. Wenn versucht wird die Hardware zu manipulieren, Klappt der Hack-Schutz um und die Hardware ist unbrauchbar. Zum Beispiel wer mit BruteForce Den UserCode knacken will. Soviel zu der Hardware.
Nehmen wir mal an ich habe einen String: "Hallo Welt" Dieser soll jetzt über das Netzwerk verschickt werden. Nun habe ich mir folgendes ausgedacht:
Der String wird als erstes mit aes verschlüsselt. Danach wird dieser in einen Buffer geschrieben.
Der Buffer wird mir der Hardware Dongle verschlüsselt. Der Transfare und die Signierung des Buffers wird mittels Public-Key verfahren realisiert.
Was ist wenn Jemand das Daten-Paket abfängt?
Wie knackt man das, damit man an den Plain-Text kommt? Muss man da Verschlüsselung für Verschlüsselung knacken? Oder kann man den Plain-Text gleich wieder angreifen? Worauf ich hinaus will ist folgendes... Der String läuft durch 3 verschiedene Verschlüsselung-Algorithmen. Ist das nun sicherer oder ist das wurscht?
Muss ein Bösewicht das Paket Algorithmus für Algorithmus knacken oder gibt es da einen anderen Ansatz? Sprich welche Möglichkeiten hat ein Angreifer und wir kann ich das noch sicherer machen?
-
Das kommt drauf an. Teilweise kann das anwenden von mehreren Algorithmen sogar die Sicherheit verringern.
Ich würde an deiner Stelle auch nicht selbst ein Protokoll für den verschlüsselten Transport entwerfen. Das Thema ist einfach zu umfangreich und kompliziert, als dass man es ohne Erfahrung richtig hinbekommt. Benutz einfach etwas existierendes so wie TLS/SSL.
btw. Wenn du den Verschlüsselungsalgorithmus der Dongles nicht kennst, dann wirf sie weg.
-
Also String->AES-Encryption->Buffer->Hardware Verschlüsselung->Trasfare mittels RSA. So kann auch nur der was mit dem Paket anfangen für den es bestimmt ist. Die Verbindung ist mittels SSL/TLS abgesichert. Von da her entwickle ich nichts neues, ich nehme vorhandenes alles was ich benötige liefert mir OpenSSL, da habe ich auch alle Algorithmen. Hier sind die Dongle-Spezifikationen: http://www.matrixlock.de/techndat.htm
Das mit PublicKey muss sein warum ist denke ich mal klar... (Dazu ist Public-Key verfahren da
)
XTEA Ver-/Entschlüsselung 128-Bit bei allen Modellen vollständig im Dongle. Standard-Verfahren wie 3DES, AES oder RSA verfügbar.
-
Hi
Wieso den ganzen datenstrom durch den Key schläusen. das wird doch sicher
irgendwann zum flaschenhals.ggf den Key nur zum austausch der Session keys verwenden.
Server generiert zufälligen session key. verschlüsselt diesen mit dem dongel. transfeririert diesen zum client. client entschlüsselt diesen mitels des dongels wieder und setzt ihn für die weitere kommunikation zum server ein. z.B. als key für die SSL verbindung. ( je weniger daten mit dem key verschlüsselt werden umso weniger daten liegen für einen angriff auf den key vor, voraussetzung das verfahren des Keys ist sicher )Wieso eigentlich public key? du hast auf beiden seiten der verbindung einen dongel mit keys, die keiner kennt.
gruss
-
Termite, deine Idee ist gut.
Das mit dem Public-Key verfahren hat sich an sich schon erledigt, wenn ich Session-Keys verwende. Somit hat jeder Client/Verbindung einen anderen Key, somit sind die Daten auch nicht veränderbar. Es geht darum, wenn eine Anfrage vom Server an den Client kommt, das auch nur der Client es lesen kann und kein anderer Client , Da dachte ich mir das ich das am einfachsten mit Public-Key realisieren kann.
Oben habe ich ja geschrieben mit was für einem Algorithmus die Dongle fährt. In jeder Dongle ist der selbe Schlüssel.
Ich fasse das ganze nochmal zusammen mit der Theorie von Termite:
Client-Server Verbindung ist SSL/TLS verschlüsselt.
[Programmstart]
- Programm startet nur mit gültiger Dongle
=> Knackbar durch Reverse-Engineering
- Anfrage an den Server
[Server]
- generiert ein Session-Key
- Session-Key wird mittels Dongle verschlüsselt
- Key wird zum Client der die Anfrage gestellt hat geschickt.
=> Sicherheitslücke? Da den Key jeder anfordern kann(?)
[Client]
- Session-Key wird mittels Dongle entschlüsselt
- Client wechselt in den "Silent-Mode" (finde das wort nur geil :P)
- Durch die Session können nun auch die Relevanten Daten des Server empfangen werden
- Client schickt Daten an den Server nur mit Session-Key möglich.
- Daten werden mit dem Session-Key signiert, somit kann der Server das ganze auf Gültigkeit und Vertrauenswürdigkeit prüfen.
=> sollen die Daten auch mit den Session-Key verschlüsselt werden?Ich glaube ich haue da jetzt langsam was durcheinander...
so long
-
Hi
Zum Thema Session keys: diese sind zwar für symetrische verschlüsselungs verfahren, müssen aber ausgetauscht werden. es gibt dafür zwar verfahren, So ein schlüsselaustausch ohne public key verfahren, ist meines wissens für durch eine Man in the midel atack angreifbar bzw. sogar zu überwinden.
Ich dachte eigentlich daran die daten mit dem Session key zu verschlüsseln / für die ssl verbindung zu benutzen. für signaturen ggf wieder den Dongel. ( session key könnte geknackt werden. kennt er den key im dongel, ist das system sowieso geknackt )
und das problem mit der anfrage. Wer sagt denn, das die anfrage nicht auch verschlüsselt laufen kann? bzw, das das ganze nicht in mehreren schritten abläuft? das der klient sich erst einmal autentifizieren muss.
z.B.
client (c): Hallo server, ich bin ... und hätte gerne einen Session key.
Server (s): Das kann aber jeder sagen. Sag mir erst mal die Antwort auf folgende Frage: ...
c: ok hir hast du die Antwort: ....
s: ok du bist ...., ich vertrau dir, hier dein session key. ( die dann natürlich verschlüsselt )Die frage kann ein zufälliges datenpaket sein, das der client mit seinem key signieren muss. oder ... ggf. kann man da sogar für unterschiedliche Clients ein anderer key zur signierung verwendet werden. für den client ist der key im dongel, auf dem server kommt der key aus einer db. ( shutz der db ist dann auch ein thema, fällt die db ist das system sowieso ein fall fürs WC )
bei sochen systemen stellt sich immer die frage nach nutzen und kosten. Wieviel sind die zu schützenden daten wert, und ist der aufwand, den ich dafür aufwende gerechtfertigt?
gruss
-
Wenn ich Session-Key austausch via Public-Key verfahren machen, Kann ich das auch zur Signierung hernehmen... Das gilt ja schließlich als sicher. Der Session-Key dient dann zu allgemeinen symmetrischen Verschlüsselung. Wie du schon sagtest die Dongle als Authentifizierung zu nehmen ist eine gute Idee. Sprich alles was vor dem Session-Key Austausch gemacht werden muss läuft dann über Dongle, ich denke mal so bekommt ich dann auch ein sicheres challenge response Verfahren hin. Da der Key aus der Dongle nicht auslesbar ist und bei einem Angriff das teil eh dicht macht, ist es auch sicher. Oder was meinst du dazu?