For certain high-security devices, such as card readers, ATMs, and hardware security modules, normal physical security isn’t enough – they need to wipe out their sensitive data if someone starts drilling through the case. Such devices, therefore, often integrate circuit meshes into their cases and regularly monitor them for changes that could indicate damage. To improve the sensitivity and accuracy of such countermeasures, [Jan Sebastian Götte] and [Björn Scheuermann] recently designed a time-domain reflectometer to monitor meshes (pre-print paper).

Many meshes are made from flexible circuit boards with winding traces built into the case, so cutting or drilling into the case breaks a trace. The problem is that most common ways to detect broken traces, such as by resistance or capacitance measurements, aren’t easy to implement with both high sensitivity and low error rates. Instead, this system uses time-domain reflectometry: it sends a sharp pulse into the mesh, then times the returning echoes to create a mesh fingerprint. When the circuit is damaged, it creates an additional echo, which is detected by classifier software. If enough subsequent measurements find a significant fingerprint change, it triggers a data wipe.

The most novel aspect of this design is its affordability. An STM32G4-series microcontroller manages the timing, pulse generation, and measurement, thanks to its two fast ADCs and a high-resolution timer with sub-200 picosecond resolution. For a pulse-shaping amplifier, [Jan] and [Björn] used the high-speed amplifiers in an HDMI redriver chip, which would normally compensate for cable and connector losses. Despite its inexpensive design, the circuit was sensitive enough to detect when oscilloscope probes contacted the trace, pick up temperature changes, and even discern the tiny variations between different copies of the same mesh.

It’s not absolutely impossible for an attacker to bypass this system, nor was it intended to be, but overcoming it would take a great deal of skill and some custom equipment, such as a non-conductive drill bit. If you’re interested in seeing such a system in the real world, check out this teardown of a payment terminal. One of the same authors also previously wrote a KiCad plugin to generate anti-tamper meshes.

Thanks to [mark999] for the tip!

Today’s PCs are locked up with Trusted Platform Module (TPM) devices so much so that modern Windows versions insist on having a recent TPM to even install. These have become so prevalent that even larger embedded boards now have TPM and, of course, if you are repurposing consumer hardware, you’ll have to deal with it, too. [Sigma Star] has just the primer for you. It explains what TPM does, how it applies to embedded devices, and where the pitfalls are.

The TPM is sometimes a chip or sometimes secure firmware that is difficult to tamper with. They provide secret storage and can store boot signatures to detect if something has changed how a computer starts up. The TPM can also “sign off” that the system configuration is the same to a remote entity. This allows, for example, a network to prevent a hacked or rogue computer from communicating with other computers.

Embedded systems, usually, aren’t like PCs. A weather station at a remote location may have strangers poking at it without anyone noticing. Also, that remote computer might be expected to be working for many more years than a typical laptop or desktop computer.

This leads to a variety of security concerns that TPM 2.0 attempts to mitigate. For example, it is unreasonable to think a typical attacker might connect a logic analyzer to your PC, but for an embedded system, it is easier to imagine. There is a session-based encryption to protect against someone simply snooping traffic off the communication bus. According to the post, not all implementations use this encryption, however.

Motherboard has a slot for TPM, but no board? We’ve seen people build their own TPM boards.

Title image by [Raimond Spekking] CC BY-SA-4.0

A joy of covering the world of the European hackerspace community is that it offers the chance for train travel across the continent using the ever-good-value Interrail pass. For a British traveler such a journey inevitably starts with a Eurostar train that whisks you in comfort through the Channel Tunnel, so a report of an AI vulnerability on the Eurostar website from [Ross Donald] particularly caught our eye. What it reveals goes beyond the train company, and tells us some interesting tidbits about how safeguards in AI chatbots can be circumvented.

The bot sits on the Eurostar website, and is a simple HTML and JavaScript client that talks to the LLM back-end itself through an API. The API queries contain the whole conversation, because as AI toy manufacturers whose products have been persuaded to spout adult context will tell you, large language models (LLM)s as commonly implemented do not have a context memory for the conversation in hand.

The Eurostar developers had not made a bot without guardrails, but the vulnerability lay in those guardrails only being applied to the most recent message. Thus an innocuous or empty message could be sent, with a payload concealed in a previous message in the conversation. He demonstrates the bot returning system information about itself, and embedding injected HTML and JavaScript in its responses.

He notes that the target of the resulting output could only be himself and that he was unable to access any data from other customers, so perhaps in this case the train operator was fortunately spared the risk of a breach. From his description though, we agree they could have responded to the disclosure in a better manner.

Header image: Eriksw, CC BY-SA 4.0.