Chip Fingerprinting Scheme Could Secure IoT Devices Against Malware
Illustration: iStockPhoto

With the coming Internet of Things (IoT) in mind, Mitsubishi Electric, Ritsumeikan University, and the Japan Science and Technology Agency have developed a security scheme that can be used to identify individual logic chips by their “fingerprints.” The scheme provides a means of preventing device spoofing, as well as a way to authenticate embedded software running on networked devices and so prevent malicious programs from being introduced.

Chips with the same circuitry produce the same computed results when processing the same input. However, small variations in the circuitry occur due to slightly differing amounts of dopant chemicals or other materials added during the fabrication process.  These differences produce random glitches or signal variations, though without affecting the computed results.

In the fingerprinting scheme the team in Japan cooked up, such glitches are counted using a logic circuit embedded in the chip. When the number of glitches counted for a given input signal is even, 0 is assigned as an output bit; if the number is odd, 1 is assigned.

“We are using 128-bit IDs in prototypes now, but this can rise to 4,096 bits, if needed, though you only need 80 bits to cover 100 billion different devices”

To create a unique ID, a series of four predefined 32-bit input signals is applied to a certain portion of the chip’s circuitry. Each of these generates a 32-bit string of 0s and 1s based on the counted glitches. An embedded algorithm then combines the four results to produce a unique 128-bit number string, which is placed in the chip’s register when the power is turned on.

Here’s how that unique ID can work to guard against attempts to install malware. First, equipment to be networked is provided with a common encryption key (stored in flash memory) that is itself encrypted using code embedded in the logic chip and the chip’s unique ID.

Application software to be installed (or updated) is encrypted using the same common encryption key. To decrypt the software for installation, the system employs the unique ID in the chip’s register to decrypt the common key, which is then used to decrypt the software.

Injected malware would be encrypted with a wrong key and so would be read as random numbers and not be installed.

Using this ID system, networked gear can also be configured to operate only with other components that have specified IDs. Consider a situation where device A needs to authenticate device B. The authentication procedure is similar to installing application software, except a string of random numbers is used in place of the application. The numbers in device A are encrypted using the common encryption key and sent to device B, where they are decrypted using the same procedure just described. The decrypted numbers are sent back to device A and if they are the same as those it sent, device B is authenticated.

“Unique ID generation, encryption, and authentication takes up only [15,000 logic gates] of space on the chip,” says Takeshi Yoneda, senior manager of Mitsubishi Electric’s information security technology department. “This is because they share some of the same components.” The three functions—ID generation, encryption, and authentication—only take up one-third the space they would need if they were implemented separately, he says.

He notes that because the ID is only activated when the chip is running, there is no way it can be read using reverse engineering tricks.

Contrary to what you might expect, the technology actually works better the smaller the chips’ transistors and interconnects are. In fact, the smaller the circuit components, “the more glitches available for counting,” says Daisuke Suzuki, a head researcher at Mitsubishi who invented this security scheme. “We are using 128-bit IDs in prototypes now, but this can rise to 4,096 bits, if needed, though you only need 80 bits to cover 100 billion different devices.”

Mitsubishi will deploy the technology first in its own products starting in April 2016, targeting areas with high safety demands such as factory automation, the auto industry, billing systems, and critical IoT devices.

“It’s been estimated that by 2020 there’ll be some 50 billion IoT devices,” says Suzuki. “If only one of these proves vulnerable, it could have a serious impact around the world. We hope to prevent that happening with this technology.”

The Conversation (0)

Why Functional Programming Should Be the Future of Software Development

It’s hard to learn, but your code will produce fewer nasty surprises

11 min read
Vertical
A plate of spaghetti made from code
Shira Inbar
DarkBlue1

You’d expectthe longest and most costly phase in the lifecycle of a software product to be the initial development of the system, when all those great features are first imagined and then created. In fact, the hardest part comes later, during the maintenance phase. That’s when programmers pay the price for the shortcuts they took during development.

So why did they take shortcuts? Maybe they didn’t realize that they were cutting any corners. Only when their code was deployed and exercised by a lot of users did its hidden flaws come to light. And maybe the developers were rushed. Time-to-market pressures would almost guarantee that their software will contain more bugs than it would otherwise.

Keep Reading ↓Show less
{"imageShortcodeIds":["31996907"]}