FR 2913152 A1 20080829 FR 0701277 A 20070222 Procédé de surveillance d'exécution d'un protocole de communication, produit programme d'ordinateur, moyen de stockage et dispositifs correspondants. 1. Domaine de l'invention Le domaine de l'invention est celui des réseaux de communication de données. Plus particulièrement, l'invention concerne la protection des protocoles de communication lors de leur exécution. L'invention s'applique notamment, mais non exclusivement, dans le cas d'un réseau multimédia, où le flux de données transporte des données de type audio-vidéo (AV) protégées contre la copie transmises entre plusieurs dispositifs terminaux d'un tel réseau. 2. Art antérieur L'utilisation massive de supports numériques a contribué à l'augmentation de la copie d'oeuvres soumises au droit d'auteur (par exemple des oeuvres audio, vidéo, littéraire, scientifique, logicielle,...). Aussi, et afin de protéger de telles oeuvres de la copie (et leur auteur par voie de conséquence), un cryptage des fichiers numériques d'origine de ces oeuvres a été mis en place afin de s'assurer que chaque utilisateur n'a accès à ces fichiers qu'au moyen d'un lecteur adapté sécurisé. Des protocoles de DRM (pour en anglais Digital Rights Management ou Gestion des Droits Numériques en français) sont ainsi mis en oeuvre pour crypter les fichiers d'origine et les transmettre ensuite sur un réseau de communication. Le protocole DTCP (pour en anglais Digital Transmission Content Protection ou en français Protection de transmissions numériques de Contenu ) est par exemple un protocole de DRM classiquement utilisé. Cependant, les logiciels d'implémentation des protocoles de DRM sont la cible de personnes malintentionnées (encore appelées pirates informatiques) qui cherchent à en comprendre le code et/ou à obtenir les clés secrètes utilisées lors du cryptage, afin de pouvoir ensuite contourner la protection contre la copie instaurée. Pour arriver à leur fin, les pirates informatiques utilisent des débogueurs ou des émulateurs qui leur permettent de poser des points d'arrêt dans le code des logiciels d'implémentation de protocoles de DRM. Dès lors, ils peuvent exécuter ces logiciels pas à pas, et ainsi avoir accès à l'état des variables, à l'état de la mémoire ou à toute autre information secrète (par exemple les clés secrètes). L'accès à de telles informations secrètes ainsi que la compréhension du fonctionnement des logiciels d'implémentation des protocoles de DRM fragilisent alors nettement l'efficacité et la sécurité de tels protocoles. La demande de brevet américaine US 2006010329 décrit une technique de détection d'intrusions frauduleuses de dispositifs électroniques connectés à un réseau de communication mettant en oeuvre un protocole de communication. Cette technique permet à des dispositifs électroniques d'exécuter au moins une opération de calcul, telle que le hachage d'une partie de la mémoire (de chaque dispositif). Le résultat de chaque opération est reçu puis analysé par le dispositif concerné. Cependant, cette vérification d'intégrité est uniquement effectuée sur requête extérieure. En effet, un serveur de détection d'intrusions surveille un ou plusieurs dispositifs connectés à un réseau de communication en leur envoyant des requêtes de détection d'intrusions. Le serveur de détection d'intrusions peut alors analyser l'exactitude des réponses ainsi que la durée de traitement de chacune des requêtes. Aucune intrusion n'est détectée lorsque le résultat est correct et reçu dans un délai prédéterminé. Par contre, dans le cas d'un résultat erroné ou lorsque le résultat n'est pas reçu dans un délai prédéterminé (même si ce résultat est correct), une intrusion est détectée. En outre, en cas d'absence de réponse dans un délai prédéterminé, le serveur de détection considère qu'une erreur s'est produite, et déclenche une alarme. Aussi, un inconvénient de cette technique de l'art antérieur réside dans le fait qu'elle ne réalise de vérifications d'intégrité (sous la forme d'un calcul de hachage) que sur requête d'un serveur de détection d'intrusions. Elles ne sont pas déclenchées en fonction d'évènements prédéterminés d'un protocole de communication. Ces vérifications ne sont par conséquent pas optimales. Un autre inconvénient de cette technique de l'art antérieur est que la détection d'intrusions nécessite la mise en oeuvre d'un dispositif extérieur (le serveur de détection d'intrusions) pour déclencher une vérification d'intégrité d'un dispositif électronique. Encore un autre inconvénient de cette technique de l'art antérieur est qu'il n'existe pas de mécanisme permettant de gérer le cas d'un abandon volontaire (c'est-à- dire qui n'est pas imputable à l'action d'un pirate informatique) de l'exécution d'un protocole de DRM. En effet, en raison de l'abandon volontaire de l'exécution d'un protocole de DRM, aucun message n'est envoyé dans un délai prédéterminé. L'absence de message conduit le serveur de détection à générer une fausse alarme. La demande de brevet US 2005229164 décrit une technique de sécurisation d'un programme stocké dans un appareil électronique. Cette technique consiste à vérifier la durée d'exécution d'au moins une séquence protégée du programme par rapport à une durée prédéterminée d'exécution normale de la séquence. De nouveau, un inconvénient de cette technique de l'art antérieur précitée est qu'il n'existe pas de mécanisme permettant de gérer le cas d'un abandon volontaire de l'exécution d'un protocole de DRM. En effet, l'absence d'un tel mécanisme d'abandon conduit au déclenchement d'une fausse alarme lorsqu'un abandon d'exécution d'un protocole est effectué. 3. Objectifs de l'invention L'invention, dans au moins un mode de réalisation, a notamment pour objectif de pallier ces différents inconvénients de l'état de la technique. Plus précisément, l'un des objectifs de la présente invention, dans au moins un mode de réalisation, est de fournir une technique permettant de détecter les intrusions des pirates informatiques dans des protocoles de communication, telles que par exemple le détournement ou la falsification de données protégées contre la copie lors de leur transmission sur un réseau de communication selon un protocole de communication. L'invention a également pour objectif, dans au moins un mode de réalisation, de fournir une telle technique permettant de préserver un logiciel d'implémentation d'un protocole de DRM de toute intrusion frauduleuse. L'invention a également pour objectif, dans au moins un mode de réalisation, de fournir une telle technique permettant cle signaler tout fonctionnement anormal d'un logiciel d'implémentation d'un protocole de DRM. Un autre objectif de l'invention, dans au moins un mode de réalisation, est proposer une technique permettant de signaler l'abandon de l'exécution d'un protocole de DRM. Encore un objectif de l'invention, dans au moins un mode de réalisation, est de fournir une technique qui ne dégrade pas les performances d'un logiciel d'implémentation d'un protocole de DRM. Un autre objectif de l'invention, dans au moins un mode de réalisation, est de fournir une telle technique qui soit simple à mettre en oeuvre et peu coûteuse. 4. Exposé de l'invention Ces objectifs ainsi que d'autres qui apparaîtront par la suite, sont atteints à l'aide d'un procédé de surveillance d'exécution d'un protocole de communication dans un dispositif comprenant un module de traitement de données exécutant ledit protocole de communication et un module d'interface permettant d'interfacer ledit module de traitement de données avec un réseau de communication, ledit protocole de communication définissant des messages qui sont reçus du réseau de communication par ledit module de traitement de données et des messages qui sont émis par ledit module de traitement de données vers le réseau de communication, lesdits messages marquant respectivement des débuts et fins de traitements prédéterminé. Selon l'invention, un tel procédé comporte les étapes suivantes : - réception du réseau de communication d'un message, dit message entrant, destiné à être traité par le module de traitement de données selon le protocole de communication et marquant le début d'un traitement donné ; - dans le cas d'une réception d'indication d'abandon dudit traitement donné par le module de traitement de données, vérification d'intégrité, dite première vérification d'intégrité, d'un ensemble d'instructions mises en oeuvre par le module de traitement de données pour l'exécution dudit protocole de communication. Le principe général de l'invention consiste donc à : - introduire des indications d'abandon, non prévues dans le protocole, pour indiquer une fin de traitement dans une situation où le protocole n'associe aucun message sortant à un message entrant ; et - éviter une utilisation frauduleuse des indications d'abandon, en effectuant une vérification d'intégrité après réception par le module d'interface d'une indication d'abandon. De façon avantageuse, ladite première vérification d'intégrité comprend une étape de vérification d'intégrité d'au moins un bloc d'une mémoire comprise dans ledit dispositif et dans lequel est stocké ledit ensemble d'instructions. Ainsi, la vérification d'intégrité peut par exemple être exécutée sur les blocs mémoire de la mémoire morte ROM et/ou de la mémoire vive RAM, chacune de ces deux types de mémoire pouvant stocker des instructions du protocole de communication. Avantageusement, ladite vérification d'intégrité d'au moins un bloc d'une mémoire comprend une étape d'obtention de l'ensemble d'instructions stocké dans ledit ou lesdits bloc(s) d'une mémoire, selon un mécanisme d'accès direct à la mémoire. Ainsi, la récupération du contenu d'un bloc mémoire selon un mécanisme d'accès direct à la mémoire (ou DMA) permet au module d'interface d'accéder directement à la mémoire sans passer par le module de traitement de données, ce qui permet d'améliorer notablement les performances du module d'interface, ainsi que la sécurisation du transfert du contenu puisque la mise en oeuvre est uniquement matérielle ( hardware ) et donc plus difficilement accessible aux pirates informatiques. Selon une caractéristique avantageuse, ladite vérification d'intégrité d'au moins un bloc d'une mémoire comprend les étapes suivantes : obtention d'une valeur résultant d'une fonction prédéterminée appliquée à l'ensemble d'instructions stocké dans ledit ou lesdits bloc(s) d'une mémoire ; comparaison de ladite valeur obtenue avec une valeur prédéterminée ; la vérification d'intégrité étant négative dans le cas où la valeur obtenue diffère de la valeur prédéterminée. Ainsi, il est possible au moyen d'une vérification d'intégrité de détecter des modifications (ajouts d'instructions, points d'arrêt, ...) du code du logiciel d'un protocole de communication (par exemple DTCP), ces modifications permettant à une personne malintentionnée d'avoir accès à des informations confidentielles (par exemple des clés secrètes) via l'utilisation d'un débogueur ou d'un émulateur. En outre, la vérification d'intégrité peut mettre en oeuvre un calcul de somme de contrôle ( CRC ) qui porte, par exemple, sur des instructions ou segments d'instructions du logiciel du protocole de communication. Le résultat de ce calcul peut être comparé à une valeur prédéterminée attendue, cette valeur correspondant au résultat du calcul de sommes de contrôle appliqué aux instructions ou segments d'instructions d'origine non modifiées. Ainsi, une intrusion dans le dispositif est détectée lorsque que le résultat obtenu diffère de la valeur prédéterminée attendue. Dans un mode de réalisation avantageux de l'invention, le procédé de surveillance comprend une étape de vérification d'intégrité, dite seconde vérification d'intégrité, d'un ensemble d'instructions mises en oeuvre par le module de traitement de données pour l'exécution dudit protocole de communication, ladite seconde vérification d'intégrité étant déclenchée à l'initialisation du protocole de communication, la seconde vérification d'intégrité étant négative dans le cas d'une détection d'un message émis par le module de traitement de données à destination du réseau de communication correspondant à un message non prévu par le protocole de communication. Ainsi, cette seconde vérification d'intégrité permet de vérifier qu'aucun message sortant non prévu dans le protocole de communication n'a été émis par le module de traitement de données. En effet, la réception d'un tel message sortant non prévu est considérée par le module d'interface comme le fruit d'une intrusion extérieure, et engendre une seconde vérification négative pour protéger le logiciel exécutant le protocole de communication. Dans un mode de réalisation avantageux de l'invention, le procédé de surveillance comprend une étape de vérification d'intégrité, dite seconde vérification d'intégrité, d'un ensemble d'instructions mises en oeuvre par le module de traitement de données pour l'exécution dudit protocole de communication, ladite seconde vérification d'intégrité étant déclenchée à l'initialisation du protocole de communication, la seconde vérification d'intégrité étant négative dans le cas d'une réception d'une indication d'abandon d'exécution du protocole de communication par le module de traitement de données ne correspondant pas à un traitement donné. Ainsi, cette seconde vérification d'intégrité permet de vérifier qu'aucune notification d'abandon n'a été émise par le module de traitement de données, sans qu'elle ne corresponde à un traitement de données prévu par le protocole de communication. En effet, la réception d'une telle notification d'abandon est considérée par le module d'interface comme le fruit d'une intrusion extérieure, et engendre une seconde vérification négative pour protéger le logiciel exécutant le protocole de communication. Dans un mode de réalisation particulier de l'invention, le procédé de surveillance comprend, sur réception du message entrant, les étapes suivantes : - déclenchement d'une temporisation associée à une durée maximale autorisée pour le traitement du message entrant par le module de traitement de données ; - détermination si un message à érnettre par le module de traitement de données, dit message sortant, fait suiteä selon le protocole de communication, au traitement du message entrant et marquant la fin dudit traitement donné. Ainsi, l'invention permet d'utiliser comme instants de début et fin de chaque partie d'un logiciel implémentant un protocole de communication (par exemple DTCP) dont on souhaite vérifier la durée d'exécution, les instants de réception, par le module d'interface, d'un couple de messages (message entrant, message sortant) défini par ce protocole. En d'autres termes, les mesures de temps de traitement sont intimement liées à une séquence de messages entrant et sortant définie par le protocole. Ainsi, la temporisation (déclenchée par un message entrant) expire, par exemple, lorsque aucun message sortant marquant la fin du traitement du message entrant n'a été détecté pendant la durée maximale de traitement (définie selon les spécifications du protocole de communication), indiquant ainsi une exécution anormale du protocole de communication. Il est ainsi possible de vérifier la durée de traitement de toutes les actions déclenchées par le logiciel exécutant le protocole de communication pour détecter tout comportement anormal du protocole de communication. Avantageusement, le procédé de surveillance comprend une étape de vérification d'intégrité, dite troisième vérification d'intégrité, d'un ensemble d'instructions mises en oeuvre par le module de traitement de données pour l'exécution dudit protocole de communication, ladite troisième vérification d'intégrité comprenant une étape d'attente de détection d'un message émis par le module de traitement de données à destination du réseau de communication correspondant au message sortant. Ainsi, l'étape de détection de cette troisième vérification d'intégrité permet de vérifier qu'un message sortant a bien été généré en réponse à l'émission d'un message entrant avant l'expiration d'une temporisation (correspondant à une durée maximale de traitement du message entrant). De façon avantageuse, la troisième vérification d'intégrité est négative dans le cas où la temporisation expire sans qu'un message émis par le module de traitement de données à destination du réseau de communication correspondant au message sortant ne soit détecté. Ainsi, lorsqu'un message sortant prévu par le protocole de communication n'est pas détecté pendant la temporisation donnée, une détection d'intrusion est diagnostiquée. Dans un mode de réalisation avantageux de l'invention, en cas de première, deuxième ou troisième vérification d'intégrité négative, le procédé de surveillance comprend une étape de déclenchement d'une procédure d'alarme visant à modifier le comportement dudit dispositif vis-à-vis du protocole de communication. Lorsque la vérification d'intégrité est négative, une alarme est déclenchée pour préserver le code du logiciel d'implémentation d'un ]protocole de communication ainsi que les données protégées contre la copie. L'alarme générée peut par exemple conduire à un redémarrage complet du dispositif. Selon une caractéristique avantageuse, le protocole de communication correspond à un protocole de protection des droits associés à un contenu comprenant une phase d'encryptage et/ou de décryptage dudit contenu et en ce que ladite procédure d'alarme comprend une étape de modification d'au moins une clé servant à l'encryptage et/ou au décryptage dudit contenu. Ainsi, et afin de préserver la confidentialité des données protégées contre la copie et la sécurité du protocole de communication, l'alarme déclenchée peut conduire au changement de la valeur de certaines clés secrètes mises en oeuvre par le protocole de communication de manière à le rendre impropre à l'exécution du protocole de communication, jusqu'à restauration des clés secrètes initiales. Dans un autre mode de réalisation particulier, l'invention concerne un produit programme d'ordinateur téléchargeable depuis un réseau de communication et/ou enregistré sur un support lisible par ordinateur et/ou exécutable par un processeur, comprenant des instructions de code de programme pour l'exécution des étapes du procédé de surveillance d'exécution d'un protocole de communication tel que décrit précédemment., lorsque ledit programme est exécuté sur un ordinateur. Dans un autre mode de réalisation particulier, l'invention concerne un moyen de stockage, éventuellement totalement ou partiellement amovible, lisible par un ordinateur, stockant un jeu d'instructions exécutables par ledit ordinateur pour mettre en oeuvre le procédé de surveillance d'exécution d'un protocole de communication tel que décrit précédemment. L'invention concerne aussi un dispositif comprenant un module de traitement de données exécutant un protocole de communication et un module d'interface permettant d'interfacer ledit module de traitement de données avec un réseau de communication, ledit protocole de communication définissant des messages qui sont reçus du réseau de communication par ledit module de traitement de données et des messages qui sont émis par ledit module de traitement de données vers le réseau de communication, lesdits messages marquant respectivement des débuts et fins de traitements prédéterminés, et comprenant : - des moyens de réception du réseau de communication d'un message, dit message entrant, destiné à être traité par ledit module de traitement de données selon le protocole de communication et marquant le début d'un traitement donné ; - des premiers moyens de détection d'une réception d'indication d'abandon dudit traitement donné par le module de traitement de données ; - des premiers moyens de vérification d'intégrité d'un ensemble d'instructions mises en oeuvre par le module de traitement de données pour l'exécution dudit protocole de communication, lesdits premiers moyens de vérification d'intégrité étant activés dans le cas d'une réception d'indication d'abandon dudit traitement donné par lesdits premiers moyens de détection. Dans un mode de réalisation avantageux de l'invention, lesdits premiers moyens de vérification d'intégrité comprennent des moyens de vérification d'intégrité d'au moins un bloc d'une mémoire comprise dans ledit dispositif et dans lequel est stocké ledit ensemble d'instructions. De façon avantageuse, lesdits moyens de vérification d'intégrité d'au moins un bloc d'une mémoire comprennent des moyens d'obtention de l'ensemble d'instructions stocké dans ledit ou lesdits bloc(s) d'une mémoire, selon un mécanisme d'accès direct à la mémoire. Avantageusement, lesdits moyens de vérification d'intégrité d'au moins un bloc d'une mémoire comprennent : des moyens d'obtention d'une valeur résultant d'une fonction prédéterminée appliquée à l'ensemble d'instructions stocké clans ledit ou lesdits bloc(s) d'une mémoire ; - des moyens de comparaison de ladite valeur obtenue avec une valeur prédéterminée ; - des premiers moyens de décision permettant de décider qu'une première vérification est négative dans le cas où la valeur obtenue diffère de la valeur prédéterminée. Dans un mode de réalisation particulier de l'invention, le dispositif comprend des moyens de vérification d'intégrité, dits seconds moyens de vérification d'intégrité, d'un ensemble d'instructions mises en oeuvre par le module de traitement de données pour l'exécution dudit protocole de communication, lesdits seconds moyens de vérification d'intégrité étant déclenchés à l'initialisation du protocole de communication ; et en ce que lesdits seconds moyens de vérification d'intégrité comprennent : - des seconds moyens de détection d'un message émis par le module de traitement de données à destination du réseau de communication correspondant à un message non prévu par le protocole de communication ; - des seconds moyens de décision permettant de décider qu'une seconde vérification est négative dans le cas d'une détection par lesdits seconds moyens de détection d'un message émis par le module de traitement de données à destination du réseau de communication correspondant à un message non prévu par le protocole de communication. Avantageusement, le dispositif comprend des moyens de vérification d'intégrité, dits seconds moyens de vérification d'intégrité, d'un ensemble d'instructions mises en oeuvre par le module de traitement de données pour l'exécution dudit protocole de communication, lesdits seconds moyens de vérification étant déclenchés à l'initialisation du protocole de communication, et en ce que lesdits seconds moyens de vérification d'intégrité comprennent : - des seconds moyens de détection d'une réception d'une indication d'abandon d'exécution du protocole de communication ne correspondant pas à un traitement donné ; - des seconds moyens de décision permettant de décider qu'une seconde vérification est négative dans le cas d'une réception d'une indication d'abandon d'exécution du protocole de communication par lesdits seconds moyens de détection ne correspondant pas à un traitement donné. Dans un mode de réalisation avantageux de l'invention, le dispositif comprend : - des moyens de déclenchement d'une temporisation associée à une durée maximale autorisée pour le traitement du message entrant par le module de traitement de données ; - des moyens de détermination si un message à émettre par le module de traitement de données, dit message sortant, fait suite, selon le protocole de communication, au traitement d[u message entrant et marquant la fin dudit traitement donné. De façon avantageuse, le dispositif comprend : - des moyens de vérification d'intégrité, dits troisièmes moyens de vérification d'intégrité, d'un ensemble d'instructions mises en oeuvre par le module de traitement de données pour l'exécution dudit protocole de communication ; - des troisièmes moyens de détection d'un message émis par le module de traitement de données à destination du réseau de communication correspondant au message sortant. Selon une caractéristique avantageuse, lesdits troisièmes moyens de vérification d'intégrité comprennent : - des moyens de détection de l'expiration de la temporisation sans qu'un message émis par le module de traitement de données à destination du réseau de communication correspondant au message sortant ne soit détecté ; - des troisièmes moyens de décision permettant de décider qu'une troisième vérification d'intégrité est négative dans le cas où l'expiration de la temporisation est détectée par lesdits moyens détection sans qu'un message émis par le module de traitement de données à destination du réseau de communication correspondant au message sortant ne soit détecté. Dans un mode de réalisation avantageux de l'invention, le dispositif comprend des moyens de déclenchement d'une procédure d'alarme visant à modifier le comportement dudit dispositif vis-à-vis du protocole de communication, lesdits moyens de déclenchement étant activés en cas de vérification d'intégrité négative par lesdits premiers, seconds ou troisièmes moyens de vérification d'intégrité. Avantageusement, le dispositif comprend : des moyens d'encryptage et/ou de décryptage d'un contenu ; des moyens de modification d'au moins une clé servant à l'encryptage et/ou au décryptage dudit contenu, lesdits moyens de modification étant activés lors de ladite procédure d'alarme. 5. Listes des figures D'autres caractéristiques et avantages des modes de réalisation de l'invention apparaîtront à la lecture de la description suivante, donnée à titre d'exemple indicatif et non limitatif (tous les modes de réalisation de l'invention ne sont pas limités aux caractéristiques et avantages de ce mode de réalisation particulier), et des dessins annexés, dans lesquels : la figure 1 présente, sous forme d'un schéma bloc, une architecture détaillée d'un dispositif mettant en oeuvre l'invention selon un mode de réalisation particulier ; la figure 2 illustre un exemple de protocole connu (à savoir DTCP) pouvant être protégé par la mise en oeuvre du mode de réalisation précité de la présente invention ; la figure 3 présente une application du mode cle réalisation particulier précité de l'invention pour la protection du protocole DTCP de la figure 2 ; et la figure 4 illustre une machine d'états finis, selon le mode de réalisation particulier précité de l'invention. 6. Description détaillée On se place, dans la suite, dans un réseau de communication mettant en oeuvre le protocole de communication IEEE-1394 compatible avec un protocole de DRM par exemple le protocole DTCP. Il est clair que l'invention s'applique également à tout autre réseau de communication, par exemple au cas d'un réseau audio-vidéo mettant en oeuvre les technologies de communication Ethernet TCP/IP (pour en anglais Transmission Control Protocol/Internet Protocol ) compatible avec un protocole de DRM. La figure 1 présente, sous forme d'un schéma bloc, une architecture détaillée d'un dispositif 200 selon un mode de réalisation particulier de l'invention. Le dispositif 200 peut par exemple être un ordinateur personnel, une station de travail, un système informatique intégré dans un équipement électronique, ... Selon le mode de réalisation particulier de l'invention, le dispositif 200 est un dispositif récepteur capable de recevoir un contenu protégé contre la copie. Bien entendu, selon une variante du mode de réalisation particulier del'invention, le dispositif 200 peut également servir de dispositif source capable de délivrer un contenu protégé contre la copie. Selon le mode de réalisation particulier de l'invention, le dispositif récepteur 200 est notamment connecté aux différents dispositifs périphériques suivants : un dispositif source audio-vidéo 225 (par exemple un boîtier décodeur ou STB (en anglais pour Set Top Box ), ou un dispositif de stockage de masse d'images et/ou de données audio-vidéo). La connexion entre le dispositif récepteur 200 et le dispositif source AV 225 est réalisée par l'intermédiaire d'un réseau de communication 220 mettant en oeuvre le protocole de communication IEEE-1394. La transmission sur le réseau 220 d'un contenu protégé contre la copie est réalisée en utilisant par exemple le protocole de protection DTCP. Le dispositif source 225, bien que non représenté en détail sur la figure 1, peut également mettre en oeuvre l'invention. Dans ce cas, le dispositif source 225 comprend une architecture similaire (bien que symétrique), à l'architecture du dispositif récepteur 200. En particulier, l'unité de déchiffrement 232 est remplacée par une unité de chiffrement. Pour un dispositif source, les périphériques classiques connectés au bus interne 202 comprennent des syntoniseurs pour une réception par câble ou satellite, des lecteurs de DVD, ... Par ailleurs, il peut exister des dispositifs comportant à la fois une fonction source et une fonction récepteur (par exemple un disque dur audio-vidéo, ou un lecteur-enregistreur de DVD) capables de mettre en oeuvre l'invention soit par sa fonction source, soit par sa fonction récepteur, soit alors au moyen de ses deux fonctions ; un récepteur vidéo 221 (encore appelé périphérique vidéo) qui comprend un module d'affichage. Le récepteur vidéo 221 peut par exemple être un moniteur d'ordinateur. La connexion du récepteur vidéo 221 avec le dispositif récepteur 200 peut être réalisée au moyen d'une connexion analogique ou d'une connexion numérique, par exemple une connexion HDMI (pour en anglais High Definition Multimedia Interface ). Que ce soit pour une connexion analogique ou pour une connexion numérique, la transmission de contenus protégés contre la copie peut être réalisée selon des technologies de protection de connexion adaptées au type de connexion en place (analogique ou numérique). Ainsi, les protocoles Macrovision AGC ( Automatic Gain Control ) et ColorstripeTM peuvent être mises en oeuvre pour une connexion analogique, et le protocole HDCP (pour en anglais High Bandwidth Digital Content Protection ou en français Protection de contenus numériques à haute bande passante ) pour une connexion numérique ; un récepteur audio 222 (par exemple un amplificateur comprenant des écouteurs ou des haut-parleurs) connecté soit à une sortie audio analogique soit à une sortie audio numérique du dispositif récepteur 200 ; un clavier externe 223. Par ailleurs, le dispositif 200 peut également comprendre un bus de communication interne 202 auquel sont connectés les éléments suivants : un processeur ou CPU (pour en anglais Central Processing Unit ) 203 (encore appelé module de traitement de données) ; une mémoire ROM 204 (pour en anglais Read Only Memory traduit en français par mémoire morte ) ; une mémoire RAM 206 (pour en anglais Random Access Memory traduit en français par mémoire vive ) comprenant notamment dans un ou plusieurs blocs situés chacun à une adresse prédéterminée connue et ayant une taille prédéterminée connue : - un code exécutable ; - des données en lecture seule ; - des données en lecture/écriture initialisées et non-initialisées ; - des piles et tas ( stack and heap en anglais) du logiciel implémentant un protocole d'authentification et d'échange de clés AKE (pour en anglais Authentification/Key Exchange ) permettant de recevoir un contenu audio-vidéo protégé, comme par exemple le protocole DTCP-AKE. Selon le mode de réalisation particulier de l'invention, le code exécutable, les données en lecture seules et les données en lecture-écriture initialisées sont par exemple chargées à partir d'un disque dur 212 au démarrage d'une application permettant la réception et l'affichage de contenus protégés contre la copie. Selon une variante du mode de réalisation particulier de l'invention, le code exécutable, les données en lecture seule et les données en lecture-écriture initialisées sont chargées à partir de la mémoire ROM 204. La table présentée ci-après liste notamment les segments de code pertinents du logiciel : Nom du segment Définitions .text Code exécutable par le CPU 203 .rodata Données globales initialisées en lecture seule .data Données globales initialisées modifiables .bss Données globales non initialisées (initialisées à 0 au démarrage) .stack Pile de programme, stockant automatiquement des données .heap (arguments des fonctions, variables locales, valeurs de retour des fonctions...). Des segments piles multiples peuvent être présents dans le cas d'un programme multi-tâches ( multi- threaded en anglais). Tas de programme, stockant dynamiquement les données allouées Des variantes de cette structure de segments sont envisageables. Par exemple, les segments de code .text ou ärodata peuvent être divisés physiquement en plusieurs zones mémoires non continues. Par ailleurs, une distinction peut exister entre des adresses mémoires logiques telles qu'elles sont perçues par un programmeur, et des adresses physiques réelles telles qu'elles apparaissent sur le bus interne de communication 202. Dans ce cas, la transposition d'une adresse logique à une adresse physique est réalisée par une unité de gestion de mémoire MMU (pour en anglais Memory Management Unit ) incorporée dans le CPU 203 sous le contrôle d'un système d'exploitation ; un contrôleur vidéo 208 capable de délivrer en sortie un signal vidéo compatible avec le récepteur vidéo 221 et d'appliquer sous certaines conditions un protocole de protection de connexion approprié ; un contrôleur audio 209 pouvant délivrer en sortie un signal audio connu du récepteur audio 222 ; un module d'interface 219, réalisé par exemple en un seul bloc matériel. Le module d'interface 219 comprend notamment : un contrôleur d'accès réseau 218 permettant de recevoir des contenus audiovidéo susceptibles d'être protégés contre la copie, et d'exécuter un protocole AKE permettant la réception de contenus audio-vidéo protégés. Ce protocole AKE peut par exemple être le protocole DTCP AKE. Selon le mode de réalisation particulier, le contrôleur d'accès réseau 218 peut reconnaître les messages entrants et sortants de commande du protocole AKE, mais également des notifications d'abandon telles que décrites ultérieurement. Il peut également déterminer les tops horloges associés à la réception ou à l'envoi de ces messages de commande et notifications d'abandon. Le contrôleur d'accès réseau 218 est décrit plus en détail dans la suite de la description. Les paquets de données reçus par le contrôleur d'accès réseau 218 et comprenant un contenu protégé sont dirigés vers l'unité de déchiffrement 232 ; - un calculateur 230 de sommes de contrôle ( CRC ). Le calculateur 230 est averti de l'adresse de la taille de départ de chaque bloc mémoire de la mémoire physique RAM 206 comprenant les segments .text (du code exécutable) et 5 10 15 20 25 30 .rodata (des données en lecture seule) du logiciel implémentant le protocole AKE. Bien entendu, selon une variante, le calcul de sommes de contrôle peut être réalisé à partir des blocs mémoires de la mémoire morte ROM 204. Selon une autre variante, les adresses de départ et les tailles des blocs mémoire sont connues lors de la phase de fabrication, et sont figées dans le code du calculateur 230. Selon une autre variante permettant une mise à jour dynamique des logiciels, le calculateur 230 comprend notamment des registres spécialisés modifiables par le CPU 230 qui sont initialisés au démarrage du dispositif 200. L'algorithme de calcul de sommes doit fournir un contrôle d'intégrité fiable et infalsifiable. Ainsi, des algorithmes de signature numérique appropriés comprennent par exemple les algorithmes RSA (du nom de ses inventeurs Rivest, Shamir et Adleman ), DSA (pour en anglais Digital Signature Algorithm ou Algorithme de Signature Numérique en français) ou ECDSA ( pour en anglais Elliptic Curve Digital Signature Algorithm ou en français Algorithme de signature numérique réalisé à l'aide d'une courbe elliptique ). Ces algorithmes reposent sur la mise en oeuvre de paires de clés privée/publique. Une signature électronique est générée pour chacun des segments à protéger sur le logiciel, suite à la phase de compilation/édition de liens (en utilisant une clé d'accès secrète privée). Cette signature électronique est ensuite ajoutée à la fin de chacun des segments concernés. Le calculateur 230 connaît la clé publique correspondante. La clé publique est classiquement câblée ( hard wired en anglais) pour augmenter la résistance à la falsification, puisqu'il n'y a pas besoin de changer la clé au cours de la durée de vie du produit même lorsque des mises à jour logicielles sont effectuées. Il est à noter que le contenu des segments restants, par exemple .data , change au cours de l'exécution du programme. Par conséquent, aucune protection par somme de contrôle ne leur est appliquée. Le calculateur 230 de sommes de contrôle peut être déclenché via le contrôleur d'accès réseau 218. Il extrait alors les données des zones mémoires concernées, comprenant les signatures électroniques ajoutées, par un accès direct à la mémoire DMA (pour en anglais Direct Memory Access ). La détection d'une somme de contrôle non appropriée (par exemple due à la présence de points 10 15 20 25 30 d'interruption logicielle ou de modifications temporaires du code réalisées par un pirate informatique utilisant un débogueur) est signalée à l'unité d'alarme 231 décrite ci-après ; une unité 231 d'alarme, pouvant être déclenchée par le contrôleur 218 d'accès réseau selon des conditions qui sont décrites ultérieurement en relation avec la figure 4. Elle peut également être activée par le calculateur 230 de sommes de contrôle lorsque ce dernier détecte une somme de contrôle erronée résultant d'une intrusion dans le dispositif 200. En réponse à cette intrusion, l'unité 231 d'alarme peut déclencher un redémarrage complet du dispositif récepteur 200 immédiatement ou après une période aléatoire déterminée. Selon une première variante, l'unité 231 d'alarme envoie un signal erroné à une unité 232 de déchiffrement de contenus (décrite ci-après) qui ne peut dès lors plus recevoir ni traiter de contenus protégés contre la copie. Selon une seconde variante, qui peut être combinée avec les deux précédentes, l'unité 231 d'alarme génère un drapeau d'altération non volatile qui conserve sa valeur même après le redémarrage ou la mise en hors tension du dispositif 200, par exemple rendant impossible le prochain démarrage du dispositif 200, et qui ne peut être effacé que par le Service Clients en charge de la maintenance du dispositif 200. Le dispositif attaqué est alors verrouillé de manière permanente. Selon une troisième variante, l'unité 231 d'alarme génère un signal à l'unité 232 de déchiffrement de contenus, dont la conséquence est la modification d'au moins une clé (il peut y avoir plusieurs contenus protégés qui sont traités en parallèle, donc plusieurs clés en cours d'utilisation) de décryptage (respectivement d'encryptage pour un dispositif source 205) de manière à rendre le dispositif récepteur 200 impropre vis-à-vis de l'exécution du protocole de communication. D'autres actions, après le déclenchement de l'alarme, sont envisageables. Il est préférable que de telles actions de ripostes ne révèlent pas au pirate informatique une relation de cause à effet immédiate entre l'intrusion dans le dispositif et les symptômes de l'action de riposte, afin de rendre toute possibilité de contournement aussi difficile que possible ; - une unité 232 de déchiffrement, exécutant le déchiffrement de contenus protégés cryptés, par exemple selon le protocole DTCP, L'unité 232 de déchiffrement est intégrée dans la partie physique du dispositif récepteur 200, le logiciel d'implémentation du protocole DTCP exécuté sur le CPU 203 lui fournit alors uniquement les clés de contenu et les vecteurs d'initialisation corrects selon les spécifications du protocole DTCP'. Selon une variante, le déchiffrement peut être exécuté par un logiciel (sans unité physique de déchiffrement physique). En outre, il est également envisageable de connecter sur le bus de communication interne 202 du dispositif 200 les éléments suivants : un contrôleur de clavier 210 relié à un clavier externe 223 ; un disque dur 212 ; d'autres interfaces périphériques 214 telles qu"un contrôleur USB, un contrôleur de souris, un contrôleur de connexion série RS-232, un lecteur de disquette, un lecteur de CD/DVD, ... On présente maintenant, en relation avec la figure 2, une séquence simplifiée de messages échangés sur le réseau 220 de communication lors de l'exécution d'une phase d'authentification et d'échange de clés AKE (pour en anglais Authentification/Key Exchange ) conforme au protocole DTCP. Des messages supplémentaires (non représentés sur la figure 2) tels que par exemple les messages SRM ( System Renewability Messages ) pour l'échange d'informations concernant les dispositifs révoqués pour l'utilisation du protocole DTCP, les messages CONTENT_KEY_REQ, les mesures RTT ( Round Trip Time ) pour la détermination des temps de transferts des données entre un dispositif émetteur et un dispositif récepteur, ainsi que les messages CONT_KEY_CONF peuvent également être mis en oeuvre. Toute adaptation de la présente invention concernant l'utilisation de ces messages, lorsqu'elle est désirée et considérée nécessaire, sera évidente à mettre en oeuvre par l'Homme de l'Art. La phase AKE est initiée par le dispositif récepteur 200 lors de l'envoi d'un message 001 de commande CHALLENGE contenant un nombre aléatoire Bn ainsi que le certificat BCert du dispositif récepteur 200. Le dispositif source 225 accuse réception du message 001 de commande CHALLENGE en envoyant par retour un message 002 de réponse CHALLENGE. Le dispositif source 225 vérifie alors la validité de la signature électronique du certificat BCei1 reçu, ainsi que la présence d'une éventuelle révocation de ce certificat pour l'utilisation du protocole DTCP. Dans le cas d'une signature erronée ou d'une révocation, la phase AKE est arrêtée par le dispositif source 225 sans envoi de message supplémentaire. Dans le cas d'une vérification positive (signature valide et absence de révocation), le dispositif source 225 transmet à son tour un message 003 de commande CHALLENGE contenant un nombre aléatoire A. ainsi que le certificat ACert du dispositif source 225. La durée totale du traitement effectué par le dispositif source 225, entre la réception du message 001 et l'envoi du message 003, est notée toi. Après réception du message 003 de commande CHALLENGE, le dispositif récepteur 200 envoie un message 004 de réponse CHALLENGE comme accusé de réception. La durée du traitement effectué par le dispositif récepteur 200, entre la réception du message 003 et l'envoi du message 004, est notée t11. Après réception du message 004, le dispositif source 225 prépare puis envoie un message 005 de commande RESPONSE qui comprend. : la valeur A, de la première phase d'échange de clé EC-DH (pour Elliptic Curve Diffie-Hellman en anglais), déterminé à partir d'une valeur secrète aléatoire Ak. La valeur de Ak doit être maintenue secrète afin de préserver la confidentialité de la clé d'authentification Kaut,, (et par conséquent celle de la clé d'échange Kx), et du contenu de la clé Ke, ainsi que la sécurité du contenu protégé contre la copie crypté par K. lors de sa transmission sur le réseau 220 ; les numéros de version AsRmv et de génération AsRmc liés au SRM (pour en anglais System Renewability Message ou Message de mise à jour système en français) ; une signature du message, calculée à partir du nombre aléatoire B. (fourni par le dispositif récepteur 200), concaténé aux précédentes valeurs A,, AsRmv et ASRMc au moyen de la clé privé A-' du dispositif source 225. La clé privée A-' doit être conservée secrète pour empêcher un pirate informatique de cloner le dispositif et ainsi contourner la protection contre la copie mise en oeuvre par le protocole DTCP. La durée du traitement effectué par le dispositif source 225, entre la réception du message 004 et l'envoi du message 005, est notée t02. Après réception du message 005, le dispositif récepteur 200 envoie en retour un message 006 de réponse RESPONSE comme accusé de réception. Le dispositif récepteur 200 vérifie alors la validité de la signature du message 005, en utilisant la clé publique du dispositif source 225 contenue dans le certificat Acer reçu avec le message 003. Dans le cas d'une signature erronée du message 005, la phase AKE est arrêtée par le dispositif récepteur 200 sans envoi de message supplémentaire. Dans le cas d'une signature valide du message 005, le dispositif récepteur 200 choisit une valeur secrète aléatoire Bk et calcule le secret partagé à partir de la valeur A, et de la valeur Bk, à partir duquel est déterminée la clé d'authentification Kauth• Ensuite, le dispositif 200 prépare puis envoie en retour un message 007 de commande RESPONSE dont le contenu similaire (mais symétrique) au message 005 précédemment décrit ci-dessus (la valeur B, de la première phase d'échange de clé ECDH, les numéros de version BsRmv et de génération BsRmc liés au SRM, ainsi que la signature du message correspondant à la concaténation de An, B,, BsRmv et BsRmc utilisant la clé privé W1 du dispositif récepteur 200). Comme précédemment décrit, la clé privée 13-1, la valeur secrète aléatoire Bk ainsi que la clé d'authentification Kauth doivent être conservées secrètes pour empêcher un pirate informatique de cloner le dispositif et ainsi contourner la protection contre la copie mise en oeuvre par le protocole DTCP, et pour préserver la sécurité du contenu protégé contre la copie par cryptage en utilisant la clé K. lors de sa transmission sur le réseau de communication. La durée du traitement effectué par le dispositif récepteur 200, entre la réception du message 005 et l'envoi du message 007, est notée t12. Dès réception du message 007, le dispositif source 225 envoie un message 008 de réponse RESPONSE comme accusé de réception. La vérification de la signature du message 008, l'interruption de la phase AKE en cas de signature erronée, le calcul du secret partagé ainsi que la détermination de Kat. sont mis en oeuvre de manière similaire à ce qui a été décrit précédemment concernant le dispositif récepteur 200. Lorsque ces opérations sont réalisées, une autre valeur de secret aléatoire est choisie, par exemple la clé d'échange Kx. Elle est brouillée en utilisant la clé d'authentification Kaal, puis est envoyée au dispositif récepteur 200 dans un message 009 de commande EXCHANGE_KEY. La durée du traitement effectué par le dispositif source 225, entre la réception du message 007 et l'envoi du message 009, est notée t03. Dès réception du message 009, le dispositif récepteur 200 envoie un message 010 de réponse EXCHANGE_KEY comme accusé de réception. Après son décryptage mettant en oeuvre la clé d'authentification KaUlh, la clé d'échange reçue Kx peut être utilisée pour générer la ou les clé(s) de contenu IÇ, qui servent à leur tour au décryptage du contenu protégé contre la copie reçu provenant du dispositif source 225. La durée du traitement effectué par le dispositif source 225, entre la réception du message 009 et l'envoi du message 010, est notée t13. Les durées de traitement toi, t02, tO3 (respectivement t11, t12 et t13) représentent le temps de traitement local par le dispositif source 225 (respectivement par le dispositif récepteur 200) et ne tiennent pas compte des retards de transmission des messages du réseau 220 ni des délais de traitement du dispositif récepteur 200 (respectivement du dispositif source 225). Cependant, les durées du traitement précitées dépendent par exemple de la vitesse globale du dispositif récepteur 200, de la vitesse du CPU 203, ainsi que de la charge des bus. Ces durées de traitement sont par exemple de l'ordre de dizaines ou centaines de microsecondes. Les traitements réalisés pendant les durées de traitement t02, 4, et t12 impliquent notamment le calcul de valeurs secrètes dont la confidentialité est critique pour la sécurité de l'exécution du protocole DTCP et pour les contenus protégés contre la copie. Par conséquent, il peut être préférable de surveiller davantage ces délais afin de détecter une éventuelle tentative de détournement d'informations secrètes par un pirate informatique au moyen d'un débogueur (en établissant des points d'arrêt ou de simples modifications dans le code du logiciel d'implémentation du protocole de communication et de protection de données). On décrit en relation avec la figure 33 la mise en oeuvre d'un mode de réalisation particulier de l'invention appliquée à la phase AKE d'authentification et d'échange de clés selon le protocole DTCP décrit précédemment. On rappelle que le logiciel d'implémentation du protocole DTCP est par exemple exécuté par le processeur CPU 203 du dispositif récepteur 200. Les messages sortants de la phase AKE générés par le logiciel d'implémentation du protocole DTCP transitent par le contrôleur d'accès réseau 218 qui les envoie sur le réseau de communication 220. Les messages entrants de la phase AKE provenant du réseau de communication 220 transitent de manière similaire par le contrôleur d'accès réseau 218 avant d'être présentés au logiciel d'implémentation du protocole DTCP exécuté par le CPU 203. Selon le mode de réalisation particulier de l'invention, le contrôleur d'accès réseau 218 réceptionne puis analyse les messages entrants et sortants lors de l'exécution de la phase AKE. Ainsi, vu du dispositif récepteur 200, le contrôleur d'accès réseau 218 détecte par exemple le message 005 entrant de commande RESPONSE, aussi bien que les messages sortants correspondants de réponse RESPONSE 006 et de commande RESPONSE 007. Par ailleurs, le contrôleur d'accès réseau 218 peut permettre au logiciel d'implémentation du protocole DTCP d'émettre une notification d'abandon, par exemple au moyen d'un registre matériel adapté dans lequel une valeur prédéterminée peut être écrite. En outre, le contrôleur d'accès réseau 218 est capable de mesurer la durée de traitement t12 qui s'écoule entre la réception du message 005 et l'envoi soit du message 007 soit d'une notification d'abandon. Il est par exemple possible de renvoyer le message 007 à la suite d'une perte de paquets de données ou après l'expiration d'une temporisation, sous réserve qu'un tel renvoi soit effectué conformément au protocole DTCP. Les différents aspects de l'invention peuvent être implémentés par une machine d'états finis décrite plus en détails ultérieurement en relation avec la figure 4. De manière similaire, le contrôleur d'accès réseau 218 du dispositif récepteur 200 peut vérifier la durée de traitement t11 (respectivement t13) du logiciel d'implémentation du protocole DTCP entre la réception du message 003 de commande CHALLENGE (respectivement du message 009 de commande EXCHANGE_KEY) et soit l'envoi du message 004 de réponse CHALLENGE (respectivement du message 010 de réponse EXCHANGE_KEY) soit l'émission d'une notification d'abandon. Indépendamment des vérifications précédentes, des vérifications similaires peuvent être mises en oeuvre au sein du dispositif source 225. Cependant, elles ne seront pas décrites ici plus en détail par soucis de simplicité. La mise en oeuvre de l'invention dans un dispositif (récepteur ou source) n'affecte généralement pas son interopérabilité avec les autres dispositifs partenaires (avec lequel il échange des données selon le protocole DTCP), qu'ils mettent en oeuvre ou non la présente invention. La fonction de reconnaissance des messages entrants et sortants de la phase AKE (encore appelés, par abus de langage, messages AKE) du contrôleur d'accès réseau 218 peut par exemple dépendre de la nature du réseau de communication 220. Ainsi, dans un réseau de communication conforme à la norme IEEE 1394, les messages AKE sont par exemple encapsulés dans des trames de sécurité AV/C (pour Audio-Video/Command en anglais). Les commandes et réponses AV/C sont décrites dans le document Specification of AV/C Digital Interface Command Set . Par ailleurs, selon une variante, dans un réseau mettant en oeuvre le protocole Internet IP, les messages AKE sont transmis selon le protocole de communication DTCP-TCP. Le format des commandes AKE est décrit selon les spécifications du protocole DTCP. Dans chacun des deux cas précités, la reconnaissance des paquets (réalisée sous forme de moyen matériel) est facilitée par le fait que les messages AKE (avec l'exception possible de messages SRM (pour en anglais System Renewability Message ou Message de mise à jour système en français) sont suffisamment courts pour être conformes au protocole d'unité de données PDU (pour en anglais Protocol Data Units ) sans fragmentation. Le type de sous fonctions pertinentes (par exemple CHALLENGE, RESPONSE, EXCHANGE_KEY, ...) et d'autres champs typiques de la phase d'authentification et d'échange AKE (par exemple les champs OPCODE/TYPE, CATEGORY, AKE_ID, ...) sont localisés dans le paquet entête selon une position prédéterminée. Par ailleurs, chaque message AKE possède par exemple une taille caractéristique dépendant d'une sous-fonction, qui est également stockée dans le paquet entête et qui peut être analysée pour permettre une reconnaissance matériel des paquets AKE. On décrit, en relation avec la ferre 4, une machine d'états finis comportant les notations UML (pour en anglais Unified Modeling Language ) selon un mode de réalisation particulier de l'invention. Cette machine d'états finis illustre les états, les transitions entre états en fonction d'un état actuel et d'un évènement, ainsi que les actions associées qui sont réalisées par le contrôleur d'accès réseau 218. Sauf indication contraire, les traitements des messages AKE sont détaillés ci- après en prenant l'exemple d'un dispositif récepteur 200. Ils peuvent aisément être adaptés à un dispositif source 225 par l'Homme du Métier. Le détecteur d'intrusions des messages AKE du contrôleur d'accès réseau 218 se situe dans l'état 300 (nommé DEMARRAGE ) suite à l'initialisation du protocole de communication et aussi longtemps que la phase d'authentification et d'échange de clés AKE n'a pas débuté avec le dispositif source 225 auquel la machine d'état est associée. En effet, il existe une telle machine d'état pour chacun des dispositifs avec lequel le dispositif récepteur communique selon le protocole DTCP, les phases d'authentification et d'échange de clés AKE pour chacun des dispositifs sources étant exécutées de manière indépendante. L'initialisation du protocole de communication engendre la mise en place d'une vérification d'intégrité (seconde vérification d'intégrité) visant à détecter les utilisations inappropriées des messages sortants (émis par le dispositif récepteur 200 à destination du réseau de communication) et des signaux (aussi appelées notifications) d'abandon. Dans le cas d'unevérification d'intégrité négative résultant d'une utilisation inappropriée des messages du protocole de communication ou des signaux d'abandon, une procédure d'alarme sera déclenchée, comme ci-après décrit. Selon les évènements détectés par le contrôleur d'accès réseau 218, les transitions d'états ci-après décrites ainsi que les éventuelles actions associées peuvent être mises en oeuvre lors de l'exécution du protocole I)TCP : la requête, par la pile logicielle DTCP s'exécutant sur le CPU 203, au contrôleur d'accès réseau 218, d'envoi d'un message 001 de commande CHALLENGE est considérée comme un message sortant prévu par le protocole de communication et provoque la transition de l'état 300 vers l'état 302 décrit ultérieurement ; les autres messages sortants AKE (par exemple le message 004 de réponse CHALLENGE, le message 007 de commande RESPONSE ou le message 006 de réponse RESPONSE) ne peuvent pas être émis dans l'état 300 lors de l'exécution normale du protocole DTCP. Cependant, de tels messages peuvent être émis lors d'intrusions menées par des pirates informatiques. Ainsi, et afin d'éviter tout détournement des données transmises, ces messages sortants AKE sont considérés comme des messages sortants non prévus par le protocole de communication (seconde vérification d'intégrité négative) et provoquent la transition vers l'état 303 (étape de déclenchement d'une procédure d'alarme) décrit ultérieurement. Par ailleurs, lors de l'exécution normale de la pile logicielle DTCP, aucune notification d'abandon n'est émise dans l'état 300. Cependant, lorsqu'une telle notification d'abandon (notification d'abandon ne correspondant pas à un traitement donné selon le protocole de communication) est émise dans l'état 300 (seconde vérification d'intégrité négative), elle déclenche le passage de l'état 300 vers l'état 303 ; vu du dispositif récepteur 200, aucun message entrant reçu provenant du réseau de communication 220 n'est considéré comme pertinent dans l'état 300. Cependant, vu du dispositif source 225, le message 001 de commande CHALLENGE reçu par le dispositif source 225 en provenance du réseau 220 est considéré pertinent . Il déclenche le passage à l'état 301 (étape de réception), ainsi que le lancement (déclenchement) d'une temporisation dont la valeur initiale est égale à une valeur maximale autorisée pour le traitement de la commande reçue (par exemple la durée de traitement to,) par la pile logicielle DTCP. La valeur initiale peut par exemple être choisie élevée de façon à exclure tout déclenchement de fausses alarmes, notamment dans en cas de charge importante du système. Cependant, il est également préférable d'avoir une valeur initiale qui soit relativement faible afin de garantir la détection d'intrusions au sein des dispositifs récepteur 200 et/ou source 225 par des pirates informatiques. Une telle détection peut par exemple résulter de l'interruption du flux normal de données du logiciel d'implémentation à cause de la présence de points d'arrêt d'un débogueur (par exemple pour exécuter le logiciel d'implémentation pas à pas). On peut par exemple choisir une valeur initiale égale à une seconde ; vu du dispositif source 225 ou du dispositif récepteur 200, les messages AKE entrants considérés comme non pertinents sont par exemple ignorés, c'est-à-dire qu'ils ne feront pas l'objet d'une surveillance temporelle de leur traitement associé et seront simplement transmis au logiciel d'implémentation du protocole DTCP. Ainsi, le détecteur d'intrusions du contrôleur d'accès réseau 218 reste dans l'état 300. Dans l'état 301 (nommé ATTENTE MESSAGE SORTANT ), selon les évènements détectés par le contrôleur d'accès réseau 218, les transitions d'états ci-après décrites ainsi que les éventuelles actions associées peuvent être mises en oeuvre lors de l'exécution du protocole DTCP : lorsque le logiciel d'implémentation du protocole DTCP délivre un signal d'abandon (encore appelé indication d'abandon), une transition vers l'état 300 ainsi qu'une vérification d'intégrité (première vérification d'intégrité) d'un ensemble d'instructions du logiciel d'implémentation du protocole DTCP (mises en oeuvre par le CPU 203) sont déclenchées. Dans le mode de réalisation particulier de l'invention, la vérification d'intégrité (première vérification d'intégrité) est exécutée par le calculateur 230 de sommes de contrôle capable de déclencher l'alarme de l'unité d'alarme 231 en cas d'intrusion. Un tel signal d'abandon peut notamment permettre au logiciel d'implémentation du protocole DTCP de signaler une fin anormale de la phase AKE lorsque aucun message sortant supplémentaire n'est envoyé conformément au spécifications du protocole DTCP. Le signal d'abandon peut par exemple être émis lorsque le dispositif récepteur 200 (respectivement le dispositif source 225) reçoit un 5 10 15 20 25 30 '28 message de commande CHALLENGE 003 (respectivement un message 001 de commande CHALLENGE) avec un certificat non valide ou révoqué, ou un message 005 de commande RESPONSE (respectivement un message 007 de commande RESPONSE) possédant une signature erronée. La délivrance d'un signal d'abandon est relativement rare, et permet ainsi de minimiser l'impact d'une vérification d'intégrité (première vérification d'intégrité) sur la réactivité et les performances globales du dispositif récepteur 200. En effet, une telle vérification d'intégrité requiert une utilisation importante de bande passante sur le bus 202 notamment à cause des nombreux accès direct à la mémoire DMA (pour en anglais Direct Memory Access ) du calculateur 230 de sommes de contrôles (étape d'obtention du contenu du ou des blocs mémoires). En particulier, les contraintes temporelles de communications avec le dispositif AKE pair ( peer en anglais) n'entre pas en considération puisque dans tous les cas la phase AKE est abandonnée sans communication supplémentaire. Ainsi, la vérification d'intégrité permet notamment de défendre le système contre les diverses intrusions des pirates informatiques qui, au travers de modifications du code du logiciel d'implémentation du protocole DTCP, essaient de détourner la fonction première du signal d"abandon pour contourner le mécanisme de vérification de la temporisation ; une transition vers l'état 300, sans aucune action associée, peut avoir lieu lorsque la fin de l'exécution de la phase AKE est détectée. Une transition vers l'état 300 est par exemple réalisée lorsque le contrôleur d'accès réseau 218 du dispositif récepteur 200 détecte un message sortant 010 cle réponse EXCHANGE_KEY ; l'envoi d'un message sortant final par le logiciel d'implémentation du protocole DTCP termine avec succès le traitement du message d'entrée correspondant. Il déclenche ainsi une transition vers l'état 302 et une annulation de la temporisation lancée préalablement à l'entrée dans l'état 301. Le message 003 de commande CHALLENGE émis en réponse au traitement du message entrant 001 de commande CHALLENGE par le dispositif source 225, ainsi que le message entrant 007 de commande RESPONSE 200 émis après le traitement du message entrant 005 de commande RESPONSE par le dispositif récepteur 200 sont par exemple des messages sortants finaux ; les messages entrants, ainsi que les messages intermédiaires sortants détectés par le contrôleur d'accès réseau 218 sont ignorés, comme précédemment décrit. Ainsi, le détecteur d'intrusions du contrôleur d'accès réseau 218 reste dans l'état 301. Le message sortant 002 de réponse CHALLENGE (respectivement le message sortant 006 de réponse RESPONSE) est par exemple considéré comme un message sortant intermédiaire pour le dispositif source 225 (respectivement le dispositif récepteur 200) lors du traitement du message 001 de commande CHALLENGE (respectivement du message entrant 005 de commande RESPONSE). Dans le mode de réalisation particulier de l'invention, la temporisation (déclenchée préalablement à l'entrée dans l'état 301) est arrêtée puis relancée après une réinitialisation de sa valeur initiale (par exemple une seconde) à chaque détection d'un message sortant intermédiaire . On peut ainsi prévenir le risque de déclenchement de fausses alarmes du, par exemple, à un délai de transmission anormalement élevé sur le réseau 220 (conduisant à la retransmission du message) ; à l'expiration de la temporisation déclenchée préalablement à l'entrée dans l'état 301, ou à la réception d'un message sortant non prévu par le protocole de communication, on considère qu'une intrusion d'un pirate informatique est en cours (troisième vérification d'intégrité négative), l'exécution du logiciel d'implémentation du protocole DTCP (qui traite le message entrant AKE en question) étant alors suspendue ou anormalement réalisée. Une transition vers l'état 303 est réalisée (étape de déclenchement d'une procédure d'alarme). On rappelle qu'un message sortant AKE est considéré comme non prévu par le protocole de communication lorsque ce dernier n'est ni un message sortant intermédiaire ni un message sortant final tels que décrits précédemment. Dans l'état 302 (nommé ATTENTE MESSAGE ENTRANT ), les transitions d'états ci-après décrites ainsi que leurs éventuelles actions associées peuvent être mises en oeuvre lors de l'exécution du protocole DTCP, selon les évènements détectés par le contrôleur d'accès réseau 218 : 5 10 15 20 25 30 lorsque le logiciel d'implémentation du protocole DTCP délivre un signal d'abandon, une transition vers l'état 300 ainsi qu'une vérification d'intégrité (correspondant à la première vérification d'intégrité) du système sont déclenchées de manière similaire au traitement du signal d'abandon de l'état 301. Dans ce cas, le signal d'abandon permet notamment au logiciel d'implémentation du protocole DTCP de signaler une fin anormale de la phase AKE lorsque aucune réponse du dispositif pair de communication n'est reçue avant l'expiration de la temporisation (déterminée conformément aux spécifications du protocole DTCP), ou lorsque la connexion mise en oeuvre lors de la phase AKE est interrompue (en fonction de la nature du réseau 220, de la réinitialisation des bus IEEE 1394 ou de la fermeture de la connexion TCP/IP dédiée à la procédure AKE) ; une transition vers l'état 300, sans action associée, est exécutée lorsque la fin de la phase AKE est détectée, par exemple lorsque le contrôleur d'accès réseau 218 du dispositif source 225 détecte un message entrant 010 de réponse EXCHANGE_KEY ; la réception d'un message entrant pertinent en provenance du réseau 220 déclenche une transition vers l'état 301 ainsi que le lancement d'une temporisation (de manière similaire au traitement de l'action effectuée dans l'état 300). Le message 003 de commande CHALLENGE, le message 005 de commande RESPONSE et le message 009 de commande EXCHANGE_KEY (respectivement le message 004 de commande CHALLENGE et le message 007 de commande RESPONSE) sont par exemple considérés pertinents par le dispositif récepteur 200 (respectivement par le dispositif source 225) ; les messages entrants AKE non pertinents (par exemple le message 002 de réponse CHALLENGE et le message 008 de réponse RESPONSE pour le dispositif récepteur 200, et le message 006 de réponse RESPONSE pour le dispositif source 225) ainsi que les messages sortants AKE (par exemple le renvoi d'un message par le logiciel d'implémentation du protocole DTCP pour lequel aucun accusé de réception n'a été reçu à temps) sont ignorés, comme précédemment décrit. Ainsi, le détecteur d'intrusions du contrôleur d'accès réseau 218 reste dans l'état 302. Les messages entrants non pertinents sont caractérisés par le fait qu'ils ne déclenchent pas de traitement particulier du logiciel d'implémentation du protocole DTCP (mettant en oeuvre des valeurs secrètes et aboutissant à l'envoi d'un message sortant AKE). L'état 303 (encore appelé ALARME ) est par exemple atteint lorsqu'une intrusion a été détectée, soit à cause d'un temps d"exécution anormale soit à cause d'évènements non prévus par le protocole de communication délivrés par le logiciel d'implémentation du protocole DTCP exécuté par le CPU 203, tel que précédemment décrit. Lorsque cet état 303 est atteint, le contrôleur d'accès réseau 218 peut déclencher l'alarme de l'unité d'alarme 231. La machine d'états finis à quatre états précédemment décrite constitue une manière simple et efficace d'implémenter l'invention dans laquelle le détecteur d'intrusions du contrôleur d'accès réseau 218 n'a, par exemple, pas besoin de faire de distinction entre le dispositif source 225 ,et le dispositif récepteur 200 mettant en oeuvre l'invention. La table suivante résume les états de transition de la machine d'états finis précédemment décrites en fonction de l'état actuel et de l'évènement détecté. Un telle table peut être présente dans le contrôleur d'accès réseau 218 de manière à mettre en oeuvre l'invention. Cette table décrit les différents messages utilisés lors de l'exécution du protocole DTCP et quelle est leur succession. Le contrôleur d'accès réseau 218 doit posséder ce type d'informations de manière à analyser l'exécution des différentes phases de traitements liés à la mise en oeuvre du protocole DTCP. Tous les messages sortants qui ne sont pas répertoriés prévu , intermédiaire ou final sont considérés non prévus par le protocole de communication (à l'exception des messages de commande et de réponse AKE_STATUS et AKE_CANCEL, non détaillés dans la table ci-après pour des raisons de clarté, qui peuvent être ignorés par le détecteur d'intrusions du contrôleur d'accès réseau 218, comme précédemment décrit. Par ailleurs, on rappelle que tous les messages qui ne sont pas répertoriés pertinents sont considérés non pertinents .30 Etat Etat visé Démarrage 300 Attente message Attente message Alarme 303 actuel sortant 301 entrant 302 b Démarrage • Message entrant • Message entrant • Message sortant • Message sortant 300 non pertinent pertinent: prévu: commande non prévu commande CHALLENGE 001 •Signal d'abandon CHALLENGE 001 Attente • Signal d'abandon • Message sortant Message sortant • Temporisation message Phase AKE intermédiaire: final: expirée (1 s après sortant 301 complète: réponse 002 commande 003 le lancement) message sortant CHALLENGE, CHALLENGE, • Message sortant de réponse 010 réponses 006 ou commandes 005 ou non prévu EXCHANGE KEY 008 RESPONSE 007 RESPONSE, • Tout message commande 009 entrant EXCHANGE KEY ù Attente • Signal d'abandon • Message entrant • Message entrant _ message .phase AKE pertinent : non pertinent entrant 302 complète: commande 003 • Tout message message entrant CHALLENGE, sortant (considéré de réponse 010 rénse 004 comme un nouvel EXCHANGE KEY p envoi) CHAALL LLENNG GE, C commandes 005 ou 007 RESPONSE, commande 009 EXCHANGE KEY Alarme 303 ù _ _ • (Reste de manière permanente dans cet état) Bien entendu, des machines d'états finis plus sophistiquées mettant en oeuvre un nombre plus élevé d'états capables de détecter notamment le mauvais séquençage de messages (par exemple un dispositif récepteur envoyant un message 007 de commande RESPONSE avant d'envoyer un message 004 de réponse CHALLENGE) sont également envisageables. De telles machines d'états finis peuvent être réalisées de manière évidente par l'Homme du Métier. Par exemple, l'état 301 ATTENTE MESSAGE SORTANT décrit à la figure 4 peut être divisé en plusieurs états Traitement du message 001 de commande CHALLENGE du dispositif source 225, Traitement du message 003 de commande CHALLENGE du dispositif récepteur 200, Traitement du message 004 de réponse CHALLENGE du dispositif source 225, Traitement du message 005 de commande RESPONSE du dispositif récepteur 200, Traitement du message 007 de commande RESPONSE du dispositif source 225, ,et Traitement du message 009 de commande EXHANGE_KEY du dispositif récepteur 200. De manière similaire, l'état 302 ATTENTE MESSAGE ENTRANT peut être divisé. Dans ce cas, la valeur du retard de la temporisation déclenchée lors de la transition des états équivalents 300 ou 302 vers l'état. équivalent 301 peut être fonction du traitement appliqué dans l'état visé. Par exemple, lorsque le traitement requiert l'envoi de messages sortants intermédiaires , par exemple dans le cas du traitement du message 001 de commande CHALLENGE et du message 007 de commande RESPONSE par le dispositif source 225, ou du traitement du message 005 de commande RESPONSE par le dispositif récepteur 200, la durée du traitement peut être établie à deux secondes, bien qu'il ne reste qu'une seconde pour effectuer le traitement des messages entrants restants. Ainsi, l'invention permet de détecter et neutraliser toutes les tentatives d'intrusions du code d'un logiciel d'implémentation d'un protocole de DRM en proposant une solution simple de mise en oeuvre qui ne perturbe pas l'exécution du protocole de DRM. Par ailleurs, le calcul des sommes de contrôle n'est effectué qu'à la réception d'une notification d'abandon, minimisant ainsi l'utilisation des ressources des dispositifs mettant en oeuvre l'invention. Ainsi, l'invention améliore grandement la sécurité d'exécution des protocoles de DRM, par voie de conséquence les données protégées contre la copie transmises.20 REVENDICATIONS 1. Procédé de surveillance d'exécution d'un protocole de communication dans un dispositif (200 ; 225) comprenant un module de traitement de données (203) exécutant ledit protocole de communication et un module d'interface (219) permettant d'interfacer ledit module de traitement de données avec un réseau de communication (220), ledit protocole de communication définissant des messages qui sont reçus du réseau de communication par ledit module de traitement de données et des messages qui sont émis par ledit module de traitement de données vers le réseau de communication, lesdits messages marquant respectivement des débuts et fins de traitements prédéterminés, caractérisé en ce que ledit module d'interface effectue les étapes suivantes : - réception du réseau de communication d'un message, dit message entrant, destiné à être traité par le module de traitement de données selon le protocole de communication et marquant le début d'un traitement donné ; - dans le cas d'une réception d'indication d'abandon dudit traitement donné par le module de traitement de données, vérification d'intégrité, dite première vérification d'intégrité, d'un ensemble d'instructions mises en oeuvre par le module de traitement de données pour l'exécution dudit protocole de communication. 2. Procédé selon la revendication 1, caractérisé en ce que ladite première vérification d'intégrité comprend une étape de vérification d'intégrité d'au moins un bloc d'une mémoire (204 ; 206) comprise dans ledit dispositif (200 ; 225) et dans lequel est stocké ledit ensemble d'instructions. 3. Procédé selon la revendication 2, caractérisé en ce que ladite vérification d'intégrité d'au moins un bloc d'une mémoire (204 ; 206) comprend une étape d'obtention de l'ensemble d'instructions stocké dans ledit ou lesdits bloc(s) d'une mémoire, selon un mécanisme d'accès direct à la mémoire. 4. Procédé selon l'une quelconque des revendications 2 et 3, caractérisé en ce que ladite vérification d'intégrité d'au moins un bloc d'une mémoire (204 ; 206) comprend les étapes suivantes : - obtention d'une valeur résultant d'une fonction prédéterminée appliquée à l'ensemble d'instructions stocké dans ledit ou lesdits bloc(s) d'une mémoire ;comparaison de ladite valeur obtenue avec une valeur prédéterminée ; et en ce que la vérification d'intégrité est négative dans le cas où la valeur obtenue diffère de la valeur prédéterminée. 5. Procédé selon l'une quelconque des revendications 1 à 4, caractérisé en ce qu'il comprend une étape de vérification d'intégrité, dite seconde vérification d'intégrité, d'un ensemble d'instructions mises en ceuvre par le module de traitement de données (203) pour l'exécution dudit protocole de communication, ladite seconde vérification d'intégrité étant déclenchée à l'initialisation du protocole de communication, et en ce que la seconde vérification d'intégrité est négative dans le cas d'une détection d'un message émis par le module de traitement de données à destination du réseau de communication (220) correspondant à un message non prévu par le protocole de communication. 6. Procédé selon l'une quelconque des revendications 1 à 4, caractérisé en ce qu'il comprend une étape de vérification d'intégrité, dite seconde vérification d'intégrité, d'un ensemble d'instructions mises en ceuvre par le module de traitement de données (203) pour l'exécution dudit protocole de communication, ladite seconde vérification d'intégrité étant déclenchée à l'initialisation du protocole de communication, et en ce que la seconde vérification d'intégrité est négative dans le cas d'une réception d'une indication d'abandon d'exécution du protocole de communication par le module de traitement de données (203) ne correspondant pas à un traitement donné. 7. Procédé selon l'une quelconque des revendications 1 à 6, caractérisé en ce qu'il comprend, sur réception du message entrant, les étapes suivantes : - déclenchement d'une temporisation associée à une durée maximale autorisée pour le traitement du message entrant par le module de traitement de données (203) ; - détermination si un message à émettre par le module de traitement de données (203), dit message sortant, fait suite, selon le protocole de communication, au traitement du message entrant et marquant la fin dudit traitement donné. 8. Procédé selon la revendication 7, caractérisé en ce qu'il comprend une étape de vérification d'intégrité, dite troisième vérification d'intégrité, d'un ensemble d'instructions mises en oeuvre par le module de traitement de données (203) pourl'exécution dudit protocole de communication, ladite troisième vérification d'intégrité comprenant une étape d'attente de détection d'un message émis par le module de traitement de données (203) à destination du réseau de communication correspondant au message sortant. 9. Procédé selon la revendication 8ä caractérisé en ce que la troisième vérification d'intégrité est négative dans le cas où la temporisation expire sans qu'un message émis par le module de traitement de données (203) à destination du réseau de communication (220) correspondant au message sortant ne soit détecté. 10. Procédé selon l'une quelconque des revendications 1 à 9, caractérisé en ce qu'en cas de première, deuxième ou troisième vérification d'intégrité négative, il comprend une étape de déclenchement d'une procédure d'alarme visant à modifier le comportement dudit dispositif (200 ; 225) vis-à-vis du protocole de communication. 11. Procédé selon la revendication 10, caractérisé en ce que le protocole de communication correspond à un protocole de protection des droits associés à un contenu comprenant une phase d'encryptage et/ou de décryptage dudit contenu et en ce que ladite procédure d'alarme comprend une étape de modification d'au moins une clé servant à l'encryptage et/ou au décryptage dudit contenu. 12. Produit programme d'ordinateur téléchargeable depuis un réseau de communication et/ou enregistré sur un support lisible par ordinateur et/ou exécutable par un processeur, caractérisé en ce qu'il comprend des instructions de code de programme pour l'exécution des étapes du procédé selon au moins une des revendications 1 à 11, lorsque ledit programme est exécuté sur un ordinateur. 13. Moyen de stockage, éventuellement totalement ou partiellement amovible, lisible par un ordinateur, stockant un jeu d'instructions exécutables par ledit ordinateur pour mettre en oeuvre le procédé selon au moins une des revendications 1 à 11. 14. Dispositif comprenant un module de traitement de données (203) exécutant un protocole de communication et un module d'interface (219) permettant d'interfacer ledit module de traitement de données (203) avec un réseau de communication (220), ledit protocole de communication définissant des messages qui sont reçus du réseau de communication (220) par ledit module de traitement de données (203) et des messages qui sont émis par ledit module de traitement de données (203) vers le réseau decommunication (220), lesdits messages marquant respectivement des débuts et fins de traitements prédéterminés, caractérisé en ce que ledit module d'interface (219) comprend : - des moyens de réception du réseau de communication d'un message, dit message entrant, destiné à être traité par ledit module de traitement de données selon le protocole de communication et marquant le début d'un traitement donné ; - des premiers moyens de détection d'une réception d'indication d'abandon dudit traitement donné par le module de traitement de données ; - des premiers moyens de vérification d'intégrité d'un ensemble d'instructions mises en oeuvre par le module de traitement de données pour l'exécution dudit protocole de communication, lesdits premiers moyens de vérification d'intégrité étant activés dans 1,e cas d'une réception d'indication d'abandon dudit traitement donné par lesdits premiers moyens de détection. 15. Dispositif selon la revendication 14, caractérisé en ce que lesdits premiers moyens de vérification d'intégrité comprennent des moyens de vérification d'intégrité (230) d'au moins un bloc d'une mémoire (204 ; 206) comprise dans ledit dispositif et dans lequel est stocké ledit ensemble d'instructions. 16. Dispositif selon la revendication 15, caractérisé en ce que lesdits moyens de vérification d'intégrité (230) d'au moins un bloc d'une mémoire (204 ; 206) comprennent des moyens d'obtention de l'ensemble d'instructions stocké dans ledit ou lesdits bloc(s) d'une mémoire, selon un mécanisme d'accès direct à la mémoire. 17. Dispositif selon l'une quelconque des revendications 15 et 16, caractérisé en ce que lesdits moyens de vérification d'intégrité (230) d'au moins un bloc d'une mémoire comprennent : des moyens d'obtention d'une valeur résultant d'une fonction prédéterminée appliquée à l'ensemble d'instructions stocké clans ledit ou lesdits bloc(s) d'une mémoire (204 ; 206) ; - des moyens de comparaison de ladite valeur obtenue avec une valeur prédéterminée ;- des premiers moyens de décision permettant de décider qu'une première vérification est négative dans le cas où la valeur obtenue diffère de la valeur prédéterminée. 18. Dispositif selon l'une quelconque des revendications 14 à 17 caractérisée en ce qu'il comprend des moyens de vérification d'intégrité, dits seconds moyens de vérification d'intégrité, d'un ensemble d'instructions mises en oeuvre par le module de traitement de données pour l'exécution dudit protocole de communication, lesdits seconds moyens de vérification d'intégrité étant déclenchés à l'initialisation du protocole de communication ; et en ce que lesdits seconds moyens de vérification d'intégrité comprennent : - des seconds moyens de détection d'un message émis par le module de traitement de données à destination du réseau de communication correspondant à un message non prévu par le protocole de communication ; - des seconds moyens de décision permettant de décider qu'une seconde vérification est négative dans le cas d'une détection par lesdits seconds moyens de détection d'un message émis par le module de traitement de données à destination du réseau de communication correspondant à un message non prévu par le protocole de communication. 19. Dispositif selon l'une quelconque des revendications 14 à 17 caractérisée en ce qu'il comprend des moyens de vérification d'intégrité, dits seconds moyens de vérification d'intégrité, d'un ensemble d'instructions mises en oeuvre par le module de traitement de données pour l'exécution dudit protocole de communication, lesdits seconds moyens de vérification étant déclenchés à l'initialisation du protocole de communication ; et en ce que lesdits seconds moyens de vérification d'intégrité comprennent : - des seconds moyens de détection d'une réception d'une indication d'abandon d'exécution du protocole de communication ne correspondant pas à un traitement donné ; -. des seconds moyens de décision permettant de décider qu'une seconde vérification est négative dans le cas d'une réception d'une indication d'abandond'exécution du protocole de communication par lesdits seconds moyens de détection ne correspondant pas à un traitement donné. 20. Dispositif selon l'une quelconque des revendications 14 à 19, caractérisé en ce qu'il comprend : des moyens de déclenchement d'une temporisation associée à une durée maximale autorisée pour le traitement du message entrant par le module de traitement de données ; des moyens de détermination si un message à émettre par le module de traitement de données, dit message sortant, fait suite, selon le protocole de communication, au traitement d[u message entrant et marquant la fin dudit traitement donné. Dispositif selon la revendication 20, caractérisé en ce qu'il comprend : des moyens de vérification d'intégrité, dits troisièmes moyens de vérification d'intégrité, d'un ensemble d'instructions mises en oeuvre par le module de traitement de données pour l'exécution dudit protocole de communication ; des troisièmes moyens de détection d'un message émis par le module de traitement de données à destination du réseau de communication correspondant au message sortant. Dispositif selon la revendication 21, caractérisé en ce lesdits troisièmes moyens 20 de vérification d'intégrité comprennent : - des moyens de détection de l'expiration de ladite temporisation sans qu'un message émis par ledit module de traitement de données (203) à destination du réseau de communication correspondant au message sortant ne soit détecté ; des troisièmes moyens de décision permettant de décider qu'une troisième 25 vérification d'intégrité est négative dans le cas où l'expiration de la temporisation est détectée par lesdits moyens détection sans qu'un message émis par le module de traitement d,e données (203) à destination du réseau de communication correspondant au message sortant ne soit détecté. 23. Dispositif selon l'une quelconque des revendications 14 à 22, caractérisé en ce 30 qu'il comprend des moyens de déclenchement d'une procédure d'alarme visant à modifier le comportement dudit dispositif vis-à-vis du protocole de communication, - - 21. - -22.lesdits moyens de déclenchement étant activés en cas de vérification d'intégrité négative par lesdits premiers, seconds ou troisièmes moyens de vérification d'intégrité. 24. Dispositif selon la revendication 23, caractérisé en ce qu'il comprend : des moyens d'encryptage et/ou de décryptage d'un contenu ; - des moyens de modification d'au moins une clé servant à l'encryptage et/ou au décryptage dudit contenu, lesdits moyens de modification étant activés lors de ladite procédure d'alarme.