Brevet FR2826472A1 — publié le 20021227

PROCEDE DE VERIFICATION DES DROITS D'ACCES A DES FICHIERS INFORMATIQUES L'invention concerne un procédé pour vérifier les droits d'accès associés à des fichiers informatiques d'un dispositif informatique tel qu'une carte à puce électronique. Les cartes à puce électronique sont de plus en plus utilisées pour mettre en oeuvre sur une même carte différentes applications, telles que des opérations de banque, de bourse, d'accès à des locaux, etc,... du fait que leur puissance de traitement a fortement augmentée, notamment par suite de l'augmentation de la taille des mémoires qu'elles peuvent contenir. Les possibilités d'évolution s'ouvrent vers de nouveaux intervenants : les émetteurs les fournissent avec un certain nombre d'applications de base. Puis leurs utilisateurs peuvent les faire évoluer en ajoutant des nouvelles applications et en modifiant des applications existantes. Le chargement de ces différentes applications dans une carte à puce peut être la source à l'introduction de virus si un contrôle d'accès n'est pas réalisé avec rigueur. Par ailleurs, les applications, de plus en plus évoluées, créent des fichiers dont les droits d'accès ne sont pas définis de manière précise ou sont trop larges et il en résulte des possibilités de mauvais fonctionnement et de propagation de virus. Un but de la présente invention est donc de mettre en oeuvre un procédé pour vérifier les droits d'accès associés à des fichiers informatiques d'un dispositif informatique tel qu'une carte à puce électronique. L'invention concerne un procédé de vérification de la sécurité de fichiers informatiques d'un dispositif informatique tel qu'une carte à puce électronique, caractérisé en ce qu'il comprend les étapes suivantes consistant à : (a) comparer les droits d'accès associés à chaque fichier informatique à des droits d'accès prédéterminés dits de référence, et (b) élaborer un message selon le résultat de la comparaison. Les droits d'accès de référence sont prédéterminés en fonction du type de fichier sélectionné pour la vérification, le type de fichier étant défini par un code en début de fichier. Les types de fichier sont les fichiers de programme et les fichiers de données et éventuellement des fichiers de ressources et présentent chacun des droits d'accès de référence. Ces droits d'accès de référence peuvent être figés, de préférence réduits au maximum, mais peuvent être modifiés par l'utilisateur du dispositif informatique de manière à les étendre. Le message élaboré indique, au moins, l'identité du fichier concerné, les droits d'accès de référence pour ce type de fichier et le résultat de la comparaison. Il peut indiquer, en outre, une proposition de modification des droits d'accès existants qui consiste, par exemple, à introduire les droits d'accès de référence. Ce message peut indiquer le blocage du dispositif informatique tant qu'une modification n'a pas été introduite. Le procédé est mis en oeuvre soit par l'utilisateur du dispositif informatique, soit de manière périodique, soit lors d'une demande de changement de droits. D'autres caractéristiques et avantages de la présente invention apparaîtront à la lecture de la description suivante d'un exemple particulier de réalisation, ladite description étant faite en relation avec les dessins joints dans lesquels : - les figures 1 et 2 sont des vues d'écran de menus partiels d'une application à laquelle s'applique le procédé selon l'invention. L'invention sera décrite en relation avec une application connue sous l'acronyme"WfSC"pour l'expression anglo-saxonne"Windows for Smart Card". Cette application représente un outil de développement qui permet de créer des solutions à base de carte à puce. Il se pose donc des problèmes de sécurité dans un tel contexte. Pour cela, elle est prévue notamment pour définir, dans une carte à puce électronique, des droits d'accès à un fichier en utilisant une"liste de droits d'accès", plus connue par l'acronyme"ACL"pour l'expression anglo-saxonne"Access Control List". Ainsi, l'émetteur d'une carte accorde à chaque fichier des droits d'accès en lui associant une ACL. L'utilisateur fait de même lors de ses interventions ultérieures pour les fichiers dont il est propriétaire. De manière plus pratique, les vues d'écran des figures 1 et 2 montrent les menus partiels de l'application WfSC qui permettent de comprendre le fonctionnement des ACL ainsi que celui de l'invention. La vue d'écran de la figure 1 montre l'arborescence du système de fichiers sur la carte à puce électronique. Elle montre que pour un fichier sélectionné 10 correspond une ACL 12 stockée dans un répertoire particulier" :/s/a/". Les fichiers de ce répertoire sont eux-même associés à une ACL dans ce répertoire, par exemple,"/s/a/acl"peut être associé à lui-même : "/s/a/acl" (figure 2). Chaque fichier ACL est créé dans un autre menu selon la vue d'écran de la figure 2 qui montre une liste d'ACL 21 déjà créée et la liste 22 des droits associés à l'ACL sélectionnée. Cette figure 2 montre également l'interface graphique 23 pour effacer et créer de nouvelles ACL. A l'aide de ces menus présentés sur les figures 1 et 2, l'utilisateur peut définir les droits d'accès à chacun des fichiers qu'il crée mais une telle liberté de choix peut aboutir à des erreurs dans cette sélection des droits d'accès, particulièrement pour un utilisateur faiblement expérimenté, ce qui peut aboutir à un fonctionnement défectueux et, surtout, à laisser la porte ouverte à l'introduction d'un virus. Le procédé de vérification de l'invention consiste à comparer l'ACL de chaque fichier à un ACL de référence pour ce type de fichier, c'est-à-dire à comparer les droits d'accès de chaque fichier à des droits d'accès classiques pour le type de fichier en cours de vérification. Dans un mode de réalisation, des droits d'accès de référence ou des ACL de référence, sont définis selon les trois types de fichiers : - les fichiers de programme contiennent le code qui doit être exécuté et, dans l'application WfSC, leur extension est souvent". RTE" (figure 1). L'accès à ces fichiers ne sera autorisé que pour leur exécution, et pas pour leur lecture, écriture, extension et effacement ; - les fichiers de données contiennent des données utilisées par un ou plusieurs programmes et ne doivent pas pouvoir être exécutés. Ils doivent en revanche être accessibles en lecture et en écriture par leur propriétaire. On peut aussi prévoir que l'émetteur y ait toujours accès. - les fichiers de ressources contiennent les variables et autres ressources d'un programme et, dans l'application WfSC, leur extension est souvent ". DAT". Ces fichiers de ressources comme ceux de programme ne peuvent être qu'exécutés, c'est-à-dire qu'ils ne peuvent pas être lus, écrits, étendus ou effacés par une autre personne que leur propriétaire. La vérification de chaque fichier consiste à : - déterminer le type de fichier, programme, données ou ressources, par exemple, en ouvrant le fichier et en lisant les premiers octets, - rechercher l'ACL associée au fichier en cours de vérification, - comparer l'ACL associée à l'ACL de référence pour ce type de fichier, et - élaborer un message à l'utilisateur selon le résultat de la comparaison. On distingue trois mises en oeuvre du principe selon l'invention, qui peuvent être complémentaires : * le système d'exploitation de la carte à puce peut contenir un programme approprié, qu'on appellera le vérificateur par la suite, et les fichiers ACL de référence. Dans ce cas, ce programme est lancé soit par une commande venant de l'extérieur, sur une demande de l'utilisateur de la carte par exemple, soit de manière autonome selon des critères prédéfinis, de façon périodique ou lors d'une demande de changement de droits par exemple. Le programme vérificateur ainsi que les ACL de référence, parties intégrantes du système d'exploitation, sont mémorisés dans une mémoire protégée et, par conséquent, sont inaccessibles, ce qui garantit une grande sécurité. * La vérification peut avoir lieu sur un ordinateur personnel après la phase de développement d'une application et avant son téléchargement sur la carte à puce. Dans un tel cas, l'ordinateur contient un programme de type vérificateur et des ACL de référence. Avantageusement, la vérification sera faite juste avant le téléchargement pour éviter les fraudes. on peut aussi prévoir une vérification d'une carte à partir d'un ordinateur personnel : pour des raisons de sécurité, cette mise en oeuvre n'est accordée qu'à l'émetteur de la carte. Avantageusement, ce dernier a un accès prioritaire à tous les fichiers de la carte pour une vérification complète. La vérification permet d'informer un code de retour SW (Status Word) qui indique s'il y a un problème. Ce SW est suivi d'un descriptif comportant le nom du fichier posant problème et l'ACL de référence. Ce code SW est également renvoyé en réponse à tous les ordres communiqués à la carte, tant que le problème n'est pas résolu. Dans ce cas, le descriptif ne suit pas le code SW . Dans une variante, la carte reste bloquée tant que le problème correspondant au message d'erreur n'est pas résolu. Le code SW indique alors non seulement qu'il y a un problème relatif aux droits des fichiers mais également que la carte ne réagit plus aux ordres envoyés. Dans une telle variante, seules les étapes permettant de se renseigner sur l'origine du problème et de le corriger seront autorisées, comme par exemple une vérification manuelle et/ou une modification d'ACL. Le procédé peut aussi prévoir des messages préventifs et informer par exemple lors d'une demande de changement de droits que la modification est dangereuse. Le message à l'utilisateur peut être de différentes formes. Il peut : - soit simplement prévenir l'utilisateur en indiquant le nom complet du fichier de manière à l'identifier et l'ACL de référence, - soit lui proposer de remplacer l'ACL par l'ACL de référence, - soit effectuer automatiquement la modification de l'ACL selon le message fourni. L'invention a été décrite dans un mode de réalisation en relation avec l'application connue sous l'acronyme "WfSC"pour l'expression anglo-saxonne"Windows for Smart Card", en identifiant trois groupes particuliers de fichiers selon leur type, les données, les exécutables et les fichiers de ressources et en leur appliquant certaines règles d'accès. Le concept de l'invention, qui consiste à maîtriser les opérations effectuées sur des supports informatiques de type cartes à puce grâce à un contrôle des différents droits sur les fichiers, peut bien sûr être appliqué à toutes applications utilisant des structures de fichiers, comme Java par exemple. De plus, il peut s'implémenter à l'aide de toute autre répartition en groupes de fichiers, par exemple selon des critères comme leur origine, leur propriétaire. De même, d'autres règles de sécurité sont possibles. L'invention est particulièrement adaptée aux cartes à puce, destinées en premier lieu au support d'applications liées au domaine bancaire ou à un réseau de télécommunication de type GSM, GSM étant l'acronyme de l'expression anglo-saxonne"Global System for Mobile communications"par exemple, évolutives pour apporter un meilleur service à leurs utilisateurs, sans nuire à la sécurité. REVENDICATIONS 1. Procédé de vérification de la sécurité de fichiers d'un dispositif informatique tel qu'une carte à puce électronique, caractérisé en ce qu'il comprend les étapes suivantes consistant à : (a) comparer les droits d'accès (ACL, 21,22) associés à au moins un fichier à des droits d'accès prédéterminés dits de référence, et (b) élaborer un message selon le résultat de la comparaison. 2. Procédé selon la revendication 1, caractérisé en ce que les droits d'accès de référence sont prédéterminés en fonction du type de fichier sélectionné pour la vérification. 3. Procédé selon la revendication 2, caractérisé en ce que le type du fichier sélectionné pour la vérification est défini par un code enregistré en début dudit fichier. 4. Procédé selon l'une quelconque des revendications précédentes 1 à 3, caractérisé en ce que les fichiers à vérifier sont classés en au moins deux groupes : les fichiers de programme dont les droits d'accès sont tels qu'ils ne peuvent pas être lus, écrits, étendus ou effacés par tous, et les fichiers de données dont les droits d'accès sont tels qu'ils ne peuvent pas être exécutés, mais seulement lus et écrits. 5. Procédé selon la revendication 4, caractérisé en ce que les fichiers à vérifier comprennent, en outre, un troisième groupe de fichiers appelé fichiers de ressources dont les droits d'accès sont tels qu'ils ne peuvent pas être lus, écrits, étendus ou effacés par tous. 6. Procédé selon l'une quelconque des revendications 1 à 5, caractérisé en ce que le message élaboré selon le résultat de la comparaison indique au moins : l'identité du fichier concerné, - le résultat de la comparaison des droits d'accès. 7. Procédé selon la revendication 6, caractérisé en ce que le message indique, en outre, une proposition de modification des droits d'accès existants. 8. Procédé selon la revendication 7, caractérisé en ce que la proposition de modification des droits d'accès existants consiste à introduire les droits d'accès de référence. 9. Procédé selon l'une quelconque des revendications précédentes 1 à 8, caractérisé en ce le dispositif informatique est bloqué tant qu'une modification n'a pas été introduite. 10. Procédé selon l'une quelconque des revendications précédentes 1 à 9, caractérisé en ce que le procédé est mis en oeuvre à la demande de l'utilisateur du dispositif informatique. 11. Procédé selon l'une quelconque des revendications précédentes 1 à 10, caractérisé en ce que le procédé est mis en oeuvre périodiquement par le dispositif informatique. jLz. Proceae selon l'une quelconque des revendications précédentes 1 à 11, caractérisé en ce que le procédé est mis en oeuvre à chaque demande de changement de droits d'accès à un fichier. 13. Dispositif informatique sécurisé tel qu'une carte à puce caractérisée en ce qu'il contient au moins un fichier de droits d'accès de référence et un programme vérificateur apte à comparer les droits d'accès d'au moins un fichier du dispositif informatique auxdits droits d'accès de référence. 14. Dispositif informatique selon la revendication 13 caractérisé en ce que les droits d'accès de référence et le programme vérificateur font partie du système d'exploitation dudit dispositif. 15. Utilisation du procédé selon l'une quelconque des revendications 1 à 12-comme anti-virus dans une carte à puce électronique.