ECC (ECDSA) möglich?

[Transcendence]

Hallo,

Für VPN, action-handler-Mail, Config-Webseiten etc.: Können Lancom-Router moderne EC-Zertifikate verwenden (und ECDSA einsetzen) oder können sie ausschließlich RSA?


Viele Grüße
Transcendence

[alf29]

Moin,

Im SSL/TLS ist in der 10.20 Support für Zertifikate mit EC-Schlüssel theoretisch drin, wenn Du die entsprechenden Signaturverfahren einschaltest. Du wärst aber vermutlich der erste, der das ausprobiert, und Du wirst mit entsprechenden Überraschungen rechnen müssen Generell habe ich den Eindruck, daß die Verbreitung von Zertifikaten mit etwas anderem als RSA-Schlüsseln in der Praxis noch gegen Null tendiert...

Viele Grüße

Alfred

[GrandDixence]

und Du wirst mit entsprechenden Überraschungen rechnen müssen

Ich versuchte vor einigen Jahren irgend so ein exotisches asymmetrisches Schlüsselverfahren (DSA glaub ich...) für die "Digitale Signatur" des Webinterface (HTTPS). Ich durfte dann das Gerät (1781EF) als Garantiefall an LANCOM einschicken, da sich das Gerät selbst nach dem Hardware-Reset beim Aufstarten abstürzte und nie mehr hoch kam... Ich habe dieses Gerät nie mehr gesehen...

Soll das DSA-Verfahren und der darauf basierenden asymmetrisches Kryptosysteme (ECDSA) für digitale Signaturen eingesetzt werden, ist der Einsatz eines zuverlässigen Hardware-Zufallsgenerator absolut zwingend Pflicht! Siehe auch:

- In für IT-Fachpersonen verständlicher deutscher Sprache:
https://www.golem.de/news/verschluessel ... 457-6.html

https://www.golem.de/news/dan-j-bernste ... 11605.html

- In nur für Kryptologen verständlicher Sprache (BSI TR-02102-1, Kapitel :
https://www.bsi.bund.de/DE/Publikatione ... x_htm.html

Die LANCOM-Router mit einem modernen FreeScale-Prozessor erfüllen, dank dem integrierten Hardware-Zufallsgenerator, diese zwingende, sicherheitsrelevante Voraussetzung. Moderne Laptop erfüllen dank dem in der CPU integrierten Hardware-Zufallsgenerator (AES-NI/RDRand) ebenfalls diese Voraussetzung.

Ist man nicht sicher, ob alle Kommunikationspartner der verschlüsselten Kommunikation über einen zuverlässigen Hardware-Zufallsgenerator verfügen und deren Software (auch an Verschlüsselung aufbrechende Software wie Anti-Virus, TLS/SSL-Proxy und all diesen Schrott denken) als Quelle von Zufallszahlen auch den Hardware-Zufallsgenerator miteinbezieht, sollte aus Sicherheitsgründen für digitale Signaturen (das gute alte) RSA eingesetzt werden! Dies gilt insbesondere für Virtuelle Maschinen wie VMWare, VirtualBox, KVM, Xen, Hyper-V etc.

https://www.heise.de/security/artikel/E ... 09009.html

https://www.heise.de/security/meldung/N ... 53716.html

[alf29]

Ich versuchte vor einigen Jahren irgend so ein exotisches asymmetrisches Schlüsselverfahren (DSA glaub ich...) für die "Digitale Signatur" des Webinterface (HTTPS).

DSA-Zertifikate hat das TLS im LCOS nie unterstützt - und wird es wohl auch nicht mehr. Das Thema ist inzwischen wohl durch...

Ich durfte dann das Gerät (1781EF) als Garantiefall an LANCOM einschicken, da sich das Gerät selbst nach dem Hardware-Reset beim Aufstarten abstürzte und nie mehr hoch kam... Ich habe dieses Gerät nie mehr gesehen...

Bei mir ist dieses Gerät oder dieses Thema jedenfalls nie angekommen. Falls Du den PKCS-Container noch hast, kannst Du ihn mir ja mal schicken...

Viele Grüße

Alfred

[Transcendence]

Hallo alf29,

Im SSL/TLS ist in der 10.20 Support für Zertifikate mit EC-Schlüssel theoretisch drin, wenn Du die entsprechenden Signaturverfahren einschaltest. Du wärst aber vermutlich der erste, der das ausprobiert, und Du wirst mit entsprechenden Überraschungen rechnen müssen

ah, ok, dann bin ich gespannt - schön, das es in dieser Richtung weiteregeht.

Generell habe ich den Eindruck, daß die Verbreitung von Zertifikaten mit etwas anderem als RSA-Schlüsseln in der Praxis noch gegen Null tendiert...

Ja, einige Jahre lang ging es nicht recht voran damit. So langsam scheint sich das zu ändern: Unser Mailserver hat den Logs zufolge inzwischen jede Menge Verbindungen mit Clients, die Ciphersuites mit ECDHE-ECDSA-xxx akzeptieren, und auch Mailserver, an die wir senden, vereinbaren mit unserem Mailserver schon häufig solche Verbindungen. Auch bei https-Verbindungen sehe ich das immer öfter.

Endgeräteseitig scheint das ja schon länger zu funktionieren: Ich habe hier noch ein Schubladen-Samsung Galaxy S4 aus ich glaube 2013 rumliegen, dessen Original-Webbrowser TLSv1.2-Verbindungen mit ECDHE-ECDSA-AES128-GCM-SHA256 zu unserem heutigen Webserber beherrscht. Mir ist kein Webserver in der freien Wildbahn aus der Zeit gegenwärtig, der das angeboten hätte. Dennoch funktioniert es einwandfrei, das Gerät war schon damals so weit. Bei SSl Labs finden sich auch jede Menge ältere Geräte und Browsersoftware, die das schon lange beherrschen.

Aus Gründen der Rückwärtskompatibilität wird natürlich fast immer parallel auch RSA angeboten (machen wir auch so). Gleichzeitig scheinen immer mehr Server mittlerweile so konfigurert, das sie die neuen Ciphersuiten präferieren. Da bewegt sich gerade etwas.

Schönen Abend!
Frank

[alf29]

Moin,

ah, ok, dann bin ich gespannt - schön, das es in dieser Richtung weiteregeht.

Beabsichtigst Du selber, etwas in der Richtung zu machen? Wenn nein, dann wird vermutlich gar nichts in der Richtung passieren, und das Feature wird im LCOS im jetzigen Zustand liegen bleiben, wie es ist. Die Entwickler haben hier sowieso immer zeitlich "landunter", also kriegen nur die Themen Beachtung, wo aktuell Kundenszenarien dran hängen...bitte nicht übelnehmen, aber so läuft das halt leider...

Viele Grüße

Alfred

[Transcendence]

Hallo Alfred,

ich war ein paar Wochen verhindert. Nein, das nehme ich nicht übel. Es wäre schön rund wenn man irgendwann mal konsistent auf neuere Verfahren umstellen könnte. Dringend ist das aber nicht, insofern kann ich nachvollziehen, dass das momentan keine Priorität hat. RSA bleibt ja weiterhin erprobt und sicher. Es soll bei den aktuellen Schlüssellängen sogar schneller sein? Ich schau mir mal an, was geht.

Schönes Wochenende!
Frank

[alf29]

Moin,

RSA bleibt ja weiterhin erprobt und sicher. Es soll bei den aktuellen Schlüssellängen sogar schneller sein? Ich schau mir mal an, was geht.

Also zumindest bei den analogen Verfahren fürs Key-Agreement (DH versus ECDHE) ist man mit elliptischen Kurven deutlich schneller unterwegs als mit "klassischem" Diffie-Hellman. So deutlich, daß das Key-Agreement auf Basis elliptischer Kurven bei den neuen WPA3-Verfahren (OpenEnhanced bzw. SAE) mandatory ist, FFC ist nur optional und kaum einer macht's. So ähnlich sieht es bei TLS 1.3 aus, ECDHE auf Basis der Curve25519 scheint quasi der Standard zu werden.

Viele Grüße

Alfred