Abschlussbericht

BSI, Bonn
IHP, Frankfurt (Oder)
Abschlussbericht
Trusted Sensor Node
Version 1.00
13. Oktober 2011
IHP: Prof. Dr. Peter Langendörfer / Frank Vater / Thomas Basmer / Oliver Stecklina
BSI: Frank Gehring, Christian Wieschebrink

2
Abschlussbericht
Trusted Sensor Node

Inhaltsverzeichnis
1 Einleitung 13
1.1 Beschreibung des Gesamtsystems . . . . . . . . . . . . . . . . . . . . . . . 14
2 Hardware 15
2.1 Beschreibung der Teilkomponenten . . . . . . . . . . . . . . . . . . . . . . . 15
2.2 LEON2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.3 AMBA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.4 Konfigurationsregister . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.5 Memory-Controller und Integration der Hardwarebeschleuniger . . . . . . . 18
2.6 Speicher . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.7 Parallel I/O-Port . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.8 UART . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.9 DSU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.10 Interrupt-Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.11 Timer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.12 Memory-Like Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.13 AES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.13.1 Arithmetische Grundlagen . . . . . . . . . . . . . . . . . . . . . . . . 23
2.13.2 Algorithmusbeschreibung des AES . . . . . . . . . . . . . . . . . . . 24
2.13.3 Implementierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.14 ECC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.14.1 Arithmetische Grundlagen . . . . . . . . . . . . . . . . . . . . . . . . 27
2.14.2 Multiplizierer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.14.3 Reduktion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.14.4 System-Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.14.5 Parameter im TSN . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.15 SHA-1 / PRNG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.15.1 Secure Hash Algorithmus . . . . . . . . . . . . . . . . . . . . . . . . 33
2.15.2 Pseudo Random Number Generator (PRNG) . . . . . . . . . . . . . 36
2.15.3 Hardwarebeschreibung . . . . . . . . . . . . . . . . . . . . . . . . . 37
2.16 SPI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
2.17 Pads und Pins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
2.18 Vom VHDL zum ASIC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
2.19 Layoutgenerierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
2.20 Boardbeschreibung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
2.21 Systemtest und Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
2.22 Energie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
2.23 Debug- und Diagnoseschnittstellen . . . . . . . . . . . . . . . . . . . . . . . 44

Abschlussbericht
Trusted Sensor Node
3 Software 45
3.1 Das Betriebssystem eCos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.1.1 eCos im Detail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.1.2 Hinzufügen von Komponenten . . . . . . . . . . . . . . . . . . . . . 48
3.1.3 build-Prozess . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4 Softwarearchitektur des TSN 57
4.1 Gerätetreiber . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
4.1.1 UART Treiber . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
4.1.2 SPI Treiber . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
4.1.3 MMIO Treiber . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
4.1.4 General Purpose Input/Output (GPIO) Treiber . . . . . . . . . . . . . 61
4.2 Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
4.2.1 CryptAPI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
4.2.2 SensorAPI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
4.3 Protokollstapel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
4.3.1 lightweight IP Stack . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
4.3.2 Point to Point Protocol (PPP) . . . . . . . . . . . . . . . . . . . . . . 66
4.3.3 Bluetooth Stack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
4.3.4 Sensor Protokoll . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
4.4 TSN Threads . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
4.4.1 Bridge Thread . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
4.4.2 Schlüsselaustausch Thread . . . . . . . . . . . . . . . . . . . . . . . 70
4.4.3 Sensorik Thread . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
4.4.4 Management Thread . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
5 Simulation und Messergebnisse 73
5.1 Ziel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
5.2 Messaufbau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
5.3 Messprogramm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
5.4 Messungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
5.5 Lebensdauertest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
6 Future Work 77
6.1 System-Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
6.1.1 Mikrokern-basierter TSN mit Security Compartments . . . . . . . . . 78
6.1.2 Trusted Computing . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
6.1.3 TCP/IP Netzwerk-Stack . . . . . . . . . . . . . . . . . . . . . . . . . 90
6.2 Optimiertes Hardwarekonzept . . . . . . . . . . . . . . . . . . . . . . . . . . 95
6.2.1 Einfügen neuer Komponenten . . . . . . . . . . . . . . . . . . . . . 96
6.2.2 Veränderungen an vorhandenen Komponenten . . . . . . . . . . . . 100
6.2.3 Schutzkonzept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
6.3 Energieversorgung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
6.3.1 Einführung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
6.3.2 Boardkomponenten . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
6.3.3 Alternativen zur Energieversorgung aus Primärbatterien . . . . . . . 112
Abkürzungsverzeichnis 115
4

Abschlussbericht
Trusted Sensor Node
Literaturverzeichnis 117
5

Tabellenverzeichnis
1.1 Eigenschaften des TSN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.1 Signale eines Memory-Like Interface . . . . . . . . . . . . . . . . . . . . . . 22
2.2 Struktur des Kontrollregisters . . . . . . . . . . . . . . . . . . . . . . . . . . 38
2.3 Adressen der SHA-1-Register . . . . . . . . . . . . . . . . . . . . . . . . . . 39
2.4 Simulation der Leistungsaufnahme für Einzelkomponenten und das Gesamtsystem
bei 16 MHz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.1 Speichergrößen verschiedener Konfigurationen von eCos 3.0 . . . . . . . . 45
4.1 Konfigurationskommandos des MMIO Treibers . . . . . . . . . . . . . . . . 61
4.2 AT-Kommandos des Bluebear SP-S . . . . . . . . . . . . . . . . . . . . . . 68
5.1 Messungen der Stromaufnahme für den AES . . . . . . . . . . . . . . . . . 76
5.2 Messungen der Stromaufnahme für den ECC . . . . . . . . . . . . . . . . . 76
6.1 Vergleich verschiedener Multiplizierer für Punktmultiplikation der ECC Komponente
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104

Abbildungsverzeichnis
1.1 Anwendungsbeispiel des TSN . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.1 Blockschaltbild des TSN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.2 Grafische Darstellung der fünfstufigen Pipeline des LEON2 (entnommen
aus LEON2 Processor User’s Manual) [3] . . . . . . . . . . . . . . . . . . . 17
2.3 Aufbau des AMBA-Bus-Systems im TSN . . . . . . . . . . . . . . . . . . . . 17
2.4 Verwendung eines AES-Blocks mit einem memory-like Interface . . . . . . 19
2.5 Schlüsseladdition für 128 Bit . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.6 Schematischer Aufbau der AES-Implementierung . . . . . . . . . . . . . . . 24
2.7 Spaltenweise Generierung des nächsten Rundenschlüssels . . . . . . . . . 26
2.8 Da das Ergebnis einer Multiplikation länger als die maximale Feldlänge ist,
benötigt man einen Reduktionsschritt, der das Ergebnis innerhalb des Feldes
reduziert. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.9 Blockschaltbild des 233-Bit-ECC-Beschleunigers. Ein 233 Bit breiter, von
einer Controller-Einheit kontrollierter Bus verbindet die Rechen- und Registereinheiten.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.10 Resultate der verschiedenen ECC-Beschleuniger-Schaltungen. Die Balken
zeigen die benutzte Siliziumfläche. Die Linien entsprechen dem Energieverbrauch.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.11 Ablauf der Signatur mit Hilfe von Soft- und Hardware . . . . . . . . . . . . . 33
2.12 Blockschaltbild des SHA-1-Moduls . . . . . . . . . . . . . . . . . . . . . . . 37
2.13 Gehäuse des TSN vom Typ QFP128 . . . . . . . . . . . . . . . . . . . . . . 40
2.14 Test eines entwickelten Hardware-Modells . . . . . . . . . . . . . . . . . . . 41
2.15 Layout des TSN-Chip nach der Verdrahtung. Insbesondere die Verdrahtung
auf den beiden obersten Metallebenen (hier: gelb und braun) treten hervor 41
2.16 Analyse der Leistungsaufnahme des Gesamtsystems (rot) sowie selektierter
Einzelkomponenten. Der grüne Plot zeigt exemplarisch den deutlich erhöhten
Stromverbrauch des ECC-Beschleunigers in seiner Aktivitätsphase. 43
3.1 eCos-Systemarchitektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.1 Softwarearchitektur des TSN . . . . . . . . . . . . . . . . . . . . . . . . . . 57
4.2 SPI Chip Select . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
4.3 Die Protokollstapel des TSN . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
4.4 Zustandsautomat der Sensorüberwachung . . . . . . . . . . . . . . . . . . 71
4.5 Management der TSN Threads . . . . . . . . . . . . . . . . . . . . . . . . . 71
6.1 Auswirkung von Fehlern in Betriebssystemen ohne Security Compartments 79
6.2 Schutz von Betriebssystemkomponenten durch Security Compartments . . 79

Abschlussbericht
Trusted Sensor Node
6.3 Aufteilung von Diensten und Services in monolithischen und µKern-Betriebssystemen
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
6.4 Integration des Sicherheitsmoduls in den Trusted Sensor Node (TSN) . . . 83
6.5 Trusted Boot eines L4-basierten Systems mit Signatur-basierter Modulauthentifizierung
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
6.6 Kryptographisch gesichertes Programmcode Update . . . . . . . . . . . . . 87
6.7 Kategorisierung der Ansätze zur Verbesserung der TCP-Performanz in heterogenen
Netzwerken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
6.8 Anzahl der in den drahtlosen Kanal gesendeten Bytes in Abhängigkeit von
der Anzahl der Übertragungswiederholungen im Medium Access Control
(MAC) und der Bitfehlerrate (BER) . . . . . . . . . . . . . . . . . . . . . . . 95
6.9 Datenrate in Abhängigkeit von der Paketgröße auf MAC bzw. Transmission
Control Protocol (TCP) Ebene, und der Bitfehlerrate (BER) . . . . . . . . . 96
6.10 Clockgating-Controller bestehend aus Latch und OR-Gatter . . . . . . . . . 97
6.11 Finite-State-Machine mit 5 Zuständen . . . . . . . . . . . . . . . . . . . . . 98
6.12 Zunahme der Leckströme bei Verkleinerung der Strukturgröße[1] . . . . . . 98
6.13 Darstellung eines Power-Gating-Controllers . . . . . . . . . . . . . . . . . . 99
6.14 Darstellung einer Power-Gating Architektur . . . . . . . . . . . . . . . . . . 99
6.15 Veränderte Anbindung der kryptografischen Komponenten zwischen Memory-
Controller und Speicher . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
6.16 BGA-Gehäuse (Unterseite) . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
6.17 TSN in einem offenen PQFP-128-Gehäuse . . . . . . . . . . . . . . . . . . 106
6.18 Trägerplatine mit aufgebondeten ASICs . . . . . . . . . . . . . . . . . . . . 107
6.19 Chip in einem BGA-Gehäuse . . . . . . . . . . . . . . . . . . . . . . . . . . 107
6.20 Trägerplatine mit teilweise vergossenen Kondensatoren . . . . . . . . . . . 108
6.21 Anbindung der Authentifizierungskomponente in den TSN . . . . . . . . . . 108
6.22 Authentifizierung des Nutzers am TSN, um Man-In-The-Middle Attacken zu
vermeiden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
6.23 Authentifizierung zwischen Nutzer und TSN zum Start einer neuen Session
mit Schutz Replay-Attacken . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
10

Listings
2.1 Beispielcode zum Ansprechen des AES am Memory-Controller . . . . . . . 22
2.2 Unterfunktionen f und K . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
2.3 Der Algorithmus von G . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.1 Package–Verzeichnisbaum . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
3.2 Package–Defintion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
3.3 Package–Registration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
3.4 Device Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
3.5 Device IO Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
3.6 Application Skeleton . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
5.1 Code für maximalen Datendurchsatz des AES . . . . . . . . . . . . . . . . 74
6.1 Schreibbefehl für die Verschlüsselung von Daten mit expliziten Adressen . 101
6.2 Schreibbefehl für die Verschlüsselung von Daten auf eine Adresse . . . . . 101

1 Einleitung
Drahtlose Sensornetze werden heute in vielen Bereichen, wie zum Beispiel der Industrieautomatisierung,
Umweltdatenerfassung und Überwachung von Infrastrukturen eingesetzt.
Aus Gründen des Schutzes vor Ausspähung von Betriebsgeheimnissen, Manipulation und
Sabotage von Anlagen, zum Beispiel im Bereich der biologischen und chemischen Prozesstechnologie,
aber auch im Bereich der Homeland Security, werden hohe Sicherheitsanforderungen
an drahtlose Sensorknoten gestellt. Insbesondere die Verwendung des Mediums
Luft macht diese Geräte leicht angreifbar, da kein physikalischer Zugang für das
Abhören oder die Manipulation der Daten und Geräte benötigt wird. Dem Einsatz starker
kryptographischer Mechanismen stehen jedoch im Regelfall die begrenzten Ressourcen
der drahtlosen Sensorknoten entgegen.
Im Rahmen des Projekts „Trusted Sensor Node“ (TSN) sollte ein vertrauenswürdiger Sensorknoten
für das Bundesamt für Sicherheit in der Informationstechnik (BSI) entwickelt
werden. Dieser Knoten fungiert als Bridge zwischen „einfachen“ Sensorknoten, die der
Detektion von Ereignissen dienen, und einer Datensenke. Für die Kommunikation im Sensornetzwerk
wird IEEE 802.15.4 eingesetzt. Die Kommunikation mit der Datensenke erfolgt
auf Basis der Bluetooth-Technologie. Dieser TSN soll zudem die erste vertrauenswürdige
Instanz in der Netzwerktopologie bilden. Deshalb wurde eine Unterstützung starker kryptographischer
Verfahren durch entsprechende Hardwarebeschleuniger vorgesehen.
IEEE 802.15.4
iSense
iSense
IEEE 802.15.1
TSN
iSense
Basestation
iSense
iSense
Abbildung 1.1: Anwendungsbeispiel des TSN

Abschlussbericht
Trusted Sensor Node
1.1 Beschreibung des Gesamtsystems
Der TSN-Knoten setzt sich zusammen aus einem Singlechip, welcher aus einem Prozessor
und den Hardwarebeschleunigern besteht und den externen Komponenten wie Funkmodulen
und zusätzlichem Speicher, die auf dem Board mit dem Core kombiniert werden.
Der Knoten fungiert als Bridge zwischen Bluetooth und IEEE 802.15.4 (siehe Abbildung
1.1). Um dies zu ermöglichen, muss der TSN mit zwei unterschiedlichen externen Radiomodulen
ausgestattet sein. Neben diesen Funkmodulen müssen auch Sensoren und
zusätzliche Speicher (RAM, Flash) an den TSN angeschlossen werden. Die notwendigen
Schnittstellen sind in den TSN integriert. Das Blockschaltbild in Abbildung 2.1 verdeutlicht
den Aufbau des Sensorknotens.
Um die Sicherheitsanforderungen erfüllen zu können wurde der TSN abweichend vom
LEON2-Referenz-Design [1] um Co-Prozessoren für AES, SHA-1/PRNG sowie ECC erweitert.
Sie werden zum Ver- und Entschlüsseln von Daten sowie zur Signierung von
Nachrichten eingesetzt. Die Zusatzmodule dienen somit einer sicheren Verarbeitung und
Übertragung von Daten.
Für die Anbindung externer Sensoren steht der Serial Peripheral Interface (SPI)-Master zur
Verfügung. An diesen können bis zu drei SPI-Slave-Komponenten angeschlossen werden.
Die vorgesehenen Radiomodule werden über zwei UART-Schnittstellen mit dem System
verbunden. Der externe Speicher wird direkt an den Memory Controller angeschlossen.
Tabelle 1.1 zeigt die Systemeigenschaften des TSN-ASICs. Er wird mit der IHP-eigenen
0,25-µm-Technologie gefertigt.
Fläche 30mm 2
Signalpins 87
Powerpins 24
BIST/Scan-Ports 5
Cache
2x4kByte
Maximale Taktfrequenz 16 MHz
Corespannung 2,5 V
Padspannung
3,3 V
Tabelle 1.1: Eigenschaften des TSN
14

2 Hardware
2.1 Beschreibung der Teilkomponenten
Wie im Blockschaltbild (siehe Abbildung 2.1) zu erkennen ist, setzt sich der TSN aus verschiedenen
Hardwarekomponenten zusammen. Diese werden in diesem Kapitel genauer
erläutert.
Programming
Interface
Sensors
802.15.4
Module
D-Cache
I-Cache
Scanchain
DSU
SPI
(Master)
UART
Bluetooth
Module
LEON2
Processor
Core
AMBA AHB
Bridge
(Master)
AMBA APB
Memory Controller
Intr
Ctrl
Timer
GPIO
Sensors
AES
ECC
SHA1
PRNG
Flash
RAM
Abbildung 2.1: Blockschaltbild des TSN
2.2 LEON2
Das Herz des TSN bildet der LEON2, ein 32-Bit-RISC-Prozessor. Der Chip ist als VHDL-
Modell von Gaisler Research [2] entwickelt worden und steht als „Open Source“-Komponente
unter der Lesser GNU Public License (LGPL) [31] zur Verfügung.
Als Grundlage dient die SPARC-V8-Architektur, die in IEEE 1754 beschrieben ist. Der Chip
enthält separate Befehls- und Datencaches, Interrupt-Controller, Timer, Debug-Unterstüt-

Abschlussbericht
Trusted Sensor Node
zung und ein einfaches Powermanagement. Als zentrales Bussystem dient der AMBA-Bus
[4], über den auch zusätzliche Peripherie angeschlossen werden kann.
Der LEON2 besitzt eine fünfstufige Pipeline für die Befehlsverarbeitung (siehe Abbildung
2.2) und in der vorliegenden Konfiguration einen Satz von 8 Register-Windows. Die Instruktions-Pipeline
ist folgendermaßen aufgebaut:
• Stufe 1: Instruktion holen (Fetch)
Instruktion aus dem Instruktionscache oder über den Memory-Controller aus dem
Speicher holen.
• Stufe 2: Instruktion dekodieren (Decode)
Instruktion wird dekodiert und die Operanden werden aus dem entsprechenden Register-Window
gelesen.
• Stufe 3: Instruktion ausführen (Execute)
Operation der Arithmetisch-Logischen Einheit wird ausgeführt.
• Stufe 4: Speicherzugriff (Memory)
Ergebnisse aus der Stufe 3 werden in den Datencache zurückgeschrieben.
• Stufe 5: Schreiben (Write)
Ergebnisse der Operationen aus Stufe 3 werden in entsprechende Register-Windows
zurückgeschrieben.
Unter der Voraussetzung, dass sich die nötigen Daten im Cache befinden, wird ein Großteil
der Instruktionen in einem Clockzyklus abgearbeitet. Ausgenommen hiervon sind die
Jump-, Load- und Store-Operationen.
In der Konfiguration des LEON2 besteht die Möglichkeit, einen Hardwaremultiplizierer in
das Design zu integrieren. Dadurch werden die Multiplikationsoperationen beschleunigt.
Die hierdurch beschleunigten Operationen würden, falls überhaupt, als Teil der kryptographischen
Operationen benötigt. Da für diese bereits Hardwarebeschleuniger vorgesehen
sind, wurde zur Minimierung der Chipfläche auf die Integration eines solchen Multiplizierers
verzichtet.
2.3 AMBA
Der Advanced Microcontroller Bus Architecture (AMBA)-Bus wird zur Kommunikation der
Komponenten auf einem Application Specific Integrated Circuit (ASIC) verwendet [4]. Er
besteht in der Regel aus zwei Untersystemen, dem Advanced High-performance Bus
(AHB) und dem Advanced Peripheral Bus (APB).
Der AHB wird verwendet, um Komponenten mit hohen Datentransferraten zu verbinden.
Prozessor, Speicher sowie gegebenenfalls Co-Prozessoren sind über diesen schnellen
Datenbus angebunden.
16

Abschlussbericht
Trusted Sensor Node
Abbildung 2.2: Grafische Darstellung der fünfstufigen Pipeline des LEON2
(entnommen aus LEON2 Processor User’s Manual) [3]
Der APB hingegen ist auf Energieeffizienz optimiert und besonders geeignet, langsame
Peripherie, wie z.B. serielle Schnittstellen, in das System zu integrieren. Der AHB und der
APB sind über eine Bridge miteinander verbunden. Durch das Hinzufügen des APB bleibt
die hohe Leistungsfähigkeit des AMBA-Busses auch im Fall des Zugriffs auf langsame
Komponenten erhalten.
Der AHB im TSN (siehe Abbildung 2.3) enthält einen AHB-Master mit dem LEON2-Prozessor
und zwei AHB-Slaves, den Memory-Controller sowie die APB-Bridge. Ein AHB-Master
kann einen Zugriff auf den AHB initialisieren, während ein AHB-Slave nur auf Transaktionen
(Lese- oder Schreibbefehl) reagieren kann.
Prozessor mit
Pipeline
D-Cache I-Cache
AHB-Master
AHB
AHB/APB-Bridge
(AHB-Slave)
Memory-Controller
(AHB-Slave)
UART
SPI
Abbildung 2.3: Aufbau des AMBA-Bus-Systems im TSN
17

Abschlussbericht
Trusted Sensor Node
2.4 Konfigurationsregister
Am APB sind die Konfigurations- und teilweise auch die Datenregister der Komponenten
angeschlossen. Dazu gehören die Register für den Memory-Controller, für UART, SPI,
PIO, Timer und den Interrupt-Controller.
2.5 Memory-Controller und Integration der
Hardwarebeschleuniger
Der Memory-Controller übernimmt die wesentliche Aufgabe, alle Zugriffe auf die Speicherelemente
zu koordinieren und durchzuführen. Das umfasst als Speicher- und speicherähnliche
Elemente den Flash, den memory-mapped I/O sowie den SRAM.
Unter „memory-mapped I/O“ versteht man den Zugriff auf Blöcke, die zwar ein Interface
wie ein Speicher besitzen, dessen Funktionalität jedoch eine andere ist (z.B. Co-Prozessor
zur Datenverarbeitung). Der I/O-Bereich wird so in den Arbeitsspeicher eingeblendet.
Man kann ein neues Hardwaremodul mit einem proprietären Interface ausstatten, das von
der jeweiligen Funktion der Hardwarekomponente bestimmt wird. Für den AES könnte
das zum Beispiel bedeuten, dass die Schnittstelle einen Eingang für Clock und Reset
sowie Eingänge mit einer Breite von 128 Bit für die Daten und weiteren 128 Bit für den
Schlüssel hat. Der Ausgang für die Daten wäre ebenso 128 Bit breit. Dieses, zunächst
nahe liegende, Interface ist jedoch nicht brauchbar, da es keine passende Hardware gibt,
an die die Komponente angeschlossen werden kann.
Es muss also ein etwas höherer Aufwand betrieben werden, um die neue Komponente mit
der gleichen Schnittstelle wie von Speicherblöcken auszustatten. Diese Art der Schnittstelle
wird „memory-like Interface“ genannt. Durch das vergleichsweise einfach ausgeführte
Interface eines Speichers (Clock, Daten- und Adressbus, Read- und Write-Enable) ist
diese Art der Anbindung weit verbreitet. Daher wurde für den AES, SHA-1 und den ECC
ein solches Interface gewählt (siehe Abbildung 2.4). Prinzipiell ließen sich die Komponenten
auch als SRAM anschließen. Das hat jedoch den Nachteil, dass dieser „cacheable“
ist und somit oftmals bei Lesevorgängen auf den Cache zugegriffen wird anstelle eines
direkten Lesezugriffs. Der Cache enthält an dieser Stelle jedoch veraltete Daten, da der
Co-Prozessor die Daten modifiziert hat. So werden falsche Ergebnisse zurück geliefert.
Mit der Verwendung von memory-mapped I/O wird das Problem vollständig umgangen.
In der Ausgangskonfiguration erlaubt der LEON2 die Anbindung einer Komponente an
den memory-mapped I/O. Dieses ist für den TSN nicht ausreichen, da AES, ECC und
SHA-1 angeschlossen werden muss. Durch die Aufteilung des Adressbereich für memorymapped
I/O in drei Unterbereiche wird der Anschluß aller Komponenten ermöglicht.
Während memory-mapped I/O den nicht gepufferten Zugriff mittels Memory-Controller auf
die Komponente meint, ist das memory-like Interface die Beschreibung der Schnittstelle.
18

Abschlussbericht
Trusted Sensor Node
Zu Konfigurationszwecken besitzt der Memory-Controller drei Konfigurationsregister. Mit
dessen Hilfe werden die Wortbreite (8, 16 oder 32 Bit), Zugriffszeiten sowie Speichergrößen
definiert. Alle Signale liegen jederzeit an den angeschlossenen Komponenten an. Einzige
Ausnahme bildet hierbei das „Chip-Select“-Signal, welches exklusiv für jede Komponente
ist. Anhand dieses Signals erkennt das Modul, ob es angesprochen wird. Unabhängig
vom Memory-Controller agiert der Cache, welcher direkt mit dem Prozessor verbunden
ist.
CHIP_SELECT
CLOCK
Memory-Controller
RESET
WRITE
RAM
DATA_OUT
ADDR
DATA_IN
AMBA-Bus
AES
DATA_OUT
LEON2
CHIP_SELECT
Abbildung 2.4: Verwendung eines AES-Blocks mit einem memory-like Interface
2.6 Speicher
Der TSN verfügt über verschiedenartige Speicher. Der 4-KByte-Befehlscache und der 4-
KByte-Datencache beschleunigen das System durch ihre direkte Anbindung an den Prozessor.
Der TSN ist mit RAM ausgestattet, der auf dem Board untergebracht ist. Dessen
Größe ist variabel zwischen 16 Kilobyte und 16 Megabyte. Derzeit ist das Board mit einem
2-Megabyte-Modul bestückt.
Der RAM ist über den Memory-Controller mit einer Wortbreite von 32 Bit an den schnellen
AMBA-AHB-Bus angeschlossen. Zur Minimierung der Chipfläche wurde nur der Cache in
den Chip integriert. Durch die Art der Ausführung des Memory-Controllers ist sichergestellt,
dass der Zugriff auf den externen RAM genauso schnell ist, wie auf dem internen
RAM. Aufgrund der beschränkten Anzahl an I/O-Pins (siehe Abschnitt 2.17) kann der externe
Speicher nur mit 16 Bit Wortbreite angesprochen werden, so dass für das Schreiben
und Lesen eines 32-Bit-Wortes jeweils zwei Zugriffe stattfinden müssen. Durch die Verwendung
von Cache wird der Geschwindigkeitsnachteil im laufenden Betrieb so weit wie
möglich kompensiert werden.
Ein sicherer Speicher ist in der vorliegenden Entwicklungsstufe nicht das Entwurfsziel, da
zunächst die Gesamtarchitektur des Systems geprüft werden soll. Um in späteren Entwicklungsstadien
einen sicheren Speicher zu realisieren, genügt es nicht, den Speicher
vollständig on-Chip auszuführen. Er wird vielmehr dadurch erreicht, dass alle Daten verschlüsselt
abgelegt werden. Dies ist notwendig, um eine Abfrage des internen Speichers
19

Abschlussbericht
Trusted Sensor Node
durch physikalische Angriffe zu verhindern. RAM-Strukturen sind besonders problematisch,
da die Speicherelemente in einem gefertigten Design sehr gut zu identifizieren und,
mit der richtigen Technik auch auslesbar sind.
Eine Komponente zur Ansteuerung eines sicheren Speichers ermöglicht es auch, externen
Speicher „sicher“ anzuschließen und lässt somit genügend Spielraum für die Speichererweiterung.
2.7 Parallel I/O-Port
Der Parallel I/O-Port ist ein bitweise programmierbarer I/O-Port (PIO). In der Basiskonfiguration
des LEON2 werden alle 32 Bit nach außen geführt. Dabei werden die Pins für die
Ports 0 bis 15 mit den UART-Ports sowie Konfigurationspins für den Bootvorgang geteilt
um Pins einzusparen. Über ein Konfigurationsregister wird die jeweils gewünschte Funktion
ausgewählt, also als Eingang oder Ausgang. Für den Fall, dass der Pin als Eingang
agiert, kann der Wert, der am Pin von außen anliegt, über ein Register abgefragt werden.
Ist der Pin als Ausgang konfiguriert, so muss der Wert am Ausgang gesetzt werden
(logisch „0“ oder „1“).
Durch das mögliche bitweise Ansprechen der Datenpins ist es auch möglich, Kommunikationsprotokolle
in Software nachzubilden. Zum Beispiel sieht die aktuelle Umsetzung des
TSN kein Modul für die I 2 C-Schnittstelle vor. Sollte sich die Notwendigkeit einer solchen
ergeben, wird diese in Software, zu Lasten der gesamten Systemperformance, abgearbeitet.
2.8 UART
Die beiden Universal Asynchronous Receiver Transmitter (UART)-Komponenten sind Bestandteil
des LEON2-Prozessors. Um Pins am Prozessor zu sparen, teilen sich die UARTs
ihre Anschlüsse mit einigen PIO-Pins.
Für die Datenübertragung muss der UART, der direkt an den APB angeschlossen ist, konfiguriert
werden. Dabei können der UART-Takt, die Übertragungsrichtung und zahlreiche
Sicherungsmechanismen eingestellt werden. Um Daten übertragen zu können, müssen
diese in die entsprechenden Register geschrieben werden.
Getestet wurden die UART-Schnittstellen, indem beide miteinander verbunden wurden.
Abwechselnd wurden sie als Sender und Empfänger konfiguriert und Datenübertragungen
initiiert.
20

Abschlussbericht
Trusted Sensor Node
2.9 DSU
Die Debug Support Unit (DSU) unterstützt die Fehlersuche und den Test des Systems.
Sie ist integraler Bestandteil des LEON2-Prozessors und mit dem AMBA-AHB verbunden.
Dies ermöglicht, den TSN in einen Debugmodus zu versetzen. Dabei wird der Prozessor
angehalten, um Daten an jeder beliebigen Adresse lesen und schreiben zu können.
2.10 Interrupt-Controller
Der Interrupt-Controller dient als zentrale Instanz zur Signalisierung von Ausnahmezuständen.
Ein Ausnahmezustand kann z. B. sein, dass in einem UART-Block Daten zur Abholung
bereitstehen. Solange die CPU diese Daten nicht ausgelesen hat, können keine weiteren
Daten empfangen werden. Daher ist es notwendig, die CPU über den Erhalt dieser Daten
zu informieren und eine zügige Abarbeitung zu forcieren. Diese erfolgt durch das Auslösen
eines Interrupts. Mittels des Interrupt-Controllers kann die CPU auswerten, welche
Komponente den Interrupt ausgelöst hat und wie der Ausnahmezustand zu behandeln ist.
2.11 Timer
Die Timerkomponente besteht aus einem Prescaler und zwei Timern. Der Prescaler dient
dazu, den Takt der Systemclock zu reduzieren. Die Timer dekrementieren einen vorher
festgelegten Wert. Erreicht ein Timer den Wert „Null“, so wird mit Hilfe des Interrupt-
Controllers ein Interrupt ausgelöst, den der Prozessor entsprechend beantworten muss.
Dafür setzt der Prozessor zunächst den Interrupt zurück und signalisiert, dass der Interrupt
bearbeitet wird. Anschließend wird eine vom Programmierer vorgegebene Softwareroutine
abgearbeitet.
2.12 Memory-Like Interface
Die Schnittstellen des Advanced Encryption Standard (AES), Elliptic Curve Cryptography
(ECC) und Secure Hash Algorithmus 1 (SHA-1) sind so ausgelegt, dass sie an den
Memory-Controller angeschlossen werden können (siehe Tabelle 2.1).
Das Listing 2.1 zeigt einen Beispielcode wie ein AES mit einem memory-like Interface
in Software angesprochen wird. Die Funktion „writeReg“ hat als erstes Argument den zu
schreibenden Wert und als zweites die Zieladresse. Es werden keine gesonderte Compilerbefehle
benötigt, so dass auch keine Veränderungen am Compiler vorgenommen werden
müssen.
21

Abschlussbericht
Trusted Sensor Node
RESETN
CLK
CE
OEN
WE
A [15 ... 0]
d_in[31 ... 0]
d_out[31 ... 0]
ist ein low-aktiver Eingang. Es setzt das Modul zurück, in dem es die
Register mit dem Startwert „0“ belegt. Die State-Machine geht in den
Startzustand.
ist der Eingang für das externe Taktsignal.
ist ein low-aktiver Eingang. Er selektiert und aktiviert die Komponente.
ist ein low-aktiver Eingang. Er wird während eines Lesezyklus auf aktiv
gesetzt.
ist der low-aktive Eingang, der einen Schreibzugriff signalisiert.
ist der Adressbus. Dieser Eingang beinhaltet die Adressen der verschiedenen
Register.
ist ein 32 Bit Dateneingang. Er enthält die Daten, die in die adressierten
Register geschrieben werden sollen.
ist ein Datenausgang, der die Daten beinhaltet, die aus den Registern
gelesen werden.
Tabelle 2.1: Signale eines Memory-Like Interface
// AES base address
#define AESBASE 0x20200000 //memory mapped IO
//Write key
writeReg(0x2b7e1516, AESBASE + KEYBASE + 0);
writeReg(0x28aed2a6, AESBASE + KEYBASE + 1);
writeReg(0xabf71588, AESBASE + KEYBASE + 2);
writeReg(0x09cf4f3c, AESBASE + KEYBASE + 3);
writeReg(0x3243f6a8, AESBASE + DATABASE + ENCRYPTION + 0);
writeReg(0x885a308d, AESBASE + DATABASE + ENCRYPTION + 0);
writeReg(0x313198a2, AESBASE + DATABASE + ENCRYPTION + 0);
writeReg(0xe0370734, AESBASE + DATABASE + ENCRYPTION + 0);
//Wait 77 Clock cycles or for interrupt
//READ_OUT
Listing 2.1: Beispielcode zum Ansprechen des AES am Memory-Controller
2.13 AES
In symmetrischen Verschlüsselungsverfahren wird sowohl zur Verschlüsselung als auch
zur Entschlüsselung der gleiche geheime Schlüssel benutzt. Ist einem Dritten dieser Schlüssel
bekannt, so kann dieser den Kommunikationsprozess abhören und selbst verschlüsselte
Datenpakete in Umlauf bringen. Ein bekanntes Beispiel für symmetrische Verschlüsselungsverfahren
ist der DES-Algorithmus. Dieser wurde 2001 durch den AES abgelöst.
Am häufigsten wird derzeit die 128-Bit-Version im Electronic Code Book (ECB)-Modus genutzt.
Der ECB-Modus ist nicht rückgekoppelt, d.h. es wird jeder Datenblock unabhängig
von anderen verarbeitet. So ist ein wahlfreier Zugriff auf verschlüsselte Blöcke möglich.
Nachteilig ist, dass so gleiche Eingangsdaten zu gleichen Ausgangsdaten führen. Es gibt
Anwendungsfälle, in denen der ECB-Modus nicht vermieden werden kann. Gehen z.B. in
einem rückgekoppelten Modus wie Cipher Block Chaining (CBC) Datenpakete verloren, so
22

Abschlussbericht
Trusted Sensor Node
ist das nachfolgende Datenpaket nicht mehr zu entschlüsseln. Insbesondere bei unzuverlässigen
Verbindungen (wie Funk) ist daher der CBC-Modus nicht geeignet. In Systemen,
die neben dem AES über eine CPU verfügen, können rückgekoppelte Modi so nachgebildet
werden, dass zunächst die Verschlüsselung im AES-Coprozessor durchgeführt wird
und anschließend die Operationen zur Rückkopplung in Software ausgeführt werden.
2.13.1 Arithmetische Grundlagen
Der Advanced Encryption Standard (AES) ist ein symmetrisches Verschlüsselungsverfahren.
Im Gegensatz zu Stromchiffren, welche bit- oder byteorientiert arbeiten, werden beim
AES jeweils Blöcke von 128 Bit (16 Byte) der Ver- oder Entschlüsselung unterzogen. Daher
ist der AES eine Blockchiffre. Ein Datenblock wird in einer Matrix mit 4x4 Byte angeordnet
(siehe Formel 2.1).
⎡
⎤
32 88 31 e0
3243f68a885a308d313198a2e0370734 ⇒ ⎢43 5a 31 37
⎥
⎣f6 30 98 07⎦ (2.1)
8a 8d a2 34
Nicht in jedem Fall wird die Länge eines zu verschlüsselnden Datenblocks (in Bit) einem
ganzzahligen Vielfachen von 128 entsprechen. Hier müssen höhere Schichten durch die
Auswahl geeigneter Padding-Algorithmen die tatsächliche Datenlänge an die geforderte
Datenlänge anpassen.
Durch das National Institute of Standards and Technology (NIST) [37] ist die Datenblocklänge
von 128 Bit bei Schlüssellängen von 128, 192 sowie 256 Bit standardisiert. Dazu
kommen Modi, die eine Kopplung zwischen verschiedenen Datenblöcken ermöglichen.
Diese verhindern Attacken, bei denen einzelne Datenblöcke durch den Angreifer ausgetauscht
werden. Ein grundlegender Unterschied zwischen den Versionen mit unterschiedlichen
Schlüssellängen besteht in der Anwendung des Rundenschlüssels auf die Daten.
Unabhängig von der Länge des Eingangsschlüssels werden in jeder AddKey-Operation
der 128 Bit lange Datenblock mit einem 128 Bit langen Schlüsselteil verknüpft (siehe Abbildung
2.5).
Während für einen 128-Bit-Schlüssel jeweils der komplette Rundenschlüssel auf die 128
Bit Daten angewendet wird, wird die Anwendung des 256-Bit-Schlüssels auf zwei Verarbeitungsrunden
aufgeteilt. Bei jeder dieser Runden werden 128 Bit als Teilschlüssel verwendet.
Ähnlich verhält es sich mit dem 192-Bit-Schlüssel. Die ersten 128 Bit des Rundenschlüssels
werden auf die 128 Bit Daten angewandt. In der folgenden Runde wird
zunächst aus dem Schlüssel der nächste Rundenschlüssel erzeugt. Anschließend werden
die verbleibenden 64 Bit aus dem Initialschlüssel und die 64 Bit aus dem erzeugten
Rundenschlüssel zusammen auf den 128-Bit-Datenblock angewendet. Aufgrund der Überlappungen
eines Schlüssels auf mehrere Runden wird bei der Schlüssellänge von 192 Bit
die Rundenzahl auf 12 und bei einem 256-Bit-Schlüssel auf 14 erhöht.
23

Abschlussbericht
Trusted Sensor Node
128 Bit Datenpfad
Runde n
128 Bit
128 Bit
XOR
Abbildung 2.5: Schlüsseladdition für 128 Bit
Input key
Calc
key
10 Rounds
xor
S-Box
Shift
row
Mix
Column
Input data
Output data
Abbildung 2.6: Schematischer Aufbau der AES-Implementierung
2.13.2 Algorithmusbeschreibung des AES
Die Abbildung 2.6 zeigt schematisch den Ablauf der Verschlüsselung. Der Algorithmus wird
für einen 128-Bit-Schlüssel in elf Runden auf die Daten angewendet. Jede dieser Runden
besteht aus mehreren Teilschritten, wobei jeweils in der ersten und in der letzten Runde
nicht alle Teilschritte ausgeführt werden. In den Beschreibungen der Teilschritte werden
die Zeilen mit i (0 bis 3) sowie die Spalten mit j (0 bis 3) gekennzeichnet.
• 1. Runde
data=AddKey(data, key)
• 2. Runde bis 10. Runde
data=S-Box(data)
data=ShiftRow(data)
data=MixColumn(data)
data=AddKey(data, key)
• 11. Runde
data=S-Box(data)
data=ShiftRow(data)
data=AddKey(data, key)
24

Abschlussbericht
Trusted Sensor Node
AddKey
Die Schlüsseladdition wird durch eine binäre XOR-Operation ausgeführt.
S-Box Die Substitutions-Box (S-Box) ist eine nichtlineare Abbildung eines Bytes auf ein
anderes. Dazu wird vom Eingangswert x in GF(2 8 ) das multiplikative Inverse x −1 (in Formel
2.2 gilt: x −1 entspricht z0 bis z7) gebildet. Anschließend wird eine Matrixmultiplikation
mit der vorgegebenen Matrix c ausgeführt und der Vektor (11000110) addiert (siehe Formel
2.2). Die Ausführung der S-Box ist so gewählt, dass kein Bytewert auf sich selbst
abgebildet wird, da dies ein potentieller Ansatzpunkt für Kryptoanalysen wäre. Da die S-
Box-Transformation jeweils auf ein Byte angewendet wird, sind 16 dieser Transformationen
pro Runde notwendig.
⎡ ⎤ ⎡
⎤ ⎡ ⎤ ⎡ ⎤
y0 1 0 0 0 1 1 1 1 z0 1
y1
1 1 0 0 0 1 1 1
z1
1
y2
1 1 1 0 0 0 1 1
z2
0
y3
y4
=
1 1 1 1 0 0 0 1
z3
1 1 1 1 1 0 0 0
z4
+
0
0
⎢y5
⎥ ⎢0 1 1 1 1 1 0 0
⎥ ⎢z5
⎥ ⎢1
⎥
⎣y6⎦
⎣0 0 1 1 1 1 1 0⎦
⎣z6⎦
⎣1⎦
y7 0 0 0 1 1 1 1 1 z7 0
(2.2)
ShiftRow Die Bytes der Matrix rotieren in Abhängigkeit von der Zeilennummer i (i = 0 bis
3) um i Stellen nach links (zyklisches Shiften, siehe Formel 2.3).
⎡
⎤ ⎡
⎤
00 01 02 03 00 01 02 03
⎢10 11 12 13
⎥
⎣20 21 22 23⎦ ⇒ ⎢11 12 13 10
⎥
⎣22 23 20 21⎦ (2.3)
30 31 32 33 33 30 31 32
MixColumn Während die S-Box-Operation sich byteweise auswirkt, ist die MixColumn-
Transformation eine Interaktion zwischen den 4 Bytes einer Spalte y0, j bis y3, j für j = 0
bis 3 in GF(2 8 ). Dazu wird eine Matrixmultiplikation der Spalte j (j = 0 bis 3) mit der Matrix
c ausgeführt (siehe Formel 2.4).
⎡ ⎤ ⎡
⎤ ⎡ ⎤
y0, j 02 03 01 01 z0, j
⎢y1, j
⎥
⎣y2, j⎦ ⇐ ⎢01 02 03 01
⎥ ⎢z1, j
⎥
⎣01 01 02 03⎦
⎣z2, j⎦ ∀j ∈ [0, 1, 2, 3] (2.4)
y3, j 03 01 01 02 z3, j
Schlüsselexpansion In jeder der elf Runden wird ein neuer Rundenschlüssel mit der
Länge von 128 Bit benötigt. Der Schlüssel wird analog zu den Eingangsdaten auf eine
4x4-Byte-Matrix abgebildet. Die Generierung eines neuen Rundenschlüssels besteht aus
25

Abschlussbericht
Trusted Sensor Node
4 Teilschritten, in denen jeweils eine Spalte mit 4 Byte erzeugt wird. Gemäß Abbildung
2.7 wird die erste Spalte des Folgeschlüssels durch die Ausführung einer Funktion F, die
auf der S-Box basiert, auf die Spalte 3 sowie der XOR-Verknüpfung von F mit der Spalte
0 gebildet. Die drei folgenden Spalten werden durch eine Addition der vorhergehenden
Spalte mit der gleiche Spalte des vorhergehenden Schlüssels berechnet.
Abbildung 2.7: Spaltenweise Generierung des nächsten Rundenschlüssels
2.13.3 Implementierung
Die im TSN genutzte Implementierung ver- und entschlüsselt Datenblöcke mit einer Länge
von 128 Bit mit einem 128 Bit langen Schlüssel im ECB-Modus und ist auf niedrige bis
mittlere Datenraten optimiert. Durch das 32-Bit-Dateninterface ist es notwendig, jeweils
4 Datenblöcke á 32 Bit in das AES-Modul zu schreiben, um einen vollständigen 128-Bit-
Datenblock zu erhalten. Vier weitere Schreiboperationen sind erforderlich, um den Schlüssel
im AES-Modul abzulegen. Insgesamt werden so theoretisch nur 8 Adressen benötigt.
Der zu Verfügung stehende Adressraum ist jedoch um einiges größer und wird auch ausgenutzt,
um den notwendigen Kommandoblock und die dazugehörige Schreiboperation
einzusparen. Dem AES-Modul muss mitgeteilt werden, ob die Daten zur Entschlüsselung
oder zur Verschlüsselung abgeliefert wurden. Die Auswahl wird mit Hilfe eines Adressbits
codiert. Die Daten zur Verschlüsselung werden beginnend mit der Adresse 0x90 und die
Daten zur Entschlüsselung beginnend mit Adresse 0xA0 geschrieben. Für einen Datenblock
werden insgesamt 78 Clocktakte benötigt, um die Daten zu ver- oder entschlüsseln.
2.14 ECC
Bei asymmetrischen Verschlüsselungsverfahren wird ein Schlüsselpaar, bestehend aus einem
öffentlichen und einem privaten Schlüssel, eingesetzt. Der öffentliche Schlüssel des
26

Abschlussbericht
Trusted Sensor Node
Empfängers ist frei zugänglich (z.B. über dessen Homepage) und die Daten können hiermit
verschlüsselt werden. Der private Schlüssel ist geheim zu halten. Mit diesem kann
die Nachricht wieder entschlüsselt werden. Aus dem öffentlichen Schlüssel kann der private
Schlüssel nicht mit vernünftigem Aufwand errechnet werden, so dass verschlüsselte
Nachrichten ausschließlich mit dem privaten Schlüssel zugänglich sind. Eine alternative
Anwendung von asymmetrischen Verschlüsselungsverfahren ist das Unterschreiben einer
Nachricht mit dem privaten Schlüssel. Mit dem entsprechenden öffentlichen Schlüssel
kann dann die Echtheit dieser Signatur überprüft werden, da davon ausgegangen werden
kann, dass einzig der Besitzer des privaten Schlüssels diese Nachricht so verschlüsseln
beziehungsweise digital unterschreiben konnte. Ein asymmetrisches Verschlüsselungsverfahren
eignet sich nicht für größere Datenmengen. Der Berechnungsaufwand für die Verschlüsselung
der gleichen Datenmenge liegt mehrere Größenordnungen über dem für ein
symmetrisches Verschlüsselungsverfahren.
Das derzeit populärste Verfahren ist die RSA-Verschlüsselung, benannt nach den drei Erfindern
Rivest, Shamir und Adleman [44]. Die Elliptic Curve Cryptography (ECC) auf Basis
elliptischer Kurven ist ein modernerer alternativer Verschlüsselungsansatz. Im Vergleich
zum RSA bietet der ECC-Ansatz einen gleichwertigen Sicherheitsgrad bei wesentlich kürzeren
Schlüssellängen. Soll zum Beispiel die Sicherheit von verschlüsselten Daten für
die nächsten 20 Jahre gewahrt sein, ist empfohlen, für RSA 2048 Bit lange Schlüssel zu
nutzen. Das ECC-Verfahren erreicht den gleichen Grad an Sicherheit schon mit 233 Bit
langen Schlüsseln [29]. Kürzere Schlüssel sind besonders wichtig, wenn Kryptographie
auf mobilen Geräten mit wenig Speicher und begrenzter Rechenstärke eingesetzt wird.
2.14.1 Arithmetische Grundlagen
ECC ist ein kryptographisches Verfahren, das mit 2-dimensionalen Punkten (x, y) auf einer
elliptischen Kurve arbeitet. Die x- und y-Koordinaten sind Elemente eines finiten Feldes,
des so genannten Basisfeldes. Auf den Punkten dieser Kurve sind algebraische Operationen,
wie die Addition zweier Punkte definiert. Die wichtigste, kryptographisch eingesetzte
Operation ist die k*P-Multiplikation, bei der ein Punkt mit einer ganzen Zahl multipliziert
wird. Diese Operation ist recht einfach zu berechnen. Die Umkehroperation ist allerdings
nicht in polynomineller Zeit zu lösen.
Für das ECC-Verfahren eignen sich zwei Arten von generellen Basisfeldern: Restklassenfelder
basierend auf einer großen Primzahl (GF(p)) und Restklassenfelder basierend auf
erweiterten Binärfeldern (GF(2 m )). Beide Arten gelten als sicher. Geeignete Parameter
wurden bereits von Standardisierungsgremien empfohlen. Für energie- und flächeneffiziente
Implementierungen in Hardware eigenen sich insbesondere die binären Kurven, da
deren Arithmetik eine vereinfachte Darstellung in Hardware (GF(2 m )) erlaubt. Desweiteren
sind additive Operationen einfache XOR-Operationen und benötigen daher keine Überträge.
Diese Eigenschaften begründen die Entscheidung, bei dem Design binäre Felder als
Basisfeld zu nutzen.
ECC-Operationen nutzen intensiv Operationen des Basisfelds. Zum Beispiel benötigt eine
k*P-Multiplikation in (GF(2 233 )) etwa 1500 Feldmultiplikationen. Deshalb sind genaue
27

Abschlussbericht
Trusted Sensor Node
Untersuchungen der Operationen im Basisfeld für eine effiziente ECC-Implementierung
unumgänglich. Bei den Betrachtungen der mathematischen Grundlagen im Basisfeld der
elliptischen Kurve stellen sich insbesondere folgende Operationen als kritisch heraus:
• Feldmultiplikation
• modulare Reduktion.
2.14.2 Multiplizierer
Die Feldmultiplikation ist die mit Abstand aufwändigste Operation im Basisfeld. Eine 256-
Bit-Multiplikation benötigt zum Beispiel je über 65000 XOR- und AND-Operationen, wenn
sie nach der Methode der klassischen Schulmultiplikation ausgeführt würde. In der Literatur
werden verbesserte Verfahren wie die klassische Karatsuba-Multiplikation und die iterative
Karatsuba-Multiplikation vorgestellt [14]. Letztere verringert vor allem die Anzahl der
notwendigen AND-Operationen (auf 6561) aber kaum die Anzahl der XOR-Operationen
(62000). In dem Design wird eine rekursive Anwendung der iterativen Karatsuba-Methode
(RAIK) [39], die auch die Anzahl der XOR-Operationen (auf unter 43000) reduzieren
kann, genutzt. Bei den rekursiven Karatsuba-Methoden wird eine Multiplikation durch kleinere
Multiplikationen mit kürzerer Bitlänge ersetzt, die dann wiederum mit der Karatsuba-
Methode gelöst wird. Da festgestellt wurde, dass sich für kürzere Multiplikationen mit Bitlängen
von unter 8 Bit eine weitere rekursive Zerlegung nach der Karatsuba-Methode nicht
positiv auf den Gesamtaufwand auswirkt, werden für diese kurzen Multiplikationen andere
Verfahren angewandt. Als Beispiel sei hier die klassische Schulmultiplikation genannt,
wodurch der Gesamtaufwand für rekursive Multiplikation signifikant reduziert wird. Diese
theoretischen Betrachtungen der polynominellen Multiplikation sind die Basis für eine effiziente
Implementierung dieser Operation in Hardware, wie sie in dem Design realisiert
wurden. Der Ansatz ist detaillierter in [45] diskutiert.
2.14.3 Reduktion
Die zweite kritische Operation ist die Reduktion. Diese Operation muss nach jeder Feldmultiplikation
ausgeführt werden. Das ist begründet durch den finiten Charakter des Basisfeldes.
Die Multiplikation zweier m Bit langen Faktoren ergibt ein 2m-1 Bit langes Produkt
(siehe Abbildung 2.8). Da die Elemente des Feldes genau m Bit lang sind, muss zu dem
2m-1 Bit langen Element ein in dem Feld äquivalentes Element mit der Länge m berechnet
werden. Ein klassisches Verfahren für diese Operation ist die Division mit Rest durch das
Generatorpolynom, wobei der Rest der Division das äquivalente Element darstellt.
Ähnlich wie eine Division in „normalen“ Zahlensystemen ist auch die Division in GF(2 m )
sehr komplex und deshalb nach jeder Feldmultiplikation nicht sinnvoll. In der Literatur werden
Verfahren beschrieben, welche die Reduktion als eine einfache Abbildung mit konstantem
Aufwand herausstellen. Diese Verfahren können sowohl in Software- als auch
in Hardwareimplementierungen angewendet werden. Das Problem bei dieser Vorgehens-
28

Abschlussbericht
Trusted Sensor Node
weise ist, dass für jedes Feld und damit für jede Schlüssellänge eine spezielle Abbildung
generiert werden muss. Hier ergibt sich das Problem der Reduktion: Entweder man hat
eine schnelle, effiziente Implementierung, die aber nur eine bestimmte Kurve unterstützt
oder einen komplexen Algorithmus, der dann aber nicht an bestimmte Kurven gebunden
ist.
In dem Design wurde sich auf die Beschleunigung einer einzigen Kurve konzentriert. Ziel
war es, eine möglichst schnelle und kleine Hardwarelösung für die ECC-Operation mit
einer Bitbreite von 233 Bit zu realisieren. Hierfür kann das Reduktionspolynom direkt in
dem Design verdrahtet werden. Die Reduktionsoperation benötigt somit 0,034 mm 2 Siliziumfläche,
während eine flexible Lösung die Fläche und auch die letztendliche Laufzeit
signifikant erhöht hätten.
Die Kurve mit Operanden von 233 Bit ist seitens der NIST unter der Bezeichnung „B 233“
standardisiert [13]. Diese Kurve wurde ausgewählt, da die Sicherheit in etwa der Sicherheit
des eingesetzten, symmetrischen Verschlüsselungsverfahren AES entspricht [6a].
Abbildung 2.8: Da das Ergebnis einer Multiplikation länger als die maximale
Feldlänge ist, benötigt man einen Reduktionsschritt, der das
Ergebnis innerhalb des Feldes reduziert.
2.14.4 System-Design
Im ECC-Design wurde eine Prozessorarchitektur gewählt, die der Transport-getriggerten
Architektur (TTA) entspricht. Alle Funktionseinheiten (siehe Abbildung 2.9), also Multiplizierer
(MUL), Addierer, Quadrierer (beides als Teil der Arithmetisch-Logischen-Unit (ALU))
sowie Register (Register File) sind mit einem 233 Bit breiten Bus verbunden. Der Zugriff
auf den Bus wird von einer zentralen Kontrollsteuerung (Controller) geregelt. In dieser Einheit
befindet sich das fest verdrahtete Ausführungsprogramm der ECC-Einheit. Die Testbit-
Einheit verbindet die ansonsten komplett getrennten Datenfluss- und Kontrollflussteile der
Schaltung. Diese Testbit-Einheit überprüft, ob ein bestimmtes Bit auf dem Datenbus gesetzt
wurde. Bei der TTA sind die Operationen der Funktionsblöcke durch den Bustransfer
getriggert. Der Start einer Multiplikation wird beispielsweise aktiviert, wenn zwei Datenworte
(die Faktoren) zum Multiplizierer transportiert wurden. Späteres Lesen vom Multiplizierer
liefert dann automatisch das Produkt. Diese Art der Architektur ist sehr einfach, da
Komponenten hinzugefügt oder entfernt werden können ohne andere Komponenten oder
Kontrollstrukturen ändern zu müssen. Neben dieser Flexibilität erlaubt diese Architektur eine
explizite Parallelität. In der Zeit, in der beispielsweise eine Multiplikation berechnet wird,
können weitere Operationen, wie Additionen oder Registertransfer, ausgeführt werden.
29

Abschlussbericht
Trusted Sensor Node
Das Programm in der Kontrolleinheit führt die Punktmultiplikation entsprechend dem Lopez-Dahab-Algorithmus
[32] aus. Dieser Algorithmus erlaubt die Ausführung einer EC
Punktmultiplikation (ECPM) mit lediglich einer Division im Basisfeld. Diese eine Division
wird mittels des Itoh-Tsujii-Ansatzes [22] berechnet. Durch den im Design vorhandenen
schnellen Quadrierer und Multiplizierer ist dieser Algorithmus schneller und ressourcensparender
als zum Beispiel der alternative erweiterte Euklidische Algorithmus. Die Algorithmen
sind Teil des fest verdrahteten Programms in der Kontrolleinheit, die den Fluss der
Daten zwischen den Rechen- und Registereinheiten steuert.
Die Flexibilität des Designs bezüglich der Funktionseinheiten erlaubt es, eine praxisnahe
„Design-Space-Exploration“ durchzuführen. Mittels dieser Exploration wird der Einfluss
der Anzahl und der Geschwindigkeit der einzelnen Funktionseinheiten auf die Leistung
des gesamten Systems ermittelt. Die Untersuchung ergab, dass die Geschwindigkeit der
Feldmultiplikation die wichtigste Einflussgröße für die Leistung des Gesamtsystems darstellt.
Mehrere Multipliziereinheiten können allerdings überraschenderweise die Leistung
nicht entscheidend verbessern. Deshalb werden letztlich drei Designs für die 233-Bit-ECC-
Beschleunigung näher untersucht. Deren wesentlicher Unterschied liegt in der Geschwindigkeit
und damit der Größe des Feldmultiplizierers.
Für eine Feldmultiplikation erfordert das schnellste und damit auch das größte Design drei
Taktzyklen. Das mittelgroße Design benötigt neun und das kleinste 27 Taktzyklen. Die Gesamtzeit
für eine ECPM beträgt 60 µs für das schnellste, 80 µs für das mittlere und 230
µs für das kleinste Design. Die schnelleren beiden Designs gehören zu den schnellsten
bisher veröffentlichten Implementierungen. Dabei ist die erforderliche Siliziumfläche von
2,1 mm 2 für das größte bis zu 1,3 mm 2 für das kleinste Design im Vergleich zu anderen
Implementierungen mit vergleichbarer Geschwindigkeit sehr gering. Die benötigte Energie
der vorgestellten Designs für eine ECPM ist geringer als bei allen anderen bisher veröffentlichten
Implementierungen. Entsprechend dem 233-Bit-Design wurden auch Designs
für andere elliptische Kurven bis zu 571 Bit implementiert, vermessen und verglichen. Abbildung
2.10 zeigt die verschiedene Flächen und Energieverbräuche für eine ECPM der
untersuchten Designs von 163 bis 571 Bit.
Für den TSN wurde die 233-Bit-Implementierung mit der mittleren Geschwindigkeit, d.h. 9
Clockzyklen pro Feldmultiplikation, gewählt.
Dies wird dadurch begründet, dass die 233-Bit-Implementierung das beste Verhältnis zwischen
Fläche und Energie und Leistung (Geschwindigkeit) verspricht und dabei eine hohe
Sicherheit bietet. Für eine noch höhere Sicherheit besteht die Möglichkeit der Nutzung
größerer Schlüssellängen, wobei das entsprechend mehr Fläche in der Schaltung, mehr
Berechnungszeit und auch mehr Stromverbrauch implizieren würde.
Die 233-Bit-Implementierung wurde bereits in einem System-on-Chip (SoC) integriert, das
neben einem eingebetteten 32-Bit-Prozessor Hardwareblöcke für die Verarbeitung von
Netzwerkprotokollen und symmetrischer Verschlüsselung umfasst. Auf diesem Chip, der
bereits im IHP in 0,25-µm-CMOS-Technologie gefertigt wurde, kann die Leistung des Hardwaredesigns
gut mit einer alternativen Softwareimplementierung (MIRACL [47]), die auf
dem eingebettetem Prozessor läuft, verglichen werden. Im Vergleich mit der Softwareim-
30

Abschlussbericht
Trusted Sensor Node
plementierung ist die dedizierte Hardware hierbei 1000-mal schneller und benötigt insgesamt
ein 500stel der Energie für eine 233-Bit-ECPM.
Abbildung 2.9: Blockschaltbild des 233-Bit-ECC-Beschleunigers. Ein 233 Bit
breiter, von einer Controller-Einheit kontrollierter Bus verbindet die
Rechen- und Registereinheiten.
Abbildung 2.10: Resultate der verschiedenen ECC-Beschleuniger-Schaltungen. Die
Balken zeigen die benutzte Siliziumfläche. Die Linien entsprechen
dem Energieverbrauch.
2.14.5 Parameter im TSN
Im TSN befindet sich eine Recheneinheit für die 233-Bit-Elliptische-Kurven-Punkt-Multiplikation
im Feld (GF(2 233 )). Das Design der ECC-Recheneinheit entspricht derjenigen, die
in Abbildung 2.9 dargestellt ist. Es beinhaltet:
31

Abschlussbericht
Trusted Sensor Node
• Acht 233-Bit-Register, von denen vier von außen zugreifbar sind, die anderen vier
sind für die interne Berechnung.
• Eine Arithmetisch-Logische-Einheit (ALU), die die Addition und die Quadrierungsoperation
ausführt. Beide Operationen können innerhalb eines Taktzyklus berechnet
werden.
• Einen Multiplizierer, der die Multiplikation im Basisfeld (GF(2 233 )) inklusive der Reduktion
ausführt. Basierend auf den Ergebnissen der Design-Space-Exploration haben
wir uns für das Design, welches neun Taktzyklen pro Multiplikation benötigt (also das
4-Segment-Design), entschieden. Eine detaillierte Untersuchung des Multiplizierers
kann in [14] gefunden werden.
• Einen Controller und Testbit-Einheit, die den Datenfluss steuern. Das Programm
selbst ist Teil des VHDL-Codes und ist optimiert auf die Busstruktur und den gewählten
Multiplizierer.
Sowohl die Quadrierungseinheit als auch der Multiplizierer führen automatisch und innerhalb
eines Taktzyklus die fest verdrahtete Reduktionsoperation mit dem für das Feld standardisierten
Reduktionspolynom (r(x) = x 233 + x 74 + 1) aus. Die Ausführung des Lopez-
Dahab-Algorithmus benötigt
• 232 mal 55 (12760) Taktzyklen für die Punktmultiplikation
• 314 Taktzyklen für die Inversion im Basisfeld
• 119 Taktzyklen für die Koordination und Bereitstellung des Ergebnisses,
also insgesamt 13193 Taktzyklen. Die ECC-Punktmultiplikation wird gestartet, indem der
Faktor k, die Koordinaten des Basispunktes x und y und der Parameter der Kurve b in
die entsprechenden Register (siehe Anhang) geschrieben werden. Anschließend wird das
32-Bit-Kommandowort, welches die Gesamtoperation startet an die Kontrolleinheit übergeben.
2.15 SHA-1 / PRNG
Das SHA-1-Modul ist nach den NIST-Standards FIPS 180-1 [34], FIPS 186-1 [35] und FIPS
186-2 [36] aufgebaut. Der SHA-1 ist ein Teil des Digital Signature Standard (DSS), der eindeutige
Hashwerte für einen Datenblock erzeugt. Anhand dieser kann man feststellen, ob
ein Datenblock nachträglich verändert wurde oder nicht. Weiterhin kann die Komponente
als Pseudozufallszahlengenerator (engl. Pseudo Random Number Generator (PRNG))
verwendet werden. Derartige Zufallszahlen werden für viele kryptographische Algorithmen,
wie zum Beispiel ElGamal, benötigt. In Abbildung 2.11 ist das Blockdiagramm des SHA-1-
Moduls dargestellt. Der zugrunde liegende Algorithmus und die Funktionalität der Komponente
werden in den folgenden Abschnitten genauer beschrieben. Die Implementierung
des SHA-1 ist auf 32-Bit-Lese- und Schreibzugriffe ausgelegt. Für einen einfachen Zugriff
32

Abschlussbericht
Trusted Sensor Node
wurde das Modul mit einer Schnittstelle mit einem memory-like Interface ausgestattet. Die
Implementierung setzt nicht den kompletten SHA-1 um. Sie enthält nur die Funktion G,
die den Hauptteil des Algorithmus darstellt. Die restlichen Funktionen, wie zum Beispiel
Bitstuffing, werden sinnvollerweise in höheren Schichten umgesetzt.
Software
Split data into 512-Bit blocks;
Bitstuffing for the last data block;
Write and read controlregister;
Write data to registers H0 to H4(160-bit KEY);
Write data and W0 to W15 (512-bit data block);
Function G
Function K
Function f
Hardware
Algorithm of G
Software
Read registers H0 to H4 (160-bit Signature of the data);
Abbildung 2.11: Ablauf der Signatur mit Hilfe von Soft- und Hardware
2.15.1 Secure Hash Algorithmus
Für den SHA-1 werden die Daten, über die der Hashwert gebildet werden soll, in 512 Bit
lange Blöcke zerlegt. Lässt sich das Datum nicht in ein Vielfaches von 512 zerlegen, muss
der letzte Block aufgefüllt werden. Dies wird als „Bitstuffing“ bezeichnet. Zur Realisierung
sind die letzten 64 Bit des letzten Datenblocks reserviert. Sie enthalten die Länge der zu
signierenden Nachricht. Mit Hilfe dieses Wertes kann festgestellt werden, wie viele Bits des
letzten Blocks nicht mehr für die Nachricht benötigt werden und aufgefüllt werden müssen.
Das Auffüllen wird umgesetzt, indem nach dem letzten für die Nachricht relevanten Bit eine
binäre „1“ eingeführt wird. Die restlichen Bitstellen werden mit „0“ belegt.
Für die Integritätsprüfung mit Hilfe des SHA-1 gibt es zwei unterschiedliche Verfahren.
Das erste Verfahren basiert darauf, dass beide Kommunikationspartner einen geheimen,
frei gewählten Schlüssel kennen. Die zu signierende Nachricht wird dabei zunächst auf ein
Vielfaches von 512 Bit vervollständigt und anschließend in 512 Bit lange Blöcke zerlegt.
Diese werden dann blockweise an den SHA-1 übergeben. Neben den Datenblöcken benötigt
der Algorithmus einen definierten Startwert. Dieser ist 160 Bit lang und wird als der
geheime „Schlüssel“(KEY) bezeichnet. Er sollte nur den Kommunikationspartnern bekannt
sein, da mit diesem eine eindeutige Signatur für die Daten erzeugt wird und diese auch
verifiziert werden kann. Die erstellte Signatur wird mit den Daten übertragen. Der Empfänger
führt ebenfalls den SHA-1 mit dem gleichen Schlüssel auf die empfangenen Daten
aus. Wurden die Daten bei der Übertragung durch Dritte verändert, führt dies zu einer anderen
Signatur. Derartige Veränderungen werden dann beim Vergleich beider Signaturen
entdeckt. Um eine sichere Signierung der Daten zu gewährleisten, muss der Schlüssel
für den SHA-1 zwischen den Kommunikationspartnern geheim übertragen werden. Dafür
33

Abschlussbericht
Trusted Sensor Node
werden Schlüsselaustauschverfahren, wie zum Beispiel das Verfahren von ElGamal, benötigt.
Mit deren Hilfe wird verhindert, dass Dritte unerlaubt in den Besitz des geheimen
Schlüssels kommen.
Die zweite Möglichkeit zur Signierung von Daten mittels SHA-1 besteht in der Nutzung des
ECC als asymmetrisches Verfahren, so dass der Sender der Nachricht einen privaten und
einen öffentlichen Schlüssel besitzt. Der private Schlüssel dient der Signierung durch den
Absender und der öffentliche Schlüssel der Prüfung der Signatur durch den Empfänger.
Dieses Verfahren wird als „ECDSA“ bezeichnet und ist unter ANSI X9.62 standardisiert.
Hierbei fungiert der sogenannte „Key“ als standardisierter Initialisierungswert (h0 bis h4).
Im Folgenden wird der Ablauf und der Aufbau des Secure-Hash-Algorithmus vorgestellt.
Wie bereits erläutert, erhält der Algorithmus als Eingabe die zu signierenden Daten und
den geheimen Schlüssel. Zu Beginn wird das „Bitstuffing“ für die zu signierenden Daten
ausgeführt. Der letzte Block wird der oben beschriebenen Vorgehensweise nach mit einer
„1“ und „0“ aufgefüllt. Diese Vorverarbeitung der Daten wird vorzugsweise in Software
realisiert, da hier kaum eine Optimierung durch die Verwendung von Hardware erreicht
werden kann. Im Anschluss wird der geheime 160-Bit-Schlüssel in die entsprechenden
Register (H-Register) des SHA-1-Hardware-Moduls geschrieben. Dazu ist es notwendig,
den Schlüssel in fünf 32-Bit-Blöcke zu unterteilen. Der Datenblock wird in sechzehn 32-Bit-
Blöcke aufgeteilt und in die W-Register der Komponente geschrieben. Nachdem das letzte
der W-Register geschrieben wurde, beginnt die SHA-1-Hardwarekomponente mit der Generierung
der Signatur. Ist der Algorithmus nach 80 Taktzyklen abgeschlossen, kann der
nächste Datenblock in die W-Register geschrieben werden. Dies wird für alle 512-Bit-Blöcke
durchgeführt. Nachdem alle Daten die SHA-1-Komponente passiert haben, befindet
sich in den H-Registern des Moduls die Signatur des Datenpakets. Diese kann nun ausgelesen
werden, um zum Beispiel mit der Nachricht verschickt zu werden. Der innere Aufbau
der Hardwarekomponenten umfasst drei Funktionen, die zur Generierung der Signatur benötigt
werden. Bei diesen handelt es sich um die Funktionen f, K und G. In Abbildung 2.11
ist der Aufbau des SHA-1 dargestellt mit der Unterteilung nach Soft- und Hardware.
Die Arbeitsweise dieser drei Funktionen f, K und G steht in Abhängigkeit zur Anzahl der
verstrichenen Taktzyklen. Die Funktion G stellt die Hauptfunktion des SHA-1 dar. Mit ihr
wird aus dem eingegebenen 160-Bit-Schlüssel und dem 512 Bit langen Datenblock die
Signatur erzeugt. Die Funktion K liefert in Abhängigkeit der aktuellen Laufzeit des Algorithmus
eine Konstante, die in der Funktion G genutzt wird, um einen Teil der Zwischenergebnisse
für die Signaturerzeugung zu generieren. Diese Zwischenergebnisse werden nach
jedem Takt in den Registern A bis E abgelegt. Nach 80 Takten wird der Inhalt dieser Register
in den H-Registern verrechnet. Diese enthalten dann die Signatur des Datenblocks.
Die Funktion f erzeugt, ebenfalls in Abhängigkeit von der aktuellen Taktanzahl, einen Teil
dieser Zwischenergebnisse und bezieht bei der Berechnung ihres neuen Wertes die Zwischenergebnisse
in den Registern B, C und D des vorherigen Taktes ein. Listing 2.2 zeigt
den Aufbau der Funktionen f und K.
f(j) with 0

Abschlussbericht
Trusted Sensor Node
f(j,B,C,D)= (B and C) or (B and D) or (C and D) for 40

Abschlussbericht
Trusted Sensor Node
Zu Beginn jedes der 80 Takte der Funktion G ermitteln die Funktionen f und K ihre Zwischenergebnisse.
Als Ergebnis von K wird eine 32 Bit lange Konstante ausgegeben, die in
Abhängigkeit der aktuellen Anzahl von Takten bestimmt wird. Die Funktion F ermittelt ihr
32-Bit-Ergebnis aus der Verknüpfung der Werte aus den Registern B, C und D. Zu Beginn
des Algorithmus enthalten diese, wie die H-Register auch, den geheimen Schlüssel und
im weiteren Verlauf die Zwischenergebnisse der Signatur. Der Aufbau der Verknüpfung ist
ebenfalls von der aktuellen Taktanzahl abhängig. Nachdem diese beiden Funktionen ihre
Ergebnisse generiert haben, startet die Funktion G. Als erstes wird ein weiteres Zwischenergebnis
in Abhängigkeit von der aktuellen Taktzahl ermittelt. Dieses entspricht entweder
dem Inhalt des Registers W0 oder der XOR-Verknüpfung der Register W13, W8, W2 und
W0 mit einer zusätzlichen Bitschiebeoperation des Ergebnisses nach links (in Richtung der
höherwertigen Bits). Im Anschluss werden alle W-Register um ein Register nach rechts,
das heißt in Richtung der niederwertigen Register, geschoben. Der Wert des Registers W0
wird in dem Register W15 abgelegt.
Aus all den bis zu diesem Zeitpunkt ermittelten Werten wird durch Addition der Ergebnisse
das Zwischenergebnis eines Teilblocks der Signatur ermittelt. Dessen Wert setzt sich aus
einer fünfmaligen Bitschiebeoperation des Registerinhalts von A nach links zusammen.
Auf diesen Wert werden anschließend der Registerinhalt von E sowie die Ergebnisse von
f, K und der Verknüpfung der drei W-Register addiert. Dieses Ergebnis wird später in dem
Register A abgelegt. Zuvor werden die Inhalte der Register B bis E um ein Register nach
links verschoben. Der neue Wert des Registers C wird zudem noch um 30 Bit nach links
verschoben. Nun enthält das Register A den zuvor berechneten Wert.
Nach 80 Takten werden die Zwischenergebnisse aus den Registern A bis E mit den Inhalten
der H-Register addiert. Der Wert in Register B wird zudem noch um 30 Bit nach
links verschoben. In den H-Registern steht nun die Signatur der bis dahin behandelten
Datenblöcke. Die Signatur kann über Software aus den H-Registern ausgelesen werden.
2.15.2 Pseudo Random Number Generator (PRNG)
Es besteht die Möglichkeit, das SHA-1-Modul als Generator für Pseudozufallszahlen zu
verwenden. Dies wird in FIPS 186-2 [36] genauer erläutert. Für die Generierung derartiger
Zahlen mit Hilfe des Secure Hash Algorithmus ist es zu Beginn notwendig einen Schlüssel
und einen Datenblock in die entsprechenden H- und W-Register des Moduls zu schreiben.
Die Kombination aus Schlüssel und Daten bilden den Ausgangswert (Seed) für die
Generierung der Pseudozufallszahl. Verwendet man stets den gleichen Seed, wird immer
eine identische Folge von Zufallszahlen erzeugt. Aufgrund der Wiederholbarkeit nennt
man diese Werte auch pseudozufällige Zahlen. Ist der Seed jedoch unbekannt, wirken die
Ergebnisse des Algorithmus wie zufällig generierte Zahlen. Nach dem derzeitigen Kenntnisstand
kann man nicht anhand dieser Zahlenfolgen auf den Seed schließen. Wurden
alle Register mit den Ausgangswerten belegt, kann der Algorithmus gestartet werden. Am
Ende jedes Durchlaufs steht eine Pseudozufallszahl von 160 Bit in den Registern H0 bis
H4.
36

Abschlussbericht
Trusted Sensor Node
Möchte man die Komponente für die Generierung von Hashwerten und als PRNG verwenden,
ist es notwendig, beim Wechsel zwischen beiden Funktionalitäten die Werte der H-
und W-Register zu speichern. Darüber hinaus müssen bei der Wiederaufnahme der Funktionalität
die gespeicherten Werte in die Register zurückgeschrieben werden. Für einen
Wechsel von PRNG zu SHA-1 muss die letzte ermittelte Zufallszahl und der Inhalt aller W-
Register gespeichert werden. Im Anschluss können der Schlüssel und der Datenblock für
den SHA-1 in die Register geschrieben werden.
Möchte man im Anschluss an einen SHA-1-Durchlauf wieder eine Pseudozufallszahl generieren,
muss der Hashwert und der Inhalt der W-Register gespeichert werden. Dies ist
nur dann notwendig, wenn im Folgenden ein Hashwert in Abhängigkeit von diesen Werten
erzeugt werden soll. Ansonsten reicht es aus, die letzte generierte Zufallszahl in die H-
Register zurück zu schreiben und auch den Inhalt der W-Register wieder so herzustellen,
wie er vor dem Wechsel von PRNG auf SHA-1 war.
2.15.3 Hardwarebeschreibung
Das implementierte SHA-1-Modul, welches in Abbildung 2.12 gezeigt wird, besitzt ein Memory-Like-Interface
und fünf 32-Bit-Register für den 160 Bit langen Schlüssel und den
Hashwert. Weiterhin sind sechzehn 32-Bit-Register für den Datenblock und die Zwischenergebnisse
vorhanden. Der Schlüssel und der Datenblock werden in 32-Bit-Blöcke aufgeteilt
und in die Register geschrieben. Ein zusätzliches 8-Bit-Kontrollregister wird verwendet,
um die Komponente zu konfigurieren und zu steuern. Im folgenden Abschnitt werden die
verschiedenen Register genauer beschrieben.
Abbildung 2.12: Blockschaltbild des SHA-1-Moduls
W0 ... W15:
Diese sechzehn 32-Bit-Register beinhalten den 512-Bit-Datenblock. Das Ergebnis des Algorithmus
ist ein 160 Bit langer Hashwert für diesen Datenblock. Um diese Register lesen
und schreiben zu können, muss man diese über die SHA-1-Basisadresse (0x20000000)
plus einen Offset zwischen 0 und 15 adressieren. Nachdem das Register W15 geschrieben
wurde, beginnt der SHA-1 automatisch mit der Generierung der Signatur.
H0 ... H4:
Diese fünf 32-Bit-Register enthalten den 160 Bit langen Schlüssel zu Beginn des Algorithmus
und am Ende den Hashwert des Datenblocks. Adressiert werden diese Register über
37

Abschlussbericht
Trusted Sensor Node
die SHA-1-Basisadresse plus einen Offset zwischen 16 und 20. Nachdem der Algorithmus
durchlaufen wurde, ist ein entsprechendes Interruptflag im Kontrollregister gesetzt. Dieses
wird über das Auslesen des Registers H0 zurückgesetzt.
CTRL:
Das 8-Bit-Kontrollregister beinhaltet Konfigurations- und Statusinformationen des SHA-1-
Moduls (siehe Tabelle 2.2). Es wird über die SHA-1-Basisadresse plus einen Offset von 21
adressiert.
Bit Beschreibung
7 run
6 irpend
5 reserved
4 reserved
3 reserved
2 new block
1 BRDYN
0 reserved
Tabelle 2.2: Struktur des Kontrollregisters
Bit 1 (BRDYN) schaltet den BRYDN (Bus ready)-Port des SHA-1-Moduls zu. Wenn dieses
Bit gesetzt wurde, wird der AMBA-Bus, an welchen die Komponente über den Memory
Controller angeschlossen wurde, als besetzt angezeigt. BRYDN ist „0“ (aktiv), während
der SHA-1 läuft.
Bit 2 (new block) zeigt an, dass ein neuer Datenblock beginnt. In diesem Fall wird ein initialer
Schlüssel, der in einigen Konstanten gespeichert ist, verwendet. Diese Funktionalität
kann auch realisiert werden, in dem man den Schlüssel von außen in die entsprechenden
Register schreibt. Werden keine neuen Daten in die H-Register geschrieben, wird
der Hashwert des zuvor verwendeten Datenblocks als Ausgangspunkt für den nächsten
Datenblock verwendet. Dadurch wird eine Abhängigkeit des Hashwertes von vorangegangenen
Ergebnissen realisiert und es können Datenblöcke, die größer als 512 Bit sind,
behandelt werden.
Bit 6 (irpend) zeigt den anliegenden Interrupt, wenn der SHA-1 durchlaufen wurde. Um
den Interrupt zurückzusetzen, kann dieses Bit überschrieben werden oder das Register
H0 ausgelesen werden.
Bit 7 (run) zeigt an, ob der Algorithmus noch läuft oder bereits beendet wurde. Dieses
Bit wird auf „1“ gesetzt, nachdem Register W15 geschrieben und auf „0“, nachdem der
gesamte Algorithmus durchlaufen wurde.
Bit 6 und 7 darüber können die Werte von „Bus Ready“ und „Interrupt“ abgerufen werden.
38

Abschlussbericht
Trusted Sensor Node
Register Adresse
W0 ... W15 SHA1_BASE + [0 ... 15]
H0 ... H4 SHA1_BASE + [16 ... 20]
CTRL SHA1_BASE + 21
Tabelle 2.3: Adressen der SHA-1-Register
2.16 SPI
Das SPI wurde aus der „Synopsys DesignWare“-Bibliothek [51], die dem IHP zur Verfügung
steht, übernommen. Es ist direkt mit dem APB verbunden. Das Interface besitzt drei
„Chip-Select“-Pins mit denen jeweils eine SPI-Slave-Komponente angesprochen werden
kann. Für die Datenübertragung stehen ein Data-Out- und ein Data-In-Pin zur Verfügung.
Weiterhin gibt es einen Pin für den SPI-Takt, der die Geschwindigkeit der Datenübertragung
festlegt.
Der SPI-Master kann durch das Schreiben der entsprechenden Kontrollregister konfiguriert
werden. Hierzu zählen das Einstellen des SPI-Takts, der aktiven Taktflanke und der
Phasenverschiebung des Takts. Der SPI-Master wurde mit Hilfe einer einfachen, angeschlossenen
Slavekomponente getestet. Zwischen dieser und dem Master wurden anschließend
Datenübertragungen ausgeführt.
2.17 Pads und Pins
Die Pads sind die Kontaktfelder auf einem Chip, über die mit Hilfe von Bonddrähten die
Verbindung zu den Pins eines Gehäuses geführt wird. Das hier verwendete QFP-Gehäuse
(siehe Abbildung 2.13) besitzt 128 Pins, von denen 87 I/O-Pins und 24 Pins für die
Spannungsversorgung. Die übrigen 17 Pins nicht belegt sind (siehe Abbildung 2.15). Hinsichtlich
der Pinverteilung werden 26 Pins an der kurzen und 38 Pins an jeder langen
Kante untergebracht.
Über die Pins erfolgt die Kommunikation des TSN mit externen Komponenten. Insbesondere
das Speicherinterface sowie UART und SPI sind über die Pins nach außen geführt.
Außerdem gibt es eine Schnittstelle zur DSU sowie Pins für Testzwecke, um die Funktionsfähigkeit
des Speichers zu überprüfen.
Die Basiskonfiguration des LEON2 sieht vor, dass für das Speicherinterface alle 32 Datenleitungen
nach außen geführt werden. In der vorliegenden Umsetzung ist die Anzahl der
nach außen geführten Datenleitungen auf 16 reduziert worden, um nötige Siliziumfläche
möglichst gering zu halten.
39

Abschlussbericht
Trusted Sensor Node
Für die Spannungsversorgung sind 24 Pins vorgesehen, die sich in je 8 Pins für die Corespannung,
die Padspannung und die Masse aufteilen. Die Anzahl der Pins und deren
Position für die Spannungsversorgung ist vom IHP-eigenen Testsystem vorgegeben.
Um eine Interoperabilität mit anderen Chips zu gewährleisten, beträgt die Padspannung
3,3 V. So liegt der Spannungswert für eine logische Null bei 0 V und für eine logische Eins
bei 3,3 V. Die Werte entsprechen dem Standard von Low Voltage Transistor Transistor
Logic (LVTTL). Die Corespannung beträgt 2,5 V und wird von der verwendeten Technologie
vorgegeben.
Abbildung 2.13: Gehäuse des TSN vom Typ QFP128
2.18 Vom VHDL zum ASIC
Die Generierung des ASIC aus dem VHDL ist ein mehrstufiger Prozess. Zunächst werden
die Funktionen des Chips in einer Hochsprache beschrieben.
VHDL bietet dafür die so genannte Verhaltensbeschreibung. Hierbei werden die entsprechenden
Schnittstellen der Schaltung mit der Außenwelt und die Funktionalität des Systems
beschrieben. Diese Form erinnert stark an die Programmierung in anderen Programmiersprachen
wie C++, Java oder Python und macht es somit einfach für Entwickler im
Bereich der digitalen Schaltungen solche zu beschreiben.
Der nächste Schritt ist die funktionale Simulation, in der mittels einer Testbench die Hardwarebeschreibung
in VHDL auf ihre Korrektheit geprüft wird. In einer Stimuli-Datei im
VHDL-Format werden die Eingänge des simulierten Bausteins mit Werten belegt und nach
Abschluss der Simulation liegen die Ausgangswerte an den Ausgangsports an. Die Abbildung
2.14 zeigt den Aufbau für die funktionale Simulation einer Hardwarekomponente.
Ist die Hardware korrekt beschrieben, erfolgt durch die Synthese der nächste Schritt zur
Generierung des ASICs, die Umsetzung in eine Gatternetzliste. Dabei werden Informationen
aus einer Zellbibliothek, bestehend aus den Grundgattern, mit der funktionalen
40

Abschlussbericht
Trusted Sensor Node
Beschreibung so verknüpft, dass die Gatternetzliste entsteht. Nach der Synthese muss
erneut die Korrektheit der Datenverarbeitung in der Hardwarekomponente geprüft werden.
Dieses erfolgt analog zur Prüfung in der Pre-Synthese-Simulation unter Zuhilfenahme einer
Testbench (die i.d.R. die gleiche Testbench wie für die Pre-Synthese-Simulation ist).
Neben dem funktionalen Test kann hier geprüft werden, ob die gewünschte Clockfrequenz
erreicht wird.
Abbildung 2.14: Test eines entwickelten Hardware-Modells
Abbildung 2.15: Layout des TSN-Chip nach der Verdrahtung. Insbesondere die
Verdrahtung auf den beiden obersten Metallebenen (hier: gelb und
braun) treten hervor
2.19 Layoutgenerierung
In der Phase der Layoutgenerierung wird der Schritt von der Gatternetzliste, die lediglich
aus Grundgattern besteht, zum eigentlichen Chip vollzogen. Zunächst werden die
41

Abschlussbericht
Trusted Sensor Node
Außenmaße festgelegt. In der Regel werden diese durch die Anordnung der Pads, dem
sogenannten Padring, vorgeben. Dieser Padring muss so gestaltet sein, dass die Anzahl
der Pads an jeder Kante der Pinanzahl an der Kante des Gehäuses entspricht. Anschließend
werden die Black-Box-Komponenten manuell platziert. In diesem Fall sind das die
Speicherblöcke für den Cache. Diese Black-Box-Komponenten sind vorgefertigte Instanzen,
die bereits dem Layoutprozess unterzogen wurden und daher wie Bibliothekselemente
verwendet werden. In der verbleibenden Fläche werden die Grundgatter platziert und
anschließend der „Clock tree“ generiert. Dieser sorgt mit Hilfe von schnellen Treiberelementen
dafür, dass das Clocksignal möglichst gleichmäßig auf dem Chip verteilt wird.
Zudem bestimmt er später wesentlich die maximal mögliche Taktfrequenz mit. Die Verdrahtung
ist der letzte Schritt in der Layoutgenerierung. Die Abbildung 2.15 zeigt den TSN nach
der Verdrahtung. Dabei werden die Gatter über 5 Metallebenen miteinander verbunden.
2.20 Boardbeschreibung
Das Kernstück auf der Platine ist der TSN-Prozessor. Daneben wird externer Speicher
in Form von RAM und Flash den ASIC vervollständigen. Als Sensorik sind Infrarot- und
Beschleunigungssensoren vorgesehen, die mögliche Ortsveränderungen detektieren können.
Zur Kommunikation mit weiteren Knoten und dem Server kommen ein Zigbee-Funkmodul
nach dem IEEE-802.15.4-Standard sowie ein Bluetooth-Modul zum Einsatz.
Überdies soll das Board eine Elektronik zur Bereitstellung der Spannungsversorgung besitzen.
Dieses ist so gestaltet, dass entweder ein Brennstoffzellensystem, Batterien/Akkus
oder gegebenenfalls ein Solarzellensystem zum Einsatz kommen kann.
2.21 Systemtest und Software
Wie in Abschnitt 2.18 beschrieben existiert für den TSN eine Testbench. Durch die Komplexität
des Systems gibt es einen angepassten Aufbau.
Die Testroutinen sind in der Programmiersprache C verfasst. Ein Cross-Compiler erzeugt
ein ausführbares Programm, das in einem simulierten Speicher abgelegt wird. Dieser simulierte
Speicher ist Teil der Testbench. Die CPU des TSN arbeitet das Programm regulär
ab und wird damit in ihrer Funktion getestet.
Zurzeit existieren einzelne Testroutinen in Software, die stapelweise abgearbeitet werden.
Diese Testroutinen senden Daten an das zu testende Modul und werten im Anschluss
die Ergebnisse aus. Für alle Komponenten (UART, SPI, AES, ECC, SHA-1) sind solche
Prozeduren vorhanden. Ein Auszug der Testdaten befindet sich im Anhang. Die jeweiligen
Testvektoren wurden den Standardisierungsdokumenten entnommen [34], [35], [36], [37].
42

Abschlussbericht
Trusted Sensor Node
2.22 Energie
Vor allem im Bereich von batteriebetriebenen Geräten ist es von Interesse, die voraussichtliche
Leistungsaufnahme der Hardware bestimmen zu können. Das ermöglicht die
Auswahl einer geeigneten Spannungsquelle, die weder unter- noch überdimensioniert ist.
Eine schnelle, aber ungenaue Angabe der Leistungsaufnahme ist durch das Synthesetool
möglich. Dieser Wert ist allerdings ausreichend, um die Anzahl der Pads für die Stromversorgung
festzulegen (je Pad ca. 100 mA) sowie die Breite der stromzuführenden Leitungen
zu bestimmen.
Sinnvoller ist es, spezielle Programme einzusetzen, die die Leistungsaufnahme anhand
der tatsächlichen Umschaltvorgänge der Gatter ermittelt. Die Abbildung 2.16 zeigt die Simulation
des TSN mit der Aufgliederung in die einzelnen Komponenten. Die Aktivitätsphasen
stechen jeweils durch erhöhte Leistungsaufnahme hervor. Ein Analysewerkzeug
hilft die Leistungsaufnahme in jedem Clocktakt zu summieren, so dass, wie in Tabelle 2.4
gezeigt, die exakte Leistungsaufnahme einer Operation (z.B. Hashwertberechnung oder
Verschlüsselung) ermittelt werden kann. Die Leistung ist nach den einzelnen Komponenten
aufgeschlüsselt. Durchschnittlich benötigt der TSN 95 mW, von denen 47 mW auf die
CPU entfallen. Die verbleibende Leistung verteilt sich auf die Komponenten SHA-1, AES
und ECC. Für die kryptographischen Funktionen sind jeweils die Leistungsaufnahme und
Laufzeit in Tabelle 2.4 für eine typische Operation angegeben.
Die tatsächliche Leistungsaufnahme kann abweichen, da die Pads Transistoren enthalten,
die mit 2,5 V versorgt werden. Diese werden in der Simulation der Leistungsaufnahme
nicht mit berücksichtigt.
Abbildung 2.16: Analyse der Leistungsaufnahme des Gesamtsystems (rot) sowie
selektierter Einzelkomponenten. Der grüne Plot zeigt exemplarisch
den deutlich erhöhten Stromverbrauch des ECC-Beschleunigers in
seiner Aktivitätsphase.
43

Abschlussbericht
Trusted Sensor Node
Komponente Leistungsaufnahme Laufzeit Taktanzahl
SHA-1 8,12 mW 5.125 ns 82
AES 3,94 mW 4.875 ns 78
ECC 29 mW 822.875 ns 13.166
LEON-Kern 47,2 mW ≈6,25 ms ≈100.000
TSN-System (ohne Pads) 95 mW ≈6,25 ms ≈100.000
Tabelle 2.4: Simulation der Leistungsaufnahme für Einzelkomponenten und das
Gesamtsystem bei 16 MHz
2.23 Debug- und Diagnoseschnittstellen
Ein komplexes System, wie der TSN, lässt sich hinreichend simulieren, solange die Simulationen
auf den Chip beschränkt sind. Eine Simulation mit extern angeschlossenen
Modulen (z.B. den Radiomodulen) ist schwer umzusetzen. Für diesen Zweck müssten
Verhaltensmodelle der externen Komponenten zur Verfügung stehen welche jedoch, bedingt
durch ihre hohe Komplexität, nicht vorhanden sind. Anstelle derer nutzt man simple
Modelle von externen Komponenten, die z.B. einfach Daten wieder zurücksenden.
Darüber hinaus kann der Test eines komplexen Systems in der Simulation nie so umfassend
sein, dass alle Komponenten exzessiv validiert werden. Die Simulationszeiten sind
sehr lang, so dass eine ausführliche Simulation nach der Erstellung des Layouts bis zu
mehrere Stunden in Anspruch nehmen kann, obwohl nur einige Millisekunden simuliert
werden.
Aufgrund der nicht vollständigen Simulation des ASICs in seiner Arbeitsumgebung ist es
notwendig, Diagnoseschnittstellen, wie die in Abschnitt 2.23 beschriebene DSU, bereitzustellen.
Das erleichtert die Fehlersuche bei Hardware- oder Softwareproblemen. Die Fehler
in der Hardware können dann im nächsten Fertigungszyklus behoben werden.
44

3 Software
3.1 Das Betriebssystem eCos
eCos ist ein frei verfügbares Betriebssystem für eingebettete Systeme mit Echtzeitanforderungen.
Es wird unter einer angepassten GPL-Lizenz [33] verbreitet. Diese erlaubt die
Integration eigener Module in eCos ohne die Verpflichtung, diese auch unter der GPL verbreiten
zu müssen.
In diesem Abschnitt geben wir zunächst einen kurzen Überblick über die Funktionsweise
von eCos und den von der eCos User Community bereitgestellten Funktionsumfang. Anschließend
beschreiben wir das Erstellen und Integrieren von neuen Funktionen. Im letzten
Teil des Abschnittes wird die Toolchain und der build-Prozess von eCos erläutert.
3.1.1 eCos im Detail
Bei eCos handelt es sich um ein feingranular konfigurierbares Betriebssystem. Es bietet
die Möglichkeit den Kern sehr spezifisch an die eigenen Anforderungen anzupassen.
Hierbei wird der Anwender durch ein Konfigurationswerkzeug unterstützt. Für viele Anwendungsfälle
existieren bereits Lösungen, die je nach Bedarf eingebunden werden können.
Tabelle 3.1: Speichergrößen verschiedener Konfigurationen von eCos 3.0
Speicherbedarf in kB
Nr. Konfiguration Gesamt TCP/IP-Stack
1 Standardumfang übersetzt ohne Optimierung 320,994
2 Standardumfang optimiert auf Größe 175,094
3 (2) mit Lightweigtht-TCP/IP-Stack 399,6 224,5
4 (2) mit OpenBSD-TCP/IP-Stack 3624,3 3372,5
5 Minimalkonfiguration optimiert auf Größe 52,722
6 uIP-Stack 16,26
In Tabelle 3.1 sind die Code- und Datenbereichsgrößen verschiedener Konfigurationen von
eCos 3.0 angegeben. Anhand der Daten wird deutlich, wie entscheidend die Auswahl der
richtigen Komponenten und Optionen ist, wenn insbesondere hinsichtlich des zur Verfügung
stehenden Speicherplatzes optimiert werden muss. Der Ausgangspunkt des TSN ist
die Konfiguration 3, welche dann entsprechend den Anforderungen erweitert wurde. Allerdings
wird von Gaisler Research die Version 1.3 verwendet, so dass der Ausgangspunkt
für den TSN etwas weniger Programmcode umfasst.

Abschlussbericht
Trusted Sensor Node
Das Betriebssystem eCos ist vollständig in C implementiert, ist damit leicht erweiterbar
und portierbar und bietet darüber hinaus eine C++-Schnittstelle.
Basisprimitive
eCos Applikationen können in mehrere Threads aufgeteilt werden, die nebenläufig ausgeführt
werden. Jeder Thread besitzt einen eigenen Kontext, Stack und Priorität. Der Kern
sorgt für eine nebenläufige Ausführung der Threads entsprechend ihrer Priorität. Hierbei
kann zwischen einem Multi-Level- und einem Bitmap-Scheduler gewählt werden. Der
Multi-Level-Scheduler erlaubt die Ausführung von mehreren Threads auf einem Prioritätslevel
und wird für den TSN verwendet.
Für die Kommunikation zwischen Threads werden verschiedene Primitive wie:
• Flags,
• Zähler,
• Semaphore,
• Mutexe mit Ereignisvariablen,
• Mailbox,
• Synchronisierte dynamische Speicherverwaltung und
• Spinlocks
bereitgestellt. Die Auswahl des Primitivs ist abhängig vom Anwendungsfall: Flags zum
Beispiel benötigen sehr wenig Speicher, während Spinlocks ein atomares Sperren von
gemeinsam genutzten Datenstrukturen bieten.
Darüber hinaus enthält eCos bereits einen Hardware Abstraction Layer (HAL), über welchen
der Kern ein einheitliches Interface zu den Hardware-Funktionen, wie Timer, Interrupts,
Gerätetreiber usw. anbietet.
Außerdem stellt eCos eines dynamisches Speichermanagement zur Verfügung. Eine statische
Speicherkonfiguration des Systems ist somit nicht zwingend erforderlich. Der Speicherplatzbedarf
kann zur Laufzeit an die Anforderungen angepasst werden.
Netzwerkprotokoll-Stacks
eCos bietet bereits eine breite Auswahl an Implementierungen des TCP/IP-Stacks. So
kann zwischen einem FreeBSD, einem OpenBSD und einem lightweight TCPIP (lwIP)
Stack gewählt werden. Die Stacks enthalten neben dem TCP/IPv4 Stack auch Implementierungen
für IPv6, IPsec und verschiedene Routing Protokolle. Auf der Anwendungsschicht
sind Implementierungen für SNMP, HTTP, (T)FTP und DHCP vorhanden.
Die einzelnen Implementierungen unterscheiden sich hinsichtlich ihrer Schnittstellen bzw.
Kompatibilität zu Programmschnittstellen anderer Betriebssysteme. So ist der lwIP-Stack
46

Abschlussbericht
Trusted Sensor Node
auf Größe optimiert, jedoch vom Programmierinterface nicht kompatibel zu anderen Systemen.
So stellt der lwIP-Stack eine eigenes API bereit, dass nicht kompatible zu POSIX
ist. Bereits existierende Anwendungen müssen demzufolge für die Verwendung mit dem
Stack angepasst werden. Für den TSN wurde jedoch aufgrund der geringen Größe und
dem nicht Vorhandensein von alter Software der lwIP-Stack gewählt.
Hardwareunterstützung
Für eCos ist eine große Anzahl an Treibern für serielle Geräte, Ethernet-Controller und
Flash sowie Anbindungen an PCMCIA, USB und PCI verfügbar.
Anwendung
Treiber
API Bibliotheken
Betriebssystemkern
HAL
GDB-Unterstützung
Abbildung 3.1: eCos-Systemarchitektur
Wie in der Systemarchitektur in Abbildung 3.1 dargestellt, bildet die HAL die unterste
Schicht von eCos und stellt das Bindeglied zwischen den hardwareunabhängigen Teilen
des Systems und der Hardware selbst dar. Im Konfigurationsprozess wird dies durch die
Verwendung von Templates unterstützt. Ein Template bildet die Basis für eine Konfiguration
und beinhaltet bereits die Auswahl der verwendeten Hardwareplattform. Anschließend
können verschiedene Packages zu dieser Konfiguration hinzugefügt werden, wobei bei
den Hardware-Treibern die Auswahl bereits auf die Zielplattform abgestimmt ist.
Eine Portierung von eCos für den LEON-Prozessor (LEON2 und LEON3) inklusive Konfigurations-
und Entwicklungswerkzeuge ist bei Gaisler Aeroflex[2] verfügbar. Bei dem Konfigurationswerkzeug
handelt es sich um das Standard-Konfigurationswerkzeug von eCos.
Bei den Entwicklungswerkzeugen handelt es sich um die GNU Compiler Collection, die
als Cross-Compiler für die Zielplattform SPARC auf den Entwicklungsplattformen Linux,
MinGW und Cygwin zur Verfügung steht. Die eCos-Quellen wurden vom Main-Branch bei
der Version 1.0.8 abgespalten und können ebenfalls als Tarball bei Gaisler Aeroflex heruntergeladen
werden.
47

Abschlussbericht
Trusted Sensor Node
C-Standardbibliotheken
eCos stellt eine uITRON- und eine POSIX-API [57], [42] zur Verfügung, welche die Portierung
von Anwendungen, die diese Schnittstellen nutzen, erleichtert. Weiterhin ist eine vollständige,
multitasking-sichere ISO-C-Standardbibliothek verfügbar. Die ISO-C-Bibliothek
umfasst zahlreiche Funktionen für Dateiein- und -ausgabe, String-Manipulation und Internationalisierung.
Darüber hinaus existieren Portierungen für Bibliotheken wie zlib, mathlib und OpenSSL.
Leider ist die OpenSSL-Implementierung bei der für den TSN eingesetzten eCos-Version
nicht vollständig, sondern bietet nur eine Untermenge der aktuellen OpenSSL-Funktionalität.
Da insbesondere Implementierungen für die Krypto-Module (AES, SHA1, ECC)
des LEON2-Prozessorkerns nicht vorhanden sind, wird die OpenSSL-Komponente aktuell
nicht verwendet.
3.1.2 Hinzufügen von Komponenten
Beim Hinzufügen von neuen Funktionen in das eCos kann zwischen zwei verschiedenen
Vorgehensweisen gewählt werden. Zum einen kann man die neue Funktionalität in die
Applikation integrieren. In diesem Fall steht sie nur dieser Applikation zur Verfügung und
kann nur schwer erneut genutzt werden. Diese Variante empfiehlt sich für spezielle Funktionen,
die nur einmal genutzt werden sollen. Sie hat den Vorteil, dass hiermit ein schnelles
Prototyping möglich ist und man auf keine APIs von eCos achten muss. Die zweite Vorgehensweise
ist das Erstellen eines neuen Packages. In diesem Fall wird die Funktion in
eCos integriert und kann mittels des Konfigurationswerkszeugs in verschiedene Applikationen
integriert und innerhalb andere eCos-Module verwendet werden.
In diesem Abschnitt wird das Erstellen eines neuen Packages beschrieben. Hierbei wird
zunächst allgemein auf die notwendigen Schritte eingegangen. Im zweiten Teil wird das
Treiber API von eCos, welches die Grundlage für viele neue Funktionen bildet, erläutert.
Packages
Das Hinzufügen eines neuen Packages gliedert sich im Wesentlichen in zwei Schritte:
1. Einbinden in das Repository
2. Registrieren in der eCos-DB
Zunächst muss im Repository ein neues Verzeichnis für die Komponente angelegt werden.
Hierzu wählt man im Verzeichnis packages ein Unterverzeichnis aus, welches die
neue Komponente am besten charakterisiert. Dort legt man einen Verzeichnisbaum, wie
in Listing 3.1 beschrieben, an.
48

Abschlussbericht
Trusted Sensor Node
current
cdl
include
src
Listing 3.1: Package–Verzeichnisbaum
Das Verzeichnis current gibt die Konfiguration an, in welche das Paket integriert wird.
Hier wird im Rahmen des TSN-Projektes lediglich current verwendet. Darunter müssen
die Verzeichnisse
• cdl (enthält die Konfiguration für die eCos-DB),
• include (enthält die öffentlichen Header des Paketes) und
• src (enthält die Paketquellen)
angelegt werden. Im Verzeichnis include kann ein beliebiger Baum eingehangen werden,
der dann komplett in den build-Baum 1 von eCos kopiert wird. Die Paketquellen sollten
ohne Unterverzeichnisse unter src abgelegt werden. Das Erstellen eines Makefiles
ist nicht notwendig. Dies erfolgt automatisch beim build-Prozess. Die hierfür notwendigen
Definitionen werden im Verzeichnis cdl vorgegeben.
Im Verzeichnis cdl wird die Konfigurationsdatei für das Paket abgelegt. Sie ist zwingend
erforderlich für das Registrieren der Komponente in der eCos DB. Listing 3.2 zeigt die
Definition für einen seriellen Treiber für den LEON2 Prozessor.
cdl_package CYGPKG_IO_SERIAL_SPARC_LEON {
display "SPARC Leon2 serial device drivers"
parent
active_if
active_if
requires
include_dir
description
CYGPKG_IO_SERIAL
CYGPKG_IO_SERIAL
CYGPKG_HAL_SPARC_LEON
CYGPKG_ERROR
cyg/io
"This option enables the serial device drivers for
the SPARC Leon2."
}
compile -library=libextras.a leon_ser.c
Listing 3.2: Package–Defintion
Hier kann angegeben werden, wie der Name des Pakets ist (im Beispiel CYPPKG_IO_
SERIAL_SPARC_LEON). Dieser sollte eindeutig sein. Über das Schlüsselwort include_
dir legt man fest, wo die Header im build-Baum zu finden sind. Für eine detailierte Beschreibung
der Konfigurationsdatei sei an dieser Stelle auf [5] verwiesen.
1 Eine genauer Beschreibung des build-Baumes erfolgt im Abschnitt 3.1.3.
49

Abschlussbericht
Trusted Sensor Node
Um das neue Paket letztendlich in der eCos-DB zu registrieren, muss es in die Datei
ecos.db eingetragen werden. Listing 3.3 zeigt dies für das in Listing 3.2 eingeführte Beispiel.
package CYGPKG_IO_SERIAL_SPARC_LEON {
alias
{"SPARC Leon2 serial device drivers"
devs_serial_sparc_leon leon_serial_driver }
hardware
directory
devs/serial/sparc/leon
script
ser_sparc_leon.cdl
description "SPARC Leon2 serial device drivers"
}
Listing 3.3: Package–Registration
Hardware-Treiber, wie in unserem Beispiel, müssen einem target zugewiesen werden.
Hierfür muss der Paketname beim zugehörigen Target in die package-Liste aufgenommen
werden. Das Aktivieren des Paketes erfolgt dann zusammen mit der Auswahl der
Zielplattform.
Treiber API
eCos bietet für Treiber ein einheitliches API, so dass die Nutzung von verschiedenen Treibern
analog erfolgt. Jeder Treiber bietet die folgenden Funktionen an:
cyg_io_lookup() Diese Funktion empfängt einen Treibernamen, sucht den Namen in der
Systemtreibertabelle und liefert der Anwendung eine Referenz (Handle) auf den Treiber
zurück. Diese Referenz wird von den nachfolgend beschriebenen Methoden benötigt.
cyg_io_get_config(), cyg_io_set_config() Die API-Aufrufe ermöglichen das Lesen und
Schreiben von Konfigurationsdaten des Gerätetreibers.
cyg_io_read(), cyg_io_write() Diese API-Aufrufe dienen dazu, Daten vom Treiber zu lesen
bzw. an diesen zu übergeben.
Beim Hinzufügen eines neuen Treibers, ob als Package oder in der Applikation, müssen
diese Funktionen implementiert werden. Darüber hinaus muss der Gerätetreiber außerdem
die folgenden Elemente definieren:
• eine DEVTAB_ENTRY-Struktur und
• eine DEVIO_TABLE-Struktur.
Die DEVTAB_ENTRY-Struktur definiert den Namen und die Einsprungpunkte für die Initialisierungsroutinen
des Treibers. Listing 3.4 zeigt die Definition für einen seriellen Gerätetreiber,
der anschließend mittels cyg_io_lookup(¨/dev/ser0¨) angesprochen werden
kann.
50

Abschlussbericht
Trusted Sensor Node
DEVTAB_ENTRY(_leon_ser_io1,
"/dev/ser0",
0, // Does not depend on a lower level interface
&cyg_io_serial_devio,
_leon_ser_init,
_leon_ser_lookup, // Serial driver may need initializing
&_leon_ser_channel1
);
Listing 3.4: Device Table
Die Initialisierungsfunktion _leon_ser_init() wird bei Starten des Systems aufgerufen.
Der Treiber kann hier allgemeine Initialisierungen durchführen. Der Aufruf der Funktion
_leon_ser_lookup() erfolgt bei der Anforderung des Treibers durch die Applikation.
Weiterhin verweist die Struktur auf eine DEVIO_TABLE-Struktur, die die Einsprungpunkte
der Treiberfunktionen enthält. Für einen seriellen Treiber sind dies zum Beispiel die Funktionen
aus dem Listing 3.5.
DEVIO_TABLE(cyg_io_serial_devio,
serial_write,
serial_read,
serial_select,
serial_get_config,
serial_set_config
);
Listing 3.5: Device IO Table
Die Funktionen serial_write() und serial_read() werden zur Datenübertragung
an den bzw. vom Treiber verwendet. Mittels der Funktion serial_select() kann auf ein
Ereignis, z.B. das Eintreffen von Daten, gewartet werden. Das Konfigurieren des Treibers
erfolgt über die Funktionen serial_get_config() und serial_set_config().
3.1.3 build-Prozess
Das Erstellen einer eCos Applikation unterteilt sich in zwei Schritte. Im ersten Schritt muss
eCos konfiguriert und übersetzt werden. Als Ergebnis wird eine Bibliothek erstellt, die im
zweiten Schritt in die Zielapplikation eingebunden wird. Dieser Abschnitt enthält eine Beschreibung
dieser Schritte, zuvor wird kurz auf die notwendige Toolchain eingegangen.
Toolchain
Der LEON2-Prozessor basiert auf der SPARC-Architektur, so dass die GnuTools für SPARC
verwendet werden können. Beim Erstellen der Toolchain muss man zwischen den Entwicklungsplattformen
unterscheiden. Während für Windows die Tools nahezu vollständig von
[2] heruntergeladen werden können, müssen sie für Linux selbst erstellt werden.
51

Abschlussbericht
Trusted Sensor Node
Microsoft Windows Entwicklung Für die Entwicklung unter Microsoft Windows 2 muss
die Cygwin Umgebung von RedHat [11] verwenden werden. Hierzu muss zunächst Cygwin
inklusive der Entwicklungswerkzeuge (gcc, make, autoconf und automake) installiert werden.
Anschließend kann die Toolchain entpackt werden, dies kann mittels des folgenden
Kommandos erfolgen:
cd /usr/local
tar xjf /tmp/sparc-rtems-4.6.5-gcc-3.2.3-1.0.16-cygwin.tar.bz2
Hierbei wird davon ausgegangen, dass das Paket zuvor in dem Verzeichnis c:\cygwin\
tmp abgelegt wurde. Die Installation kann auch in ein anderes Verzeichnis erfolgen, jedoch
gehen die folgenden Beschreibungen davon aus, dass sich der Compiler unter /usr/local
befindet.
Nach der Installation der Compiler-Suite muss das eCos Konfigurationstool configtool-
-2.11-setup.exe installiert werden. Dieses kann ebenfalls unter [2] heruntergeladen
werden. Das Tool wird als natives Windows-Programm angeboten, welches direkt installiert
und anschließend über das Startmenü ausgeführt werden kann.
Für das Übersetzen von eCos auf der Kommandozeile, ohne Nutzung des Configtools,
wird ein Makefiles für cygwin-Umgebung bereitgestellt. Es befindet sich im Verzeichnis
oberhalb der ecos-Quellen. Diese Makefile nutzt für den Aufbau der build-Trees und zum
Überprüfen der Konfigurationsdatei das Kommandozeilentool ecosconfig. Dieses kann
nicht direkt heruntergeladen, sondern muss manuell erstellt werden. Hierzu lädt man von
eCosCentric [16] einen Snapshot ecos-trunk-full.tar.bz2 des ecos-CVS herunter.
Anschließend ist dieses wie folgt zu übersetzen:
mkdir /tmp/src
cd /tmp/src
tar xjf /tmp/ecos-trunk-full.tar.bz2
cd ..
mkdir build
cd build
../src/ecos/configure
make
cp host/tools/configtool/standalone/common/ecosconfig.exe \
/usr/local/bin/
Das Programm ecosconfig.exe wird von den IHP-Makefiles ohne Pfadangabe aufgerufen,
so dass darauf zu achten ist, dass /usr/local/bin im Suchpfad enthalten ist.
Linux Entwicklung Unter Linux muss zunächst die Toolchain erstellt werden. Hier zu ist
unter [55] eine Anleitung zu finden. Als TARGET sollte sparc-elf verwendet werden.
2 Die Beschreibungen zur Entwicklungsumgebung wurden ausschließlich unter Microsoft Windows XP Professional
(Service Pack 3) getestet.
52

Abschlussbericht
Trusted Sensor Node
Nach der Installation der Toolchain muss das eCos Konfigurationstool installiert werden.
Dieses kann wiederum bei Gaisler Aeroflex (ecosconfig.zip) heruntergeladen werden.
Das zip-Archiv enthält sowohl die GUI- als auch die Kommandozeilenversion des Programmes.
Für die GUI-Version ist die Bibliothek wxGTK-2.4.2 notwendig. Auf aktuellen
Distributionen, z.B. debian lenny, ist meist eine neuere Version der Bibliothek installiert.
Da das Programm jedoch direkt auf die Version 2.4.2 der Bibliothek verweist, empfiehlt
es sich diese mit der korrekten Version aus den Quellen zu übersetzen und zusätzlich zu
installieren.
eCos konfigurieren und übersetzen
In diesem Abschnitt wird das Konfigurieren und das Übersetzen von eCos beschrieben.
Hierbei wird davon ausgegangen, dass die Toolchain unter /usr/local installiert ist und
die eCos-Quellen vom IHP bezogen wurden. Das Wurzelverzeichnis der Quellen sollte die
folgende Struktur aufweisen:
apps Verzeichnis mit den Quellen der eCos Applikationen.
cfg Verzeichnis mit den Konfigurationsdateien.
ecos-rep-1.0.8 Verzeichnis mit den Quellen des eCos Betriebssystems.
Makefile Globale Steuerungsdatei zum Erstellen von eCos.
Im Verzeichnis cfg sollte eine Datei mit dem Namen tsn.ecc vorhanden sein. Hierbei
handelt es sich um die Konfigurationsdatei für eCos. Um die Datei zu bearbeiten, muss
das Programm configtool gestartet werden. Beim Start des Programms muss als Repository
das Verzeichnis ecos-rep-1.0.8 angegeben werden. Anschließend kann über
den Menüpunkt Datei/Öffnen die Konfiguration geladen werden. Es ist darauf zu achten,
dass die Datei nach den Änderungen wieder unter cfg/tsn.ecc gespeichert werden
muss.
Anschließend kann eCos durch den Aufruf make übersetzt werden. Wurde die Konfiguration
unter einem anderen Namen gespeichert, kann die neue Konfiguration mittels make
TARGET= verwendet werden. Nach jeder Änderung an der Konfiguration
ist eCos komplett neu zu übersetzen. Hierzu kann mittels make distclean das Kompilat
gelöscht werden.
Wurde die Toolchain in einem anderen Verzeichnis installiert, muss die Option Configuration/Global
build options/Global command prefix entsprechend konfiguriert
werden.
Nach dem Übersetzen von eCos sollten die Verzeichnisse tsn_build und tsn_install
vorhanden sein. Das Verzeichnis tsn_install enthält die Header und die Bibliotheken
zum Erstellen von eCos Applikationen. Beim Verzeichnis tsn_build handelt es sich um
den build-Tree von eCos.
53

Abschlussbericht
Trusted Sensor Node
Applikation erstellen
In der, vom IHP erstellten, Verzeichnisstruktur werden Applikationen im Unterverzeichnis
apps abgelegt. Hier existiert für jede Applikation ein separates Verzeichnis mit den
Quellen und einem Makefile. Darüber hinaus wurde hier das Verzeichnis lib für Applikationsbibliotheken
angelegt. Im Folgenden wird das Erstellen und Übersetzen einer
eCos-Applikation für den TSN erläutert. Dies umfasst das Anpassen der Makefiles, die
Vorstellung eines Skeleton 3 für eine einfache Applikation und das Erstellen einer Applikationsbibliothek.
Basiskonfiguration Die Basiskonfiguration für die build-Umgebung wird in die Datei
defs.mk eingetragen. Hierbei handelt es sich um ein Include für die Makefiles der Applikationen.
Die Variablen haben hierbei die folgende Bedeutung:
VPATH legt den Pfad zur Toolchain fest. Die Variable muss auf das Verzeichnis mit den
Binaries, in der Regel bin, verweisen.
PREFIX gibt den Prefix der Binaries an. Hier sollte der gleiche Prefix, wie für eCos verwendet
werden. Unter Windows ist dies sparc-rtems- und unter Linux sparc-elf-.
VERSION gibt den Namen der zu verwendenden Konfiguration an.
Die Datei build.sh aus dem Verzeichnis apps muss nicht angepasst werden. Sie wird
von den Makefiles zur Erstellung der build-Nummer 4 verwendet.
Skeleton einer Applikationen Das Erstellen einer Applikation erfolgt durch den Aufruf
von make im Applikationsverzeichnis. Anschließend sollte eine Datei mit dem gleichen
Namen wie des Verzeichnisses vorhanden sein. Die Datei kann dann mittels grmon 5 auf
die Zielhardware übertragen werden.
Um eine neue Applikation zu erstellen, legt man unter apps ein neues Verzeichnis an und
kopiert ein Makefile aus einem der anderen Applikationsverzeichnisse hinein. In dieser
Datei sind anschließend die folgenden Variablen anzupassen:
TARGET legt den Namen der Applikation fest, sollte identisch mit dem Verzeichnisnamen
sein.
OBJS enthält eine Auflistung aller Objektdateien des Programms.
3 Grundgerüst, dass durch den Anwendungsprogrammierer aufgefüllt wird
4 Bei der build-Nummer handelt es sich um die globale Variable build_ver die über das Include
build.h eingebunden werden kann. Sie wird bei jedem Aufruf von make inkrementiert und mittels make
distclean zurückgesetzt.
5 Bei grmon handelt es sich um den General Debugging Monitor von Gaisler Aeroflex. Das Programm wird
kommerziell über die Homepage von Gaisler (http:\\www.gaisler.com) mit einem Hardware-Dongle vertrieben.
54

Abschlussbericht
Trusted Sensor Node
DEFINES enthält eine Auflistung von Defines, die dem Compiler übergeben werden sollen.
Die Angabe muss ohne das Prefix -D erfolgen, dieses wird automatisch hinzugefügt.
ULIBS enthält eine Liste von Bibliotheken, die mit in das Programm eingebunden werden
sollen. Hierbei sind nicht die eCos Bibliotheken anzugeben.
Im eCos des TSN wird keine main() Funktion unterstützt. Eine Applikation beginnt immer
mit der Funktion cyg_user_start(). Listing 3.6 zeigt das Grundgerüst für eine TSN
eCos Applikation.
#include
#include
#include "build.h"
static cyg_handle_t _simple_thread;
static cyg_thread _thread_s;
static char _stack[4096];
static void _app_thread(cyg_addrword_t data)
{
diag_printf("\r\neCos Application (build %d)\r\n",
(unsigned int) data);
for (;;) {
/* waiting forever */
}
}
return;
void cyg_user_start(void)
{
(9, _app_thread, (cyg_addrword_t) build_ver, "app",
(void *) &_stack[0], 4096, &_simple_thread,
&_thread_s);
}
cyg_thread_resume(_simple_thread);
Listing 3.6: Application Skeleton
Die Applikation des Skeleton startet einen neuen Thread mit der Priorität 9 und der Funktion
_app_thread(). Als Argument wird ihr die externe Variable build_ver, die von dem
Skript build.sh erzeugt wird, übergeben. Die Funktion gibt eine kurze Meldung auf der
Debug-Konsole des LEON2 Prozessor aus und wartet anschließend in einer Endlosscheife.
Bibliothek erstellen Erstellt man Funktionen, die in mehreren Applikationen genutzt
werden sollen, kann es zweckmäßig sein, diese in eine Bibliothek auszulagern. Hierzu
55

Abschlussbericht
Trusted Sensor Node
erstellt man unter apps ein Verzeichnis mit dem Namen der Bibliothek und darin die Verzeichnisse:
include enthält die Header der Bibliothek und
lib enthält die Quelltextdateien der Bibliothek.
In das Verzeichnis libs wird ein Makefile aus einer bereits vorhandenen Bibliothek
kopiert. Hier müssen, wie bei einer Applikation, die Variablen TARGET und OBJS angepasst
werden. Es ist darauf zu achten, dass die Bibliothek keine Funktion mit dem Namen
cyg_user_start() enthält.
56

4 Softwarearchitektur des TSN
Nach der Einführung in eCos wird in diesem Abschnitt die Softwarearchitektur des TSN im
Detail vorgestellt. Als Basis für das System wird eCos mit einer minimalen Konfiguration
gewählt. Darauf aufbauend wurden alle Services und Treiber hinzugefügt, die für den TSN
benötigt werden. Abbildung 4.1 zeigt die Architektur im Überblick.
Management Thread
Application
eCos
Driver/Services
Sensor
Thread
Sensor API
Sensor
Protocol
Bridge
Thread
LwIP
PPP
KeyExchange
Thread
CryptAPI
GPIO drv SPI drv UART drv
MMIO drv
TSN
Hardware
GPIO SPI UART
ECC
SHA1
AES
ext.
Hardware
PIR
Sensor
Accelerator
Sensor
802.15.4
Radio
Bluetooth
Radio
Abbildung 4.1: Softwarearchitektur des TSN
Die Module des TSN lassen sich in zwei Funktionsgruppen unterteilen. Dies ist zum einen
die Sensorik des Knotens. Hierzu gehört der Sensor-Thread und das SensorAPI inklusive
der zugehörigen Treiber. Der zweite Teil umfasst das Sensor-Protokoll, den lwIP-Stack,
PPP und das CryptAPI mit den zugehörigen Threads. Diese Funktionsgruppe ist für die
Weiterleitung der Sensordaten aus dem 802.15.4 in ein TCP/IP-Netzwerk verantwortlich.
Hierbei werden die Daten mittels des CryptAPI verschlüsselt. Die Schlüsselaushandlung
übernimmt der KeyExchange-Thread. Für die Steuerung der Threads ist der Management-
Thread verantwortlich.
Bis auf den lwIP-Stack und PPP, welche bereits Bestandteil von eCos sind, wurden alle
Komponenten der Architektur im Rahmen des TSN-Projektes implementiert. Hierbei wurden
Frameworks und APIs erstellt, die entsprechend den letztendlichen Anforderungen an
den TSN im Detail implementiert werden müssen.

Abschlussbericht
Trusted Sensor Node
4.1 Gerätetreiber
Bei der Beschreibung von eCos im Kapitel 3.1 wurde bereits erwähnt, dass von Gaisler
Aeroflex ein Portierung für den LEON2Prozessor erstellt wurde. Diese Portierung umfasst
im Wesentlichen den HAL für den Prozessor. Im Rahmen des TSN-Projektes war es notwendig,
zusätzliche Treiber für die Peripheriegeräte zu erstellen. Hierzu gehören Treiber
für die seriellen Schnittstellen UART und SPI, für GPIO und für das memory-like Interface
der kryptografischen Komponenten.
Dieser Abschnitt enthält eine Beschreibung der im Rahmen des TSN-Projektes zu eCos
hinzugefügten Treiber. eCos unterstützt eine Vielzahl zusätzlicher Peripheriegeräte für die
bereits Treiber existieren. Eine Beschreibung dieser Treiber ist nicht Bestandteil dieses
Abschnittes, hier sei auf die Dokumentation von eCos [15] verwiesen.
4.1.1 UART Treiber
Der LEON2-Prozessor verfügt, wie in Abbildung 2.1 dargestellt, über zwei UART-Schnittstellen.
An eine dieser Schnittstellen wird das Bluetooth-Modul angeschlossen. Eine Erläuterung
hierzu erfolgt im Abschnitt 4.3.3. Die Schnittstelle wird durch den PPP Netzwerk-
Layer für die Übertragung der Netzwerkpakete an die Basisstation verwendet.
In der Portierung von Gaisler Aeroflex wurde die UART1 als Diagnoseschnittstelle genutzt.
Diese Schnittstelle kann über /dev/haldiag geöffnet und verwendet werden. Allerdings
ist die Hardware nur eingeschränkt nutzbar, da Lesezugriffe das System blockieren und
nicht beliebige Zeichen übertragen werden können. Aus diesem Grund kann der vorhandene
Treiber nicht genutzt werden und wird daher durch einen neuen Treiber ersetzt, welcher
das in Abschnitt 3.1.2 beschriebene Interface in vollem Umfang unterstützt.
Die Implementierung des Treibers ist in den Quellen von eCos im Verzeichnis devs/serial/sparc/leon/
zu finden. Das Package ist Bestandteil des LEON2-Hardware und
kann nur zusammen mit dieser konfiguriert werden. Die Konfiguration des Treibers ist im
eCos Configuration Tool unter
I/O sub-system
Serial device drivers
SPARC Leon2 serial device drivers
SPARC Leon2 serial CON1 port driver
SPARC Leon2 serial CON2 port driver
zu finden. Jede UART-Schnittstelle kann im Konfigurationswerkzeug separat aktiviert und
deaktiviert werden. Darüber hinaus lässt sich festlegen, über welchen Verzeichniseintrag
das Gerät angesprochen werden kann. Zusätzlich existiert eine Option für die Größe eines
Zwischenpuffers. Dieser Puffer wird für den Interrupt-basierten Betrieb der Schnittstelle
benötigt. Im Interrupt-Handler der Schnittstelle werden, bei Vorhandensein des Puffers, die
58

Abschlussbericht
Trusted Sensor Node
Daten vom Gerätespeicher in den Puffer kopiert. Die Anwendung liest die Daten in diesem
Fall nur noch aus dem Puffer und nicht mehr direkt aus dem Gerätespeicher. Wenn der
Puffer voll ist und weiterhin Daten eintreffen, werden diese verworfen. Die Verwendung
eines Puffers hat den Vorteil, dass hierin wesentlich mehr Daten zwischengespeichert
werden können als im Gerätespeicher und somit der Datenverlust reduziert werden kann.
Über die Funktion serial_set_config() können die Parameter der Schnittstelle verändert
werden. Hierbei unterstützt das API von eCos jedoch mehr Funktionen als die Hardware
des LEON2. So können hierüber die folgenden Parameter verändert werden.
• Baudrate
• Parität (None, Even und Odd)
• Flowcontrol
Die Datenbreite (8 Bit) und die Anzahl der Stoppbits (1) ist nicht frei konfigurierbar. Eine
andere Konfiguration dieser Parameter lässt die Hardware des LEON2 nicht zu.
4.1.2 SPI Treiber
Neben den, im Abschnitt 4.1.1 beschriebenen UART-Schnittstellen, verfügt der LEON2-
Prozessor über eine SPI-Schnittstelle zum Anschluss von maximal drei Peripheriegeräten.
Die Schnittstelle wird, wie in Abbildung 2.1 dargestellt, für die 802.15.4 Module und für den
Beschleunigungssensor verwendet.
Die von Gaisler Research zur Verfügung gestellten eCos Quellen beinhalten keinen SPI-
Treiber. Die Implementierung musste vollständig im Rahmen des TSN-Projektes erfolgen.
Als Basis für den Treiber wurde der generische IO-Treiber von eCos verwendet. Dieser
stellt Funktionen zum Lesen und zum Schreiben von Daten und zum Konfigurieren der
Schnittstelle bereit. Der Zugriff auf das Gerät erfolgt wiederum über ein zeichenorientiertes
Gerät, welches mittels der Funktion cyg_io_lookup() angefordert werden kann.
Anschließend kann die Applikation mit den Lese- und Schreibfunktionen Daten senden
und empfangen. Das Einstellen der Schnittstellenparameter erfolgt mittels der Funktion
cyg_io_set_config().
Der SPI-Treiber ist im Verzeichnis devs/spi/sparc/leon/ in die eCos Quellen integriert.
Die Konfiguration ist im Konfigurationswerkzeug unter den folgenden Einträgen zu
finden:
I/O sub-system
SPI support
Sparc LEON2 SPI drivers
Enable support for SPI
Enable Chip Select 0
Device name for Sparc LEON2 SPI CS0
Enable Chip Select 1
Device name for Sparc LEON2 SPI CS1
59

Abschlussbericht
Trusted Sensor Node
Enable Chip Select 2
Device name for Sparc LEON2 SPI CS2
Das SPI-Modul unterstützt, wie in Abbildung 4.2 dargestellt, bis zu drei Slave-Geräte, die
über das Chip Select Signal (CSn) adressiert werden. Der LEON2-Prozessor agiert immer
als Master und legt fest, zu welchem Slave die Daten übertragen werden sollen. Ein SPI-
Slave kann keinen Datentransfer initiieren, er kann nur auf Anforderungen des Masters
reagieren 1 . Über den Eintrag Enable Chip Select n des Konfigurationswerkzeuges kann
der Nutzer festlegen, ob ein Slave für diese Select Leitung existiert. Beim TSN werden nur
CS0 und CS1 verwendet.
Die Datenübertragung erfolgt über die Leitungen MISO (Master In Slave Out) und MOSI
(Master Out Slave In). Mit jedem Takt auf der Clock Leitung CLK wird ein Bit vom Master
an den Slave und ein Bit vom Slave an den Master übertragen.
CLK
MISO
MOSI
CS0
SPI
Slave 0
SPI
Master
CLK
MISO
MOSI
CS0
CS1
CS2
CLK
MISO
MOSI
CS1
SPI
Slave 1
CLK
MISO
MOSI
CS2
SPI
Slave 2
Abbildung 4.2: SPI Chip Select
4.1.3 MMIO Treiber
Wie in [27] beschrieben, werden die kryptografischen Module des LEON2-Prozessors über
ein Memory Mapped Input Output (MMIO) Interface eingebunden. Zugriffe auf die Module
werden in Speicherschreib- und Speicherleseoperationen gekapselt. Die verschiedenen
Einheiten/Register der Module sind jeweils an spezifischen Adressen im IO-Bereich des
LEON2-Prozessors 2 eingeblendet.
1 Zur Signalisierung vom SPI-Slave zum Master wird ein Pin des TSN als IRQ verwendet. Der Master kann
nach dem Empfang des Interrupt den Status und die Nachricht beim Slave erfragen.
2 Der virtuelle Speicher des LEON2 wird in mehrere Bereiche unterteilt, die jeweils eine andere Hardware-
Einheit adressieren. Der IO-Bereich beginnt an der Adresse 0x20000000 und der physische RAM an
Adresse 0x40000000.
60

Abschlussbericht
Trusted Sensor Node
Der Zugriff auf diese Bereiche erfolgt über den MMIO Treiber. Die Implementierung des
Treibers befindet sich in dem Verzeichnis io/mmio und kann über die Option Memory
mapped I/O device drivers konfiguriert werden. Da der Treiber zunächst nur einen strukturierten
Zugriff auf einen beliebigen Speicherbereich bereitstellt, ist dieser nicht an die
LEON2-Hardware und damit an das zugehörige Template gebunden.
Eine Instanz des Treibers kann über /dev/memio/ angefordert werden.
Ein direkter Zugriff auf /dev/memio ist nicht möglich, es ist immer die zusätzliche
Angabe eines Instanznamens notwendig. Nach dem Anfordern der Instanz kann der Bereich
mit den in Tabelle 4.1 beschriebenen Kommandos konfiguriert werden. Anschließend
können mittels cyg_io_read() und cyg_io_write() Daten in Bereich geschrieben
oder von dort gelesen werden.
Der MMIO-Treiber bildet die Basis für die Zugriffe auf die kryptografischen Module des
LEON2-Prozessors. Somit sind keine Treiber für die einzelnen Module notwendig. Das
CryptAPI aus Abschnitt 4.2.1 greift über den MMIO Treiber direkt auf die kryptografischen
Module der CPU zu.
Kommando
CYG_IO_CONFIG_MEMIO_ADRBASE
CYG_IO_CONFIG_MEMIO_LENGTH
CYG_IO_CONFIG_MEMIO_ENABLE_CACHE
CYG_IO_CONFIG_MEMIO_CONTEXT
CYG_IO_CONFIG_MEMIO_GET_ALL_INSTANCES
Beschreibung
Setzt die Basisadresse des Speicherbereichs
Legt die Größe des
Speicherbereichs fest
Aktiviert das Caching der Daten
Erlaubt das Setzen der Option
Address, Length und Cache mit
einem Aufruf
Gibt ein Array auf alle im Treiber
registrierten Bereiche zurück
Tabelle 4.1: Konfigurationskommandos des MMIO Treibers
4.1.4 General Purpose Input/Output (GPIO) Treiber
Der LEON2 verfügt über 32 I/O Pins, welche in 16-Low und 16-High-Pins aufgeteilt werden.
Die oberen 16 Pins (High-Pin) sind nur nutzbar, wenn der Speicherzugriff im 8-bit
oder im 16-bit Modus erfolgt und der SD-Ram Controller nicht genutzt wird. Beim Leon-2
des TSN sind die oberen 16 Pins für die Chip-interne Nutzung vorgesehen, so dass sie
nicht aus dem Chip-Package geführt sind. In eCos können aus diesem Grund lediglich
die unteren 16 Pins über das GPIO-Treiber Interface angesprochen werden. Die meisten
der verfügbaren GPIOs werden für die UART-Schnittstellen des TSN verwendet und wäre
nur verfügbar, wenn man auf diese Schnittstellen verzichtet [3]. Die freien GPIOs werden
für die Anbindung des passiven Infrarotsensors und zum Steuern des Bluetooth-Moduls
verwendet.
Um eine einheitliche Nutzung der Schnittstelle zu gewährleisten, werden alle Pins durch
einen Treiber verwaltet. Der Treiber ist Bestandteil des eCos-Kerns und kann über die Op-
61

Abschlussbericht
Trusted Sensor Node
tion ”Enable gpio support” im Konfigurationswerkzeug aktiviert werden. Der Treiber bietet
Funktionen zum Konfigurieren der GPIOs, zum Auslesen und des Setzen des Levels und
zum Aktiviere sowie Deaktivieren eines Interrupts an.
Mittels der Funktion hal_gpio_set_direc() kann die Richtung des GPIOs festgelegt
werden. Ein GPIO kann als Ausgang oder als Eingang genutzt werden. Ist der GPIO als
Eingang definiert, kann mittels der Funktion hal_gpio_get() das aktuelle Level des Pins
erfragt werden. Das Setzen des Levels erfolgt mittels hal_gpio_set(). Das Auslesen
und Setzen des GPIO-Levels ist jederzeit möglich.
Der LEON2 Prozessor unterstützt bis zu vier Interrupt-Vektoren für seine 16 GPIO-Pins.
Für das Konfigurieren des Interrupt-Handlers wird Funktion hal_gpio_cfg_irq() bereitgestellt.
Die Funktion wählt einen freien Interrupt-Vektor aus und registiert die übergebene
callback-Funktion. Sind bereits alle Interrupt-Vektoren belegt, wird ein Fehler zurückgegeben.
Beim Konfigurieren des Interrupts kann zusätzlich festgelegt werden, ob der
Interrupt bei einem Flankenwechsel (edge-triggered) oder bei einem bestimmten Level
(level-triggered) auslösen soll. Über einen weiteren Parameter wird das Level festgelegt.
Bei einem edge-triggered Interrupt legt das Level fest, ob dieser bei einer fallenden (lowlevel)
oder steigenden Flanke (high-level) ausgelösen soll.
Das Aktivieren des Interrupts erfolgt mittels der Funktion hal_gpio_enable_gpio().
Nach der Ausführung dieser Funktion, wird der Interrupt-Hander aufgerufen, wenn ein der
Konfiguration entsprechender Interrupt aufgetreten ist. Das Deaktivieren des Interrupt erfolgt
mittels der Funktion hal_gpio_disable_gpio(). Zum Reaktivieren des Interrupts
muss dieser nicht erneut konfiguriert werden. Stattdessen ist es ausreichend, wenn die
Funktion hal_gpio_enable_gpio() aufgerufen wird.
4.2 Services
Neben den im Abschnitt 4.1 eingeführten Treibern, wurde eCos um zwei zusätzliche Services
erweitert. Die Services können von beliebigen eCos Applikationen verwendet werden.
Hierzu gehört das CryptAPI, über welches die Hardware-beschleunigten kryptografischen
Funktionen des LEON2-Prozessor angeboten werden, und das SensorAPI, welches
eine einheitliche Schnittstelle für die Sensorik des TSN bietet.
Die beiden Services können über die Packages CryptAPI und SensorAPI ausgewählt werden.
Da sie von Hardwarefunktionen des TSN abhängig sind, sind sie an die LEON2-
Hardware gebunden. In der Konfiguration des TSN tsn.ecc sind beide Packages aktiviert.
4.2.1 CryptAPI
Das CryptAPI stellt eine einheitliche Schnittstelle auf die kryptografischen Module des LE-
ON2-Prozessors bereit. Die Implementierung ist jedoch nicht auf die Hardware-Funktionen
62

Abschlussbericht
Trusted Sensor Node
beschränkt. Das API wurde so definiert, dass zur Laufzeit zusätzliche Algorithmen hinzugefügt
und wieder entfernt werden können. Im Rahmen des TSN-Projektes wurden die
folgenden Algorithmen in das API integriert:
• AES, Software-Implementierung des AES,
• AES_HW, Treiber für die AES-Einheit des LEON2,
• SHA1, Treiber für die SHA1-Einheit des LEON2,
• PRNG, Pseudo-Zufallszahlen Generator auf Basis der SHA1-Einheit des LEON2,
• ECC, Treiber für die ECC-Einheit des LEON2,
• ECDSA, Implementierung von ECDSA nach ANSI X9.62 auf Basis der SHA1- und
der ECC-Einheit des LEON2 und
• EL-Gamal, Implementierung von EL-Gamal nach ANSI X9.63 auf Basis der ECC-
Einheit des LEON2.
Die Implementierung des API befindet sich in dem Verzeichnis services/crypt_api
und ist im Konfigurationswerkzeug direkt unter dem Punkt CryptAPI zu finden. Für den
AES Algorithmus wurden die beiden Modi Electronic Code Book (ECB) und Cipher Block
Chaining (CBC) implementiert, die separat in dem Konfigurationswerkzeug ausgewählt
werden können.
Registrieren von Crypto-Algorithmen
Einleitend wurde erwähnt, dass zur Laufzeit des TSN Algorithmen hinzugefügt und entfernt
werden können. Hierfür stellt das API die beiden Funktionen crypt_api_register()
und crypt_api_unregister() zur Verfügung. Beim Anmelden eines Algorithmus wird
der Funktion ein Objekt vom Type crypt_api_alg_t übergeben. Dieses enthält die Parameter
und Verweise auf die Implementierung des Algorithmus. Zu den Parametern gehört
dessen Name, die Blockgröße und die Schlüsselgröße. Der Name muss eindeutig
sein, da über diesen später eine Instanz des Algorithmus angefordert wird.
Ein Algorithmus kann erst dann aus dem System entfernt werden, wenn keine weitere
Instanz geöffnet ist. Ein genauere Erläuterung hierzu erfolgt im nächsten Abschnitt.
CryptAPI-Verwendung
Die Algorithmen des CryptAPI werden über ein einheitliches Interface aufgerufen, so dass
in einer Applikation Algorithmen des gleichen Typs (Verschlüsselung, Hash oder Signatur)
leicht gegeneinander ausgetauscht werden können.
Für der Nutzung des Algorithmus muss mittels der Funktion crypt_api_lookup() die
ID des Algorithmus ermittelt werden. Über diese ID kann mittels crypt_api_open() eine
Instanz angefordert werden. Wenn eine Applikation eine Instanz angefordert hat, kann der
Algorithmus nicht mehr entfernt werden, bis diese Instanz mittels crypt_api_close()
freigegeben wird. Die Funktion crypt_api_open() gibt die Adresse eines Objektes vom
63

Abschlussbericht
Trusted Sensor Node
Typ crypt_api_ctx_t zurück. In diesem Objekt wird der aktuelle Zustand gespeichert.
Damit ist es möglich, mehrere Instanzen eines Algorithmus zu öffnen und gleichzeitig zu
nutzen. Die Funktion erwartet als Parameter den zu verwendenden Schlüssel. Um den
Schlüssel zu tauschen ohne die Instanz freizugeben, kann die Funktion crypt_api_-
reopen() verwendet werden. Sie setzt außerdem den internen Zustand des Algorithmus 3
zurück.
Die Ausführung der Crypto-Funktion wird mittels der Funktion crypt_api_transform()
initiiert. Sie erwartet einen Crypto-Datencontainer für die Input- und die Output-Daten sowie
für den Initialisierungsvektor. Abhängig vom Typ des Algorithmus bestimmt sich die
Größe des jeweiligen Datencontainers bzw. ob dieser angegeben werden muss.
Verwaltung von Crypto-Datencontainern
Die Funktionen des CryptAPI erwarten die Daten in Form eines Crypto-Datencontainers,
welcher durch die Struktur crypt_api_data_t beschrieben wird. Die Struktur enthält
ein Element len, das die Größe des Bereiches angibt, und ein Element data, welches
auf die Daten des Objektes verweist.
Für das Anfordern und das Freigeben eines Crypto-Datencontainers werden die Funktionen
crypt_api_alloc() und crypt_api_free() bereitgestellt.
4.2.2 SensorAPI
Der TSN verfügt mit dem Beschleunigungs- und dem passiven Infrarotsensor über zwei
Sensorquellen, die eine Überwachung des eigenen Zustands gewährleisten sollen. Die
Anbindung erfolgt, je nach Sensor, über SPI (Beschleunigungssensor) und über GPIO
(PIR-Sensor). Im Rahmen des Projektes wurde für beide Sensoren Treiber entwickelt,
die eine einfache Programmierschnittstelle für die Sensorik bereitstellt. Die Nutzung der
Schnittstelle ist exemplarisch im Sensorik Thread, eine Beschreibung hierzu erfolgt im Abschnitt
4.4.3, umgesetzt.
4.3 Protokollstapel
Dieser Abschnitt beschreibt die Protokollstapel des TSN. Der TSN agiert als Gateway zwischen
zwei verschiedenen Netzwerken mit separaten Protokollstapeln und kommuniziert
damit.
1. mit der Basisstation und
3 Bei Hash-Algorithmen ist ein crypt_api_reopen() nach jeder Signaturberechnung notwendig.
64

Abschlussbericht
Trusted Sensor Node
2. mit den Sensorknoten.
In Abbildung 4.3 sind die Protokollstapel des TSN dargestellt. Entsprechend der beiden
Endpunkte sind zwei Stacks, die über den Bridge Thread mit einander verbunden sind,
vorhanden. Das 802.15.4 Module stellt die Verbindung zu den Sensorknoten und das
802.15.1 Modul die Verbindung zur Basisstation her.
Bridge Thread
PPP
Thread
BluezCfg
Thread
Sensor
Protocol
SPI
802.15.4
Module
lwIP
PPP
UART
802.15.1
Module
Abbildung 4.3: Die Protokollstapel des TSN
Für die Kommunikation des TSN mit der Basisstation wurde gefordert, dass TCP als zuverlässiges
Transportprotokoll verwendet werden soll. Hieraus ergibt sich die Verwendung von
IP für die Umsetzung der Netzwerkschicht. In eCos existiert mit lwIP eine kleine und leichtgewichtige
TCP/IP Implementierung, die im Rahmen des Projektes verwendet wird. Für
die Datenübertragung gemäß 802.15.1 (Bluetooth) werden Bluebear-Module von Lesswire
verwendet, die direkt über eine serielle Schnittstelle angesprochen werden können
und damit den Bluetooth-Stack vollständig kapseln. Als Verbindungsschicht zwischen dem
Bluetooth Module und dem TCP/IP-Stack wird PPP verwendet.
Für die Kommunikation zwischen dem TSN und den Sensorknoten wurde die zum Einsatz
kommende Funktechnik, hier IEEE 802.15.4, verbindlich festgelegt. Als Hardware wurden
Module von Jennic ausgewählt, um eine möglichst einfache Kommunikation zu den Knoten
zu ermöglichen. Die Module werden über SPI in eCos eingebunden, hierfür wird der
in Abschnitt 4.1.2 beschriebene Treiber verwendet. Als Transport- und Netzwerkprotokoll
wurde flooding iSense definiert.
4.3.1 lightweight IP Stack
Als TCP/IP Stack Implementierung kommt, der bereits angesprochene, lwIP-Stack zum
Einsatz. Der Stack ist sehr klein und lässt sich auf wenige Protokoll des TCP/IP-Stacks
begrenzen. Der Stack unterstützt die folgenden Protokolle:
• IPv4 ( Internet Protokoll der Version 4),
65

Abschlussbericht
Trusted Sensor Node
• TCP (Transmission Control Protocol),
• UDP (User Datagram Protocol),
• ARP (Address Resolution Protocol) und
• ICMP (Internet Control Message Protocol).
Die Protokolle DHCP und SLIP sind zwar Bestandteil der Implementierung werden jedoch
im TSN nicht verwendet. Ebenso wird auf die Unterstützung von Ethernetgeräten verzichtet.
4.3.2 Point to Point Protocol (PPP)
Das PPP ist ebenfalls Bestandteil des lwIP-Package. Es wird benötigt, um die Datenpakete
aus dem Netzwerkstack über die serielle Schnittstelle des Bluetooth Moduls zu übertragen.
Der Einsatz von PPP ermöglicht eine standardisiert Anbindung an externe Systeme.
Das PPP ist ein Schicht 2 Protokoll des OSI-Models. Auf der Schicht 1 werden vom PPP
zeichenorientierte Geräte verwendet. Das lwIP-Modul nutzt hierfür eine serielle Schnittstelle
von eCos. Die Schnittstelle muss bereits beim Konfigurieren des Systems festgelegt
werden. Beim Initialisieren des PPP-Moduls wird die Schnittstelle dann automatisch mittels
sio_open() geöffnet. Eine Rekonfigurierung zur Laufzeit ist nicht vorgesehen.
Mittels PPP kann zusätzlich eine Authentifizierung in den TSN integriert werden. Bei jedem
Verbindungsaufbau fordert der PPP-Server vom Client eine gültige Nutzernamen-
Passwort-Kombination an. Darüber hinaus enthält PPP bereits Mechanismen für Keep Alive
(LCP Echo) und zum Konfigurieren der Netzwerkparameter.
4.3.3 Bluetooth Stack
Die Kommunikation zur Basisstation erfolgt mittels Bluetooth IEEE 802.15.1. Um die Komplexität
der Software auf dem TSN möglichst gering zu halten, wird für die Übertragung
ein Bluetooth-Modul von Lesswire [30] genutzt. Das Modul kapselt den Bluetooth-Stack
vollständig und bietet für die Kommunikation ein UART-Interface an.
Im Folgenden wird das Modul kurz vorgestellt und die Integration in eCos beschrieben.
Lesswire Module Bluebear SP-S
In den TSN wird das Bluebear SP-S Module von Lesswire integriert. Das Modul bietet ein
Serial Port Profile (SPP) zur Datenübertragung und zur Konfiguration an. Der Bluetooth-
Stack wird vollständig durch das Modul gekapselt, so dass der Zugriff ausschließlich über
die serielle Schnittstelle erfolgt. Das Modul verwendet das ISM Band (2,4 - 2,4835 GHz)
womit eine theoretische Datenrate von 3 MBit/s möglich wäre. Die maximale Datenrate
wird jedoch durch die serielle Schnittstelle auf 115 kBit/s begrenzt.
66

Abschlussbericht
Trusted Sensor Node
Das Modul unterstützt die Bluetooth-Protokolle Logical Link Control and Adaption Layer
Protocol (L2CAP) und Service Discovery Protocol (SDP). Damit ist es zu jedem Bluetooth-
Gerät, welches diese Protokolle anbietet und das SPP nutzt, kompatibel. Somit können für
die Basisstation standardisierte bzw. marktübliche Geräte verwendet werden.
Zur Sicherung der Bluetooth-Verbindung unterstützt das Modul einen Pin-geschützten Verbindungsaufbau
und die 128-Bit-Verschlüsselung nach dem Bluetooth-Standard. Diese
Verschlüsselung ist an SAFER+ angelehnt [46].
Initialisierung und Datenübertragung
Für die Datenübertragung wird die Schnittstelle UART0 des LEON2-Prozessor verwendet.
Die Kommunikation mit der Schnittstelle erfolgt über den in Abschnitt 4.1.1 beschriebenen
Treiber. Die Schnittstelle wird mit den folgenden Parametern konfiguriert:
• 38400 baud,
• 8 Datenbits,
• 1 Stoppbit und
• keine Parität.
Der Zugriff auf die serielle Schnittstelle erfolgt über den PPP-Layer des TCP/IP-Stacks. Der
PPP-Layer verwendet direkt read- und write-Funktionen des Treibers. Weitere Funktionen
sind nicht notwendig.
Wie in Abschnitt 4.3.2 beschrieben, wird die serielle Schnittstelle mittels der Funktion
sio_open() geöffnet. Die Funktion gibt einen Zeiger auf ein Objekt vom Typ cyg_io_
handle_t zurück. Über dieses kann anschließend die serielle Schnittstelle konfiguriert
werden. Das Konfigurieren muss vor dem Öffnen der PPP-Verbindung erfolgen. Hierfür
können die im Abschnitt 3.1.2 beschriebenen Funktionen verwendet werden. In der aktuellen
Implementierung des TSN ist es nicht notwendig die Parameter der seriellen Schnittstelle
zu ändern.
Konfigurationsmodus
Für das Setzen der Bluetooth-Parameter verfügt das Modul, wie einleitend erwähnt, über
ein zusätzliches SPP. Für den Zugriff auf das Konfigurations-SPP muss die Datenverbindung
unterbrochen und das Konfigurationsprofil geöffnet werden. Damit ist es möglich,
dass Modul über die Basisstation zu konfigurieren.
Zusätzlich kann das Konfigurieren über die serielle Schnittstelle erfolgen. Hierzu muss das
Modul zuvor über einen I/O-Pin in den Konfigurationsmodus versetzt werden. Diese Leitung
verbindet den Pin CONFMOD des Bluebear-Moduls mit einem GPIO des LEON2-Prozessors.
Das Umschalten in den Konfigurationsmodus erfolgt durch einen Flankenwechsel
67

Abschlussbericht
Trusted Sensor Node
auf der Leitung. Anschließend kann das Modul über AT-Kommandos konfiguriert werden.
Über dieses Interface können die in Tabelle 4.2 beschriebenen Parameter gesetzt werden.
Kommando
Beschreibung
AT name Bluetooth-Name
AT pin
Anzeigen und Setzen der Pin
AT security Anzeigen und Ändern des Security-Modus
AT setdefaults Rücksetzen auf default-Einstellungen
AT slaveaddress MAC-Adresse
AT uart Einstellen der UART-Parameter 4
AT exit
Neustarten des Moduls und übernehmen der Parameter
Tabelle 4.2: AT-Kommandos des Bluebear SP-S
Die aktuelle Version der Firmware des TSN das Konfigurieren des Bluebear-Moduls über
die serielle Schnittstelle nicht möglich. Stattdessen wird eine statische Konfiguration verwendet.
So ist die serielle Verbindung auf die Parameter 38.400 Baud 8N1 und die Pin auf
1234 festgelegt. Änderungen können über die Basisstation vorgenommen werden. Hierbei
ist jedoch zu achten, dass die Parameter der serielle Verbindung nicht geändert werden
können, da sie fest mit der Implementierung der Firmware des TSN verknüpft sind.
4.3.4 Sensor Protokoll
Für die Kommunikation mit den Sensorknoten wird ein Protokoll entsprechend dem Standard
IEEE 802.15.4 verwendet. Dieser Standard, der erstmals 2003 veröffentlicht wurde,
umfasst die Spezifikation eines PHY-Layers und eines MAC-Layers des OSI-Referenzmodells.
Im Jahr 2006 erschien eine revidierte Fassung, die Verbesserungen und Ergänzungen
gegenüber dem Vorgänger enthält. In der Erweiterung aus dem Jahr 2007 werden
zwei zusätzliche, alternative Physical Layer definiert [54].
Auf der Vermittlungsschicht wird für 802.15.4 das ZigBee-Protokoll empfohlen, dieses soll
eine Interoperabilität zwischen Komponenten verschiedener Hersteller gewährleisten. Im
Rahmen des TSN-Projektes ist eine Kompatibilität zu den iSense-Knoten gewünscht. Die
Knoten verwenden Module von Jennic, jedoch ohne die ZigBee-Erweiterung, so dass auf
der Vermittlungsschicht ein proprietäres Protokoll verwendet wird.
Da im Rahmen des Projektes die Koppelung des TSN mit den iSense-Knoten nicht möglich
war, wurde eine proprietäre Implementierung für das Sensorprotokoll erstellt. Diese ist
im User Manual des TSN dokumentiert. Sie erlaubt das Weiterleiten von den Daten der
Sensorknoten und von Alarmnachrichten des TSN an eine Basisstation.
4 Die Parameter beziehen sich nur auf SPP-Data. Für SPP-Config wird immer mit 115200 Baud 8N1 verwendet
68

Abschlussbericht
Trusted Sensor Node
4.4 TSN Threads
Bereits im Abschnitt 3.1.1 wurde erwähnt, dass unter eCos mehrere parallele Ausführungspfade
implementiert werden können. Für den TSN wird dies für die verschiedenen
Kernaufgaben empfohlen. So sollten neben dem Bridge- noch ein Schlüsselaustausch-,
ein Sensorik- und ein Management-Thread erstellt werden.
Dieser Abschnitt gibt einen kurzen Überblick über die vier mögliche Threads und beschreibt
deren Funktionsweisen. Die im Rahmen des TSN-Projektes erstellten Applikationen
implementiert nur einen Teil der Threads. Eine vollständige Implementierung ist noch
zu erstellen, wenn die Integration des TSN in ein reales Sensornetz erfolgt.
4.4.1 Bridge Thread
Der Bridge Thread stellt die Verbindung zwischen den beiden Netzwerk-Stacks her. Er
empfängt von den Sensorknoten die Sensordaten und leitet sie an die Basisstation weiter.
Zusätzlich können Konfigurationsdaten bzw. neue Parameter von der Basisstation über die
Bridge Applikation an die Sensorknoten verteilt werden.
Darüber hinaus ist der Bridge Thread für die folgenden Funktionen verantwortlich:
• Verbindungsaufbau zur Basisstation,
• Ver- und Entschlüsseln der Sensordaten,
• Überwachung der Sensorknoten und
• Keep-Alive zur Basisstation.
Der Verbindungsaufbau zur Basisstation ist immer nach dem Neustart des TSN bzw. des
Kommunikationsmoduls notwendig. Hierbei erfolgt der Bluetooth-Verbindungsaufbau und
die Einwahl bei der Basisstation mittels PPP. Zur Realisierung eines Keep-Alive ist dies in
regelmäßigen Abständen notwendig. Das Keep-Alive signalisiert der Basisstation, das der
TSN noch verfügbar ist. In einem initialen Schritt können hier für die Keep-Alive Nachrichten
des Link Control Protocol (LCP) von PPP genutzt werden.
Zusätzlich ist der TSN für die Überwachung der Sensorknoten verantwortlich. Hier wird,
wie zur Basisstation, ein ständiges Keep-Alive durchgeführt. Ist ein Knoten nicht mehr
erreichbar, wird dies der Basisstation gemeldet.
69

Abschlussbericht
Trusted Sensor Node
4.4.2 Schlüsselaustausch Thread
Der Schlüsselaustausch Thread ist für das Aushandeln von Schlüsseln verantwortlich. Im
Rahmen des Projektes wurde eine Schlüsselaushandlung mittels Hashed Random Preloaded
Subsets (HARPS) [43] für den TSN umgesetzt.
4.4.3 Sensorik Thread
Der Sensorik Thread ist für die Auswertung der Sensordaten des TSN zuständig. Der TSN
verfügt mit dem Beschleunigungs- und dem passiven Infrarotsensor über zwei Sensorquellen.
Die Sensorquellen werden über das im Abschnitt 4.2.2 beschriebene SensorAPI
angesprochen.
Die Sensoren liefern lediglich Rohdaten, die vom Sensorik Thread ausgewertet werden
müssen. Der Thread entscheidet anhand der Konfiguration des TSN, welche Sensorwerte
als zulässig bzw. als unzulässig gewertet werden sollen. Nach der Erkennung von unzulässigen
Werten wird von einer versuchten Manipulation bzw. Gefährdung des TSN ausgegangen.
Derartige Ereignisse müssen der Basisstation gemeldet werden. Zusätzlich sind
geeignete Schutzmaßnahmen für den TSN zu ergreifen. Denkbar wäre das Löschen der
vorgehaltenen Schlüssel.
Um fehlerhafte Sensorwerte und damit Fehlalarme zu vermeiden, enthält der Sensorik
Thread den in Abbildung 4.4 dargestellten Zustandsautomaten. Im Normalzustand werden
die Sensordaten alle n Sekunden von den Sensoren erfragt. Entsprechen sie den
Vorgaben, kehrt der Automat in den Startzustand zurück, d.h. der Thread schläft für n Sekunden.
Liegt der Wert in der Nähe des unzulässigen Bereiches, geht der Thread in den
Bereitschaftszustand über. In diesem Zustand werden die Sensordaten in einem geringeren
Intervall erfasst. Kehren sie in den Normalbereich zurück, wird der Bereitschaftszustand
wieder verlassen. Bleiben die Werte über einen längeren Zeitraum in diesem Grenzbereich,
so wird dies ebenfalls als unzulässiger Bereich gewertet.
Die Werte für den Übergang in den Bereitschaftszustand und die Verweildauer in diesem
Zustand sollten, zusammen mit dem zulässigen und dem unzulässigen Wertebereich für
de Sensordaten, Bestandteil der Sensorparameter sein. Es ist sinnvoll diese unabhängig
von der Firmware des TSN zu speichern, um bei stark veränderten Umweltbedingungen
TSNs mit verschiedenen Parametern einzusetzen.
4.4.4 Management Thread
Die Steuerung der TSN-Software wird von dem Management Thread übernommen. Hierbei
handelt es sich auch um den Thread, der von der Funktion cyg_user_start() gestartet
und initialisiert wird. Wie in Abbildung 4.5 dargestellt, übernimmt der Thread direkt
die Steuerung des Bridge-, des Schlüsselaustausch- und des Sensorik Threads. Hierzu
70

Abschlussbericht
Trusted Sensor Node
Normal Status
sleeping
n secs
clear
OnAlert
counter
fetch
sensor
data
not
reached
ok
data
OnAlert
OnAlert
Status
count
max
Alarm
reached
Alarm Status
Abbildung 4.4: Zustandsautomat der Sensorüberwachung
gehört das Starten und das Initialisieren der Threads, sowie die Verwaltung der Konfigurationsdaten.
Management
Thread
Config
Data
Bridge
Thread
KeyExchange
Thread
Sensor
Thread
Abbildung 4.5: Management der TSN Threads
In der aktuellen Implementierung wird die Konfiguration zusammen mit der Firmware abgelegt.
Wie bereits in anderen Abschnitten erwähnt, sollte hier in weiterführenden Arbeiten
ein gesicherter Update-Prozess integriert werden. Der Management Thread hat über das
CryptAPI Zugriff auf die Crypto-Komponenten des TSN und verfügt damit über die Voraussetzungen
für einen integritäts- und authentizitätsgesicherten Update-Prozess.
71

5 Simulation und Messergebnisse
5.1 Ziel
Dieser Abschnitt beschreibt die Simulation und die reale Messungen der Leistungsaufnahme
des TSN. Ein Vergleich von Simulation und Realität ist notwendig, da sich beide i.d.R.
oft unterscheiden. Eine Simulation kann viele Einflussfaktoren nicht berücksichtigen, die
zwangsläufig in der Praxis auftreten.
5.2 Messaufbau
Zunächst wurde für die Messung eine Platine modifiziert. Die beiden notwendigen Spannungen
von 2,5 V und 3,3 V werden nicht durch den, auf der Platine integrierten, Spannungswandler
bereitgestellt, sondern separat eingespeist. Dies hat den Vorteil, dass der
Strom für beide Spannungen exakt bestimmt werden kann. Die Spannungen werden von
einem Dual SourceMeter 2636 von Keithley [25] bereit gestellt. Im genutzten Messbereich
bis 100 mA beträgt die Abweichung weniger als 1µA.
Die beiden Funkmodule wurden von ihrer Spannungsversorgung getrennt, da diese die
Messung erheblich verfälschen würden. Mit 3,3 V werden neben den Pads des TSN der
Speicher (SRAM, Flash), der Beschleunigungssensor und dem der Quarzoszillator versorgt.
Die Spannung von 2,5 V liegt ausschließlich an der Corespannung des TSN und an der
Power-On-LED an. Die Power-On-LED benötigt ca. 2 mA, so dass vom Messwert 2mA
abgezogen werden müssen, um den Strom für den die Corespannung zu bestimmen.
Im Resetzustand 1 arbeitet lediglich der Quarzoszillator, so kann der Strom bestimmt werden,
den der Quarzoszillator benötigt. Dieser beträgt ca. 5,9 mA. Des Weiteren beträgt der
Strom für den Core ca. 40,3 mA. In diesem Zustand befindet sich der Chip im Ruhezustand,
nur das Taktsignal wird an jedes Register geführt. Der hohe Wert zeigt, dass es
sinnvoll ist, bei späteren Optimierungen auf das Clock-Gating zu setzen oder die Anzahl
der Register zu reduzieren (siehe Abschnitt 6.2).
1 Der Resettaster ist dauerhaft gedrückt

Abschlussbericht
Trusted Sensor Node
5.3 Messprogramm
Die Messung der Leistungsaufnahme wurde exemplarisch für die Verschlüsselungsalgorithmen
AES und ECC durchgeführt. Um diese möglichst exakt zu bestimmen, wurde jeweils
ein Assemblerprogramm geschrieben, dass den maximalen Datendurchsatz beider
Komponenten ermöglicht. Das Listing 5.1 zeigt den Code für die Ansteuerung des AES.
Initial wird der Schlüssel in die notwendigen Register geschrieben. Da dieser Vorgang nur
einmalig erfolgt, wurde an der Stelle auf die Optimierung in Assembler verzichtet. Anschließend
werden in einer Endlosschleife die zu verschlüsselnden Daten geschrieben, 70 Takte
gewartet und die nun verschlüsselten Daten ausgelesen. Das Programm wird bei seiner
erstmaligen Ausführung aus dem SRAM geladen. Danach wird das Programm aus dem
Cache ausgeführt, so dass das Programm ohne jede Verzögerung abgearbeitet wird.
Für die Bestimmung der Leistungsaufnahme des AES wird zunächst das AES-Programm
wie in Listing 5.1 auf dem TSN zur Ausführung gebracht und dabei die Leistungsaufnahme
ermittelt. Anschließend wird das Programm so modifiziert, dass die Zeile 27 auskommentiert
und Zeile 29 einkommentiert wird. Die Änderung im Programm sorgt dafür, dass das
AES seine Verschlüsselungsoperation nicht startet. Der gesamte Programmablauf entspricht
der der Verschlüsselung, das letzte Datenwort wird jedoch nicht an die Adresse
0x25C geschrieben. Das Schreiben an diese Adresse würde für den AES-Core bedeuten,
die Verschlüsselung zu beginnen. Dieses Programm wird im folgenden mit „AES_dum“ 2
bezeichnet Für den ECC wurde die Ansteuerung auf gleiche Art und Weise implementiert.
1 //write Key
2 //write key bits 127 downto 96
3 *((unsigned int *) 0x20200210) = 0x2b7e1516;
4 //write key bits 95 downto 64
5 *((unsigned int *) 0x20200214) = 0x28aed2a6;
6 //write key bits 63 downto 32
7 *((unsigned int *) 0x20200218) = 0xabf71588;
8 //write key bits 31 downto 0
9 *((unsigned int *) 0x2020021C) = 0x09cf4f3c;
10
11 //endless loop
12 for (;;)
13 {
14 //write data - optimized in asm
15 asm (
16 "!set global adress in register %o1\n"
17 " sethi %hi(0x20200000), %o1\n"
18 "!write first 32 bit\n"
19 "!write upper 23 bits into register %o0"
20 " sethi %hi(0x3243f400), %o0\n"
21 "!write lower 9 bits into register %o0"
22 " or %o0, 0x2a8, %o0\n"
23 "!write content of register %o0 in AES reg"
24 "!destination address will be calculated from value of %o1 + offset"
25 " st %o0, [ %o1 + 0x250]\n"
26 "!write next data bits\n"
2 dum= Dummy Operation
74

Abschlussbericht
Trusted Sensor Node
27 " sethi %hi(0x885a3000), %o0\n"
28 " or %o0, 0x8d, %o0\n"
29 " st %o0, [ %o1 + 0x254]\n"
30 "!write next data bits\n"
31 " sethi %hi(0x31319800), %o0\n"
32 " or %o0, 0xa2, %o0\n"
33 " st %o0, [ %o1 + 0x258]\n"
34 "!write next data bits\n"
35 " sethi %hi(0xe0370400), %o0\n"
36 " or %o0, 0x334, %o0\n"
37 "! use this line for a normal AES operation \n"
38 " st %o0, [ %o1 + 0x25C]\n"
39 "! use this line for switched off AES \n"
40 "! st %o0, [ %o1 + 0x258]\n"
41 "!wait until aes finished\n"
42 " 70 x nop\n"
43 "!read words from aes, aes base address is stored in %o1\n"
44 "!store value in register %o0"
45 " ld [ %o1 + 0x250], %o0\n"
46 " ld [ %o1 + 0x254], %o0\n"
47 " ld [ %o1 + 0x258], %o0\n"
48 " ld [ %o1 + 0x25C], %o0\n"
49 );
50 }
Listing 5.1: Code für maximalen Datendurchsatz des AES
5.4 Messungen
Der Messaufbau wurde wie in Abschnitt 5.2 beschrieben umgesetzt und die Programme
auf dem TSN zur Ausführung gebracht. In Tabellen 5.1 und 5.2 zeigen jeweils Messungen
für den realen Knoten sowie die Simulation.
Zur Verifikation der Messergebnisse kann die Simulation der Leistungsaufnahme wie in
Abschnitt 2.22 herangezogen werden. Die Simulationsergebnisse sind in den Tabellen mit
ausgewiesen. Bei genauerer Betrachtung der Differenz in der Stromaufnahme bei Verschlüsselung
und der Ausführung des Dummy-Programms, ist ersichtlich dass diese in
der Simulation und der realen Messung fast den gleichen Wert haben.
Die jeweilige Stromaufnahme wird durch die Differenz der Stromaufnahme beider Programme
(also funktionsfähiges Programm und Dummy-Programm) ermittelt. Beim AES ist
eine Stromaufnahme von 1,4 mA gemessen und eine Stromaufnahme von 1,3 mA simuliert
worden. Beim ECC hingegen war die Abschätzung in der Simulation schlechter als
tatsächlich gemessen. In der Simulation werden 10,87 mA ermittelt, während tatsächlich
8,58 mA gemessen wurden.
Der durchschnittliche Fehlbetrag in Simulation und Messung beträgt etwa 22 mA. Davon
entfallen 2 mA auf die Power-On-LED. Die verbleibenden 20 mA müssen somit innerhalb
75

Abschlussbericht
Trusted Sensor Node
des TSN verbraucht werden. Dafür kommen Pads und Cache in Frage. Beide werden in
der Simulation bei der Bestimmung der Leistungsaufnahme nicht berücksichtigt, da für
diese keine geeigneten Bibliotheksinformationen vorliegen.
Programm VDDPad VDDCore
AES auf TSN 11,20 mA 44,70 mA
AES_dum auf TSN 11,17 mA 43,30 mA
AES in Simulation - 21,0 mA
AES_dum in Simulation - 19,7 mA
Tabelle 5.1: Messungen der Stromaufnahme für den AES
Programm VDDPad VDDCore
ECC auf TSN 11,07 mA 49,09 mA
ECC_dum auf TSN 11,11 mA 40,51 mA
ECC in Simulation - 29,63 mA
ECC_dum in Simulation - 18,76 mA
Tabelle 5.2: Messungen der Stromaufnahme für den ECC
5.5 Lebensdauertest
Der Lebensdauertest wurde mit zwei verschiedenen Szenarien durchgespielt. Zunächst
erfolgte die Stromversorgung über 3 NiMH-Akkus mit einer Kapazität von je 2700 mAh.
Dabei wurde eine Laufzeit von ca. 20 Stunden für den TSN-Knoten ermittelt. Nach dieser
Zeit war die Spannung an der belasteten Spannungsquelle auf 2,4 V eingebrochen, so
dass auf der Platine integrierte Spannungswandler den unteren Arbeitspunkt erreicht hatte.
Der zweite Test wurde mit einer Solarzellen-Akku-Kombination durchgeführt. Dabei wurde
eine durchschnittliche Betriebsdauer von 16 Stunden ermittelt. Eine Aufladung des Akkus
mit Hilfe der Solarzellen fand nicht statt, so dass bei Sonneneinstrahlung mit verlängerter
Lebensdauer zu rechnen ist.
76

6 Future Work
In diesem Abschnitt wird eine Projektskizze vorgestellt, bei der das abgeschlossene TSN-
Projekt die Grundlage bildet. In den einzelnen Abschnitten werden Optimierungen des TSN
gezeigt. Dabei wird die Software und die Hardware betrachtet. Darüber hinaus werden
Veränderungen am Board-Design und an der Energieversorgung vorgeschlagen.
Im Überblick beziehen sich die Änderungsvorschläge auf:
• die Einführung einer µKern-Architektur,
• das Trusted Computing,
• ein sicheres Code-Update auf Softwareebene,
• die Veränderungen an vorhandener Hardware,
• das Hinzufügen neuer Hardwarekomponenten,
• die Nutzung eines Ball Grid Array (BGA)-Gehäuses für den ASIC,
• die Verbesserungen im Board-Design und
• das Aufzeigen alternativer Energieversorgungen.
6.1 System-Architektur
Bei der Erstellung der Softwarearchitektur für den TSN wurden, wenn möglich, Komponenten
aus dem embedded Configurable operating system (eCos) verwendet. Dies hat
den Vorteil, dass auf ein bereits funktionierendes System aufgebaut und die Softwareentwicklung
auf die Peripheriekomponenten des TSN konzentriert werden konnte. Da eCos
ein Betriebssystem für eingebettete Systeme ist, deckt es nicht alle Anforderungen an
einen drahtlosen Sensorknoten wie den TSN ab.
In diesem Abschnitt werden Software- und Hardware-Mechanismen vorgestellt, die die Sicherheit,
die Verfügbarkeit und die Flexibilität des TSNs erhöhen. Insbesondere die Mechanismen
zur Steigerung der Systemsicherheit sind integrale Bestandteile eines Betriebssystem
und lassen sich nur mit großem Aufwand in eCos integrieren. Aus diesem Grund wird
unter anderem ein alternatives Betriebssystem näher beleuchtet.

Abschlussbericht
Trusted Sensor Node
6.1.1 Mikrokern-basierter TSN mit Security Compartments
Viele der aktuellen Betriebssysteme für eingebettete Systeme, z.B. eCos, µClinux, TinyOS
oder Reflex, bestehen aus einen monolithischen Kern, der funktional in verschiedene Module
unterteilt wird. Die Trennung der Module besteht hierbei jedoch nur auf der Programmiersprachenebene,
zur Laufzeit existiert keine Trennung zwischen den Modulen.
Ein monolithisches System hat im Wesentlichen die folgenden Nachteile:
• Fehler einer Komponente bleiben nicht auf diese beschränkt
• alle Daten des Knotens sind von jeder Komponente les- und schreibbar
• ein dediziertes Wiederaufsetzen von einzelnen Modulen ist nicht möglich
Aufgrund oben genannter Nachteile befürworten wir den Ansatz eines mikrokern-basierten
Betriebssystems für eingebettete Systeme. Hierbei stellen wir zunächst das Konzept der
„Security Compartments“ vor, welche die Grundlage für ein sicheres System bilden, jedoch
nur von den wenigsten aktuellen eingebetteten Systemen unterstützt wird. Darauf
aufbauend wird mit L4 eine Mikrokern-Architektur aufgezeigt, mit der die Sicherheit des
TSN signifikant erhöht werden kann.
Security Compartments
Unter Security Compartments versteht man die Aufteilung der Systemressourcen auf voreinander
geschützte Teilkomponenten. Diese Security Compartments werden dabei durch
Protection Domains voreinander geschützt. Eine Protection Domain ist eine Menge von
Zugriffsrechten zum Schutz von Ressourcen [12]. Jedes Compartment wird hierbei genau
einer Domain zugeordnet. Allerdings können verschiedene Compartments einer Domain
angehören. Zwei Security Compartments können daher nur dann miteinander kommunizieren,
wenn ihre Protection Domains den Zugriff auf eine gemeinsame Ressource gestatten.
Durch das Fehlen von Security Compartments in eingebetteten Systemen wirken sich
lokale Fehler in den Komponenten auf das gesamte System aus. Wie in Abbildung 6.1
dargestellt, kann z.B. ein Fehler in einem Treiber durch das Fehlen von Schutzbarrieren
auch das Memory Management oder den Scheduler beeinflussen, so dass ein störungsfreier
Betrieb des Gesamtsystems nicht mehr sichergestellt werden kann. Wie Abbildung
6.2 verdeutlicht, können durch die Einführung von Security Compartments die verschiedenen
Module voreinander geschützt werden, so dass die Auswirkungen eines Fehlers
auf die betroffene Komponente begrenzt sind. Ein Compartment hat nur Zugriff auf einen
bestimmten, ihm zugeteilten, Bereich des Systems.
Die Unterteilung des Systems in verschiedene Security Compartments wird durch den
Systemkern organisiert. Der Kern muss hierbei durch die Hardware unterstützt werden.
So ist die Bereitstellung von verschiedenen Ausführungsmodi und von Zugriffsrechten auf
78

Abschlussbericht
Trusted Sensor Node
Service
Service
ISR
Driver
Driver
Scheduler
Service
Service Task
Task
Memory
Manager
Abbildung 6.1: Auswirkung von Fehlern in Betriebssystemen ohne Security
Compartments
Service
Service
ISR
Driver
Driver
Scheduler
Service
Service Task
Task
Memory
Manager
Abbildung 6.2: Schutz von Betriebssystemkomponenten durch Security
Compartments
79

Abschlussbericht
Trusted Sensor Node
Speicherseiten zwingend erforderlich. Nahezu alle 32-Bit-Mikroprozessoren unterstützen
mindestens zwei Ausführungsmodi, den SuperVisor- und User-Modus. Der aktuelle Ausführungsmodus
wird im Statusregister des Prozessors abgelegt. Ein Wechsel vom unprivilegierten
User-Modus in den privilegierten SuperVisor Modus ist nur über eine wohldefinierte
Schnittstelle möglich.
Jede Nutzer-Task wird in einem eigenen Security Compartment im User-Modus des Prozessors
ausgeführt und kann nur über definierte Schnittstellen mit anderen Tasks kommunizieren.
Sie erhalten dabei nur eine eingeschränkte Sicht auf die Systemressourcen.
Ein beliebiger Zugriff ist hier nicht möglich. Durch die Ausführungen von Programmen und
Diensten im User-Modus wird verhindert, dass Daten einer anderen Task gelesen oder
geschrieben werden können. Fehler in einer Task beeinflussen nur diese und nicht das
gesamte System. Zusätzlich kann nach einem schwerwiegenden Fehler die Task neu gestartet
werden.
Mikrokern-Systeme
Durch eine weitere Unterteilung des Gesamtsystems in verschiedene Security Compartments
können die Auswirkungen von Fehlern weiter verringert werden. Systeme mit einer
sehr feingranularen Unterteilung und einem kleinen Kern bezeichnet man als Mikrokern-
Systeme. Hierbei werden im Systemkern lediglich Funktionen umgesetzt, die zwingend im
SuperVisor-Modus des Prozessors ausgeführt werden müssen.
Der L4-Mikrokern basiert auf zwei Basiskonzepten: Threads und Adressräume. Für die Interadressraumkommunikation
bietet der Kern zusätzlich Interprozesskommunikation (IPC)-
Funktionen an. Alle weiteren Funktionen bauen auf diesen Basisfunktionen auf und werden
weitestgehend im Userspace ausgeführt.
Wie in Abbildung 6.3 dargestellt, werden Dienste und Treiber eines monolithischen Systemkerns
in einem Mikrokern-basierten System in den User-Mode verlagert. Dies umfasst
auch in weiten Teilen die Verwaltung von Hardwareressourcen. Interrupts werden vom
Kern als IPC an die Treiber-Task zugestellt und die Memory-Mapped-IO-Bereiche werden
in den Adressraum der Task eingeblendet.
Ein wesentlicher Nachteil von Mikrokernen besteht in dem Leistungsverlust durch die
große Anzahl an Adressraumwechseln. Bei jedem Umschalten des Adressraumes müssen
Teile des Prozessors neu geladen werden. Insbesondere bei komplexen Systemen,
wie einen Desktop- oder Server-System, wird dieser Leistungsverlust spürbar, so dass eine
kommerzielle Nutzung von µKernen in derartigen Systemen heutzutage nicht existiert.
Da ein eingebettetes System nur über eine überschaubare Anzahl an Threads verfügt,
sind die Kosten für einen Adressraumwechsel weniger beeinträchtigend für das System.
Die Threads umfassen bei einem µKern-basierten eingebetteten System lediglich Systemdienste.
Nutzer-Threads (Applikationen) sind für die meisten Einsatzszenarien gar nicht
oder nur in einer sehr geringen Anzahl notwendig. Gerade die Beschränkung auf Systemdienste
führt dazu, dass der Einsatz von µKernen bei eingebetteten Systemen einen
signifikanten Zuwachs an Systemsicherheit bei akzeptablen Performanceeinbußen bietet.
80

Abschlussbericht
Trusted Sensor Node
Task Task Task
Network Stack, Filesystem
Memory Manager, Scheduler
Device Drivers, ISR, ...
User-
Mode
SuperVisor-
Mode
Task
Device Driver
Network Stack
File System
IPC, Memory Management
Hardware
Hardware
Abbildung 6.3: Aufteilung von Diensten und Services in monolithischen und
µKern-Betriebssystemen
L4-basierter Trusted Sensor Node
L4 ist eine Mikrokern-Architektur entworfen und erstmals implementiert von Jochen Liedtke
[52]. Aktuell existieren verschiedene Implementierungen (L4Ka::Pistachio [26], Fiasco
[18], OKL4 [38]), die für den jeweiligen Einsatz- und Forschungszweck optimiert wurden.
Ursprünglich für die x86-Architektur IA32 von Intel entwickelt, sind aktuell Portierungen für
weitere Hardware-Plattformen (z.B. MIPS64, PPC, AMD64, Alpha, ARM) frei verfügbar.
Der TSN verfügt über wenige Dienste, die bereits in der aktuellen Implementierung in Module
ausgelagert wurden. Da eCos jedoch das Konzept der Security Compartments nicht
unterstützt, werden diese Dienste in einem Adressraum zusammengefasst, so dass Fehler
in einem Modul alle anderen Module beeinflussen bzw. sensitive Daten nicht wirksam
geschützt werden können. Durch den Einsatz eines Mikrokerns, können die Module des
TSN auf verschiedene Adressräume verteilt werden. Damit kann ein wirksamer Schutz
zwischen den Diensten installiert werden, so dass eine sichere Speicherung von sensitiven
Daten möglich wird. Darüber hinaus ermöglicht die Mikrokern-Technologie durch den
Einsatz von Watchdog-Technologien die Überwachung und das Wiederherstellen von Systemdiensten.
L4 ist aktuell nicht für die SPARC-Architektur verfügbar. Es gibt erste Ansätze für eine
Portierung auf diese Plattform, die weitergeführt werden müssten. Die Auslagerung von
Diensten in verschiedene Adressräume muss ebenfalls für den TSN umgesetzt werden. Es
existieren bereits Frameworks wie z.B. L4Env[56], die viele Dienste eines Betriebssystems
als L4-Tasks bereitstellen. Allerdings müssen die TSN-spezifischen Dienste, wie z.B. die
Implementierung von HARPS, SPI oder die Tamper Detection auf die Plattform portiert
werden.
81

Abschlussbericht
Trusted Sensor Node
TSN-MMU
Die LEON2-CPU des TSN verfügt über keine Memory Management Unit (MMU), so dass
eine Implementierung von Security Compartments auf dieser Hardware nicht möglich ist.
Eine MMU ist für die Übersetzung von virtuellen Adressen in physikalische Adressen verantwortlich
und ermöglicht die Bereitstellung von virtuellen Adressräumen. Damit kann
jedem Prozess ein einheitlicher virtueller Adressraum bereitgestellt werden. Es existiert
jedoch ein Referenzdesign in VHDL für eine MMU der SPARC-V8-Architektur [49], die unter
anderem über einen User- und einen SuperVisor-Modus sowie über Zugriffsflags für
Speicherseiten verfügt.
Es ist somit ohne größeren Implementierungsaufwand möglich den TSN um eine MMU zu
erweitern. Es bleibt zu prüfen, in wieweit die Integration der MMU Auswirkungen auf den
Platz- und den Energiebedarf des Chips hat. Beides kann bereits durch die Integration in
die Simulationsumgebung des TSN bzw. in einen Field programmable Gate Array (FPGA)
evaluiert werden.
6.1.2 Trusted Computing
Trusted Computing (TC) ist eine Technologie, die von der Trusted Computing Group (TCG)
entwickelt und beworben wird [53]. TC bedeutet, dass die im Computersystem verwendete
Hard- und Software sicher kontrolliert werden kann. Hierzu werden die Systeme mit einem
zusätzlichen Sicherheitsmodul ausgestattet, welches mittels kryptographischer Verfahren
die Authentizität, Integrität und die Vertrauenswürdigkeit der Hard- und der Software nachprüfbar
macht. Für die Umsetzung ist ein sicheres Betriebssystem zwingend erforderlich,
da die Überprüfung des Systems nicht vom Sicherheitsmodul sondern vom Betriebssystem
initiiert werden muss.
Sicherheitsmodul des TSN
Das Sicherheitsmodul bietet mittels eines One Time Programmable (OTP)-Speicher einen
sicheren Anker (Root Key) für eine vertrauenswürdige Authentifizierung, Identifizierung
und Überprüfbarkeit des Systems. Es befindet sich zwischen dem AMBA-Bus und dem
internen Flash und überwacht alle Zugriffe auf den Flashspeicher und hat Zugriff auf den
Programmzähler des LEON2-Kerns. Damit besteht die Möglichkeit festzustellen, von welchem
Programmmodul aus auf den Flashspeicher zugegriffen wird. Unerlaubte Zugriffe
auf den Flash und den OTP können blockiert werden.
Durch die Sicherung des internen Flashspeichers mittels des Sicherheitsmoduls kann dieser
als Trusted Code Base verwendet werden. Der OTP-Speicher wird für die Speicherung
von eindeutigen Identifikatoren verwendet. Eine genauere Beschreibung hierzu erfolgt in
den nächsten Abschnitten.
82

Abschlussbericht
Trusted Sensor Node
Root Key im OTP Ein OTP-Speicher ist ein einmalig programmierbarer nicht flüchtiger
Speicher und kann nach dem Fuse 1 -Prinzip programmiert werden. Nach der Fertigung
haben alle Bits des Speichers den Wert „1“. Durch das Anlegen einer hohen Spannung
(ca. 9,5V), können Bits auf „0“ gesetzt werden.
Für den Root Key (K root ) des TSN wird ein OTP-Speicher verwendet. Dieser ist als direkt
adressierbarer Bit-Vektor organisiert. Jedes einzelne Bit wird über eine separate Leitung
mit dem Datenbus verbunden. Beim K root handelt es sich um ein ECC-Schlüsselpaar
(K pub
root , Kpriv root ), welches die Basis für die Schlüsselinfrastruktur des TSN bildet. Der K root
wird bei der Initialisierung des TSN einmalig gespeichert und kann im Folgenden nicht
mehr verändert werden. Die Schlüssel K pub
root und Kpriv root werden über separate Datenbusse
aus dem OTP-Speicher herausgeführt.
Wie in Abbildung 6.4 dargestellt, ist der Datenbus von K pub
root an den AMBA-Bus angeschlossen.
Der Zugriff wird zwar durch das Sicherheitsmodul kontrolliert, aber die Abfrage
von K pub
root ist unbeschränkt möglich. Der Datenbus des Kpriv root ist mit dem ECC-Modul des
TSN verbunden. Es existiert keine Verbindung zwischen dem K priv
root im OTP und einem
Systembus. Der Schlüssel kann nur über das Select-Signal Sel in den Schlüsselspeicher
K der ECC-Komponente geladen werden. Ein direktes Auslesen von K und K priv
root im OTP
ist nicht vorgesehen. Damit ist auch kein Backup des Schlüssels möglich.
AMBA
LEON2
PC
Security Module
P(x,y)
ECC
K
Sel
K priv
root
OTP
K pub
root
internal
Flash
Abbildung 6.4: Integration des Sicherheitsmoduls in den TSN
Das Einspielen von K root erfolgt über die DSU des LEON2. Damit ist der Vorgang nach
dem Assembling des Chips möglich und kann ortsungebunden durchgeführt werden. Das
Einspielen kann über die im Abschnitt 6.2.3 beschriebene Authentifizierungskomponente
der DSU gesichert werden.
Trusted Code Base (TCB) In einer späteren Version wird der TSN über zwei verschiedene
Flash-Speicher verfügen. Ein Flash-Speicher kann Bestandteil des TSN-Die 2 sein.
1 to fuse kommt aus dem Englischen und wird mit durchschmelzen übersetzt.
2 Ein Die (engl. Plättchen) ist die Bezeichnung eines einzelnen ungehäusten Halbleiter-Chips.
83

Abschlussbericht
Trusted Sensor Node
Der interne Flash ist 64 kByte groß und über einen Flash-Controller an den AMBA-Bus angeschlossen.
Zusätzlich verfügt der TSN über einen externen Flash der neben dem TSN
Mikrocontroller auf dem Printed Circuit Board (PCB) 3 platziert ist. Die Größe des externen
Flashs ist abhängig von den verwendeten Chips und beträgt im aktuellen Design 8 MByte.
Durch die Integration des internen Flashs auf dem Die bietet sich dieser für die Speicherung
von sensitiven Daten an. Eine manuelle Kontaktierung ist nur mit großem technischen
Aufwand und nicht ohne Beschädigung des Chipgehäuses möglich. Damit kann eine Änderung
des Inhaltes des Flashs ohne die Nutzung von TSN Komponenten weitestgehend
ausgeschlossen werden. Zur Sicherung des Flash-Speichers gegen Veränderungen des
Inhalts durch nicht autorisierten Programmtext wird in den TSN das Sicherheitsmodul integriert.
Das Modul befindet sich, wie in Abbildung 6.4 dargestellt, zwischen dem AMBA-Bus
und dem Flash-Controller. Zusätzlich kann das Sicherheitsmodul den Programm Counter
(PC) des LEON2-Kerns auslesen. Dies ermöglicht die Bestimmung der aktuellen Programmstelle
zum Zeitpunkt des Zugriffs. Der PC des LEON2-Kerns enthält die Adresse
des Befehls, der aktuell ausgeführt wird. Da der LEON2-Kern auf der Load/Store-Architektur
des SPARC basiert, kann der Zugriff auf den Flash nur durch eine Load/Store-Operation
erfolgen.
Ein schreibender Zugriff auf den Flash darf nur durch einen autorisierten Programmcode
erfolgen. Dieser muss Bestandteil der TCB sein. Die TCB (der interne Flash) wird beim
TSN immer auf einem festen Bereich des Adressraumes abgebildet. Alle Instruktionen der
TCB müssen sich innerhalb dieses Bereiches befinden. Wird ein schreibender Zugriff auf
dem Flash von einer anderen Speicheradresse ausgeführt, wird dieser Zugriff blockiert
und ein None-Maskable Interrupt (NMI) 4 generiert.
Trusted Boot Chain (TBC)
Ausgehend von der im vorangegangenen Abschnitt beschriebenen TCB und dem K root
lässt sich für den TSN, eine sichere Bootkette TBC, aufbauen. Bei einer TBC stellt, wie in
Abbildung 6.5 dargestellt, jedes Programmmodul sicher, dass das im Folgenden zu ladende
und auszuführende Modul vertrauenswürdig ist. Der Nachweis der Vertrauenswürdigkeit
kann mittels kryptographischer Prüfsummen erfolgen. Dabei ist bei der Verwendung
von internem Flash ein Hashwert ausreichend, bei der Verwendung von externem Flash
muss auf eine Signatur zurückgegriffen werden.
Die TBC wird beim ersten Einbringen der TSN-Software initialisiert. Hierzu wird der Programmtext
in einzelne Module unterteilt und separat eingespielt. Beim Einspielen eines
Moduls wird für das Modul mittels des K root oder eines davon abgeleiteten Schlüssels
eine Signatur erstellt. Die Signatur wird im internen Flash abgelegt und kann somit von außen
nicht verändert werden. Eine genaue Beschreibung hierzu erfolgt im Abschnitt 6.1.2.
Da nicht allgemeingültig vorausgesagt werden kann, in welcher Form die TBC aufgebaut
wird, kann im Rahmen des Projektes nur ein Framework für die TBC erstellt wer-
3 Printed Circuit Board ist die englische Bezeichnung für eine gedruckte Leiterplatte.
4 NMI sind Interrupts, die nicht von der CPU deaktiviert und damit zwingend behandelt werden müssen.
84

Abschlussbericht
Trusted Sensor Node
Drivers Services Task
µKern
Memory
Manager
Loader
external Flash
internal Flash
Boot Loader
Signatures
Abbildung 6.5: Trusted Boot eines L4-basierten Systems mit Signatur-basierter
Modulauthentifizierung
den. Das Framework enthält den Initial Boot Loader (IBL) und das Module Verification
Module (MVM). Beide sind Bestandteil der TCB, um sie gegen spätere nicht autorisierte
Änderungen zu schützen.
Initial Boot Loader (IBL) Der IBL enthält die ersten Instruktionen für den LEON2-Prozessor.
Nach einem Reset springt der Prozessor zunächst an die Startadresse des IBL. Im
Bootloader erfolgt das Initialisieren des Prozessor-Caches, des Systemspeichers und des
AMBA-Buses. Anschließend können weitere Module für das System geladen werden. Da
der IBL automatisch vom System gestartet wird und nicht geladen werden muss, kann dieser
Programmcode nicht vor dem Ausführen authentifiziert werden. Aus diesem Grund ist
der IBL zwingender Bestandteil der TCB, so dass schreibende Zugriffe kontrolliert werden
können.
Module Verification Module (MVM) Das MVM stellt ein Application Programming Interface
(API) für die Authentifizierung und Verifizierung von Programmmodulen bereit. Es
verwendet hierfür das in den LEON2-Prozessor integrierte Crypto-Modul und den K root
aus dem OTP-Speicher. Durch die Verwendung des MVM wird sichergestellt, dass die
Überprüfung der Module einheitlich und sicher durchgeführt wird. Das MVM ist als fester
Bestandteil in die TCB integriert, um so den Schutz vor Manipulation des MVM zu gewährleisten.
Abbildung 6.5 zeigt beispielhaft eine mögliche Trusted Boot Chain für ein L4-basiertes
System. Das System startet zunächst den Initial Boot Loader aus der TCB. Dieser lädt
anschließend den Mikrokern, den Speicher-Manager und den Loader-Thread aus dem externen
Flash. Die Module werden durch den IBL mittels des MVM verifiziert. Hierzu wird
die im internen Flash angelegte Signaturdatenbasis verwendet. Anschließend kann die
Programmkontrolle vom IBL an den Mikrokern bzw. den Loader übergeben werden. Dieser
kann danach weitere Module, z.B. Geräte-Treiber, Netzwerk-Stack und Applikationen
85

Abschlussbericht
Trusted Sensor Node
nachladen. Das Verifizieren der zu ladenden Module erfolgt durch Funktionen des MVM
und kann für alle weiteren Module durch den zuvor authentifizierten Loader durchgeführt
werden.
Secure Update
Der TSN ist für einen langjährigen Einsatz im Outdoor-Umfeld konzipiert und muss über
eine Remote-Update-Fähigkeit verfügen. Hierzu können die für die Übertragung der Sensordaten
zur Verfügung gestellten Kommunikationskanäle genutzt werden. Die Nutzung der
von außen zugänglichen Schnittstellen bedingt jedoch eine umfangreiche Absicherung des
Prozesses, um zu verhindern, dass dieser nicht ohne vorherige Autorisierung durchgeführt
wird.
Um einen möglichst flexiblen Einsatz des TSN zu ermöglichen, ist es notwendig, dass sowohl
die Konfigurationsdaten als auch der Programmcode aktualisiert werden können. Im
Folgenden werden Software-technische Mechanismen zur Bereitstellung eines sicheren
Update-Dienstes beschrieben. Hierbei wird zwischen dem Update der Konfigurationsdaten
und des Programmtextes des TSN unterschieden.
Konfigurationsupdate Für einen flexiblen Einsatz des TSN ist es sinnvoll, die Konfigurationsdaten
von dem Programmcode zu trennen. Dadurch kann der TSN durch Anpassen
der Konfiguration in verschiedenen Anwendungsgebieten mit unterschiedlichen Umgebungsbedingungen
eingesetzt werden. Außerdem ergibt sich hierdurch die Möglichkeit,
die Konfigurationsdaten und den TSN erst beim Rollout 5 zusammenzuführen.
In der aktuellen Architektur wird die Trennung von Programmtext und Konfiguration bereits
durch die Einführung einer separaten Konfigurationskomponente realisiert. Allerdings sind
die Daten aktuell noch fest in diese Komponente integriert. Eine Separierung innerhalb
dieser Komponente ist noch vorzunehmen. Die Konfigurationsdaten des TSN umfassen
aktuell die folgenden Informationen:
• Kommunikationsschlüssel,
• Tamper-Parameter und
• Netzwerkparameter.
Wie bereits einleitend erwähnt, bietet es sich an, die von außen zugänglichen Kommunikationsverbindungen
für das Update nutzen. Zur Absicherung des Prozesses müssen die
Daten kryptographisch gesichert werden. Hierfür können die Krypto-Module und der K root
des TSN verwendet werden.
5 Rollout bezeichnet den Vorgang des Verteilens des Produktes beim Kunden bzw. der Inbetriebnahme im
Einsatzszenario.
86

Abschlussbericht
Trusted Sensor Node
Programmcode Update Die angestrebte lange Einsatzzeit und die verschiedenen Einsatzszenarien
machen es erforderlich, dass der Programmcode des TSN aktualisierbar
ist. Hierbei muss zwischen einem Remote-Update und einem Update über die DSU unterschieden
werden. Die Absicherung des DSU-Zugriffs wird im Abschnitt 6.2.3 beschrieben
und soll hier nicht weiter betrachtet werden. Beim Remote-Update muss noch einmal zwischen
einem Update des Programmtextes im externen Flash und einem Update der TCB
im internen Flash unterschieden werden.
Das Programmcode Update wird, wie in Abbildung 6.6 dargestellt, in zwei Schritte unterteilt.
Als Ergebnis des ersten Schrittes (Store Data Fragments) wird die neue Firmware
vollständig im externen Flash gesichert abgespeichert. Hierzu werden zunächst die einzelnen
Fragmente der Firmware empfangen, authentifiziert und anschließend entschlüsselt.
Für die Authentifizierung kann K pub
prod 6 verwendet werden. Für die Entschlüsselung wird
ein separater Schlüssel K upd genutzt. Eine genauere Erläuterung zu K upd erfolgt in den
nächsten Absätzen. Da zwischen dem Empfangen der neuen Firmware und dem eigentlichen
Einspielen ein längerer Zeitraum vergehen kann, wird die Firmware zusätzlich mittels
K rand verschlüsselt im externen Flash abgelegt. Bei K rand handelt es sich um einen temporären
Schlüssel, der mittels des Pseudozufallszahlengenerators erzeugt wird und damit
nur dem TSN bekannt ist.
internal
Flash
Signature
Database
Decrypt(K
rand
)
priv
Sign(K )
root
TCB
Code Update
external
Flash
Code Base
Fragmented Update Data
pub
Verify(K prod)
Decrypt(K upd )
Encrypt(K rand)
Store Data Fragments
Update Area
Abbildung 6.6: Kryptographisch gesichertes Programmcode Update
Im zweiten Schritt (Code Update) wird die neue Firmware in den Programmtextspeicher
des TSN übernommen und aktiviert. Hierzu muss die Firmware zunächst mittels K rand
entschlüsselt werden. Anschließend müssen für die neuen Module die Signaturen mittels
des K priv
root berechnet werden. Da die Signaturen im internen Flash abgespeichert werden,
ist hierfür ein vertrauenswürdiger Programmtext notwendig. Aus diesem Grund ist die
Update-Funktion Bestandteil des MVM. Danach kann der neue Programmtext in die Code
Base im externen Flash abgelegt werden.
Der Programmtext muss bei der Übertragung mittels kryptographischer Mechanismen gesichert
werden, so dass ein unautorisiertes Einspielen verhindert werden kann. Als Schlüssel
sollte hier ein separater Update-Schlüssel K upd verwendet werden, da bei der Verwen-
6 Schlüssel des Softwareherstellers.
87

Abschlussbericht
Trusted Sensor Node
dung von K pub
root der Programmtext für jeden TSN einzeln verschlüsselt werden muss. Der
Schlüssel kann Bestandteil der Konfigurationsdaten sein oder zu einem späteren Zeitpunkt
ausgehandelt werden. Für die Authentifizierung des Moduls muss der TSN über den öffentlichen
Schlüssel der externen Update-Quelle K pub
prod
verfügen. Dieser Schlüssel kann
ebenfalls über den Update-Prozess der Konfigurationsdaten aktualisiert werden.
Ein Update des Programmtextes der TCB ist nur mittels der Funktionen aus der TCB möglich.
Hierfür muss eine separate Update-Funktion integriert werden. Die Signatur der Module
kann abhängig vom verwendeten Schlüssel entweder im internen oder im externen
Flash abgelegt werden.
Code Attestation Module
Der Programmtext des TSN wird bei der Initialisierung oder bei einem Update des Systems
im Flash-Speicher abgelegt. In der aktuellen Architektur wird davon ausgegangen, dass
die Daten im Folgenden integer sind. Diese Annahme kann jedoch im realen Betrieb nur
bedingt aufrecht erhalten werden. So können die Daten durch
• Umwelteinflüsse,
• Alterung der Flashzellen und
• bösartige Angriffe auf den TSN
verfälscht und manipuliert werden.
Für einen sicheren Betrieb des TSN ist es zwingend erforderlich, dass die Integrität der
im Flash gespeicherten Daten sichergestellt wird. Zwar wird beim Starten des Knoten die
Integrität der Module überprüft, jedoch wird bei den angestrebten Einsatzszenarien von
einer langen Laufzeit des Knotens ausgegangen. Damit würde die Überprüfung nur in
sehr langen Abständen erfolgen. Zur Erfüllung der an den TSN gestellten Sicherheitsanforderungen
ist eine regelmäßige Überprüfung des Programmtextes in kurzen Abständen
zwingend erforderlich.
Das im Abschnitt 6.1.2 vorgestellte Sicherheitsmodul verhindert unautorisierte Veränderungen
an der TCB. Diese enthält jedoch nur eine kleinen Teil des Programmtextes, der
nur beim Booten des Knotens bzw. beim Update ausgeführt wird. Außerdem werden hiermit
keine Beschädigungen des Programmtextes durch Alterung der Flashzellen erkannt.
Aus diesem Grund wird die Trusted Code Base um ein Code Attestation Module (CAM) erweitert.
Um sicherstellen zu können, dass der Programmcode des TSN vertrauenswürdig
ist und zyklisch überprüft wird und ferner die Überprüfung nicht umgangen werden kann,
besteht das CAM aus zwei Teilen. Der erste Teil nutzt das MVM zur Überprüfung der Module.
Hierbei werden analog zum Secure Boot die Signaturen der Module berechnet und
mit der Signaturdatenbasis im internen Flash verglichen. Stimmen diese nicht überein,
muss davon ausgegangen werden, dass der Programmcode beschädigt oder manipuliert
wurde. In beiden Fällen sind geeignete Sicherheitsmaßnahmen einzuleiten. Der zweite
88

Abschlussbericht
Trusted Sensor Node
Teil des CAM sorgt für eine zyklische Ausführung der MVM-Funktionen. Hierzu wird die
Trap-Behandlung des LEON2 erweitert. Beim Auftreten eines Trap 7 sichert der Prozessor
seinen aktuellen Zustand in einem Register-Window und lädt den Inhalt des Trap Base Register
(TBR) in den Programm Counter. Das TBR wird beim Initialisieren der CPU gesetzt
und zeigt auf die Trap-Handler-Tabelle des Systems. Beim Einsatz des CAM wird das TBR
mit einer Adresse aus der TCB initialisiert und für spätere Zugriffe gesperrt. Schreibende
Zugriffe auf das TBR werden im Folgenden auf ein Schattenregister umgelegt, welches
vom CAM nach der Ausführung der Code Attestation zur Behandlung des Traps genutzt
wird und auf die Trap-Handler-Tabelle des Systems verweist.
Secure Storage
Dieser Abschnitt beschreibt mögliche weiterführende Sicherheitsmechanismen für den
TSN. Hierbei wird insbesondere auf den Schutz der sensiblen Daten eingegangen. In den
vorangegangenen Abschnitten wurde beschrieben, dass eine Sicherung der Konfiguration
und des Programmcodes zwingend erforderlich ist. In beiden Fällen wird eine kryptographische
Sicherung der Daten genutzt. Unter der Annahme, dass die verwendeten Verfahren
sicher sind, wird damit die Gesamtsicherheit des Systems im Wesentlichen auf die sichere
Verwahrung der Schlüssel reduziert.
Die sichere Verwahrung von Schlüsseln in elektronischen Systemen ist ein nicht-triviales
Problem. Zum einen benötigt das System Zugriff auf die Daten und zum anderen sollten
die Daten nicht lesbar verwahrt werden. Im Folgenden werden zwei Mechanismen vorgestellt,
die das Auslesen von sicherheitsrelevanten Informationen erschweren.
Systemcluster Unter einem Systemcluster wird eine Menge von Systemen verstanden,
bei dem die Systeme untereinander über ein Kommunikationsmittel verbunden sind und
gegenseitig Daten austauschen können. In derartigen Clustern, kann das sensitive Material
(z.B. die Schlüssel) verteilt gespeichert werden. Ein System des Clusters benötigt dann
zusätzliche Daten von einem anderen System, um seine sensitiven Daten wiederherstellen
zu können.
Die Verwendung eines Systemclusters hat den Vorteil, dass mehrere Systeme nahezu
gleichzeitig angegriffen werden müssen und, in Fehlerfällen, Redundanzen vorhanden
sind, die eine Selbstheilung des Systems ermöglichen. Der Nachteil besteht darin, dass
die Informationen nicht sofort zur Verfügung stehen, sondern zunächst eine Datenübertragung
zu einem anderen Systemteilnehmer des Clusters notwendig ist.
Autonome Systeme In einem autonomen System müssen alle für den Betrieb notwendigen
Informationen im System selbst gespeichert werden. Hierbei bietet sich wiederum
ein Aufteilen der Informationen an.
7 Unter Trap ist ein Ausnahmezustand zu verstehen, der durch vordefinierte Ereignisse hervorgerufen wird.
89

Abschlussbericht
Trusted Sensor Node
Ein Schlüssel wird nicht als zusammenhängender Datenblock abgelegt, sondern über den
Speicher des Systems verteilt. Zusätzlich muss an dieser Stelle dafür gesorgt werden,
dass die Speicherorte möglichst zufällig gewählt werden und nicht von Dritten vorhergesagt
werden können. Zudem darf es nicht möglich sein, die abgelegten Schlüssel direkt in
einem Speicherauszug zu erkennen. Dies kann durch das Initialisieren des Speichers mit
Zufallswerten verhindert werden.
Gelingt es dem Angreifer den kompletten Speicher des Systems zu kopieren und ist ihm
der Programmcode bekannt, erschweren diese Maßnahmen lediglich ein Kompromittieren
des Systems.
6.1.3 TCP/IP Netzwerk-Stack
In der aktuellen Umsetzung des TSN wird für die Anbindung des Knotens an die Basisstation
der lightweight Internet Protocol (lwIP)-Stack von eCos verwendet. Hierbei handelt es
sich um eine schlanke TCP/IP-Implementierung, die insbesondere für den Einsatz in kleinen
Systemen optimiert wurde. Hierbei wurde der TCP/IP-Stack mit einem Mindestmaß
an Funktionalität umgesetzt.
Der Einsatz eines lwIP hat den Vorteil, dass damit ein sehr kleines standardkonformes System
erstellt werden kann. In diesem Abschnitt beschreiben wir denkbare Erweiterungen für
den lwIP-Stack oder eines alternativen Stacks, um diesen an die aktuellen Anforderungen
an drahtlose Sensornetzwerke anzupassen.
IPv6
Das Internet Protocol Version 4 (IPv4) ist auf einen Adressraum von vier Milliarden Adressen
beschränkt. Aufgrund des stetigen Wachstums des Internets herrscht bereits heute eine
Knappheit der Adressen. Laut aktuellen Schätzungen werden im Jahr 2011 die letzten
IPv4 Adressen aufgebraucht sein [21]. Neben den Problemen, die sich durch den kleinen
Adressraum ergeben, hat IPv4 noch weitere Nachteile, die sich nur durch Erweiterungen
(z.B. IPsec) oder nur eingeschränkt lösen lassen (Mobile IP).
Für viele der Probleme von IPv4 bietet das Nachfolgeprotokoll Internet Protocol Version
6 (IPv6) eine Lösung. Eine detaillierte Beschreibung des Protokolls ist in [13] zu finden.
Die wesentlichen Verbesserungen gegenüber IPv4 lassen sich wie folgt zusammenfassen:
• Vergrößerung des Adressraums von 32 auf 128 Bit,
• zustandslose und automatische Konfiguration von Netzwerkgeräten,
• Mobile IP [24] sowie Vereinfachung von Umnummerierung [8] und Multihoming [9],
• Integration von Sicherheitsmechanismen,
90

Abschlussbericht
Trusted Sensor Node
• verbesserte Unterstützung von Quality of Service und Multicast sowie
• Vereinfachung und Verbesserung des Protokollrahmens (Kopfdaten) 8
Obwohl IPv6 sehr viele Vorteile gegenüber der Vorgängerversion hat, ist die Verbreitung
des Protokolls aktuell noch sehr gering. Nur wenige Standorte im Internet verwenden bereits
diese Version [20]. Dabei kommen oftmals auch Dual-Stack-Systeme 9 und Tunneling-
Mechanismen 10 zum Einsatz. Der zögerliche Einsatz von IPv6 ist oftmals auf die Befürchtung
von Inkompatibilitäten mit bestehenden Systemen zurückzuführen.
Für ein eingebettetes System, wie den TSN, bietet sich der Einsatz von IPv6 an. Die eingesetzte
Netzwerktopologie hat den Vorteil, dass die Sensorknoten zunächst nur über
einen Gateway-Knoten (Basisstation) mit dem Internet kommunizieren. Hierdurch wird das
Sensornetz gekapselt und Tunneling-Mechanismen, wie sie oftmals aktuell bei IPv6 zur
Vermeidung von Inkompatibilitäten eingesetzt werden, lassen sich leicht integrieren. Die
integrierten Sicherheits- und Konfigurationsmechanismen von IPv6 ermöglichen einen flexiblen
Einsatz des TSN in den Szenarien mit hohen Sicherheitsanforderungen und wechselnden
Umweltbedingungen.
Die verwendete Version des lwIP von eCos unterstützt aktuell kein IPv6. Für den Einsatz
von IPv6 auf dem TSN ist dieses Protokoll zu implementieren. Obwohl IPv6 aktuell nur
wenig eingesetzt wird, existieren doch bereits zahlreiche Umsetzungen. Abhängig von den
jeweiligen Lizenzen der Implementierung, deren Größe und Funktionsumfang sollte eine
Implementierung ausgewählt und auf den TSN portiert werden.
eTCP
Das Ziel dieses Abschnittes ist es, kurz zu erläutern, welche Probleme bei der Verwendung
von TCP bei drahtlosen Übertragungsstrecken auftreten und welche Gegenmaßnahmen
getroffen werden können. Darüber hinaus soll geklärt werden, ob eine eventuell proprietäre
eTCP-Lösung integriert werden kann.
TCP Funktionalität Das TCP-Protokoll stellt höheren Schichten eine zuverlässige, verbindungsorientierte
Kommunikation zur Verfügung. TCP selbst setzt jedoch auf dem unzuverlässigen
datenpaketorientierten Protokoll IP auf. Um die oben genannten Eigenschaften
gewährleisten zu können, verwendet das TCP folgenden Mechanismen:
• Drei-Wege-Handshake zum Verbindungsaufbau, 4-Wege-Handshake zum Verbindungsabbau
8 Durch die Unterteilung des Paketkopfes in Basis- und Extension-Header, kann die Paketverarbeitung auf
den Zwischensystemen stark vereinfacht werden. Die Header werden hinsichtlich ihrer Relevanz für die
Zwischensysteme sortiert, so dass nur ein geringerer Teil ausgewertet werden muss.
9 Dual-Stack-System, sind System, die sowohl IPv4- als auch IPv6-Pakete verarbeiten können.
10 Beim Tunneling werden IPv6-Pakete in IPv4-Pakete eingepackt und versendet.
91

Abschlussbericht
Trusted Sensor Node
• Sequenznummern
• Zwischenspeicher, um bei Paketüberholungen die richtige Reihenfolge wieder herstellen
zu können
• Acknowledgements und Timer um die erfolgreiche bzw. nicht erfolgreiche Übertragung
eines Paketes zu signalisieren
• Flusskontrolle zwischen Sender und Empfänger, indiziert durch die Information in
den Acknowledgement Paketen, die anzeigt wie viele Bytes maximal empfangen werden
können
Zusätzlich realisiert TCP einen fairen Umgang mit Netzwerkressourcen. Die Anzahl der
Bytes, die gleichzeitig gesendet werden dürfen, wird im Congestion Window gespeichert
und schrittweise, beim Erhalt positiver Acknowledgements, erhöht (Slow Start). Beim Eintreffen
von „Duplicate Acknowledgements“, die Übertragungsfehler, also Paketverluste indizieren,
wird das Congestion Window jeweils halbiert.
Die Literaturquellen in [10, 50] bieten sehr gute Einführungen in das TCP-Protokoll.
TCP und drahtlose Übertragungskanäle In den vergangenen Jahren wurde die Performanz
von TCP im Bereich drahtloser Netze intensiv untersucht. Der Grund hierfür ist
der signifikante Leistungsverlust des TCP-Protokolls in heterogenen Netzen. Der Durchsatz,
der über eine TCP-Verbindung erreicht werden kann, hängt stark von der Größe des
Congestion Windows 11 ab. Dieses wird bei Paketverlusten immer halbiert, da das TCP
diese Verluste immer als „Congestion“ also als Überlastung des Netzes interpretiert und
aus Fairnessgründen folglich seine eigene Last reduziert. Dies geschieht insbesondere
auch dann, wenn die Pakete auf der drahtlosen Übertragungsstrecke verloren gehen, z.B.
wegen Interferenzen.
Die verfolgten Lösungsansätze lassen sich in die folgenden drei Kategorien einteilen:
1. End-to-End: Die verwendeten Maßnahmen betreffen die Datensenke und die Quelle,
jedoch keine Zwischensysteme. Zum Einsatz kommen beispielsweise „selective acknowledgements“
[23, 17], mit denen der Empfänger anzeigen kann, welche Pakete
korrekt empfangen wurden. Eine andere Möglichkeit ist die „Explicit Loss Notification“
[7], mit der angezeigt werden kann, dass „duplicate acknowledgements“ nicht
durch Congestion sondern durch Paketverluste in der drahtlosen Verbindung verursacht
wurden. Die TCP NEW Reno Variante [19] bleibt zur Verbesserung der TCP-
Performanz im Fast Recovery Mode, falls nach einer Übertragungswiederholung das
letzte korrekt empfangene Byte kleiner ist als das letzte gesendete. Hierdurch kann
TCP NEW Reno einen Paketverlust pro Round Trip Time kompensieren.
2. Split Connection: Hier werden Übertragungswiederholungen z.B. von der Basisstation
durchgeführt, wenn diese die Pakete erhalten hat, die Pakete aber bei der Über-
11 Das Congestion Window ist ein Hilfsmittel zur Vermeidung von Überlast im Netzwerk.
92

Abschlussbericht
Trusted Sensor Node
tragung über den drahtlosen Kanal verloren gegangen sind. Hierfür müssen die „duplicate
acknowledgements“ aus dem Datenstrom gefiltert werden [6].
3. Link Layer: Diese Ansätze versuchen die TCP-Verbindungen völlig von der schlechten
Übertragungsqualität auf dem drahtlosen Netzwerk zu entkoppeln (vgl. [28]).
Hierfür werden Mechanismen wie Fragmentierung der TCP-Pakete, Erhöhung der
Übertragungswiederholungen im MAC-Layer o.ä. verwendet.
Abbildung 6.7 illustriert die hier skizzierten Ansätze. Dabei ist in allen Teilbildern links eine
mobile Gegenstelle, mittig der Proxy zwischen mobilem Gerät und Internet und rechts die
Basisstation dargestellt.
Die Anwendbarkeit der Lösungsansätze hängt stark davon ab, ob alle an der Kommunikation
beteiligten Geräte durch eine Instanz verwaltet werden. Nur dann sind Ansätze wie
End-to-End bzw. Split-Connection überhaupt realisierbar. Trotzdem bleibt bei diesen Ansätzen
der erhöhte Aufwand für die Adaption der TCP-Implementierungen bzw. der Zwischensysteme
zu beachten. Die Veränderung des Link Layers, z.B. durch Erhöhen der
Anzahl der Übertragungswiederholungen kann auf dem TSN-Knoten umgesetzt werden,
ohne dass andere Systeme verändert werden müssten. Die in [28] veröffentlichten Untersuchungen
haben gezeigt, dass die Anzahl der über den drahtlosen Kanal übertragenen
Bytes unabhängig von der Anzahl der Übertragungswiederholungen im MAC ist (vgl. Abbildung
6.8). Hieraus kann man schließen, dass das Auslösen der Übertragungswiederholung
durch den MAC sehr viel effizienter ist, als eine entsprechende Reaktion im TCP.
Dieses resultiert aus der Tatsache, dass weniger Header bearbeitet werden müssen. Auch
eine Fragmentierung der TCP-Pakete auf MAC-Ebene ist, wegen der geringeren Headerinformationen
deutlich effizienter als eine Fragmentierung auf TCP-Ebene (siehe Abbildung
6.9).
TSN und TCP Der voraussichtliche Einsatz des TSN als lokale Senke innerhalb eines
drahtlosen Sensornetzes und als Bridge zu einem Einsatzzentrum hat einen deutlichen
Einfluss auf die zu erwartenden Informationsflüsse, gerade weil TCP nur im Rahmen
der Bridge-Funktionalität verwendet wird. Bei einem derartigen Netzwerkaufbau wird der
Nachrichtenaustausch eher vom TSN zum Einsatzzentrum fließen, da in dieser Richtung,
die erkannten Ereignisse zur Auswertung/Reaktion verbreitet werden müssen. Da aktuell
keine Aktorik im Netzwerk vorhanden ist, werden in der Rückrichtung selten Daten fließen.
Der Informationsfluss vom Einsatzzentrum zum TSN wird wahrscheinlich ausschließlich
aus kurzen Konfigurationsnachrichten, mit denen Parameter verändert werden, bestehen.
Bei dem hier vorliegenden Nachrichtenaustausch können die vom TCP ausgelösten Performanzprobleme
vernachlässigt werden. Diese resultieren aus der Verringerung des Congestion
Windows beim Eintreten von Übertragungsfehlern. Hierdurch wird der Durchsatz
deutlich verringert. Da im TSN-Szenario nur geringe Datenmengen ausgetauscht werden,
ist der maximale Datendurchsatz von geringer Bedeutung. Interessanter erscheint hier die
Verzögerungszeit, die durch die Paketverluste ausgelöst wird. Um diese klein zu halten,
sind wahrscheinlich Link-Layer-Ansätze zu bevorzugen. Eventuell wäre ein proprietäres
verbindungsorientiertes Transportprotokoll dem TCP vorzuziehen, falls sehr kurze Verzö-
93

Abschlussbericht
Trusted Sensor Node
Abbildung 6.7: Kategorisierung der Ansätze zur Verbesserung der TCP-Performanz
in heterogenen Netzwerken
94

Abschlussbericht
Trusted Sensor Node
Abbildung 6.8: Anzahl der in den drahtlosen Kanal gesendeten Bytes in
Abhängigkeit von der Anzahl der Übertragungswiederholungen im
MAC und der Bitfehlerrate (BER)
gerungszeiten erreicht werden sollen. Damit ließe sich der relativ komplexe Verbindungsaufbau
des TCP-Protokolls vermeiden.
6.2 Optimiertes Hardwarekonzept
In diesem Abschnitt werden die Möglichkeiten diskutiert, das Hardwarekonzept des TSN
zu verbessern. Die Veränderungen sollen die Systemleistung, die benötigte Fläche, die
Programmierung, die Sicherheit und den Energiebedarf des Knoten verbessern. Die Veränderungen
beziehen sich darauf, vorhandene Komponenten zu verändern oder neue
Komponenten hinzuzufügen.
Zu Beginn des Abschnittes wird eine neue Komponente (Reset-Controller) sowie das Konzept
des Clock-Gating und des Power-Gating vorgestellt. Im Anschluss werden mögliche
Veränderungen an den bereits vorhandenen Komponenten AES, SHA1/PRNG, ECC,
SPI, Speicheranbindung und LEON2-Registerfile diskutiert. Der letzte Abschnitt beschäftigt
sich mit dem Schutzkonzept des TSN. In diesem werden Möglichkeiten aufgezeigt, die
Sicherheit des Systems zu verbessern.
95

Abschlussbericht
Trusted Sensor Node
Abbildung 6.9: Datenrate in Abhängigkeit von der Paketgröße auf MAC bzw. TCP
Ebene, und der Bitfehlerrate (BER)
6.2.1 Einfügen neuer Komponenten
In diesem Abschnitt werden Komponenten vorgestellt, die zu dem bisherigen Entwurf hinzugefügt
werden sollen. Eine davon verbessert die Stabilität (Reset-Controller) des Sensorknotens.
Mit der Einführung des Clock-Gatings und eventuell des Power-Gatings verringert
man den Energiebedarf des Systems.
Reset-Controller
Der TSN kann bisher nur im Ganzen über ein globales Reset-Signal neu gestartet werden.
Nach diesem Reset ist eine Initialisierung aller Teilkomponenten des Systems nötig. Dies
verbraucht zusätzliche Ressourcen wie Energie und Zeit.
Im normalen Betrieb kann es aus Gründen der Betriebssicherheit oder zum Schutz von
Daten notwendig werden, einzelne Teile des Systems neu zu starten. Detektiert ein Sensor
einen möglichen Angriff, so kann die Software dafür sorgen, dass z.B. die Kryptokomponenten
zurückgesetzt werden und dadurch keine sensiblen Daten mehr im Speicher
enthalten sind. Um dies realisieren zu können, soll ein Reset-Controller in das System
eingefügt werden. Mit diesem können, durch Software gesteuert, Bits gesetzt werden, die
dann ein Reset einzelner Komponenten auslösen.
Der Reset-Controller kann als Register, dessen einzelne Bit-Stellen mit den Reset-Signalen
der verschiedenen Komponenten verbunden sind, an den Memory-Controller angeschlossen
werden. Das Register kann beschrieben und gelesen werden. Es wird an allen Bit-
Positionen mit „1“ initialisiert, da die Reset-Signale LOW-aktiv sind. Schreibt man an eine
96

Abschlussbericht
Trusted Sensor Node
Position eine „0“, wird die entsprechende Komponente neu gestartet und im Anschluss das
Bit im Reset-Controller wieder auf „1“ gesetzt.
Der Controller sollte als Memory-Mapped-I/O Komponente, analog zu den kryptografischen
Modulen, in das System integriert werden. Dadurch kann das Lesen und Schreiben
des Controllers durch einfache Speicherzugriffe realisiert werden.
Einführen von Clock-Gating
Der TSN verwendet in der aktuellen Version kein Clock-Gating, so dass das Clock-Signal
stets zu jeder Zeit zu jeder Komponente weitergeleitet wird. Das Clock-Gating wird dazu
benutzt, den Systemtakt an den Registern der Schaltung zu unterbrechen, um somit das
interne Schalten der Flipflops zu verhindern und Energie zu sparen. Dieses Unterbrechen
wird immer dann eingesetzt, wenn der aktuelle Zustand des Systems den Zugriff auf die
Register nicht zulässt.
Abbildung 6.10: Clockgating-Controller bestehend aus Latch und OR-Gatter
Durch dieses Verfahren kann, wie bereits erwähnt, der Energieverbrauch des Systems gesenkt
werden. Der Flächenbedarf vergrößert sich durch die zusätzliche Steuerlogik nicht
wesentlich. Durch die Verwendung der Clock-Gating-Logik können andere Schaltungselemente,
wie z.B. einige Multiplexer, verkleinert werden oder entfallen. Dadurch fällt der
Hardwareoverhead nicht ins Gewicht. Das Syntheseprogramm 12 erkennt selbständig, welche
Register gerade angesprochen werden können und welche nicht. Die Abbildung 6.10
zeigt den Aufbau eines Clock-Gating-Elements. Am Eingang liegen die Systemclock sowie
das „Clock Enable“ an, welches den Ausgang aktiviert, so dass das Signal der Systemclock
an die angeschlossene Komponente weiter geleitet wird.
Als Beispiel kann eine Finite State Machine (FSM) dienen (vgl. Abbildung 6.11). Diese hat
mehrere Zustände mit „Reset“ als Startzustand. Danach geht die FSM in den Zustand „Register
0“ über. In diesem Zustand kann ausschließlich das Register 0 geschrieben werden.
Ein Zugriff auf Register 1 bis 3 ist nicht möglich. Im aktuellen Zustand wartet die FSM nun
auf ein Ereignis auf dem Clocksignal, in der Regel eine steigende Flanke, sowie darauf,
dass das Signal „WENB“ („Write ENaBle“) den Wert „0“ annimmt. Dabei wird der Wert
am Dateneingang in das Register 0 übernommen. In einem herkömmlichen Design wird
das Clocksignal stets an alle Register (0 bis 3) weitergeleitet, ohne dass Vorbedingungen
eine Rolle spielen. Im hier gezeigten Beispiel ist sichtbar, dass die Register 1 bis 3 kein
12 Ein Programm zur Erzeugung der Gatternetzliste aus dem VHDL-Code.
97

Abschlussbericht
Trusted Sensor Node
Clocksignal brauchen, wenn sich die FSM im Zustand „Register 0“ befindet, da die Register
1 bis 3 den Wert am Eingang nicht übernehmen können. Das Synthesetool analysiert
eine solche FSM und erkennt selbständig die Vorbedingungen, die erfüllt sein müssen,
damit die Register den am Eingang liegenden Wert übernehmen. Für den Fall, dass die
Vorbedingung nicht erfüllt wird, wird das Clocksignal nicht an das Register weitergeleitet,
sondern bleibt auf „0“.
Abbildung 6.11: Finite-State-Machine mit 5 Zuständen
Einführen von Power-Gating
Power-Gating bezeichnet eine Technologie bei der mit Hilfe von Leistungstransistoren einzelne
Hardwarekomponenten von der Energieversorgung abgetrennt werden können. Die
Verwendung des Power-Gatings soll den Energieverlust durch Leckströme reduzieren. In
den typischen Einsatzszenarien von drahtlosen Sensornetzen sind viele Komponenten für
lange Zeit inaktiv. In der inaktiven Phase, wird auf Grund der Leckströme, Energie verschwendet.
Die Größe der Leckströme nimmt mit Abnahme der Strukturgrößen zu (vgl.
Abbildung 6.12).
Abbildung 6.12: Zunahme der Leckströme bei Verkleinerung der Strukturgröße[1]
98

Abschlussbericht
Trusted Sensor Node
Das IHP fertigt zur Zeit Halbleiter mit einer Strukturgröße von 0, 25µm. Bei dieser Technologie
entfallen ca. 10% des Energieverbrauchs auf die Leckströme. Darüber hinaus werden
am IHP Versuche unternommen, die Strukturgröße auf 0, 13µm zu verringern. Bei dieser
Technologie entfallen dann bereits 25% des Energieverbrauchs auf die Leckströme (vgl.
Abbildung 6.12). Diese beiden Werte zeigen, wie wichtig es ist, Leckströme im Bereich der
eingebetteten Low-Power Systeme zu verringern.
Um mit Hilfe von Power-Gates die Leckströme zu reduzieren, werden sie in die Energieversorgung
der abzuschaltenden Teilblöcke eingebunden. Sie müssen die Hardware
von der Versorgungsspannung und Masse trennen. Das An- und Abschalten der Power-
Gates übernimmt ein Power-Gating-Controller. Dieser enthält einen eingebauten Timer,
der nach Ablauf einer Zeitspanne die abgeschaltete Komponente automatisch reaktiviert.
Das Schalten kann ebenso durch einen externen Interrupt veranlasst werden (vgl. Abbildung
6.13). In Abbildung 6.14 ist der Aufbau der eben beschriebenen Power-Gating
Architektur dargestellt.
Abbildung 6.13: Darstellung eines Power-Gating-Controllers
Abbildung 6.14 zeigt einen abschaltbaren Logikblock (Power-Gated Functional Block). Dieser
kann über die Transistoren von der Versorgungsspannung und von der Masseleitung
getrennt werden. Gesteuert wird dieser Schalter durch den Power-Gating-Controller. Dessen
Aufbau ist in Abbildung 6.13 dargestellt.
Abbildung 6.14: Darstellung einer Power-Gating Architektur
Trennt man eine Komponente von der Energieversorgung verliert sie alle Daten der internen
Register. Sind diese wichtig und werden nach dem Zuschalten wieder benötigt,
99

Abschlussbericht
Trusted Sensor Node
müssen sie vor dem Abschalten gesichert werden. Dazu gibt es von allen wichtigen Registern
ein Duplikat, das als nicht-flüchtiger Speicher ausgelegt ist. In diesem werden die
wichtigen Inhalte gerettet und später wieder ausgelesen. Im TSN könnten damit alle Kryptokomponenten
abgeschaltet werden. Zu beachten ist hierbei, dass Register, die Schlüssel
enthalten, auf sichere Art 13 zwischengespeichert werden müssen. Darüber hinaus kann
die DSU abgeschaltet werden, da diese nur zur Inbetriebnahme des TSN notwendig ist.
6.2.2 Veränderungen an vorhandenen Komponenten
In diesem Abschnitt werden Veränderungen an Komponenten zur Minimierung des Flächenund
Energiebedarfs sowie zur Erhöhung der Performanz diskutiert. Die Veränderungen
beziehen sich dabei in erster Linie auf die kryptografischen Komponenten AES, SHA1 und
ECC. Weiterhin werden Verbesserungen am LEON2-Prozessor vorgestellt.
In der aktuellen Implementierung belegt der TSN ca. 35mm 2 Siliziumfläche. Zwar ist der
Prozessor sehr leistungsfähig, dennoch erscheint die Fläche recht groß. In Anbetracht der
hohen Kosten pro Quadratmillimeter sollte angestrebt werden, die Fläche, ohne Einbußen
an der Funktionsweise, zu verkleinern.
Optimierung des AES
Die AES-Komponente kann auf verschiedene Weise verbessert werden. Als erstes kann
die Fläche reduziert werden, indem bei den Datenregistern auf den Reseteingang verzichtet
wird. Der initiale Wert der Datenregister ist nach einem Neustart des TSN nicht von
Bedeutung. Neben dem Einsatz von kleineren Flipflops ohne Reset kann der Resetpfad
dementsprechend kleiner ausgeführt werden. Einige Treiberbausteine können entfallen.
Memory Controller
SHA1
PRNG
AES
ECC
RAM
Abbildung 6.15: Veränderte Anbindung der kryptografischen Komponenten
zwischen Memory-Controller und Speicher
13 Das bedeutet, dass ein Zugriff durch Dritte nicht möglich ist.
100

Abschlussbericht
Trusted Sensor Node
Um weitere Fläche einzusparen, könnte bei der AES-Komponente ein Teil der Adresslogik
entfernt werden. Bisher werden die Blöcke der zu verarbeitenden Nachricht in verschiedene
Register geschrieben, die alle separat adressiert werden. Man kann die einzelnen
Blöcke alle an eine Adresse schreiben und diese intern an die richtige Position des Registers
legen. Der Nachteil dieser Methode ist, dass der Programmcode schlechter lesbar ist
(vgl. Listings 6.1 und 6.2).
...
//AES write data word
//write(Adress, value);
//AES first word
write_reg(0x20100000, 0x01234567);
//AES second word
write_reg(0x20100004, 0x89abcdef);
//AES third word
write_reg(0x20100008, 0xabbeabbe);
//AES second word
write_reg(0x2010000A, 0xc0dec0de);
Listing 6.1: Schreibbefehl für die Verschlüsselung von Daten mit expliziten
Adressen
...
//AES write data word
//write(Adress, value);
//AES first word
write_reg(0x20100000, 0x01234567);
//AES second word
write_reg(0x20100000, 0x89abcdef);
//AES third word
write_reg(0x20100000, 0xabbeabbe);
//AES second word
write_reg(0x20100000, 0xc0dec0de);
Listing 6.2: Schreibbefehl für die Verschlüsselung von Daten auf eine Adresse
Optimierung des SHA1/PRNG
Das SHA1/PRNG Modul wird verwendet, um den Hashwert über Daten zu bilden und um
pseudozufällige Zahlen zu erzeugen. Möchte man Daten des TSN übertragen, geschieht
dies über UART. Diese sind mit Radiomodulen oder seriellen Übertragungsleitungen verbunden.
In der Regel werden Daten vor dem Senden signiert oder deren Signatur nach
dem Empfang überprüft.
101

Abschlussbericht
Trusted Sensor Node
In [41] wurde ein TCP-System evaluiert. Dabei wurde festgestellt, dass einfache Kopieroperationen
einen Großteil der Systemlast ausmachen. Daher bietet es sich bei kopierintensiven
Anwendungen an, diese zu optimieren, so dass die Anzahl an Kopieroperationen
minimiert wird. Es wird versucht, die Daten mit einer einzigen Kopieroperation allen notwendigen
Komponenten zur Verfügung zu stellen. Eine solche Vorgehensweise wird als
„Single Copy Architecture“ bezeichnet.
Am Beispiel des Sendens von Daten, über die der Hashwert gebildet wird, soll der bisherige
Ablauf kurz erläutert und die Optimierung vorgestellt werden.
Der LEON2-Prozessor lädt die Daten aus dem Speicher und überträgt diese anschließend
an das SHA1/PRNG Modul. Nach der Erzeugung des Hashwertes, wird dieser vom Prozessor
ausgelesen und mit den Daten an einen der UARTs zur Übertragung gesendet.
Die Überprüfung eines Hashwertes erfolgt analog. Die empfangenen Daten werden durch
den Prozessor von einem der UARTs gelesen. Anschließend werden die Daten in das
SHA1/PRNG Modul geschrieben und der Hashwert ermittelt. Diese wird mit dem empfangenen
Hash verglichen.
Eine Optimierung kann erreicht werden, indem die SHA1/PRNG Komponente direkt an
den Speicherbus angebunden wird (vgl. Abbildung 6.15). Dadurch vereinfacht sich das
Senden und Empfangen „gehashter“ Daten erheblich. Der LEON2 lädt die Daten aus dem
Speicher und überträgt sie an den UART. Dabei wird von den Daten der Hashwert durch
den SHA-1 berechnet, da dieser permanent auf dem Speicherbus lauscht. Im Anschluss
an die Kopieroperation (von Speicher nach UART) kann der Hashwert aus dem SHA1
ausgelesen und ebenfalls übertragen werden. Beim Empfang gelangen die Daten beim
Auslesen durch den Prozessor, über den Speicherbus, in das SHA1-Modul. In diesem wird
direkt der Hashwert berechnet und kann anschließend mit dem empfangenen Hashwert
verglichen werden.
Durch diese Verlagerung des SHA1/PRNG Moduls kann die Systemlast 14 verringert und
somit Energie gespart werden.
Für eine weitere Optimierung kann auch hier die Adresslogik vereinfacht werden. Dies
wurde bereits beim AES-Modul (vgl. 6.2.2) diskutiert. Das SHA1/PRNG-Modul erhält einen
512-Bit langen Datenblock, der in sechzehn 32-Bit Teilblöcke unterteilt ist. Diese sind alle
einzeln adressierbar und können separat ausgelesen und geschrieben werden. An dieser
Stelle kann die Adressierung auf nur einen Teilblock reduziert werden. Die in diesen
Teilblock geschriebenen Daten werden bei jedem Schreibzugriff einen Teilblock weitergeschoben.
Das Auslesen erfolgt analog. Somit gelangen alle Daten in die vorgesehenen
Register.
Der 160-Bit Hashwert des Algorithmus ist ebenfalls in 32-Bit Teilblöcke gegliedert. Diese
sind zudem einzeln adressierbar. Auch hier reicht die Adressierung eines Teilblocks, um
die Daten lesen und schreiben zu können. Durch diese Veränderung kann die Adresslogik
minimiert werden. Zur Zeit werden einundzwanzig 32-Bit Register und ein 8-Bit Kontrollregister
adressiert. Bei einer Optimierung würde sich die Adresslogik nur noch auf drei
14 Belastung des Prozessors und des Speichers
102

Abschlussbericht
Trusted Sensor Node
Register beschränken. Der Nachteil hierbei ist, genau wie beim AES, dass die entsprechende
Software unübersichtlich und schlechter lesbar wird (vgl. Listing 6.1 und 6.2).
Optimierung des ECC
Das ECC-Modul unterstützt die Berechnung von Punktmultiplikationen auf elliptischen Kurven
über erweiterten Binärfeldern (GF(2 m )). Die elliptische Kurve wird, gemäß dem NIST-
Standard, über alle Punkte definiert, die die Gleichung
y 2 + xy = x 3 + x 2 + b
erfüllen. Auf dieser elliptische Kurve werden die kryptographischen Operationen ausgeführt.
Das ECC-Modul bietet ebenfalls verschiedene Optimierungsansätze. Bisher ist es
notwendig, vor der Durchführung einer Punktmultiplikation, den Kurvenparameter b zu
schreiben, da dieser in Registern gehalten wird. Der ECC wird nur auf einer Kurve durchgeführt,
die durch den Kurvenparameter b beschrieben wird. Der Parameter ist konstant
und muss nicht verändert werden. Damit können diese Register entfallen und der Kurvenparameter
b „festverdrahtet“ werden. Dies spart Fläche und Energie.
Der ECC besitzt intern eine Quadriereinheit. Diese spezialisierte Einheit führt eine Quadrierung
in nur einem Taktzyklus durch. Um Fläche einzusparen, könnte man diese entfernen
und die Multiplikationseinheit des LEON2-Prozessors verwenden. Eine andere Möglichkeit
wäre, den Quadrierer durch einen kleineren langsameren Multiplizierer zu ersetzen.
Beide Varianten würden Fläche sparen, aber auf Kosten der Geschwindigkeit des Algorithmus
gehen und werden daher nicht umgesetzt. Denn ein Multiplizierer benötigt mehr
Taktzyklen als eine spezialisierte Quadrierereinheit, um die gleiche Berechnung auszuführen.
Eine weitere Möglichkeit, Fläche und Energieverbrauch zu optimieren, ist die Größe des
internen Multiplizierers anzupassen. In den Arbeiten ([45], [40]) werden verschiedene Multiplizierervarianten
für das ECC Modul verglichen. Diese Gegenüberstellung ist auszugsweise
in Tabelle 6.1 zusammengefasst. Die erste Spalte zeigt die Größe der Faktoren in
Bit, die zweite zeigt die Anzahl der Segmente, in welche die Faktoren zerlegt werden.
Die Anzahl der benötigten Takte für die Multiplikation ist in Spalte drei zu finden. Spalten
vier und fünf zeigen die benötigte Fläche und den Energieverbrauch für den Multiplizierer.
Letzterer wurde für eine Frequenz von 33 MHz simuliert und berücksichtigt nicht den
Ruhestrom der Schaltung.
Die momentan im TSN verwendete ECC Komponente enthält einen für 233-Bit Faktoren
ausgelegten 4-Segment-Multiplizierer. Dieser ist in Tabelle 6.1 mit einem * gekennzeichnet.
Die Größe des Multiplizierers ist in erster Linie von der Bitbreite der Faktoren abhängig,
wie man in Tabelle 6.1 gut erkennen kann. Bei einer Erhöhung der Anzahl an Segmenten
nimmt die Fläche des Multiplizierers ab und der Energieverbrauch zu. Bei einer Segmentierung
der Multiplikation wird diese in mehrere kleinere Multiplikationen aufgeteilt. Dadurch
müssen mehrere Teilmultiplikationen durchgeführt werden, wodurch die Anzahl der benötigten
Takte und der Energieverbrauch zunimmt.
103

Abschlussbericht
Trusted Sensor Node
Tabelle 6.1: Vergleich verschiedener Multiplizierer für Punktmultiplikation der ECC
Komponente
Größe der Faktoren in Bit Segmente Takte Fläche in mm 2 Energieverbrauch in nW s
163 2 3 0,79 4,31
163 4 9 0,45 8,53
163 8 27 0,35 14,99
233 2 3 1,17 5,80
233* 4 9 0,62 11,58
233 8 27 0,44 18,47
571 2 3 4,35 25,00
571 4 9 2,10 38,30
571 8 27 1,31 67,14
Am Beispiel des 233-Bit Multiplizierers soll dies kurz genauer erläutert werden. Der 2-
Segment-Multiplizierer benötigt drei Takte für die Multiplikation. Er belegt dabei eine Fläche
von 1, 17mm 2 und verbraucht 5, 80nW s. Verdoppelt man die Anzahl der Segmente
auf vier, verringert sich die benötigte Fläche um 0, 55mm 2 (47%). Der Energieverbrauch
verdoppelt sich auf 11, 58nW s. Die Operation benötigt dann neun Takte. Unterteilt man
die Multiplikation in acht Segmente, benötigt diese 27 Takte. Der Flächenbedarf verringert
sich, im Vergleich zur 4-Segment-Version um 29% auf 0, 44mm 2 . Der Energieverbrauch
erhöht sich um fast 7nW s auf 18, 47nW s. Daran kann man erkennen, dass entweder die
Fläche oder der Energieverbrauch im Vergleich zum bisher eingesetzten Multiplizierer verbessert
werden können. Der im TSN verwendete ECC besitzt jedoch bereits das beste
Verhältnis zwischen Fläche, Energieverbrauch und Verarbeitungsgeschwindigkeit.
Optimierung des SPI
Die derzeit verwendete SPI-Komponente ist mit einer Fläche von 173.000µm 2 recht groß.
Dies liegt darin begründet, dass es sich hierbei um eine Standardbibliothekskomponente
handelt, die in weiten Teilen konfigurierbar ist. Diese Konfigurierbarkeit wird hier im wesentlichen
nicht benötigt, so dass eine Eigenentwicklung deutliche Einsparung in der Fläche
bringen kann.
Optimierung der Clock-Select-Komponente
Der LEON2-Prozessor ist mit einer Clock-Select-Komponente ausgestattet. Mit dieser ist
es möglich, den Prozessor über verschiedene Quellen mit einem Takt zu versorgen und
zwischen diesen umzuschalten. Der „Trusted Sensor Node“ verwendet jedoch nur einen
Takt. Somit kann die Clock-Select-Komponente entfallen. Hierdurch reduziert sich die benötigte
Fläche an Silizium im geringen Umfang weiter.
104

Abschlussbericht
Trusted Sensor Node
Realisierung des Registerfiles durch Speicher
Das Registerfile 15 des LEON2-Prozessors besteht aus 8 Fenstern je 17 Register á 32 Bit.
Jedes dieser enthält ein globales Register sowie 16 Register, die spezifisch dem einzelnen
Fenster zugeordnet ist. Die 8 Fenster bilden einen zirkularen Stack (Details siehe [49]). Im
„Trusted Sensor Node“ sind die Register durch insgesamt 4352 Flipflops realisiert. Diese
haben einen hohen Energiebedarf. Darüber hinaus belegt das Registerfile eine Fläche
von 3,1mm 2 . Man kann dieses Registerfile durch Static Random Access Memory (SRAM)
ersetzen. Dieser ist kleiner und sparsamer als die Lösung mit Flipflops. Aus Sicht der Arbeitsgeschwindigkeit
sind beide Versionen gleich schnell. Zur Umsetzung wird ein speziell
angepasster Speicher (Triple-Port Memory) benötigt. Die Größe des RAMs lässt sich im
Vorfeld schwer abschätzen, dürfte jedoch bei weniger als 1,5mm 2 liegen.
6.2.3 Schutzkonzept
Gehäuse und Platine
Einfache physikalische Angriffe können verhindert werden, indem Schutzmaßnahmen ergriffen
werden, so dass Datensignale nicht direkt auf der Platine abgreifbar sind. Beispielsweise
können alle Signalleitungen in einer Multilayer-Platine innerhalb der inneren
Schichten geführt werden. Dabei ist es sinnvoll alle Chips (LEON2, Flash, RAM) in BGA-
Ausführung zu verwenden. Alle Pins sind als Lötpunkte unterhalb des ASICs ausgeführt,
so dass einfache Messungen an den Pins der Chips nicht möglich sind (vgl. Abbildung
6.16).
15 Blockweise angeordnete Prozessorregister
Abbildung 6.16: BGA-Gehäuse (Unterseite)
105

Abschlussbericht
Trusted Sensor Node
BGA-Gehäuse sind noch an anderer Stelle von Vorteil: ein Standardgehäuse (wie z.B. das
derzeit verwendete PQFP-128) enthält lediglich den Chip mit den Bonddrähten (vgl. Abbildung
6.17). Ein BGA-Gehäuse, wie in Abbildung 6.19 dargestellt, ist eine Platine auf die
der Chip gebondet wurde (vgl. Abbildung 6.18). Nach dem Aufbringen des Chips auf die
kleine Trägerplatine, kann dieser mit einer Epoxydmasse vergossen werden (vgl. Abbildung
6.20). Um einfachen Angriffen mit Hilfe einer Power-Analysis-Attacke vorzubeugen,
kann es sinnvoll sein, auf der Trägerplatine Kondensatoren unterzubringen (vgl. Abbildung
6.20) und diese ebenfalls mit zu vergießen. Je mehr und je größere Kondensatoren dafür
verwendet werden, desto schwieriger ist es für einen Angreifer die Leistungsaufnahme
des Chips in jedem einzelnen Clocktakt eindeutig zu identifizieren. Vielmehr wird die Leistungsaufnahme
über mehrere Clocktakte „verschmiert“.
Wie in Abbildung 6.18 ersichtlich, können auch mehrere ASICs auf einer Trägerplatine
aufgebracht werden. Nach außen hin erscheint dieses als ein Komplettsystem.
Abbildung 6.17: TSN in einem offenen PQFP-128-Gehäuse
Authentifizierungskomponente
Die Authentifizierungskomponente soll den TSN vor unberechtigten Zugriffen schützen.
Dabei stellt die „Debug Support Unit“ (DSU) eine besondere Schwachstelle im System
dar. Über sie erhält man vollständigen Zugriff auf alle wichtigen Inhalte des Sensorknotens.
Mit Hilfe von Unterbrechungspunkten und anderen Debugmöglichkeiten kann das
System umfangreich untersucht und manipuliert werden. Auf den Schutz dieser seriellen
Schnittstelle sollte besonders geachtet werden.
Ein weiteres Angriffsszenario stellt das unberechtigte Bewegen des Knotens, durch zum
Beispiel Aufheben, dar. Im Falle einer unzulässigen Bewegung des TSN, die über den
Beschleunigungssensor festgestellt wird, sollen sensible Daten gelöscht und das Arbeiten
mit dem Knoten verhindert werden. Bei diesem Szenario ist es schwer, zwischen einem
berechtigten und einem unberechtigten Bewegen des Knotens zu unterscheiden. Es kann
durchaus nötig sein, dass aus Gründen eines veränderten Szenarios oder aufgrund von
106

Abschlussbericht
Trusted Sensor Node
Abbildung 6.18: Trägerplatine mit aufgebondeten ASICs
Abbildung 6.19: Chip in einem BGA-Gehäuse
107

Abschlussbericht
Trusted Sensor Node
Abbildung 6.20: Trägerplatine mit teilweise vergossenen Kondensatoren
Wartungsarbeiten, der TSN bewegt werden muss. Dabei sollten sensible Daten natürlich
erhalten bleiben.
Zur Unterscheidung, ob das Bewegen des Knotens berechtigt oder unberechtigt durchgeführt,
wird ein Autorisierungsmechanismus eingeführt. Dieser ist in Abb. 6.22 beschrieben
und findet kontaktlos statt, so dass der Knoten dazu nicht bewegt werden braucht. Nach
erfolgreicher Autorisierung, findet eine Authentifizierung statt (siehe Abb. 6.23). Erst wenn
diese erfolgreich abgeschlossen wurde, ist der Zugang zur der Programmierschnittstelle
freigegeben.
Die im Folgenden vorgestellte Komponente besitzt die Möglichkeit, zwischen berechtigtem
und unberechtigtem Zugriff zu unterscheiden und gegebenenfalls Schutzmaßnahmen zu
aktivieren.
Abbildung 6.21: Anbindung der Authentifizierungskomponente in den TSN
108

Abschlussbericht
Trusted Sensor Node
Die Authentifizierungskomponente wird zwischen die „Debug Support Unit“ und der Programmierschnittstelle
eingebunden (vgl. Abbildung 6.21). Sie sperrt die Pins solange bis
eine erfolgreiche Authentifizierung erfolgt ist. Um eine mögliche Deaktivierung oder Überbrückung
zu verhindern, muss sie unbedingt in den TSN Chip integriert sein. Sie kann
weiterhin bestimmte Schutzmechanismen, wie zum Beispiel das Sperren des Systems,
das Löschen von Schlüsseln oder sensibler Software veranlassen, wenn eine Authentifizierung
mehrfach fehlgeschlagen ist. Eine Alarmmeldung sollte in diesem Fall ebenfalls
gesendet werden.
Zur Authentifizierung kann der ECC und das SHA1/PRNG-Modul des Systems verwendet
werden um ein „Challenge-Response-Protokoll“ zu realisieren. Der Nutzer, der auf
die Programmierschnittstelle des TSN zugreifen möchte, teilt seinen Zugriffswunsch durch
das Senden seiner Identifikationsnummer (UserID) der Authentifizierungskomponente mit
(vgl. Abbildung 6.22). Danach erhält er vom TSN eine Zufallszahl(PRN) und signiert diese
mit Hilfe seines privaten Schlüssels (KeyUsrPriv) und sendet das Paket an die Authentifizierungskomponente
des TSN zurück. Der TSN prüft die Signatur mit dem öffentlichen
Schlüssel des Nutzers (KeyUsrPubl) und anschließend die Daten. Ist das Ergebnis korrekt,
so kann der TSN davon ausgehen, dass kein Dritter die Identifikationsnummer missbräuchlich
verwendet hat. Die Signierung ist notwendig, um einer Man-in-the-Middle Attacke vorzubeugen.
Die Authentifizierungskomponente besitzt also den öffentlichen Schlüssel des
Nutzers, wenn dieser autorisiert ist, auf das System zuzugreifen. Dieser liegt, z.B. mit der
zugehörigen Identifikationsnummer des Nutzers, im internen Flash.
msc User authorization
User
TSN
UserID
UserID valid
PRN
Generate PRN
Sign PRN with KeyUsrPriv
(PRN)KeyUsrPriv
Check signature
with KeyUsrPubl
and check PRN
PRN valid
Authentication protocol
Abbildung 6.22: Authentifizierung des Nutzers am TSN, um Man-In-The-Middle
Attacken zu vermeiden
Im Anschluss wird der Authentifizierungstimer gestartet (vgl. Abbildung 6.23). Vor dessen
Ablauf muss das Authentifizierungsprotokoll abgeschlossen 1
sein. Jetzt erzeugt die Authen-
109

Abschlussbericht
Trusted Sensor Node
tifizierungskomponente mit Hilfe des Pseudo Random Number Generator (PRNG) eine
Zufallszahl (PRN) und signiert diese mit ihrem privaten Schlüssel (KeyTSNPriv). Diese
Zufallszahl wird für jede Authentifizierung neu generiert, um Replay-Attacken zu verhindern.
Diese signierte Zufallszahl wird an den Nutzer gesendet. Dieser überprüft die Signatur
mit dem öffentlichen Schlüssel der Authentifizierungskomponente (KeyTSNPubl) und
inkrementiert die empfangene Zahl. Im Anschluss wird diese mit dem privaten Schlüssel
des Nutzers (KeyUsrPriv) signiert und zurück gesendet. Die Authentifizierungskomponente
nutzt den öffentlichen Schlüssel des Nutzers (KeyUsrPubl), um die Signatur zu prüfen.
Die empfangene inkrementierte Zahl wird mit dem vorab berechneten Ergebnis verglichen.
Sind die Ergebnisse identisch ist der Nutzer berechtigt, die Schnittstellen für eine vordefinierte
Dauer zu benutzen. Die Authentifizierung ist abgeschlossen und der Session Timer
wird gestartet. Während das Protokoll in Abb. 6.22 Man-in-the-Middle-Attacken verhindert,
ist das Protokoll in Abb. 6.23 dafür zuständig Replay-Attacken zu verhindern. Gegebenenfalls
lassen sich beide Protokolle zusammenführen und so optimieren.
msc Authentification protocol
User
TSN
Authentification timer
Generate PRN
and sign it with
KeyTSNPriv
(PRN)KeyTSNPriv
Check the signature
with KeyTSNPubl
Signature is valid
increment PRN and
sign it with
KeyUsrPriv
(PRN+1)KeyUsrPriv
Check the signature with
KeyUsrPubl and check
the PRN
Signature and PRN are valid
Session timer
Abbildung 6.23: Authentifizierung zwischen 1 Nutzer und TSN zum Start einer neuen
Session mit Schutz Replay-Attacken
Der „Trusted Sensor Node“ besitzt einen Bewegungssensor. Dieser registriert Bewegungen
des Knotens. Um zu unterscheiden, ob der Knoten von berechtigten Personen bewegt
wird soll eine Radio Frequenzy Identification (RFID) in die Authentifizierungskomponente
integriert werden. Diese wird im Falle einer Bewegung des TSN aktiviert und versucht im
Anschluss eine Authentifizierung eines in der Nähe befindlichen autorisierten Nutzers zu
ermöglichen. Dieser Nutzer besitzt einen sogenannten RFID-TAG, der die Kommunikation
und die nutzerseitigen Aufgaben einer Authentifizierung ermöglicht. Wird dieser innerhalb
110

Abschlussbericht
Trusted Sensor Node
einer gegebenen Zeitspanne nicht empfangen, sperrt die Komponente oder löscht sensible
Daten.
Bei Verwendung einer RFID kann gegebenenfalls auf die Authentifizierung über die DSU
verzichtet werden. Möchte man über die „Debug Support Unit“ mit dem TSN kommunizieren,
kann zur Authentifizierung ebenfalls ein RFID-TAG verwendet werden. Mit diesem
muss man sich, wie oben bereits beschrieben, an der Authentifizierungskomponente anmelden,
um die DSU freizuschalten.
RFIDs gibt es in verschiedenen Ausführungen. Bei diesen Modulen werden hochfrequente
elektromagnetische Wellen erzeugt mit denen Energie und Daten übertragen werden. Abhängig
vom verwendeten Radiostandard, beträgt die Übertragungsreichweite eines RFIDs
wenige Zentimeter bis hin zu 100m. Für die Authentifizierung an einem Sensorknoten,
sollte ein RFID-System mit geringer Sendeleistung verwendet werden. Dies erhöht die Sicherheit,
da das Mithören durch potentielle Angreifer erschwert wird. Zudem verbraucht
eine leistungsarme RFID Lösung weniger Energie, als Lösungen mit stärkeren Sendern.
Man unterscheidet in der Regel zwei Gruppen von RFIDs: Die passiven und die aktiven
Systeme. Die aktiven Module besitzen eine eigene Energieversorgung. Die passiven RFID
Module werden über die Antenne ihres Funkmoduls mit Energie versorgt, wenn diese entsprechende
Energie eines Senders empfängt.
Der TSN soll auf minimale Leistungsaufnahme im Betrieb optimiert werden, so dass eine
passive RFID-Lösung anzustreben ist.
Reset-Controller
Für den Fall, dass die externe Sensorik einen Angriff vermutet, können die kryptografischen
Module in ihren Ausgangszustand zurückgesetzt werden. Einem potentiellen Angreifer
soll es so nicht möglich sein, einen Schlüssel oder ähnlich schützenswerte Informationen
auszulesen. Bei der SHA1/PRNG-Komponente müssen beispielsweise die Register
W0 bis W15 zurückgesetzt werden. Diese Register enthalten Informationen, die die Basis
zur Generierung einer Pseudozufallszahl bilden. Kennt ein Angreifer diesen Wert, so kann
er die gleichen Pseudozufallszahlen generieren. Beim AES hingegen ist es ausreichend
die vier 32-Bit-Register für den Schlüssel auf „Null“ zu setzen, so dass ein Angreifer den
Schlüssel nicht benutzen kann. Ein direktes Auslesen des Schlüssels ist ohnehin nicht
möglich. Es wäre dem Angreifer lediglich möglich, Daten mit dem gespeicherten Schlüssel
zu ver- bzw. zu entschlüsseln, was durch das Löschen des Schlüssels wirksam verhindert
wird.
111

Abschlussbericht
Trusted Sensor Node
6.3 Energieversorgung
6.3.1 Einführung
Im Abschnitt 6.2 wurden Optimierungen, auch in Hinblick auf die Leistungsaufnahme, vorgeschlagen.
Diese beziehen sich sich auf den LEON-Prozessor und die zusätzlichen Komponenten
zur Unterstützung der kryptografischen Funktionen. Die folgenden Ausführungen
dagegen beschäftigen sich mit Verbesserungen des gesamten Boarddesigns.
6.3.2 Boardkomponenten
Neben dem Prozessor befinden sich weitere Komponenten auf der Platine. Zusätzlich zur
Spannungsregelung sind externe Komponenten, wie SRAM und nichtflüchtiger Speicher in
Form von Flash nötig. Alle Bauelemente könnten einer Prüfung unterzogen werden, ob sie
überhaupt notwendig sind und/oder gegebenenfalls durch energiesparendere Alternativen
ersetzt werden können. Beispielsweise könnte der SRAM und der Flash durch einen sogenannten
Non-Volatile Random-Access Memory (NVRAM) ersetzt werden. Dieser besteht
aus einem SRAM, dessen Inhalt beim Abschalten der Versorgungsspannung durch einen
internen Lithium-Ion-Akku (on-Chip) aufrecht erhalten wird. So könnte der Prozessor die
Energieversorgung des SRAM ein- oder ausschalten. Ein Flash könnte unter Umständen
entfallen. Zu beachten ist bei einer solchen Lösung, dass dafür spezielle Bauelemente notwendig
sind, die deutlich teurer und schwerer zu beschaffen sind als Standardelemente.
Grundsätzlich kann in Erwägung gezogen werden, dass der Prozessor die Spannungsversorgung
für die einzelnen Komponenten auf dem Board ein- und ausschalten kann.
Der Prozessor hat durch die Position als Boardkoordinator den Überblick, welche Komponenten
aktuell benötigt werden oder nicht. Mit diesem Wissen kann der Prozessor die
Energiezufuhr zum jeweiligen Modul (z.B. Funkmodul) unterbrechen oder wiederherstellen.
6.3.3 Alternativen zur Energieversorgung aus Primärbatterien
Vielfach wird die Lebensdauer von Sensorknoten durch die Energieversorgung begrenzt.
Je nach Anwendungsfall kann die Lebensdauer von einigen Tagen bis zu einigen Wochen
betragen. Die erste Möglichkeit ist, Systeme zu benutzen, deren Energiedichte bezogen
auf Baugröße und -gewicht höher ist als bei Primärbatterien. In absehbarer Zeit können
dafür Brennstoffzellen in Frage kommen, in welchen Wasserstoff und Sauerstoff derart
mit einander reagieren, dass bei dem Vorgang elektrische Energie freigesetzt wird. Die
zweite Möglichkeit, die Lebensdauer von Sensorknoten zu erhöhen ist die Gewinnung von
elektrische Energie aus der Umgebung. Diese Energie kann entweder direkt genutzt oder
in einem Akku oder großen Kondensator zwischengespeichert werden. Man bezeichnet
diesen Vorgang als „Energy Harvesting“ und stellt, mit Ausnahme von Solarzellen, einen
relativ jungen Forschungsbereich dar.
112

Abschlussbericht
Trusted Sensor Node
Mit den folgenden Verfahren ist es möglich, elektrische Energie aus der Umweltenergie
umzuwandeln:
• Induktive Wandler,
• Kapazitive Wandler,
• Thermoelektrische Wandler,
• Piezoelektrische Wandler und
• Solarzellen
Allen o.g. Systemen ist gemein, dass diese in der Baugröße klein gehalten sind und damit
für den Einsatz in Sensorknoten prädestiniert sind. Nachteilig ist jedoch, dass so nur geringe
Leistungen erreicht werden und besondere Umgebungsbedingungen vorliegen müssen.
Beispielsweise sind induktive und kapazitive Wandler auf Vibrationen angewiesen und
sind auch auf eine sehr schmalbandige Resonanzfrequenz abgestimmt. Weicht die Vibration
in ihrer Frequenz ab, so bricht die elektrische Leistung ein. Silizumbasierte Systeme
können Leistungen von ca. 45nW bis 240µW liefern [48].
Dies zeigt, dass aktuelle Systeme für „Energy Harvesting“ nicht in der Lage sein werden,
leistungsstarke Sensorknoten, wie den TSN, mit ausreichend Energie zu beliefern.
Mögliche Auswege, um einen solchen Sensorknoten dennoch mit Umgebungsenergie zu
versorgen wären:
• Erhöhung der Leistungsfähigkeit des Energy Harvesting Moduls,
• Integration von weitreichenden Power-Save-Modi für Prozessor und Boardkomponenten,
• Integration von Step-Up-Wandlern zur Spannungsversorgung aus geringen Eingangsspannungen,
• Reduzierung der Boardkomponenten (z.B. Beschränkung auf ein Funkmodul) und
• Reduzierung der Duty-Cycle
Mögliche Partner zum Aufbau eines Systems mit Brennstoffzellen oder Energy-Harvesting-
Komponenten könnten sein:
• IZM Fraunhofer, Berlin
• Imtek, Freiburg
• Micropelt, Freiburg und
• EnOcean, Oberhaching.
113

Abschlussbericht
Trusted Sensor Node
Bevor Kooperationen zu den Partnern gesucht werden, sollte jedoch die Leistungsaufnahme
grob abgeschätzt werden. Diese hängt jedoch stark vom Anwendungsfall ab. Ein nicht
zu unterschätzender Vorteil ist, dass bei der Entwicklung eines Sensorknotens und der
dazugehörigen Energieversorgung beides gut aufeinander abgestimmt werden kann.
114

Abkürzungsverzeichnis
AES Advanced Encryption Standard
AHB Advanced High-performance Bus
AMBA Advanced Microcontroller Bus Architecture
APB Advanced Peripheral Bus
API Application Programming Interface
ASIC Application Specific Integrated Circuit
BSI Bundesamt für Sicherheit in der Informationstechnik
BGA Ball Grid Array
CAM Code Attestation Module
CBC Cipher Block Chaining
DHCP Dynamic Host Configuration Protocol
DES Data Encryption Standard
DSS Digital Signature Standard
DSU Debug Support Unit
ECB Electronic Code Book
ECC Elliptic Curve Cryptography
ECDSA Elliptic Curve Digital Signature Algorithm
eCos embedded Configurable operating system
ECPM EC Punktmultiplikation
FPGA Field programmable Gate Array
FSM Finite State Machine
GPIO General Purpose Input/Output
HAL Hardware Abstraction Layer
HARPS Hashed Random Preloaded Subsets
HTTP Hypertext Transfer Protocol
IBL Initial Boot Loader
IPC Interprozesskommunikation
IP Internet Protocol
IPv4 Internet Protocol Version 4
IPv6 Internet Protocol Version 6
L2CAP Logical Link Control and Adaption Layer Protocol
LCP Link Control Protocol
LGPL Lesser GNU Public License
LVTTL Low Voltage Transistor Transistor Logic
lwIP lightweight Internet Protocol
MAC Medium Access Control
MMIO Memory Mapped Input Output
MVM Module Verification Module
MMU Memory Management Unit

Abschlussbericht
Trusted Sensor Node
NIST National Institute of Standards and Technology
NMI None-Maskable Interrupt
NVRAM Non-Volatile Random-Access Memory
OSI Open Systems Interconnection
OTP One Time Programmable
PC Programm Counter
PCB Printed Circuit Board
PHY Physical Layers
PRNG Pseudo Random Number Generator
PPP Point-to-Point Protocol
RAM Random Access Memory
RFID Radio Frequenzy Identification
SAFER Secure And Fast Encryption Routine
SDP Service Discovery Protocol
SHA-1 Secure Hash Algorithmus 1
SNMP Simple Network Managment Protocol
SoC System-on-Chip
SPI Serial Peripheral Interface
SPP Serial Port Profile
SRAM Static Random Access Memory
SSL Secure Sockets Layer
TBC Trusted Boot Chain
TBR Trap Base Register
TC Trusted Computing
TCP Transmission Control Protocol
TCB Trusted Code Base
TCG Trusted Computing Group
(T)FTP (Trivial) File Transfer Protocol
TSN Trusted Sensor Node
UART Universal Asynchronous Receiver Transmitter
VHDL Very High Speed Integrated Circuit Hardware Description Language
116

Literaturverzeichnis
[1] J. Abraham. Integrating Complex I/O in an SoC. Chip Design, 4, 2004.
[2] Aeroflex Gaisler.
http://www.gaisler.com/.
[3] Aeroflex Gaisler. LEON2 Processor User’s Manual, 1.0.30 edition, 2005.
[4] ARM Technology. AMBA Specification (Rev 2.0), 1999.
[5] B. Veer and J. Dallaway. The eCos Component Writer’s Guide, 2001.
http://ecos.sourceware.org/docs-latest/ref/ecos-ref.html.
[6] A. Bakre and B. R. Badrinath. I-TCP: Indirect TCP for Mobile Hosts. In Proceedings
of the 15th International Conference on Distributed Computing Systems (ICDCS),
1995.
[7] H. Balakrishnan, V. N. Padmanabhan, S. Seshan, and R. H. Katz. A comparison of
Mechanisms improving TCP performance over Wireless Links. IEEE/ACM
Transactions on Networking, 5(6), 1997.
[8] T. Chown, S. Venaas, and A. Vijayabhaskar. IETF_RFC: RFC4076 - Renumbering
for stateless DHCPv6. Website, 2005.
http://tools.ietf.org/html/rfc4076.
[9] T. Chown, S. Venaas, and A. Vijayabhaskar. IETF_RFC: RFC5533 - Level 3
Multihoming Shim Protocol for IPv6. Website, 2005.
http://tools.ietf.org/html/rfc5533.
[10] E. Douglas Comer. Internetworking with TCP/IP, Vol.1: Principles, Protocols, and
Architectures. Prentice Hall International, 4 edition, 2000.
[11] GNU + Cygnus + Windows = cygwin.
http://cygwin.com.
[12] J. Daintith. protection domain. Website, 2004.
http://www.encyclopedia.com/doc/1O11-protectiondomain.html.
[13] S. Deering and R. Hinden. IETF_RFC: RFC2460 - Internet Protocol, Version 6
(IPv6) Specification. Website, 1998.
http://tools.ietf.org/html/rfc2460.

Abschlussbericht
Trusted Sensor Node
[14] Z. Dyka and P. Langendörfer. Area Efficient Hardware Implementation of Elliptic
Curve Cryptography by Iteratively Applying Karatsuba’s Method. In DATE, 2005.
[15] eCos Reference Manual, 2008.
http://ecos.sourceware.org/docs-latest/ref/ecos-ref.html.
[16] eCosCentric - eCos Snapshots.
http://www.ecoscentric.com/devzone/snapshots.shtml.
[17] K. Fall and S. Floyd. Simulation-based Comparisons of Tahoe, Reno, and SACK
TCP. Website.
http://www.icir.org/floyd/papers/sacks.pdf.
[18] The Fiasco microkernel.
http://os.inf.tu-dresden.de/fiasco/.
[19] S. Floyd, T. Henderson, and A. Gurtov. IETF_RFC: RFC3782 - The NewReno
Modification to TCP’s Fast Recovery Algorithm. Website, 2004.
http://www.faqs.org/rfcs/rfc3782.html.
[20] S.H. Gunderson. RIPE-57 Dubai: Global IPv6 statistics. Website, Oktober 2008.
http://www.ripe.net/ripe/meetings/ripe-57/presentations/Coli
tti-Global_IPv6_statistics_-_Measuring_the_current_state_of
_IPv6_for_ordinary_users_.7gzD.pdf.
[21] G. Huston. IPv4 Address Report. Website.
http://www.potaroo.net/tools/ipv4/index.html.
[22] T. Itoh and S. Tsujii. A Fast Algorithm for Computing Multiplicative Inverses in
GF(2m) using Normal Bases. In Inf. Comput, 1988.
[23] V. Jacobson and R. Braden. IETF_RFC: RFC1072 - TCP extensions for long-delay
paths. Website, 1988.
http://www.faqs.org/rfcs/rfc1072.html.
[24] D. Johnson, J. Arkko, and C. Perkins. IETF_RFC: RFC3775 - Mobility support for
IPv6. Website, 2004.
http://tools.ietf.org/html/rfc3775.
[25] Keithley. Datasheet Keithley Series 2600. Website, 2010.
http://www.keithley.de/dataasset=50827.
[26] L4ka::pistachio microkernel.
http://l4ka.org/projects/pistachio/.
[27] Dr. P. Langendörfer, F. Vater, S. Peter, G. Panic, and T. Basmer. Deliverable 1.1 und
1.1a Trusted Sensor Node - Hardwareversion 1, 2009.
118

Abschlussbericht
Trusted Sensor Node
[28] P. Langendörfer, M. Methfessel, H. Frankenfeldt, I. Babanskaja, I. Matthaei, and
R. Kraemer. Shielding TCP from Wireless Link Errors: Retransmission Effort and
Fragmentation. The Journal of Supercomputing (Kluwer), 23(3):245–260, 2002.
[29] A. K. Lenstra and E. R. Verheul. Selecting Cryptographic Key Sizes. Journal of
Cryptology: the journal of the International Association for Cryptologic Research,
14(4):255–293, 2001.
[30] Lesswire - leading in wireless worlds: Startseite.
http://www.lesswire.de.
[31] LGPL.
http://www.gnu.org/licenses/lgpl.html.
[32] J. López and R. Dahab. Fast multiplication on elliptic curves over gf(2m) without
precomputation. In CHES, 1999.
[33] Modified GPL for eCos.
http://ecos.sourceware.org/license-overview.html.
[34] NIST Computer Security Division. FIPS 180-1, 2001.
[35] NIST Computer Security Division. FIPS 186-1, 2001.
[36] NIST Computer Security Division. FIPS 186-2, 2001.
[37] NIST Computer Security Division. FIPS 197: Advanced Encryption Standard, 2001.
[38] Okl4-open kernel labs.
http://www.ok-labs.com/.
[39] S. Peter and P. Langendörfer. An efficient polynomial multiplier in gf(2m) and its
application to ecc designs. In DATE, 2007.
[40] S. Peter, P. Langendörfer, and K. Piotrowski. Flexible hardware reduction for elliptic
curve cryptography in gf(2 m ). In Design, Automation and Test in Europe, April 16-20,
2007, Nice, France, 2007.
[41] S. Peter, M. Zessack, F. Vater, G. Panic, H. Frankenfeldt, and M. Methfessel. An
Encryption-Enabled Network Protocol Accelerator. In Wired/Wireless Internet
Communications, 6th International Conference, WWIC 2008, Tampere, Finland, May
28-30, 2008, Proceedings, pages 79–91, 2008.
[42] POSIX. IEEE Std 1003.2-1992 (POSIX.2).
[43] M. Ramkumar and N. Memon. An Efficient Random Key Pre-distributin Scheme.
IEEE Journal on Selected Areas of Communication, 23, 2005.
119

Abschlussbericht
Trusted Sensor Node
[44] R. L. Rivest, A. Shamir, and L. M. Adelman. A method for obtaining digital signatures
and public key cryptosystems. Technical Report MIT/LCS/TM-82, Laboratory for
Computer Science, Massachusetts Institute of Technology, Cambridge, 1977.
[45] S. and P. Langendörfer. An efficient polynomial multiplier in gf(2 m ) and its application
to ecc designs. In Design, Automation and Test in Europe, April 16-20, 2007, Nice,
France, 2007.
[46] Description of SAFER+.
http://www.quadibloc.com/crypto/co040407.htm.
[47] M. Scott. MIRACL—A Multiprecision Integer and Rational Arithmetic C/C++ Library,
Version 5.0. Shamus Software Ltd, Dublin, Ireland, 2005.
http://indigo.ie/~mscott.
[48] C. Serre, A. Pérez-Rodríguez, N. Fondevilla, J.R. Morante, J. Montserrat, and
J. Esteve. Vibrational Energy Scavenging with SI Technology Electromagnetic
Inertial Microgenerators. In DTIP of MEMS & MOEMS, Stresa, Italy, 26-28 April
2006, 2006.
[49] The SPARC Architecture Manual, Version 8. Website, 1992.
http://www.sparc.org.
[50] W. R. Stevens. TCP/IP Illustrated I, 1993.
http://www.uic.rsu.ru/doc/inet/tcp_stevens/tcp_bulk.htm.
[51] Synopsys. DesignWare DW_apb_ssi Databook, July 2005.
[52] System Architecture Group: About Us: People: Liedtke.
http://i30www.ira.uka.de/aboutus/people/liedtke/nachruf.php.
[53] TCG Specification Architecture Overview. Website, 2007.
http://www.trustedcomputinggroup.org/resources/tcg_architect
ure_overview_version_14.
[54] IEEE 802.15 TG4.
http://www.ieee802.org/15/pub/TG4.html.
[55] Building a toolchain for use with eCos.
http://ecos.sourceware.org/build-toolchain.html.
[56] TUD Betriebssysteme L4Env.
http://www.inf.tu-dresden.de/index.phpnode_id=1431.
[57] uITRON.
http://www.assoc.tron.org/spec/itron/mitron-400e.pdf.
120