Couverture ElectroniqueS n°127

Pour répondre à la nécessité de protéger la propriété intellectuelle du piratage, tout en facilitant son déploiement, Synplicity a mis au point une méthodologie ouverte de cryptage/décryptage. Grâce à elle, fournisseurs de blocs IP et éditeurs d'outils de CAO peuvent proposer des solutions capables de tirer pleinement parti du potentiel des conceptions à base de blocs IP. L'apparition dans le domaine de la conception de circuits intégrés des blocs de propriété intellectuelle (IP) à forte valeur ajoutée, voici plus de dix ans, était porteuse de promesses : perspectives d'économies substantielles en termes de temps de développement, fonctionnalités de conception améliorées, facilité accrue de réutilisation des efforts de conception, pour ne citer que les principales. Malheureusement, cette approche est loin d'avoir atteint les espoirs qu'elle avait suscités. En fait, bien que de très nombreux blocs IP extrêmement performants aient été introduits sur le marché, l'échec est venu de la manière dont ils s'intègrent dans un flot de conception classique. En clair, de nombreuses équipes de conception ont eu, et ont encore, les pires difficultés à utiliser facilement les blocs IP au sein de leur kit d'outils de conception existant. Au c&oelig;ur du problème, on trouve la nécessité pour les fournisseurs d'IP de protéger leur investissement de développement. En effet, peu de concepteurs de circuits intégrés peuvent se permettre de payer le prix prohibitif du code source d'un bloc IP sous la forme d'un fichier RTL. C'est la raison pour laquelle beaucoup de fournisseurs de tels blocs proposent des versions nettement moins onéreuses sous forme de « boîte noire », c'est-à-dire avec un code source crypté, qui peuvent être utilisées avec certains outils de conception spécifiques. Le problème ici est double : non seulement ces fournisseurs ont la lourde tâche de maintenir plusieurs versions de leurs c&oelig;urs adaptées à différents kits d'outils mais, au-delà et plus grave encore, cette approche est complètement inadaptée pour toute une population de concepteurs. En effet, la plupart des flots de conception utilisés à l'heure actuelle sont constitués de plusieurs outils de CAO provenant de sources diverses. Il est par conséquent difficile, voire impossible, pour les concepteurs de circuits d'employer des blocs IP cryptés sur l'ensemble de leur flot. De plus, de tels flots, appelés « black box flow » (flots boîte noire), peuvent gêner les équipes de conception dans leurs tâches de débogage et, in fine, les empêcher de développer un produit final optimisé. Si l'on examine par exemple le seul cas de la synthèse pour un FPGA, on s'aperçoit que l'utilisateur (qui intègre des blocs IP), le fournisseur d'outils de CAO (ici la synthèse logique) et le vendeur de FPGA (pour les logiciels de placement-routage final) doivent accomplir des efforts importants de manipulation de données, consommateurs de temps de calcul, pour crypter puis décrypter à plusieurs reprises, les blocs IP entrant dans la conception du FPGA (figure 1). Pour un flot d'Asic, la situation est similaire avec en plus les contraintes liées aux étapes complexes de vérifications pour lesquelles l'accès au code source du bloc IP crypté est impossible. Diffuser la méthode, une nécessité Etant donné que les clés, le cryptage et le décryptage sont tous gérés dans l'environnement de conception, de manière transparente pour l'utilisateur final, ce dernier n'a aucune opération spécifique supplémentaire à initier. Côté concepteur d'IP, les tâches à réaliser consistent à créer, d'une part, une clé privée symétrique et, d'autre part, à « activer » les outils de CAO en cryptant sa clé symétrique avec la clé publique de chacun des éditeurs de CAO. Avec un seul fichier par c&oelig;ur IP, cette tâche est ainsi grandement simplifiée par rapport au passé. L'éditeur de CAO électronique fournit une clé publique, qui constitue la moitié de la paire clé publique/clé privée, utilisable par quiconque veut que son IP fonctionne avec les éditeurs d'outils de CAO de leur choix. On le voit, le cryptage de blocs IP n'est pas un processus compliqué et s'avère beaucoup moins laborieux que les méthodes actuelles. Car le créateur de code peut crypter la source à l'aide du script écrit en langage Perl « protectip » mis à disposition du public (voir tableau dans l'encadré I). Ce script en Perl réalise toutes les opérations de cryptage et de packaging, en s'appuyant sur un utilitaire en Open Source appelé Openssl. Cet utilitaire est aujourd'hui intégré dans la plupart des configurations du système d'exploitation Linux. Quant aux exécutables Windows, ils peuvent être trouvés facilement sur le web. Les possibilités de cette méthodologie ouverte de cryptage d'IP ont été testées et éprouvées par plusieurs entités qui l'ont déjà adoptée, notamment les sociétés Lattice Semiconductor et Aldec. Concernant cette dernière, un accord de coopération étroit avec Synplicity a permis à Aldec de supporter au sein de son outil de simulation Riviera la méthode de cryptage proposée par Synplicity. Les utilisateurs de cet outil peuvent donc d'ores et déjà crypter des blocs IP et/ou simuler des designs intégrant des blocs IP cryptés au sein de l'environnement de simulation Riviera. Une diffusion plus large de cette méthode constitue la prochaine étape qui lui permettra de réaliser son plein potentiel. Pour faciliter cette diffusion, Synplicity a décidé de fournir l'ensemble de ses travaux à l'organisme VSIA afin de poursuivre le déploiement de la technologie (encadré II). En effet, grâce à l'appui d'un organisme de normalisation, en l'occurrence ici le VSIA, cette méthodologie pourra plus rapidement toucher un large éventail d'éditeurs de CAO électronique et de fournisseurs de blocs IP, ainsi que servir la communauté des utilisateurs. Avec ce nouveau flux de cryptage, les fournisseurs d'IP pourront proposer des composants fonctionnels interopérables avec différents kits d'outils de conception, sans soucis de sécurité ni processus laborieux de cryptage. De leur côte, les éditeurs d'outils de CAO seront à même de prendre en charge une vaste palette de fournisseurs de blocs IP sans grever les temps de maintenance et de mise à jour de leurs logiciels. Enfin, les utilisateurs, pour qui la protection de la propriété intellectuelle a jusqu'à présent constitué une nuisance qui inhibait leur liberté de conception et le choix des outils, seront plus libres que par le passé dans leur choix du bloc IP le plus approprié à leurs besoins. (*) Openssl (Open secure socket layer) est une implantation Open Source des protocoles cryptographiques TLS (Transport layer security) et SSL (Secure socket layer) destinés à l'origine à assurer des communications sécurisées sur Internet. I. - Plusieurs variantes de cryptage symétrique Le choix du type de cryptage symétrique utilisant le logiciel Open Source Openssl (troisième commutateur dans le tableau) a une influence sur la spécification du texte ou des clés hexadécimales à utiliser (respectivement quatrième et cinquième commutateurs dans le tableau). Il revêt donc une importance toute particulière. Les trois types de cryptage symétriques les plus courants, à savoir DES, 3DES et AES, sont actuellement pris en charge par le script : Le cryptage DES (nom du commutateur de cryptage « des-cbc ») est rapide mais peu sûr. Ce type de cryptage exige soit une clé alphabétique sur huit caractères, soit une clé hexadécimale sur 64 bits. Etant donné que DES n'utilise que 7 bits par octet, la longueur réelle de la clé est de 56 bits. Le cryptage 3DES (nom du commutateur de cryptage « 3des-cbc ») correspond à trois utilisations d'un algorithme DES simple, avec trois clés différentes. Ce type de cryptage est beaucoup plus sûr que DES, mais il prend plus de temps. Cette méthode de cryptage réclame soit une clé alphabétique sur 24 caractères, soit une clé hexadécimale sur 192 bits. Elle est de plus en plus utilisée au détriment de la méthode DES. Le cryptage AES (nom du commutateur de cryptage « aes128-cbc ») est le plus sûr de tous, tout en demandant un temps raisonnable. Cet algorithme exige soit une clé alphabétique sur seize caractères, soit une clé hexadécimale sur 128 bits. Cette méthode de cryptage est la meilleure pour la plupart des éléments d'un bloc IP. Ainsi, la ligne de commande permettant de crypter un élément d'IP « memory.v, » doit être (si l'on utilise le cryptage AES avec clé alphabétique, MY_AES_SAMPLEKEY et si l'on stocke le résultat dans le fichier « memory_ip.v ») : protectip - in memory.v - out memory_ip. v - c aes128-cbc - k MY_AES_SAMPLEKEY - om persistent_key - v II. - Vers une normalisation du cryptage hybride La proposition de méthodologie de cryptage faite par Synplicity en juillet dernier a reçu depuis un accueil favorable de la part de la communauté des développeurs de circuits intégrés. La société a donc décidé de porter le projet auprès d'un organisme de normalisation et a choisi pour ce travail l'alliance VSI (VSIA, VSI Alliance). Focalisé sur les problèmes de qualité et de protection des IP, l'organisme, où se côtoient fabricants de circuits, fournisseurs de logiciels de CAO et vendeurs de blocs IP, a créé un groupe de travail concernant le cryptage des IP, suite à la donation de Synplicity. Une normalisation en bonne et due forme devrait intervenir dans le courant de l'année 2007. Une fois cette tâche achevée, les futurs travaux porteront sur la définition de points d'observabilité (view-ports) ou points de test, qui permettront d'accéder de manière sélective à certains objets seulement du bloc IP crypté.

Un cryptage adapté améliore les flots de conception à base de blocs IP

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

Un cryptage adapté améliore les flots de conception à base de blocs IP

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