DE10-nano Encrypted ROM IP Content help

[Altera_Forum]

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

[Altera_Forum]

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]

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]

--- 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]

--- 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]

--- 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]

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]

--- 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.