Battling Persistent Hacks At The Flash Level

Hardware vendors are beginning to close up security vulnerabilities across a broader range of technology than in the past, a sign that they are taking potential hardware breaches much more seriously.

Awareness of security flaws has been growing since the introduction of Meltdown, Spectre and Foreshadow, and more recently, the Cable Haunt attack. The general conclusion among chipmakers is that security needs to be layered throughout hardware and software stacks, and that it needs to extend across the supply chain.

“There are various experiments to make hardware more robust, most of those around RISC-V,” says Paul Kocher, an independent cryptographer and security consultant to Rambus. “What was interesting was that Cable Haunt was against a MIPS processor.”

Of particular note here is the focus on the processor as an attack target. But the processor runs code, and protecting the code itself is vital for neutralizing an attack on the processor. This is particularly important in applications where chips are expected to function for one to two decades, which means that the firmware must be secure and kept current by performing ongoing updates. Flash is a vulnerable point in this process since it contains a persistent copy of the firmware.

“Within a system, the root of trust is traditionally the microcontroller, and vendors are continuously creating ever better security solutions to ensure the MCU is trusted. But, of course, nothing is foolproof, and there is always a danger that the MCU can be hacked. If the MCU is compromised at runtime, it can end up compromising the flash memory. If that happens, and malicious code gets into the system, it can remain in there even after a system reboot, until you update the flash,” says Graham Loveridge, vice president of product marketing for semiconductor products at Adesto Technology.

This is the subject of a project between Adesto and NanoLock, whose goal is to ensure that fundamental operating code cannot be altered without permission.

“Our infrastructure is under attack,” says Yoni Kahana, NanoLock’s vice president of business development. “This isn’t science fiction. It’s already happening. It’s not a question of if and when [an attack will happen], but how big it’s going to be.”

That has drawn attention in some unusual quarters. “This has been of interest especially for distributed energy and distributed infrastructure such as smart metering and energy companies,” says Adesto’s Loveridge.”

The proliferation of IoT, smart infrastructure, and other connected devices has expanded the overall attack surface of the world’s networks enormously. “We’re focusing on lightweight connected devices,” says Kahana, which limits the cost of security that the market can bear. Attempts at compromising a device also may come from a variety of directions. “The attacks may come from outside, like a standard hack attempt, or from inside the company itself, or from somewhere in the supply chain.”

Importantly, these devices typically aren’t the end goal of attackers. They’re a means to access higher-value targets further on in the network, and one of the first steps in an attack will be to take control of the processor while making code changes that promote further infiltration. Such changes are often made first to live code that’s resident in RAM, but those changes will disappear when the device is power-cycled. For an attack to survive a power-down, the code change must be made persistent, which means that it needs to be written into the firmware that’s stored in the flash memory.

“In order to make it a ‘critical’ attack, it must be persistent,” notes Kahana. That’s ordinarily a job that the processor in the system handles, which is of concern if the processor is under the control of the attacker.

Fig. 1: Typical chip architecture. Source: NanoLock

Permission to change the code
“We assume the processor is compromised,” says Kahana. If that’s the case, then they need to protect the flash – or at least those regions within the flash that contain the firmware – from being written to by the processor. This is done first by placing a hardware root-of-trust (RoT) inside the flash memory itself.

That RoT can selectively block or allow changes to specific regions of the flash by requiring authentication prior to any such changes.

Requiring authentication ensures that changes can’t be made without the proper credentials. That will protect against unauthorized alterations, but it can also get in the way of legitimate code updates, which otherwise would be executed by the processor upon receiving updated firmware code. In order to enable updates, NanoLock’s system moves the control of the update procedure out of the processor and into a Trusted Entity (TE) that resides in a data center, regardless of whether it is on-premise or in the cloud. This means updates can be performed only while the device is connected to the cloud, even if the device doesn’t otherwise require a connection to operate.

Fig. 2: Adding a trusted entity. Source: NanoLock

This TE executes a protocol with the flash memory in order to make any firmware changes. The protocol is proprietary, but the cryptographic elements that it leverages are standard public ones like AES, SHA-2, and SHA-3. While the processor is still involved in writing to the flash, “it acts like a network node, passing the data to the flash.”

The processor can block an update, but it can’t modify an update that’s in process. The flash will be able to detect attempts to change the update code and will then reject the update.

And because the RoT protects only against unauthorized write operations, it doesn’t affect read performance. Write performance is also unaffected when writing to unprotected areas in the flash. There is a speed hit only when performing an update to the protected area. In that case, according to Kahana, “it requires an additional command to ‘open’ the gate. But the update process is long, so it’s completely negligible.”

The TE can do more than simply facilitate an update. It also can execute an audit all the way down to the flash chip, and it can retrieve forensic information that the flash chip stores. If, for example, there is an unauthorized attempt to write to the flash, the RoT will block the operation, but it will also store the event. The TE can retrieve that information after authentication. If, for any reason, the processor blocks an update or other legitimate access, the flash unit won’t know about it, but the TE will make note of the fact that the transaction did not complete.

Two levels of protection
The authentication aspect of the protocol is similar to what might be possible using existing hardware RoT devices, with the added benefit of not requiring an extra device on the board and in the bill of materials. But there’s a second aspect to the NanoLock solution, and that’s the ability to protect selected regions of the flash. Blocking all writes to the flash would keep the processor from storing operational data that’s not critical to the security of the system. Instead, only pre-defined regions of the flash are protected. That is a capability that an external RoT cannot provide.

That means that manufacturing now will have two steps for enabling flash protection. As shipped, a flash memory with the NanoLock capabilities will not have the protection turned on. “’NanoLock-Enabled’ means that the flash is capable of protection,” says Kahana, but it remains latent until properly set up.

The first step is provisioning, and this is handled much like it would be for any RoT. Provisioning populates the RoT with the keys necessary for authentication. Each device gets a unique key that is then authenticated with a unique device ID. In some cases, the flash may be provisioned by a Trusted Platform Module (TPM) in a trusted, secure manufacturing facility. In other cases, system builders may ask the flash manufacturers to pre-provision the flash units before shipping them for assembly on the board. As the protocol uses symmetric keys, there is no need for public-key infrastructural elements like certificates.

The second step is so-called activation. This defines the regions within the flash that are to be protected. It’s a step completely separate from provisioning, but it requires authentication, so it must be performed after provisioning. There is no requirement that activation occur immediately following provisioning. “Activation can be done a year after deployment, over the air.”

As to what options are available for protection, “It depends a bit on implementation, which [can] vary between flash vendor partners, but it is normally defined at the block level, and it doesn’t have to be contiguous. There is no limitation on the protected area size”, says Kahana. After updates, if the code size has increased beyond the space that was protected, one can reactivate with a larger protected size.

Broad applicability
NanoLock’s capability is not restricted to Adesto flash memories. It is already available in Cypress, Micron, and Winbond flash devices, with others planned. “These partners cover about 85% of the flash vendors that serve the IoT domain,” says Kahana. What’s different about the Adesto solution is that the security has been added to a relatively small NOR flash array – and they had to find a way to do that cost effectively.

“The reason this is important is that if you have a low-density (e.g. 64-Mbit) device created in a 55nm flash process, only the flash cell itself is at 55nm,”says Adesto’s Loveridge. “Because it’s on a flash process, the logic gates are at greater than 220nm. If you then need to add more logic on top of that to add security, it can be a significant adder to the area/cost.”

Minimizing the amount of extra logic is what has made this solution viable. The protection also is not restricted to flash memory.

“Our technology can work with any kind of memory,” says Kahana. He noted that flash is by far the preferred non-volatile memory for use in edge devices at consumer price points. Other non-volatile memories are in development, such as MRAM, PCRAM, and ReRAM. For now, those devices are in limited production at a price that makes their applications more limited. But if and when they become attractive for connected edge devices, a similar approach can work with them, as well.

Protecting the flash can be an important step, but Loveridge notes this doesn’t remove pressure from any of the other security steps that may also be in place. “Security is about adding layers on top of layers,” he says. “This solution doesn’t replace other system security. It complements other layers.”

—Ed Sperling contributed to this report.

Related Stories
Hardware Attack Surface Widening
Cable Haunt follows Spectre, Meltdown and Foreshadow as potential threat spreads beyond a single device; AI adds new uncertainty.
New Security Risks Create Need For Stealthy Chips
Thinner dies and insulation layers add vulnerabilities for better hacker tools. Solutions do exist, but there are tradeoffs and no guarantees.
Security Tradeoffs In A Shifting Global Supply Chain
How many simulation cycles are needed to crack an AES key? Plus, the impact of trade wars on semiconductor security and reliability.
A Trillion Security Risks
Why an explosion in IoT devices significantly raises the threat level.
Semiconductor Security Knowledge Center
Top stories, special reports, videos, blogs and white papers on security issues