linux-l: Sicherheitsmodell (Marke Eigenbau)

[Steffen Dettmer]

* Sebastian Rother wrote on Wed, Oct 03, 2001 at 23:05 +0200:
> Ich habe ein Sicherheitskonzept entwickelt :o)

Optimist :)

> Das alles hat mit dem Rijndael (AES) Algorithmus zu tun.

Nein, überhaupt nicht. Dein Algorithmus ist mit jedem
symetrischen Algorithmus machbar, insbesondere auch 3DES.

> Ziel:
> - Abruf von z.B. Datenbankinformationen für Registrierte Benutzer mittels
> einem speziellem Verfahren.

Das ist ein blödes Ziel. Mit "einem Speziellen Verfahren". Kann
ja alles sein (Benutzer muß dreimal x drücken ist auch ein
spezielles Verfahren :)). Hier muß man unbedingt das Ziel richtig
beschreiben. Du möchtest:
- Authentifizierung von Benutzern 
- Brute-Force-Angriff soll der effektivste sein
- große Schlüssellängen, um diesen unrealistisch zu machen (aber
  300 Byte ist für ne MySQL Datenbank ein bißchen fett. Ein
  Bankautomat benutzt auch "nur" 3DES mit 112).

> Aufgabenstellung:

Die Aufgabenbeschreibung liest sich mehr wie ein Lösung :)

> - ein Programm muss mit einem pseudo Zufallsgenerator einen 300 Zeichen
> langen Schlüssel erstellen

Warum ausgerechnet 300? Läßt sich ja nichtmal durch die gleich
folgende Schlüssellänge von 256bit==32 byte Teilen?!

> - dieser muss dann mit Rijndael (256-Bit Modus) verschlüsselt werden
>   (Warum 256 Bit? Das Schützt den Schlüssel gegen Angriffe von
> Quantenrechnern, falls diese mal entwickelt werden)

Warum soll das schützen?! Der Quantenrechner kann alle
Operationen, die man vorwärts schnell ausführen kann, rückwärts
genausoschnell ausführen. Da Quanten Superpositiv sind, ist es
(theoretisch) möglich, sozusagen mit allen Ergebnissen
gleichzeitig zu rechnen. Damit spielt der verwendete Algorithmus
nur eine untergeordnete Rolle, es sei denn, er ist genau
One-Time-Pad...

Zurück. Welcher Schlüssel wird für AES verwendet? Ist dieser
konstant? Wer hat Kenntnis dieses Schlüssels?

Zusammenfassung: Du erzeugst eine Zufallszahl, verschlüsselst sie
mit einen Schlüssel. Soweit.

> - dieser Schlüssel wird dann per Kartenschreiber
> (Smart-Card-Writer oder so) auf eine Smart-Card übertragen

Du meinst eine Speicherkarte? Ich hab auch im Folgenden nicht
gefunden, warum die Karte "Intelligenz" benötigen soll.

> - die Karte wird an den Endbenutzer überstellt welcher nicht
> weiss, wie das Passwort lautete

Was ist jetzt plötzlich "Passwort"? Die große Zufallszahl aus
dem ersten Punkt?

Er kennt also nur die verschlüsselte Zufallszahl, ja?

> - eine Kopie des Schlüssels muss an einen Schlüsseldeamon
>   übertragen werden

Des Schlüssels für AES, die Zufallszahl oder die verschlüsselte
Zufallszahl?

> - Der Endbenutzer lässt zu Hause die Karte einlesen wo der Schlüssel zur
>   Anmeldung per Internet zum Schlüsseldeamon übertragen wird

Du meinst, die Zufallszahl? Die kennt der Benutzer doch überhaupt
nicht? Hast Du jedenfalls oben gefordert. Oder soll die
verschlüsselte Zufallszahl übertragen werden?

> - Der Schlüsseldeamon vergleicht dann dieses Passwort mit seinem
>   Schlüsselring

Das kann er genau dann, wenn er entweder den Schlüssel und die
Zufallszahl oder die verschlüsselte Zufallszahl kennt, da der
Benutzer nur die verschlüsselte Zufallszahl kennt.

Da stellt sich dann die Fragen, warum Du die Zufallszahl
überhaupt verschlüsselst. Du kannst gleich die Zufallszahl
benutzen, daß macht überhaupt keinen Unterschied. 

> - Bei richtigem Passwort darf der Benutzer einen Dienst (z.B. MySQL)
>   benutzen
> - Bei falschem Passwort darf nichts freigegeben werden

> Besonderheiten:
> 
> - Der Schlüsseldeamon muss sich VOR die Dienste "klemmen" und darf diese
> freischalten
> - Die Übertragung des Schlüssels muss wiederum stark verschlüsselt werden
> (Einweghash) -> Hier wäre SSH evtl. eine Lösung

Davon hab ich in Deiner Beschreibung überhaupt nichts gefunden.
Wenn Du SSH brauchst, kannst Du gleich SSH nehmen, daß hat
bereits alle Funktionen :) SSH an sich ist ein Verfahren, was
Deine Ziele erfüllt. Da dies also bereits ausreichend wäre, sind
demzufolge alle zusätzlichen Schritte (also die "Deines"
Verfahrens) überflüssig...

> - Die Programme / Deamons müssten an sich erstmal geschrieben werden :o)

Was, ein Daemon, der zwei 300 byte Zeichenketten vergleicht? Kann
ja nun nicht das Problem sein.

> Nun, sollte Jemand den Schlüssel abfangen, könnte er sich, sofern er die
> Zieladresse kennt, am Server anmelden und so Datenzugriffe erhalten.

Eben, und das funktioniert bei Deinem Verfahren leider.

> Ein einweghash mach das Abhören theoretisch Sinnlos. Da bei jeder erneuten
> Schlüsselübertragung ein neuer Übertragungsschlüssel vereinbart wird.

Übertragungsschlüssel erwähnst Du das erstemal.

> a) Realisierbarkeit

Vergleichsweise einfach.

> b) zum Sicherheitsmodell, hat es evtl. Lücken die ich übersehen
>    habe?  (bin ja erst 16)

Für erste Krypto-Betrachtung nicht schlecht. Aber im Vergleich
zum Aufwand ist die Sicherheit gering. Mit den Erweiterungen
(Übertragungschlüsseln usw.) ist die Sicherheit eben genau davon
abhängig.

> c) Richtigkeit der kryptographischen Begriffe (Ich habe gerade erst
> angefangen mich da einzuarbeiten :o) 

Diese sind leider nicht so ganz klar. Man kann nicht immer
erkennen, welchen Schlüssel Du wann meinst. Du kannst denen ja
Namen geben. Schlüssel (engl. Key) K1 oder Kmaria oder so.

Verfahren, die Deine Ziele erfüllen, gibt es natürlich. Mal ganz
kurz ein schönes Verfahren mit asymetrischen Algorithmen. Wir
nehmen mal spaßeshalber ruhig eine richtige Smartcard hinzu.
Diese verfüge über RSA Operationen (so ein Teil kostet in
"Massen" auch nur noch DM 5 - DM 10 pro Stück).

Warum Smartcard? Eine Smartcard kann wie ein
"Hardware-Sicherheitsmodul" (HSM) gebaut werden, d.h, sie erfüllt
Eigenschaften eines HSMs. Dies sind: Durch äußere elektrische
Analyseverfahren (z.B. Strommessungen usw.) kann nicht auf die
intern gespeicherten Daten geschlossen werden. Weiterhin kann
selbst durch mechanische Angriffe (ohne Chip-Labor) nichts
erkannt werden - man kriegt die Karte nur kaputt (in dem man den
Chip einfach in etwas sehr hartes einbettet, da kommt man ohne
Super HighTech nicht mehr ran. Mit Super-HighTech kommt man an
_alles_ ran). Das heißt dann, man bekommt die geheimen Daten
nicht mehr aus der Karte herraus.

Die Karte kennt folgende Operationen (Namen in Klammern):

- erzeugen und speichern eines asymetrischen Schlüsselpaars
  (myKey) (Funktion: keyGen) Das funktioniert nur einmal.
- ausgeben des öffentlichen Schlüssels (nicht des geheimen)
  (getPubKey)
- lesen von Daten, die mit dem geheimen Schlüssel verschlüsselt
  werden und deren Ausgaben (wir nennen das ab jetzt "signieren
  von Daten")
  (sign)
- Die Karte kann Zufallszahlen erzeugen und je eine davon speichern
  (random)
  Diese können ausgegeben werden (getRandom). 

Weil wir auch gleich möchten, daß erkannt wird, falls das
"Serversytem" nachgemacht wird, möchten wir auch dieses erkennen
können. Dazu muß die Karte die Möglichkeit haben, Fremd-Schlüssel
zu prüfen. Wir machen das ganz einfach:

- die Karte hat einen weiteren internen Schlüsselspeicherplatz
- es ist möglich, einen Schlüssel (peerKey) von außen in diesen
  Schlüsselplatz einzubringen. Dies funktioniert nur genau
  einmal.
  (storePeerKey)
- Die Karte liest Daten, entschlüsselt diese mit "peerKey" und
  vergleicht diese mit der zuvor gespeicherten Zufallszahl
  (random) (verifyResponse)
- Um die Karten bei Fehlern nicht wegwerfen zu müssen (man kann
  ja nur einmal einen Key erzeugen und nur einmal einen
  einbringen) definieren wir noch eine Funktion, die alle Daten
  löscht und den Urzustand wiederherstellt (wipeAll)

Warum wir die alle brauchen, wird später klar.

Vorbereitung:

Der Server (Daemon) hat eine solche Karte, und der Benutzer (das
System muß für mehrere Benutzer entsprechend ausgedehnt werden,
aber ich wollte nicht gleich mit Zertifikaten anfangen).

Beide Karten werden in einem Sicherheitsraum gebracht. Dort wird
bei beiden Karten keyGen ausgerufen (man nennt dies
"Personalisierung"). Danach wird der Pubkey mit
getPubKey ausgelesen und mit storePeerKey in die andere Karte
eingebracht. 

Die Karten werden verteilt. Soweit ist das einmalig.

Betrieb:

Nun möchte sich der Benutzer authentifizieren, und das System muß
sich ebenfalls beim Benutzer authentifiziren (damit nichts
manipuliert werden kann, z.B. vorgaugeln eines Servers, der
überhaupt keine Authentifizierung prüft, weil er die Karte ja
nicht hat oder so).

Das Programm des Benutzers ruft random auf und holt sich die
Zahl (getRandom) und schickt das zum Server. Wir nennen das
Challenge. Die Serversoftware ruft sign auf seiner Karte (mit der
Zufallszahl) auf und schickt das Ergebnis zurück (wir nennen das
mal Response). Das Benutzerprogramm ruft mit den Daten nun
verifyResponse auf. Das ist nur erfolgreich, wenn nach dem
Entschlüsseln wieder die zuvor erzeugte (und gepeicherte)
Zufallszahl herrauskommt. Dadurch ist sichergestellt, daß die
richtige Zufallszahl für das Erzeugen der Response verwendet
wurde und das der richtige SecretKey des Servers zum
verschlüsseln verwendet wurde (also die richtige Karte zum
Einsatz kam). In allen anderen Fällen gibt es das falsche
Ergebnis (das verwenden von "alten" abgefangenen Responses wird
damit erkannt, da ja jedesmal eine andere Zufallszahl verwendet
wird). Nun weiß der Benuzter, daß der Server die richtige Karte
hat.

Nun macht man das nochmal umgekehrt (server erzeugt Zufallszahl,
schickt die an den Benutzer, dessen Karte signiert diese; der
Server prüft mit seiner Karte, ob das entschlüsselte Ergebnis die
zuvor gespeicherte Zahl ist). Nun wissen beide, daß auf der
anderen Seite der "richtige" sitzt. Jemand dazwischen kann nichts
manipulieren, daß die Übertragenen Werte nur ein einziges Mal
gültig sind, da es immer aus Zufallszahlen basiert.

Mir fällt gerade auf, daß getPubKey nicht wirklich (nur einmal im
Sicherheitsraum) benötigt wird. Klar; das Verfahren hier
funktioniert genausogut mit symetrischen Algorithmen. Verstehst
Du, wie?

Na, ganz einfach. Anstatt pub/sec Keys und so, gibt es eine
Funktion zum Einbringen eines z.B. AES keys (jedoch keine zum
Auslesen). Im Sicherheitsraum wird an einem PC (so einem ohne
Festplatte und so) ein AES Key erzeugt und in beide Karten
einbracht. Danach wird er von PC gelöscht - der Key ist nur noch
in den Karten, und niemand kriegt den mehr herraus.

Die Karte braucht damit insgesammt nur einen Schlüsselplatz, da
beide (hier gehen auch 10 oder mehr) den selben Key haben.

Das Challenge-Response Verfahren bleibt genauso. Ein paar
Funkionen auf der Karte müssen geändert werden:
- sign verwendet den gespeicherten Key, um die Daten zu
  verschlüsseln
- verifyResponse ebenfalls

Das wird ja damit schön einfach. 

Das ist aber in der Praxis meist nicht machbar, weil ja alle
Karten im Sicherheitsraum den Key kriegen müssen --> teuer.
Außerdem reicht es aus, eine Karte zu stehlen. Man kann die
Karten ja nicht "erkennen", also muß man auch alle anderen Karten
sperren. Deshlab verwendet man asysmetrische Schlüssel. Damit der
Server nicht alle Partner-Schlüssel kennen muß, bekommt der ein
"ober" Schlüssel, mit dess (sec) Key die Partnerschlüssel
signiert sind (->zertifiziert sind). Die Partnerkarten bekommen
auch dieses Zertifikat gespeichert. Daran kann der Server dann
erkennen, ob es echt ist (mit dem Ober-Schlüssel erzeugt) und den
zertifizierten Key verwenden (analog zum obrigen Verfahren könnte
man sagen, daß man z.B. eine Funktion storePeerKey hat, die nur
funktioniert, wenn der peerKey in gültiges Zertifikat ist. Damit
müßte die Funktion natürlich anders heißen, vielleicht
loadCertifiedKey. Natürlich muß man den
Zertifizierungs-Ober-Schlüssel dafür ständig in der Karte
speichern.

So, das war jetzt wieder viel auf einmal, was :)

oki,

Steffen

-- 
Dieses Schreiben wurde maschinell erstellt,
es trägt daher weder Unterschrift noch Siegel.