Re: Hello PPl, is there a way of locking a design (NGC) to a particular FPGA board?

"Ray Andraka" <ray@xxxxxxxxxxx> schrieb im Newsbeitrag
news:WaAnf.17576$Mi5.17212@xxxxxxxxxxxxx
> Antti Lukats wrote:
>
>> all 1-wire products *must* have unique number, it is IMPOSSIBLE to
>> something else
>>
>> Antti
> Well, not impossible. The codes are customized to the customer. IIRC, it
> is a 48 bit code, and part of that number is a unique number assigned to
> the customer, and part is a range of numbers assigned to that customer.
> You can (or at least you used to be able to) get duplicate numbers within
> your range. The codes, as I understand it, are added after the silicon is
> manufactured.
>
> The problem with using these in attempt to secure a bitstream is that the
> code is not secure...anyone with a data *** and an oscilloscope or logic
> analyzer can extract the serial number easily. Once you have the serial
> number, it is nearly trivial to create a circuit that will mimic the
> dallas part using what ever serial number you want to use. These parts
> are intended for electronic serial numbers, not for secure encryption
> keys.

Hi Ray,

you are one of the very few I am little bit 'scared' to argue with, but

from maxim:
"Unique, factory-lasered and tested 64-bit registration number assures
absolute traceability because no two parts are alike"

this applies for the 1-wire 64 ROM code what is PRODUCT code + 48 bit serial
+ CRC

normally most "Key" things use only this code as the key, what is TOTAL
bull*** and nonsense as it way easier to copy a dallas memory button then
nornal door-key, having a reader in your lap and placing your hand for a
second would do the job. As soon as you have the 64 bits then its easy to
rebuild the 'emulator' - I have not done that, but I know what it takes.
surprisingly many companies are selling products that use this 64 bit rom
code as security key. one example is Atmel FPLSIC dongle, but there are many
many more.

the suggestion in this thread was to use secure SHA-1 memory for the
protection, not the rom id code. DS2432 includes several nonvalotile areas
that are protected and provide somewhat higher degree of safety. Whatever is
written into those areas can sure be anything.

I have not checked the xilinx bitstream security application for design
flows, it could be that the SHA-1 is not used or not used properly yielding
the actualy protection to near void.

some hard macros from that XAPP I think are not correct at least failed with
ISE 7.1 so I assume that design has not been tested a very big extent. The
random number generator at least will not work out of box (at least not on
all supported fpga families). And ah well the actual protection level
depends on many more aspects if this approuch is used to protect edif or ngc
files the protection level would be lower than protection .bit files

Antti















.