Secure Coding in der Embedded-Welt: Warum jede Codezeile zählt – Recap von „Importance of secure coding“ mit Bassem Taamallah (HID Global GmbH)

Überblick und Kontext der Session

In „Importance of secure coding“ erläutert Bassem Taamallah (Principal Firmware Engineer, HID Global GmbH) pointiert, warum sichere Programmierung kein „Nice-to-have“, sondern ein zwingender Bestandteil professioneller Embedded-Entwicklung ist. Wir von DevJobs.at haben die Session aufmerksam verfolgt – mit einem klaren Erkenntnisgewinn: Wer in sicherheitskritischen Geräten (wie Zutrittslesern) Firmware entwickelt, muss Angriffsmodelle verstehen, Code-Entscheidungen absichern und robuste Muster konsequent umsetzen.

Bassem strukturiert seine Ausführungen in drei Schritten: Er stellt HID Global und das Core-Firmware-Team vor, ordnet den Bedarf für sichere Software ein und geht dann tief in zwei zentrale Angriffskategorien – Fehlerinjektion und Seitenkanalangriffe – inklusive konkreter Abwehrmuster ein. Mehrfach betont er: „Security ist nicht nice to have – sie ist mandatory.“

HID Global, das Core-Firmware-Team und die Produktlandschaft

Bassem beginnt mit einem kurzen Blick auf die Organisation:

• HID Global wurde 1991 als Anbieter von Sicherheitszugangslösungen gegründet und ist seit 2000 Teil von Assa Abloy.
• Das Portfolio umfasst eine große Bandbreite an Credential-Produkten (im Vortrag fällt u. a. „COSI class“) sowie vielfältige Reader-Technologien.
• In diesen Produkten gibt es gemeinsame Modelle und wiederverwendbare Komponenten. Genau hier setzt das Core-Firmware-Team an.

Das Core-Firmware-Team liefert modulare Firmware-Bausteine auf einer gemeinsamen Hardware-Entwicklungsplattform – darunter:

• Wi-Fi
• NFC
• BLE
• UWB
• Module rund um den Secure Element (Dateisystem-Management)
• Kryptografie-Module

Zielbild dieser Plattformarbeit:

• Time-to-Market und Kosten senken, indem funktionsfähige, wiederverwendbare Module bereitgestellt werden.
• Hohe Modularität: Bausteine sollen sich leicht integrieren lassen.
• Orientierung an Industriestandards.
• Arbeit mit der neuesten Technologie, um Wiederverwendung über Produktlinien hinweg zu ermöglichen.
• Und „last but not least“: stets sichere und robuste Module.

Warum sichere Programmierung?

Selbst wenn Software „funktioniert“, bleibt die Frage: Warum zusätzlich sicher programmieren? Bassem nennt klare Gründe:

• Geheimnisse müssen geheim bleiben: Vertrauliche Informationen und Assets (z. B. Schlüsselmaterial) dürfen nicht auslaufen.
• Unautorisierte Zugriffe verhindern: Nur berechtigte Entitäten sollen an sensible Daten oder Funktionen gelangen.
• Sicherheitsmechanismen dürfen nicht umgangen werden: Kein „Überspringen“ kryptografischer Prüfungen oder Authentifizierung.
• Kein Einschleusen von Schadcode: Maliziöse Modifikationen verändern Chipverhalten – mit potenziell katastrophalen Folgen.
• Compliance und Regulierung: Sicherheit ist heute Pflicht, nicht Kür.

Bassem verknüpft dies direkt mit realen Angriffsflächen: In einem physischen Zugangssystem können sowohl Karten/Smartcards bzw. Smartphone-Apps als auch die Reader selbst attackiert werden. Während verteilte Karten leichter in Angreiferhände gelangen, wäre das Kompromittieren eines Readers aus Wirkungssicht „noch katastrophaler“ – denn er kontrolliert die Tür.

Zwei Hauptklassen von Angriffen: Fehlerinjektion und Seitenkanal

Bassem gruppiert Attacken in zwei große Klassen:

1) Seitenkanalangriffe (nicht-invasiv):

• Beobachtung der Chipaktivität über Power Consumption, elektromagnetische Abstrahlung oder Timing.
• Ziel: Aus indirekten Merkmalen Rückschlüsse auf interne Zustände oder geheime Daten ziehen.

2) Fehlerinjektion (invasiver bzw. aktiv herbeigeführter instabiler Zustand):

• Der Chip wird in eine „unstabile“ Situation gebracht, um Sicherheitsprüfungen zu überspringen oder interne Daten zu leaken.
• Beispiele: Laser-Fokus zur Bit-Flip-Induktion, Power-Glitching, Clock-Glitching.

Im Folgenden vertieft er beide Klassen – jeweils mit praktischen Beispielen und den dazugehörigen sicheren Codiermustern.

Fehlerinjektion: Was passiert – und wie schützt sichere Programmierung?

Bassem beschreibt Fehlerinjektion als gezielte Störung, die den Chip oder den Programmlauf in instabile Zustände versetzt. Wirkungen und Angriffsziele:

• Überspringen kritischer Operationen (z. B. Authentifizierung, MAC-Prüfungen), wenn durch Bit-Flips Entscheidungszweige kippen.
• Erzwingen von Buffer Overflows: Ein Angreifer sendet „zu viel“ Daten, die im RAM sensible Inhalte überschreiben oder offenlegen (z. B. Schlüsselmaterial). Er spricht von „damping the memory“ – also effektivem Auslesen/Leaken des RAM-Inhalts.
• Blockieren des Schlüssel-Ladevorgangs: Wird ein Krypto-Key nicht geladen und stattdessen mit Nullwerten gearbeitet, können Klar- und Chiffratbeziehungen leichter analysiert werden – da die „Schlüssel“ dann bekannte (Null-)Werte sind.

Beispiel 1: Entscheidungsbit flippen – warum boolesche Zustände gefährlich sind

Ein von Bassem gewähltes, greifbares Szenario: „Wir haben eine Funktion, die den Zugang erlaubt (Tür öffnen) oder verweigert (Fehlermeldung). Der Zweig wird anhand einer booleschen Variable entschieden.“ In C kann ein Boolean als 0/1 repräsentiert sein. Ein einzelner Bitflip – ausgelöst etwa durch Laser oder Glitch – könnte die Entscheidung invertieren und aus „Zutritt verweigert“ plötzlich „Tür auf“ machen.

Seine Kernbotschaft: Verwenden Sie für sicherheitsrelevante Kontrollzustände keine einfachen Booles. Stattdessen:

• Nutzen Sie breitere Datentypen mit möglichst großer Hamming-Distanz zwischen den kodierten „wahren“ und „falschen“ Werten.
• Definieren Sie explizite „Secure False“/„Secure True“-Werte sowie „invalid“ Zustände. Wird ein ungültiger Zustand erkannt, führen Sie einen „Security Reset“ oder eine „Trap“ aus.

So wird aus einem potenziellen Einzelbitfehler ein Detektionsereignis – und nicht ein unbemerkter Zustandswechsel.

Beispiel 2: Schlüssel-Load aushebeln – Redundanz mit Gegenläufern

Ein weiteres Muster adressiert die Blockade des Schlüssel-Ladevorgangs. Ziel des Angreifers ist, das Laden zu verhindern, sodass die nachfolgenden Kryptoperationen mit Nullwerten laufen. Bassem empfiehlt Redundanz:

• Statt eines Zählers verwenden Sie zwei Zähler, die in entgegengesetzte Richtungen laufen.
• Nach jedem Schritt vergleichen Sie beide Werte.
• Bei Abweichungen wird eine Trap bzw. ein Security Reset ausgelöst.

Das gleiche Prinzip lässt sich für andere kritische Sequenzen einsetzen – jede Form der konsistenten Zustandsüberwachung erhöht die Wahrscheinlichkeit, Faults zu entdecken.

Weitere Muster gegen Fehlerinjektion

Bassem führt zusätzlich mehrere Good Practices auf, die wir im Kontext Fehlerinjektion als besonders relevant einordnen:

• Keine einfachen Konstanten für sicherheitskritische Flags verwenden, sondern Werte mit maximaler Hamming-Distanz.
• Kommunikationspuffer: Intermediäre RAM-Puffer vermeiden, die bei Overflows geheime Daten „nebenan“ überschreiben oder preisgeben könnten.
• „Flow Protection“ (Ablaufschutz): Mitlaufende Prüfwerte („matching number“), die zu Beginn einer Funktion aktualisiert und am Ende validiert werden, um Sprünge/Skips zu erkennen.
• „Watermark“ am Stackende: Bei jeder Rückkehr prüfen, ob der Stack seinen Guard/Marker noch enthält, um Stacküberläufe zu detektieren.
• Datenintegrität absichern: CRCs für Datenblöcke einsetzen; bei einfachen Variablen Redundanzen mit invertierten Spiegelwerten halten und kontinuierlich prüfen.

Diese Muster wirken wie Netze auf unterschiedlichen Ebenen – und adressieren insbesondere das ungewollte Auslassen von Prüfschritten, das Überschreiben sensibler Zustände oder das Fehlschlagen von Sicherheitsinitialisierungen.

Seitenkanalangriffe: Beobachten statt Manipulieren

Im Kontrast zur aktiven Störung steht die stille Beobachtung des Chips, ohne invasive Eingriffe. Bassem nennt mehrere SCA-Varianten:

• Timing-Angriffe: Aus der Dauer bestimmter Berechnungen lässt sich auf intern verwendete Daten oder Pfade schließen. „Allein die Zeit, die ein bestimmter Vorgang benötigt, kann Daten leaken.“
• Power-Analyse: Über die Leistungsaufnahme des Chips kann man Aktivitätsprofile ableiten. Bassem nennt explizit Simple Power Analysis (SPA) und die anspruchsvollere Differential Power Analysis (DPA). Er erwähnt auch den praktischen Messaufbau mit einem Oszilloskop.
• Kommunikationsantwort-Analyse: Rückschlüsse aus Muster und Inhalt der Antworten eines Systems.
• Temperatur-/Heizcharakteristik: Erwärmung während der Berechnung als indirektes Signal (weniger offensichtlich, aber potenziell informativ).

Während Bassem hier vor allem Sensibilisierung leistet, sind die Folgerungen für Entwickler klar: Seitenkanäle müssen als reale Datenabflusswege begriffen werden. Im Code-Alltag heißt das, Datenabhängigkeiten in Abläufen im Blick zu behalten, Variablen und Speicherbereiche nach Kryptoverwendungen zu säubern und keine unnötigen Speicherbewegungen oder Zwischenspeicher zu erzeugen, die Beobachtung oder Leakage begünstigen.

Speicherhygiene und Systemzustände: Leaks vorbeugen

Mehrfach adressiert Bassem die „Hygiene“ rund um sensible Daten:

• Nach kryptografischen Operationen Variablen gezielt bereinigen.
• Falls das System internen Cache besitzt: Cache flushen, um Reste sensibler Daten zu entfernen.
• Intermediäre Buffer vermeiden, insbesondere in Kommunikationspfaden – jede zusätzliche Kopie erhöht die Angriffsfläche.

Diese Maßnahmen sind nicht nur „gute Manieren“, sie unterbinden ganz konkret das zufällige „Liegenlassen“ sensibler Informationen in Speicherregionen, die via Overflow, Fault oder indirekt über Seitenkanäle erreichbar werden könnten.

Von der Theorie in die Praxis: So fügen sich die Muster zusammen

Was uns an der Session besonders überzeugt hat: Die einzelnen Maßnahmen sind bewusst einfach gehalten – ihre Stärke entfalten sie im Verbund. Beispielhafter Ablauf für eine sicherheitskritische Funktion:

1. Zu Beginn wird ein Flow-Protection-Wert gesetzt/aktualisiert.
2. Ein doppelter (gegenläufiger) Zähler begleitet die Schritte der Initialisierung und des Schlüsselmanagements.
3. Zustandsflags sind als breite, Hamming-distanzierte Codes realisiert – mit spezifischem Handling für „invalid“.
4. Eingehende Datenpakete laufen möglichst ohne zusätzliche Zwischenpuffer, werden in Größe/Format streng validiert und über eine CRC abgesichert.
5. Nach jedem kritischen Segment wird redundant geprüft (Invert-Spiegelwerte, Counter-Kohärenz, Watermark am Stack).
6. Vor Verlassen der Funktion werden sensible Variablen bereinigt und (falls vorhanden) Caches invalidiert.
7. Am Ende verifiziert die Flow-Protection, dass der vorgesehene Pfad eingehalten wurde – andernfalls: Trap/Security Reset.

Diese Kette von Schutzmechanismen erschwert sowohl die Ausnutzung einzelner Fehlereinschleusungen als auch das Extrahieren verwertbarer Seitensignale. Zentral ist nicht die „eine perfekte Abwehr“, sondern der robuste Verbund aus Checks, Redundanzen und Fail-safe-Verhalten.

Angriffsoberflächen in Zutrittssystemen konkret denken

Bassem betont die reale Bedrohungslage im physischen Zugangsumfeld:

• Karten/Smartcards/Smartphone-Apps sind „leicht erreichbar“, da sie verteilt in Nutzerhänden sind.
• Reader selbst sind weniger erreichbar, dafür umso „katastrophaler“ im Fall des Bypasses: Wird der Reader überwunden, steht die Tür offen.

Für Firmware-Teams bedeutet das, die Schutzmuster sowohl für Endpunkte mit hohem Expositionsgrad (Karten/Apps) als auch für hochkritische Kontrollpunkte (Reader) konsequent anzuwenden und zu testen.

Compliance und Betrieb: Sicherheit als kontinuierliche Arbeit

Ein weiterer, wichtiger Punkt der Session: Sicherheitsarbeit endet nicht mit dem Release. Bassem formuliert es deutlich: Angriffe entwickeln sich weiter, daher muss auch unser Code fortlaufend verbessert werden. Drei Konsequenzen daraus:

• Laufende Überprüfung und Härtung vorhandener Module – neue „Secure Patterns“ entdecken und integrieren.
• Testen, Validieren, Beobachten: Wissen, „was passiert“, um neue Angriffsarten früh zu erkennen.
• Regulatorische Anforderungen einhalten: „Security ist mandatory“ – Unternehmen stehen in der Pflicht, Vorgaben zu erfüllen.

Konkrete Best Practices aus der Session (kompakt)

• Zustandscodierung mit hoher Hamming-Distanz statt einfacher Booles; „invalid“ erkennen und in Trap/Security Reset überführen.
• Redundanz bei kritischen Sequenzen: Gegenläufige Doppelzähler, Spiegel-/Invertwerte für Variablen, kontinuierliche Kohärenzchecks.
• Flow Protection pro Funktion: „Matching Number“ am Start aktualisieren, am Ende prüfen.
• Stack-Watermarking: Überläufe durch Marker-Kontrolle detektieren.
• Kommunikationspfade ohne unnötige Zwischenpuffer; strikte Längen-/Formatvalidierung.
• Datenintegrität via CRC; für Einzelwerte Redundanz plus Invert.
• Speicherhygiene nach Kryptoverwendungen: Variablen sauber löschen, Caches flushen (falls vorhanden).
• Fail-safe Default: Bei Inkonsistenz, invaliden Zuständen oder Zeit-/Ablaufverletzungen in sichere Resets/Traps gehen.

Diese Liste spiegelt genau die Muster wider, die Bassem in seinem Vortrag benennt und die sich in Embedded-Krypto- und Zugriffs-Workflows gut verankern lassen.

Was wir als Engineering-Learnings mitnehmen

• Sicherheitskodierung ist Funktionskodierung: Ohne Schutzmuster ist die „funktionierende“ Implementierung unvollständig – denn sie lässt Angriffe zu, die das Verhalten der Anwendung verändern.
• Zwei Denkachsen – Beobachtung und Störung: Seitenkanal vs. Fehlerinjektion bilden das Raster, durch das wir Implementierungen prüfen sollten.
• Robustheit kommt aus Vielfalt: Mehrere kleine, komplementäre Checks sind oft wirksamer als eine einzelne große Barriere.
• Einfacher Start, hoher Effekt: Boolesche Flags gegen Hamming-kodierte Zustände zu tauschen, kostet wenig – verhindert aber kritische Bitflip-Eskalationen.
• Test und Betrieb: Sicherheitsmaßnahmen benötigen laufende Verifikation im Feld, um der Evolution von Angriffen zu begegnen.

Fazit: Secure Coding als Pflichtprogramm – nicht nur im Reader

Bassem Taamallah führt in „Importance of secure coding“ vor, wie sich mit disziplinierten Codiermustern echte Angriffsklassen adressieren lassen – ohne aufwändige Spezialequipment-Diskussionen oder theoretische Exkurse. Das Bild ist pragmatisch: Wenn ein einzelnes Bit den Zugang entscheidet, ist das ein Designproblem. Wenn ein Key-Ladevorgang ohne Redundanz abgesichert ist, lädt das zum Angriff ein. Wenn Zwischenspeicher kryptografische Restwerte halten, ist Leakage nicht weit.

Die Botschaft an Firmware-Teams – bei HID Global und darüber hinaus – ist klar: Absichern, überwachen, bereinigen, prüfen. Fehler provozieren und abfangen, Seitenkanäle antizipieren, Zustände absichern. Und das kontinuierlich, weil Angriffe sich weiterentwickeln. So entsteht aus Code, der „funktioniert“, Code, der zuverlässig schützt.

• 

  

  Testing on all Levels

  Stephan Puri-Jobi von HID Global beleuchtet in seinem devjobs.at TechTalk das Thema Testing und was es insbesondere bei Secure Devices zu beachten gibt.

  Jetzt ansehen

• 

  

  Stephan Puri-Jobi, Software Test Lead von HID Global

  Software Test Lead bei HID Global Stephan Puri-Jobi gibt im Interview Einblicke in den Aufbau des Unternehmens und des agilen Testing Teams, mit welchen Technologien gearbeitet wird und wie das Recruiting im Team gestaltet ist.

  Jetzt ansehen

• 

  

  Anna Dziarkowska, Software Engineer bei HID Global

  Anna Dziarkowska von HID Global erzählt im Interview wie sie zum Software Engineering gekommen ist, mit welchen Themen sie sich aktuell als Software Engineer beschäftigt und was sie Anfängern empfehlen würde.

  Jetzt ansehen
• 

  

  Stephan Puri-Jobi, Software Test Lead bei HID Global

  Stephan Puri-Jobi von HID Global redet im Interview über seine Anfänge im Programmieren bis hin zum Software Testing, was seine Arbeit beinhaltet und gibt Tipps für Neueinsteiger.

  Jetzt ansehen