Datum:
Angehängte Dateien:Hallo, das Projekt ist nicht von mir selber, aber es sollte hier nicht fehlen: http://www.das-labor.org/wiki/Crypto-avr-lib Short Facts * kleine Implementierungen von Kryptofunktionen in C (fast alle Mikrocontroller) * noch kleinere Implementierungen von Kryptofunktionen in Assembler (ATmega, gnu-avr-as) * Lizenz: GPLv2 (nahezu alles) About Die crypto-avr-lib stellt ein reihe kryptographischer Funktionen für Atmels AVR Mikrocontroller zur Verfügung. Aufgrund der besonderen Begrenzungen in Mikrocontrollern (sehr wenig Speicher, sowohl RAM als auch Flash bewegen sich je nach Controller im Byte oder im unteren KiB Bereich), kann in der Regel nicht eine Standard oder Referenzimplementierung (in C) für den Mikrocontroller genutzt werden. Daher werden hier zum einen an die Anforderungen angepasste C Implementierungen zur Verfügung gestellt (die sich auch leicht auf andere Systeme portieren lassen) wie auch optimierte Assembler Implementierungen. ---Was soll rein--- Symmetrisch Block * aes (davon gibt es eigentlich schon eine Menge) * serpent * cast6 * twofish * idea * kasumi Stream * seal * A5/1 * Turing * Rabbit Hashes * ripemd Asymmetrisch * DH * RSA * ElGamal * EC * DSA ---Was ist da--- Symmetrisch Block * XTEA * CAST5 * Camellia * Skipjack * RC6 * SEED * DES * SHABEA Stream * ARCFOUR (RC4 kompatibel) Asymmetrisch Hashes * SHA-256 * SHA-1 * MD5 Sonstiges * HMAC-SHA256 (nach RFC2104) * PRNG Stand 11.07.2007/Revision 1602
Datum:
Extrem schwach kommentierter Code. Hat jemand Lust, sich damit zu beschäftigen?
Datum:
Was mich brennend interessieren würde, worin siehst Du die Anwendungsfelder für Kryptographie auf nem MC ? Mir fallen da keine ein. Ich baue hauptsächlich Systemsteuerungen und da ist man schon froh, wenn alles mit Klardaten richtig zusammenspielt. Wenn man bei der Fehlersuche dann noch alles erstmal entschlüsseln müßte, würde ich wahnsinnig, bzw. ließen sich gestörte Daten warscheinlich nicht mehr entschlüsseln. Man müßte daher die ganze Kommunikationsabsicherung erstmal in Klardaten machen, die dann einen Container transportieren, der verschlüsselte Daten enthält. Und darin überträgt man dann Temperaturen, Drücke, Spannungswerte usw. verschlüsselt, naja, sowas kann ich mir grad noch verkneifen. Peter
Datum:
Verschlüsselung ist für Firmware-Updates nicht ungewöhnlich, um unlizensierten Nachbau von Geräten inkl. Controllerfirmware zu unterbinden oder zu vermeiden, dass "gepatchte" Firmware auf das Gerät übertragen wird. Controller per Lock-Bits geschützt, Update der Firmware nur per Bootloader, der den verschlüsselt übertragenen Firmwarecode erst entschlüsselt und dann ins Flash schreibt. Weiterer Einsatzzweck: Konfiguration von Geräteparametern oder Steuereingriffe zu Testzwecken, die der Endanwender nicht verändern bzw. durchführen soll/darf. Meist reicht zur Sicherung eine PIN aber der Endanweder kann evtl. einfach mitlauschen (im einfachsten Fall UART-RX des Controllers an einen PC "abzweigen"), die PIN abfangen und damit dann selbst Parameter "manipulieren" oder Testfunktionen auslösen. Verschlüsselung evtl. inkl. Challenge-Response hilft, dies zu vermeiden. Beides wurde schon von Auftraggebern gefordert. Zumindest die Firmware-Update-Verschlüsselung scheint auch keine unübliche Forderung, sonst hätte Atmel nicht zwei Application-Note dazu herausgebracht. Verschlüsselung bei Parametereinstellungen sind m.W. auch im Automotive-Bereich nicht unüblich.
Datum:
Mir ist auch vorallem Firmware Verschlüsselung bekannt. Ich selber brauchte den md5 Algo für einen AVR Webserver um ein http Digest Auth zu implementieren.
Datum:
Hallo *, warum Kryptographie auf MC?? Nun, wenn der MC Messdaten erfasst und sie via TCP/IP an einen Host überträgt, dann könnte es schon interessant werden. Schließlich wollen wir ja sicher gehen, dass die Daten die wir bekommen auch wirklich von unserer Messstation kommen. In gesicherten Netzwerken mag das vielleicht (und selbst da hätte ich meine Zweifel!!!) nicht so die Rolle spielen, aber spätetens wenn ich anfange Daten über das Internet zu schicken, wäre die Frage wie ich die Authenzität und evtl. auch die Vertraulichkeit der Daten sicher stellen kann. Nehem wir als Beispiel den bakanntesten deutschen Wetterfrosch. Er baut Messstationen auf deren Messwerte er jeden Abend präsentiert. Wäre doch peinlich wenn er für Oberbayern im Dezember 25°C melden würde weil ihm jemand was untergeschoben hat.... Gruß Sebastian
Datum:
Ich sehe da 100 Möglichkeiten wo man die Crypt-Funktionen einsetzen könnte, wobei ich es zur Zeit selbst nicht unbedingt brauche. @ Peter: Poste es doch im CCC Forum, da wird sich manch einer freuen :)
Datum:
Peter Dannegger wrote: > Was mich brennend interessieren würde, worin siehst Du die > Anwendungsfelder für Kryptographie auf nem MC ? > > Mir fallen da keine ein. Naja, stell Dir mal vor, Du möchtest ein Zahlenschloss bauen. Die einfache Lösung dafür ist, Du baust hinter die Tastatur einen Mikrocontroller welcher den Code auswertet und dann einen Relaiskontakt schließt. Das kann man einfach dadurch überlisten, in dem man den Relaiskontakt manuell überbrückt. Um dies zu verhindern muss man das Gehäuse sehr gut bauen. Mit Kryptographie kannst du das schöner machen. Du kannst die Tastatur von der Auswertung trennen und die Kommunikation verschlüsseln. Somit muss das Teil, welches sicher sein muss, nicht mehr in der Nähe der Tastatur sein.
Datum:
Hi, ist folgende Anwendung lebensnah? Zugangskontrolle mit IR-Sender/Empänger anstatt RFID. Nach bewährtem Muster könnte man z.B. die in RFID-Verfahren eingesetzten Challenge-Response-Verfahren zur Authentifizierung verwenden. Dazu müßten beide Seiten mit einem IR-Sender & IR-Empfänger ausgestattet werden und Ver/Entschlüsselungslogik. Das hätte den Charme einer individuellen (=weithin unbekannten) Lösung und die kryptographischen Verfahren oder Schlüssel könnten auch nach Bedarf in Eigenregie ausgetauscht werden. Mir ist allerdings nicht klar, welche Datenmengen jeweils bewegt werden müssen, um so eine Kommunikation durchzuführen, d.h. ob die mit IR erreichbaren Datenraten hierfür praktisch ausreichend sind. Grüße schnack
Datum:
Auch wenn der Beitrag schon älter ist, mich würde mal interessieren, wo Peter (Gast) den Code her hat, wenn er sagt, dass er nicht von ihm ist (ist ja schon mal rühmlich, dies zumindest zu erwähnen!). Aber ich habe so den Eindruck, dass er den Schnipsel irgendwo beim Googlen gefunden hat und knallt ihn so ohne Beispiele Kommentare Implementierungsergebnisse hier rein, von der sehr dürftigen Kommentierung mal abgesehen, denn ohne diese sind die Codes nahezu nicht nachvollziebar, speziell, wenn es, wie er sagt, "gestutzte" Codes sind, die gerade noch in einen uC passen. Also etwas mehr "Background Intelligence" wäre hier im Forum schon angemessen. Zum Thema: "Worin siehst Du die Anwendungsfelder?" von Peter: Da könnten mir auch Tausend Beispiele einfallen, wenn ich darüber nachdenke, was alles so über die RFM12 Module (oder auch ähnliche) gesendet wird. Es muß ja nicht gleich die ganze Nachbarschaft wissen, was man da so treibt. Zugegeben, meinen Bank-Pin werde ich darüber noch lange nicht senden. Gruß Manni
Datum:
Manni schrieb: > Auch wenn der Beitrag schon älter ist, mich würde mal interessieren, wo > Peter (Gast) den Code her hat, wenn er sagt, dass er nicht von ihm ist > (ist ja schon mal rühmlich, dies zumindest zu erwähnen!). > sieht man doch am Link, den er angegeben hat: Das Labor, die Seite sollte eigentlich hier nicht unbekannt sein...
Datum:
So, ich möchte mich auch mal kurz dazu äußern (als Autor). Ich finde durch den Link wird eigentlich gut ausgedrückt woher das kommt (im Zweifelsfall steht das auch im Kopf der meisten Dateien). Der Code ist auch bestimmt noch nicht optimal kommentiert, aber der Code ist auch nicht dazu gedacht die Algorithmen zu verstehen, dafür sind die jeweiligen Spezifikationen gedacht. In den Dateien USAGE.blockciphers, USAGE.hashfunctions und USAGE.streamciphers wird die Verwendung der einzelnen Primitiven erklärt, diese sollten als Ausgangspunkt für die Nutzung dienen. Es sollte auch ein checkout aus dem SVN oder Bazaar genutzt werden und nicht das Zipfile aus dem ersten Posting. Wie man an so ein checkout kommt ist im verlinkten Wiki beschrieben. mit freundlichen Grüßen, Daniel
Datum:
Das Projekt ist sehr interessant. Und die Implementierung schön klein. Da der SourceCode aber unter der GPL steht, ist er für mich unbrauchbar. Ich kann es mir nicht leisten meinen SourceCode zu veröffentlichen (was ich ja müsste wenn ich Teile der lib einbaue). Dann wäre das ganze Projekt für die Tonne. :-( @ Daniel Otte Gibt es da eine Möglichkeit einer Ausnamegenehmigung?
Datum:
Ja, wer Probleme mit der GPL hat kann sich via E-Mail an mich wenden. Am besten mit ein paar Projektdetails, damit wir eine entsprechenden (Lizenz-)Vertrag erarbeiten können. mit freundlichen Grüßen Daniel
Datum:
Ok. Ich hab Ihnen eine Mail an die im Sourcecode angegebene Adresse geschickt.
Datum:
Hallo zusammen, erstmal danke für die tolle Bibliothek :) Eine Frage: Auf welchen Atmegas besteht denn die Möglichkeit RSA zu nutzen? Wie hoch ist denn der benötigte RAM-Speicher dieser Implementierung? Ich weiß nur von einer anderen Implementierung (relic-toolkit), welche fast 30 KB an Arbeitsspeicher genutzt hat ... Falls jemand hier Erfahrungswerte hat, bin ich sehr dankbar :) Gruß Stephan
Datum:
Hi Stephan, wenn ich mich richtig erinnere, hab ich damals DSA mit 1024 Bit auf einem Atmega644 (4KiB RAM) getestet. DSA benutzt wie RSA modulare exponentiation, daher sollte RSA mit 1024 Bit mit unter 4KiB RAM auskommen. Von RSA mit unter 1024 Bit ist dringend abzuraten und eigentlich sollte man schon 2048 Bit verwenden. Ein anderes entscheidendes Problem ist allerdings die Laufzeit. Ich meine auf dem Atmega644 bei 20MHz dauerte das mehrere Minuten. Ich werde mich gleich nochmal dran setzten OAEP zu implementieren und dann das ganze auf den AVR zurück zu portieren. Wenn ich dabei bin, werde ich auch mal versuchen den Speicherverbrauch zu messen. Den meisten Leuten die asymmetrische Kryptographie machen wollen empfehle ich zur Zeit die Verwendung von schnelleren ARM-Prozessoren. mfg Daniel
Datum:
Hallo Daniel, danke für deine Antwort und vorallem deine Mühe! Leider ist der Prozessor festgelegt, weshalb dies auf einem AVR laufen sollte (auch wenn die Berechnung wohl recht lange dauern dürfte ...). 1024 Bit Keys wären schon die minimale Schlüssellänge, welche für mich noch in Frage kommen würde. In Hinblick auf die Rechenzeit werde ich gegebenenfalls bewusst auf 2048 Bit Keys verzichten. Gruß und Danke Stephan
Datum:
Hallo Daniel, ich versuche im Moment deine RSA-Bibliothek auf einem Atmega644 und einem Atmega1284P zu nutzen. Leider ohne Erfolg. Mein Code sieht wie folgt aus (angelehnt an deine main-rsa-test.c):
rsa_ctx_t rsa_ctx; uint8_t testmsg[128] PROGMEM = { 0x25, 0x11, 0x1e, 0x08, 0x1c, 0x72, 0x57, 0xbf, 0x46, 0xbb, 0x56, 0xe8, 0x0b, 0x24, 0x0d, 0x72, 0x77, 0x11, 0x12, 0x10, 0xec, 0xb9, 0xe4, 0x6f, 0xe0, 0x6c, 0x83, 0x65, 0xe2, 0xe5, 0x1a, 0x3c, 0xdb, 0x6c, 0x51, 0x8d, 0xbc, 0xd0, 0x30, 0xb6, 0xca, 0x01, 0xb4, 0x03, 0x03, 0xe9, 0x86, 0x86, 0xfe, 0x76, 0x4e, 0xb7, 0x47, 0xb5, 0x06, 0x15, 0x92, 0x38, 0xc2, 0x0d, 0x3c, 0xfa, 0x53, 0xe3, 0xe3, 0x57, 0xeb, 0x34, 0xb8, 0xda, 0x7b, 0x0e, 0x06, 0x28, 0x1d, 0x4a, 0x14, 0xcc, 0x56, 0x8d, 0xf3, 0x0f, 0x40, 0x2e, 0x23, 0x45, 0xe7, 0xcd, 0xc5, 0x83, 0x8f, 0xaa, 0x55, 0x55, 0x7d, 0xbd, 0x19, 0x63, 0xbd, 0x17, 0xda, 0xfd, 0x18, 0xd1, 0x62, 0x43, 0xc7, 0x33, 0x39, 0x2c, 0xda, 0x64, 0x27, 0x96, 0xa0, 0x83, 0xa0, 0xf9, 0x3b, 0x1e, 0x17, 0x71, 0x59, 0xaa, 0x43, 0x3b, 0xeb, 0x80 }; void load_fix_rsa(void){ load_rsa_key_blob(&rsa_ctx); } int main(void) { uint8_t mw[rsa_ctx.modulus.length_B], cw[rsa_ctx.modulus.length_B], m_w[rsa_ctx.modulus.length_B]; bigint_t m,c,m_; load_fix_rsa(); m.wordv = mw; c.wordv = cw; m_.wordv = m_w; m.length_B = rsa_ctx.modulus.length_B; m.info = 0; memcpy_P(mw, testmsg, 128); bigint_changeendianess(&m); bigint_adjust(&m); rsa_enc_bigint(&c, &m, &rsa_ctx); while(1) { //TODO:: Please write your application code } } |
Ich versuche das ganze mittels JTAGICE3 zu debuggen. Das Problem ist, dass er bei "bigint_adjust(&m)" einen Fehler wirft: > # An unknown failure occurred. > # Error terminating session: Prog Mode Leave failed: > # An unknown failure occurred. > # jtagice3: Unknown event: 0xA Und direkt danach wieder ganz von Vorne beginnt. Auch ohne Debugger und dafür mit Ausgaben auf der UART scheint dieses Codestück Probleme zu machen. Habe ich irgendwas übersehen? Gruß Stephan
Datum:
Ich glaube der Fehler ist, dass du die Größe der Arrays mit rsa_ctx.modulus.length_B angibst, bevor dieser Wert durch load_fix_rsa() initialisiert wurde. Ich empfehle allerdings, noch 1-3 Tage zu warten, da ich RSA komplett umgestrickt habe (z.Zt. in der ARM-Crypto-Lib). Ich werde das Zeitnah auf die AVR-Crypto-Lib zu portieren. Dann gibt es unter anderem RSA-OAEP (PKCS#1). Ich bin gerade dabei den Code zu testen, aber insbesondere die Tests auf dem AVR werden lange dauern, daher bitte ich noch um ein wenig Geduld. mfg Daniel
Datum:
Hallo Daniel, > Ich glaube der Fehler ist argh, ja. Das kann so nicht funktionieren. > Ich empfehle allerdings, noch 1-3 Tage zu warten dann warte ich noch ab :) Vielen Dank nochmal für deine Mühe. Gruß Stephan
Datum:
Hallo Daniel, so, ich hab jetzt doch nochmal das ganze mit korrekt initialisieren Arrays testen müssen ;) . Allerdings scheint beim Entschlüsseln nicht die Klartextnachricht heraus zu kommen. Mein Code.
int main(void) { load_fix_rsa(); uint8_t mw[rsa_ctx.modulus.length_B], cw[rsa_ctx.modulus.length_B], m_w[rsa_ctx.modulus.length_B]; bigint_t m,c,m_; DDRB = 0xFF; uart_init( UART_BAUD_SELECT(UART_BAUD_RATE,F_CPU) ); sei(); uart_puts_P("INIT\n"); m.wordv = mw; c.wordv = cw; m_.wordv = m_w; m.length_B = rsa_ctx.modulus.length_B; m.info = 0; uart_puts_P("memcpy_P\n"); memcpy_P(mw, testmsg, 128); uart_puts_P("bigint_changeendianess\n"); bigint_changeendianess(&m); uart_puts_P("bigint_adjust\n"); bigint_adjust(&m); uart_puts_P("rsa_enc_bigint\n"); rsa_enc_bigint(&c, &m, &rsa_ctx); uart_puts_P("rsa_dec_bigint\n"); rsa_dec_bigint(&m_, &c, &rsa_ctx); uart_puts_P("compare\n"); if(bigint_cmp_s(&m, &m_)){ uart_puts_P("true\n"); }else{ uart_puts_P("false\n"); } PORTB |= (1<<PB1); uart_puts_P("FERTIG\n"); while(1) { //TODO:: Please write your application code } } |
Auf einem Atmega644 und einer Taktfrequenz von etwas über 7 MHz habe ich folgende Laufzeiten feststellen können: rsa_enc_bigint: ca. 30-40 Sekunden rsa_dec_bigint: ca. 45 Minuten Allerdings liefert:
if(bigint_cmp_s(&m, &m_)) |
false zurück. Sind denn die Laufzeiten einigermaßen plausibel? 45 Minuten zum Enschlüsseln kommen mir schon relativ lange vor ... //Nachtrag: Die Schlüssellänge betrug 1024 Bit Gruß Stephan
Datum:
Hi Stephan, als mögliche Fehlerquelle fällt mir ein, dass evtl. deine test-nachricht größer als N, also der Modulus ist. Ich mag auch nicht ausschließen, dass in der bigint-Bibliothek noch Fehler sind (ich bin mir eher sicher, dass da noch welche sind, ich hab nämlich noch Fehler in der ARM-Variante gefunden). Ich meine, dass so Zeiten um 17min normal waren zum entschlüsseln. Das wird aber noch besser werden. Ich möchte aber dringend_ davon _abraten direkt diese Variante von RSA zu benutzen. Die Verwendung von Plain-RSA bringt einen Haufen von Sicherheitsproblemen mit sich. Normalerweise kapselt und kodiert man die Nachricht speziell und wendet dann die Exponentiation an. mfg Daniel
Datum:
Hallo Daniel, Die Testnachricht und der Modulus waren gleich groß. Ich habe einfach deine Testnachricht aus "main-rsa-test.c" kopiert. Das sollte dann für den 1024-Bit-Key eigentlich passen.
#define N_LEN_B (16*8) |
und
uint8_t testmsg[128] PROGMEM = {
|
Ich würde daher tatsächlich auf einen Fehler in der Bigint-Bibliothek tippen. Bezüglich neuer Bibliothek: Ich werde auf die neue Version warten. Allerdings wollte ich (nachdem ich eh schon so viel probiert habe) noch ein paar Experimente mit der jetzigen Version durchführen. Gerade auch um ein Gefühl dafür zu bekommen, wie lange der Prozessor tatsächlich für die Durchführung der Operationen benötigt ;) Im Moment versuch ich noch deine DSA-Implementierung zu nutzen. Fragt sich nur, ob diese funktionieren wird ... immerhin greift sie auf dieselbe Bigint-Library zurück. Aber ich werde das einfach mal testen :) Die Fehler in der Bigint-Lib sind in deiner ARM-Version behoben? Sprich ich könnte z.B. versuchen die ARM-Version der Bibliothek zurück zu portieren? Gruß Stephan
Datum:
Hallo Daniel, also DSA passt. Ich konnte eine erstellte Signatur erfolgreich überprüfen :) Dauer bei 512-bit-Keys und 7,xx MHz: dsa_sign_message: 2:30 min dsa_verify_message: 5:20 min Ich werde die Geschwindigkeit mal mit ECDSA vergleichen. Das war in meiner Erinnerung auf dem AVR nämlich recht schnell. Gruß Stephan
Datum:
Hi Stephan und alle anderen Interessierten, ich habe soeben RSA-OAEP eingecheckt. RSA-PKCS#1-v1.5 wird gerade getestet. Tut mir leid, dass es nun doch länger gedauert hat. Ich war überrascht, dass es so viele Veränderungen im GCC und der avr-libc gab, dass die Bibliothek nicht mehr gebaut hat. Daher musste ich zunächst viel Arbeit darein investieren, alles auf Vordermann zu bringen. Und da ich so viel Source-Code angefasst habe, musste das ganze auch nochmal getestet werden. Insgesammt wurden mehrere Bugs beseitigt, und ich bin recht zuversichtlich, dass RSA-OAEP gut funktionieren wird (habe bisher nur die Testvektoren von RSA benutzt, der NESSIE-Test muss noch, aber das wird lange dauern). 1024 Bit hat auf einem ATmega644 (4KiB RAM) @ 20MHz funktioniert. Zur groben Orientierung, habe ich Zeiten um 30-40s für das Verschlüsseln und ca. 4-5min für das Entschlüsseln beobachtet. Die Umsetzung in Assembler wird wohl die Geschwindigkeit verdoppeln, und die Code-Size halbieren (dass sind grobe Werte die in etwa dem entsprechen, was bei anderen Algorithmen passiert ist). Zudem plane ich in nächster Zeit, den Reduktions-Algorithmus zu verbessern, der ist im Moment noch sehr rudimentär. 1536 Bit hat übrigens mit 4KiB nicht mehr funktioniert. 2048 Bit hat auf meinem Ethernut 2.1 (ATmega128 (4KiB RAM) + externes RAM) funktioniert. Ich meine dabei allerdings Zeiten um 45min für das entschlüsseln gemessen zu habe. mfg Daniel
Datum:
Hallo Daniel erstmal vielen vielen Dank für all deine Mühe! Ich werde mir deine neue Library auf jeden Fall ansehen. Asymmetrische Kryptographie auf einem Atmega scheint schon eine ziemlich grenzwertige Sache zu sein. Da ist natürlich auch der Einsatz zusätzlicher ICs interessant, welche solche Kryptographie von sich aus schon anbieten und in Hardware implementiert haben. Gruß Stephan
Datum:
Hat mal jemand die Geschwindigkeit mit http://www.basiccard.com/ verglichen ? Würde mich interessieren.
E-Mail-Benachrichtigung einschalten
Neu: Seitenaufteilung einschalten