Rocksolid Light

Welcome to novaBBS (click a section below)

mail  files  register  newsreader  groups  login

Message-ID:  

"We will bury you." -- Nikita Kruschev


devel / comp.arch.fpga / Re: Hardware based IP protection of FPGA designs

SubjectAuthor
* Hardware based IP protection of FPGA designsgnuarm.del...@gmail.com
+- Re: Hardware based IP protection of FPGA designsRichard Damon
+* Re: Hardware based IP protection of FPGA designsTheo
|`* Re: Hardware based IP protection of FPGA designsRichard Damon
| `* Re: Hardware based IP protection of FPGA designsTheo
|  `* Re: Hardware based IP protection of FPGA designsRichard Damon
|   `- Re: Hardware based IP protection of FPGA designsgnuarm.del...@gmail.com
`* Re: Hardware based IP protection of FPGA designsgnuarm.del...@gmail.com
 `* Re: Hardware based IP protection of FPGA designsClifford Heath
  `* Re: Hardware based IP protection of FPGA designsgnuarm.del...@gmail.com
   `- Re: Hardware based IP protection of FPGA designsgnuarm.del...@gmail.com

1
Hardware based IP protection of FPGA designs

<5b207976-3f19-4559-b510-fe1cc2213922n@googlegroups.com>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=333&group=comp.arch.fpga#333

  copy link   Newsgroups: comp.arch.fpga
X-Received: by 2002:ae9:f70e:0:b0:6cb:d0df:d210 with SMTP id s14-20020ae9f70e000000b006cbd0dfd210mr8174415qkg.676.1664005319931;
Sat, 24 Sep 2022 00:41:59 -0700 (PDT)
X-Received: by 2002:a05:6870:5a2:b0:12b:3e64:e770 with SMTP id
m34-20020a05687005a200b0012b3e64e770mr14081431oap.40.1664005319448; Sat, 24
Sep 2022 00:41:59 -0700 (PDT)
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.com!peer01.iad!feed-me.highwinds-media.com!news.highwinds-media.com!border-1.nntp.ord.giganews.com!nntp.giganews.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.arch.fpga
Date: Sat, 24 Sep 2022 00:41:59 -0700 (PDT)
Injection-Info: google-groups.googlegroups.com; posting-host=2604:b000:c208:974:7409:ab51:d0f1:e253;
posting-account=I-_H_woAAAA9zzro6crtEpUAyIvzd19b
NNTP-Posting-Host: 2604:b000:c208:974:7409:ab51:d0f1:e253
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <5b207976-3f19-4559-b510-fe1cc2213922n@googlegroups.com>
Subject: Hardware based IP protection of FPGA designs
From: gnuarm.d...@gmail.com (gnuarm.del...@gmail.com)
Injection-Date: Sat, 24 Sep 2022 07:41:59 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Lines: 24
X-Received-Bytes: 2377
 by: gnuarm.del...@gmail. - Sat, 24 Sep 2022 07:41 UTC

My customer is asking for a redesign of a very profitable board to deal with components that are EOL. Because of delivery issues from the EOL components, they are asking for the IP and manufacturing rights if I can't build them adequately. This seems a bit egregious, but I'm willing to do it if I can protect my financial interests.

The ideal solution would be a device of some sort, soldered to the board, that disables the design if a serial number does not match in some way. But I can't figure out a way to do this that can't be circumvented.

I've been assuming they would want the source code for the FPGA, but maybe not. If they have the source code, I don't think I can make the design secure. They can always alter the code to remove the dependency on the key. But if they don't demand that, a one wire chip could be added to provide adequate security. I believe Maxim will sell you registration numbers, so you have your own private devices for authentication.

I guess I need to learn more about this.

--

Rick C.

- Get 1,000 miles of free Supercharging
- Tesla referral code - https://ts.la/richard11209

Re: Hardware based IP protection of FPGA designs

<IcBXK.320622$wLZ8.203931@fx18.iad>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=335&group=comp.arch.fpga#335

  copy link   Newsgroups: comp.arch.fpga
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.com!peer03.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx18.iad.POSTED!not-for-mail
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0)
Gecko/20100101 Thunderbird/91.13.1
Subject: Re: Hardware based IP protection of FPGA designs
Content-Language: en-US
Newsgroups: comp.arch.fpga
References: <5b207976-3f19-4559-b510-fe1cc2213922n@googlegroups.com>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <5b207976-3f19-4559-b510-fe1cc2213922n@googlegroups.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Lines: 24
Message-ID: <IcBXK.320622$wLZ8.203931@fx18.iad>
X-Complaints-To: abuse@easynews.com
Organization: Forte - www.forteinc.com
X-Complaints-Info: Please be sure to forward a copy of ALL headers otherwise we will be unable to process your complaint properly.
Date: Sat, 24 Sep 2022 06:44:56 -0400
X-Received-Bytes: 2680
 by: Richard Damon - Sat, 24 Sep 2022 10:44 UTC

On 9/24/22 3:41 AM, gnuarm.del...@gmail.com wrote:
> My customer is asking for a redesign of a very profitable board to deal with components that are EOL. Because of delivery issues from the EOL components, they are asking for the IP and manufacturing rights if I can't build them adequately. This seems a bit egregious, but I'm willing to do it if I can protect my financial interests.
>
> The ideal solution would be a device of some sort, soldered to the board, that disables the design if a serial number does not match in some way. But I can't figure out a way to do this that can't be circumvented.
>
> I've been assuming they would want the source code for the FPGA, but maybe not. If they have the source code, I don't think I can make the design secure. They can always alter the code to remove the dependency on the key. But if they don't demand that, a one wire chip could be added to provide adequate security. I believe Maxim will sell you registration numbers, so you have your own private devices for authentication.
>
> I guess I need to learn more about this.
>

Microsemi, now Microchip, has FPGAs that the programming tools can be
setup to need authorization keys to program a specific number of devices.

The system is designed for this sort of environment, where you don't
have complete trust of your assembly house.

They don't need the FPGA source code unless they need to change or
retarget the FPGA, and if you give them that, you will need to price the
transaction understanding that you are lossing control over your IP.

If they are just building a defined product, they just need the compiled
bit-stream, which for some devices, like the Microsemi ones I mentioned,
may have some control over its duplication if properly encrypted.

Re: Hardware based IP protection of FPGA designs

<i8b*YYbZy@news.chiark.greenend.org.uk>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=336&group=comp.arch.fpga#336

  copy link   Newsgroups: comp.arch.fpga
Path: i2pn2.org!i2pn.org!aioe.org!nntp.terraraq.uk!nntp-feed.chiark.greenend.org.uk!ewrotcd!.POSTED.chiark.greenend.org.uk!not-for-mail
From: theom+n...@chiark.greenend.org.uk (Theo)
Newsgroups: comp.arch.fpga
Subject: Re: Hardware based IP protection of FPGA designs
Date: 25 Sep 2022 16:24:56 +0100 (BST)
Organization: University of Cambridge, England
Message-ID: <i8b*YYbZy@news.chiark.greenend.org.uk>
References: <5b207976-3f19-4559-b510-fe1cc2213922n@googlegroups.com>
Injection-Info: chiark.greenend.org.uk; posting-host="chiark.greenend.org.uk:212.13.197.229";
logging-data="32010"; mail-complaints-to="abuse@chiark.greenend.org.uk"
User-Agent: tin/1.8.3-20070201 ("Scotasay") (UNIX) (Linux/5.10.0-15-amd64 (x86_64))
Originator: theom@chiark.greenend.org.uk ([212.13.197.229])
 by: Theo - Sun, 25 Sep 2022 15:24 UTC

gnuarm.del...@gmail.com <gnuarm.deletethisbit@gmail.com> wrote:
> The ideal solution would be a device of some sort, soldered to the board,
> that disables the design if a serial number does not match in some way.
> But I can't figure out a way to do this that can't be circumvented.

You can do some kind of DRM with crypto keys and such, but do you have a way
to securely identify one board from another? If you can safely query the
FPGA serial number you can bind a decryption key (eg of the bitfile or some
critical firmware) to that serial number, and only issue keys for specific
FPGAs.

But if they can spoof the FPGA serial number then they can make every FPGA
look the same.

For example, working with Stratix 10s lately, we haven't found a way to get
the chip serial number via JTAG without programming a bitfile that reads it
out. Although I suppose you could first program a 'good' (encrypted)
bitfile that reads out the serial number. That would require somebody to
MITM that bitfile to replace it with a chosen-serial number: not impossible,
but hard to do at scale. (Bonus points if every device has a slightly
different way to send the serial number, like every bitfile send it with a
encrypted with a different key)

Or, if the thing is online in some way, you can make it check in to a
licence server, where you would notice if lots of the same serial number
turned up and could block them.

Theo

Re: Hardware based IP protection of FPGA designs

<5J%XK.371147$SAT4.178871@fx13.iad>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=337&group=comp.arch.fpga#337

  copy link   Newsgroups: comp.arch.fpga
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.com!peer01.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx13.iad.POSTED!not-for-mail
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0)
Gecko/20100101 Thunderbird/91.13.1
Subject: Re: Hardware based IP protection of FPGA designs
Content-Language: en-US
Newsgroups: comp.arch.fpga
References: <5b207976-3f19-4559-b510-fe1cc2213922n@googlegroups.com>
<i8b*YYbZy@news.chiark.greenend.org.uk>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <i8b*YYbZy@news.chiark.greenend.org.uk>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Lines: 45
Message-ID: <5J%XK.371147$SAT4.178871@fx13.iad>
X-Complaints-To: abuse@easynews.com
Organization: Forte - www.forteinc.com
X-Complaints-Info: Please be sure to forward a copy of ALL headers otherwise we will be unable to process your complaint properly.
Date: Sun, 25 Sep 2022 12:54:25 -0400
X-Received-Bytes: 3163
 by: Richard Damon - Sun, 25 Sep 2022 16:54 UTC

On 9/25/22 11:24 AM, Theo wrote:
> gnuarm.del...@gmail.com <gnuarm.deletethisbit@gmail.com> wrote:
>> The ideal solution would be a device of some sort, soldered to the board,
>> that disables the design if a serial number does not match in some way.
>> But I can't figure out a way to do this that can't be circumvented.
>
> You can do some kind of DRM with crypto keys and such, but do you have a way
> to securely identify one board from another? If you can safely query the
> FPGA serial number you can bind a decryption key (eg of the bitfile or some
> critical firmware) to that serial number, and only issue keys for specific
> FPGAs.
>
> But if they can spoof the FPGA serial number then they can make every FPGA
> look the same.
>
> For example, working with Stratix 10s lately, we haven't found a way to get
> the chip serial number via JTAG without programming a bitfile that reads it
> out. Although I suppose you could first program a 'good' (encrypted)
> bitfile that reads out the serial number. That would require somebody to
> MITM that bitfile to replace it with a chosen-serial number: not impossible,
> but hard to do at scale. (Bonus points if every device has a slightly
> different way to send the serial number, like every bitfile send it with a
> encrypted with a different key)
>
> Or, if the thing is online in some way, you can make it check in to a
> licence server, where you would notice if lots of the same serial number
> turned up and could block them.
>
> Theo

The Microsemi FPGA's each have a factory assigned crypto-serial number
(and individual key) built into the FPGA itself, and a programming file
can be generated that can only program that EXACT FPGA (that factory
assigned key). You can also generate a programming file encrypted to a
generic key that any of that model FPGA can take (when you trust the
programming facility)

Their secure programmer takes a programming file encrypted to the
programmers key, and with a secure file that the designer has to sign,
gets the public key for the FPGA and decrypts and reencrypt the
programming file for THAT FPGA, while ticking off the usage count kept
in its own secure storage.

This seems fairly secure.

Re: Hardware based IP protection of FPGA designs

<4ad4f30a-bc09-41d6-ba88-2c7ab469e188n@googlegroups.com>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=338&group=comp.arch.fpga#338

  copy link   Newsgroups: comp.arch.fpga
X-Received: by 2002:ac8:5a8c:0:b0:35b:b2f7:7e96 with SMTP id c12-20020ac85a8c000000b0035bb2f77e96mr15471803qtc.659.1664130993673;
Sun, 25 Sep 2022 11:36:33 -0700 (PDT)
X-Received: by 2002:a05:6808:ec5:b0:337:ac3c:550c with SMTP id
q5-20020a0568080ec500b00337ac3c550cmr9173788oiv.262.1664130993379; Sun, 25
Sep 2022 11:36:33 -0700 (PDT)
Path: i2pn2.org!i2pn.org!usenet.goja.nl.eu.org!weretis.net!feeder8.news.weretis.net!proxad.net!feeder1-2.proxad.net!209.85.160.216.MISMATCH!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.arch.fpga
Date: Sun, 25 Sep 2022 11:36:33 -0700 (PDT)
In-Reply-To: <5b207976-3f19-4559-b510-fe1cc2213922n@googlegroups.com>
Injection-Info: google-groups.googlegroups.com; posting-host=2604:b000:c208:974:a11a:546c:5b19:a139;
posting-account=I-_H_woAAAA9zzro6crtEpUAyIvzd19b
NNTP-Posting-Host: 2604:b000:c208:974:a11a:546c:5b19:a139
References: <5b207976-3f19-4559-b510-fe1cc2213922n@googlegroups.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <4ad4f30a-bc09-41d6-ba88-2c7ab469e188n@googlegroups.com>
Subject: Re: Hardware based IP protection of FPGA designs
From: gnuarm.d...@gmail.com (gnuarm.del...@gmail.com)
Injection-Date: Sun, 25 Sep 2022 18:36:33 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
 by: gnuarm.del...@gmail. - Sun, 25 Sep 2022 18:36 UTC

On Saturday, September 24, 2022 at 3:42:02 AM UTC-4, gnuarm.del...@gmail.com wrote:
> My customer is asking for a redesign of a very profitable board to deal with components that are EOL. Because of delivery issues from the EOL components, they are asking for the IP and manufacturing rights if I can't build them adequately. This seems a bit egregious, but I'm willing to do it if I can protect my financial interests.
>
> The ideal solution would be a device of some sort, soldered to the board, that disables the design if a serial number does not match in some way. But I can't figure out a way to do this that can't be circumvented.
>
> I've been assuming they would want the source code for the FPGA, but maybe not. If they have the source code, I don't think I can make the design secure. They can always alter the code to remove the dependency on the key. But if they don't demand that, a one wire chip could be added to provide adequate security. I believe Maxim will sell you registration numbers, so you have your own private devices for authentication.
>
> I guess I need to learn more about this.

If I am going to give them source code for the FPGA, the only way I can assure they can't build units without compensation, is to have a part on the board that is essential to the operation, and is only available from me. So a small CPLD might do the job. Lattice has a part with 5V compatibility which I would need anyway, but it's missing any logic! Only ADC and other "power" related circuits. The parts in this series with logic are in much larger packages. Still...

Hmmm... I think the way Greenpak works, is you do your designs with the "special" versions of the chips, then Greenpak "makes" your chips for you. That would do the job. I'll have to see the best way to insert something like that into the design so it is indispensable.

--

Rick C.

+ Get 1,000 miles of free Supercharging
+ Tesla referral code - https://ts.la/richard11209

Re: Hardware based IP protection of FPGA designs

<17183f3e0ba20a07$1$1622261$32dd386f@news.thecubenet.com>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=339&group=comp.arch.fpga#339

  copy link   Newsgroups: comp.arch.fpga
Date: Mon, 26 Sep 2022 09:46:35 +1000
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.11.0
Subject: Re: Hardware based IP protection of FPGA designs
Content-Language: en-US
Newsgroups: comp.arch.fpga
References: <5b207976-3f19-4559-b510-fe1cc2213922n@googlegroups.com> <4ad4f30a-bc09-41d6-ba88-2c7ab469e188n@googlegroups.com>
From: no_s...@please.net (Clifford Heath)
In-Reply-To: <4ad4f30a-bc09-41d6-ba88-2c7ab469e188n@googlegroups.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Lines: 42
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.com!peer01.iad!feed-me.highwinds-media.com!news.highwinds-media.com!feeder.usenetexpress.com!tr2.iad1.usenetexpress.com!news.thecubenet.com!not-for-mail
NNTP-Posting-Date: Sun, 25 Sep 2022 23:46:38 +0000
Organization: theCubeNet - www.thecubenet.com
X-Complaints-To: abuse@thecubenet.com
Message-ID: <17183f3e0ba20a07$1$1622261$32dd386f@news.thecubenet.com>
X-Received-Bytes: 3800
 by: Clifford Heath - Sun, 25 Sep 2022 23:46 UTC

On 26/9/22 04:36, gnuarm.del...@gmail.com wrote:
> On Saturday, September 24, 2022 at 3:42:02 AM UTC-4, gnuarm.del...@gmail.com wrote:
>> My customer is asking for a redesign of a very profitable board to deal with components that are EOL. Because of delivery issues from the EOL components, they are asking for the IP and manufacturing rights if I can't build them adequately. This seems a bit egregious, but I'm willing to do it if I can protect my financial interests.
>>
>> The ideal solution would be a device of some sort, soldered to the board, that disables the design if a serial number does not match in some way. But I can't figure out a way to do this that can't be circumvented.
>>
>> I've been assuming they would want the source code for the FPGA, but maybe not. If they have the source code, I don't think I can make the design secure. They can always alter the code to remove the dependency on the key. But if they don't demand that, a one wire chip could be added to provide adequate security. I believe Maxim will sell you registration numbers, so you have your own private devices for authentication.
>>
>> I guess I need to learn more about this.
>
> If I am going to give them source code for the FPGA, the only way I can assure they can't build units without compensation, is to have a part on the board that is essential to the operation, and is only available from me.

Firstly, if they're trying to ensure robustness against future supply
shortages, i.e they might need to change to a different FPGA, they're
going to need the source code anyway.

Secondly, if you add a smaller chip to add authentication, it needs to
perform some critical function that cannot easily be replicated. That
is, it needs to be the part that implements your core innovations.
Removing it (and changing the FPGA code) must not result in a workable
device.

If you can do that without incurring the exact same continuity problem
that you could have with the main chip, go for it. But I think this kind
of secure lockout is much harder than you think, and probably harder
that it's worth.

Another path that might work with some networked equipment is to design
it to either "phone home" periodically, or to expire an internal license
key that must be renewed to restore operation. But that's more
appropriate for a high-value device where you don't charge your
customers, and may only be legal in a rental/subscription model, not
outright ownership. It typically engenders so much ill will among buyers
that you'll sell enough more without any protection to make up the
difference.

Business is built on relationships of trust. If you don't trust these
folk, and can't get them to agree to some regime that will keep your
confidence, quit them and find someone else to do business with.

Clifford Heath.

Re: Hardware based IP protection of FPGA designs

<74292f74-45b8-478d-a7fd-11dcae1c82d7n@googlegroups.com>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=341&group=comp.arch.fpga#341

  copy link   Newsgroups: comp.arch.fpga
X-Received: by 2002:a05:620a:2806:b0:6b8:eced:ba3a with SMTP id f6-20020a05620a280600b006b8ecedba3amr13209390qkp.462.1664171305429;
Sun, 25 Sep 2022 22:48:25 -0700 (PDT)
X-Received: by 2002:a05:6870:178e:b0:126:7055:fc78 with SMTP id
r14-20020a056870178e00b001267055fc78mr11568896oae.58.1664171305153; Sun, 25
Sep 2022 22:48:25 -0700 (PDT)
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.com!peer03.iad!feed-me.highwinds-media.com!news.highwinds-media.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.arch.fpga
Date: Sun, 25 Sep 2022 22:48:24 -0700 (PDT)
In-Reply-To: <17183f3e0ba20a07$1$1622261$32dd386f@news.thecubenet.com>
Injection-Info: google-groups.googlegroups.com; posting-host=2604:b000:c208:974:2cf3:9b5a:df1b:d471;
posting-account=I-_H_woAAAA9zzro6crtEpUAyIvzd19b
NNTP-Posting-Host: 2604:b000:c208:974:2cf3:9b5a:df1b:d471
References: <5b207976-3f19-4559-b510-fe1cc2213922n@googlegroups.com>
<4ad4f30a-bc09-41d6-ba88-2c7ab469e188n@googlegroups.com> <17183f3e0ba20a07$1$1622261$32dd386f@news.thecubenet.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <74292f74-45b8-478d-a7fd-11dcae1c82d7n@googlegroups.com>
Subject: Re: Hardware based IP protection of FPGA designs
From: gnuarm.d...@gmail.com (gnuarm.del...@gmail.com)
Injection-Date: Mon, 26 Sep 2022 05:48:25 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Received-Bytes: 5375
 by: gnuarm.del...@gmail. - Mon, 26 Sep 2022 05:48 UTC

On Sunday, September 25, 2022 at 7:46:42 PM UTC-4, Clifford Heath wrote:
> On 26/9/22 04:36, gnuarm.del...@gmail.com wrote:
> > On Saturday, September 24, 2022 at 3:42:02 AM UTC-4, gnuarm.del...@gmail.com wrote:
> >> My customer is asking for a redesign of a very profitable board to deal with components that are EOL. Because of delivery issues from the EOL components, they are asking for the IP and manufacturing rights if I can't build them adequately. This seems a bit egregious, but I'm willing to do it if I can protect my financial interests.
> >>
> >> The ideal solution would be a device of some sort, soldered to the board, that disables the design if a serial number does not match in some way. But I can't figure out a way to do this that can't be circumvented.
> >>
> >> I've been assuming they would want the source code for the FPGA, but maybe not. If they have the source code, I don't think I can make the design secure. They can always alter the code to remove the dependency on the key.. But if they don't demand that, a one wire chip could be added to provide adequate security. I believe Maxim will sell you registration numbers, so you have your own private devices for authentication.
> >>
> >> I guess I need to learn more about this.
> >
> > If I am going to give them source code for the FPGA, the only way I can assure they can't build units without compensation, is to have a part on the board that is essential to the operation, and is only available from me.
> Firstly, if they're trying to ensure robustness against future supply
> shortages, i.e they might need to change to a different FPGA, they're
> going to need the source code anyway.
>
> Secondly, if you add a smaller chip to add authentication, it needs to
> perform some critical function that cannot easily be replicated. That
> is, it needs to be the part that implements your core innovations.
> Removing it (and changing the FPGA code) must not result in a workable
> device.
>
> If you can do that without incurring the exact same continuity problem
> that you could have with the main chip, go for it. But I think this kind
> of secure lockout is much harder than you think, and probably harder
> that it's worth.
>
> Another path that might work with some networked equipment is to design
> it to either "phone home" periodically, or to expire an internal license
> key that must be renewed to restore operation. But that's more
> appropriate for a high-value device where you don't charge your
> customers, and may only be legal in a rental/subscription model, not
> outright ownership. It typically engenders so much ill will among buyers
> that you'll sell enough more without any protection to make up the
> difference.
>
> Business is built on relationships of trust. If you don't trust these
> folk, and can't get them to agree to some regime that will keep your
> confidence, quit them and find someone else to do business with.

Trust, but verify.

If I can get a chip on the board, that is made with my part number, I think security by obscurity will be adequate. I've yet to find that part. GreenPak has some op amp chips that don't seem to combine much on board that would be useful to this design. If I can put an obscure part in the signal path, that should be adequate for my purposes. It's a part number they will need to buy through me. The part I've found seems to have enough to make it a programmable gain amp, which might suffice. So far, it's hard to read the data sheet and actually understand the limitation. Like the bandwidth, it looks like it's programmable, but I'm not sure I believe what they show.

--

Rick C.

-- Get 1,000 miles of free Supercharging
-- Tesla referral code - https://ts.la/richard11209

Re: Hardware based IP protection of FPGA designs

<2e0257f7-4cc7-49a5-8111-a83c2e13a7een@googlegroups.com>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=342&group=comp.arch.fpga#342

  copy link   Newsgroups: comp.arch.fpga
X-Received: by 2002:ac8:7f11:0:b0:35b:a3e7:648f with SMTP id f17-20020ac87f11000000b0035ba3e7648fmr18920351qtk.132.1664217753083;
Mon, 26 Sep 2022 11:42:33 -0700 (PDT)
X-Received: by 2002:a05:6870:3452:b0:127:74a6:365c with SMTP id
i18-20020a056870345200b0012774a6365cmr53492oah.169.1664217752540; Mon, 26 Sep
2022 11:42:32 -0700 (PDT)
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.com!peer03.iad!feed-me.highwinds-media.com!news.highwinds-media.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.arch.fpga
Date: Mon, 26 Sep 2022 11:42:32 -0700 (PDT)
In-Reply-To: <74292f74-45b8-478d-a7fd-11dcae1c82d7n@googlegroups.com>
Injection-Info: google-groups.googlegroups.com; posting-host=2607:fb90:25d4:6a71:5578:2de7:f8d7:4ab8;
posting-account=I-_H_woAAAA9zzro6crtEpUAyIvzd19b
NNTP-Posting-Host: 2607:fb90:25d4:6a71:5578:2de7:f8d7:4ab8
References: <5b207976-3f19-4559-b510-fe1cc2213922n@googlegroups.com>
<4ad4f30a-bc09-41d6-ba88-2c7ab469e188n@googlegroups.com> <17183f3e0ba20a07$1$1622261$32dd386f@news.thecubenet.com>
<74292f74-45b8-478d-a7fd-11dcae1c82d7n@googlegroups.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <2e0257f7-4cc7-49a5-8111-a83c2e13a7een@googlegroups.com>
Subject: Re: Hardware based IP protection of FPGA designs
From: gnuarm.d...@gmail.com (gnuarm.del...@gmail.com)
Injection-Date: Mon, 26 Sep 2022 18:42:33 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Received-Bytes: 2247
 by: gnuarm.del...@gmail. - Mon, 26 Sep 2022 18:42 UTC

I'm looking at the Greenpak SLG46580 and SLG47004 as candidates. The SLG47004 has amplifiers, rheostats and switches, which might be useful to customize a part of the analog circuitry. The SLG46580 has four LDOs which I'm pretty sure I'm going to need at least three of, depending on the FPGA chosen.

Give these parts custom part numbers and I think that will help protect the design a lot. Maybe not complete assurance, but this is a large company who will only be interested in getting their boards. I don't think they will be intentionally cheating me, but it might be tricky to get confirmation, when they build units. This shortcuts the process.

--

Rick C.

-+ Get 1,000 miles of free Supercharging
-+ Tesla referral code - https://ts.la/richard11209

Re: Hardware based IP protection of FPGA designs

<i8b*m7kZy@news.chiark.greenend.org.uk>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=344&group=comp.arch.fpga#344

  copy link   Newsgroups: comp.arch.fpga
Path: i2pn2.org!i2pn.org!aioe.org!nntp.terraraq.uk!nntp-feed.chiark.greenend.org.uk!ewrotcd!.POSTED.chiark.greenend.org.uk!not-for-mail
From: theom+n...@chiark.greenend.org.uk (Theo)
Newsgroups: comp.arch.fpga
Subject: Re: Hardware based IP protection of FPGA designs
Date: 27 Sep 2022 09:58:24 +0100 (BST)
Organization: University of Cambridge, England
Message-ID: <i8b*m7kZy@news.chiark.greenend.org.uk>
References: <5b207976-3f19-4559-b510-fe1cc2213922n@googlegroups.com> <i8b*YYbZy@news.chiark.greenend.org.uk> <5J%XK.371147$SAT4.178871@fx13.iad>
Injection-Info: chiark.greenend.org.uk; posting-host="chiark.greenend.org.uk:212.13.197.229";
logging-data="22122"; mail-complaints-to="abuse@chiark.greenend.org.uk"
User-Agent: tin/1.8.3-20070201 ("Scotasay") (UNIX) (Linux/5.10.0-15-amd64 (x86_64))
Originator: theom@chiark.greenend.org.uk ([212.13.197.229])
 by: Theo - Tue, 27 Sep 2022 08:58 UTC

Richard Damon <Richard@damon-family.org> wrote:
> The Microsemi FPGA's each have a factory assigned crypto-serial number
> (and individual key) built into the FPGA itself, and a programming file
> can be generated that can only program that EXACT FPGA (that factory
> assigned key). You can also generate a programming file encrypted to a
> generic key that any of that model FPGA can take (when you trust the
> programming facility)
>
> Their secure programmer takes a programming file encrypted to the
> programmers key, and with a secure file that the designer has to sign,
> gets the public key for the FPGA and decrypts and reencrypt the
> programming file for THAT FPGA, while ticking off the usage count kept
> in its own secure storage.
>
> This seems fairly secure.

It does, but it doesn't seem to address the OP's threat model. Which is
that they want to give the third party the source code and the ability to
generate their own FPGA bitfiles while still maintaining control (to prevent
overproduction). In that instance the third party can modify the FPGA to
work around the protection, and you need to do attestation against some
external authority (microcontroller for example) to 'activate' the system,
and a way that can't be spoofed by changing the FPGA bitfile.

So if you can run the secure programmer on a microcontroller and extract the
serial number without trusting any bitfile, you might be able to use that as
a key for some component that you do not release to the third party (eg
firmware that runs on a soft-core inside the FPGA).

Or you could require your third party to submit their FPGA bitfile for
signing by an approved key server you control, along with a list of serial
numbers of FPGAs you want to allow to run it.

It sounds like they have a useful toolkit, but it would need further
understanding of the pieces and put them together to meet the requirements.

Theo

Re: Hardware based IP protection of FPGA designs

<5fBYK.284178$G_96.78981@fx13.ams1>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=345&group=comp.arch.fpga#345

  copy link   Newsgroups: comp.arch.fpga
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!newsreader4.netcologne.de!news.netcologne.de!peer01.ams1!peer.ams1.xlned.com!news.xlned.com!fx13.ams1.POSTED!not-for-mail
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0)
Gecko/20100101 Thunderbird/91.13.1
Subject: Re: Hardware based IP protection of FPGA designs
Content-Language: en-US
Newsgroups: comp.arch.fpga
References: <5b207976-3f19-4559-b510-fe1cc2213922n@googlegroups.com>
<i8b*YYbZy@news.chiark.greenend.org.uk> <5J%XK.371147$SAT4.178871@fx13.iad>
<i8b*m7kZy@news.chiark.greenend.org.uk>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <i8b*m7kZy@news.chiark.greenend.org.uk>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Lines: 53
Message-ID: <5fBYK.284178$G_96.78981@fx13.ams1>
X-Complaints-To: abuse@easynews.com
Organization: Forte - www.forteinc.com
X-Complaints-Info: Please be sure to forward a copy of ALL headers otherwise we will be unable to process your complaint properly.
Date: Tue, 27 Sep 2022 07:36:34 -0400
X-Received-Bytes: 3855
 by: Richard Damon - Tue, 27 Sep 2022 11:36 UTC

On 9/27/22 4:58 AM, Theo wrote:
> Richard Damon <Richard@damon-family.org> wrote:
>> The Microsemi FPGA's each have a factory assigned crypto-serial number
>> (and individual key) built into the FPGA itself, and a programming file
>> can be generated that can only program that EXACT FPGA (that factory
>> assigned key). You can also generate a programming file encrypted to a
>> generic key that any of that model FPGA can take (when you trust the
>> programming facility)
>>
>> Their secure programmer takes a programming file encrypted to the
>> programmers key, and with a secure file that the designer has to sign,
>> gets the public key for the FPGA and decrypts and reencrypt the
>> programming file for THAT FPGA, while ticking off the usage count kept
>> in its own secure storage.
>>
>> This seems fairly secure.
>
> It does, but it doesn't seem to address the OP's threat model. Which is
> that they want to give the third party the source code and the ability to
> generate their own FPGA bitfiles while still maintaining control (to prevent
> overproduction). In that instance the third party can modify the FPGA to
> work around the protection, and you need to do attestation against some
> external authority (microcontroller for example) to 'activate' the system,
> and a way that can't be spoofed by changing the FPGA bitfile.
>
> So if you can run the secure programmer on a microcontroller and extract the
> serial number without trusting any bitfile, you might be able to use that as
> a key for some component that you do not release to the third party (eg
> firmware that runs on a soft-core inside the FPGA).
>
> Or you could require your third party to submit their FPGA bitfile for
> signing by an approved key server you control, along with a list of serial
> numbers of FPGAs you want to allow to run it.
>
> It sounds like they have a useful toolkit, but it would need further
> understanding of the pieces and put them together to meet the requirements.
>
> Theo

IF you actually need to give source code, then this system doesn't
provide protection, but my reading of the situation doesn't define that
they absolutely need to get source code, but the OP thinks they may want it.

Fundamentally, if you give source code, you have not true secretes in
what you give them. If you can put something ESSENTIAL, that is also not
possible to reverse engineer or duplicate into something you can
control, you can maintain control, at least until they figure out how to
get around that toll-gate.

In my opioion, if you are going to sell the code for the major part of
the system, you need to price that part of the transaction to get what
you need out of it, and make the effectively unenforceable unit fees (if
any) small enough that they aren't incentivized to break the agreement.

Re: Hardware based IP protection of FPGA designs

<cad6dd87-c950-4ac1-8284-e17bc3feed87n@googlegroups.com>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=346&group=comp.arch.fpga#346

  copy link   Newsgroups: comp.arch.fpga
X-Received: by 2002:a05:620a:4310:b0:6ac:f9df:178d with SMTP id u16-20020a05620a431000b006acf9df178dmr19366585qko.773.1664300662328;
Tue, 27 Sep 2022 10:44:22 -0700 (PDT)
X-Received: by 2002:a05:6808:1704:b0:351:43bc:5e52 with SMTP id
bc4-20020a056808170400b0035143bc5e52mr2376884oib.107.1664300662003; Tue, 27
Sep 2022 10:44:22 -0700 (PDT)
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.com!peer02.iad!feed-me.highwinds-media.com!news.highwinds-media.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.arch.fpga
Date: Tue, 27 Sep 2022 10:44:21 -0700 (PDT)
In-Reply-To: <5fBYK.284178$G_96.78981@fx13.ams1>
Injection-Info: google-groups.googlegroups.com; posting-host=2604:b000:c208:974:5556:7bea:3a2a:22f9;
posting-account=I-_H_woAAAA9zzro6crtEpUAyIvzd19b
NNTP-Posting-Host: 2604:b000:c208:974:5556:7bea:3a2a:22f9
References: <5b207976-3f19-4559-b510-fe1cc2213922n@googlegroups.com>
<i8b*YYbZy@news.chiark.greenend.org.uk> <5J%XK.371147$SAT4.178871@fx13.iad>
<i8b*m7kZy@news.chiark.greenend.org.uk> <5fBYK.284178$G_96.78981@fx13.ams1>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <cad6dd87-c950-4ac1-8284-e17bc3feed87n@googlegroups.com>
Subject: Re: Hardware based IP protection of FPGA designs
From: gnuarm.d...@gmail.com (gnuarm.del...@gmail.com)
Injection-Date: Tue, 27 Sep 2022 17:44:22 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Received-Bytes: 6715
 by: gnuarm.del...@gmail. - Tue, 27 Sep 2022 17:44 UTC

On Tuesday, September 27, 2022 at 7:36:39 AM UTC-4, Richard Damon wrote:
> On 9/27/22 4:58 AM, Theo wrote:
> > Richard Damon <Ric...@damon-family.org> wrote:
> >> The Microsemi FPGA's each have a factory assigned crypto-serial number
> >> (and individual key) built into the FPGA itself, and a programming file
> >> can be generated that can only program that EXACT FPGA (that factory
> >> assigned key). You can also generate a programming file encrypted to a
> >> generic key that any of that model FPGA can take (when you trust the
> >> programming facility)
> >>
> >> Their secure programmer takes a programming file encrypted to the
> >> programmers key, and with a secure file that the designer has to sign,
> >> gets the public key for the FPGA and decrypts and reencrypt the
> >> programming file for THAT FPGA, while ticking off the usage count kept
> >> in its own secure storage.
> >>
> >> This seems fairly secure.
> >
> > It does, but it doesn't seem to address the OP's threat model. Which is
> > that they want to give the third party the source code and the ability to
> > generate their own FPGA bitfiles while still maintaining control (to prevent
> > overproduction). In that instance the third party can modify the FPGA to
> > work around the protection, and you need to do attestation against some
> > external authority (microcontroller for example) to 'activate' the system,
> > and a way that can't be spoofed by changing the FPGA bitfile.
> >
> > So if you can run the secure programmer on a microcontroller and extract the
> > serial number without trusting any bitfile, you might be able to use that as
> > a key for some component that you do not release to the third party (eg
> > firmware that runs on a soft-core inside the FPGA).
> >
> > Or you could require your third party to submit their FPGA bitfile for
> > signing by an approved key server you control, along with a list of serial
> > numbers of FPGAs you want to allow to run it.
> >
> > It sounds like they have a useful toolkit, but it would need further
> > understanding of the pieces and put them together to meet the requirements.
> >
> > Theo
> IF you actually need to give source code, then this system doesn't
> provide protection, but my reading of the situation doesn't define that
> they absolutely need to get source code, but the OP thinks they may want it.
>
> Fundamentally, if you give source code, you have not true secretes in
> what you give them. If you can put something ESSENTIAL, that is also not
> possible to reverse engineer or duplicate into something you can
> control, you can maintain control, at least until they figure out how to
> get around that toll-gate.
>
> In my opioion, if you are going to sell the code for the major part of
> the system, you need to price that part of the transaction to get what
> you need out of it, and make the effectively unenforceable unit fees (if
> any) small enough that they aren't incentivized to break the agreement.

I've made "a bunch" from the unit prices of this design, most of it in the last transaction. I doubt anyone will pay "a bunch" for a board and FPGA design, even if they don't know how to do it up front.

I don't want to negotiate a one time fee for the design. I've found negotiation to be worse than working. I want to set up a license, as they have asked, that gives them the right to make the boards if my company is unable to supply them. I think I can tie the design to the use of a couple of custom chips. While, in theory, they could figure out what they do and how they might be replaced, that would be a redesign of the board, requiring a bunch of product testing, etc. They would only be in the position of making the boards if something happens that I can't produce them. Then they would only consider designing out these devices if they created some problem.

I'm going to let this rattle about in my mind until it is ripe, but at the moment, I'm thinking use the custom chips as a way of tracking their production. A fee will be paid by them according to their stated production. I can verify their production by tracking their use of these parts. I need to figure out if I can track that through the company making the parts, or if I have to be an intermediary.

I haven't heard back from GreenPak as yet. They don't make it easy to contact anyone.

I received an email from a company, Simplytronix. They didn't say anything about why they were contacting me, other than just to say they sell components. The really strange part is my email is rejected by their server and when I dial their number, it never rings. Their web site is so generic, they could be selling nearly anything. I can't figure out how he got the email address he is using, unless he was contacted by myself or someone I'm doing business with.

--

Rick C.

+- Get 1,000 miles of free Supercharging
+- Tesla referral code - https://ts.la/richard11209


devel / comp.arch.fpga / Re: Hardware based IP protection of FPGA designs

1
server_pubkey.txt

rocksolid light 0.9.81
clearnet tor