one of our clients would like to implement a secure design flow on an existing Cyclone V based board. I read the AN556 but i am not sure that i understand it quite right : Once i generate a sof i then convert it to JIC and enable the encryption setting providing my key, this would generate an ekp file for me. My question is once i programmed the ekp file as non-volatile key on the FPGA can I update the bitstream and load entirely different encrypted design, provided that it has been encrypted with the same key used to generate the ekp ? should i just take the jic output in this case and don't program the ekp file, since it can't be reprogrammed to the polyfuse ?
does the ekp changes for different sofs or it depends entirely on the key ?
Thank you for contacting Intel community.
Design security is a design that allow user to program the device once and cannot be copied from other person. Hence, once it is programmed, it cannot be reprogram anymore. 2 approaches for this are burning the fuse or without burning the fuse.
Burning the fuse means hardware wise burnt, means no turning back once you program the jic file.
Usually user will do the approach without burning the fuse as a trial. So the ekp is actually the key and is needed as part of the secure design and everything. Per my understanding from AN556, the file cannot be reprogrammed once you have program the ekp file if you are using Non-volatile key.
Thanks for your answer,
i understand that the .ekp file is a needed part of the secure design flow but, as the document is not so clear about this point, i wonder if the key programming file (.ekp) is, as the name suggests, just the key file to be written to the FPGA? if such a key is the same as the user key, used to generate the encrypted jic file, i assume that any bitstream encrypted with the user key should be fine and get decrypted by the secure core. This would allow a scenario where if you have a device "in the wild" you can protected and also have the ability to update its design when its needed.
I am aware that the volatile key might fit well in this situation but we are working on a pre-existing hardware that dosen't provide a battery for retaining the encryption key in the volatile memory. That is way we are forced to use the non-volatile approach if we were to provide any security for our design but we don't want to lose the possibility to push new updates to the design and extend its functionality once the secure flow is in place.
Is there are any suggestions that you can provide regarding this matter ?
Apologize for the delay in response.
An .ekp file used to encrypt your configuration files using the Intel Quartus Prime software. Hence, it is not just the key file to be written to the FPGA.
Since you are using pre-existing hardware that doesn't provide a battery for retaining the encryption key in the volatile memory, and the pre-existing hardware wasn't design
for security from the first place, hence you cannot use volatile key. However, if you use non-volatile, it is only a one time program but can be risky. To make it short:
Volatile key: Cannot be use without battery. Can ONLY be use if you re-design your board.
Non-Volatile key: Can be use, but only a one time program hence putting your design to risk.
That is the only way to make it work since the pre-existing design is not design for security purpose from the first place.
Hope this will clarify.