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.
TrustZone for Armv8-M has been designed for ARM microcontrollers (Cortex-M). …
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.
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…
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.
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 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:
Another day, another CPU-specific ‘speculative execution’ bug and another scary headline. The latest in the list is here- https://cpu.fail.
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.
Product Security | IoT Edge & Cloud Security | Security Strategist | Adversarial Resilience & Neural Networks