Hallo Zusammen,

in einem Prüfungsprotokoll von VSS habe ich die Frage : "Welche Arten von Nonces gibt es und was sind ihre Vor- und Nachteile?" gesehen. Ähm, kann aber nicht wirklich was damit anfangen. Nonce ist doch Numbers used Once und eine Zufallszahl, die generiert wird. Welche Arten soll es denn davon geben? und was sind die Vor- und Nachteile??

Wäre für Eure Hilfe sehr dankbar!

hab auch eine frage zu vss. wenn nach vpn-arten gefragt wird. ist es richtig, wenn ich L2F, PPTP, L2TP UND IPSEC erläutere? das sind doch vpn-arten, oder?

merci!

"Welche Arten von Nonces gibt es und was sind ihre Vor- und Nachteile?" gesehen. Ähm, kann aber nicht wirklich was damit anfangen. Nonce ist doch Numbers used Once und eine Zufallszahl, die generiert wird.

Hm. Also du erklaerst doch schon erstmal zwei voellig verschiedene Sachen.

"Numbers used Once" und "Zufallszahl".

Eine Zufallszahl kann man als Nonce benutzen. Man koennte aber auch immer eine Zahl inkrementieren. Oder die (Mikro)Sekunden seit 1970 nehmen.

Und naja, random Nonces sind wohl besser um sich gg. Angreifer zu schuetzen, die diese Nonce nicht sehen sollen. Aber wenn du dich mit jmd verabreden musst, die gleiche Nonce zu verwenden, sind deterministische Verfahren erstmal einfacher zu implementieren.

Disclaimer: Ich kenne den VSS Stoff nicht und das gesagt kann ueberhaupt nichts mit dem zu tun haben, wasin VSS gefragt wird.

Es gibt 4 Arten von Nonces

1. (Pseudo-)Zufallszahlen
2. Timestamps
3. Sequenznummern
4. Challenges

Über die jeweiligen Eigenschaften sowie Vor- und Nachteile kann ich später noch was schreiben, aber man darf sich gerne selber dazu Gedanken machen

vielen dank… jetzt habe ich wenigstens anhaltspunkte und kann auch recherchieren..
aber würd mich trotzdem freuen, wieder was von dir zu hören, um abzugleichen. muss erstmal ipsec vertiefen– also tausend dank!!

also, hier ein paar ideen von mir. wäre super, wenn ihr mich korrigieren oder eventuell meine antwort ergänzen würdet..

- große Zufallszahlen scheinen für noncen am besten geeignet zu sein, da sie nicht erratbar und vorhersagbar sind.
- die wiederverwendung von zufallszahlen beruht auf wahrscheinlichkeiten
- sequenznummern erfordern nichtflüchtige Zustände, so dass ein knoten
sicher sein kann, dass es nicht zweimal die gleiche nummer verwendet. auch nach einem absturz muss dies sichergestellt werden.

nachteil: die Verwendung von echten zufallszahlen kann sehr teuer werden.
- ungeeignete zufallszahlen können dazu führen, dass ein algorithmus
oder ein protokoll, das eigentlich sicher ist, unsicher wird.

habt ihr was zu ergänzen?

dankschön!

ach so @ anonymer user: ja, das sind die arten von vpn. site-to-side, host-to-host… sind eher anwendungsfälle/szenarien

Die Grundidee von Nonces ist doch diese:
* Client + Server kennen dasselbe Geheimnis (Passwort)
* Der Client soll zeigen, dass er das Geheimnis kennt, ohne es zu übertragen
* Wenn ein Angreifer eine Verbindung belauscht, soll er die gewonnenen Informationen nicht nutzen können,
  um sich später als der Client ausgeben zu können.

Der Server schickt die Nonce, der Client schickt msg=HASH(Nonce || Geheimnis), der Server berechnet ebenfalls den HASH und vergleicht.

Angriffsszenarien:
* Dieselbe Nonce wird ein zweites Mal verwendet: Der Angreifer schickt dieselbe Antwort, die er mal mitgeschnitten hat.
* Passwort unsicher oder Hashfunktion unsicher: Angreifer kann aus Nonce + msg (eventuell mehrere Paare) das Passwort ermitteln.
* Man in the middle: Angreifer nimmt die Verbindung vom Client entgegen, baut selbst eine zum Server auf, leitet Nonce + Antwort 1:1 durch. Danach ist der Angreifer am Server authentifiziert und freut sich. Häufig kann ein Angreifer, der mithören kann, auch die Kommunikation selbst manipulieren. Also was soll der ganze Noncense?!

Ich frage mich, was an Sequenznummern (z. B. Timestamp) das Problem ist. Hierdurch ist doch wenigstens garantiert, dass dieselbe Nonce kein zweites Mal verwendet wird (vorausgesetzt die Uhr geht richtig).
Der Angreifer kennt zwar die Nonce im Voraus, aber was gewinnt er damit?
* Kann er den Client dazu bringen, ihm die Antwort auf diese Nonce zu geben? Kann er auf demselben Weg nicht auch eine gerade erst bekannt gewordene Nonce angreifen?
* Kann er mit genügend Aufwand aus vorherigen Nonce/Antwort-Paaren und der neuen Nonce die neue Antwort berechnen?
[latex]\textnormal{msg}_0 = {\mathcal H}(\textnormal{Nonce}_0 || \textnormal{Secret}), \textnormal{msg}_1 = {\mathcal H}(\textnormal{Nonce}_1 || \textnormal{Secret}) \Rightarrow \textnormal{msg}_1 = {\mathcal H}(\textnormal{Nonce}_1 || \textnormal{Nonce}_0^{-1} || {\mathcal H}^{-1}(\textnormal{msg}_0))[/latex].
Es muss also die Möglichkeit geben, in einem Hashwert die alte Nonce durch die neue Nonce zu ersetzen. Wenn dies in akzeptabler Zeit möglich ist, würde ich mir eine neue Hashfunktion suchen.

Ich sehe keine relevanten Sicherheits-Unterschiede zwischen Zufallszahlen + Timestamps. Was übersehe ich?!

… ziemlich vieles, was in der Vorlesung von KPK öfter runtergebeten wurde. Ist anscheinend wichtig … ach ja, Nonces sind nicht ursächlich bei Übertragung von Geheimnissen wichtig sondern gegen: *REPLAYANGRIFFE* !!!!!

Euer Smiley

Das sind die vier gängigen Protokolle in kommerziellen Produkten, drei eher auf Ebene 2 und damit flexibler als IPSEC, IPSEC halt nur für IP

Interessant ist vom Protokoll her halt IPSEC (ohne das Schlüsselmanagement im Detail) und bei den anderen drei interessiert mich nur die Übersichtstabelle.

Beste Grüße
KPK

- große Zufallszahlen scheinen für noncen am besten geeignet zu sein, da sie nicht erratbar und vorhersagbar sind.
- die wiederverwendung von zufallszahlen beruht auf wahrscheinlichkeiten

Also Nonces können vorhersagbar sein, aber Random Numbers wie der Name schon mal sagt, nicht. Üblicherweise können Nonces, die zufällig gewählt werden, immer im Klartext übertragen werden. Es geht ja generell um FRESHNESS, damit keine Replay-Angriffe - guter Tipp vom Anonymen Smiley ;) - möglich sind. Wird eine Nonce wiederverwendet, kann das ursprüngliche Paket, in dem diese das erste Mal zum Einsatz kam, nicht unterschieden werden.

Damit man Random Numbers aber verwenden kann, müssen ja beide Seiten die Übersicht behalten, d.h. beide Seiten müssen Blacklists anlegen und evtl. eine neue Nummer suchen, wenn eine schon verwendete generiert wird. Natürlich werden die Blacklists (endlicher Zahlenraum für gespeicherte Nummern mit maximaler Bitzahl) auch ab und zu mal ausgedünnt, wieder ein Verwaltungsschritt mehr.

- sequenznummern erfordern nichtflüchtige Zustände, so dass ein knoten
sicher sein kann, dass es nicht zweimal die gleiche nummer verwendet. auch nach einem absturz muss dies sichergestellt werden.

Genau. Aber die Speichermenge ist dafür eng begrenzt, es reicht, sich die letzte SeqNo für jede Verbindung zu merken. Allerdings reicht speichern nicht aus, beide müssen sich auch einig sein, welche die richtige ist = Synchronizität.

nachteil: die Verwendung von echten zufallszahlen kann sehr teuer werden.
- ungeeignete zufallszahlen können dazu führen, dass ein algorithmus
oder ein protokoll, das eigentlich sicher ist, unsicher wird.

das gilt fast überall und schließt auch Session Keys ein, die ja auch zufällig erzeugt werden sollen oder auch andere Keys

Was in der Aufzählung noch fehlte sind Zeitstempel und Challenges. Zeitstempel sind so ähnlich wie Sequenznummern, nur hängt das ganze dann noch komplizierter an den Clock Drifts und die Synchronisierung ist schwieriger, siehe im VSYS-Teil dazu die üblichen Protokolle, worauf man ja auch auf die relevanten Prüfungsfragen schließen kann.

Bei Challenges muss eine syntaktische und semantische Verarbeitung vereinbart werden. Üblicherweise ist das das nicht so trivial wie Nummern erzeugen und austauschen.

Aber immer tauschen wir nur Komplexität an einer Stelle gegen Komplexität an anderer Stelle ein.

Was im sicheren Protokoll wirklich zum Einsatz kommt, hängt ja auch vom Anwendungsszenarium ab. Wenn ich bei Kerberos eh mit Zeiten und Zeitperioden arbeiten und darum eine gemeinsame Zeit brauche, dann kann ich die auch gleich als Nonce verwenden. Wenn ich einen billigen Garagenöffner bauen will, werde ich keinen teuren ClockChip mit RadioEmpfänger für die Abfrage der Atomuhren einbauen …

Beste Grüße
KPK

Die Grundidee von Nonces ist doch diese:
* Client + Server kennen dasselbe Geheimnis (Passwort)
* Der Client soll zeigen, dass er das Geheimnis kennt, ohne es zu übertragen
* Wenn ein Angreifer eine Verbindung belauscht, soll er die gewonnenen Informationen nicht nutzen können,
um sich später als der Client ausgeben zu können.

Der Server schickt die Nonce, der Client schickt msg=HASH(Nonce || Geheimnis), der Server berechnet ebenfalls den HASH und vergleicht.

Das ist tatsächlich eine Anwendung. Hier bindet die Nonce aber auch die Antwort des Clients an die Reaktion des Servers (denn der Client schickt ja das erste Paket, fehlt oben).

Wenn der Angreifer also die msg des Clients abfängt, dann wird die kein zweites Mal funktionieren, denn beim nächsten Verbindungsaufbauwunsch würde der Server eine neue (=andere und damit FRISCHE) Nonce erzeugen.

Und das ist genau die Hauptidee von Nonces: Frischheit! … und das obige Anwendungsbeispiel ist nur eins.

Angriffsszenarien:
* Dieselbe Nonce wird ein zweites Mal verwendet: Der Angreifer schickt dieselbe Antwort, die er mal mitgeschnitten hat.
* Passwort unsicher oder Hashfunktion unsicher: Angreifer kann aus Nonce + msg (eventuell mehrere Paare) das Passwort ermitteln.
* Man in the middle: Angreifer nimmt die Verbindung vom Client entgegen, baut selbst eine zum Server auf, leitet Nonce + Antwort 1:1 durch. Danach ist der Angreifer am Server authentifiziert und freut sich. Häufig kann ein Angreifer, der mithören kann, auch die Kommunikation selbst manipulieren.

Alles richtig, aber die Angriffsszenarien auf die Anwendung sind nicht 1:1 Angriffe auf Nonces. Nonces an sich wirken nur gegen Replay-Angriffe, gegen Man-in-the-Middle muss Authentisierung her.

Also was soll der ganze Noncense?!

Wiederholen Sie das Mantra: Nonces wirken gegen Replay-Angriffe!

Ich frage mich, was an Sequenznummern (z. B. Timestamp) das Problem ist. Hierdurch ist doch wenigstens garantiert, dass dieselbe Nonce kein zweites Mal verwendet wird (vorausgesetzt die Uhr geht richtig).

Exakt erkannt und damit das Problem identifiziert.

Der Angreifer kennt zwar die Nonce im Voraus, aber was gewinnt er damit?
* Kann er den Client dazu bringen, ihm die Antwort auf diese Nonce zu geben? Kann er auf demselben Weg nicht auch eine gerade erst bekannt gewordene Nonce angreifen?
* Kann er mit genügend Aufwand aus vorherigen Nonce/Antwort-Paaren und der neuen Nonce die neue Antwort berechnen?
[latex]\textnormal{msg}_0 = {\mathcal H}(\textnormal{Nonce}_0 || \textnormal{Secret}), \textnormal{msg}_1 = {\mathcal H}(\textnormal{Nonce}_1 || \textnormal{Secret}) \Rightarrow \textnormal{msg}_1 = {\mathcal H}(\textnormal{Nonce}_1 || \textnormal{Nonce}_0^{-1} || {\mathcal H}^{-1}(\textnormal{msg}_0))[/latex].
Es muss also die Möglichkeit geben, in einem Hashwert die alte Nonce durch die neue Nonce zu ersetzen. Wenn dies in akzeptabler Zeit möglich ist, würde ich mir eine neue Hashfunktion suchen.

… alles richtig, bezieht sich aber auf die Anwendung der Nonce in diesem Beispiel.

Ich sehe keine relevanten Sicherheits-Unterschiede zwischen Zufallszahlen + Timestamps. Was übersehe ich?!

Den Anwendungskontext, der unterschiedlich hinsichtlich erfüllter Voraussetzungen oder Möglichkeiten ist.

Zufallszahlen -> Blacklists
Zeitstempel -> synchrone Uhrzeiten
Zähler -> synchrone Zählerstände
Challenges -> Logik

Beste Grüße
KPK