Identity based networking for embedded systems

I’ve been evaluating `TLS replacements` in constrained/embedded systems for a while now. Embedded systems have fewer (yet precise) security requirements, owing to available resources.

Machines, unlike people don’t need to talk to every other machine/device on the planet. They are designed to perform a specific set of functions. Functions that most likely require them to communicate with a predetermined set of peers/hosts.

The vast majority of embedded systems communicate with a `known or predetermined` set of peers.

However, clearly identifying a machine/device/entity is a non trivial undertaking, even today.

Right about now, you must be thinking — don’t we have…

A few weeks ago, I happen to revisit a ‘Rust’ project of mine — a barebones embedded bootloader, hoping to re-use and extend it. I chose ‘rust-lang’ (over C) to write a security-focused ‘cortex-m’ bootloader, so that I could take advantage of rust’s memory-safety properties (other considerations such as size and performance being equal).

My requirements for the bootloader were as follows — boot the system, interface with a hardware root of trust, verify a signed boot-image using ECC and perform ‘downloaded software upgrades’ (or DSU).

At first glance, this seemed relatively straightforward, given that I already have a PoC…


TrustZone is different from that of a separate physical security co-processor (like a TPM or a secure element) with a pre-defined set of features. You can think of it as a virtualization technology for ARM CPUs i.e. it virtualizes a physical ARM CPU core — a TrustZone enabled ARMv8 core can exist in one of 2 states Secure OR Non-Secure. This, in turn, allows us to partition all system HW and SW resources so that they exist in 1 of the 2 worlds.

Execution view of a TrustZone enabled ARMv8-M processor core.

TrustZone for Armv8-M has been designed for ARM microcontrollers (Cortex-M). …

A code sequence with good auto-correlation properties yields a Gaussian-distribution of cross-correlation scores.

In the last part, we were able to recover the data-signal by un-mixing (i.e. de-spreading) the base-band signal..

We then proceeded to demodulation and discovered that the signal is MFSK modulated (i.e. Multiple Frequency Shift Keyed).

To be more precise, we are fairly confident or rather have enough information to assume it’s MFSK-16 i.e. uses 16 different tones for data transfer.

So, lets pick up where we left Part2.

  • Symbol Extraction*
  • Symbol decoding*
  • Token recovery*

7. Symbol Extraction

So, how do we demodulate an MFSK-modulated signal?

At first, I thought it shouldn't be any different from demodulating something like Binary FSK or 2-FSK…

Recording cash mode’s ‘near-ultrasound’ signal.

I finally managed to give this project my undivided attention. All it took was a world-stopping event -a stupid virus.

To recap from Part1

Google pay ‘Tez-mode’ (also called ‘cash-mode’) uses near-ultrasound to discover and pair parties. ‘Cash mode’ does not rely on RF-based technologies like (Bluetooth, Wi-Fi, NFC etc.) for data transfer and leverages ‘sound’ instead, which has certain advantages (such as it doesn’t pass through walls).

More precisely, ‘cash-mode’ tries to establish physical co-presence by transmitting a short 8 digit token as inaudible sound.

Put simply, if you want to transfer some money…

The market for commercial and law-enforcement related drone usage in India is set to explode in the next few years.

Applications include

  1. Precision farming or agriculture.
  2. Industrial inspections.
  3. 3D terrain mapping and image processing
  4. Border defense
  5. Hyper-local delivery (including medical supplies)

In short, it’s a huge green-field opportunity but there’s a BIG catch.

There are numerous concerns about a ‘precarious’ future where our skies could be flooded with little flying robots without the oversight of a ‘digitally enforceable’ regulatory framework (key-word being ‘digital’ here).

NPNT or No-permission No-take-off (which forms the foundation of India’s RPAS or drone policy) attempts to…

The esp32 (IoT) board connected to a 0.50$ crypto-processor (atecc608a)

The goal— Evaluate how one could vastly improve security in any IoT project with just 0.50$. (yes, including that 10$ thing that has no business being connected to the internet.)

When you think about embedded-device security, pretty much most if not all requirements (i.e. use-cases) depend on some kind of crypto. Ex:

  1. You need a unique device identity to securely — ‘authenticate your device’
  2. You need to make sure the code on your device is what you expect it to be — ‘firmware validation aka secure boot’
  3. You need to know that people can’t make (illegitimate) copies of your devices…

Quite the attention grabber!

Another day, another CPU-specific ‘speculative execution’ bug and another scary headline. The latest in the list is here-

This is usually accompanied by speculation (pun intended) and hysteria, attributable to a lack of understanding of the inner workings of ‘processor microarchitectures’. I’ve had the opportunity to speak to many different security teams who deal with such attack(s) (or attack variants) over the course of the last year.

Invariably, all of them seem to be grappling with new variants coming their way. I think the problem lies in our approach. Every variant ends-up being treated as an entirely new problem…

Started work on a new (sort of) project of mine over the weekend — “Reverse-engineer a random blob of binary recovered from a downloaded firmware image.

Half-way into it, I realized this topic (is something that) doesn’t seem to get the attention it so desperately needs or rather I couldn’t find enough public discussions on the subject, especially given its current state — ‘Firmware analysis and its challenges’

A quick summary of my thoughts on the subject (in a couple of mind-maps) and an *advertisement* for an open-source analysis framework that attempts to address some of these challenges.

A mind map of challenges I’ve had to deal with in analyzing firmware.

This (really)…

Nihal Pasham

Product Security | IoT Edge & Cloud Security | Security Strategist | Adversarial Resilience & Neural Networks

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store