¿Qué configuración debo usar para un sistema que incluye un ARM y un FPGA?

Tengo un diseño que utiliza un FPGA Altera Cyclone para implementar una función físicamente no clonable (PUF) y un dispositivo ARM para realizar trabajo criptográfico y E/S con la PUF. El PUF es muy grande y ocupa bastante espacio (solo cabe alrededor de 1/4 en el Cyclone)

Mi pregunta es, ¿sería mejor obtener un FPGA lo suficientemente grande para incluir tanto el PUF como el núcleo ARM o un FPGA más pequeño para el PUF y un segundo chip ARM externo? ¿Puede proporcionar algunas sugerencias?

Si usara dos chips, se comunicarían con SPI. No hay mucha comunicación entre los dos, ni hace falta que sea rápida.

Respuestas (4)

No puedo comentar sobre su aplicación específica (no soy un experto en criptografía), sin embargo, colocar un procesador a bordo con un FPGA es algo extremadamente común. Principalmente, la razón es que ahora libera espacio FPGA para hacer lo que FPGA es bueno, mientras usa el procesador separado menos costoso para hacer lo que es bueno, quizás incluso más rápido de lo que se podría hacer con una CPU suave que se ejecuta en FPGA. Además, los FPGA más grandes pueden resultar bastante caros, en comparación con los ARM más rápidos, que pueden tener un precio bastante razonable.

Básicamente, creo que deberías usar los dos chips, pero es difícil hacer una proclamación con seguridad sin conocer los detalles sobre tu área específica.

Creo que la respuesta correcta de dos chips frente a un FPGA grande se reducirá a qué tipo de ataques enfrentará el dispositivo. Eso significa que necesita saber algo sobre sus posibles escenarios de ataque y necesidades de seguridad.

¿Cuál es el daño si el atacante prueba esa comunicación SPI? ¿Él recibe las llaves? ¿Texto sin formato? ¿Etapas intermedias del proceso de cifrado? Si el atacante puede convertir esa sonda en texto sin formato, ¿cuál es el daño? ¿Acceso ilegal a un canal de televisión por satélite de pago? ¿Datos financieros? ¿Secretos militares? Esto es lo más importante de entender. Informa todas sus otras preguntas (porque, por supuesto, cuanto más confidenciales son los datos, más vale la pena protegerlos).

¿Estará el dispositivo en algún lugar donde el atacante pueda manipularlo sin ser detectado?

Por ejemplo, si se trata de un sistema de seguridad en un reproductor de Blu-ray, debe suponer que el atacante lo abrirá mientras se está ejecutando en algún momento. Por otro lado, si se trata de un sistema de comunicaciones militares utilizado solo por el presidente de los Estados Unidos, es seguro asumir que el atacante no tendrá tiempo a solas con el dispositivo.

¿Qué tan motivado está el atacante? ¿Qué tipo de recursos es probable que tenga el atacante?

¿Se le permite sellar la cosa en una caja especial que puede destruir el tablero si se rompe?

Necesitas un buen perfil de a lo que te enfrentas para tomar esta decisión.

depende del tamaño/complejidad del núcleo ARM y la FPGA que necesite.

Las únicas preocupaciones técnicas son el uso de energía (el único FPGA grande es probablemente más alto) y la integridad de los datos en la línea SPI. Es decir, ¿puede la seguridad de su sistema verse comprometida por alguien que analiza los datos que se envían en la línea SPI?

Aparte de eso, el precio es el problema. No olvide incluir el espacio de PCB y los componentes externos necesarios para cada IC cuando tenga en cuenta las diferencias de precio.

Para la primera versión, la completé usando un procesador ARM7TDMI-S. Usted mencionó la integridad de la línea SPI, esto en realidad es importante. ¿Cuáles son algunas formas en que puedo asegurar la transmisión? (Sin embargo, eso podría ser para una pregunta completamente separada)
Bueno, no creo que haya nada que sea perfecto en términos de mantener a la gente alejada de esos rastros. Si los datos en la línea no están encriptados, su SOL. Puede usar paquetes de chips BGA y ejecutar los rastros de señal en capas internas en la PCB. Eso al menos mantendría alejados a aquellos sin una motivación real. Pero a menos que uno de los circuitos integrados los tenga internamente, SPI necesita resistencias de extracción para que aún haya acceso a la superficie de la señal.
+1 para la sugerencia de rastreo de capa interna de BGA, excepto que SPI no requiere resistencias pull-up, que yo sepa, porque SPI está conectado en cadena punto a punto en lugar de una topología de bus compartida.
No debería haber dicho "necesito", sino "a menudo requiere". SPI puede ser un bus compartido, para eso están las líneas de selección de chip. Esto no tiene nada que ver con la presencia de resistencias pull up. La necesidad de resistencias pull up depende de la naturaleza de los pines de E/S en el microcontrolador (u otros dispositivos en el bus). Si son de colector abierto, también conocido como drenaje abierto en mosfets, pueden tener pull-ups muy débiles (~ 100kohm), el bus no funcionará a velocidades más altas, por lo que se necesita un pull-up externo de menor resistencia. También es posible que no tengan ningún tirón, en cuyo caso son incapaces de impulsar la línea hacia arriba.

Desde un punto de vista de diseño práctico, los chips separados son una buena idea. Sin embargo, las preocupaciones de seguridad requerirían comunicaciones encriptadas en el bus, medidas cuidadosas para asegurarse de que no pasen datos importantes por el bus o el uso de un solo chip monolítico.

También hay otros problemas. Los FPGA generalmente se programan desde la memoria Flash (excepto en algunos casos raros que usan cosas como anti-fusibles). También debe preocuparse de que la aplicación sea espiada durante la configuración.

Incluso después de la configuración, muchos FPGA y otros microcontroladores también tienen pines JTAG que se pueden usar para leer el programa del dispositivo o inspeccionar otros aspectos de la programación.