Skip to main content

36C3: Open Source is Insufficient to Solve Trust Problems in Hardware

With open source software, we’ve grown accustomed to a certain level of trust that whatever we are running on our computers is what we expect it to actually be. Thanks to hashing and public key signatures in various parts in the development and deployment cycle, it’s hard for a third party to modify source code or executables without us being easily able to spot it, even if it travels through untrustworthy channels.

Unfortunately, when it comes to open source hardware, the number of steps and parties involved that are out of our control until we have a final product — production, logistics, distribution, even the customer — makes it substantially more difficult to achieve the same peace of mind. To make things worse, to actually validate the hardware on chip level, you’d ultimately have to destroy it.

On his talk this year at the 36C3, [bunnie] showed a detailed insight of several attack vectors we could face during manufacturing. Skipping the obvious ones like adding or substituting components, he’s focusing on highly ambitious and hard to detect modifications inside an IC’s package with wirebonded or through-silicon via (TSV) implants, down to modifying the netlist or mask of the integrated circuit itself. And these aren’t any theoretical or “what if” scenarios, but actual possible options — of course, some of them come with a certain price tag, but in the end, with the right motivation, money is only a detail.

Sure, none of this is particularly feasible or even much of interest at all for a blinking LED project, but considering how more and more open source hardware projects emerge to replace fully proprietary components, especially with a major focus on privacy, a lack of trust in the hardware involved along the way is surely worrying to say the least. At this point, there is no perfect solution in sight, but FPGAs might just be the next best thing, and the next part of the talk is presenting the Betrusted prototype that [bunnie] is working on together with [xobs] and [Tom Marble]. That alone makes the talk worth watching, in our view.



from Hackaday https://ift.tt/39xFgZA

Comments

Popular posts from this blog

How To Play Doom – And More – On An NES

Doom was a breakthrough game for its time, and became so popular that now it’s essentially the “Banana For Scale” of hardware hacking. Doom has been ported to countless devices, most of which have enough processing ability to run the game natively. Recently, this lineup of Doom-compatible devices expanded to include the NES even though the system definitely doesn’t have enough capability to run it without special help. And if you want your own Doom NES cartridge, this video will show you how to build it . We featured the original build from [TheRasteri] a while back which goes into details about how it’s possible to run such a resource-intensive game on a comparatively weak system. You just have to enter the cheat code “RASPI”. After all the heavy lifting is done, it’s time to put it into a realistic-looking cartridge. To get everything to fit in the donor cartridge, first the ICs in the cartridge were removed (except the lockout IC) and replaced with custom ROM chips. Some modifica...

The Flexible Permanence of Copper Tape Circuits

Somewhere between shoving components into a breadboard temporarily and committing them to a piece of protoboard or a PCB lies the copper tape method. This flexible Manhattan-style method of circuitry formed the basis for [Bunnie Huang]’s Chibitronics startup, and has since inspired many to stop etching boards and start fetching hoards of copper tape. [Hales] hit the ground running when he learned about this method , and has made many a copper tape circuit in the last year or so. He offers several nice tips on his site that speak from experience with this method, and he’ll even show you how to easily work an SMD breakout board into the mix. Generally speaking, [Hales] prefers plywood as the substrate to paper or cardboard for durability. He starts by drawing out the circuit and planning where all the tape traces will go and how wide they need to be. Then he lays out copper traces and pads, rubs the tape against the substrate to make it adhere strongly, and reinforces joints and laps w...

The Newbie’s Guide To JTAG

Do you even snarf? If not, it might be because you haven’t mastered the basics of JTAG and learned how to dump, or snarf, the firmware of an embedded device. This JTAG primer will get you up to snuff on snarfing, and help you build your reverse engineering skills. Whatever your motivation for diving into reverse engineering devices with microcontrollers, JTAG skills are a must, and [Sergio Prado]’s guide will get you going. He starts with a description and brief history of the Joint Test Action Group interface, from its humble beginnings as a PCB testing standard to the de facto standard for testing, debugging, and flashing firmware onto devices. He covers how to locate the JTAG pads – even when they’ve been purposely obfuscated – including the use of brute-force tools like the JTAGulator . Once you’ve got a connection, his tutorial helps you find the firmware in flash memory and snarf it up to a file for inspection, modification, or whatever else you have planned. We always apprec...