5
\$\begingroup\$

I have a design that uses an Altera Cyclone FPGA to implement a Physically Unclonable Function (PUF) and an ARM device to do cryptographic work and I/O with the PUF. The PUF is very large, and takes quite a bit of space (only about 1/4th will fit on the Cyclone)

My question is, would I be best served by getting a large enough FPGA to include both the PUF and the ARM core or a smaller FPGA for the PUF and a second, external ARM chip? Can you provide some suggestions?

If I used two chips, they would communicate with SPI. There is not a lot of communication between the two, nor does it need to be fast.

\$\endgroup\$
9
\$\begingroup\$

I can't comment on your specific application (not being a cryptography expert), however placing a processor on board with a FPGA is an exceedingly common thing to do. Mostly the reason is that you now free up FPGA space to do what FPGA is good at, while using the less expensive separate processor to do what it is good at, perhaps even faster than could be done with a soft CPU running in the FPGA. In addition, larger FPGA's can get quite expensive, compared to faster ARM's which can be fairly reasonably priced.

Basically I think you should use the two chips, but it's hard to make a proclamation for sure without knowing details about your specific area.

\$\endgroup\$
5
\$\begingroup\$

I think the right answer of two chips vs. big FPGA will boil down to what sort of attacks the device will face. That means you need to know something about your possible attack scenarios and security needs.

What's the harm if the attacker does probe that SPI communication? Does he get keys? Plaintext? Intermediate stages of the encryption process? If the attacker can parlay that probe into plaintext, what's the harm? Illegal access to a pay satellite tv channel? Financial data? Military secrets? This is the most important thing to understand. It informs all of your other questions (because of course the more sensitive the data, the more it's worth protecting it).

Will the device be somewhere that the attacker can mess with it without detection?

For instance, if it's a security system in a blu-ray player, you have to assume that the attacker is going to open the thing up while it's running at some point. On the other hand, if it's a Military communications system used only by the President of the United States, it might be safe to assume that the attacker isn't going to get any alone time with the device.

How motivated is the attacker? What sort of resources is the attacker likely to have?

Are you allowed to seal the thing into a special box that can destroy the board if breached?

You need a good profile of what you are up against in order to make this decision.

\$\endgroup\$
4
\$\begingroup\$

depends on the size/complexity of the ARM core and the FPGA you need.

The only technical concerns are power usage (the single large FPGA is likely higher) and data integrity on the SPI line. That is, can your system's security be compromised by someone scoping the data being sent on the SPI line.

Other than that, price is the issue. Don't forget to include PCB space and required external components for each IC when consider the price differences.

\$\endgroup\$
  • \$\begingroup\$ For the first version, I completed it using an ARM7TDMI-S processor. You mentioned SPI line integrity, this actually is important. What are some ways that I can secure the transmission? (That might be for a whole seperate question though) \$\endgroup\$ – samoz Jun 30 '10 at 17:39
  • 1
    \$\begingroup\$ well, i don't think there is anything thats perfect in terms of keeping people off those traces. If the data on the line isn't encrypted your SOL. You can use BGA chip packages and run the signal traces on internal layers in the PCB. That would at least keep out those without real motivation. But unless one of the IC's has them internally SPI need pull up resistors so there would still be surface access to the signal. \$\endgroup\$ – Mark Jun 30 '10 at 20:31
  • \$\begingroup\$ +1 for the BGA-internal-layer-trace suggestion, except that SPI does not require pull-up resistors to my knowledge because SPI is daisy-chained point-to-point instead of a shared bus topology. \$\endgroup\$ – ajs410 Jul 1 '10 at 20:08
  • \$\begingroup\$ I shouldn't have said "need" but rather "often requires". SPI can be a shared bus, thats what chip select lines are for. This has nothing to do with the presence of pull up resistors. The need for pull up resistors is dependent on the nature of the I/O pins on the microcontroller (or other devices on the bus). If they are open-collector,aka open-drain in mosfets they may have very weak (~100kohm) pull-ups the bus won't work at higher speeds so an external, lower resistance, pull up is needed. They may also have no pull up at all in which case they are incapable of driving the line high. \$\endgroup\$ – Mark Jul 1 '10 at 23:38
2
\$\begingroup\$

From a practical design standpoint, the separate chips are a good idea. However, security concerns would either required encrypted communications on the bus, careful measures to make sure no important data goes over the bus, or using a single monolithic chip.

There are other issues, too. FPGA's are usually programmed from Flash memory (except in some rare cases that use things like anti-fuses). You also have to worry about the application being eavesdropped on during configuration.

Even after configuration, many FPGA's and other microcontrollers also have JTAG pins that can be used to read the program back out of the device, or inspect other aspects of the programming!

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.