Forum Discussion

SEbbert's avatar
SEbbert
Icon for New Contributor rankNew Contributor
5 years ago

Design security key programming gone wrong!

Hi everybody,

we are working with the Cyclone V GT Development Kit and use the Intel Design Security Features of the Cyclone V Device Family. Recently we had some strange problems occur during programming the non-volatile key to some of our boards/devices.

We use a EthernetBlaster II for programming and use a chain description file to make sure we always program the same key.

I programmed the non-volatile key to a few development boards and for two of them it seems that somehow the key was corrupted during programming. These two boards won't work with our standard encrypted configuration files, only with unencrypted ones.

First I thought that programming the non-volatile key was just unsuccesful and tried to do it again. The Quartus Programmer states, that a non-volatile key has already been programmed to the device.

From the fact that the devices in question only work with unencrypted configurations and still have a non-volatile key set, i deduce that the key was corrupted during programming.

What can i do? How could this happen?

Best regards

Sebastian

3 Replies

  • JohnT_Altera's avatar
    JohnT_Altera
    Icon for Regular Contributor rankRegular Contributor
    5 years ago

    Hi,


    May I know if the board can still be programmed with unencrypted bitstream?


    I do not have any information as what might be happen as there is no way for us to know what is the key programmed to the device.


    • SEbbert's avatar
      SEbbert
      Icon for New Contributor rankNew Contributor
      5 years ago

      Hi John,

      thanks for the quick reply.

      Yes, the FPGA runs unencrypted bitstreams. It just doesn't run with encrypted bitstreams that match the programmed non-volatile design security key.

      My issue step by step:

      - The Cyclone V GT DevKit is setup to use the Active Serial configuration scheme, booting from the EPCQ256 device -> MAX V is programmed with the correct .pof file and MSEL dipswitches are set accordingly.

      - I program a non-volatile design security with an EthernetBlaster II using the same .ekp file as always.

      - I program a .jic file to the EPCQ256 that was encrypted with the key used in the ekp file.

      - The FPGA does not configure successfully and the Load-LED is flickering

      - The FPGA configures successfully if I program an unencrypted .jic file to the EPCQ256

      Is there really no way at all to find out what key was actually programmed? Maybe I can return the Board to you for finding out the actual key and compare it to the one in the ekp file?

      Best regards

  • JohnT_Altera's avatar
    JohnT_Altera
    Icon for Regular Contributor rankRegular Contributor
    5 years ago

    Hi,


    Unfortunately there is no way to find out the key that is being programmed into the FPGA. The reason is that we architecture the device security so that there is no way to reverse engineering. So unfortunately even we are not able to know the key that is programmed into the device.