PUF Away For Hardware Fingerprinting

April 17, 2023 by Matthew Carlson 9 Comments

Despite the rigorous process controls for factories, anyone who has worked on hardware can tell you that parts may look identical but are not the same. Everything from silicon defects to microscopic variations in materials can cause profoundly head-scratching effects. Perhaps one particular unit heats up faster or locks up when executing a specific sequence of instructions and we throw our hands up, saying it’s just a fact of life. But what if instead of rejecting differences that fall outside a narrow range, we could exploit those tiny differences?

This is where physically unclonable functions (PUF) come in. A PUF is a bit of hardware that returns a value given an input, but each bit of hardware has different results despite being the same design. This often relies on silicon microstructure imperfections. Even physically uncapping the device and inspecting it, it would be incredibly difficult to reproduce the same imperfections exactly. PUFs should be like the ideal version of a fingerprint: unique and unforgeable.

Because they depend on manufacturing artifacts, there is a certain unpredictability, and deciding just what features to look at is crucial. The PUF needs to be deterministic and produce the same value for a given specific input. This means that temperature, age, power supply fluctuations, and radiation all cause variations and need to be hardened against. Several techniques such as voting, error correction, or fuzzy extraction are used but each comes with trade-offs regarding power and space requirements. Many of the fluctuations such as aging and temperature are linear or well-understood and can be easily compensated for.

Broadly speaking, there are two types of PUFs: weak and strong. Weak offers only a few responses and are focused on key generation. The key is then fed into more traditional cryptography, which means it needs to produce exactly the same output every time. Strong PUFs have exponential Challenge-Response Pairs and are used for authenticating. While strong PUFs still have some error-correcting they might be queried fifty times and it has to pass at least 95% of the queries to be considered authenticated, allowing for some error. Continue reading “PUF Away For Hardware Fingerprinting” →

Hackaday Links: April 16, 2023

April 16, 2023 by Dan Maloney 25 Comments

The dystopian future you’ve been expecting is here now, at least if you live in New York City, which unveiled a trio of technology solutions to the city’s crime woes this week. Surprisingly, the least terrifying one is “DigiDog,” which seems to be more or less an off-the-shelf Spot robot from Boston Dynamics. DigiDog’s job is to de-escalate hostage negotiation situations, and unarmed though it may be, we suspect that the mission will fail spectacularly if either the hostage or hostage-taker has seen Black Mirror. Also likely to terrify the public is the totally-not-a-Dalek-looking K5 Autonomous Security Robot, which is apparently already wandering around Times Square using AI and other buzzwords to snitch on people. And finally, there’s StarChase, which is based on an AR-15 lower receiver and shoots GPS trackers that stick to cars so they can be tracked remotely. We’re not sure about that last one either; besides the fact that it looks like a grenade launcher, the GPS tracker isn’t exactly covert. Plus it’s only attached with adhesive, so it seems easy enough to pop it off the target vehicle and throw it in a sewer, or even attach it to another car.

Continue reading “Hackaday Links: April 16, 2023” →

Sufficiently Advanced Tech: Has Bugs

April 15, 2023 by Elliot Williams 74 Comments

Arthur C. Clarke said that “Any sufficiently advanced technology is indistinguishable from magic”. He was a sci-fi writer, though, and not a security guy. Maybe it should read “Any sufficiently advanced tech has security flaws”. Because this is the story of breaking into a car through its headlight.

In a marvelous writeup, half-story, half CAN-bus masterclass, [Ken Tindell] details how car thieves pried off the front headlight of a friend’s Toyota, and managed to steal it just by saying the right things into the network. Since the headlight is on the same network as the door locks, pulling out the bulb and sending the “open the door” message repeatedly, along with a lot of other commands to essentially jam some other security features, can pull it off.

Half of you are asking what this has to do with Arthur C. Clarke, and the other half are probably asking what a lightbulb is doing on a car’s data network. In principle, it’s a great idea to have all of the electronics in a car be smart electronics, reporting their status back to the central computer. It’s how we know when our lights are out, or what our tire pressure is, from the driver’s seat. But adding features adds attack surfaces. What seems like magic to the driver looks like a gold mine to the attacker, or to car thieves.

With automotive CAN, security was kind of a second thought, and I don’t mean this uncharitably. The first goal was making sure that the system worked across all auto manufacturers and parts suppliers, and that’s tricky enough. Security would have to come second. And more modern cars have their CAN networks encrypted now, adding layers of magic on top of magic.

But I’m nearly certain that, when deciding to replace the simple current-sensing test of whether a bulb was burnt out, the engineers probably didn’t have the full cost of moving the bulb onto the CAN bus in mind. They certainly had dreams of simplifying the wiring harness, and of bringing the lowly headlight into the modern age, but I’d bet they had no idea that folks were going to use the headlight port to open the doors. Sufficiently advanced tech.

Fail Of The Week: Car Starter Motors Aren’t The Best Fit For EBikes

April 14, 2023 by Dan Maloney 40 Comments

A lot of what real engineering is all about is designing to the limits of your materials, with a healthy margin for error. On the other hand, seat-of-the-pants engineering often takes the opposite tack — working with the materials you have and finding their limits after the fact. While the former is more rigorous and better suited to anything where life and limb are on the line, there’s something to be said for the flexibility that informal engineering offers.

[Austin Blake]’s latest eBike is a case study in informal engineering. [Austin] started out wondering if a starter motor from a car engine would make a decent electric bike motor. Our first instinct before watching the video below was to answer that question with a resounding “No!” Yes, starter motors seem like a natural for the job, delivering high torque in a compact package. But starting a car engine is the very definition of a low-duty-cycle application, since it should only take a second or two of cranking to get an engine started. Pressing a motor designed for such a task into continuous duty seems like, well, a non-starter.

And to be fair, [Austin] fully acknowledges this from the start. He even retrofits the motor, wisely replacing the shaft bushings with proper bearings in an attempt to get a better duty cycle. And it works, at least for a while — with the motor, a homebrew battery, and an ESC mounted to a bike frame, the bike was actually pretty peppy. But bearings aren’t the only thing limiting a starter motor to intermittent duty operation. The short drive really heated up the motor, and even with a few ventilation holes knocked in the motor housing, it eventually released the Magic Smoke. The video has all the gory details.

As always, we like to stress that “Fail of the Week” is not necessarily a badge of shame. We appreciate it whenever someone shows us the way not to go, as [Austin] did here. And let’s keep in mind that he’s had success with this approach before, albeit with a much, much bigger starter motor.

Continue reading “Fail Of The Week: Car Starter Motors Aren’t The Best Fit For EBikes” →

Retro Gadgets: The 1983 Pocket Oscilloscope

April 14, 2023 by Al Williams 29 Comments

In the 1980s, an oscilloscope was typically a bulky affair with a large CRT, and a heavy power supply. So it probably grabbed a lot of attention in 1983 when Calvert Instruments Incorporated ran an ad in magazines like Radio Electronics. The ad touted a 5 MHz scope that was pocket-sized and weighed 4 ounces. The ad proudly proclaimed: CRT oscilloscopes just became obsolete!

Indeed they would, but if you are wondering who Calvert Instruments was, so are we. We have never heard of them before or since, and we don’t know for certain if any of these devices were ever actually produced. What did it use instead of a CRT? The CI Model 210 Pocket-O-Scope was not only solid state but used an LED screen 1.5 inches square. That’s small, but it packed in 210 LEDs for “high resolution.” We assume that was also the genesis of the model number. Judging from the product picture, there were 14 LEDs in the X direction and 15 in the Y direction. High resolution, for sure!

There were some early LCD scopes (like the Iskrascope and one from Scopex) around the same time, but it would be the 1990s before we would see LCD oscilloscopes and even longer before CRTs were totally squeezed out.

Continue reading “Retro Gadgets: The 1983 Pocket Oscilloscope” →

This Week In Security: QueueJumper, JS VM2 Escape, And CAN Hacking

April 14, 2023 by Jonathan Bennett 9 Comments

You may not be familiar with the Microsoft Message Queuing (MSMQ) service, a store and forward sort of inter-process and inter-system communication service. MSMQ has become something of a legacy product, but is still available as an optional component in Windows. And in addition to other enterprise software solutions, Microsoft Exchange turns the service on by default. That’s why it’s a bit spooky that there’s a one packet Remote Code Execution (RCE) vulnerability that was just patched in the service.

CVE-2023-21554, also known as QueueJumper, is this unauthenticated RCE with a CVSS score of 9.8. It requires sending a packet to the service on TCP port 1801. The Check Point Research team scanned for listening MSMQ endpoints on the public Internet, and found approximately 360,000 of them. And no doubt far more are listening on internal networks. A one packet exploit is a prime example of a wormable problem, and now that the story has broken, and the patch is available, expect a rapid reverse engineering. Beware, the queue jumpers are coming.

JavaScript VM Escape

The VM2 library is a rather important JavaScript package that sandboxes code, letting a project run untrusted code securely. Or, that’s the idea. CVE-2023-29017 is an example of how hard sandboxing is to get right. It’s another CVSS 9.8 vulnerability, and this one allows a sandbox escape and code execution.

This one now has public Proof of Concept code, and this package has over 16 million monthly installs, so the attack surface is potentially pretty wide. The flaw is fixed in version 3.9.15. Continue reading “This Week In Security: QueueJumper, JS VM2 Escape, And CAN Hacking” →

Tinkercad Gets A Move On

April 13, 2023 by Al Williams 22 Comments

Going to the movies is an experience. But how popular do you think they’d be if you went in, bought your popcorn, picked your seat, and the curtain would rise on a large still photograph? Probably not a great business model. If a picture is worth 1,000 words, then a video is worth at least a million, and that’s why we thought it was awesome that Tinkercad now has a physics simulator built right in.

Look for this icon on the top right toolbar.

It all starts with your 3D model or models, of course. Then there’s an apple icon. (Like Newton, not like Steve Jobs.) Once you click it, you are in simulation mode. You can select objects and make them fixed or movable. You can change the material of each part, too, which varies its friction, density, and mass. There is a play button at the bottom. Press it, and you’ll see what happens. You can also share and you have the option of making an MP4 video like the ones below.

We, of course, couldn’t resist. We started with a half-sphere and made it larger. We also rotated it so the flat side was up. We then made a copy that would become the inside of our bowl. Using the ruler tool, we shaved about 2 mm off the length and width (X and Y) of the inner sphere. We also moved it 2 mm up without changing the size.

Using the alignment tools, you can then center the inner piece in the X and Y axis. Change the inner color to a hole and group the objects. This forms a simple bowl shape. Then we moved the workplane to a random part of the inner surface of our bowl and dropped a sphere. Nothing complicated.

Continue reading “Tinkercad Gets A Move On” →