{"id":15247,"date":"2020-01-08T21:14:26","date_gmt":"2020-01-08T17:14:26","guid":{"rendered":"https:\/\/me-en.kaspersky.com\/blog\/36c3-open-source-hardware-dangers\/15247\/"},"modified":"2020-01-08T21:14:34","modified_gmt":"2020-01-08T17:14:34","slug":"36c3-open-source-hardware-dangers","status":"publish","type":"post","link":"https:\/\/me-en.kaspersky.com\/blog\/36c3-open-source-hardware-dangers\/15247\/","title":{"rendered":"Open source is not a cure-all"},"content":{"rendered":"

With many believing open-source software is more secure than proprietary software, we are now also seeing attempts to apply a similar theory to hardware development. At the 36th Chaos Communication Congress<\/a> (36C3) hackers\u2019 conference last month, however, experts Andrew \u201cbunnie\u201d Huang, Sean \u201cxobs\u201d Cross, and Tom Marble raised doubts<\/a> about whether employing open-source development is enough to solve trust problems in hardware. Huang spoke at length on the topic.<\/p>\n

Differences between hardware and software in terms of trust<\/h2>\n

Open-source software\u2019s safety lies not only in its openness, but also in widely used tools that help ensure the program you run at the endpoint is true to the published source code. Programmers sign their software with a digital certificate, for example, and the system checks the certificate before running the software on a user\u2019s computer.<\/p>\n

With hardware, it\u2019s a different story. With no hardware analogs for hashing or digital signatures, users have no tools to check hardware\u2019s authenticity against published information about it. The last time a device or chip is actually checked is at the factory. And the longer the gap between factory check and device use, the greater the chance of a successful MITM attack.<\/p>\n

What can go wrong?<\/h2>\n

Generally speaking, anything at all can happen to chips or entire devices between leaving the factory and being used for the first time. To begin with, firmware can be replaced. (Sure, firmware is actually a software problem, so it can be verified, but you still have to rely on hardware during verification.) That\u2019s why Huang focused on problems \u2014 component replacements, modifications, and implants \u2014 having to do strictly with hardware.<\/p>\n

Adding components<\/h3>\n

These days, a totally unauthorized module can fit into a charging cable\u2019s USB connector<\/a>. Naturally, it\u2019s even easier to tamper with more sophisticated multicomponent equipment that provides much more room for implants. The only good news here is that it\u2019s relatively easy to detect added chip.<\/p>\n

Substituting components<\/h3>\n

The simplest substitution trick is to tamper with marking. One real-life example: A misbehaving microcontroller showed, on visual check, to have the right mark (from STMicroelectronics) on an altogether different chip. That time, the cheat was an expensive component replaced with a cheap one, but the replacement could have contained anything at all.<\/p>\n

Chip modification<\/h3>\n

People tend to think that chips cannot be modified once out of the factory, but that is not so. In many cases what we see as a single chip is actually several separate microcircuits in one package. An experienced adversary can use the same technology to put one more tiny piece of silicon into the very same package and connect this implant to existing contacts.<\/p>\n

\"Chip-on-chip<\/a>

Chip-on-chip implant. Image source<\/a><\/p><\/div>\n

In fact, equipment to do just that is relatively inexpensive and readily available (according to the speaker, a used wirebonding machine from China costs about $7,000), although the falsified results will be detectible in X-rays.<\/p>\n

Wafer-level chip-scale packages (WL-CSP) are much costlier to modify, but X-rays won\u2019t reveal the deception.<\/p>\n

Integrated circuit (IC) modification<\/h3>\n

Typically, companies design chips for their field-specific tasks but outsource them for production; only large market players can afford to produce their own chips. In this kind of arrangement, there is more than one way to modify the end product such that it still complies with the terms of reference. Moreover, after a chip or device is out of the designers\u2019 hands, it\u2019s rare anyone bothers to cross-check the resulting product against the original specifications.<\/p>\n

At what point can hardware be altered?<\/h2>\n

The presenter offered several substitution scenarios ranging from fairly tricky (in-transit interception of cargo<\/a> as an extreme example) to comparatively easy. Broadly speaking, anybody can buy a product, tamper with it, and return it to the seller, who can sell it again. And, formally, at various stages of procurement, the manufacturer\u2019s packing team, customs agents, and many more parties have access to the equipment, and any of them can tamper with it if they choose. For all intents and purposes, using open-source hardware will not improve security much.<\/p>\n

Conclusions<\/h2>\n

Toward the end of his presentation, Huang speculated about what hardware production changes could enable end users to verify the safety of chips and devices. Those interested in the movement\u2019s philosophy, as well as the technical details of chip modification, should view the presentation video<\/a>.<\/p>\n

Not all of the many ways to make hardware dangerous are expensive or laborious, and most important, there is no direct correlation between an attack\u2019s complexity and how difficult it is to detect. As for business users, stay mindful of the threat and do not rely solely on endpoint security products; corporate infrastructure protection systems fend off advanced threats and targeted attacks<\/a>.<\/p>\n","protected":false},"excerpt":{"rendered":"

A Chaos Communication Congress speaker reflects on whether using open-source hardware can solve trust problems in hardware.<\/p>\n","protected":false},"author":700,"featured_media":15250,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1318,1916],"tags":[2211,1618,1619,1613,1969],"class_list":{"0":"post-15247","1":"post","2":"type-post","3":"status-publish","4":"format-standard","5":"has-post-thumbnail","7":"category-business","8":"category-enterprise","9":"tag-36c3","10":"tag-ccc","11":"tag-chaos-communication-congress","12":"tag-hardware","13":"tag-open-source"},"hreflang":[{"hreflang":"en-ae","url":"https:\/\/me-en.kaspersky.com\/blog\/36c3-open-source-hardware-dangers\/15247\/"},{"hreflang":"en-in","url":"https:\/\/www.kaspersky.co.in\/blog\/36c3-open-source-hardware-dangers\/18372\/"},{"hreflang":"ar","url":"https:\/\/me.kaspersky.com\/blog\/36c3-open-source-hardware-dangers\/7352\/"},{"hreflang":"en-us","url":"https:\/\/usa.kaspersky.com\/blog\/36c3-open-source-hardware-dangers\/20126\/"},{"hreflang":"en-gb","url":"https:\/\/www.kaspersky.co.uk\/blog\/36c3-open-source-hardware-dangers\/18434\/"},{"hreflang":"es-mx","url":"https:\/\/latam.kaspersky.com\/blog\/36c3-open-source-hardware-dangers\/16859\/"},{"hreflang":"es","url":"https:\/\/www.kaspersky.es\/blog\/36c3-open-source-hardware-dangers\/20876\/"},{"hreflang":"it","url":"https:\/\/www.kaspersky.it\/blog\/36c3-open-source-hardware-dangers\/19624\/"},{"hreflang":"ru","url":"https:\/\/www.kaspersky.ru\/blog\/36c3-open-source-hardware-dangers\/25995\/"},{"hreflang":"tr","url":"https:\/\/www.kaspersky.com.tr\/blog\/36c3-open-source-hardware-dangers\/7532\/"},{"hreflang":"x-default","url":"https:\/\/www.kaspersky.com\/blog\/36c3-open-source-hardware-dangers\/32015\/"},{"hreflang":"pt-br","url":"https:\/\/www.kaspersky.com.br\/blog\/36c3-open-source-hardware-dangers\/13888\/"},{"hreflang":"pl","url":"https:\/\/plblog.kaspersky.com\/36c3-open-source-hardware-dangers\/12622\/"},{"hreflang":"de","url":"https:\/\/www.kaspersky.de\/blog\/36c3-open-source-hardware-dangers\/21868\/"},{"hreflang":"ja","url":"https:\/\/blog.kaspersky.co.jp\/36c3-open-source-hardware-dangers\/26606\/"},{"hreflang":"nl","url":"https:\/\/www.kaspersky.nl\/blog\/36c3-open-source-hardware-dangers\/24798\/"},{"hreflang":"ru-kz","url":"https:\/\/blog.kaspersky.kz\/36c3-open-source-hardware-dangers\/20813\/"},{"hreflang":"en-au","url":"https:\/\/www.kaspersky.com.au\/blog\/36c3-open-source-hardware-dangers\/25658\/"},{"hreflang":"en-za","url":"https:\/\/www.kaspersky.co.za\/blog\/36c3-open-source-hardware-dangers\/25489\/"}],"acf":[],"banners":"","maintag":{"url":"https:\/\/me-en.kaspersky.com\/blog\/tag\/36c3\/","name":"36c3"},"_links":{"self":[{"href":"https:\/\/me-en.kaspersky.com\/blog\/wp-json\/wp\/v2\/posts\/15247","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/me-en.kaspersky.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/me-en.kaspersky.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/me-en.kaspersky.com\/blog\/wp-json\/wp\/v2\/users\/700"}],"replies":[{"embeddable":true,"href":"https:\/\/me-en.kaspersky.com\/blog\/wp-json\/wp\/v2\/comments?post=15247"}],"version-history":[{"count":1,"href":"https:\/\/me-en.kaspersky.com\/blog\/wp-json\/wp\/v2\/posts\/15247\/revisions"}],"predecessor-version":[{"id":15249,"href":"https:\/\/me-en.kaspersky.com\/blog\/wp-json\/wp\/v2\/posts\/15247\/revisions\/15249"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/me-en.kaspersky.com\/blog\/wp-json\/wp\/v2\/media\/15250"}],"wp:attachment":[{"href":"https:\/\/me-en.kaspersky.com\/blog\/wp-json\/wp\/v2\/media?parent=15247"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/me-en.kaspersky.com\/blog\/wp-json\/wp\/v2\/categories?post=15247"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/me-en.kaspersky.com\/blog\/wp-json\/wp\/v2\/tags?post=15247"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}