how can i recover my unencrypted bitstream starting from encrypted one and knowing the KEY

swiss,

There is nothing proprietary about the algorithm, nor the format: it is all documented.

All configuration bitstream data (config memory and BRAM contents) are encrypted.

There is no built in hardened secure authentication (e.g. SHA-XXX), only AES256 decryption. SHA-XXX can be added as soft IP, and used to authenticate after startup using the ICAP feature (we have SHA-256 as a reference design, in process).

Any bitstream, encrypted or not, is accepted by the part today. If you are an areospace/defense customer, contact your FAE for information on how parts which will only accept encrypted bitstreams are accomplished.

What is it you are trying to do? Why? What problem are you trying to solve? How do you solve this problem today? (for our market research)

Austin

Sir Austin

As a designer using extensively Xilinx products , i want to verify that really aes 256 is used to encrypt bitstream .

When i tried to encrypt configurable data ( after writing to FDRI) in the unencrypted raw bit file with AES 256 cbc i couldn't find the right cipher in the encrypted one !? why ?

If some designer would have wanted to decrypt his bitstream , so as you said "there is nothing proprietary about the algorithm" why this designer can not recover his unencrypted bitstream with his secret key ?!

Thank you , Swissi

swissi,

I have no idea what you are trying to tell me.

If you have the key used to encrypt the bitstream, then of course, you can decrypt the bitstream. That is how it works, and how it is used.

The only information you need is the key, and where in the bitstream the encryption begins (there is pre-pended information which is always common, encrypted or not preceding the information).

Are you just trying to check that we are using AES256?

Are you trying to make sure that your bitstream has been encrypted?

Austin

Hey Austin, You remember a day or two ago, in all seriousnes, you said I need to treat your future customers with a little patience? Let me know when I can be rude to this one! To be honest, I don't think they're a 'keeper'. Thanks, Syms.

Symon,

I had no intent to be rude! I am honestly saying I do not understand. I am trying the best I can, but for some reason (perhaps my defective brain cells), it isn't making any sense.

If I have offended anyone, I apologize! I am just trying to understand what is being asked.

Austin

I think it's this that he's trying to do.

G.

hi folks !

Very interesting question , me too i want to be sur that my bitstream is encrypted with aes 256 cbc . how can i check this ?!

Austin u told us one time about how to make the difference between encrypted and unencrypted bitstream ...

mowa

mowa,

The first, and most obvious difference, is that an unencrypted bitstream is mostly all 0's. There are less than 10% of the bits that are set to

1's in a bitstream.

Identifying the structure of the bitstream is not all that tough: 1312 bit frames in V4 and V5, 41 frames for a column of CLB's, locations of BRAM data, etc. For example, place all BRAMs in a design with initial values of 0xAAh, and then the 10101010 binary patterns will pop out for the BRAM blocks. When encrypted, there will never be a block of

10101010 the length of a BRAM any longer (as it will have been encrypted)

The second, and fairly obvious difference, is that encryption tends to make things look like noise, so an encrypted bitstream has ~ 50% 1's and 50% 0's (looks like a random string of 1's and 0's). Nothing in the bitstream will "make any sense" or correlate with anything that you think it should be (i.e BRAM contents as above).

To prove to yourself that the encryption which is performed is AES256 per the NIST standard, one has to read how we format the bistream: what comes before the encrypted part, and what follows after the encryption ends and then to decrypt that middle part using a NIST c or Fortran program with the key you used to encrypt with.

The AES256 encryption has been confirmed by more than one third party, so depending on how paranoid you are, you may or may not want to duplicate this work (although it is not hard to do, just takes some programming skills).

Austin

Austin

it takes a) some programming skills b) re-inventing SOME missing info from Xilinx

I assume this is what the OP/others have been trying to tell you.

Some bitstream info is documented yes. Some not, I have not looked the very last documents but a while ago it was not so easy to implement the auto-crc on some devices (based solely on Xilinx info) my bet is that is the same with the AES256 as well

As example is it plain normal CBC or not? WHERE is that information?

Sure it is easy to verify that there is encryption by looking ad 01 density, but some want to check more than that

Antti

No secret, we do state that CBC is used (in a number of places).

Simply:

Select no encryption, generate bitstream.

Select encryption, generate bitstream.

Do a "diff."

Now you see exactly where to start (and stop).

Austin

Austin ,

Thank you for useful informations ,

But i still have some questions about this subject ; in fact after doing the diff , i could localise the startCBC ( one word for command and four words for cbc value) followed by two commands (write to FDRI) ; after these two commands data is encrypted .

My question is that if i take the first block of data ( 128 bits = 4 words)and i try to dercypt it with my key + startCBC (using Nist C AES 256 CBC) i don't find the clear data !

Also i would like to know if all zeros that we can see in the beginning of configurable data (clear bitstream) corresponds to the intialization of BRAM or not (?)

Mario Bamboutcha ,

I have exactly the same problem...

With the help of ebook Virtex5 FPGA Configuration User Guide I can "decompile" the encrypted bitstream to something like this... (NOPs arent shown)

0x0000012f: P1 WRITE CBC [30016004](4) 50 66 d8 9e f6 17 2c f8 49 ee 41 6b 3a de 6d de 0x00000143: P1 WRITE FDRI [30004000](0) 0x00000147: P2 WRITE [5003fd28](261416) 0x000ff60f: P1 WRITE CRC [30000001](1) 83 96 e4 9f

I can see, that iv has the same value like that one in my .nky file (Key StartCBC 5066d89ef6172cf849ee416b3ade6dde;) and if I decrypt data part (with AES-256 mode CBC) from offset 0x0000014b, size 261416 * 4 Bytes with key from .nkey file, I get something like this 09 95 2D 5B D0 E3 D0 19 ..., that doesnt looks like a valid data, so I made another encrypted bitstream (with different key and iv). The encrypted bitstreams are different only in date, iv, crc and of course encryped data. But, when I decrypt data part of the second bitstream with his iv and key, I get different output (A5 7E F8 8A AC 74 30 F6 ...). So I think that you dont use the standard NIST C AES 256 CBC, if you would, then I should get same output from the 1. and 2. bitstream.

And another thing, how are you computing crc, is it standard crc-32? after this command, crc is cleared,

0x00000097: P1 WRITE CMD [30008001](1) 00 00 00 07 Reset crc

and which data from the following bistream part are involved?

0x000000a7: P1 WRITE TIMER [30022001](1) 00 00 00 00 0x000000af: P1 WRITE ??? [30026001](1) 00 00 00 00 0x000000b7: P1 WRITE COR0 [30012001](1) 00 00 31 e5 0x000000bf: P1 WRITE COR1 [3001c001](1) 00 00 00 00 0x000000c7: P1 WRITE IDCODE [30018001](1) 02 86 e0 93 0x000000cf: P1 WRITE CMD [30008001](1) 00 00 00 09 Switch clk 0x000000db: P1 WRITE MASK [3000c001](1) 00 40 04 40 0x000000e3: P1 WRITE CTL0 [3000a001](1) 00 40 04 40 0x000000eb: P1 WRITE MASK [3000c001](1) 00 00 00 00 0x000000f3: P1 WRITE CTL1 [30030001](1) 00 00 00 00 0x0000011b: P1 WRITE FAR [30002001](1) 00 00 00 00 0x00000123: P1 WRITE CMD [30008001](1) 00 00 00 01 Write CFG 0x0000012f: P1 WRITE CBC [30016004](4) 50 66 d8 9e f6 17 2c f8 49 ee 41 6b 3a de 6d de 0x00000143: P1 WRITE FDRI [30004000](0) 0x00000147: P2 WRITE [5003fd28](261416) 0x000ff60f: P1 WRITE CRC [30000001](1) 83 96 e4 9f

Whole packets with their heads (30022001 00 00 00 00) or only the data parts (00 00 00 00) and what about NOPs (20 00 00 00) are they involved?

I was trying to compute crc from all data, all data w/o nops, only the data parts but with no luck...

Antonin Kriz

All,

For those working to use your own AES256 decryption software for decrypting the bitstream, sorry I can't be of more help.

I have been told what I have related here (generally how to do it).

I haven't done it myself, but I certainly trust our test benches which show it is being done, and I also trust those who have independently verified it (No Such Agency, etc.) and are happy.

I will find out which CRC we are using, and post here later.

I believe it is a 32 bit CRC, but there is more than one "standard" 32 bit CRC out there, so I will find which polynomial is used.

I think it is also important to know what the CRC covers for the bitstream (config frames+?+overhead?+commands?).

It may be you have to run bitgen on the commond line, and specify every possible option (yea or nay), so that the encrypted, and unencrypted differ only in the encryption. Not sure if this is done through the gui if the options are identical with the exception of the encryption.

Austin

The CRC32 used internally is not a standard.

Austin

That's unfortunate. I can't imagine why a standard CRC polynomial wouldn't have been used.

I wrote a brute-force CRC polynomical finder in C a few years ago:

More recently someone wrote another more general brute-force CRC parameter finder in Perl:

I doubt that either program would be practical to find a 32-bit CRC polynomial, though.