FPGA Intellectual Property
PCI Express*, Networking and Connectivity, Memory Interfaces, DSP IP, and Video IP
Announcements
Intel Support hours are Monday-Fridays, 8am-5pm PST, except Holidays. Thanks to our community members who provide support during our down time or before we get to your questions. We appreciate you!

Need Forum Guidance? Click here
Search our FPGA Knowledge Articles here.
5988 Discussions

DE10-nano Encrypted ROM IP Content help

Altera_Forum
Honored Contributor II
1,224 Views

I have a requirement to initialize a ROM block used on the Cyclone V FPGA fabric with externally stored values. This ROM block is part of a proprietary core we're developing. The ROM data must be stored prior to boot-up as an encrypted (AES) file on the SD Card or some other device. When the FPGA is configured using an .rbf file, the ROM contents must be read from the separate encrypted file, decrypted with its AES key and loaded into the ROM for use by our core. 

 

  • Is this feasible for Cyclone V?  

  • Can I program a non-volatile AES key used for ROM contents decryption onto the Cyclone 5?  

  • Are there better suggestions/alternatives to do this?  

 

 

I realize a .hex file is used by the On-Chip Memory core in Qsys but this doesn't support encryption. Additionally the ROM cannot be exposed to any of the system buses, only the core that uses the data. 

 

Thanks in advance
0 Kudos
7 Replies
Altera_Forum
Honored Contributor II
94 Views

You can embed an AES key in the FPGA's configuration (the .rbf file). It can be as easy as hardcoding it as a constant in an hardware AES core. 

Although possible in theory, it would be very difficult for someone to try and recover your AES key from the .rbf file. But if you want to avoid this, you can also use an encrypted .rbf file with another AES key. That key is stored in a special non volatile memory in the FPGA but can't be accessed from the application, so you'd need two keys. One for the FPGA configuration itself, and one to decode your encrypted file.
Altera_Forum
Honored Contributor II
94 Views

Thank you for your reply 

 

Only the ROM contents are required to be unique for each FPGA , the IP that uses it's contents will be the same. The ROM contents are required to be accessible only by the IP. The question then becomes "is there a way of programming a ROM residing in an IP core with a unique set of values for the same IP?". Could the chips .rbf image use another image just for programming those values, keeping them hidden? My project is a security application and the ROM contents are key data.  

 

Thanks
Altera_Forum
Honored Contributor II
94 Views

 

--- Quote Start ---  

I have a requirement to initialize a ROM block used on the Cyclone V FPGA fabric with externally stored values. This ROM block is part of a proprietary core we're developing. The ROM data must be stored prior to boot-up as an encrypted (AES) file on the SD Card or some other device. When the FPGA is configured using an .rbf file, the ROM contents must be read from the separate encrypted file, decrypted with its AES key and loaded into the ROM for use by our core. 

--- Quote End ---  

 

 

What you are describing is not really a ROM, but it is a RAM whose contents are generated during the boot/powerup process of the FPGA. It will be be written once at initialization so it kind of appears to be a ROM, but really it is not, from the point of view of FPGA design. If you could provide one set of data to load into the memory in the Verilog (or VHDL) source file, and compile with that data, then that would be a ROM. Otherwise what you describe is really a RAM that is to be initialized by your FPGA code during the startup process.
Altera_Forum
Honored Contributor II
94 Views

 

--- Quote Start ---  

Otherwise what you describe is really a RAM that is to be initialized by your FPGA code during the startup process. 

--- Quote End ---  

 

 

Keeping that data secure is a high priority requirement. But they also want the flexibility of having different data in a different instance of the core. It sounds like the way to go is create a secure, encrypted IP for distribution. I imagine the customer would instance this as a back box and load the encrypted IP when they build the chip. We'd have to automate creating IP cores, each having it's own special data. Anyone have a better method?
Altera_Forum
Honored Contributor II
94 Views

 

--- Quote Start ---  

Keeping that data secure is a high priority requirement. But they also want the flexibility of having different data in a different instance of the core. It sounds like the way to go is create a secure, encrypted IP for distribution. I imagine the customer would instance this as a back box and load the encrypted IP when they build the chip. We'd have to automate creating IP cores, each having it's own special data. Anyone have a better method? 

--- Quote End ---  

 

 

Depends what you mean by 'secure'. You could have a generic FPGA image that gets distributed to all users, but you have a microSD/SD card attached to the FPGA, that only your startup code can read, that has the 'secure' keys that you distribute that is user specific. Or if it does not need to be replaceable use a separate soldered down SPI flash memory chip that has the secure data that is specific to each board (in case 'removable' storage for the data is not an option).
Altera_Forum
Honored Contributor II
94 Views

I would do a custom block, with separate write and read ports. The write port would receive encrypted data read from the SD card or an onboard flash that would contain your unique data, and your custom block would decrypt it on the fly with a hard coded AES key. Then the read port would be connected to your IP and provide the decrypted data.

Altera_Forum
Honored Contributor II
94 Views

 

--- Quote Start ---  

Depends what you mean by 'secure'. You could have a generic FPGA image that gets distributed to all users, but you have a microSD/SD card attached to the FPGA, that only your startup code can read, that has the 'secure' keys that you distribute that is user specific. Or if it does not need to be replaceable use a separate soldered down SPI flash memory chip that has the secure data that is specific to each board (in case 'removable' storage for the data is not an option). 

--- Quote End ---  

 

 

The consequences of the data being compromised is that our product (a security method) could be then used to tamper with devices that "trust" it, i.e. spoofing or impersonating a trusted device. The IP core protocol engine is not so much a concern as is the contents of that ROM. The method itself has been published and wouldn't be difficult to mock up in an HDL. The ROM contents are the "identity" of the particular device in a system. In our targeted market, customers (ideally) would like "absolute security" if such a thing were possible.  

 

A custom block solution would be feasible since AES decryption is relatively inexpensive. It would require access to an AES key provisioned somewhere having the same type of security the ROM data has.  

 

Thanks both for your input.
Reply