How to protect fpga based design against cloning?

[Markus Zingg]

Hi all

I don't know too much about fpga's yet so bear with me if this sounds
too silly. I'm quite interested from what I heard so far and intend to
dig deeper into the topic.

While reading diverse articles about fpga's I got the impression that
they have to be programmed out of a prom or through a microprocessor
etc. However, this means that it would be very easy to "catch" this
code in a finished design and abuse it to clone/copy such a design.

So, my question is, is my impression right, and if so what common
protection mechanisms are available? Or are there fpga's available
that contain flash memory for the purpose of progrmming them on chip
or such? Some scheme similar to what's available with most
microcontrollers that contain on chip flash?

TIA

Markus

 

[Peter Molesworth]

On Wed, 29 Oct 2003 13:30:09 +0100, Markus Zingg <m.zingg@nct.ch> wrote:

Hi all

I don't know too much about fpga's yet so bear with me if this sounds
too silly. I'm quite interested from what I heard so far and intend to
dig deeper into the topic.

While reading diverse articles about fpga's I got the impression that
they have to be programmed out of a prom or through a microprocessor
etc. However, this means that it would be very easy to "catch" this
code in a finished design and abuse it to clone/copy such a design.

So, my question is, is my impression right, and if so what common
protection mechanisms are available? Or are there fpga's available
that contain flash memory for the purpose of progrmming them on chip
or such? Some scheme similar to what's available with most
microcontrollers that contain on chip flash?

TIA

Markus

Yes it is possible to clone an FPGA that gets its config from a boot prom
if somebody really wanted to do so. However if you are worried about this
for your design then there are device families out there that are flash or
antifuse based which make this much harder if not almost impossible. Actel
have a feature called 'FlashLock' in their ProASIC+ devices which I
believe is designed to protect against this and their Accelerator family
as well as their older families are antifuse. Also Xilinx do what are
called 'Hardcopy' devices which are basically the same as the original
FPGA but with hardwired logic rather than being configurable. There are
many other choices from Altera, Quicklogic, etc aswell I should imagine.

Cheers,

Pete.

 

[Matt North]

Markus,

You might want to look at Lattice PLD's. They have on board flash.
You write to the chip initialy in the normal manner via JTAG, your code is
then stored on the chips flash untill you reprogram it.

Matt

"Peter Molesworth" <noemail@anonymous.net> wrote in message
newsprxs2d9yz0ve4v7@news.tiscali.co.uk...

On Wed, 29 Oct 2003 13:30:09 +0100, Markus Zingg <m.zingg@nct.ch> wrote:

Hi all

I don't know too much about fpga's yet so bear with me if this sounds
too silly. I'm quite interested from what I heard so far and intend to
dig deeper into the topic.

While reading diverse articles about fpga's I got the impression that
they have to be programmed out of a prom or through a microprocessor
etc. However, this means that it would be very easy to "catch" this
code in a finished design and abuse it to clone/copy such a design.

So, my question is, is my impression right, and if so what common
protection mechanisms are available? Or are there fpga's available
that contain flash memory for the purpose of progrmming them on chip
or such? Some scheme similar to what's available with most
microcontrollers that contain on chip flash?

TIA

Markus

Yes it is possible to clone an FPGA that gets its config from a boot prom
if somebody really wanted to do so. However if you are worried about this
for your design then there are device families out there that are flash or
antifuse based which make this much harder if not almost impossible. Actel
have a feature called 'FlashLock' in their ProASIC+ devices which I
believe is designed to protect against this and their Accelerator family
as well as their older families are antifuse. Also Xilinx do what are
called 'Hardcopy' devices which are basically the same as the original
FPGA but with hardwired logic rather than being configurable. There are
many other choices from Altera, Quicklogic, etc aswell I should imagine.

Cheers,

Pete.

 

[kryten_droid]

You are right, and it is a problem.

I have been thinking about it too.

Overall I feel there isn't much security in the FPGA chips themselves, but I
thought it might be an idea to have a smart card chip (as used in the SIMs
for mobile phones). Your FPGA system configures as per normal.

It then has encrypted conversation with the SIM (which is a far more secure
device), and if it confirms the SIM is valid it works as normal, else it
shuts down as you wish.

This transfers the problem of cracking from the FPGA to the SIM.

The FPGA config can still be ripped off of course, but without the SIM it
will be useless.

SIMs are pretty small and the carriers are easily available.

The SIM only needs a 3.58 (or 5) MHz clock, and 5V or 3V.
(I run my design off 14.3181 MHz, so this is easy to obtain).
The SIM reader electronics is easy to implement.

You still have to write the verification protocol.
Sounds easy but it is not trivial making sure it has no security holes (I've
worked with these chips).
But easier to make the SIM secure (that's what they were designed for) than
the FPGA/config ROM system.

If you do manage to implement this, then it opens up a lot of possibilities.

The SIM is detachable so you can get your stuff built in say the far east
and post the SIMs to the end user by trusted carrier. They can easily
install the SIM.
You might also make the SIM specific to individual signed config ROMs.
Or send upgrade config ROMs with SIMs.

 

[Markus Zingg]

You are right, and it is a problem.

I have been thinking about it too.

Overall I feel there isn't much security in the FPGA chips themselves, but I
thought it might be an idea to have a smart card chip (as used in the SIMs
for mobile phones). Your FPGA system configures as per normal.

It then has encrypted conversation with the SIM (which is a far more secure
device), and if it confirms the SIM is valid it works as normal, else it
shuts down as you wish.

This transfers the problem of cracking from the FPGA to the SIM.

The FPGA config can still be ripped off of course, but without the SIM it
will be useless.

SIMs are pretty small and the carriers are easily available.

The SIM only needs a 3.58 (or 5) MHz clock, and 5V or 3V.
(I run my design off 14.3181 MHz, so this is easy to obtain).
The SIM reader electronics is easy to implement.

You still have to write the verification protocol.
Sounds easy but it is not trivial making sure it has no security holes (I've
worked with these chips).
But easier to make the SIM secure (that's what they were designed for) than
the FPGA/config ROM system.

If you do manage to implement this, then it opens up a lot of possibilities.

The SIM is detachable so you can get your stuff built in say the far east
and post the SIMs to the end user by trusted carrier. They can easily
install the SIM.
You might also make the SIM specific to individual signed config ROMs.
Or send upgrade config ROMs with SIMs.

Thanks for your reply. The problem I see with this aproach - provided
I understood you correctly - is that since the code in the fpga would
be "open" it could be reverse engineered much easier and the sim part
could be shorted as a result also. I might sound paranoid - I'm not, I
just like to know what I'm dealing with.

The aproach with the Lattice PLD containing flash the other poster
mentioned seems to be the best to me so far cause this means that a
cracker would have to physically open the PLD and get down to this
level where as "listening" on the bus is IMHO a lot easier. I might be
wrong here, but at least to me the Lattice PLD aproach would be much
harder to crack.

Well, I'm looking foreward to eventually hear other ideas.

Markus

 

[Peter Alfke]

This discussion has not mentioned the best protection in any FPGA:
All Xilinx Virtex-II devices have an on-chip decryptor that can decrypt
a triple-DES encoded bitstream, using an on-chip stored 3x56-bit key.
This key is kept alive with a small external battery. A small price to
pay for the best security in a wide range of high-performance FPGAs...
Peter Alfke, Xilinx Applications
==================
Markus Zingg wrote:

You are right, and it is a problem.

I have been thinking about it too.

Overall I feel there isn't much security in the FPGA chips themselves, but I
thought it might be an idea to have a smart card chip (as used in the SIMs
for mobile phones). Your FPGA system configures as per normal.

It then has encrypted conversation with the SIM (which is a far more secure
device), and if it confirms the SIM is valid it works as normal, else it
shuts down as you wish.

This transfers the problem of cracking from the FPGA to the SIM.

The FPGA config can still be ripped off of course, but without the SIM it
will be useless.

SIMs are pretty small and the carriers are easily available.

The SIM only needs a 3.58 (or 5) MHz clock, and 5V or 3V.
(I run my design off 14.3181 MHz, so this is easy to obtain).
The SIM reader electronics is easy to implement.

You still have to write the verification protocol.
Sounds easy but it is not trivial making sure it has no security holes (I've
worked with these chips).
But easier to make the SIM secure (that's what they were designed for) than
the FPGA/config ROM system.

If you do manage to implement this, then it opens up a lot of possibilities.

The SIM is detachable so you can get your stuff built in say the far east
and post the SIMs to the end user by trusted carrier. They can easily
install the SIM.
You might also make the SIM specific to individual signed config ROMs.
Or send upgrade config ROMs with SIMs.

Thanks for your reply. The problem I see with this aproach - provided
I understood you correctly - is that since the code in the fpga would
be "open" it could be reverse engineered much easier and the sim part
could be shorted as a result also. I might sound paranoid - I'm not, I
just like to know what I'm dealing with.

The aproach with the Lattice PLD containing flash the other poster
mentioned seems to be the best to me so far cause this means that a
cracker would have to physically open the PLD and get down to this
level where as "listening" on the bus is IMHO a lot easier. I might be
wrong here, but at least to me the Lattice PLD aproach would be much
harder to crack.

Well, I'm looking foreward to eventually hear other ideas.

Markus

 

[Petter Gustad]

Peter Molesworth <noemail@anonymous.net> writes:

antifuse. Also Xilinx do what are called 'Hardcopy' devices which are
basically the same as the original FPGA but with hardwired logic

Altera has HardCopy, not Xilinx.

Petter
--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

 

[Nicholas C. Weaver]

In article <l9cvpv4fb6dssvm0u6pn4t84di2cn0op9p@4ax.com>,
Markus Zingg <m.zingg@nct.ch> wrote:

So, my question is, is my impression right, and if so what common
protection mechanisms are available? Or are there fpga's available
that contain flash memory for the purpose of progrmming them on chip
or such? Some scheme similar to what's available with most
microcontrollers that contain on chip flash?

The V2/V2Pro has a configuration loader which can load bitfiles
encrypted with DES/3DES. The decryption keys are stored, in
battery-backed-up SRAM on the FPGA.

--
Nicholas C. Weaver nweaver@cs.berkeley.edu

 

[Martin Euredjian]

"Markus Zingg" wrote:

While reading diverse articles about fpga's I got the impression that
they have to be programmed out of a prom or through a microprocessor
etc. However, this means that it would be very easy to "catch" this
code in a finished design and abuse it to clone/copy such a design.

One take on this is the actual value of a bitstream and how someone
would/could use it in a commercial application and potential reproduction of
your project. I've put a lot of thought into this and decided that, at
least for the type of work I'm doing, it's not an issue. Why? Because, by
the nature of the designs, if someone were to copy the bitstream with intent
to clone the design (presumably for commercial gain) they'd also have to
design their board exactly as mine. There isn't a court in the world that
wouldn't favor the original designer when shown that evidence.

In complex designs, where a microprocessor might be running an FPGA as a
peripheral, the commercial value of the bitstream might be reduced even
further. You could implement all sorts of little tricks to make sure you
can show a judge that the design was stolen from you. Like, a pin on the
FPGA that, when connected to a PC serial port through a resistor displays a
repeating "STOLEN FROM ..." message.

Without doing much thinking, the only applications that I'd think truly
require bitstream protection might be government/military or when the
requirement is simply dictated down to the design engineer/consultant by the
employer, for whatever reasong (including ignorance). In those cases Xilinx
has you covered rather well with the triple DES technology and a little $3
battery.


--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Martin Euredjian

To send private email:
0_0_0_0_@pacbell.net
where
"0_0_0_0_" = "martineu"

 

[Glen Herrmannsfeldt]

"Martin Euredjian" <0_0_0_0_@pacbell.net> wrote in message
news:J8Vnb.151$t45.14067905@newssvr21.news.prodigy.com...

"Markus Zingg" wrote:

While reading diverse articles about fpga's I got the impression that
they have to be programmed out of a prom or through a microprocessor
etc. However, this means that it would be very easy to "catch" this
code in a finished design and abuse it to clone/copy such a design.

One take on this is the actual value of a bitstream and how someone
would/could use it in a commercial application and potential reproduction
of
your project. I've put a lot of thought into this and decided that, at
least for the type of work I'm doing, it's not an issue. Why? Because,
by
the nature of the designs, if someone were to copy the bitstream with
intent
to clone the design (presumably for commercial gain) they'd also have to
design their board exactly as mine. There isn't a court in the world that
wouldn't favor the original designer when shown that evidence.

My belief is that for most devices, in most markets, with reasonable markups
this is true.

Consider the toy/video game market. (I don't know if any use FPGA, but they
could.) The markup is generally very low, using the razor model and making
most of the money off selling the games (software). In that case, someone
will have a hard time pricing it low enough (assuming one uses cheap foreign
labor, as the cloners would). Also, the profitable lifetime is short.

Consider the high end scientific/engineering equipment market. The number
of devices built will be low, and they might be sold with a high markup (to
cover design cost, for example). Usually, though, support is an important
part of the purchase, and buyers of clone devices wouldn't get any support.
There is also the embarassment of being caught with an illegal device,
especially in a public company.

If your market is primarily in places that have strong copyright laws, that
is a big part of your protection. If a large part of the market is in
places with weak copyright laws, then you have to consider other
alternatives.

-- glen

 

[Khim Bittle]

On Wed, 29 Oct 2003 13:30:09 +0100, Markus Zingg <m.zingg@nct.ch>
wrote:

Hi all

I don't know too much about fpga's yet so bear with me if this sounds
too silly. I'm quite interested from what I heard so far and intend to
dig deeper into the topic.

While reading diverse articles about fpga's I got the impression that
they have to be programmed out of a prom or through a microprocessor
etc. However, this means that it would be very easy to "catch" this
code in a finished design and abuse it to clone/copy such a design.

So, my question is, is my impression right, and if so what common
protection mechanisms are available? Or are there fpga's available
that contain flash memory for the purpose of progrmming them on chip
or such? Some scheme similar to what's available with most
microcontrollers that contain on chip flash?

TIA

Markus

This is an interesting subject. I guess there are two concerns:

1) Theft of the configuration bitstream so that you could clone and
produce identical products. Obviously the circuitry connected to the
FPGA would have to be a copy and probably not to hard to go after the
bad guys in the courts with copywrite laws etc. I am more concerned
about #2.

2) IP Theft. The question here is ( in the Altera/Xilinx context )
if you record the configuration bitstream what can you do with it as
far as reverse engineering ? Can anyone reasonably , meaning with
existing tools or software or ... how?, take this bitstream and
figure out your HDL ? I wouldn't know where to start but perhaps
there are some factory or other smart folks here who have a better
insight into this ??

Khim Bittle

 

[David R Brooks]

As Peter Alfke has pointed out, Xilinx FPGAs can use a 3DES encrypted
bitstream, with battery-backed SRAM in the FPGA holding the key.
But if batteries are verboten for you, bear in mind that it's one
thing to *copy* a bit stream, and quite another to reverse-engineer it
to a point where one can make useful changes. So the SIM-card idea is
still useful. That idea of shipping the SIM separately to the
end-users, so that the (contract) manufacturer cannot sell units on
the side, also has merit.

Markus Zingg <m.zingg@nct.ch> wrote:

:>You are right, and it is a problem.
:>
:>I have been thinking about it too.
:>
:>Overall I feel there isn't much security in the FPGA chips themselves, but I
:>thought it might be an idea to have a smart card chip (as used in the SIMs
:>for mobile phones). Your FPGA system configures as per normal.
:>
:>It then has encrypted conversation with the SIM (which is a far more secure
:>device), and if it confirms the SIM is valid it works as normal, else it
:>shuts down as you wish.
:>
:>This transfers the problem of cracking from the FPGA to the SIM.
:>
:>The FPGA config can still be ripped off of course, but without the SIM it
:>will be useless.
:>
:>SIMs are pretty small and the carriers are easily available.
:>
:>The SIM only needs a 3.58 (or 5) MHz clock, and 5V or 3V.
:>(I run my design off 14.3181 MHz, so this is easy to obtain).
:>The SIM reader electronics is easy to implement.
:>
:>You still have to write the verification protocol.
:>Sounds easy but it is not trivial making sure it has no security holes (I've
:>worked with these chips).
:>But easier to make the SIM secure (that's what they were designed for) than
:>the FPGA/config ROM system.
:>
:>If you do manage to implement this, then it opens up a lot of possibilities.
:>
:>The SIM is detachable so you can get your stuff built in say the far east
:>and post the SIMs to the end user by trusted carrier. They can easily
:>install the SIM.
:>You might also make the SIM specific to individual signed config ROMs.
:>Or send upgrade config ROMs with SIMs.
:
:Thanks for your reply. The problem I see with this aproach - provided
:I understood you correctly - is that since the code in the fpga would
:be "open" it could be reverse engineered much easier and the sim part
:could be shorted as a result also. I might sound paranoid - I'm not, I
:just like to know what I'm dealing with.
:
:The aproach with the Lattice PLD containing flash the other poster
:mentioned seems to be the best to me so far cause this means that a
:cracker would have to physically open the PLD and get down to this
:level where as "listening" on the bus is IMHO a lot easier. I might be
:wrong here, but at least to me the Lattice PLD aproach would be much
:harder to crack.
:
:Well, I'm looking foreward to eventually hear other ideas.
:
:Markus

 

[Peter Alfke]

Khim Bittle wrote:

1) Theft of the configuration bitstream so that you could clone and
produce identical products. Obviously the circuitry connected to the
FPGA would have to be a copy and probably not to hard to go after the
bad guys in the courts with copywrite laws etc. I am more concerned
about #2.

2) IP Theft. The question here is ( in the Altera/Xilinx context )
if you record the configuration bitstream what can you do with it as
far as reverse engineering ? Can anyone reasonably , meaning with
existing tools or software or ... how?, take this bitstream and
figure out your HDL ? I wouldn't know where to start but perhaps
there are some factory or other smart folks here who have a better
insight into this ??

The simple answer is that it is impossible, since there is no

documentation about the function of the individual config bits.
The more sophisticated answer would be that is outrageously difficult
and time consuming. After all the detective work figuring out what
millions of individual bit are doing ( or not doing), you finally arrive
at a big unstructured circuit mess.
Good luck!
I think it is easier to re-invent the functionality than to
reverse-engineer it.

Peter Alfke

 

[Hal Murray]

That idea of shipping the SIM separately to the
end-users, so that the (contract) manufacturer cannot sell units on
the side, also has merit.

How much of a problem is that?

I'd think that major US based contract manufacturer would be
very careful. It would be a serious damage to their reputation
if something like that happened and word about it got out.

--
The suespammers.org mail server is located in California. So are all my
other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited
commercial e-mail to my suespammers.org address or any of my other addresses.
These are my opinions, not necessarily my employer's. I hate spam.

 

[kryten_droid]

"Hal Murray" <hmurray@suespammers.org> wrote in message
news:vq0q8120q03379@corp.supernews.com...

That idea of shipping the SIM separately to the
end-users, so that the (contract) manufacturer cannot sell units on
the side, also has merit.

How much of a problem is that?

I'd think that major US based contract manufacturer would be
very careful. It would be a serious damage to their reputation
if something like that happened and word about it got out.

True.

I suspect most people only behave fairly because of the risks and costs of
getting caught are high.

In poorer parts of the world (where much manufacturing is done) they have
much to gain from 'cheating' and know the difficulty of flying lawyers there
to do expensive international legal actions.

Often they don't give a mouse-sized shit -
their attitude is "what are you going to do about it?"

Some people don't have a reputation to worry about.

 

[Jake Janovetz]

Several years ago in an interview with a large company, a friend of
mine asked how they ended up reverse engineering a product from
another large company. The guy smirked and said: "We removed the top
and took lots of pictures." They were working on a full-custom ASIC.

First entry on Google: http://www.bltinc.com

Jake


khimbittle@cliftonREMOVEsystems.com (Khim Bittle) wrote in message news:<3fa04f49.34454006@news.compuserve.com>...

On Wed, 29 Oct 2003 13:30:09 +0100, Markus Zingg <m.zingg@nct.ch
wrote:

Hi all

I don't know too much about fpga's yet so bear with me if this sounds
too silly. I'm quite interested from what I heard so far and intend to
dig deeper into the topic.

While reading diverse articles about fpga's I got the impression that
they have to be programmed out of a prom or through a microprocessor
etc. However, this means that it would be very easy to "catch" this
code in a finished design and abuse it to clone/copy such a design.

So, my question is, is my impression right, and if so what common
protection mechanisms are available? Or are there fpga's available
that contain flash memory for the purpose of progrmming them on chip
or such? Some scheme similar to what's available with most
microcontrollers that contain on chip flash?

TIA

Markus

This is an interesting subject. I guess there are two concerns:

1) Theft of the configuration bitstream so that you could clone and
produce identical products. Obviously the circuitry connected to the
FPGA would have to be a copy and probably not to hard to go after the
bad guys in the courts with copywrite laws etc. I am more concerned
about #2.

2) IP Theft. The question here is ( in the Altera/Xilinx context )
if you record the configuration bitstream what can you do with it as
far as reverse engineering ? Can anyone reasonably , meaning with
existing tools or software or ... how?, take this bitstream and
figure out your HDL ? I wouldn't know where to start but perhaps
there are some factory or other smart folks here who have a better
insight into this ??

Khim Bittle

 

[Glen Herrmannsfeldt]

"Peter Alfke" <peter@xilinx.com> wrote in message
news:3FA06256.3B3F612B@xilinx.com...

Khim Bittle wrote:
(snip)
2) IP Theft. The question here is ( in the Altera/Xilinx context )
if you record the configuration bitstream what can you do with it as
far as reverse engineering ? Can anyone reasonably , meaning with
existing tools or software or ... how?, take this bitstream and
figure out your HDL ? I wouldn't know where to start but perhaps
there are some factory or other smart folks here who have a better
insight into this ??

The simple answer is that it is impossible, since there is no
documentation about the function of the individual config bits.
The more sophisticated answer would be that is outrageously difficult
and time consuming. After all the detective work figuring out what
millions of individual bit are doing ( or not doing), you finally arrive
at a big unstructured circuit mess.
Good luck!
I think it is easier to re-invent the functionality than to
reverse-engineer it.

For large designs, I would have to agree. People used to talk about
disassembling software and reverse engineering from that. In the days when
software was 8K bytes or so, it might have been possible. It is possible
to carry around 4000 lines of disassembled code, try to follow it and
comment it as one learns the functions. Consider that some programs today
may be 80M, or maybe 20 million lines of disassembled code. Well, maybe
some of it is tables and such. It may have been written in a high-level
language, but you will get uncommented assembly code, with numeric addresses
instead of symbolic ones.

It might have been possible to disassemble the code for an XC4002 and figure
out the functions. You might be able to carry around the netlist for it.
It will be a netlist, and likely not VHDL, or at least not readable VHDL.
For a device with millions, or hundreds of millions of equivalent gates,
well, you can figure out how big it might be to print.

It would probably be possible if your budget is in the tens of millions of
dollars or so. Just a guess.

-- glen

 

[Markus Zingg]

This discussion has not mentioned the best protection in any FPGA:
All Xilinx Virtex-II devices have an on-chip decryptor that can decrypt
a triple-DES encoded bitstream, using an on-chip stored 3x56-bit key.
This key is kept alive with a small external battery. A small price to
pay for the best security in a wide range of high-performance FPGAs...
Peter Alfke, Xilinx Applications

Hi Peter

Thanks for your reply. This sounds like a good solution too. The
battery aproach is a bit two folded. On one hand it may adds security
in that if someone would tamper with the device and power would be
interupted the key is lost. On the other hand there are the added
costs of such a battery and also the not always so consistent
livespan. In other words the user would not even be able to replace
this battery or in other words, once the battery is low the product is
trash - right?

Markus

 

[Lorenzo Lutti]

"Peter Alfke" <peter@xilinx.com> ha scritto nel messaggio
news:3F9FF64E.CD3D238B@xilinx.com...

This discussion has not mentioned the best protection in
any FPGA:
All Xilinx Virtex-II devices have an on-chip decryptor
that can decrypt
a triple-DES encoded bitstream, using an on-chip stored
3x56-bit key.
This key is kept alive with a small external battery.

Another solution (more suitable for smaller devices, even if slightly less
secure) could be to use a private-public key algorithm, like PGP: you
encrypt the bitfile with the public key, and the FPGA decrypts it with the
private key. The private key would be the same for all the devices (or a
"group" of devices), so you could "hardwire" the decode logic and save costs
and space.

--
Lorenzo

 

[Brad Eckert]

hmurray@suespammers.org (Hal Murray) wrote in message news:<vq0q8120q03379@corp.supernews.com>...

That idea of shipping the SIM separately to the
end-users, so that the (contract) manufacturer cannot sell units on
the side, also has merit.

How much of a problem is that?

I'd think that major US based contract manufacturer would be
very careful. It would be a serious damage to their reputation
if something like that happened and word about it got out.

No problem in the US. China is another story, where IP rip-off is
business as usual. Cultural change doesn't happen overnight.

If you boot from parallel EPROM, you usually need a CPLD. If the CPLD
has a little logic left over, an authentication algorithm can be
implemented between the CPLD and FPGA. Ship the manufacturer enough
pre-programmed CPLDs for the build.