Couverture ElectroniqueS n°127

Les concepteurs de circuits spécifiques doivent mettre en œuvre des algorithmes cryptographiques en hardware, en software ou une combinaison des deux, et faire des comparaisons efficaces entre ces approches exige un ensemble cohérent de mesures. L es applications telles que le stockage chiffré, la communication authentifiée, le démarrage sécurisé et la mise à jour logicielle nécessitent toutes la confidentialité, l'intégrité, l'authenticité et/ou la non-répudiation, qui sont rendues possibles par les algorithmes de cryptographie. Les protocoles de sécurité prescrivent quels algorithmes de cryptographie doivent être utilisés, comment ils doivent être appliqués et dans quel ordre. Dans ces contraintes, les concepteurs de SoC ont beaucoup de choix de mise en œuvre, qui peuvent dépendre du type d'appareil qu'ils essaient de sécuriser, l'importance de le faire, et les contraintes de ressources. La robustesse de l'implémentation de la sécurité variera également en fonction du type d'attaques attendues. Il s'agit donc d'un compromis entre des facteurs tels que le niveau de risque, le niveau de sécurité, le coût d'intégration de la sécurité, la consommation électrique et la performance. RUUD DERWIG (SYNOPSYS) Ruud Derwig est ingénieur principal chez Synopsys. Formé à l'Université de technologie d'Eindhoven, il est préalablement passé par Philips, NXP et Virage Logic. Options d'implémentation de la cryptographie Les algorithmes et les protocoles de cryptographie peuvent être mis en œuvre en hardware, en software, ou une combinai-son des deux. La figure 1 montre les trois méthodes disponibles sur le marché construites de trois manières différentes. La gauche de la figure 1 montre une implémentation purement logicielle construite avec la bibliothèque de logiciels de cryptographie DesignWare de Synopsys. Cette bibliothèque présente des algorithmes de cryptographie symétrique et asymétrique configurables pour les fonctions de chiffrement et de traitement des certificats. La bibliothèque est certifiée dans le cadre du programme de vérification de l'algorithme cryptographique du National Institute of Science and Technology, ce qui la rend utile pour les systèmes devant être conformes à la norme FIPS 140-2. Le milieu de la figure 1 montre un exemple d'accélération partielle au moyen d'instructions spécialisées et de registres auxiliaires. Le processeur de sécurité DesignWare ARC SEM est doté de l'option DesignWare ARC CryptoPack, qui ajoute des instructions et des registres personnalisés aux processeurs ARC pour accélérer les algorithmes logiciels, notamment AES, 3DES, ECC, SHA-256 et RSA. Le côté droit de la figure 1 montre les solutions matérielles. Les solutions IP de cryptographie DesignWare incluent des blocs configurables d'accélération matérielle de cryptographie symétrique et de hachage, des accélérateurs à clé publique (PKA) et des générateurs de nombres vraiment aléatoires (TRNG). Implémentation purement logicielle L'implémentation logicielle implique des compromis entre la performance, la taille du code et la mémoire. Utiliser des tables de correspondance plutôt que de calculer à la volée, par exemple, peut accélérer la mise en œuvre de certains algorithmes – mais sollicite davantage de mémoire. Le dérou-lagedeboucle peut diminuer le nombre de branchements et fournir davantage d'options d'ordonnancement au compilateur, au coût d'un code plus volumineux. Les concepteurs doivent prendre en compte la vulnérabilité de leurs implémentations logicielles aux attaques. Par exemple, l'implémentation de RSA nécessite l'exponentiation modulaire de très grands nombres entiers. L'algorithme Square-and-Mulitply le fait efficacement, mais le temps nécessaire à l'exécution dépend linéairement du nombre de bits «1» dans la clé. En répétant des mesures de temps de réponse pour les différentes valeurs de données et en effectuant une analyse statistique des résultats, un attaquant pourrait obtenir la clé secrète. À titre d'exemple de l'impact des différents choix d'implémentation logicielle, la figure 2 montre la performance en fonction de la taille du code de plusieurs implémentations de hachage SHA. Les étiquettes des points de données indiquent le choix de l'implémentation logicielle. Un nombre indique le facteur de déroulage de boucle, et « pre » ou « otf » indique si l'ordonnanceur de messages est pré-calculé au début de la routine (pre), ou si le calcul est entrelacé à la volée ( on the fly ou otf ). La forme et la couleur des points indiquent la configuration du compilateur pour générer le code optimisé, soit pour la performance ou la taille. La performance est affichée sous forme de nombre de cycles par octet de message, donc un nombre inférieur indique une performance plus élevée. La figure montre que le déroulage de la boucle a le plus grand impact sur la per-formance, mais l'optimisation du compilateur pour la vitesse et le calcul à la volée améliorent également la performance, au coût d'une augmentation de surface. Implémentation accélérée partiellement Dans cette approche, des parties de l'algorithme cryptographique sont implémentées dans un bloc d'accélération matérielle dédié, ce qui améliore la performance globale et réduit la consommation électrique au coût d'une augmentation de surface et d'une flexibilité réduite. Une partie de la surface absorbée par les fonctions d'accélération cryptographique peut être récupérée en réduisant la mémoire d'instructions. La mémoire de données pourrait également être réduite en calculant les valeurs à la volée dans le hardware au lieu d'utiliser des tables de correspondance. Les concepteurs peuvent décharger des calculs logiciels sur du hardware dédié de diverses manières. L'une consiste à utiliser un périphérique à base de bus pour effectuer les calculs, mais cela n'a de sens que si suffisamment de calculs cryptographiques sont déchargés en même temps pour compenser les latences du bus vers et depuis le périphérique. D'autres approches incluent l'utilisation d'une interface de coprocesseur ou l'extension du processeur avec des registres dédiés et des instructions spécialisées. La mise en œuvre de CryptoPack AES montre une approche pour trouver la bonne granularité et la combinaison d'éléments matériels et logiciels pour répondre à une contrainte de performance, surface et consommation. L'algorithme AES répète les mêmes calculs (appelé un «tour») plusieurs fois. CryptoPack introduit une instruction pour le processeur ARC 32 bits qui calcule un quart de tour au lieu d'un tour complet. Cela assure une meilleure utilisation des mots de 32 bits du cœur ARC pour transférer les clés de tour nécessaires de la mémoire à l'accélérateur, en pipeline avec les calculs. La mise en œuvre d'un tour complet en hardware en tant qu'extension d'instructions nécessiterait davantage de portes, mais n'améliorerait pas beaucoup la performance, car des instructions supplémentaires seraient toujours nécessaires pour charger et transférer complètement la clé de tour de 128 bits. Implémentation purement matérielle Dans les cas où une implémentation logicielle ou partiellement accélérée ne fournirait pas suffisamment de performances ou d'efficacité énergétique, un bloc d'accélération matérielle peut mettre en œuvre l'algorithme complet. Le logiciel est alors limité à un pilote de périphérique ou à une couche d'abstraction matérielle pour interagir avec le moteur matériel. Pour les opérations cryptographiques en masse (telles que le hachage, le chiffrement et le déchiffrement), les moteurs matériels ont souvent des fonctionnalités DMA, de sorte que le moteur ne doit pas dépendre d'un processeur et d'un logiciel pilote de périphérique pour les transferts de données. Un autre problème d'implémentation concerne la gestion des clés nécessaires aux algorithmes. Dans une implémentation logicielle, les clés sont accessibles par le logiciel, ce qui peut constituer un risque de sécurité. Dans une implémentation hardware, les clés peuvent être accessibles via une interface dédiée à la mémoire non volatile. Un bloc d'accélération matérielle de cryptographie peut également être configuré avec une mémoire supplémentaire de stockage de clés, de sorte qu'il peut basculer rapidement entre plusieurs clients parallèles. Les concepteurs de SoC doivent également décider de la manière d'implémenter les algorithmes de cryptographie, par exemple en explorant la possibilité d'utiliser des techniques qui assurent un temps de calcul constant pour une sécurité supplémentaire, ou de choisir d'utiliser des tables de correspondance plutôt que de calculer à la volée. Chaque choix a une implication différente sur la robustesse de la mise en œuvre de la sécurité. Robustesse de la sécurité: contre-mesures Différentes implémentations d'un algorithme de cryptographie influent sur les niveaux de robustesse de la sécurité. Par exemple, que se passe-t-il quand une implémentation est alimentée par des paramètres incorrects, tels des clés faibles? Est-ce que l'implémentation vérifie ces cas particuliers ? Résistera-t-elle aux attaques par canal latéral effectuées en mesurant la synchronisation, la puissance ou les émissions électromagnétiques de la mise en œuvre lors de l'exécution d'un algorithme? Les contre-mesures à ces attaques ont un coût en termes de performances, de consommation et de surface. Savoir s'il faut assumer ou non ce coût exige une analyse des types de menaces auxquelles l'appareil peut être confronté, et l'importance de se protéger contre de telles attaques. Les réponses peuvent aller de l'absence de parade physique (le dispositif n'est exploité que dans un environnement sécurisé par des opérateurs de confiance), à certaines parades (la robustesse contre les attaques liées au temps de réponse), ou à un durcissement plus complet (la protection contre l'analyse de consommation différentielle et/ou attaques par injection de faute). Les attaques utilisant les informations temporelles ou la consommation électrique peuvent être contrées en empêchant les fuites d'informations au moyen de techniques assurant un temps de calcul indépendant des données en cours de traitement et/ou en masquant les informations en ajoutant délibérément du bruit parasite. Paramètres mesurables Si les concepteurs de SoC veulent évaluer s'ils ont choisi la solution de traitement cryptographique appropriée, ils doivent choisir des paramètres mesurables avec lesquels comparer les options. Ceux-ci peuvent inclure: - la performance cryptographique, généralement définie comme étant le débit mesuré sous forme de bits ou d'octets par cycle ou seconde, ou d'opérations par seconde. - la latence, c'est-à-dire le temps écoulé entre le début du traitement d'un message et son achèvement. - l'utilisation du processeur lors d'opérations cryptographiques. Ce sera typiquement 100 % pour une solution logicielle, mais moins pour une solution matérielle, surtout si un accélérateur de cryptage est utilisé et que le processeur principal peut effectuer d'autres opérations, ou passer en mode basse consommation. - la taille de la solution. Le bloc hardware peut être mesuré par la taille de la logique et des mémoires ou la surface en résultant. Le logiciel peut être mesuré par l'encombrement mémoire, divisé entre la taille du code et la taille des données. - la puissance, généralement mesurée en watts, ou l'énergie mesurée en joules. La puissance évolue généralement linéairement avec la fréquence, ce qui permet de normaliser la fréquence d'horloge pour mesurer l'efficacité de la consommation en µW/MHz. - la robustesse de sécurité, ce qui est plus difficile à quantifier. Certains tests en laboratoire évaluent le temps nécessaire pour pirater une solution, en fonction de certaines ressources. Les tests en laboratoire font souvent partie de la certification formelle comme les critères communs ou la spécification EMV. Ces certifications peuvent être utilisées pour estimer la robustesse de la sécurité. L'IoT SecureMark d'EEMBC L'Embedded Microprocessor Benchmark Consortium (EEMBC) développe des bancs d'essai tels que CoreMark, la norme de l'industrie pour la performance du microprocesseur embarqué. Il a récemment introduit un ensemble de benchmarks pour l'Internet des objets: IoTMark et SecureMark. SecureMark fournit un cadre pour l'analyse comparative de l'efficacité des solutions de traitement cryptographique, qui prend en charge des profils différents pour les domaines d'application différents. SecureMark-TLS modélise les opérations cryptographiques requises pour le protocole TLS (Transport Layer Security) utilisé pour les communications Internet sécurisées. TLS prend en charge diverses approches cryptographiques pour authentifier les parties communicantes et garantir la confidentialité et l'intégrité des messages échangés entre elles. Le groupe de travail sur la sécurité IoT d'EEMBC a choisi un ensemble d'algorithmes de cryptographie et de paramètres appropriés pour les périphériques d'IoT pour son indice de référence Secu-reMark-TLS. Les résultats de l'indice de référence au niveau du système mesurent l'énergie utilisée et la performance des opérations cryptographiques nécessaires pour effectuer les opérations TLS pour les périphériques IoT. L'infrastructure de test Secure-Mark-TLS connecte le périphérique sous test (DUT), tel qu'un kit de développement IoT basé sur un processeur ARC, à un banc de test doté de deux cartes et de deux composants logiciels. Une carte de gestionnaire d'E/S envoie des commandes à travers un UART au DUT et reçoit des résultats en retour pour vérifier si les opérations ont été effectuées correctement. Une carte de contrôle de l'énergie alimente le DUT et mesure sa consommation. Un horodatage des broches d'E/S, basculé par le DUT, marque le début et la fin des opérations en cours de mesure. Le logiciel d'analyse comparative SecureMark-TLS consiste en une application PC hôte et un logiciel DUT intégré. L'application hôte conduit l'exécution du test en utilisant les cartes du banc de test pour envoyer des commandes au DUT afin d'effectuer des opérations cryptographiques. Il reçoit les résultats des opérations pour les vérifier, et obtient des mesures de consommation et de temps de réponse du moniteur de consommation. Le harnais de test software EEMBC qui s'exécute sur le DUT bascule les E/S d'horodatage pour indiquer quand les mesures de consommation doivent être démarrées et arrêtées, et utilisent une API pour indiquer au DUT d'effectuer diverses opérations cryptographiques de référence. Exemple de résultats de référence Synopsys a expérimenté l'utilisation de la version bêta de SecureMark-TLS, comme illustré sur la figure 3. Il a utilisé l'implémentation de référence mbed TLS d'EEMBC et l'implémentation software de la cryptographie DWC, accélérée par les extensions du processeur ARC EM du DesignWare ARC EM Starter Kit. Le graphique montre les résultats mesurés en unités de temps, normalisés au plus petit nombre (l'opération de hachage SHA256 de 23 octets sur le processeur ARC EM utilisant l'accélération CryptoPack). Les nombres inférieurs sont les meilleurs. L'indice de référence montre que le cryptage symétrique et le hachage sont beaucoup plus rapides que les calculs asymétriques à clé partagée, de signe et de vérification de signature. Cela montre également que l'accélération CryptoPack accélère les processus symétriques et de hachage (AES et SHA) entre quatre fois et sept fois, en fonction de la taille du message. L'accélération des opérations asymétriques ECDH et ECDSA est moindre, jusqu'à 40%. CryptoPack a été conçu pour ajouter seulement 10% à 20% de surface à un petit processeur ARC EM, et les grands multiplicateurs requis pour l'accélération supplémentaire des opérations asymétriques nécessiteraient une surface plus importante. n

Évaluer la solution de cryptage adaptée à son SoC

Couverture ElectroniqueS n°127

IBM grave les premières puces en 2 nm en abandonnant les FinFET

Zeta, le protocole LPWAN made in China, arrive en Europe

Harting invente le connecteur électronique sur mesure

Évaluer la solution de cryptage adaptée à son SoC

Dans la même rubrique

Couverture ElectroniqueS n°127

IBM grave les premières puces en 2 nm en abandonnant les FinFET

Zeta, le protocole LPWAN made in China, arrive en Europe

Harting invente le connecteur électronique sur mesure