Keeping Digital Assets Safe: PUF-based Security Solutions for Flash Memory

One of the major problems today is the security concerns of digital assets, especially those stored within the non-volatile memory. Flash is a very popular non-volatile memory in consumer electronics, providing highly efficient storage solutions for code, data, etc. However, Flash is still facing threats brought by physical attacks with increasing connectivity.

eMemory’s subsidiary, PUFsecurity, has developed PUF-based security IPs by leveraging the robust quantum-tunneling PUF technology. Built upon the PUF-based Root-of-Trust, PUFrt, and crypto coprocessor, PUFcc, we develop a series PUF-based Flash Protection Solutions: (1) PUFef encrypts the code stored in an embedded Flash and provides execution in place (XiP) functionality for microcontrollers or other types of computing units; (2) PUFxip supports high-speed data encryption and decryption, allowing XiP of encrypted code stored in external NOR Flash; and (3) PUFenc supports data encryption of a high-density NAND Flash, providing extra protection for the assets stored in NAND Flash.

In this webinar, we will discuss the different security threats and solutions related to Flash memory. Furthermore, we will dive deeper into the PUFef solution and show you how PUF-based security solutions can help in protecting the Flash memory.

The Q&A section starts from 28:45

Q&A Section Sharing

Question: What is the availability of Flash protection solutions?

Answer:
Regarding the PUFef for secure eFlash, it is implemented in the eFlash technology that are commercially available. The availability of PUFef follows the roadmap of NeoFuse and NeoPUF, where these IPs have been qualified or verified from 90nm down to 40nm eFlash technology nodes across different foundries.

Actually, a joint development project with UMC had just been completed, in which a PUFef secure eFlash macro and its test chip have been developed in UMC’s 55nm eFlash technology.

Regarding the other two solutions for external Flash protection, since we are not limited by the technology of Flash devices, the availability of these solutions is the same as the PUFcc IP, which is available from 0.15um down to 6nm technology nodes.

*

Question: What are the applications of these Flash protection solutions.

Answer:
Generally speaking, any applications that need to store sensitive data in the Flash memory would require Flash protection. For example, a microcontroller needs to execute a specific set of codes that is an essential intellectual property of the developer, these codes will need to be encrypted as they are stored in the eFlash. Our PUFef solution allows direct execution of the encrypted codes with high throughput and can hence protect the intellectual property while maintaining the performance.

*

Question: What are the advantages of the PUF-based Flash protection solutions compared to the other Flash solutions in the market?

Answer:
The first and most obvious one is that we provide security against physical attacks targeting Flash devices and interfaces. In addition, it is an integrated solution that supports standard interfaces, including the APB interface and the high-speed AXI or AHB interface. In particular, for the designers who require an eFlash solution, adopting our PUFef solution can also help to save the efforts of understanding the eFlash datasheets and to design or integrate the eFlash controllers.

*

Question: Why not use standard algorithms like AES for PUFef?

Answer:
As mentioned in the webinar, we want to optimize the tradeoff between security, speed, and resources. Using AES indeed provides high-security strength, but it requires at least 10 rounds of operation and implementing the 8-bit AES Sbox also requires a lot of hardware resources. Since we already know the required security strength for eFlash, there is no need to overdesign for a security strength that is not needed. As a result, the RC6 cipher chosen for the PUFef solution is a more reasonable choice than AES.

*

Question: What kinds of techniques can be used to attack Flash?

Answer:
There are many attack methods, including invasive attacks and semi-invasive attacks. For example, one can carefully delayer the Flash macro and then apply the microprobe technique to the readout interface to obtain the Flash contents. One can also inject laser pulses to the Flash or the interface, which may change some data stored in the Flash, impacting the integrity of the digital assets, or they may result in fault patterns that can be leveraged to discover the value stored within Flash, impacting the confidentiality of the digital assets.

*

Question: In XiP, should we decrypt all codes or just parts of code when we want to execute? For the data generated by the codes, should we encrypt the data?

Answer:
It depends on what kind of code. Not all the code needs to be encrypted. Regarding the data that is generated, of course, it also depends on whether it needs to be confidential or not.
XiP is mainly to real-time execute the code on NOR flash. We design a bypass register for determining the encryption and decryption actions, so the customer can keep part of the encryption, or plaintext on NOR flash, depending on your SW plan.
For temporary data, no additional buffer is needed. The CPU can directly execute the encryption code. So the biggest advantage of XiP is that: 1) it can protect the data on NOR flash/eFlash, and 2) it can save the working memory buffer of customers, like SRAM size.

*

Question: Is there any use for such powerful technology in other fields?
Answer:
Yes, PUF has been widely adopted in protecting electronic devices in various applications.

*
Question: What are the typical form factors and silicon chip area sizing estimations a customer needs to consider integrating a PUF solution in their design?

Answer:
It depends on the density and technology nodes. The size is similar to OTP, and is smaller than eFuse.

*

Question: If we use PUFxip to store code image (each die uses a unique PUF key), does that means each image should be generated uniquely during fabrication?

Answer:
The code image can be re-encrypted using the PUF key, so there is no need to generate different images during fabrication.

*

For more questions, you’re welcome to contact us by sending an email to info@pufsecurity.com.

Share:

Related Posts

Post-Quantum Cryptography (PQC) – On the Road to Preparedness
PUFrt Datasheet
The Challenge of Automotive Hardware Security Deployment