Cryptography Engineering, Teil 4: AES auf AVR ATmega

Interpreter

Anzeige

Die Steuerung des Mikrocontrollers erfolgt über einen Kommandozeileninterpreter aes8term. Das Programm liegt im Verzeichnis aes8term-1.00 und erwartet eine POSIX/Unix-kompatible Umgebung. Unter Windows – wie für die folgende Simulation notwendig – läuft es problemlos unter Cygwin. Den Build des Programms übernimmt die Kommandofolge ./configure && make. Das Programm des Mikrocontrollers versteht einige per serieller Schnittstelle übertragene Kommandos:

  • T für einen AES-Test,
  • v für die Ausgabe der Softwareversion,
  • e<String>\n\r für einen simplen Echo-Service, der den übergebenen String einfach wieder zurückschickt, und
  • #<Kryptogramm>\n\r für verschlüsselte Kommandos.

Die per # übertragenen Kommandos steuern das Verhalten der Ampelsteuerung. Sie sind kritisch für das Verhalten des Systems. Das AVR-System akzeptiert diese nur verschlüsselt:

  • 0 bzw. 1 für "Ampel stoppen/starten",
  • s1 bis s4 zum Setzen der Geschwindigkeit der Ampel über den Prescaler von TIMER1, und
  • h für Hack, die alle Ampeln auf grün schaltet.

aes8term ist ein unter Cygwin laufendes Terminalprogramm, das die komfortable Steuerung übernimmt. Es erwartet als Parameter lediglich den seriellen Port /dev/ttyS?? und den verwendeten AES-Schlüssel als hexadezimalen Wert. Im EEPROM liegt gemäß eeprom.c der Schlüssel 000102030405060708090A0B0C0D0E0F101112131415161718191A1B1C1D1E1F.

Das Programm aes8term nutzt die aes32bit-Bibliothek aus Teil 2 dieser Artikelreihe. Das zeigt auch, dass die beiden AES-Implementierungen kompatibel sind; auch wenn das zu erwarten war. Die Funktionsweise von aes8term ist im Wesentlichen selbst erklärend. Neben der mit dem vorherigen Artikel nachvollziehbaren AES-Kryptografie besteht das Programm hauptsächlich aus POSIX/Unix-konformen Arbeiten mit dem seriellen Port.

Die gesamte AVR-Schaltung inklusive seriellem Terminal lässt sich mit den Programmen AVR Studio 4 mit installiertem WinAVR, HAPSIM und com0com auf einem Windows-PC emulieren. Die Grundlage der Simulation bildet das Gespann aus dem Simlator/Debugger aus AVR Studio 4, der die ATmega32-MPU emuliert. HAPSIM bildet die Peripherie in Form der Ampel-LEDs an Port A sowie den USART nach. com0com wiederum ermöglicht es den per HAPSIM emulierten seriellen Port auf einen virtuellen Port umzuleiten, um so ein echtes Terminalprogramm, wie aes8term darauf zu verbinden. Die Grundsimulation und das Zusammenspiel der Programme ist bei "Cogito ergo sum" beschrieben. Sobald diese Umgebung grundsätzlich funktioniert, folgt die Vorbereitung für aes8term beziehungsweise das eingesetzte Cygwin.

Hierzu erhält das com0com-Setup zunächst ein weiteres virtuelles Portpaar (siehe Abbildung 3). Der virtuelle Port auf der AVR-Seite erhält den Namen AVR0. Der virtuelle Port für Cygwin bekommt zwingend den Namen eines freien COM-Ports. Das liegt daran, dass Cygwin serielle Ports lediglich in Form von COMxx: als /dev/ttySxx abbilden kann. Im Beispiel aus Abbildung 3 ist COM18: angegeben, der als /dev/ttyS17 unter Cygwin ansprechbar ist.

com0com-Setup für die virtuelle serielle Verbindung von AVR-Simulation zu Cygwin (Abb. 3)

Nach dem Laden des Projekts aes8bit-1.00\avr\aes8bit.aps von AVR Studio 4, startet der Debugger über das Menü Debug | Start Debugging. Es folgt die Frage, ob das simulierte EEPROM mit den Daten aus eeprom.c initialisiert werden soll. Ein Klick auf die Schaltfläche Ok lädt die Daten und damit den AES-Schlüssel. Der Debugger ist nun aktiv und steht am Anfang der Funktion main(). Jetzt ist HAPSIM zu starten und die aes8bit-1.00\avr\hapsim.xml-Datei zu laden. Falls der virtuelle COM-Port nicht COM18: lautet, ist analog zum Artikel "Simulation Of Serial Connections In Avr Studio 4" der COM-Port für USART1 in HAPSIM anzupassen.

Auf den virtuellen seriellen Port verbindet sich nun aes8term mit folgendem Befehl in Cygwin:

./aes8term.exe /dev/ttyS17
000102030405060708090A0B0C0D0E0F101112131415161718191A1B1C1D1E1F

Ist der COM-Port nicht COM18:, ist auch die Angabe /dev/ttyS17 entsprechend anzupassen. Zu beachten ist hier, dass die Nummerierung für die ttyS*-Devices mit null beginnt, wohingegen die COM-Ports beginnend mit eins aufwärts nummeriert werden. COM1: entspricht also /dev/ttyS0, COM2: /dev/ttyS1 und so weiter.

Die von HAPSIM simulierte Ampelschaltung in Aktion (Abb. 4)

Sowohl die simulierte MPU (Micro-Processor Unit) als auch die Peripherie sind nun bereit. Ein Klick auf den Menübefehl Debug | Run in AVR Studio 4 startet nun die Simulation. Das Terminal in Cygwin zeigt die ersten Ausgaben, und die simulierte Ampel startet ihr Werk (siehe Animation in Abbildung 4). Nun lassen sich Befehle im aes8term absetzen und so an den simulierten ATmega32 schicken. Der Befehl help gibt eine kurze Hilfe aus. Die nicht verschlüsselten Befehle wie echo jpn lassen sich auch mit falschem AES-Schlüssel absetzen. Die verschlüsselten, wie speed 4, funktionieren nur mit dem passenden AES-Schlüssel. Ein Test mit einem anderen Schlüssel auf der Kommandozeile demonstriert das deutlich. Als Erstes ist in der Simulation sinnvoll der Befehl speed 1 abzusetzen, da die Simulation wesentlich langsamer als eine echte Schaltung ist. Damit startet die Ampel in akzeptabler Geschwindigkeit. Der Rest sei der Experimentierfreude überlassen.

Anzeige