Software ubiquitärer Systeme · 2020-06-20 · SuS Übung 4 – Variantenmanagement und Funk 3...

11

Software ubiquitärer SystemeÜbung 4: Variantenmanagement und

Funk

Christoph Borchert und Michael EngelArbeitsgruppe Eingebettete Systemsoftware

Lehrstuhl für Informatik 12TU Dortmund http://ess.cs.uni-dortmund.de/~chb/

http://ess.cs.tu-dortmund.de/DE/Teaching/SS2012/SuS/

SuS Übung 4 – Variantenmanagement und Funk 22

Inhalt● Variantenmanagement

● Software-Produktlinien● Werkzeugunterstützung

● Drahtlose Kommunikation● Funkhardware der EZ430 Chronos● SimpliciTI: Ein Funkstack für die EZ430 Chronos

● Beispielanwendungen● Sensorik● Door Lock


Wdh.: Betriebssystem-ProduktlinienDie Idee der Software-Produktlinien ist die„organisierte Wiederverwendung“.

● Pro

● Systemkomponenten sind besser erprobt, d.h. bessere Qualität

● kürzere Entwicklungszeiten, d.h. geringere Kosten

● Contra

● Initialer Mehraufwand

● Konsistenzwahrung der aus der Produktlinie abgeleiteten Produkte

● Komplexere Verantwortlichkeiten

● Änderungen am Entwicklungsprozess


Wdh.: Produktlinienentwicklung

ProblemraumProblemraum LösungsraumLösungsraum

KonkretesProblem

KonkretesProblem

KonkreteLösung

KonkreteLösung

Domänenexperte f1

f7

f3f2

f6f5f4

Merkmale und Abhängigkeiten

PL-Architekt /Entwickler

Class

Aspect

ClassClass

AspectAspectAspect...

Referenzarchitektur / Merkmalimplemente

Applikationsentwickler

f2f6...

gewünschteEigenschaften

A C

B

D

tatsächlicheEigenschaften

PrinzipienMethoden

Werkzeuge


Software-Produktlinien● Werkzeugunterstützung notwendig um erhöhte

Komplexität zu beherrschen, u.a.:

● Merkmalselektion durch Applikationsentwickler● Ohne die Interna der Produktlinie zu kennen

● Festhalten von Domänenwissen● Abhängigkeiten zwischen Merkmalen● Sicherstellung, dass nur gültige Varianten einer SW-Produklinie

abgeleitet werden können (Konsistenz)

● Automatische Generierung der ausführbaren SW-Variante


Werkzeugunterstützung● pure::variants (siehe Vorlesung „BS-Produktlinien“)

● Kommerzielles Eclipse Plugin● Getrennte Modellierung von Problem- und Lösungsraum

FeaturemodellFeaturemodell

Lösungsraum

Einzelnes Problem Einzelne Lösung

Problemraum

FamilienmodellFamilienmodell

VariantenrealisierungVariantenrealisierungVariantenmodellVariantenmodell

pure::variantspure::variants


The Linux Kernel Configurator● Seit 2002 Bestandteil des Linux Kernels

● Löst bis dahin verwendete Skripte zur Konfiguration ab (CML)

● Ermöglicht statische Konfiguration der Kernel-Features● Das sind mehr als 10.000 bei Linux-2.6.33, Tendenz steigend!● Ist der Linux-Kernel damit eine Produktlinie?

● Bestandteile:● Parser und Dependency Checker (Back-end)

- Für die eigens definierte Sprache KConfig

● Diverse Front-ends (ncurses, QT, GTK+)● Configuration Database

- Baumstruktur → Merkmalmodelle


Merkmalmodelle● Dienen der Formalisierung von Variabilität

● z.B. grafisch als Merkmaldiagramme● Oder als Eingabe der Werkzeugunterstützung

● Welche Arten von Merkmalen gibt es?● Und wie werden sie grafisch dargestellt?

● Lassen sich alle Merkmal-Arten in KConfig umsetzen?● Falls ja, wie?


Linux-Build-Prozess

Quelle: R. Tartler et al. Feature Consistency in Compile-Time-Configurable System Software:Facing the Linux 10,000 Feature Problem. In EuroSys '11, pages 47–60, April 2011.


KConfig → auto.make / autoconf.h● Ausgabedateien von KConfig

● Definieren die Merkmalselektion

● Damit können #ifdef Anweisungen ausgewertet werden

● Lässt sich aber auch für andere Transformationen nutzen- z.B. um selektiv Dateien zu kopieren

CONFIG_64BIT=y # CONFIG_X86_32 is not set CONFIG_X86_64=y [...]


AOStuBS Familienmodell● Stellt Relation zwischen Problem- und Lösungsraum her

● Abbildung: Merkmale → Softwarekomponenten (z.B. Dateien)

● Damit lässt sich automatisch eine Kopie der Software generieren, die genau die erforderlichen Komponenten enthält→ Merkmalgetriebene Produktableitung

{ 'vname' => 'Show Panic', 'depends' => '&debug_panic', 'subdir' => 'machine', 'file' => 'show_panic.ah' }


Funkhardware der EZ430 Chronos● Je nach Modell: 433, 868 oder 915 MHz RF-Funk● Integrierter CC1101 <1 GHz wireless transceiver● Blockschaltbild:


Leistung des CC1101 Funkchips● Sendeleistung: +10dBm = 1mW

● 30 mA

● Empfangsverstärker● 15 mA

● Schlafmodus● 0,1 mA

● Vergleich: MSP430 AOStuBS idle● 200 μA


Anbindung der Funkhardware● Aufwendig direkt in

Hardware zuprogrammieren● Datenbuch Kap. 22● 70 Seiten Doku!

● Fertige Funkstacks● SimpliciTI● BlueRobin● Weitere in Entwicklung


SimpliciTI-Netzwerkstack● Proprietäres, energiesparendes Funknetzwerk-Protokoll

von TI● Für EZ430-Chronos und andere RF-basierte Chips● 433/868/933 MHz und 2.4 GHz-Band (je nach Hardware)

● Effizient: verwendet < 8 kiB Flash und 1 kiB RAM● Abhängig von jeweiliger Konfiguration

● Flexibel● Einfache Stern-Netztopologie mit Bereichserweiterung● und/oder Peer-to-Peer-Kommunication

● Einfach: Verwendet sehr simples API● Unterstützung für viele Geräte

● MSP430+CC110x/2500, CC1110/2510, CC1111/CC2511, CC2430, CC2520

● Energiesparend: Unterstützt schlafende Geräte


Eigenschaften von SimpliciTI ● Minimale Hardware-Abstraktion● Kein Heap notwendig

● Pakete werden in statischen Puffern verwaltet

● Kein Netzwerkkontext zur Laufzeit notwendig● „stateless“

● Single thread-Applikation● Keine Tasks oder Scheduling notwendig● ...aber in AOStuBS für andere Dinge nutzbar

● Netzwerk-API ist synchron● Kein return aus Funktionen bis die jew. Operation abgeschlossen ist● Übertragungswiederholungen (retries) und Bestätigungen (ACKs)

müssen von der Anwendung implementiert werden


SimpliciTI-Anwendungen● Alarm & Sicherheit

● Belegungs-Sensoren● Lichtsensoren● Kohlenmonoxid-Sensoren● Glasbruch-Detektoren

● Rauchmelder● Fernbedienungen● AMR (automatisierte Messung über RF)

● Gas-, Wasser-, Stromzähler

● Hausautomatisierung: ● Garagentoröffner● Appliances● „environmental“-Geräte (Lichtsensor, Temperatur, etc.)


SimpliciTI: Netztopologien (1)● Drahtlose Sensor-Anwendung

● Bereich kann durch Repeater erweitert werden.● Kreise: Reichweite v. Gateway/erweiterte Reichweite der Repeater


SimpliciTI: Netztopologien (2)● Aktive RF-Tags

● Netzwerk wird „ad-hoc“ betreten und verlassen● Tags müssen sich schnell mit Netzwerk verbinden können

- Und gleichzeitig wenig Energie verbrauchen


Beispiel: Rauchmelder


SimpliciTI: Architektur● Layer:

● MRFI (“minimal RF interface”) – NWK – nwk applications (Module) – customer applications

● Netzwerk-Support:● – init – ping – link / linklisten – nwk mgmt – send / receive – I/O


SimpliciTI: Paketformat

● Preamble: hw sync – Synchronisation Sender/Empfänger ● Sync: hw sync – Synchronisation Sender/Empfänger● Length: bytes non-phy – Länge Nutzdaten● Dstaddr – Zieladresse● Srcaddr – Quelladresse● Port: app port number – Unterscheidung mehrerer Anwendungen● Devinfo: capabilities – Eigenschaften des Geräts● Tractid: transaction or seq num – Paketfolgen● App Payload: 0<=n<=52 Byte – Nutzdaten● FCS: valid CRC – Checksumme


Adressierung und Kommunikation● Netzadresse = Hardware-Adresse (4 Byte) + Anwendungs-Port

● Statisch zugewiesene Hardware-Adresse

- In Software pro Uhr konfigurierbar● Broadcast-Adresse: Byte 1: 0x00 oder 0xFF

● Kommunikationstopologien:


SimpliciTI: Statische Konfiguriation● Operations-Modus (type)

● Infrastruktur oder P2P

● Powermodi (sleep support) ● Topologie ● Adressierung / Identifikation● RAM-Allokation

● Paketgröße● Puffergrößen● # unterstützt. Links (Verbindungen)

● Sicherheits-Tokens● Messaging (hop ct, repeaters)● Funk

● Frequenz, Krypto-Schlüssel, Modulation, CCA-Parameter


SimpliciTI: Laufzeit-Konfiguriation● IOCTL Systemaufrufe:


Access-Point-Programmierung● Stern-Hub im Netzwerk (einer pro Netz)

● Immer aktiv (auch als Bereichserweiterung/Repeater)● Store-and-forward-Funktion für schlafende Geräte● Verbindungs- und Token (link and join)-Verwaltung● Kann auch Endgeräte-Funktionen haben (link listen, receive)


Endgeräte-Programmierung● API-Sequenz (Beisp.):

● Initialisierung (und Join)● Link (setzt listen voraus)● Temperatur lesen● Senden

● Option: Schlafmodi


Beispielanwendung: Sensorik● Einfache Anwendung

● Konfigurierbar● Verteilt

● Idee: Erzeuger-Verbraucher-Struktur● Übertragen von Sensordaten● Erste Uhr sammelt und versendet Sensordaten per Funk...● Zweite Uhr empfängt die Daten und zeigt sie an

Druck

Temp

Accel


Beispielanwendung: Door Lock● Video: Rochester Institute of Technology Robotics Club

http://www.youtube.com/watch?v=yqMbdQptdfw&feature=player_embedded


Beispielanwendung: Door Lock● Elektronisches Türschloß● Uhr kommuniziert drahtlos, um Tür zu öffnen und zu

verschließen ● Geheimes Passwort: Sequenz von „Taps“ auf den 3-Achsen-

Beschleunigungssensor der Uhr● → Sensoreinsatz für innovative Anwendungen!

● Extrem geringer Energieverbrauch● ...insbesondere für eine drahtlose Anwendung● Erreicht geschätzte Batterielaufzeit von > 4 Jahren (Uhr) bzw. > 1

Jahr (Tür)


Door Lock – Türhardware● Eigenbau mit CC1111EMK868-915 Evaluation Kit

● Verwendet CC1111F32 Wireless System-on-a-Chip


Door Lock: Stromverbrauch● Erwartete Nutzung der Uhr:

● 10 Aufschließ-Vorgänge pro Tag● Realistisch in Büroumgebungen?

● Erwartete Nutzung der Tür:● Je 30 Auf- und Abschließ-Vorgänge pro Tag

● Chronos verwendet 220mAh Knopfzelle● Uhr verbraucht 0.131mAh pro Tag● Funktion auf Batterie: ca. 1679 Tage = 4,6 Jahre!

● Tür verwendet vier 2500mAh, 1,2V-Batterien in Reihe● Tür verbraucht 4,03mAh pro Tag● Funktion auf Batterie: ca. 620 Tage oder 1,7 Jahre!


Door Lock: Sicherheit● Behauptung der Entwickler:

● „In a sense, our wireless door lock solution is even more secure than the traditional method of unlocking doors using keys“

● Zum Aufschließen wird nicht nur eine vorher mit der Tür verbundene („paired“) Uhr benötigt...● sondern auch noch eine geheime „Klopf“-Sequenz für die jeweilige

Tür

● Bei normalen Schlüsseln ist nur der physikalische Besitz wichtig

● Sicherheit wird beim „door lock“ durch eine Kombination erreicht● Physikalischer Besitz der Uhr● Wissen eines geheimen Passwortes

(Klopfsequenz)


Door Lock: Sicherheit● Informationen über bis zu 21 verbundene Türen in einer

einfachen Datenbank in der Uhr● Eindeutige 16-Bit Tür-ID● 128-Bit shared AES-Key, mit der Tür beim Verbinden vereinbart ● Jedes Tupel (Uhr, Tür) hat eigene gemeinsame Schlüssel und

Aufschließ-(„Knock“-)Sequenz ● Tür und Uhr kommunizieren sicher mit Hilfe des gemeinsamen

Schlüssels

● Datenbank der Uhr (Beispiel) – bis zu 21 Einträge:● Door ID Shared 128-bit AES Key● 0xFE12 01 6D 2D 83 66 64 0E 25 3B A0 41 0D 2D 83 66 FF● 0x11D3 0E 25 3B A0 41 3B A0 410D 2D 83 66 FF66 64 0E


Door Lock: Sicherheit● Datenbank auf Tür-Seite (bis zu 68 Einträge im Flash):

● Watch ID Shared 128-bit AES KeySecret 96-bit Knock Sequence

● 0x434F 01 6D 2D 83 66 64 0E 25 3B A0 41 0D 2D 83 66 FF50 FF 8C A0 35 32 80 EF 41 0D 00 00

● 0x100A 83 66 FF 66 64 0E A0 41 0D 2D 0E 25 3B A0 41 3B35 32 80 2D 83 66 64 00 00 00 00 00

● 0x100A A0 35 32 80 41 0D 2D 3B A0 41 0D 2D 0E 25 3B 0399 FF 30 00 00 00 00 00 00 00 00 00

● Auf Nutzeraktion initiiert Uhr neue Schlüsselvereinbarung● Neuer, partieller 64-Bit-Schlüssel wird generiert● Neuer Schlüssel wird mit alten Schlüssen verschlüsselt und zur Tür

übertragen● Diese kombiniert neuen part. Schlüssel mit Teil des alten Schlüssels● Doppelte Ausführung vereinbart komplett neuen 128-Bit-Schlüssel

zwischen Uhr und Tür● Wird einmal pro Monat empfohlen (warum?)


Door Lock: Angriffs-Szenario 1● Klassischer Angriff: „Replay-Attacke“● Aufzeichnen der Funkübertragung

● ...und erneutes Abspielen● Funktioniert (leider) gut bei älteren Funk/IR-Fernbedienungen für

Auto-Zentralverriegelungen... auch bei der Uhr?

● Wenn ein Angreifer die Türöffnungs-Sequenz wiederholt● Durch Aufnehmen und Abspielen einer erfolgreichen Sequenz

● ...scheitert dies an einem ungültigen Token● Angreifer kann auch kein neues Token anstelle der Uhr

anfordern● Sitzungs-Token sind gültig, bis Operation erfolgreich beendet oder

Gültigkeitsdauer abgelaufen


Door Lock: Sicherheit● Sitzungs-Token-System beim Aufschließen, Schlüssel

erneuern oder Sequenz ändern. Ablauf:● Watch will send unencrypted SYN packet to discover nearby doors● The door will receive the SYN request and looks up the watch in its

database and find the shared key● The door will generate a 32-bit pseudo random number known as

the session token for the particular watch● Token is encrypted using shared key, sent to watch in a SEC packet● Watch decrypts SEC packet; verifies validity by looking for pattern

in decrypted message; saves token for the remaining of the session● During the session, the token will always be included in the

encrypted part of the packet and both the door and the watch will verify each message using the token

● Upon success completion of the operation (e.g. successfully unlocking the door, renewing partial key, or changing the knock sequence), token will be discarded by both ends and become invalid


Door Lock: Angriffs-Szenario 2● Klassischer Angriff: Physikalischer Zugriff● Wenn Angreifer Zugriff auf Uhr mit 128-Bit shared key

bekommt, kann er damit die Tür nicht öffnen:● Eine 96-Bit „Klopf“-Sequenze ist zum Aufschließen noch erforderlich● Einmalig für jedes (Tür,Uhr)-Tupel konfigurierbar ● Sequenz wird durch Abfragen des integrierten 3-Achsen-

Akzelerometers erfaßt

● Eingabe der Klopfsequenz durch den Nutzer kann leise und unauffällig erfolgen● Sequenz wird mit shared key verschlüsselt und in einem SEQ-Paket

zur Verifikation an die Tür geschickt

● Tür normalisiert die Sequenz und prüft die Gültigkeit gegen die interne Datenbank● Normalisierung ermöglicht es Benutzern, mit unterschiedlicher

Geschwindigkeit zu klopfen, solange relative Längen konsistent sind


Door Lock: Normalisierung● Folgende einfache Sequenz:

● “TAP [… pause …] TAP TAP [… pause …] TAP[… pause …] TAP”

● Uhr „bemerkt“ Erschütterung bei jedem Klopfen (TAP)● Erkennungs-Algorithmus funktioniert wie folgt:

● Starte Akzelerometer und warte auf erstes Klopfen● Nach erstem Klopfen: starte Timer zum Messen der Pausenlänge

bis zum folgenden Klopfen● Nach zweitem Klopfen: Timer anhalten, Pausenlänge (8 Bit mit 6

Millisekunden Auflösung) als erstes Element des Arrays (Länge 12) speichern

● Timer wieder starten, um nächste Pausenlänge zu messen● …● Bei Timeout (Pause zu lang) oder gefülltem Array wird Ende der

Sequenz angenommen


Door Lock: Normalisierung● Nun enthält das Array Zahlen, die die Pausenlänge

zwischen den einzelnen Taps angeben● Für die Sequenz“TAP [… pause …] TAP TAP [… pause

…] TAP[… pause …] TAP” sieht das Array wie folgt aus:● 0x50 0x10 0x45 0x49 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00

● Unabhängigkeit von der Klopfgeschwindigkeit durch Normalisierung der Sequenz● Skalieren der längsten Pause in der Sequenze zu 0xFF:● 0xFF 0x33 0xDB 0xEB 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00

● Normalsierte Sequenz kann mit vorheriger normalisierter Sequenz auf Gültigkeit verglichen werden● Wahrscheinlichkeit der Übereinstimmung wird auf Basis der

normalisierten Sequenzen berechnet● Da Sequenz nie perfekt einzugeben ist, ist ein gewisser Fehler

erlaubt


Door Lock: Sicherheitsanalyse● Kein Sicherheitssystem ist perfekt. Möglicher Angriff:

● Größtes Problem: initiale Verbindung Uhr ↔ Tür. ● Dazu: Tür in besonderen „pairing mode“ versetzen.

- Taste an Tür für >= 10 Sekunden drücken

● Im pairing mode akzeptiert Tür RAW-Pakete zum initialen Schlüsselaustausch; Nutzer initiiert Prozess an der Uhr

● Uhr sammelt Zufallsbits (Akzelerometer-Werte) und erzeugt gemeinsamen 128-Bit AES-Schlüssel. Dieser Schlüssel wird unverschlüsselt in RAW-Paketen via Funk zur Tür übertragen

● Tür akzeptiert und speichert neuen Schlüssel nur im pairing mode. bestätigt der Uhr den erfolgreichen Empfang und verlässt gefährlichen pairing mode sofort

● Pairing mode auch zum Rücksetzen der 128-Bit-Schlüssel- Im Falle von „out-of-sync“-Zustand: tritt auf, wenn ein ACK-Paket

während Schlüsselerneuerung verloren geht

- Wahrscheinlichkeit minimiert durch mehrfache ACK-Paketsendung


Door Lock: Sicherheitsanalyse (2)● As you can see, the door is considered “naked” when it is

put into pairing mode. A potential solution to this problem is to decrease transmission power in pairing mode such that the watch has to be very close to the door. Another potential solution is to run a Diffie-Hellman key exchange process and requires the user to input a pre-shared secret in order to pair with the door. The secret can be in a form of tapping or button press sequence.● http://svn.ziyan.info/svn/doorlock/trunk/


Zusammenfassung● EZ430-Chronos: ubiquitär durch Funktechnologie● Einfache Hardware, einfache Protokolle, simple API

● Aber flexibel: Infrastrukturmodus, P2P

● Komplexe Anwendungen realisierbar● Door Lock● Sicherheit von Anwendungen (AES) auch mit einfacher Hardware

realisierbar● Querschnittsthemen: Sicherheit und Energieverbrauch

● Einfache Anwendung als Demo: Sensordaten funken● In der nächsten Praxis-Übung

● Konfigurierbarkeit● ...um Anwendung mit typischen Embedded-Beschränkungen zu

realisieren● In SimpliciTI: über #defines/#ifdefs (Igitt! :-))● Bei uns: mit AOP und KConfig

Software ubiquitärer Systeme · 2020-06-20 · SuS Übung 4 – Variantenmanagement und Funk 3...

Documents

Transcript of Software ubiquitärer Systeme · 2020-06-20 · SuS Übung 4 – Variantenmanagement und Funk 3...