Autor: Giancarlo Parodi, ingeniero principal de marketing de productos, Renesas Electronics
Traducción: Samantha Navarro
En la actualidad, los requisitos de memoria de los sistemas integrados aumentan constantemente debido a la creciente funcionalidad de conectividad y la complejidad a nivel de aplicación. Muchos microcontroladores del mercado ofrecen una densidad de almacenamiento del orden de unos pocos megabytes, que hace solo una década se habría considerado más que suficiente y a prueba de futuro para la aplicación promedio. Por otro lado, la integración de una memoria aún más no volátil requiere un área de silicio bastante grande, lo que afecta significativamente el coste del producto. Una solución alternativa adecuada es utilizar memoria externa, que se puede comprar en grandes cantidades a precios comparativamente más bajos y con varias opciones de densidad, que normalmente van desde unos pocos hasta decenas de megabytes.
La solución de memoria externa es adecuada no solo para almacenar datos de la aplicación, sino también código de la aplicación, por lo que elimina cualquier preocupación sobre la hoja de ruta del proveedor para poder satisfacer las necesidades futuras. Por otro lado, hay que tener en cuenta algunos aspectos adicionales, como el rendimiento del código que se ejecuta desde la memoria externa y cómo proteger el código de la aplicación de la clonación o modificación.
Para el primer problema, la solución es utilizar una memoria con una interfaz amplia que aumente el rendimiento físico de las líneas serie. Las memorias con una interfaz octal ofrecen una de las mejores opciones en términos de equilibrio entre el número de conexiones de E/S y la mejora del rendimiento de 2x alcanzable en comparación con la interfaz quad-spi heredada. Normalmente, estas memorias modernas también admiten frecuencias de funcionamiento ligeramente superiores, por lo que la mejora del rendimiento es aún más significativa.
La protección del contenido de la memoria requiere el uso de técnicas de criptografía para cifrar el código, ya que de lo contrario sería fácil para un atacante conectarse a la memoria y leer la información almacenada con poco esfuerzo. Para evitar latencias en el proceso de descifrado es necesario utilizar soluciones de diseño que sean rápidas y se ejecuten en línea con el proceso de obtención de instrucciones, es decir, transparentes desde la perspectiva de la CPU. Los últimos MCU de Renesas, como la serie RA8x1, implementan una arquitectura denominada «decodificación sobre la marcha» (DOTF) que cumple exactamente este propósito. En la Figura 1 se puede ver una representación conceptual de la solución.
Figura 1. Arquitectura DOTF
El principio es bastante simple y se basa en el estándar de cifrado/descifrado AES, utilizando el modo contador (CTR) como se especifica en NIST SP800-38A. El principio de funcionamiento del modo CTR se muestra en la Figura 2.
Figura 2. Modo CTR (fuente: NIST SP800-38A)
En el modo CTR, se utiliza un conjunto de contadores como entrada para una función de cifrado de bloques, para generar una salida secreta que luego se combina con el texto simple (o texto cifrado) para cifrar (o descifrar) los datos del mensaje. La secuencia de contadores debe elegirse de modo que cada bloque de entrada del conjunto sea diferente y único. Este requisito es válido para todos los «mensajes» (es decir, elementos de datos) que se cifran utilizando la misma clave.
Una propiedad interesante del modo CTR es que las funciones de cifrado asociadas con el contador se pueden realizar por adelantado de forma independiente unas de otras y no necesitan esperar a que el bloque de datos esté disponible. Esto ayuda a reducir la latencia durante la lectura de los datos cifrados de la memoria octal, ya que la generación del bloque de salida se puede realizar en paralelo. Además, un bloque de texto simple puede recuperarse independientemente de cualquier otro bloque, lo que resulta adecuado para obtener datos del programa, ya que, según el flujo del programa, el procesador puede solicitar leer código en ubicaciones de direcciones no secuenciales.
Los parámetros utilizados para definir los contadores deben elegirse con cuidado para garantizar su unicidad. Un bloque AES tiene un tamaño de 16 bytes (128 bits); por lo tanto, el contador también debe tener 128 bits de ancho. Cada bloque cifrado en la memoria también está alineado a 16 bytes, y para crear un contador único se puede utilizar una concatenación de un valor inicial y la dirección de memoria.
El valor inicial es esencialmente un “nonce” (número aleatorio único que se utiliza una vez) y la dirección del bloque cifrado que se está leyendo tiene los 4 LSB enmascarados, para crear el valor del contador de acuerdo con el siguiente esquema: contador [127:0] = ValorInicial [127:28] || (DirecciónMemoria [31:4] >> 4).
La implementación incluye un par de características interesantes adicionales que resultan muy útiles para convertirla en una solución flexible y fácil de usar. En primer lugar, la aplicación puede definir un límite de dirección para el cual se utilizará el descifrado sobre la marcha o se omitirá de otro modo, como se muestra en la Figura 3.
Figura 3. Límites DOTF
Esto resulta muy conveniente si la aplicación desea dividir el contenido de la memoria flash entre código y otros datos, donde el código se descifra sobre la marcha y los datos se leen simplemente sin descifrarlos. Esto último también permite que la aplicación utilice otra clave o modo de cifrado para los datos y evita compartir la clave de cifrado/descifrado del código de la aplicación para múltiples propósitos.
En cuanto a la alineación del área DOTF, aunque el estándar de cifrado AES implica una alineación mínima de 16 bytes, dada la organización típica de una memoria flash, el límite se colocará en un sector o tamaño de bloque (el tamaño mínimo de la unidad flash que se puede borrar durante la programación). En la implementación, el límite DOTF se puede configurar para una alineación de dirección de 4 KB; de hecho, la aplicación evitará de todos modos tener un bloque de memoria que almacene datos DOTF y no DOTF, lo que complicaría innecesariamente las actualizaciones en el campo y la programación de fábrica. El dispositivo de memoria flash se asigna linealmente al espacio direccionable de la MCU, y la IP Octa se encarga de emitir los comandos de lectura adecuados; esto se denomina normalmente modo de operación XiP (ejecución en el lugar). Para el área cifrada, cualquier acceso a los bloques de 16 bytes solicitados se puede realizar de manera eficiente emitiendo una sola vez la dirección requerida y luego leyendo los datos de manera continua, lo que reduce al mínimo la sobrecarga del protocolo OctaSPI.
Otro aspecto importante es cómo se maneja y carga la clave de descifrado. En los dispositivos que admiten DOTF, hay un motor AES dedicado implementado dentro de la IP, pero la clave para el proceso de descifrado se carga a través de una conexión de bus privada a la IP segura de Renesas; esto evita la filtración del valor de la clave a través de la interconexión de bus interna de la MCU. Además, las claves manejadas por la IP segura de Renesas están cifradas, por lo que se pueden almacenar de forma segura en la memoria sin problemas de confidencialidad e integridad. El motor DOTF admite claves de tamaño de 128, 192 y 256 bits para lograr la máxima flexibilidad y opciones a prueba de futuro, y no hay límite en la cantidad de claves diferentes que se pueden usar para descifrar una imagen específica. Esto último implica que cualquier actualización de firmware puede usar una clave diferente si se desea, y no hay necesidad de compartir la misma clave entre diferentes MCU. La preparación de la nueva imagen se puede realizar cómodamente sin conexión en un host seguro, antes de enviar la actualización de la imagen a un dispositivo en el campo o enviar la imagen cifrada a un fabricante contratado para su programación. La clave de descifrado inicial, o una «clave de actualización de clave» (para actualizar la clave de descifrado en el campo) se puede inyectar de forma segura en el MCU durante la producción. Las claves inyectadas, ya sea en el campo o en la etapa de producción, siempre están vinculadas al MCU específico, de modo que se evita la clonación.
Además, la IP proporciona contramedidas para protegerse contra ataques de canal lateral.
Toda la operación en tiempo de ejecución se realiza de forma transparente por el hardware, y los controladores de software proporcionados se encargan de inicializar y cargar los parámetros para la operación DOTF (valor inicial, límites) y la clave, antes de que pueda comenzar la operación.
Todos los MCU que requieren capacidad de expansión de memoria y requisitos de aplicaciones complejos se beneficiarán de este tipo de solución, que garantiza que el desarrollador de MCU disfrutará de una hoja de ruta de aplicación sólida y, al mismo tiempo, protegerá la inversión en software. Para obtener más información sobre la familia de MCU RA, visite www.renesas.com/ra.
