afd5856c26183402eae…
afd5856c26183402eae1979cb49fc8965c50257b3ac452d0ae6a7da0d21bb49a
afd5856c26183402eae1979cb49fc8965c50257b3ac452d0ae6a7da0d21bb49a
TL;DR: Power failures during TPM operations can leave edge devices in an inconsistent state – secure but unusable. This blog post dives into how EVE OS proactively solves this, ensuring reliable self-recovery without compromising security.
While I researching the recently added Linux kernel TPM HMAC protection (read about it here), I looked around and found a 20-year‑old, straight out of 90’s [4], classic buffer overflow in one of the Infineon TPM drivers [1] [2]:
The title is my attempt at humor and a excuse to discuss a security model introduced way back in the 1970s [1][2]. I can’t exactly remember where I first read about the inherent covert channel in the BLP design, but it stuck with me as one of the earliest (and one of the most interesting) protocol design flaws I came across.
The discrete TPMs (dTPM) have had a rough ride over the past few decades. They’ve faced numerous bugs, some fixable, others built right into the way it works. Because dTPMs are physically exposed, they’ve always been an interesting target to attack, and in most scenarios when high value devices have to operate autonomously and unsupervised, dTPM provides little to no practical security.
TL;DR: Some devices with certain fTPMs failed updates because their TPM didn’t like ECC keys without proper padding, throwing “point is not on the required curve.” when calculating ECDH shared key using ECDHZGen because off-spec fTPMs and X.Bytes() in Golang will put you in trouble.
EVE OS uses TPM as one of its core security components. A while back I was trying to make the TPM related functionality more robust in presence of faulty TPMs, so I wrote a small tool to inject faults into the TPM and test the system’s resilience.
I’ve put together some slides on how we used to do security requirement engineering at Mbition. The approach builds on threat modeling as the main activity for eliciting security requirements [1,2,3], uses EARS [4] for specification, and relies on a modified Volere [5] template for documentation. A key idea is to write reusable security requirements [6,7], gradually building up a security…
I was browsing the MS-DOS source code and I was thinking is it possible to have a preemptive scheduler in a 16-bit OS running purely in real-mode? I think it should be possible.
A few years ago, I was tasked to write a grammar fuzzer, I started looking at EBNF and BNF formats and one of the first (obvious?) ideas that popped in to my head was to convert the given grammar to a graph and then randomly walk the graph from a node with some ending condition to derive an instance of the grammar. The final fuzzer was more complicated but anyways here is the algorithm I came up…