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
Labels:

Comments

Post a Comment

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...
Post a Comment
Read more

Try NopSCADlib for your Next OpenSCAD Project

Most readers of this site are familiar by now with the OpenSCAD 3D modeling software, where you can write code to create 3D models. You may have even used OpenSCAD to output some STL files for your 3D printer. But for years now, [nophead] has been pushing OpenSCAD further than most, creating some complex utility and parts libraries to help with modeling, and a suite of Python scripts that generate printable STLs, laser-ready DXFs, bills of material, and human-readable assembly instructions complete with PNG imagery of exploded-view sub-assemblies. Recently [nophead] tidied all of this OpenSCAD infrastructure up and released it on GitHub as NopSCADlib . You can find out more by browsing through the example projects and README file in the repository, and by reading the announcement blog post on the HydraRaptor blog . Some functionality highlights include: a large parts library full of motors, buttons, smooth rod, et cetera many utility functions to help with chamfers, fillets, precis...
Post a Comment
Read more

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...
Post a Comment
Read more