Secure Coding for Embedded Systems: Every Line Matters – A Recap of “Importance of secure coding” by Bassem Taamallah (HID Global GmbH)

Session overview and why it matters

In “Importance of secure coding,” Bassem Taamallah (Principal Firmware Engineer, HID Global GmbH) makes a clear case: in security-critical embedded products, code is only “done” when it is also secure. From our DevJobs.at editorial seat, the key takeaway is straightforward and technical: understand the attack classes, design your control paths to withstand faults, and treat memory hygiene as a first-class engineering task. As Bassem puts it, security today is not nice to have; it’s mandatory.

The talk unfolds in three parts. First, Bassem introduces HID Global and the Core Firmware team’s mission. Then he explains why secure coding is necessary even when the feature set appears complete. Finally, he dives into two main attack families—fault injection and side-channel attacks—backed by concrete coding patterns engineers can apply.

HID Global, the Core Firmware team, and the platform approach

Bassem starts with a concise company and team overview:

• HID Global was founded in 1991 as a provider of security access solutions and has been part of Assa Abloy since 2000.
• HID offers a wide range of credential products (the talk mentions “COSI class”) and a large span of reader technologies.
• Across products, components and models are reused. That is where the Core Firmware team comes in.

The Core Firmware group provides reusable firmware modules on top of a shared hardware development platform, including:

• Wi-Fi
• NFC
• BLE
• UWB
• Secure element modules for file system management
• Cryptography modules

Their objectives are practical and product-driven:

• Reduce time-to-market and cost by shipping effective reusable modules.
• Maximize modularity so modules integrate easily into different product lines.
• Adhere to industry standards.
• Work with the latest technology to enable reuse across products.
• And critically: deliver secure, robust modules.

Why secure coding even when it “works”?

Bassem addresses the common trap: code is functional, so why harden it? His answers target real threats:

• Keep secrets secret: sensitive assets and keys must not leak.
• Block unauthorized access: entities without authorization must not reach sensitive data or functions.
• Prevent bypasses of cryptographic checks: no skipping authentication or integrity verification.
• Prevent malicious code injection: injected code changing chip behavior is unacceptable.
• Comply with regulations: in Bassem’s words, security is mandatory.

He grounds the argument in physical access control systems: attacks can target cards/smartcards or smartphone apps, and they can target the reader. The latter is “more catastrophic” if bypassed, because the reader often directly controls facility access—even though cards are easier to obtain and experiment with since they are distributed among users.

Two attack families: fault injection and side-channel

Bassem groups attacks into two high-level types.

1) Side-channel attacks (non-invasive observation):

• Monitor chip activity to infer sensitive information from power consumption, electromagnetic emissions, or timing patterns.

2) Fault injection (create unstable behavior):

• Force the chip into unstable states through induced faults so it leaks data or skips critical operations. Examples include focused laser to flip bits, power glitching, and clock glitching.

He then walks through how these attacks manifest and how secure coding patterns reduce their impact.

Fault injection in practice: what breaks and how to defend with code

Fault injection aims to make the program skip operations or miscompute in ways that undermine security. Bassem outlines several practical effects:

• Skipping security-critical operations (e.g., authentication steps, MAC verification) due to flipped bits in decision logic.
• Forcing buffer overflows by sending more data than expected; overflows can expose or overwrite sensitive RAM contents (such as keys). He refers to this as “damping the memory,” effectively meaning memory leakage.
• Blocking key loading; if an encryption routine runs with a zero key because loading was prevented, the attacker gains leverage since the “key” becomes a known value.

Example 1: One bit decides the door – don’t use plain booleans for security decisions

Bassem offers a clear example: a function decides whether to unlock a door or return an error. If the decision rests on a C-language boolean (0/1), a single bit flip can invert the outcome—from “deny access” to “unlock.”

His prescription: do not use simple booleans for security-sensitive decisions. Instead:

• Encode states in wider types with maximum Hamming distance between “secure false” and “secure true.”
• Define and check for invalid values. Encountering an invalid code must trigger a “security reset” or “trap.”

This makes it significantly harder for a single fault to shift the decision silently; it becomes detectable and fails safe.

Example 2: Prevent key-load sabotage with redundancy

To counter an attacker’s attempt to block key loading (leading to predictable “zero key” operations), introduce redundancy:

• Use two counters running in opposite directions for critical sequences.
• After each step, compare both counters.
• On mismatch, force a trap or security reset.

This pattern generalizes to any sequence where a missed step could silently degrade security—redundant progress tracking makes faults visible.

Additional fault-oriented patterns

Bassem enumerates several pragmatic patterns that help detect and contain faults:

• Avoid simple constant encodings for critical flags; prefer values with large Hamming distance.
• Avoid intermediate RAM buffers on communication paths that could be overrun and leak adjacent secrets.
• “Flow protection”: maintain a matching number updated at function entry and checked at exit to detect skipped code paths.
• Stack watermark: place a marker at the end of the stack and check it regularly to detect overflows.
• Data integrity: protect data using CRC; for single variables, keep a redundant inverted mirror and verify consistency.

Together these measures raise the attacker’s bar and transform many single-fault outcomes into safe traps rather than silent failures.

Side-channel attacks: watch and infer rather than tamper

Side-channel attacks do not alter the device; they observe it. Bassem lists several forms:

• Timing analysis: The time required for certain operations can reveal what the chip is doing and suggest sensitive data relationships.
• Power analysis: Monitoring power consumption with tools like an oscilloscope can expose activity patterns. He mentions both Simple Power Analysis (SPA) and the more sophisticated Differential Power Analysis (DPA).
• Communication response analysis: Analyzing responses from the device can provide clues about internal state.
• Heating/thermal behavior: Less obvious, but computation-induced heating may serve as a side channel.

While the talk focuses on raising awareness rather than cataloging mitigations for each side-channel, the coding implications are clear: treat side-channel exposure as a design constraint. Clean up sensitive variables, avoid unnecessary intermediate copies, and be conscious that control-flow and memory access patterns can produce measurable signals.

Memory hygiene and system cleanup: preventing leakage

Bassem repeatedly returns to a simple discipline that closes many doors:

• After cryptographic operations, clean sensitive variables.
• If the system has an internal cache, flush it to remove remnants of secrets.
• Avoid intermediate buffers in communication paths that could become leakage points via overflow or observation.

These steps directly reduce the footprint of secrets in memory and the observability of sensitive operations.

Composing the patterns into an end-to-end secure flow

What stood out to us is how the individual patterns reinforce each other when combined. A robust secure routine might:

1. Set/update a flow-protection matching number at function entry.
2. Track critical initialization and key-management steps with dual opposite-direction counters.
3. Represent state with Hamming-separated codes, handle invalid states by trapping/resetting.
4. Validate incoming data strictly, avoid intermediate buffers, and protect payloads with CRC.
5. Use redundant mirrors (inverted variables) and coherence checks after each critical segment.
6. Clean sensitive variables and flush caches before returning.
7. Validate the flow-protection value at function exit and trap/reset on mismatch.

This layered approach makes both fault exploitation and side-channel inference measurably harder. There is no single silver bullet; dependable security emerges from consistent checks, redundancy, and fail-safe defaults.

Where attacks hit in access control systems

Bassem’s framing within physical access systems is practical:

• Cards/smartcards or smartphone apps are easier for attackers to obtain and probe because they are widely distributed.
• Readers are physically harder to access but, if bypassed, the consequences are “more catastrophic,” as the reader often directly controls entry.

For firmware teams, this underscores a dual focus: harden the exposed endpoints and double down on protection where compromise would be most damaging.

Compliance and continuous improvement

The session closes with a reminder that security is ongoing work. Attacks are not static; they evolve. Therefore, we must:

• Continuously improve code and discover/apply new secure patterns.
• Keep visibility into what’s happening—test, validate, and monitor so emerging threats are detected early.
• Meet operating and regulatory requirements: security is mandatory.

Best practices distilled from the talk

• Encode security-relevant states with maximum Hamming distance; detect invalid values and trigger a security reset or trap.
• Add redundancy to critical sequences: dual counters in opposite directions, inverted mirror variables for single-value checks.
• Use flow protection (matching number) per function; verify on exit to catch skipped paths.
• Place and check a stack watermark to detect stack overflows.
• Avoid intermediate communication buffers; validate sizes and formats strictly.
• Protect data with CRC; keep variable-level redundancy with inverted mirrors for quick integrity checks.
• Practice memory hygiene: clean sensitive variables after cryptographic use and flush caches if present.
• Default to fail-safe behavior: inconsistencies or invalid states should cause traps/resets.

These guidelines come directly from Bassem’s walkthrough and map well onto embedded crypto and access control workflows.

Engineering lessons we’re taking away

• Functional is not enough: if decisions hinge on single bits, attackers will target those bits. Secure coding is part of making software “work.”
• Think in two axes: non-invasive observation (side-channel) and active disruption (fault injection) are the lenses for evaluating defenses.
• Defense in depth with small, composable checks is powerful: redundancy, integrity checks, and flow validation convert many single faults into safe failure.
• Low-cost, high-impact changes exist: replacing booleans with Hamming-separated encodings for critical decisions is a prime example.
• Security is a lifecycle discipline: design, test, validate, and keep improving as attacks evolve.

Conclusion: From functional code to dependable security

Bassem Taamallah’s “Importance of secure coding” makes the mechanics and mindset of secure embedded development tangible. The examples are memorable: a single bit turning “deny” into “unlock,” a blocked key load turning encryption into a zero-key exercise, a buffer overflow turning RAM into a disclosure channel. The remedies are equally concrete: distance-encoded states, redundancy with opposite counters, flow protection, CRC-backed integrity, memory cleanup, and fail-safe traps.

In access systems and beyond, the message is consistent: secure coding is part of shipping a product. As Bassem emphasizes, attacks keep changing—so our patterns must, too. Combine simple, robust techniques and treat every critical path as a candidate for fault and observation. That’s how we get from “it runs” to “it holds up.”

• 

  

  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.

  Watch now

• 

  

  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.

  Watch now

• 

  

  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.

  Watch now
• 

  

  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.

  Watch now