Brevet FR2959899A1 — publié le 20111111

MÉTHODE DE TRANSMISSION DE PAQUETS SÉCURISÉE POUR SYSTÈME DE TÉLÉCOMMUNICATION SANS FIL DESCRIPTION DOMAINE TECHNIQUE La présente invention concerne le domaine des systèmes de télécommunication sans fil et plus particulièrement celui des systèmes de télécommunication sécurisés. ÉTAT DE LA TECHNIQUE ANTÉRIEURE Le protocole HARQ (Hybrid Automatic Repeat reQuest) est un mécanisme bien connu de requête de retransmission permettant de combattre les évanouissements sur un canal (channel fading) entre un émetteur et un récepteur. Ce protocole est notamment utilisé dans les systèmes 3GPP mettant en ouvre la technologie HSPA (High Speed Packet Access) et est envisagé dans les systèmes mobiles de quatrième génération, dans le cadre du projet LTE (Long Te= Evolution). Il existe actuellement plusieurs versions de protocole HARQ. La version la plus simple, dénommée HARQ Type I, combine les avantages de la correction d'erreurs ou FEC (Forward Error Correction) et ceux du protocole ARQ classique en encodant un bloc de données d'information avec un code de détection d'erreurs (CRC) et un code de correction d'erreurs (ECC). S'il est détecté un nombre d'erreurs telles que le code ECC ne puisse les corriger, une requête de retransmission du bloc est envoyée à l'émetteur et une seconde tentative de transmission a lieu. En pratique le bloc erroné n'est pas supprimé mais est stocké dans un buffer pour être combiné (Chase combining) avec le bloc reçu à la seconde tentative. Le résultat de la combinaison est soumis au décodeur. Une seconde version de protocole HARQ, dénommée HARQ Type II ou IR HARQ (Incremental Redundancy HARQ) permet d'éviter des transmissions redondantes. Selon cette version, lors de la première transmission du bloc, le code est poinçonné de telle sorte que peu de symboles de redondance soient transmis. Si le bloc reçu lors de la première transmission se révèle erroné et ne peut être corrigé à l'aide des symboles de redondance disponibles, des symboles de redondance supplémentaires, éliminés lors du poinçonnage, sont transmis en réponse à la première requête de retransmission. Le processus peut se répéter, les symboles de redondance étant transmis de manière incrémentale, au fur et à mesure des demandes de retransmission, tant que le bloc erroné ne peut être corrigé. Le protocole HARQ ne présente en lui-même aucune mesure permettant de sécuriser les données transmises vis-à-vis d'une éventuelle interception par un récepteur espion. Diverses méthodes de chiffrement (ou d'encryptage) faisant appel à une clé publique ou bien à une clé secrète sont connues de l'état de la technique. Toutefois, ce chiffrement est généralement appliqué à un niveau applicatif, en amont de la mise en oeuvre du protocole HARQ. Or, ce protocole, qu'il soit de type I ou II, accroît, par le biais des retransmissions successives, la redondance des données transmises et par conséquent la probabilité que la clé utilisée pour le déchiffrement puisse être craquée. Il a été notamment proposé dans l'article de X. Tang et al. intitulé « On the throughput of secure hybrid-ARQ protocole for gaussian block-fading channels » publié dans IEEE Trans. on Information Theory, Vol. 5, N° 4, Avril 2009, pp. 1575-1591, d'utiliser une famille de codes de Wyner pour chiffrer les paquets à transmettre sur une liaison utilisant un protocole HARQ de type II. Cette famille de codes présente l'avantage d'être compatible avec différents taux de poinçonnage, autrement dit avec la transmission d'incréments de redondance. La méthode de transmission sécurisée précitée suppose toutefois l'envoi d'une quantité importante d'informations auxiliaires au récepteur pour décoder les paquets transmis. En outre, elle est relativement complexe à mettre en oeuvre, de sorte qu'elle se prête mal à des applications de type « temps-réel » et ne permet pas de respecter des contraintes de faible latence. Enfin, elle ne fonctionne correctement que dans la mesure où la qualité du canal entre l'émetteur et le récepteur est meilleure que celle entre l'émetteur et un récepteur espion. De manière générale, le but de la présente invention est de proposer une méthode de transmission sécurisée de paquets sur une liaison sans fil entre un émetteur et un récepteur qui ne présente pas les inconvénients de l'état de la technique. En particulier, un but de la présente invention est de proposer une méthode de transmission de paquets sécurisée utilisant un protocole HARQ de type II, qui soit simple à mettre en oeuvre, compatible avec des applications de type « temps-réel », tout en présentant un niveau de confidentialité très élevé. EXPOSÉ DE L'INVENTION La présente invention est définie par une méthode de transmission sécurisée de paquets de données sur une liaison sans fil entre un émetteur et un récepteur, selon laquelle: - l'émetteur transmet sur ladite liaison une première version d'un paquet de données ne permettant pas le décodage dudit paquet par le décodeur; - suite à l'échec du décodage de la première version du paquet, le récepteur génère une première paire de clés constituée d'une première clé privée et d'une première clé publique correspondante et transmet la première clé publique à l'émetteur ; - l'émetteur transmet sur ladite liaison une 25 seconde version dudit paquet, chiffrée au moyen de la première clé publique ; - le récepteur déchiffre la seconde version du paquet à l'aide de la première clé privée, combine ladite première version et la seconde version, pour 30 obtenir une première version combinée dudit paquet, et effectue un décodage de la première version combinée ainsi obtenue. Avantageusement, si le décodage de la première version combinée échoue, le récepteur génère une seconde paire de clés constituée d'une seconde clé privée et d'une seconde clé publique correspondante ; l'émetteur transmet sur ladite liaison une troisième version dudit paquet, après l'avoir chiffrée au moyen de la seconde clé publique ; le récepteur déchiffre la troisième version du paquet à l'aide de la seconde clé privée, combine la troisième version ainsi déchiffrée avec au moins la première version ou la seconde version déchiffrée pour obtenir une seconde version combinée dudit paquet, et effectue un décodage de la seconde version combinée ainsi obtenue. La première version du paquet peut notamment être obtenue par codage de ce paquet au moyen d'un code de correction d'erreurs, suivi d'un premier poinçonnage du paquet ainsi encodé, avec un taux de décodage excédant les capacités de correction dudit code. Selon une variante, la seconde version du paquet comprend des symboles ayant été éliminés par le premier poinçonnage du paquet encodé. La seconde version du paquet peut être obtenue par exemple au moyen d'un second poinçonnage du paquet encodé, la troisième version du paquet comprenant alors des symboles ayant été poinçonnés lors du premier et/ou du second poinçonnage(s). Le chiffrement de la seconde version du paquet au moyen de la première clé publique est typiquement réalisé après le second poinçonnage. Le codage du paquet est par exemple de type systématique. Dans ce cas, selon un exemple de réalisation, le premier poinçonnage peut éliminer les symboles systématiques du paquet encodé. De préférence, la méthode de transmission exposée ciûdessus, met en œuvre un protocole HARQ de type II. Quant à la génération des clés privées, les première et seconde clés privées sont avantageusement générées à partir d'un même germe. Ce germe subit typiquement un traitement par une fonction non-inversible, le germe ainsi traité étant utilisé comme clé privée, la clé publique correspondante étant obtenue à partir de la clé privée à l'aide de l'algorithme RSA. BRÈVE DESCRIPTION DES DESSINS 20 D'autres caractéristiques et avantages de l'invention apparaîtront à la lecture d'un mode de réalisation préférentiel de l'invention décrit en référence aux figures jointes parmi lesquelles : 25 La Fig. 1 illustre schématiquement une méthode de transmission de paquets sécurisée, selon un premier mode de réalisation de l'invention ; La Fig. 2 illustre schématiquement une méthode de transmission de paquets sécurisée selon un second mode 30 de réalisation de l'invention ; La Fig. 3 illustre schématiquement la structure d'un émetteur permettant de mettre en oeuvre la méthode de transmission de paquets sécurisée selon un mode de réalisation de l'invention. La Fig. 4 illustre schématiquement la structure d'un récepteur permettant de mettre en oeuvre la méthode de transmission de paquets sécurisée selon un mode de réalisation de l'invention. EXPOSÉ DÉTAILLÉ DE MODES DE RÉALISATION PARTICULIERS Nous considérerons dans la suite un système de télécommunication sans fil et plus particulièrement une liaison sans fil entre un émetteur et un récepteur utilisant une transmission par paquets. L'émetteur peut être un terminal mobile et le récepteur une station de base (liaison montante). Alternativement, l'émetteur peut être une station de base et le récepteur un terminal mobile (liaison descendante). Nous supposerons également que les paquets transmis sont préalablement codés à l'aide d'un code de correction d'erreur ECC (Error Correcting Code) et, le cas échéant, un code de contrôle de parité CRC (Cyclic Redundancy Check). Dans tous les cas, le récepteur peut déterminer si un paquet reçu est intègre ou erroné. La méthode de transmission selon l'invention met en oeuvre une pluralité de transmissions successives d'un paquet comme illustré en Fig. 1. Plus précisément, lors d'une première étape 110, l'émetteur transmet une première version de ce paquet, 8 vl(P,), ayant pour particularité de ne pouvoir être décodée par le récepteur. Par version d'un paquet, on entend un sous-ensemble des symboles de ce paquet. Par exemple, si le paquet est constitué par une séquence de symboles, un paquet poinçonné, c'est-à-dire un paquet pour lequel certains symboles de la séquence ont été supprimés, sera considéré comme une version de ce paquet. Typiquement, la première version du paquet, non décodable par le récepteur, est obtenue par un codage de correction d'erreur suivi par un poinçonnage du paquet encodé, avec un taux de poinçonnage excédant les capacités de correction du code. Ainsi, par exemple, si un paquet est codé à l'aide d'un code de Reed-Solomon (n,k), le paquet codé puis poinçonné de manière à ce que s> n - k symboles soient effacés, constituera une version non décodable du paquet en question. Selon un autre exemple, si un paquet est codé à l'aide d'un turbocodeur constitué par la concaténation parallèle de plusieurs codeurs récursifs systématiques, le paquet ainsi codé dans lequel la partie systématique aura été entièrement poinçonnée constituera une version non décodable de ce paquet. Bien entendu, d'autres exemples de version non décodable d'un paquet peuvent être envisagés sans pour autant sortir du cadre de la présente invention. A l'étape 120, le récepteur effectue un décodage de la première version du paquet. Ce décodage se solde nécessairement par un échec puisque cette première version ne permet pas de reconstituer l'ensemble des symboles d'information contenus dans le paquet. Le récepteur peut néanmoins stocker cette première version dans un buffer de réception pour l'exploiter ultérieurement comme détaillé plus loin. Les échecs de décodage ont été représentés en grisé, les succès en clair. On comprendra qu'un récepteur espion qui intercepterait cette première version ne pourrait pas davantage décoder le paquet. Pour garantir un haut niveau de confidentialité, on utilisera avantageusement un fort taux de poinçonnage au niveau de l'émetteur. Suite à l'échec du décodage, le récepteur renvoie un accusé de réception négatif, NACK, codé sur un bit. Le récepteur génère également une première paire de clés (prkl,pu4) constituée d'une première clé privée, prkç, et d'une première clé publique correspondante, puk,, de manière connue en soi, par exemple au moyen de l'algorithme RSA. La première clé publique, pukl, est envoyée à l'émetteur avec l'accusé de réception négatif, NACK. Sur réception du signal NACK, l'émetteur transmet, à l'étape 130, une seconde version du paquet, v2Q ), après l'avoir chiffrée à l'aide de la première clé publique, puk. La seconde version du paquet est obtenue par un second poinçonnage du paquet. Elle est avantageusement constituée de symboles éliminés par la première étape de poinçonnage. Cette seconde version peut également comprendre en sus, certains des symboles déjà présents dans la première version du paquet. A l'étape 140, le récepteur reçoit la seconde version du paquet chiffrée par la première clé publique, pu4, et la déchiffre à l'aide de la première clé privée, prk,. Il combine ensuite les première et seconde versions du paquet pour obtenir une première version combinée de ce paquet. Lorsque la seconde version est uniquement constituée de symboles éliminés par la première étape de poinçonnage, la combinaison consiste à insérer en lieu et place des symboles éliminés, les symboles de la seconde version. Il s'agit alors à proprement parler d'un dépoinçonnage du paquet. Lorsque certains symboles de la seconde version étaient déjà présents dans la première version, la combinaison est de type Chase (Chase Combining), autrement dit la combinaison peut être alors une somme des valeurs souples des symboles présents dans les deux versions. De manière générale, on comprendra que la combinaison pourra à la fois comprendre une étape de dépoinçonnage (insertion ou concaténation de symboles éliminés) et une étape de sommation de valeurs souples pour les symboles présents dans les deux versions. Le récepteur effectue ensuite une seconde tentative 25 de décodage de la première version combinée. En cas de succès, c'est-à-dire en absence d'erreur, le récepteur renvoie à l'émetteur un accusé de réception positif, ACK. L'émetteur est alors prêt à transmettre un nouveau paquet. 30 En cas de nouvel échec, le processus précédent est itéré, comme illustré en Fig. 1, autrement dit une seconde paire de clés est générée, constituée d'une seconde clé privée, prk2, et d'une seconde clé publique correspondante, puk2. Le récepteur renvoie à l'émetteur un accusé de réception négatif, NACK, ainsi que la seconde clé publique, puk2. Sur réception du signal, NACK, l'émetteur transmet en 150 une troisième version du paquet, v3Q), obtenue au moyen d'un troisième poinçonnage du paquet. La troisième version est avantageusement constituée de symboles éliminés par la première et/ou la seconde étape de poinçonnage. Enfin, cette troisième version, comme la précédente, n'est pas transmise en clair mais est préalablement chiffrée, cette fois au moyen de la seconde clé publique, puk2. Le récepteur déchiffre en 160 cette troisième version, combine la version ainsi déchiffrée à la première et/ou la seconde version stockée(s) pour obtenir une seconde version combinée, et effectue un décodage de la seconde version combinée. On notera que cette combinaison est effectuée selon le même principe que précédemment. Le processus de retransmission se poursuit jusqu'à ce que l'émetteur reçoive un accusé de réception positif, ACK, ou qu'un nombre maximal autorisé de versions successives du même paquet aient été transmises, ou encore que tous les symboles du paquet aient déjà été transmis. On comprendra que le changement de clé de chiffrement à chaque transmission d'une nouvelle version du paquet garantit un très haut degré de confidentialité sur la liaison. 12 Selon une variante, une nouvelle clé de chiffrement peut n'être générée que toutes les Q≥2 échecs de décodage. Autrement dit, le récepteur qui ne parvient pas à décoder le paquet ne crée une nouvelle paire de clés publique et privée qu'une fois sur Q. Dès lors que l'émetteur a reçu un: acquittement de bonne réception, ACK, il peut transmettre le paquet suivant, présent dans le buffer d'émission. Ce mode de fonctionnement du protocole HARQ est connu sous le nom de stop-and-avait. Autrement dit, l'émetteur attend d'être certain que le paquet en cours est bien reçu avant de transmettre le suivant. Alternativement, la présente invention peut utiliser le mode Go-Back-N ARQ ou le mode selective repeat ARQ, de manière connue en soi. On rappelle que dans ces modes de fonctionnement l'émetteur n'attend pas d'avoir reçu un accusé de réception d'un paquet pour transmettre le paquet suivant. Plus précisément, dans le mode Go-Back-N ARQ l'émetteur utilise une fenêtre temporelle glissante ayant pour taille N paquets. La taille N définit le nombre de paquets que l'émetteur peut transmettre sans recevoir d'accusé de réception, ACK. Si l'émetteur n'a pas reçu un accusé de réception après N paquets, il reprend la transmission à partir du paquet pour lequel il n'a pas reçu d'accusé de réception, ACK. Le mode « selective repeat ARQ » diffère du précédent en ce que le récepteur transmet un accusé de réception positif, ACK, pour chaque paquet correctement décodé, même après avoir reçu un paquet erroné. Si l'émetteur reçoit un signal NACK, il retransmet le paquet erroné à la volée puis reprend sa transmission là où il l'avait interrompue. Alternativement encore, la présente invention peut utiliser un mode « N-Stop-and-Wait » de manière connue en soi. On rappelle qu'un tel mode permet d'utiliser avantageusement la latence du mode « Stop-and-Wait », entre l'émission d'un paquet et la réception de son acquittement, en envoyant de nouveaux paquets dans cet intervalle de temps. Chaque paquet est traité indépendamment des autres. Il est important de noter que les modes « Go-Back-N ARQ », « selective repeat ARQ » et « N-Stop-and-Wait » peuvent être utilisés dans le cadre de la présente 15 invention. La Fig. 2 représente une méthode de transmission par paquets sécurisée utilisant un mode de retransmission selective repeat ARQ, en prenant à 20 titre d'illustration N=4. On remarque que, dans une première étape, l'émetteur transmet des premières versions de paquets, vl(P)vl(P2)V1(P3),v1(P4) sans attendre de recevoir les accusés de réception correspondants. Les premières 25 versions vl(P),vl(P,)v1(P)vl(P4) n'étant pas décodables, le récepteur renvoie les accusés de réception négatifs NACK1,...,NACK4 à l'émetteur ainsi que les clés publiques pu ), pue, pue, pue). L'émetteur reprend alors la transmission au début 30 de la fenêtre temporelle avec la transmission des secondes versions v2(P),v2(P2)v2(P3),,v2(P4), codées respectivement à l'aide des clés publiques puk , puk1 , pu/4", pue, sans attendre les accusés de réception correspondants. Le récepteur décode les secondes versions des paquets à l'aide des clés privées correspondantes prie, prie, prie, prk(') Pour chacun des quatre paquets, le récepteur combine les première et seconde versions et tente un nouveau décodage de la combinaison obtenue. Dans le cas illustré, le décodage se solde par un échec pour les paquets P2 et P3, et par un succès pour les paquets P et P4. Le récepteur renvoie par conséquent ACK1, NACK2 avec la nouvelle clé publique puk22', NACK3 avec la nouvelle clé publique pu/42', et ACK4. Lorsque l'émetteur reçoit un accusé de réception positif, il passe à un nouveau paquet et en transmet une première version. Ainsi, après A(K1, l'émetteur transmet le paquet P5 et après ACK4, il transmet le paquet P6. A l'inverse lorsque l'émetteur reçoit un accusé de réception négatif, il transmet à la volée une nouvelle version du paquet correspondant. Ainsi, après NACK2, l'émetteur transmet une troisième version, v3(P2) du paquet P2, chiffrée à l'aide de la clé puee2). De même, 25 après NACK3, l'émetteur transmet une troisième version du paquet, v3(P3), chiffrée avec la clé puk32). Dans l'exemple illustré, un nouveau couple de clés publique et privée est généré à chaque échec de 30 décodage d'un paquet. Toutefois, cette génération peut 15 n'intervenir qu'après Q échecs successifs. Par exemple, on pourra prendre Q = N = 4. Dans ce cas, on remarquera que les secondes versions des paquets sont chiffrées avec la même clé publique. Le nombre Q d'échecs entre deux générations de clés peut encore résulter d'un tirage aléatoire. La génération du couple de clés privée et publique au niveau du récepteur utilise un germe qui peut être avantageusement réinitialisé à chaque mise en route et/ou à chaque établissement d'une nouvelle communication. Par exemple, le germe peut être obtenu à l'aide d'une opération XOR entre le code PIN de l'utilisateur et l'heure de mise en route/ d'établissement de la communication, exprimée selon un format donné. Ce germe peut subir en outre un traitement par une fonction non-inversible de manière à prévenir qu'un espion puisse remonter à ce dernier à partir de la simple observation des clés générées. Par exemple, ce traitement pourra consister en une opération arithmétique complexe suivie du modulo par rapport à un nombre premier. Bien entendu, d'autres exemples peuvent être envisagés sans pour autant sortir du cadre de la présente invention. Le résultat de ce traitement sert de clé privée au récepteur. La clé publique correspondante est générée de manière connue en soi, par exemple à l'aide de l'algorithme RSA. La Fig. 3 représente schématiquement la structure d'un émetteur permettant la mise en oeuvre de la méthode de transmission sécurisée selon l'invention. L'émetteur comprend un codeur 310 codant les paquets 300 à l'aide d'un code correcteur d'erreur et, le cas échéant, d'un code de détection d'erreur. Le codeur correcteur d'erreur peut effectuer un codage par blocs, par exemple un codage de type Reed-Solomon ou BCH, un codage convolutif, un turbocodage parallèle ou série, ou encore un codage LDPC (Low Density Parity Check code). Le poinçonneur 320 poinçonne le paquet ainsi codé avec différents taux de poinçonnage possibles. Le taux de poinçonnage est fonction du numéro de la version de paquet requis par le récepteur. Comme on l'a vu précédemment, la première version est poinçonnée avec un taux de poinçonnage élevé ne permettant pas le décodage au niveau du récepteur. Par exemple, si le codeur 310 utilise un codage systématique, le premier poinçonnage pourra éliminer tous les symboles systématiques. Pour les versions suivantes du paquet, deux variantes peuvent être envisagées. Selon une première variante, le poinçonneur 320 ne fournit pour les versions suivantes d'un paquet (c'est- à-dire pour la première, seconde, etc. retransmission) que des symboles qui ont été éliminés lors d'un poinçonnage antérieur. Par exemple, si le codeur 310 utilise un codage systématique, le poinçonneur pourra fournir dans les versions successives du paquet les symboles systématiques, puis des symboles de redondance éliminés lors de la première étape de poinçonnage. L'avantage de cette variante est de ne transmettre que des nouveaux symboles à chaque nouvelle retransmission. Selon une seconde variante, le poinçonneur 320 fournit pour la seconde, troisième, etc. version d'un paquet, des symboles éliminés lors d'un poinçonnage antérieur mais également des symboles qui étaient présents dans une version précédente de ce paquet. L'avantage de cette variante est de pouvoir permettre une combinaison de type Chase combining, et donc un décodage plus rapide du paquet en cas de faible rapport signal sur bruit. La version de paquet fournie par le poinçonneur est ensuite chiffrée à l'aide d'une clé publique, notée ici puk . Celle-ci est transmise préalablement par le récepteur. La Fig. 4 représente schématiquement la structure d'un récepteur permettant la mise en oeuvre de la méthode de transmission sécurisée selon l'invention. Le récepteur comprend un buffer de réception 410, dans lequel sont stockés les paquets incidents. Le paquets sont déchiffrés par le module de déchiffrement 420, à l'aide de la clé privée, pie') associée à la clé publique pue. La version du paquet ainsi déchiffrée est ensuite traitée par le module 430. Ce module effectue une combinaison de plusieurs versions disponibles d'un même paquet pour fournir une version combinée dans un buffer de combinaison (non représenté). Le module 430 substitue aux effacements les symboles reçus, au fur et à mesure qu'ils sont fournis par les versions successives d'un même paquet (dépoinçonnage). Le cas échéant, il additionne par exemple les valeurs souples d'un même symbole, lorsqu'il est présent dans différentes versions du paquet. Le module 430 reçoit une information de numéro de version de paquet (soit transmise dans l'entête de la version, soit obtenue par incrémentation d'un compteur) et en déduit les effacements à substituer et/ou les valeurs souples des symboles à sommer. Les fonctions de sommation et de dépoinçonnage peuvent être exécutées par des entités distinctes ou non de ce module. La fonction de sommation ne sera pas implémentée si chaque nouvelle version contient de nouveaux symboles, absents des versions précédentes, autrement dit si chaque nouvelle version constitue un incrément de redondance. De manière générale, on comprendra que la combinaison comprend une étape de dépoinçonnage (des symboles reçus d'une nouvelle version complétant alors les symboles déjà disponibles dans le buffer de combinaison) et, le cas échéant, une étape d'addition (les valeurs souples de symboles d'une nouvelle version étant respectivement ajoutées à celles des symboles déjà présents dans le buffer de combinaison). Au terme de cette opération, le buffer de combinaison contient une version combinée du paquet. La version combinée du paquet est ensuite décodée à l'aide du décodeur 440. Celui-ci indique si le paquet est décodable ou non. S'il est décodable, il fournit en 441 le paquet décodé,P, et transmet en 443, à l'émetteur, un accusé de réception positif, ACK. Dans le cas contraire, il transmet en 443 un accusé de 19 réception négatif, NACK, et ordonne au module 450 de générer une nouvelle paire de clés publique et privée, notée (puk("+»,prk("+'»> La clé privée est stockée au niveau du récepteur et la clé publique est transmise à l'émetteur en 445. De préférence, la clé privée est effacée dès lors que la ou les version(s) de paquet, chiffrée(s) à l'aide de la clé publique correspondante, a(ont) bien été reçue(s) et déchiffrée(s). Enfin, on a vu que pour les modes « Go-Back-N ARQ », « selective repeat ARQ » et « N-Stop-and-Wait », N paquets sont reçus successivement et peuvent être traités indépendamment les uns des autres, en mode série et/ou parallèle. On peut prévoir dans ce cas plusieurs chaînes de traitement, par exemple N chaînes de traitement comme celle représentée en Fig. 4, le cas échéant partageant certains modules communs, au prix d'un multiplexage en entrée et/ou en sortie de ces modules.20 REVENDICATIONS1. Méthode de transmission sécurisée de paquets de 5 données sur une liaison sans fil entre un émetteur et un récepteur, caractérisée en ce que : - l'émetteur transmet (110) sur ladite liaison une première version d'un paquet de données ne permettant pas le décodage dudit paquet par le décodeur; 10 - suite à l'échec du décodage de la première version du paquet, le récepteur génère une première paire de clés constituée d'une première clé privée et d'une première clé publique correspondante et transmet (120) la première clé publique à l'émetteur ; 15 - l'émetteur transmet (130) sur ladite liaison une seconde version dudit paquet, chiffrée au moyen de la première clé publique ; - le récepteur déchiffre la seconde version du paquet à l'aide de la première clé privée, combine 20 ladite première version et la seconde version, pour obtenir une première version combinée dudit paquet, et effectue (140) un décodage de la première version combinée ainsi obtenue. 25 2. Méthode de transmission selon la revendication 1, caractérisée en ce que, si le décodage de la première version combinée échoue, le récepteur génère une seconde paire de clés constituée d'une seconde clé privée et d'une seconde 30 clé publique correspondante ;l'émetteur transmet (150) sur ladite liaison une troisième version dudit paquet, après l'avoir chiffrée au moyen de la seconde clé publique ; le récepteur déchiffre (160) la troisième version du paquet à l'aide de la seconde clé privée, combine la troisième version ainsi déchiffrée avec au moins la première version ou la seconde version déchiffrée pour obtenir une seconde version combinée dudit paquet, et effectue un décodage de la seconde version combinée ainsi obtenue. 3. Méthode de transmission selon la revendication 1 ou 2, caractérisée en ce la première version du paquet est obtenue par codage de ce paquet au moyen d'un code de correction d'erreurs, suivi d'un premier poinçonnage du paquet ainsi encodé, avec un taux de décodage excédant les capacités de correction dudit code. 4. Méthode de transmission selon la revendication 3, caractérisée en ce que la seconde version du paquet comprend des symboles ayant été éliminés par le premier poinçonnage du paquet encodé. 5. Méthode de transmission selon la revendication 4, caractérisée en ce que la seconde version du paquet est obtenue par un second poinçonnage du paquet encodé et que la troisième version du paquet comprend des symboles ayant été poinçonnés lors du premier et/ou du second poinçonnage(s).30 6. Méthode de transmission selon la revendication 5, caractérisée en ce que le chiffrement de la seconde version du paquet au moyen de la première clé publique est réalisé après le second poinçonnage. 7. Méthode de transmission selon l'une des revendications 3 à 6, caractérisée en ce que le codage du paquet est de type systématique, et que le premier poinçonnage élimine les symboles systématiques du paquet encodé. 8. Méthode de transmission selon la revendication 6, caractérisée en ce qu'elle met en oeuvre un protocole HARQ de type II. 9. Méthode de transmission selon la revendication 2, caractérisée en ce que les première et seconde clés privées sont générées à partir d'un même germe. 20 10. Méthode de transmission selon la revendication 9, caractérisée en ce que le germe subit un traitement par une fonction non-inversible, le germe ainsi traité étant utilisé comme clé privée, la clé publique correspondante étant obtenue à partir de la clé privée 25 à l'aide de l'algorithme RSA. 30