Brevet FR2898002A1 — publié le 20070831

PROCEDE POUR GERER ET CONTROLER LES CLES D'ACCES A DES SERVICES DANS UN SYSTEME DE COMMUNICATION La présente invention concerne un procédé et un système de gestion des clés permettant à un utilisateur d'accéder à un service donné, l'utilisateur pouvant ne pas être connecté en continu à ce service. Elle s'applique, par exemple, à un système de radio communication où les récepteurs autorisés partagent une même clé de trafic. Elle peut aussi être utilisée dans un système de navigation satellite où les récepteurs ou utilisateurs autorisés partagent une clé permettant l'accès aux signaux secrets diffusés dans l'espace. Dans les systèmes pré-mentionnés, les utilisateurs d'un même service S partagent une clé commune donnant l'accès à ce service. Cette clé de trafic doit être renouvelée périodiquement pour assurer la sécurité du système. Un centre de gestion est capable de diffuser une nouvelle valeur 15 de clé de trafic enfouie dans le service S lui-même, en utilisant une bande passante limitée. La gestion de clé pour les clés de trafic demande la résolution du compromis suivant : • périodiquement, session après session, la clé doit être changée et 20 l'accès au service doit être contrôlé, • l'accès au service doit être rendu le plus transparent possible pour des utilisateurs autorisés qui peuvent, ne pas être toujours connectés au service. Le but principal de cette fonction dénommée OTAR (abrégé anglo- 25 saxon de Over The Air Rekeying ) est de fournir aux utilisateurs autorisés un accès transparent au service. Pour un utilisateur donné, l'accès est d'autant plus transparent : • qu'il est capable de conserver la connaissance des clés de trafic futures en évitant l'utilisation d'autres moyens de distribution que le service S lui-même, telle qu'une distribution manuelle hors ligne des clés par exemple ; • qu'il peut quelquefois être déconnecté et, en conséquence, perdre plusieurs messages diffusés par la fonction OTAR. L'invention concerne un procédé de gestion des clés permettant à un utilisateur d'accéder à un ou plusieurs services S donnés dans un système de communication, l'utilisateur pouvant ne pas être connecté en continu à ce service, caractérisé en ce qu'il comporte au moins les étapes suivantes : • générer une clé K(t) donnant l'accès au service pour le jour[t] pour tous les t Plus précisément, si la période de transition entre la chaîne KO et la chaîne K*() est constituée de r jours consécutifs du jour [TO] au jour [TO+r-1] inclus, alors pour chaque groupe d'utilisateurs G de niveau de confiance d pour la chaîne K() et d* pour la chaîne K*O, une fonction OTAR associée au groupe G peut par exemple diffuser les informations suivantes : • Avant la période de transition : o K(t+d) chaque jour [t] avec t La fonction f est, par exemple, une fonction cryptographique ou une fonction basée sur des fonctions de hachage. L'invention concerne aussi un système de gestion des clés permettant à un utilisateur d'accéder à un ou plusieurs services S donnés dans un système de communication, l'utilisateur pouvant ne pas être connecté en continu à ce service, caractérisé en ce que la génération d'une clé d'accès au service S pour une période correspondant au niveau de confiance d attribué à un utilisateur ou à un groupe d'utilisateur caractérisé en ce qu'il comporte en combinaison au moins les éléments suivants : un centre de gestion adapté à générer des clés en mettant en oeuvre les étapes du procédé décrit ci-dessus. La présente invention permet, pour un service dont l'accès est contrôlé par une clé de trafic renouvelée régulièrement, tous les jours par exemple, de donner un accès transparent au service à des récepteurs pouvant être éteints jusqu'à d jours, où d correspond au niveau de confiance qui leur est attribué. D'autres caractéristiques et avantages de la présente invention apparaîtront mieux à la lecture de la description qui suit d'un exemple de réalisation donné à titre illustratif et nullement limitatif annexé des figures qui représentent : • La figure 1 un schéma de système comprenant un satellite et plusieurs groupes d'utilisateurs, • La figure 2 un schéma de la procédure d'accès courante, et • La figure 3 un schéma du renouvellement de la clé d'accès. Afin de mieux faire comprendre l'objet de l'invention, la description qui suit est donnée pour un système de communication par satellite 1 dans lequel les utilisateurs ou les groupes d'utilisateurs autorisés à accéder à un service S, partagent une clé d'accès K, (la clé d'accès à s est enfouie dans le service). Le système comprend notamment un centre de gestion des clés 2. On choisit, à titre d'exemple, une période de validité pour la clé de trafic à un jour, mais elle pourrait s'étaler sur une période quelconque. Si la période de validité est T alors, pour appliquer le principe selon l'invention, le mot jour dans la description doit être remplacé par l'expression période de validité de la clé ou T-période . Schéma de calcul des clés de trafic one way backward La figure 2 schématise la manière dont le centre de gestion des clés renouvelle la clé de trafic K et la diffuse aux utilisateurs (ou récepteurs). En parcourant la figure 2 on a schématisé du haut vers le bas, la fonction OTAR transmettant chaque jour, en continu, une clé d'accès future vers les utilisateurs autorisés à accéder à un service S donné. Une ligne mentionne les jours, une ligne schématise la clé d'accès K(t) du jour t. Sur cette dernière ligne on a représenté, par des diodes, la fonction à sens unique permettant de calculer la clé du jour K(t) à partir de la clé du lendemain K(t+1), sans que le calcul inverse ne soit possible. La clé K est renouvelée chaque jour. La clé courante et active pour le jour t est notée K(t). Afin de conserver un rafraîchissement de la clé de trafic simple opérationellement pour un récepteur autorisé autonome, l'idée mise en oeuvre par le procédé selon l'invention consiste, notamment, à dériver les clés de trafic successives à partir d'un paramètre secret unique. Ceci est obtenu, par exemple, en faisant appel au schéma décrit à 30 la figure 2. Le principe général repose notamment sur les 2 règles suivantes : Règle N 1 : caractéristique retour en arrière ou backward La clé K(t), pour le jour [t], est déterminée à partir de la clé K(t+1) correspondant au jour [t+1] postérieur au jour [t] K(t) = K_DERIVE(K(t+1)). Règle N 2 caractéristique sens unique ou "One way " La fonction de dérivation f = K_DERIVE est une fonction à sens unique, c'est-à-dire qu'il est facile de calculer y=f(x) à partir de x, mais il est impossible de récupérer, par calcul, une entrée x vérifiant y=f(x) pour toute image y donnée. La fonction f peut être une fonction cryptographique, comme par exemple, une fonction de chiffrement ou une fonction basée sur des fonctions de hachage. Les diodes schématisées sur la figure 1 traduisent ces deux caractéristiques backward et one way . Le centre de gestion du système, en charge de gérer les clés, utilise ce schéma pour déterminer une chaîne complète de clés de trafic pour une période donnée : K(to), K(to+1), ..., K(to+365), ..., K(tfin) (pouvant recouvrir une période de temps d'une année ou plus. Une nouvelle chaîne est déterminée, par exemple une fois par an, par le centre de gestion en utilisant une clé racine correspondant à la dernière clé de trafic de la chaîne K(tfin) et de toutes les autres clés de trafic déterminées à partir de K(tfin) pour la période de temps to t K(to) = K_DERIVE(K(to+1)). Au niveau du récepteur ou utilisateur, cette règle est aussi utilisée pour reconstruire des sous-ensembles de la chaîne totale. Pendant la crypto période de la chaîne globale de clé de trafic K(.), un récepteur autorisé le jour courant [t] possède seulement une clé de trafic intermédiaire K(t+d), où d correspond au niveau de confiance attribué à un utilisateur ou récepteur. A partir de la valeur de K(t+d), l'utilisateur calcule toutes les clés de trafic K(t+d-1), K(t+d-2),..., K(t) en appliquant la règle N 1 de manière itérative. Cette sous-chaîne lui donne un accès potentiel aux services auxquels il est autorisé pour une période temporelle limitée du jour[t] au jour[t+d]. Toutefois, grâce à la propriété de la fonction de cryptographie utilisée (règle 2 annoncée ci-avant), il ne peut déduire les clés du trafic futures K(t+d+1), K(t+d+2) correspondant aux jours [t+d+1]. Le procédé selon l'invention permet notamment de contrôler, 15 d'une manière souple, la capacité d'accès des groupes d'utilisateurs (récepteurs) de différents niveau de confiance a priori . Un utilisateur va toujours gérer une clé de trafic intermédiaire K(t+d) où, la valeur de d est sélectionnée selon le niveau de confiance a priori de l'utilisateur et assure un accès sur une fenêtre temporelle limitée 20 [jour[t],...jour[t+d]]. Pour continuer à accéder au service après cette période d, l'utilisateur autorisé doit obtenir de nouvelles clés de trafic valides K(). Les deux moyens de distribution possibles de clés de trafic valides sont, par exemple, la fonction précitée OTAR et la distribution de clés hors ligne . 25 Fonction journalière associée à un groupe d'utilisateurs Pour un utilisateur autorisé et possédant une clé de trafic active, une façon de maintenir sa capacité d'accès est d'utiliser la fonction OTAR offerte par le service. Les utilisateurs ayant un même niveau de confiance forment un groupe. Opérationnellement, il est préférable que le nombre de groupes reste limité. Une fonction spécifique OTAR est ensuite définie pour chacun de 5 ces groupes G. Les messages correspondant à cette fonction OTAR sont spécifiques et différents pour chaque groupe. 1) le message OTAR d'un groupe G(k) est chiffré au niveau applicatif avec un schéma de diffusion ou broadcast spécifique appelé BES (Broadcast Encryption Scheme) . 10 Un membre d'un groupe G(k) a uniquement accès à la fonction OTAR associée au groupe. Le BES est utilisé pour contrôler quels sont les utilisateurs du groupe qui ont accès à la clé de trafic future diffusée par le message délivré par la fonction OTAR au groupe. 2) Un message OTAR transmet principalement la clé future de trafic 15 K(t+d). Cette clé est spécifique à chaque groupe, le paramètre d pouvant être différent en fonction des groupes, dépendant du niveau de confiance du groupe. La fonction générique OTAR est effectuée jour après jour. Pendant le jour [t], la fonction transmet en continu aux membres d'un groupe 20 particulier de niveau de confiance d , la clé de trafic correspondante K(t+d) qui leur permet de calculer toutes les clés K(t+d) à K(t+1). Pendant le jour suivant jour[t+ 1 ], la fonction OTAFt transmettra au membre du groupe la clé K(t+d+1) et ainsi de suite. Gestion du niveau de confiance 25 Le paramètre d de niveau de confiance est un paramètre important qui peut être sélectionné jour après jour pour contrôler l'accès au service d'une manière souple. Une politique de sécurité permet de sélectionner le paramètre d(k) pour chaque groupe G(k) el de le modifier jour après jour en cas de risque. La valeur courante du niveau de confiance du groupe G(k) pendant le jour jour[t] est notée d(k)[jour(t)] pour souligner le fait qu'il dépende potentiellement du groupe G(k) et du jour. D'un point de vue opérationnel, d fixe aussi de manière explicite l'autonomie du récepteur, c'est-à-dire le délai maximum pendant lequel un récepteur peut être éteint et accéder à nouveau au service sans avoir recours à un moyen hors ligne pour obtenir une clé de trafic valide. Un utilisateur ayant un niveau de confiance d au jour [t] va continuer d'accéder normalement au service après le jour[t+d] si, au moins io une transmission de la fonction OTAR a été un succès pendant les jours consécutifs précédent jour [t], jour[t+1],....jour[t+d-1]. Dans le cas où il n'y a pas réellement de besoin de dénier un utilisateur (c'est-à-dire de lui interdire l'accès au service), d peut être sélectionné pour être grand, afin d'augmenter la probabilité d'accès 15 transparent au service, même dans des conditions opérationnelles difficiles (par exemple une coupure d'accès au service assez longue). En cas de risque, des politiques de gestion des dénis sont possibles. En cas de risque faible, la capacité d'accès aux groupes les plus 20 risqués peut être réduite (diminution du niveau de sécurité cl à d' t+d(k). Les utilisateurs auront donc accès au service encore d(k) jours après que le groupe soit dénié (temps de latence de d(k) jours mais pas plus). En effet, la période avant que le déni ne soit absolument garanti est d(k) jours. Le déni du groupe particulier G(k) de niveau de confiance d(k) ne change pas la condition d'accès des utilisateurs des autres groupes encore autorisés. Un utilisateur d'un autre groupe autorisé G(k') continuera à accéder normalement au service pendant le jour [t+d(k')] si au moins une transmission de la fonction OTAR a été reçue avec succès pendant les jours précédents consécutifs [t], [t+1],....[t+d(k')-1]. Cette condition est indépendante du déni du groupe G(k). Comme cette procédure de déni n'a pas de conséquence sur les groupes toujours autorisés, on parlera de procédure souple (en anglo-saxon soft) de déni de groupe. Avec cette procédure de déni standard, la période avant que le déni du groupe G(k) soit effectif est de d(k) jours. Parfois, ce délai sera réduit pour des raisons de sécurité. Si le groupe dénié a été, pour une durée importante, identifié comme un groupe à risque, son niveau de confiance alloué d(k) pourra être préventivement réduit à quelques jours ou réduit au minimum à un jour pour être certain de pouvoir dénier ce groupe dans un délai minimum de 1 jour. Dans le cas où l'on ne réduit pas de manière préventive le niveau de confiance de ce groupe, alors il est possible de mettre en oeuvre une procédure permettant de réduire le délai de d(k) jours avant que le déni ne soit effectif. Ce déni de groupe d'urgence est appelé procédure brutale (en anglo-saxon Nard ) de déni de groupe. Il est possible de changer momentanément les conditions d'accès au service pour les autres groupes autorisés. Ceci est basé sur le renouvellement des chaînes de clés de trafic comme il est explicité ci-après. Renouvellement de la chaîne de clé de trafic et déni "hard" Dans certains cas, on peut imposer un renouvellement de chaîne des clés de trafic K() avant la fin normalement prévue, afin de réduire le délai de d(k) jours avant que le déni d'un groupe G(k) soit effectif. Ce renouvellement concerne tous les utilisateurs du service S (donc tous les groupes G(k)) puisqu'ils doivent partager une clé commune donnant accès à S. La procédure suivante s'applique à chacun des groupes. Soit G un groupe 1 o de niveau de confiance d. Vers la fin de la période de validité de la chaîne en cours KO pour la clé de trafic K(t+d), les récepteurs ou utilisateurs vont mémoriser deux types de clés de trafic : • Une clé de trafic courante K(t+d) permettant l'accès pour les derniers 15 jours sous le contrôle de la chaîne en cours KO, avec le niveau de confiance d, • Une seconde clé de trafic K*(t+d*) permettant l'accès pour les jours futurs sous le contrôle d'une nouvelle chaîne K*O avec un niveau de confiance d* qui peut être différent du niveau de confiance d. 20 La figure 3 schématise une manière générique pour la procédure de renouvellement ou de rafraîchissement de la clé. Pour chaque jour en cours [u], • La ligne clé d'accès correspond aux clés de trafic K(u) en utilisation pour le jour[u], 25 • Sur la ligne OTAR , la figure 2 précise les clés de trafic K(u') qui sont transportées sur le message journalier OTAR pendant le jour courant [u], • r est un paramètre qui fixe la fenêtre temporelle qui est encore sous le contrôle temporel de l'ancienne clé de trafic KO mais dans laquelle la fonction courante OTAR donne les valeurs des clés de trafic futures de la nouvelle chaîne K*(), • d (respectivement d*) est le niveau de confiance en cours du groupe associé à la chaîne K() (respectivement K*(). En suivant cette procédure, l'accès pour les différents groupes est momentanément piloté par le paramètre r. 1) la condition pour conserver un accès transparent (non nécessaire pour réinitialiser le service) pour les groupes encore autorisés est la suivante : un utilisateur de niveau de confiance d doit être actif et accéder à la fonction OTAR pendant au moins un jour dans la fenêtre temporelle de r' jours consécutifs précédent la date d'activation de la chaîne K*O, où r' est le minimum entre r, d et d*, toujours sous le contrôle des anciennes clés de trafic, pour récupérer une clé de trafic valide de la chaîne K*(). 2) Le déni absolu (pas de clé de trafic valide) est garanti sous la condition suivante : Un groupe dont le déni est demandé au jour [t] et de niveau de confiance d n'a plus accès au service au jour [4r"], où r" est le minimum entre r et d, si sa fonction correspondante OTAR pendant cette même fenêtre temporelle est inhibé. Les paramètres r et d peuvent être modifiés jour après jour pour adapter la capacité de déni suivant le degré de risque différent, et pour gérer le rapport : [délai pour dénier un groupe risqué]/[délai pendant lequel un utilisateur peut rester inactif sans être avoir à récupérer des clés de manière manuelle]. L'information exacte diffusée dans le message OTAR dans le cas déni hard est le suivant : • avant la période de transition, avant le jour [TO] : o K(t+d) chaque jour [t] avec t REVENDICATIONS 1 ù Procédé de gestion des clés permettant à un utilisateur d'accéder à un ou plusieurs services S donnés dans un système de communication, 5 l'utilisateur pouvant ne pas être connecté en continu à ce service, caractérisé en ce qu'il comporte au moins les étapes suivantes : • générer une clé K(t) donnant l'accès au service de jour[t] pour tous les t