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 coeur 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 coeurs 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.

Jusqu'à récemment, une méthodologie de cryptage de blocs IP interopérable et accessible aisément aux concepteurs n'était pas disponible pour des raisons technologiques. Mais de récentes avancées, à la fois sur les méthodes de cryptage elle-même et sur la standardisation des langages de la CAO, ont permis de lever ces hypothèques. Le modèle proposé par Synplicity est à la confluence de toutes ces évolutions. Il s'appuie tout d'abord sur deux méthodes cryptographiques couramment utilisées, les cryptages symétriques et asymétriques.

Les algorithmes symétriques utilisent un nombre secret, appelé « clé » , qui permet au destinataire de décrypter un élément de l'IP afin de le manipuler. Cette même clé autorise le cryptage et le décryptage du code. Cette méthode a l'avantage, d'une part, d'être peu onéreuse, d'autre part, d'être rapide. Un fichier classique de quelques gigaoctets est ainsi décrypté en quelques secondes et lorsque cette technologie est intégrée, par exemple au sein d'un outil de synthèse logique, le temps de calcul alloué aux opérations de cryptage/décryptage est transparent pour le concepteur. Néanmoins, la sécurité demeure un problème car l'utilisateur doit impérativement avoir accès à la clé, et la plupart des fournisseurs de blocs IP ne sont pas prêts à prendre le risque qu'une clé soit compromise ou dévoilée par l'un de leurs clients.

Pour pallier cet obstacle et limiter ce risque, les éditeurs d'IP ont pris l'habitude de créer une clé unique par version de bloc IP, par éditeur d'outil de CAO et, dans le cas des FPGA, par fournisseur de circuits. Mais une telle approche devient rapidement ingérable, car il faut tenir compte à la fois des évolutions et des différentes versions du bloc IP mais aussi des diverses moutures des outils de CAO. D'où une inflation exponentielle du nombre de clés à gérer dans le temps, sans compter les problèmes de mises à jour desdites clés en fonction des évolutions non synchrones des blocs IP et des logiciels de CAO. De plus, bien que cette multiplication des clés circonscrive les problèmes de sécurité, cette solution ne les éradique pas pour autant.

Les algorithmes asymétriques, de leur côté, utilisent deux clés différentes. Mise au point à la fin des années quatre-vingt, cette technologie de cryptage utilise deux clés distinctes : une clé dite « publique » , distribuée à tous et utilisée uniquement pour le cryptage, et une clé dite « privée » pour le décryptage. Ces deux clés sont liées l'une à l'autre par le fait que la clé publique est le produit de deux nombres premiers très grands, la clé privée étant l'un des deux. Le protocole RSA est le plus connu des méthodes de cryptage asymétrique.

Avec cette approche, pour crypter un bloc IP de manière asymétrique, un éditeur d'outil de CAO crée des clés publiques et privées, fournit une clé publique à différents fournisseurs de blocs IP afin de les autoriser à crypter leur code, puis crypte et enfouit la clé privée dans ses outils de manière à ce qu'ils puissent décrypter les blocs IP entrants. Avantage, non seulement ces algorithmes sont plus difficiles à « casser » que les chiffrements symétriques mais ils éliminent aussi les risques de fuite, dans la mesure où la clé de décryptage n'est pas distribuée aux utilisateurs finaux.

Toutefois, le cryptage asymétrique présente lui aussi plusieurs inconvénients. Tout d'abord, le fournisseur de blocs IP doit créer des versions cryptées de ses blocs pour chaque éditeur d'outil de CAO, ce qui est une source de complications assez semblables à celles qui résultent de la méthode symétrique à clés multiples. Ensuite, le décryptage d'un gros bloc IP à l'aide d'algorithmes asymétriques s'avère très consommateur en temps de calcul : il peut prendre plusieurs heures.

La solution à ces difficultés, proposée par Synplicity, consiste à tirer parti du meilleur des deux méthodes. Dans cette approche, dite de cryptage hybride, le fournisseur de blocs IP génère d'abord une clé symétrique pour crypter son code. Une opération, comme on l'a vu, qui a l'avantage de la rapidité. A cette étape, le vendeur de blocs IP utilise la variante qu'il souhaite pour ce cryptage symétrique (encadré I). Ensuite, il crypte cette clé symétrique à l'aide d'un algorithme asymétrique et d'une clé publique fournie par l'éditeur de logiciel de CAO. Ce processus est reproduit pour chacun des éditeurs avec lequel il est en relation. Ici, la clé ne présentant pas un volume de données important, le processus de cryptage asymétrique est rapide, même avec un nombre élevé d'éditeurs d'outils de CAO. Ce travail réalisé, le fournisseur de blocs IP combine alors les blocs de données cryptés en symétrique et les clés des éditeurs de CAO cryptées en asymétrique en un seul fichier qu'il transmet à chacun de ses clients. Les outils de CAO électronique compatibles avec cette méthodologie peuvent alors « lire » les données enfouies dans les blocs IP et les exploiter sans difficulté au sein d'un flot de conception (figure 2).

Avec cette approche, le logiciel de CAO de l'utilisateur (outil de synthèse logique par exemple), dûment équipé de la clé privée du fournisseur, décrypte par la méthode symétrique à la fois les clés et le bloc IP lui-même. Ensuite, l'outil intègre ce bloc avec les éléments non cryptés de la conception, réalise son travail (ici une synthèse logique) puis crypte les parties propriétaires du résultat à l'aide des mêmes clés. Ainsi, chaque outil de CAO utilise sa propre clé privée pour accéder à la clé symétrique unique du fournisseur de blocs IP et toutes les opérations de décryptage, de manipulation de données et de cryptage se font à l'intérieur des applications de CAO électronique. Ce procédé se répète pour chaque bloc IP dans la conception. En final, l'outil de placement-routage du fournisseur de FPGA reçoit un fichier crypté, respectant ainsi la sécurité des blocs de propriété intellectuelle (figure 3). Conséquence, les blocs IP non cryptés ne sont pas accessibles à l'utilisateur final, et les fichiers sont décryptés uniquement en mémoire et ne sont jamais stockés sur un disque. Au-delà des évolutions technologiques des techniques de cryptage, les nouveaux mécanismes d'intégration d'algorithmes de cryptage au coeur des fichiers RTL qui apparaissent actuellement dans les langages de conception standard, sont l'autre élément clé de la méthode qui autorise cette nouvelle manière d'aborder un traitement sécurisé des blocs IP. En effet, le standard IEEE 1364-2005, récemment publié pour Verilog (suite à une donation de Cadence), et le prochain standard VHDL 2006 sont tous deux compatibles avec un système de cryptage hybride.

De son côté Synplicity a proposé d'étendre ces avancées en proposant des syntaxes spécifiques pour la prise en compte du format Edif ; l'idée à terme étant d'utiliser ces pragmas au niveau des fichiers de contraintes écrits en Ascii. Ces caractéristiques offrent désormais au fournisseur d'IP la possibilité de spécifier le type d'algorithme de cryptage utilisé, ainsi qu'une plus grande flexibilité au niveau du décryptage. Celui-ci peut être partiel ou se dérouler uniquement au cours de certains stades du processus de conception exigeant une plus grande visibilité, comme par exemple la vérification ou le débogage. A condition toutefois, pour cette dernière possibilité, que le bloc IP soit décrit de manière hiérarchique, avec un coeur toujours crypté et des fonctions d'interfaçage cryptables et/ou décryptables à volonté.

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 coeur 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.