none
ECDH mit ECDiffieHellmanCng: Zugriff aufs nicht ge-hashte Shared Secret RRS feed

  • Frage

  • Hallo Zusammen,

    Für ein SSH-Projekt in C# bin ich gerade dabei Elliptische-Kurven einzubauen und wollte hierbei auf die Klassen in .NET zurückgreifen. Größtenteils funktioniert das auch alles wie erforderlich, der ECDSA-Teil macht soweit keine Probleme.

    Nun bin ich beim SSH-Kex-Exchange-Mechanismus angekommen und in eine Sackgasse geraten. Die auf ein einzigartiges (keine andere Bibliothek gefunden die das auch so macht) Verhalten der .NET Klasse zurückzuführen ist.

    Für SSH-Kex wird ein Shared-Secret erstellt, das auf den jeweiligen Mechanismus beruht. Das machen SSH-Server und Client auf die selbe Weise und sie sollten wenn alles korrekt abläuft auf das identische Shared-Secret kommen.

    Bei ECDiffieHellmanCng ist das anscheinend nicht möglich:

    (Open)SSH berechnet hier das Shared-Secret mit OpenSSL:

    ECDH_compute_key(kbuf, klen, client_public,  server_key, NULL)

    Quelle: kexecdhs.c

    Der letze Parameter ist KDF und hier NULL, sprich kein Hash. Es wird erst später ein größerer Hash erstellt und signiert: kexecdh.c

    Vergleichbarer Code in C# .NET auf der Client-Seite, nachdem Server und Client jeweils ihren Public-Key (EC_Point) ausgetauscht haben, sähe so aus: 

     SharedKey = _privateKey.DeriveKeyMaterial(server_dh.PublicKey); 

    Aber der Rückgabe-Wert ist hier immer ein Hash-Bytes Array. Man kann nur die Art des Hashes beeinflußen und leider gibt es hier kein "NONE" oder dergleichen.

    Damit ist es nicht möglich das identische Shared-Secret wie OpenSSH (und alle anderen SSH-Server) zu berechnen und den Key-Exchange erfolgreich abzuschließen.

    Da es hier wirklich nur am letzten Schritt nun scheitert, ist das natürlich sehr ärgerlich und bevor ich nun nach Alternativen zu Microsoft's Cryptography suche, die Frage in den Raum: Ob jemand weiß wie man das eventuell doch mit ECDiffieHellmanCng hinbekommen könnte?

    Danke und Grüße



    • Bearbeitet da_rinkes Freitag, 30. November 2018 07:44
    Freitag, 30. November 2018 06:59

Antworten

  • Sehen sie sich bitte folgenden SSH-Code an: kexecdh.c

    Es ist unmöglich auf das selbe Ergebnis im gesamten Hash zu kommen, bei dem das Shared Secret ein umformatierter Teil ist.

    Schade! Dann mal nach alternativen OS Implementierungen Ausschau halten.

    • Als Antwort markiert da_rinkes Freitag, 30. November 2018 12:26
    Freitag, 30. November 2018 12:25

Alle Antworten

  • Als Zusatz:

    Prepend und Append der zusätzlichen Daten vor dem Hashen ist leider nicht möglich, da z.B. der ungehashte Shared-Key noch unformatiert werden müsste. Siehe sshbuf_put_bignum2.

    Das führt dazu, dass OpenSSH den Hash möglicherweise mit einem weiteren 00-Byte vorne berechnet, während DeriveKeyMaterial mit den unformatierten Shared-Key den Hash berechnet.

    Freitag, 30. November 2018 11:22
  • Im .net security blog wird das Verfahren illustriert: Elliptic Curve Diffie-Hellman
    dort steht auch wie die KeyDerivationFunction festgelegt wird - möglich ist Hash, Tls und Hmac, wobei Hash der Standard ist. Ein NULL gibt es demnach nicht.

    Es gibt auch noch ECDiffieHellmanCng.DeriveSecretAgreementHandle


    - Gruß Florian



    • Bearbeitet Florian Haupt Freitag, 30. November 2018 12:04 DeriveSecretAgreementHandle ergänzt
    Freitag, 30. November 2018 11:25
  • So wie ich es ja geschrieben habe. Eine schlechte Design-Entscheidung seitens Microsoft, da sie so nun die Anwender in der Interoperabilität mit anderer Software behindert.

    Und was macht man mit Handle dann? Damit kann man ja auch nur Ncrypt Operationen auf den Wert ausführen lassen, aber den Wert an sich nicht auslesen und umformatieren.

    Freitag, 30. November 2018 12:10
  • Das berechnete Secret dürfte gleich sein, es ist nur nicht Abfragbar - bleibt also geheim.

    Kurz, es gibt keinen Weg das Shared Secret abzufragen, sollte aber auch kein Problem sein, da beide Seiten zum gleichen Ergebnis kommen müssten.


    - Gruß Florian


    Freitag, 30. November 2018 12:21
  • Sehen sie sich bitte folgenden SSH-Code an: kexecdh.c

    Es ist unmöglich auf das selbe Ergebnis im gesamten Hash zu kommen, bei dem das Shared Secret ein umformatierter Teil ist.

    Schade! Dann mal nach alternativen OS Implementierungen Ausschau halten.

    • Als Antwort markiert da_rinkes Freitag, 30. November 2018 12:26
    Freitag, 30. November 2018 12:25