AES-128 lib

[A.Harrenberg]

Hi Rudi,

die Verschlüsselung von ZWave basiert auf AES-128 und bei S2-Security auch auf Curve25519. Ersteres habe ich für die S0-Security mit Crypt::Rijndael implementiert, für Curve gibt es auch ein Crypt::Curve25519 Modul.

Für S2 sind verschiedene Methoden von AES nötig, nach meinem bisherigen Stand mindestens: AES-128 als Basis, AES-128 CCM und AES-128 CMAC. Für CMAC sind z.B. sub-keys nach RFC 4493 zu berechnen, auf der Suche nach der RFC und einer Implementierung bei der ich evtl. "abschauen" kann bin ich dann auf einen FHEM-Codeschnipsel vom EnOcean-Modul gestossen.

Ich habe jetzt zwar für meinen Test angefangen das selbst zu implementieren, allerdings wäre es ja irgendwie geschickter das global in FHEM zu implementieren. Soweit ich weiß basiert die Verschlüsselung von HomeMatic ja auch auf AES, die von ZigBee denke ich auch, und es lassen sich wahrscheinlich noch weitere Module finden die AES nutzen.

Allerdings könnte es Unterschiede in der Nutzung der Sub-Modes geben, auch könnten evtl. einige initialisierungen unterschiedlich sein, dazu müsste man sich die einzelnen Protokolle genauer ansehen. Auch die Definition ob die Ein- und Ausgabegrößen nun "gepackt" und "ungepackt" übergeben werden dürfte uneinheitlich sein. (Das könnte man aber mit geeigneten "Wrapper"-Funktionen lösen)

Wie siehst Du das, sollte jedes Modul für sich selbst "sorgen" oder ist eine globale AES-library anzustreben?

Für meine jetzigen "offline" Tests würde ich das wohl erst mal selbst implementieren, auch um besser zu verstehen was da passiert, für die Integration in FHEM könnte man aber versuchen das als externes modul anzubieten.

Ob andere Modulauthoren bereit wären Ihren Code anzupassen und auf ein externes Modul zurückzugreifen steht erst mal auf einem anderen Blatt. Absicherung/Validierung der Implementation auch...

Gruß,
Andreas.

[rudolfkoenig]

Wenn die AES-Bibliothek so eine sub-key Berechnung nicht anbietet, und dafuer auch kein fertiges Perl-Modul existiert, dann kann man natuerlich ueberlegen, das in ein gemeinsam genutztes .pm auszulagern, wenn wenigstens 40 Zeilen dadurch gespart werden. Ich frage mich, wieso das nicht im AES-Perl Modul implementiert ist.

Einen duennen Wrapper um existierende AES-Perl-Module zu bauen finde ich nicht gut: in meinem Kopf ueberwiegen noch die Nachteile.

[A.Harrenberg]

Hi Rudi,
ich bin da auch noch etwas unschlüssig, vor allem das ich mir bei den Begriffen nicht ganz sicher bin...

Crypt::Rijndael unterstützt die folgenden Modes:

Code Auswählen Erweitern

Use these constants to select the cipher type:
MODE_CBC - Cipher Block Chaining
MODE_CFB - Cipher feedback
MODE_CTR - Counter mode
MODE_ECB - Electronic cookbook mode
MODE_OFB - Output feedback
MODE_PCBC - ignore this one for now :)


Laut Spezifikation von S2 benötigt man AES-128 CCM was laut Wiki Counter Mode CTR mit CBC-MAC, wobei ich bisher nicht ganz sicher bin was diese CBC-MAC in diesem Fall genau definiert.
Der AES-128 CMAC mode in S2 sieht für micht so aus wie ein CBC mode mit einer besonderen Verschlüsselung des letzten Blocks zur Generierung der MAC.

Egal wie, diese MAC modes sind nicht Bestandteil von Rijndael...

Wobei ich aber mittlerweile auch eine Quelle gefunden habe das z.B. ZigBee nicht CCM sonder CCM* nutzt, d.h. da geht das dann auch schon wieder auseinander und kann nicht vereinheitlich werden.

Wir können diese Diskussion ja auch erst mal vertagen bis ich die Verschlüsselung überhaupt hinbekommen habe, danach verstehe ich hoffentlich besser welche Modes wo/wie verwendet werden.

Gruß,
Andreas.

[rudolfkoenig]

Das ist auch mein Problem mit AES: der Grund-Algorithmus ist klar und relativ einfach zu verwenden, aber wie man sie dann ganz konkret parametrisiert, ist entweder nicht dokumentiert, oder mit einem selbst-erfundenen Kuerzel.

[A.Harrenberg]

Hi Rudi,
AES-128 CMAC ist in der Spezifikation von S2-Security mit "Bild" erklärt, allerdings versteht man das ohne den RFC4493 gelesen zu haben nicht, da im Bild als Eingang "key1 or key2" steht, was man fälschlicherweise als eine OR-Verknüpfung der beiden Sub-Keys ansehen könnte (deren Herkunft/Berechnung aber auch nur aus der RFC zu verstehen ist). Richtig ist aber das man ENTWEDER key1 ODER key2 nutzen muss, abhängig vom MSB des letzten Verschlüsselungsblocks...

AES-128 CCM ist in der S2 Spec ohne Bild drin, hier muss ich mir den Text noch mal genauer ansehen.

Aber ja, die ganzen Kürzel sind nicht einheitlich und je nach Quelle auch unterschiedlich erklärt. Immerhin sind in der S2-Spec Referenzen zu weiteren Quellen angegeben (wie der RFC 4493) sodass ich hoffe das sich nach Sichtung der ganzen Referenzen etc. das ganze doch noch auflösen lasst.

Gruß,
Andreas.

[kaihs]

Hallo,

das Thema ist zwar schon älter aber aktuell für mich interessant.

Um neuere Verschlüsselungsarten im 36_WMBUS Modul zu implementieren benötige ich auch eine AES-CMAC Implementierung gemäß RFC 4493.
Seit ihr bei dem Thema weiter gekommen?

Es gibt ein perl Modul Digest::CMAC, aber ich bin mir nicht sicher, ob das den selben Algorithmus implementiert.