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 but soon realized that there are many ways for things to go wrong here. As an example, take the following snippet of code, it’s a tiny part of my original PoC that controls execution-flow from the bootloader to the application-image when provided with the application’s start-address. …
Introduction:
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.
- 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 but it turns out the same methods don’t really apply. …
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 to a friend, this feature lets you transfer cash without having to give out your phone-number or bank-details, assuming both of you are in ‘relative close proximity’. …
The market for commercial and law-enforcement related drone usage in India is set to explode in the next few years.
Applications include
- Precision farming or agriculture.
- Industrial inspections.
- 3D terrain mapping and image processing
- Border defense
- 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 resolve this very conundrum and possibly put India ahead of every other country in the UAV space. In some ways, it’s as ambitious as ‘Aadhaar’ in that we could be the first to have a fully functional nation-wide digital platform to identify, register, permit and monitor all UAV traffic (…provided we get it right). …
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:
- You need a unique device identity to securely — ‘authenticate your device’
- You need to make sure the code on your device is what you expect it to be — ‘firmware validation aka secure boot’
- You need to know that people can’t make (illegitimate) copies of your devices — ‘anti-cloning or counterfeit…
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 that requires a different set of mitigations. While I agree that the 3 new ones are different from Spectre, Meltdown or Foreshadow and there is no such thing as one-single mitigation to deal with this problem, these attacks exploit a particular vulnerability class called ‘speculative execution side-channel’ and each new attack is just another variant. …
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.
This (really) doesn’t paint a pretty picture but nonetheless, the open source community has been toiling away at the problem — slowly but steadily. The available tooling, frameworks, plugins etc. for modern binary analysis look something like this. …
In part 1, we explored the problem of ‘crypto-key storage’ in embedded environments and a solution to the problem - WhiteBox crypto. In part 2, we’ll look at the security of WhiteBoxes.
Nerd alert— This one’s a bit more hands on!
If you’re not the nerd type or if you’re interested in a quick overview, skip to the end for my observations and conclusions.
Intuition tells us that WB attacks are WB specific i.e. we have to
- Figure out the type of encodings
- Figure out which cipher operations were transformed into which network of lookup tables
- And then apply a crazy (algebraic) attack. …
About
