FR 3038420 A1 20170106 FR 1556156 A 20150630 1 DOMAINE TECHNIQUE AUQUEL SE RAPPORTE L'INVENTION La présente invention concerne le traitement cryptographique des données. Elle concerne plus particulièrement un dispositif et un procédé de traitement cryptographique de données. L'invention s'applique particulièrement avantageusement dans le cas où l'on souhaite effectuer ce traitement cryptographique en utilisant un processeur graphique. ARRIERE-PLAN TECHNOLOGIQUE Il est connu d'utiliser un processeur graphique (ou GPU de l'anglais "graphical processing unit" signifiant unité de traitement graphique) pour effectuer des traitements cryptographiques des données, tels que ceux mis en oeuvre au cours d'algorithmes cryptographiques de chiffrement, de déchiffrement, de signature ou de vérification de signature. On peut se référer par exemple à ce sujet à l'article "GPU Accelerated Cryptography as an OS Service", de O. Harrison et J. VValdron in LNCS Journal Transactions on Computational Science XI, Issue 11, octobre 2010, pp. 104-131. OBJET DE L'INVENTION Dans ce contexte, la présente invention propose un dispositif de traitement cryptographique de données comprenant un processeur graphique, caractérisé en ce qu'il comprend un élément sécurisé mémorisant des instructions exécutables par le processeur graphique et conçues pour mettre en oeuvre au moins une fonction lorsqu'elles sont exécutées par le processeur graphique. Les instructions sont ainsi mémorisées de manière sécurisée dans l'élément sécurisé et peuvent être chargées dans le processeur graphique lorsqu'elles doivent être exécutées en vue de réaliser le traitement cryptographique de données souhaitées. Les instructions ont par exemple la forme d'un script utilisable en tant 30 que noyau dans le processeur graphique, comme c'est le cas dans les exemples de réalisation donnés plus loin. Un tel processeur graphique est en effet conçu pour mettre en oeuvre une pluralité (en général un grand nombre) d'algorithmes (par exemple de calcul) en parallèle. Autrement dit, le processeur graphique est généralement conçu pour 3038420 2 effectuer des calculs vectoriels. Dans ce cadre, le processeur graphique peut éventuellement fonctionner selon un modèle de type SIMD (pour "Single Instruction Multiple Data"), dans lequel une pluralité d'ensembles de données sont traités en parallèle conformément à un unique jeu d'instructions. 5 Pour ce faire, les processeurs graphiques comprennent en général un nombre important d'unité de calcul ou coeurs, par exemple au moins 100 unités de calcul (c'est-à-dire 100 coeurs). Selon d'autres caractéristiques optionnelles, et donc non limitatives : - l'élément sécurisé comprend des moyens de lecture des instructions 10 exécutables dans une mémoire de l'élément sécurisé et des moyens de transmission des instructions exécutables lues à destination du processeur graphique, si bien que les instructions peuvent être transmises directement de l'élément sécurisé au processeur graphique ; - le dispositif comprend une unité centrale conçue pour fonctionner dans 15 un mode sécurisé et pour recevoir, lors de son fonctionnement dans le mode sécurisé, les instructions exécutables en provenance de l'élément sécurisé et pour transmettre ces instructions exécutables à destination du processeur graphique, si bien que les instructions peuvent être transmises de l'élément sécurisé au processeur graphique par l'intermédiaire de l'unité centrale ; 20 - l'élément sécurisé et le processeur graphique sont conçus de manière à communiquer (entre eux) uniquement lors du fonctionnement dans le mode sécurisé ; - les instructions exécutables transmises sont signées au moyen d'une clé cryptographique (par exemple une clé privée) de l'élément sécurisé, une telle 25 signature pouvant être vérifiée par l'unité centrale précité ou par le processeur graphique avant exécution des instructions ; - la fonction est une fonction cryptographique, par exemple une fonction de génération de clé RSA ; - la fonction est une fonction graphique ; - le dispositif de traitement cryptographique est conçu pour fonctionner sélectivement dans un environnement d'exécution polyvalent et dans un environnement d'exécution de confiance ; - le processeur graphique est conçu pour traiter en parallèle une pluralité d'ensembles de données selon un unique jeu d'instructions ; 3038420 3 - le processeur graphique est conçu pour effectuer des opérations mathématiques vectorielles ; - le processeur graphique est conçu pour fonctionner selon une structure de type grille. 5 Le processeur graphique et l'unité centrale sont par exemple intégrés au sein d'une même structure, comme dans le cas d'un processeur graphique intégré ou IGP (pour "Integrated Graphics Processor"). L'invention propose également un terminal de communication mobile comprenant un tel dispositif de traitement cryptographique. 10 L'invention propose enfin un procédé de traitement cryptographique de données mis en oeuvre dans un dispositif comprenant un processeur graphique, caractérisé en ce qu'il comprend les étapes suivantes : - chargement dans le processeur graphique d'instructions mémorisées dans un élément sécurisé ; 15 - mise en oeuvre d'au moins une fonction du fait de l'exécution desdites instructions par le processeur graphique. Selon des caractéristiques optionnelles, et donc non limitatives : - le chargement des instructions dans le processeur graphique est effectué en provenance de l'élément sécurisé ; 20 - le dispositif comprend une unité centrale conçue pour fonctionner dans un mode sécurisé et pour recevoir, lors de son fonctionnement dans le mode sécurisé, les instructions en provenance de l'élément sécurisé ; - le chargement des instructions dans le processeur graphique est effectué en provenance de l'unité centrale ; 25 - lorsque la fonction est une fonction cryptographique, le processeur graphique exécute, parallèlement à l'exécution desdites instructions, d'autres instructions mettant en oeuvre un algorithme de traitement graphique ou géométrique ; - lorsque la fonction est une fonction cryptographique, le processeur 30 graphique met en oeuvre une fonction graphique utilisant au moins un résultat de la fonction cryptographique ; - la fonction est une fonction graphique ; - le dispositif est conçu pour fonctionner sélectivement dans un environnement d'exécution polyvalent et dans un environnement d'exécution de 3038420 4 confiance ; - la mise en oeuvre de ladite fonction est commandée lors du fonctionnement dans l'environnement d'exécution de confiance ; - le procédé comprend, préalablement à l'étape de chargement, une 5 étape de basculement du dispositif vers le fonctionnement dans l'environnement d'exécution de confiance ; - les instructions chargées dans le processeur graphique sont signées au moyen d'une clé cryptographique de l'élément sécurisé. DESCRIPTION DETAILLEE D'UN EXEMPLE DE REALISATION 10 La description qui va suivre en regard des dessins annexés, donnés à titre d'exemples non limitatifs, fera bien comprendre en quoi consiste l'invention et comment elle peut être réalisée. Sur les dessins annexés : - la figure 1 représente les éléments principaux d'un dispositif de 15 traitement de données conforme à l'invention ; - la figure 2 représente schématiquement l'utilisation de deux environnements d'exécution au sein du dispositif de traitement de données de la figure 1 ; - la figure 3 représente, sous forme de logigramme, un premier exemple 20 de procédé de traitement de données conforme à l'invention ; - la figure 4 représente, sous forme de logigramme, un second exemple de procédé de traitement de données conforme à l'invention ; - la figure 5 représente, sous forme de logigramme, un troisième exemple de procédé de traitement de données conforme à l'invention ; et 25 - la figure 6 présente, sous forme de logigramme, un exemple d'exécution d'un algorithme cryptographique au sein d'une unité de traitement graphique. La figure 1 représente les éléments principaux d'un dispositif de traitement de données conforme à l'invention. 30 Ce dispositif de traitement de données est par exemple un appareil électronique tel qu'un terminal (par exemple de type téléphone intelligent ou "smartphone" selon la dénomination anglo-saxonne). En variante, il pourrait s'agir par exemple d'un ordinateur personnel ou d'un décodeur vidéo (parfois dénommé par l'appellation anglo-saxonne "set-top box"). 3038420 5 Dans l'exemple décrit ici, le dispositif de traitement de données comprend un premier module de traitement 10 (ou "hôte") intégrant une unité centrale 2 (ou CPU pour "Central Processing Unit") et un élément sécurisé 4, un second module de traitement 20 formant unité de traitement graphique et une 5 interface utilisateur, ici un écran tactile 30. L'unité de traitement graphique 20, l'unité centrale 2 et l'élément sécurisé 4 pourraient en variante être regroupés au sein d'un même module. L'unité centrale 2 est réalisée sous la forme d'un processeur, par exemple un microprocesseur, apte à mettre en oeuvre les procédés décrits ci- 10 dessous du fait de l'exécution d'instructions (en particulier des instructions d'une application APP) mémorisées au sein du dispositif de traitement de données, par exemple dans une mémoire vive 6 ou une mémoire non-volatile (non représentée), éventuellement réinscriptible. L'élément sécurisé 4 est ici un élément sécurisé intégré (ou eSE pour 15 "embedded Secure Element"), soudé au sein du premier module 10. En variante, il pourrait s'agir d'un autre type d'élément sécurisé, par exemple une carte à microcircuit (telle qu'une carte à circuit intégré universelle, ou UICC pour "Universal Integrated Circuit Card', telle que définie dans la norme ETSI TS 102 221 et qui regroupe les cartes à microcircuit de type carte SIM (pour 20 "Subscriber Identity Module") ou (USIM pour "Universal Subscriber Identity Module"), mais également des jetons (ou "tokens") sécurisés, tous identifiables de manière unique). Dans ce dernier cas, le dispositif de traitement de données inclut un lecteur de cartes lié à l'unité centrale 2 et conçu pour recevoir la carte à microcircuit afin de permettre un échange de données entre l'unité centrale 2 et la 25 carte à microcircuit. L'élément sécurisé 4 est conçu pour recevoir des commandes de type APDU (pour "Application Protocol Data Unit"). L'élément sécurisé 4 comprend par exemple un microprocesseur, une mémoire non-volatile réinscriptible et une mémoire vive. L'élément sécurisé 4 est 30 conçu, du fait de sa construction physique et de la conception des programmes d'ordinateur qu'elle mémorise, de façon à rendre très difficile, voire impossible, pour un attaquant l'accès (par lecture et/ou modification) aux données confidentielles qu'elle mémorise. Ainsi, l'élément sécurisé 4 a par exemple un niveau d'assurance EAL supérieur à 4 au sens des Critères Communs (norme 3038420 6 IS015408), par exemple un niveau EAL4+ (VAN5) ou supérieur, et/ou un niveau supérieur à 3 selon la norme FIPS 140-2 (pour "Federal Information Processing Standard'). L'élément sécurisé 4 mémorise (par exemple au sein de sa mémoire 5 non-volatile réinscriptible) des scripts (ou jeux d'instructions) exécutables par l'unité de traitement graphique 20, dont l'utilisation sera décrite pus bas. Le premier module 10 comprend également une mémoire vive 6, un élément d'interfaçage 8 (réalisé par exemple sous la forme d'un circuit intégré dédié) et un circuit de communication 9. 10 Comme schématiquement représenté en figure 1, l'unité centrale 2, l'élément sécurisé 4 et la mémoire vive 6 sont chacun connectés à l'élément d'interfaçage 8 afin d'échanger des données entre eux et avec une mémoire 22 (ici une mémoire vive) de l'unité de traitement graphique 20. Le circuit de communication 9 permet de recevoir des données en 15 provenance d'un dispositif électronique extérieur et d'émettre des données à destination d'un tel dispositif électronique extérieur. Le circuit de communication 9 est par exemple un circuit de connexion à un réseau local sans fil (auquel cas les échanges de données avec le dispositif extérieur ont lieu via ce réseau local sans fil). En variante, le circuit de 20 communication 9 peut être un circuit de connexion à un réseau filaire (auquel cas les échanges de données avec le dispositif extérieur ont lieu via ce réseau filaire). Selon une autre variante, le circuit de communication 9 est un circuit de communication radio avec une station de base d'un réseau de téléphonie mobile (auquel cas les échanges de données avec le dispositif extérieur ont lieu via ce 25 réseau de téléphonie mobile). Le premier module 10 est par exemple réalisé sous la forme d'un système sur puce (ou SoC pour "System on Chip"). Comme déjà indiqué, l'unité de traitement graphique 20 comprend une mémoire vive 22 reliée au premier module 10 via l'élément d'interfaçage 8. 30 Afin de permettre un traitement en parallèle des données, l'unité de traitement graphique 20 a une structure de type grille 24 regroupant une pluralité de blocs 26. Chaque bloc 26 comprend des registres propres 25 et une mémoire à accès rapide 27 accessible par les différents fils d'exécution 28 (ou "threads" selon l'appellation anglo-saxonne) associés à ce bloc 26. 3038420 7 Lors de leur traitement par l'unité de traitement graphique 20, des données mémorisées dans la mémoire vive 22 sont transférées dans une mémoire à accès rapide 27 d'un bloc 26, où elles sont manipulées par les fils d'exécution 28 du bloc 26 concerné avant d'être copiées en tant que données 5 traitées dans la mémoire vive 22. L'écran tactile 30 comprend un écran 32 (ou afficheur) et un capteur 34 de la position d'un doigt ou d'un stylet sur l'écran 32. Grâce à une interface (représentée schématiquement par une flèche en figure 1) entre l'écran tactile 30 et l'unité de traitement graphique 20, l'écran 32 10 affiche une image telle que définie dans un tampon graphique (ou "frame buffet." selon l'appellation anglo-saxonne) mémorisé dans la mémoire vive 22 de l'unité de traitement graphique 20. Les informations détectées par le capteur 34, telles que des informations de position d'un (ou plusieurs) doigt(s) sur l'écran 32, sont quant à elles 15 transmises à l'unité centrale 2. La figure 2 représente schématiquement l'utilisation de deux environnements d'exécution au sein du dispositif de traitement de données, et en particulier au sein du premier module 10. Pour ce faire, deux systèmes d'exploitation distincts peuvent être 20 exécutés par l'unité centrale 2 : un système d'exploitation polyvalent 0S1 (ou "Rich OS" selon l'appellation anglo-saxonne) et un système d'exploitation de confiance 0S2 (ou "Trusted OS"), parfois dénommé système d'exploitation sécurisé ("Secure OS"). On remarque que le basculement d'un système d'exploitation à l'autre peut affecter l'unité de traitement graphique 20, en 25 particulier lorsque l'unité de traitement graphique 20 est un processeur graphique intégré à l'unité centrale 2. Le système d'exploitation polyvalent 0S1 permet le téléchargement, l'installation et l'exécution d'applications avec une grande liberté pour l'utilisateur. La mise en oeuvre du système d'exploitation polyvalent 0S1 crée ainsi un 30 environnement polyvalent ou REE (pour "Rich Execution Environment"). Au contraire, dans le cadre du fonctionnement du premier module 10 sur la base du système d'exploitation de confiance 0S2, les possibilités de téléchargement et d'installation d'applications sont limitées (par exemple à des applications ayant reçu une certification particulière) de sorte que l'utilisation du 3038420 8 système d'exploitation de confiance permet de créer au sein du premier module 10 un environnement d'exécution de confiance ou TEE (pour "Trusted Execution Environment"), ou encore environnement d'exécution sécurisé. Cet environnement d'exécution de confiance offre par exemple un niveau 5 de sécurité conforme aux critères communs EAL (pour "Evaluation Assurance Level"), correspondant à la norme ISO 15408, avec un niveau compris entre 2 et 7, ou à la norme FIPS (pour "Federal Information Processing Standard') 140-2. Le premier module 10 utilise également un moniteur de sécurité SM (ou "Secure Monitor" selon l'appellation anglo-saxonne), qui peut être exécuté par 10 l'unité centrale 2. Le moniteur de sécurité SM commande le basculement entre le fonctionnement du premier module 10 sur la base du système d'exploitation polyvalent 0S1 et le fonctionnement du premier module 10 sur la base du système d'exploitation de confiance 052 (et vice versa), de sorte que le premier module 10 fonctionne à chaque instant sur la base d'un seul des deux systèmes 15 d'exploitation 0S1, 0S2 (c'est-à-dire dans un seul des deux environnements mentionnés ci-dessus). Le fonctionnement du moniteur de sécurité SM répond aux mêmes exigences de sécurité que le système d'exploitation de confiance 0S2 et on considère donc en général que le moniteur de sécurité SM fait partie de l'environnement d'exécution de confiance TEE, comme représenté en figure 2. 20 Selon un mode de réalisation envisageable, le système d'exploitation exécuté avant basculement (par exemple le système d'exploitation polyvalent 0S1) est mis en veille par le basculement et tout accès à des éléments externes au processeur (par exemple l'interface utilisateur 30) est alors inhibé pour le système d'exploitation en veille, de sorte que le système d'exploitation activé par 25 le basculement (ici le système d'exploitation de confiance 0S2) contrôle totalement l'élément externe, ici l'interface utilisateur 30. Le moniteur de sécurité 40 peut également permettre, lors du basculement, le passage d'informations du système d'exploitation exécuté avant basculement au système d'exploitation exécuté après basculement. 30 Dans l'exemple décrit ici, le système d'exploitation polyvalent 0S1 et le système d'exploitation de confiance 0S2 sont exécutés par l'unité centrale 2. On pourrait en variante utiliser un module comportant deux processeurs, le système d'exploitation polyvalent 0S1 étant exécuté sur l'un et le système d'exploitation de confiance 0S2 étant exécuté sur l'autre. 3038420 9 La figure 3 représente, sous forme de logigramme, un premier exemple de procédé de traitement de données conforme à l'invention. Ce procédé débute à l'étape E2 par la détection par le capteur 34 d'une action de l'utilisateur indicative du lancement d'une application APP à exécuter 5 dans l'environnement sécurisé. Une telle action est par exemple le toucher de l'écran tactile 30 au niveau d'une icône représentant cette application APP et affichée sur l'écran 32. Des informations représentatives de l'action de l'utilisateur (par exemple des informations de position POS du doigt de l'utilisateur sur l'écran tactile 30) 10 sont transmises par le capteur 34 à l'unité centrale 2, qui fonctionne à cet instant dans l'environnement d'exécution polyvalent REE. Ces informations sont reçues par l'unité centrale 2 à l'étape E4, qui détermine ainsi que l'application APP susmentionnée doit être exécutée et initie donc tout d'abord à l'étape E6 le basculement du fonctionnement dans 15 l'environnement d'exécution de confiance TEE en faisant appel au moniteur de sécurité SM et en lui transmettant un identifiant lApp de l'application APP dont l'exécution est demandée par l'utilisateur. Le moniteur de sécurité SM provoque donc à l'étape E8 le basculement du fonctionnement du premier module 10 de l'environnement d'exécution 20 polyvalent REE à l'environnement de confiance TEE, et rend la main au système d'exploitation de confiance 0S2, tout en lui transmettant l'identifiant 'APP. Dans l'exemple décrit ici, ce basculement en mode sécurisé s'applique également à l'unité de traitement graphique 20. On prévoit ainsi que, lors du fonctionnement dans l'environnement d'exécution de confiance TEE, seules des 25 entités sécurisées (par exemple des applications exécutées dans l'environnement de confiance TEE ou dans l'élément sécurisé 4) puissent interagir avec l'unité de traitement graphique 20. On peut prévoir par ailleurs que l'élément sécurisé 4 et l'unité de traitement graphique 20 ne puissent communiquer que lors du fonctionnement 30 dans l'environnement d'exécution de confiance TEE. Le système d'exploitation de confiance 0S2 reprend donc son exécution à l'étape El 0 en commandant l'affichage sur l'écran 32 d'une information signalant à l'utilisateur le passage dans l'environnement d'exécution de confiance TEE (étape E12). En variante, cette information pourrait être signalée à l'utilisateur 3038420 10 d'une autre manière, par exemple au moyen d'une vibration du dispositif. Le fonctionnement se poursuit alors dans le cadre de l'environnement d'exécution de confiance TEE par l'exécution de l'application APP lancée par l'utilisateur à l'étape E2 et identifiée par l'identifiant lApp reçu par le système 5 d'exploitation de confiance 0S2 à l'étape E10. L'exécution de cette application APP provoque tout d'abord à l'étape E14 l'émission, à destination de l'unité de traitement graphique 20, d'une requête REQ d'allocation d'un espace mémoire dans la mémoire vive 22 de l'unité de traitement graphique 20. Cet espace mémoire est destiné à recevoir les scripts mémorisés 10 dans l'élément sécurisé 4 comme expliqué plus bas. En variante, comme indiqué plus bas, cette requête peut être envoyée lors l'étape E18 décrite ci-dessous ; la requête peut également être envoyée par l'élément sécurisé 4, par exemple lors de l'étape E20 décrite ci-dessous. L'unité de traitement graphique 20 alloue l'espace mémoire demandé 15 dans sa mémoire vive 22 à l'étape E16. L'application APP exécutée dans l'environnement d'exécution de confiance TEE envoie alors à l'élément sécurisé 4 une liste L des scripts qu'elle est susceptible d'utiliser (étape E18). Comme cela sera expliqué plus en détail ci-après, chacun de ces scripts permet, lorsqu'il est mis en oeuvre dans l'unité de 20 traitement graphique 20, d'appliquer une fonction cryptographique à des données préalablement transmises à l'unité de traitement graphique 20. Un exemple de mise en oeuvre d'une telle fonction cryptographique par l'unité de traitement graphique 20 est donné ci-dessous en référence à la figure 6. L'élément sécurisé 4 reçoit la liste L à l'étape E20 et transmet en 25 conséquence à l'étape E22 les scripts SCR identifiés dans la liste L à destination de l'unité de traitement graphique 20. Précisément, le microprocesseur de l'élément sécurisé 4 reçoit la liste L et commande la lecture, dans la mémoire non-volatile de l'élément sécurisé 4, des scripts SCR identifiés dans la liste L; le microprocesseur de l'élément sécurisé 4 commande ensuite l'envoi des scripts lus 30 SCR à destination de l'unité de traitement graphique 20 (via l'élément d'interfaçage 8) pour mémorisation dans la mémoire vive 22. Selon une variante envisageable, avant envoi des scripts SCR à l'étape E22, l'élément sécurisé 4 pourrait demander à l'unité de traitement graphique 20 l'allocation d'un espace mémoire pour ces scripts SCR (auquel cas l'étape E14 3038420 11 décrite plus haut n'est pas mise en oeuvre). Dans ce cas, l'élément sécurisé 4 transmet par exemple à l'unité centrale 2 des informations sur la localisation de l'espace mémoire alloué afin que l'unité centrale 2 puisse ultérieurement faire appel aux scripts SCR, comme décrit plus bas en référence à l'étape E34. 5 On pourrait prévoir par ailleurs que l'application exécutée dans l'environnement d'exécution de confiance TEE n'utilise qu'un script. Dans ce cas, l'étape E18 consiste en une demande de chargement de ce script dans l'unité de traitement graphique 20; à réception de cette demande, l'élément sécurisé 4 transfère le script (mémorisé dans sa mémoire non-volatile réinscriptible) à l'unité 10 de traitement graphique 20, qui mémorise le script en tant que noyau (ou "kerne' selon l'appellation anglo-saxonne) en vue de sa future exécution. On prévoit ici que les scripts SCR soient mémorisés dans l'élément sécurisé 4 signés au moyen d'une clé privée associée à l'élément sécurisé 4. Les scripts SCR sont donc transmis signés (c'est-à-dire associés à une signature SIG) 15 à l'unité de traitement graphique 20. En variante, les scripts pourraient être mémorisés non-signés puis signés au sein de l'élément sécurisé 4 (par application d'un algorithme de signature utilisant la clé privée de l'élément sécurisé 4) avant envoi à l'unité de traitement graphique 20. L'unité de traitement graphique 20 reçoit les scripts SCR signés (c'est-à- 20 dire avec leur signature SIG) à l'étape E24 et procède à l'étape E26 à la vérification de la signature SIG au moyen d'un algorithme de vérification de signature utilisant la clé publique associée à la clé privée de l'élément sécurisé 4 dans une infrastructure à clé publique (ou PKI pour "Public Key Infrastructure"). Cette clé publique a par exemple été transmise au préalable de l'élément sécurisé 25 4 à l'unité de traitement graphique 20, éventuellement après vérification auprès d'une autorité de confiance que cette clé publique était bien associée à l'élément sécurisé 4. On remarque que la clé publique et les scripts pourraient éventuellement être mis à jour en ligne (par exemple selon une méthode d'OTA, acronyme anglo-saxon signifiant "Over The Air"). 30 Si l'unité de traitement graphique 20 ne vérifie pas correctement la signature, on procède à une étape E28 de traitement d'erreur. En effet, la provenance des scripts n'est pas garantie dans ce cas et l'unité de traitement graphique 20 ne procèdera donc pas à leur exécution. Ce traitement d'erreur inclut par exemple l'envoi (non représenté) d'un message d'erreur à l'unité centrale 2, 3038420 12 l'arrêt de l'application APP et le basculement du fonctionnement du premier module 10 de l'environnement d'exécution de confiance TEE à l'environnement d'exécution polyvalent REE. Si au contraire l'unité de traitement graphique 20 effectue correctement 5 la vérification de la signature des scripts signés SCR (ce qui permet notamment de garantir l'intégrité des scripts SCR), l'exécution des ces scripts SCR est autorisée et l'unité de traitement graphique attend donc une commande d'exécution (voir ci-dessous la description de l'étape E36). Suite à l'émission de la liste L à l'étape E18, l'application APP exécutée 10 dans l'environnement de confiance TEE poursuit son fonctionnement à l'étape E30, qui implique notamment des interactions avec l'utilisateur au moyen de l'écran tactile 30 (étape E32). La mise en oeuvre de l'application APP implique éventuellement en outre des échanges de données avec des dispositifs électroniques extérieurs (par exemple un serveur connecté sur un réseau public) 15 via le circuit de communication 9 (qui permet comme indiqué ci-dessus d'accès au réseau public précité). La poursuite de l'exécution de l'application APP dans l'environnement d'exécution de confiance TEE nécessite alors la mise en oeuvre d'une opération cryptographique, par exemple de signature, de chiffrement ou de déchiffrement de 20 certaines données (par exemple des données reçues via le circuit de communication 9 ou des données à émettre via le circuit de communication 9) ou de génération de clés, comme présenté plus bas en référence à la figure 6. Pour effectuer cette opération cryptographique, l'unité centrale 2 envoie à l'unité de traitement graphique 20 les données à traiter D et l'identifiant IscR du 25 script à exécuter (qui correspond à l'opération cryptographique à effectuer). Au cours de l'étape E36, l'unité de traitement graphique 20 reçoit ainsi les données à traiter D et les mémorise dans la mémoire vive 22, dans une zone dédiée aux données à manipuler par l'unité de traitement graphique 20; par ailleurs, l'unité de traitement graphique 20 reçoit l'identifiant lscR du script à 30 exécuter et initie l'exécution de ce script (qui a été mémorisé dans la mémoire vive 22 à l'étape E24) en tant que noyau. Le script identifié par l'identifiant lscR reçu à l'étape E36 s'exécute au cours de l'étape E38, ce qui permet d'appliquer l'opération cryptographique précitée (par exemple de signature, de chiffrement ou de déchiffrement) aux 3038420 13 données D. Grâce à l'utilisation de l'architecture parallèle de l'unité de traitement graphique 20 (comme rappelé ci-dessus), le temps d'exécution de l'étape E38 est réduit. On pourra se référer à ce sujet à l'article "GPU Accelerated Cryptography 5 as an OS Service", de O. Harrison et J. Waldron in LNCS Journal Transactions on Computational Science XI, Issue 11, octobre 2010, pp. 104-131. Une fois le script totalement exécuté, l'unité de traitement graphique envoie à l'étape E40 le résultat D' de l'opération cryptographique (c'est-à-dire les données obtenues du fait de l'application de l'opération cryptographique) à l'unité 10 centrale 2 (sur laquelle s'exécute toujours, dans le cadre de l'environnement d'exécution de confiance TEE, l'application APP mentionnée plus haut). L'application APP exécutée sur l'unité centrale 2 reçoit ce résultat D' à l'étape E42 et poursuit son fonctionnement, en utilisant par exemple ce résultat. Selon un mode de réalisation, l'opération cryptographique mise en oeuvre pourrait 15 être une opération de déchiffrement et l'application APP pourrait alors commander à l'étape E42 l'affichage du résultat D' (données déchiffrées) sur l'écran 32. Selon un autre mode de réalisation, l'opération cryptographique pourrait être une opération de chiffrement et l'application APP pourrait alors commander à l'étape E42 l'émission du résultat D' (données chiffrées) à destination d'un dispositif 20 électronique extérieur via le circuit de communication 9. La figure 4 représente, sous forme de logigramme, un second exemple de procédé de traitement de données conforme à l'invention. Ce procédé débute de manière identique à celui qui vient d'être décrit en référence à la figure 3 et les étapes E2 à E16 ne seront donc pas décrites à 25 nouveau. De même, comme dans le procédé de la figure 3, lors de l'étape E18 l'application APP exécutée dans l'environnement d'exécution de confiance TEE envoie à l'élément sécurisé 4 une liste L des scripts qu'elle est susceptible d'utiliser (étape E18). L'élément sécurisé 4 reçoit la liste L à l'étape E20 et 30 transmet en conséquence à l'étape E50 les scripts signés SCR, SIG identifiés dans la liste L, cette fois à destination de l'unité centrale 2. Précisément, le microprocesseur de l'élément sécurisé 4 reçoit la liste L et commande la lecture, dans la mémoire non-volatile de l'élément sécurisé 4, des scripts SCR identifiés dans la liste L; le microprocesseur de l'élément sécurisé 4 3038420 14 commande ensuite l'envoi des scripts lus SCR à destination de l'unité centrale 2 (via l'élément d'interfaçage 8). L'application APP exécutée par l'unité centrale 2 dans l'environnement d'exécution de confiance TEE reçoit les scripts SCR et leur signature SIG à l'étape 5 E52 et procède à l'étape E54 à la vérification de la signature SIG, au moyen d'un algorithme cryptographique de vérification de signature utilisant la clé publique associée à la clé privée de l'élément sécurisé 4. Cette clé publique peut avoir été reçue au préalable de l'élément sécurisé 4, ou, en variante, d'une autorité de confiance extérieure (via le circuit de communication 9), par exemple au sein d'un 10 certificat qui contient également la signature de cette clé publique par l'autorité de confiance (cette signature pouvant être vérifiée par l'application APP exécutée par l'unité centrale 2). Si l'application APP ne vérifie pas correctement la signature SIG des scripts SCR, elle procède à un traitement d'erreur, en commandant par exemple 15 l'affichage d'un message d'erreur sur l'écran 32 (étape E56), en mettant fin à son exécution sans effectuer l'opération cryptographique mentionnée plus bas et en basculant éventuellement en outre du fonctionnement dans l'environnement d'exécution de confiance TEE au fonctionnement dans l'environnement d'exécution polyvalent REE (en faisant appel pour ce faire au moniteur de sécurité 20 SM). Si l'application APP vérifie correctement la signature SIG des scripts SCR, elle poursuit son fonctionnement à l'étape E58. Selon un mode de réalisation envisageable, illustré par une flèche en pointillés en figure 4, l'application exécutée dans l'environnement d'exécution de 25 confiance TEE peut alors commander le chargement des scripts SCR dans la mémoire vive 22 de l'unité de traitement graphique 20 (via l'élément d'interfaçage 8). Quoiqu'il en soit, le fonctionnement normal de l'application APP se poursuit à l'étape E58, au cours de laquelle peuvent notamment avoir lieu des 30 échanges avec l'interface utilisateur (écran tactile 30) à l'étape E60. Comme indiqué dans le cadre de l'exemple de réalisation de la figure 3, l'étape E58 peut également comprendre des échanges de données avec des dispositifs électroniques extérieurs via le circuit de communication 9. A l'étape E62, l'application APP exécutée par l'unité centrale 2 dans le 3038420 15 cadre de l'environnement d'exécution de confiance TEE initie la mise en oeuvre d'une opération cryptographique en envoyant à l'unité de traitement graphique 20 les données à traiter D et le script SCR à exécuter (ou, dans le mode de réalisation où les scripts ont été préalablement transmis à l'unité de traitement 5 graphique 20, l'identifiant IscR du script à exécuter). Comme pour l'exemple de réalisation de la figure 3, cette opération cryptographique est par exemple une opération de signature, de chiffrement ou de déchiffrement de certaines données (par exemple des données reçues via le circuit de communication 9 ou des données à émettre via le circuit de communication 9). 10 Au cours de l'étape E64, l'unité de traitement graphique 20 reçoit ainsi les données à traiter D et les mémorise dans la mémoire vive 22, dans une zone dédiée aux données à manipuler par l'unité de traitement graphique 20. L'unité de traitement graphique 20 reçoit par ailleurs lors de cette étape E64 le script SCR à exécuter et mémorise ce script en tant que noyau, en vue de 15 son exécution ; dans le mode de réalisation où l'unité de traitement graphique 20 reçoit l'identifiant lscR du script à exécuter, elle utilise le script désigné par cet identifiant IscR en tant que noyau. Dans les deux cas, le script SCR peut ainsi s'exécuter au cours de l'étape E66, ce qui permet d'appliquer l'opération cryptographique précitée (par 20 exemple de signature, de chiffrement ou de déchiffrement) aux données D, avec un temps d'exécution réduit grâce à l'utilisation de l'architecteur parallèle de l'unité de traitement graphique 20. Une fois le script totalement exécuté, l'unité de traitement graphique 20 envoie à l'étape E68 le résultat D' de l'opération cryptographique (c'est-à-dire les 25 données obtenues du fait de l'application de l'opération cryptographique) à l'unité centrale 2 (sur laquelle s'exécute toujours l'application APP dans le cadre de l'environnement d'exécution de confiance TEE). L'application APP exécutée sur l'unité centrale 2 reçoit ce résultat D' à l'étape E70 et poursuit son fonctionnement, en utilisant par exemple ce résultat. 30 Selon un mode de réalisation, l'opération cryptographique mise en oeuvre pourrait être une opération de déchiffrement et l'application APP pourrait alors commander à l'étape E70 l'affichage du résultat D' (données déchiffrées) sur l'écran 32. Selon un autre mode de réalisation, l'opération cryptographique pourrait être une opération de chiffrement et l'application APP pourrait alors commander à l'étape 3038420 16 E70 l'émission du résultat D' (données chiffrées) à destination d'un dispositif électronique extérieur via le circuit de communication 9. La figure 5 représente, sous forme de logigramme, un troisième exemple de procédé de traitement de données conforme à l'invention. 5 Ce procédé débute par le chargement de scripts SCR dans l'unité de traitement graphique 20 conformément à ce qui a été présenté ci-dessus en référence à la figure 3 (étapes E2 à E26) ou à la figure 4 (étapes E14 à E54). Une fois les scripts SCR chargés dans la mémoire vive 22 de l'unité de traitement graphique 20, il est ici prévu que l'un des scripts soit exécuté (étape 10 E138) afin de générer sur l'écran 32 un affichage générique sécurisé (étape E140). Un tel affichage est par exemple une image ou des primitives géométriques, dont une partie dépend éventuellement du résultat d'une opération cryptographique telle que décrit ci-après (auquel cas l'opération cryptographique est exécutée en parallèle de l'étape E138, possibilité également évoquée plus 15 loin). L'application APP exécutée dans l'environnement de confiance TEE poursuit son fonctionnement normal à l'étape E142. Dans ce cadre sont par exemple prévues des interactions avec l'utilisateur au moyen de l'écran tactile 30 (étape E144). 20 Le fonctionnement de l'étape E142 implique éventuellement en outre des échanges de données avec des dispositifs électroniques extérieurs (par exemple un serveur connecté sur un réseau public) via le circuit de communication 9 (qui permet comme indiqué ci-dessus d'accès au réseau public précité). Enfin, le fonctionnement de l'étape E142 peut inclure l'affichage 25 d'éléments sur l'écran 32. Pour ce faire, l'application APP prépare des données G correspondant à l'affichage souhaité et envoie des requêtes d'affichage, comprenant un identifiant de script I'scR et les données préparées G, à destination de l'unité de traitement graphique 20. Ces requêtes d'affichage sont reçues par l'unité de traitement graphique 30 20 à l'étape E146. Le script identifié par l'identifiant l'scR est alors exécuté, ce qui entraîne le traitement des données G (étape E148) et l'affichage voulu sur l'écran 32 (étape E150). La poursuite de l'exécution de l'application APP nécessite alors la mise en oeuvre d'une opération cryptographique, par exemple de signature, de 3038420 17 chiffrement ou de déchiffrement de certaines données (par exemple des données reçues via le circuit de communication 9 ou des données à émettre via le circuit de communication 9). Pour effectuer cette opération cryptographique, l'unité centrale 2 envoie 5 à l'étape E152 les données à traiter D et l'identifiant lscR du script à exécuter (qui correspond à l'opération cryptographique à effectuer) à l'unité de traitement graphique 20. Au cours de l'étape E154, l'unité de traitement graphique 20 reçoit ainsi les données à traiter D et les mémorise dans la mémoire vive 22, dans une zone 10 dédiée aux données à manipuler par l'unité de traitement graphique 20; par ailleurs, l'unité de traitement graphique 20 reçoit l'identifiant lscR du script à exécuter et initie l'exécution de ce script (qui a été mémorisé dans la mémoire vive 22 à l'étape E24) en tant que noyau. Le script identifié par l'identifiant lscR reçu à l'étape E154 s'exécute au 15 cours de l'étape E156, ce qui permet d'appliquer l'opération cryptographique précitée (par exemple de signature, de chiffrement ou de déchiffrement) aux données D, avec un temps de traitement réduit grâce à l'utilisation de l'architecture de type grille de l'unité de traitement graphique 20. On remarque que les exécutions des différents scripts prévues aux 20 étapes E138 et/ou E148 décrites ci-dessus pourraient, selon une possibilité de réalisation, être réalisées en parallèle de l'étape E156, ce qui est envisageable grâce à l'architecture parallélisée de l'unité de traitement graphique 20. Une fois le script totalement exécuté, l'unité de traitement graphique 20 envoie à l'étape E158 le résultat D' de l'opération cryptographique (c'est-à-dire les 25 données obtenues du fait de l'application de l'opération cryptographique) à l'unité centrale 2 (sur laquelle s'exécute toujours, dans le cadre de l'environnement d'exécution de confiance TEE, l'application APP mentionnée plus haut). Dans le cas précité où les scripts des étapes E148 et E156 sont exécutés en parallèle, le résultat D' de l'opération cryptographique pourrait être 30 combiné à l'affichage réalisé à l'étape E150. L'application APP exécutée sur l'unité centrale 2 reçoit ce résultat D' à l'étape E160 et poursuit son fonctionnement, en utilisant par exemple ce résultat. Selon un mode de réalisation, l'opération cryptographique mise en oeuvre pourrait être une opération de déchiffrement et l'application APP pourrait 3038420 18 alors commander à l'étape E160 l'affichage du résultat D' (données déchiffrées) sur l'écran 32. Cet affichage pourrait être réalisé en pratique du fait de la mise en oeuvre par l'unité centrale 2 (fonctionnant dans le cadre de l'environnement d'exécution de confiance TEE) d'une requête d'affichage du même type que décrit 5 ci-dessus à l'étape E142. En variante, le résultat D' de l'opération cryptographique pourrait être directement utilisé au sein de l'unité de traitement graphique 20 (sans être transféré à l'unité centrale 2) par les scripts conduisant à l'affichage (étapes E148 et E150). Selon un autre mode de réalisation, l'opération cryptographique pourrait 10 être une opération de chiffrement et l'application APP pourrait alors commander à l'étape E160 l'émission du résultat D' (données chiffrées) à destination d'un dispositif électronique extérieur via le circuit de communication 9. On remarque que, bien qu'elles aient été représentées séquentiellement pour la clarté de l'exposé, certaines des tâches graphiques (étapes E146 et E148) 15 et certaines des tâches cryptographiques (étapes E156 et E158) peuvent être réalisées en parallèle grâce à l'architecture en grille de l'unité de traitement graphique 20 rappelée ci-dessus, comme cela a déjà été mentionné. La figure 6 présente, sous forme de logigramme, un exemple d'exécution d'un algorithme cryptographique au sein de l'unité de traitement graphique 20. 20 Cet algorithme est un algorithme de génération de clé cryptographique, ici une clé à utiliser pour la mise en oeuvre d'un algorithme cryptographique de type RSA. Le procédé représenté à la figure 6 débute à l'étape E200 à laquelle l'unité centrale 2 envoie, à destination de chacun des coeurs C1, C2, , Cn de 25 l'unité de traitement graphique 20, une instruction d'exécution d'un algorithme GEN de génération d'un nombre premier p, q utilisable avec un exposant e pour une clé de longueur I bits. Chacun des coeurs C1, C2, ..., Cn met alors en oeuvre un traitement (ici cryptographique) T1, T2, ... , Tr, permettant de rechercher un nombre premier 30 convenable, par exemple conformément à ce qui est décrit dans la norme FIPS 186-3. Le premier coeur qui détermine un nombre convenable (ici le coeur Ci) émet ce nombre à destination de l'unité centrale 2, qui le reçoit à l'étape E202 et mémorise ce nombre en tant que nombre premier p. 3038420 19 Le second coeur qui détermine un nombre convenable (ici le coeur Ck) émet ce nombre à destination de l'unité centrale 2, qui le reçoit à l'étape E204 et mémorise ce nombre en tant que nombre premier q. L'unité centrale 2 procède alors à l'étape E206 à laquelle elle commande 5 l'arrêt de tous les coeurs C1, C, (sauf éventuellement ceux qui ont déjà arrêté leur fonctionnement du fait de l'émission d'une réponse, ici les coeurs Ci et Ck). En variante, une telle commande d'arrêt pourrait être omise, auquel cas on laisse simplement les calculs dans chaque coeur se terminer d'eux même. L'unité centrale 2 effectue alors à l'étape E208 le calcul des autres 10 éléments de la clé cryptographique, à savoir les calculs suivants : - dp = e-1 mod (p-1) ; - dg = e-1 mod (q-1) ; - n = p.q . La détermination de la clé cryptographique est ainsi terminée et l'unité 15 centrale 2 peut émettre les éléments de cette clé, soit p, q, n, dp, dg, à destination par exemple d'une autre entité électronique (étape E210). En variante, on pourrait prévoir d'attendre le résultat en provenance d'un unique coeur (qui formerait le nombre p, comme à l'étape E202), d'arrêter alors l'ensemble des coeurs (comme à l'étape E206), puis de relancer les traitements 20 dans les différents coeurs (comme à l'étape E200) jusqu'à ce qu'un coeur renvoie un nombre qui sera alors utilisé en tant que nombre premier q (le traitement pouvant alors être arrêté dans les autres coeurs comme prévu à l'étape E206). REVENDICATIONS1. Dispositif de traitement cryptographique de données comprenant un processeur graphique (20), caractérisé en ce qu'il comprend un élément sécurisé (4) mémorisant 5 des instructions (SCR) exécutables par le processeur graphique (20) et conçues pour mettre en oeuvre au moins une fonction lorsqu'elles sont exécutées par le processeur graphique (20). 2. Dispositif de traitement cryptographique selon la revendication 1, dans lequel l'élément sécurisé (4) comprend des moyens de lecture des instructions 10 exécutables (SCR) dans une mémoire de l'élément sécurisé (4) et des moyens de transmission des instructions exécutables (SCR) lues à destination du processeur graphique (20). 3. Dispositif de traitement cryptographique selon la revendication 1, comprenant une unité centrale (2) conçue pour fonctionner dans un mode 15 sécurisé (TEE) et pour recevoir, lors de son fonctionnement dans le mode sécurisé (TEE), les instructions exécutables (SCR) en provenance de l'élément sécurisé (4) et pour transmettre ces instructions exécutables (SCR) à destination du processeur graphique (20). 4. Dispositif de traitement cryptographique selon la revendication 3, dans 20 lequel l'élément sécurisé (4) et le processeur graphique (20) sont conçus de manière à communiquer uniquement lors du fonctionnement dans le mode sécurisé (TEE). 5. Dispositif de traitement cryptographique selon la revendication 2 ou 3, dans lequel les instructions exécutables (SCR) transmises sont signées au moyen 25 d'une clé cryptographique de l'élément sécurisé (4). 6. Dispositif de traitement cryptographique selon l'une des revendications 1 à 5, dans lequel ladite fonction est une fonction cryptographique. 7. Dispositif de traitement cryptographique selon la revendication 6, dans lequel la fonction cryptographique est une fonction de génération de clé RSA. 30 8. Dispositif de traitement cryptographique selon l'une des revendications 1 à 5, dans lequel ladite fonction est une fonction graphique. 9. Dispositif de traitement cryptographique selon l'une des revendications 1 à 8, conçu pour fonctionner sélectivement dans un environnement d'exécution polyvalent (REE) et dans un environnement d'exécution de confiance (TEE). 3038420 21 10. Dispositif de traitement cryptographique selon l'une des revendications 1 à 9, dans lequel le processeur graphique (20) comporte au moins 100 unités de calcul. 11. Dispositif de traitement cryptographique selon l'une des revendications 1 à 10, dans lequel le processeur graphique (20) est conçu pour traiter en parallèle une pluralité d'ensembles de données selon un unique jeu d'instructions. 12. Dispositif de traitement cryptographique selon l'une des revendications 1 à 11, dans lequel le processeur graphique (20) est conçu pour effectuer des opérations mathématiques vectorielles. 13. Dispositif de traitement cryptographique selon l'une des revendications 1 à 12, dans lequel le processeur graphique (20) est conçu pour fonctionner selon une structure de type grille. 14. Terminal de communication mobile comprenant un dispositif de traitement cryptographique selon l'une des revendications 1 à 13. 15. Procédé de traitement cryptographique de données mis en oeuvre dans un dispositif comprenant un processeur graphique (20), caractérisé en ce qu'il comprend les étapes suivantes : - chargement (E22, E24; E62, E64) dans le processeur graphique (20) d'instructions (SCR) mémorisées dans un élément sécurisé (4) ; - mise en oeuvre d'au moins une fonction (E38; E66; E138; E148; E156) du fait de l'exécution desdites instructions (SCR) par le processeur graphique (20). 16. Procédé de traitement cryptographique selon la revendication 15, 25 dans lequel le chargement (E22, E24) des instructions dans le processeur graphique (20) est effectué en provenance de l'élément sécurisé (4). 17. Procédé de traitement cryptographique selon la revendication 15, dans lequel le dispositif comprend une unité centrale (2) conçue pour fonctionner dans un mode sécurisé (TEE) et pour recevoir (E52), lors de son fonctionnement 30 dans le mode sécurisé (TEE), les instructions en provenance de l'élément sécurisé (4) et dans lequel le chargement (E62, E64) des instructions (SCR) dans le processeur graphique (20) est effectué en provenance de l'unité centrale (2). 18. Procédé de traitement cryptographique selon l'une des revendications 15 à 17, dans lequel ladite fonction est une fonction 3038420 22 cryptographique. 19. Procédé de traitement cryptographique selon la revendication 18, dans lequel le processeur graphique (20) exécute, parallèlement à l'exécution desdites instructions, d'autres instructions mettant en oeuvre un algorithme de 5 traitement graphique ou géométrique. 20. Procédé de traitement cryptographique selon la revendication 18 ou 19, dans lequel le processeur graphique (20) met en oeuvre une fonction graphique utilisant au moins un résultat de la fonction cryptographique. 21. Procédé de traitement cryptographique selon l'une des 10 revendications 15 à 17, dans lequel ladite fonction est une fonction graphique. 22. Procédé de traitement cryptographique selon l'une des revendications 15 à 21, dans lequel le dispositif est conçu pour fonctionner sélectivement dans un environnement d'exécution polyvalent (REE) et dans un environnement d'exécution de confiance (TEE) et dans lequel la mise en oeuvre 15 de ladite fonction est commandée lors du fonctionnement dans l'environnement d'exécution de confiance (TEE). 23. Procédé de traitement cryptographique selon la revendication 22, comprenant, préalablement à l'étape de chargement (E22, E24; E62, E64; E122, E124), une étape de basculement (E8, E10; E106, E108) du dispositif vers le 20 fonctionnement dans l'environnement d'exécution de confiance (TEE). 24. Procédé de traitement cryptographique selon l'une des revendications 15 à 23, dans lequel les instructions (SCR) chargées dans le processeur graphique (20) sont signées au moyen d'une clé cryptographique de l'élément sécurisé. 25. Procédé de traitement cryptographique selon l'une des revendications 15 à 24, dans lequel le processeur graphique (20) comporte au moins 100 unités de calcul.