EP1964018A2 - Procede d'authentification d'applications d'un systeme informatique - Google Patents

Procede d'authentification d'applications d'un systeme informatique

Info

Publication number
EP1964018A2
EP1964018A2 EP06847139A EP06847139A EP1964018A2 EP 1964018 A2 EP1964018 A2 EP 1964018A2 EP 06847139 A EP06847139 A EP 06847139A EP 06847139 A EP06847139 A EP 06847139A EP 1964018 A2 EP1964018 A2 EP 1964018A2
Authority
EP
European Patent Office
Prior art keywords
application
operating system
trusted environment
environment
applications
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP06847139A
Other languages
German (de)
English (en)
Inventor
Alexandre Frey
Axelle Apvrille
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Trusted Logic SAS
Original Assignee
Trusted Logic SAS
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Trusted Logic SAS filed Critical Trusted Logic SAS
Publication of EP1964018A2 publication Critical patent/EP1964018A2/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
    • G06F21/6218—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database
    • G06F21/6281—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database at program execution time, where the protection is within the operating system
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/51—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems at application loading time, e.g. accepting, rejecting, starting or inhibiting executable software based on integrity or source reliability

Definitions

  • the present invention relates to a method for authenticating applications of a computer system.
  • Trusted Environment a secure local environment
  • These services offer features that can be invoked from outside the Trusted Environment. So we want to be able to control who (which application) has the right to invoke each feature.
  • DRM Digital Rights Management
  • This DRM agent manages the read permission of MP3 files protected by a DRM license.
  • This license includes, for example, a right to play the MP3 file until a deadline.
  • the DRM agent is responsible for verifying that the conditions of the license are met.
  • Developing in a Trusted Environment helps him to fulfill his mission: he has, for example, guarantees on the time and date of the local system. If the conditions are met, the DRM agent allows playback of the MP3 file. For this, it must then provide the standard application "MP3 player" (which runs in so-called standard zone, that is to say outside the Trusted Environment) key decoding file MP3.
  • MP3 player which runs in so-called standard zone, that is to say outside the Trusted Environment
  • the DRM agent should not provide this key to an unknown "MP3 player” application (which, for example, could post it on the Internet ). It is clear in this example that the secure service (DRM agent) must authenticate the standard application (“MP3 player") that invokes the playback feature of the MP3 file.
  • MP3 player standard application
  • a local service it is easy for a local service to authenticate another local application in closed environments, whether it is closed operating systems (that is, all applications are initially installed under the control of an administrator, or authorized user) or runtime environments. Indeed, if it is a closed operating system, the installation itself of the application represents a guarantee of its authenticity since only authorized persons can perform this operation. If it is a runtime environment (virtual machine), the problem is not much more complicated because the application's format is designed to provide the virtual machine with the means to verify its authenticity or integrity. (By construction, a virtual machine manipulates the code of the applications it executes).
  • the authentication of the application is entrusted to the operating system, which is not its role.
  • the role of an operating system is to manage tasks against each other, not to perform security operations. We know that it is bad practice to entrust security treatment to a generalist entity. Instead, they should be grouped together in a dedicated and restricted module.
  • TPM Trusted Computing
  • Cryptographic attestation is designed to provide guarantees on a global system and not on a given application (there is no system using a TPM to authenticate a local application); moreover, the addition of dedicated equipment is not necessarily feasible in all situations (for technical and / or commercial reasons).
  • the object of the invention is therefore more particularly to eliminate these drawbacks by means of a method making it possible to locally provide, on an open operating system, without modifying it, guarantees on the authenticity of "standard” applications that execute. outside the Trusted Environment, to secure services operating in the Trusted Environment, this process allowing to obtain three different levels of trust:
  • This method allows the authentication of applications of a computer system comprising:
  • Identification Information a trusted environment offering services to said applications.
  • this method prior to any access to the services of the Trusted Environment by an application, this method comprises the following operating phases:
  • the method may further comprise a software component, called “Driver”, allowing access to the Trusted Environment from the operating system, and the operations can then be performed as follows:
  • the Driver provides the operating system with the identifier of the application
  • the operating system provides the Driver with the Identification Information
  • the Driver performs the "hashing" operation on the Identification Information and transmits the Condensed to the Trusted Environment.
  • the above Identification Information may include the executable code of the application as well as possibly some file names and files used by the application.
  • - Authentication operations may be performed at the time of the access request of the application to a service of the Environment of
  • the authentication operations can be performed during a prior phase, called “login” (or registration) that allows to authenticate the application prior to any request for access to the services of the Trusted Environment .
  • the Trusted Environment may grant the application different access rights to its services.
  • the services offered by the Trusted Environment may include at least access to certain resources of the computer system.
  • the resources of the computer system controlled by the Trusted Environment may include cryptographic encryption means.
  • the resources of the computer system controlled by the Trusted Environment may include content usage rights (DRM).
  • DRM content usage rights
  • the Trusted Environment can run in a secure mode of the microprocessor, which will provide increased security guarantees.
  • the invention also relates to an application authentication system implementing the method previously defined and possibly being able to execute on a portable device such as a mobile phone, an audio or video player, a PDA personal assistant, etc.
  • the single figure is a schematic representation of the architecture of an authentication system according to the invention.
  • the terminal 1 uses:
  • an OS2 open operating system such as, for example, “Linux”, “Windows”, “Solaris” ... (registered trademarks)
  • this OS2 operating system must be able to manage the applications that we want to authenticate.
  • "Standard” (non-secure) applications run directly on this operating system.
  • This operating system has two global levels of privileges (“User Mode” / "Kernel Mode”).
  • This Driver is designed to intercept access requests by an unsecured application (running on the OS2 operating system) to a secure service 4 (running in the EC Trust Environment).
  • control block data structure
  • Driver 5 performs a "hashing” operation (such as, for example, SHA-1) on the file provided by the OS2 operating system.
  • a "hashing” operation such as, for example, SHA-1
  • the OS2 operating system can further search the directory of the file, a file called "manifest" which contains the absolute name of all the important files that the application uses (eg a configuration file, a shared library , etc.) and provide this information to Driver 5.
  • Driver 5 will then perform the "hashing" operation on both the manifest executable, and all the files referenced in the manifest (or only some of them). them).
  • the Condensed uniquely identifies the unsecured application (since the "hash" function avoids collisions). It is then transmitted to the Trust Environment which verifies its authenticity. For example, the Condensed can be compared to a list of acceptable Condensed. If the Condensed is found, access to the services offered by the security service 4 may be authorized. In the example described above, the OS2 operating system intervenes only to identify the files corresponding to the request for access to a service of the EC Trust Environment and to search for the related information, which is perfectly operating system, not to calculate the Condensed or to perform an authenticity check.
  • the EC Trust Environment may also not rely on the OS2 operating system and be independent of it, the single figure only representing one possible implementation mode.
  • Driver 5 can obtain the list of files related to the connection request according to the following operating sequence, starting from the observation that each process is seen, within the core of "Linux” (registered trademark), as a task (“struct task_struct”):

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Software Systems (AREA)
  • General Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Computer Hardware Design (AREA)
  • Databases & Information Systems (AREA)
  • Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • General Health & Medical Sciences (AREA)
  • Storage Device Security (AREA)

Abstract

Le procédé selon l'invention concerne l’authentification d'application d'un système informatique comportant un microprocesseur, une pluralité d'applications; un système d'exploitation généraliste (OS2), apte à exécuter et à gérer lesdites applications, ainsi qu'à associer à chaque identifiant d'application (3) les Informations d'Identification nécessaires à son exécution; et un Environnement de Confiance (EC) offrant des services à ces applications. Préalablement à tout accès aux services de l'Environnement de Confiance (EC) par une application, ce procédé exécute une opération de 'hashage' sur les Informations d'Identification de cette application et l'Environnement de Confiance (EC) vérifie l'authenticité du résultat du 'hashage'.

Description

PROCEDE D'AUTHENTIFICATION D'APPLICATIONS D'UN
SYSTEME INFORMATIQUE
La présente invention concerne un procédé d'authentification d'applications d'un système informatique.
On considère un système informatique dans lequel un certain nombre de services dits « de confiance » évoluent dans un environnement local sécurisé (« Environnement de Confiance »). Ces services offrent des fonctionnalités qui peuvent être invoquées depuis l'extérieur de l'Environnement de Confiance. On souhaite donc pouvoir contrôler qui (quelle application) a le droit d'invoquer chaque fonctionnalité.
On peut, à titre d'exemple, prendre le cas d'un agent de gestion des droits numériques DRM (« Digital Rights Management ») s 'exécutant dans l'Environnement de Confiance. Cet agent DRM gère l'autorisation de lecture de fichiers MP3 protégés par une licence DRM. Cette licence comporte, par exemple, un droit de lecture du fichier MP3 jusqu'à une date limite. L'agent DRM est chargé de vérifier que les conditions de la licence sont respectées. Le fait d'évoluer dans un Environnement de Confiance l'aide à assurer sa mission : il dispose, par exemple, de garanties sur l'heure et la date du système local. Si les conditions sont respectées, l'agent DRM autorise la lecture du fichier MP3. Pour cela, il doit alors fournir à l'application standard "player MP3" (qui s'exécute en zone dite standard, c'est-à-dire à l'extérieur de l'Environnement de Confiance) la clé de décodage du fichier MP3. De manière évidente, l'agent DRM ne devrait pas fournir cette clé à une application "player MP3" inconnue (qui, par exemple, pourrait la poster sur Internet...). On voit bien dans cet exemple que le service sécurisé (agent DRM) doit authentifier l'application standard ("player MP3") qui invoque la fonctionnalité de lecture du fichier MP3.
Par ailleurs, il est facile pour un service local d'authentifier une autre application locale dans des environnements fermés, que ce soit des systèmes d'exploitation fermés (c'est-à-dire dans lesquels toutes les applications sont installées initialement, sous le contrôle d'un administrateur, ou utilisateur habilité) ou des environnements d'exécution. En effet, s'il s'agit d'un système exploitation fermé, l'installation même de l'application représente une garantie de son authenticité puisque seules des personnes autorisées peuvent effectuer cette opération. S'il s'agit d'un environnement d'exécution (machine virtuelle), le problème n'est guère plus compliqué car le format de l'application est conçu pour fournir à la machine virtuelle les moyens de vérifier son authenticité ou son intégrité (par construction, une machine virtuelle manipule le code des applications qu'elle exécute).
Le problème est autrement plus complexe dans le cas d'un système ouvert où de nouvelles applications peuvent être librement téléchargées et installées, et où il existe de nombreux outils pour développer, modifier, déboguer, tracer des applications. Pourtant, le besoin de trouver une solution est d'autant plus crucial que les systèmes ouverts sont de plus en plus utilisés y compris dans le domaine des systèmes informatiques embarqués (ou « enfouis ») comme les téléphones portables, les lecteurs multimédia portatifs ou les PDA (« Personal Digital Assistant »).
Certains systèmes ont en conséquence fait le choix d'intégrer des mécanismes de sécurité avancés au coeur du système d'exploitation. C'est par exemple le cas des « capabilities » que l'on trouve dans certains systèmes d'exploitation tels que "Linux", "SELinux" (marques déposées) en particulier, où le système d'exploitation intègre la notion d'autorisation (exemple d'autorisation : « une application "player MP3" intègre est autorisée à utiliser les services d'un agent DRM »). Cette solution présente plusieurs inconvénients :
• Elle est intrusive: tout le système d'exploitation (« Operating System »), doit être pensé et réécrit avec cette notion. Un système d'exploitation non prévu à cet effet doit donc subir de profondes modifications pour la mettre en œuvre. « La configuration des autorisations est un casse-tête permanent pour l'administrateur système car il est nécessaire de faire de nombreuses exceptions au cas général ; de plus, les autorisations peuvent évoluer au cours du temps.
• L'authentification de l'application est confiée au système d'exploitation, ce qui n'est pas son rôle. Le rôle d'un système d'exploitation est de gérer des tâches les unes par rapport aux autres, non pas d'effectuer des opérations de sécurité. On sait qu'il est de mauvaise pratique de confier les traitements sécuritaires à une entité généraliste. Il convient au contraire de les regrouper dans un module dédié et restreint.
D'autres solutions, comme celle du modèle dit « Trusted Computing », reposent sur la présence de matériel de sécurité particulier (« TPM » ou "Trusted Platform Module") et d'un mécanisme d'attestation cryptographique. Dans ce cas, le TPM est chargé d'apporter à une entité extérieure des garanties sur l'authenticité du système local. Cependant, l'attestation cryptographique est conçue pour fournir des garanties sur un système global et non pas sur une application donnée (il n'existe pas de système utilisant un TPM pour authentifier une application locale) ; de plus, l'adjonction d'un matériel dédié n'est pas forcément réalisable dans toutes les situations (pour des raisons techniques et/ou commerciales). L'invention a donc plus particulièrement pour but de supprimer ces inconvénients grâce à un procédé permettant de fournir localement, sur un système d'exploitation ouvert, sans le modifier, des garanties sur l'authenticité d'applications "standard" qui s'exécutent en dehors de l'Environnement de Confiance, à des services sécurisés évoluant dans l'Environnement de Confiance, ce procédé permettant d'obtenir trois niveaux de confiance différents :
- une application "Standard (non sécurisée)"
- un système d'exploitation (qui a un certain niveau de privilège) et, - les applications de confiance.
Ce procédé permet l'authentification d'applications d'un système informatique comportant :
- une pluralité d'applications,
- un système d'exploitation généraliste capable d'exécuter et de gérer lesdites applications, notamment d'associer à chaque identifiant d'application les informations nécessaires à son exécution, dites «Informations d'Identification » , - un Environnement de Confiance offrant des services auxdites applications.
Selon l'invention, préalablement à tout accès aux services de l'Environnement de Confiance par une application, ce procédé comprend les phases opératoires suivantes :
- l'exécution d'une opération de "hashage" sur les Informations d'Identification de ladite application ;
- la vérification par l'Environnement de Confiance de l'authenticité du résultat, dit Condensé, de ladite opération de "hashage". Avantageusement, le procédé pourra comporter en outre un composant logiciel, dit « Pilote », permettant l'accès à l'Environnement de Confiance à partir du système d'exploitation, et les opérations pourront alors être effectuées de la manière suivante :
- le Pilote fournit au système d'exploitation l'identifiant de l'application ;
- le système d'exploitation fournit au Pilote les Informations d'Identification ;
- le Pilote exécute l'opération de "hashage" sur les Informations d'Identification et transmet le Condensé à l'Environnement de Confiance.
Avantageusement :
- Les susdites Informations d'Identification pourront comprendre le code exécutable de l'application ainsi, qu'éventuellement, certains noms de fichiers et certains fichiers utilisés par l'application.
- La vérification de l'authenticité du Condensé par l'Environnement de Confiance peut être effectuée par recherche dans une liste de Condensés acceptables.
- Les opérations d'authentification pourront être effectuées au moment de la demande d'accès de l'application à un service de l'Environnement de
Confiance.
- Les opérations d'authentification pourront être effectuées lors d'une phase préalable, dite de "login" (ou d'enregistrement) qui permet d'authentifier l'application préalablement à toute demande d'accès aux services de l'Environnement de Confiance.
- Selon le résultat de la vérification du Condensé, l'Environnement de Confiance pourra accorder à l'application des droits d'accès différents à ses services.
- Les services offerts par l'Environnement de Confiance pourront comporter au moins l'accès à certaines ressources du système informatique. - Les ressources du système informatique contrôlées par l'Environnement de Confiance pourront comporter des moyens de chiffrement cryptographique.
- Les ressources du système informatique contrôlées par l'Environnement de Confiance pourront comporter des droits d'utilisation de contenus (DRM).
Avantageusement, l'Environnement de Confiance (EC) pourra s'exécuter dans un mode sécurisé du microprocesseur, qui apportera des garanties de sécurité accrues.
L'invention concerne également un système d'authentification d'applications mettant en œuvre le procédé précédemment défini et pouvant éventuellement s'exécuter sur un appareil portable tel qu'un téléphone portable, un lecteur audio ou vidéo, un assistant personnel PDA, etc.
Un mode d'exécution de l'invention sera décrit ci-après, à titre d'exemple non limitatif, avec référence au dessin annexé dans lequel :
La figure unique est une représentation schématique de l'architecture d'un système d'authentification selon l'invention.
Dans cet exemple, le terminal 1 utilise :
• un système d'exploitation ouvert OS2 (tel que, par exemple, "Linux", "Windows", "Solaris" ... (marques déposées)). Bien entendu, ce système d'exploitation OS2 doit être en mesure de gérer les applications que l'on souhaite authentifier. Les applications « standard » (non sécurisées) s'exécutent directement sur ce système d'exploitation. Ce système d'exploitation dispose de deux niveaux globaux de privilèges ("User Mode"/ "Kernel Mode).
• un Environnement de Confiance EC pour l'exécution des services de sécurité 4. Le passage du système d'exploitation OS2 à Y Environnement de Confiance EC est régi par un Pilote 5 ("driver"), c'est-à-dire un petit module (ou "plugin") qui s'exécute dans le noyau du système d'exploitation OS2.
Ce Pilote est conçu de manière à intercepter les demandes d'accès par une application non sécurisée (s 'exécutant sur le système d'exploitation OS2), à un service sécurisé 4 (s 'exécutant dans l' Environnement de Confiance EC).
A la suite de l'interception d'une demande d'accès, le Pilote 5 envoie alors au système d'exploitation OS2 l'identifiant de l'application et lui demande le fichier qui correspond à son code exécutable. Habituellement, les systèmes d'exploitation maintiennent cette information au sein d'une structure de donnée dite "bloc de contrôle" (parfois appelée PCB "Process Control Block").
Le Pilote 5 exécute une opération de "hashage" (telle que, par exemple, SHA- 1) sur le fichier fourni par le système d'exploitation OS2.
Eventuellement, le système d'exploitation OS2 pourra en outre rechercher dans le répertoire du fichier, un fichier appelé "manifeste" qui contient le nom absolu de tous les fichiers importants que l'application utilise (par exemple un fichier de configuration, une librairie partagée, etc.) et fournir ces informations au Pilote 5. Le Pilote 5 exécutera alors l'opération de "hashage" à la fois sur l'exécutable au manifeste, et sur tous les fichiers référencés dans le manifeste (ou seulement certains d'entre eux).
Dans tous les cas, le Condensé identifie de manière unique l'application non sécurisée (dans la mesure où la fonction de "hashage" permet d'éviter les collisions). Il est alors transmis à l'Environnement de Confiance qui vérifie son authenticité. A titre d'exemple, le Condensé pourra être comparé à une liste de Condensés acceptables. Si le Condensé est trouvé, l'accès aux services offerts par le service de sécurité 4 pourra être autorisé. Dans l'exemple précédemment décrit, le système d'exploitation OS2 n'intervient que pour identifier les fichiers correspondant à la demande d'accès à un service de l'Environnement de Confiance EC et pour rechercher les informations afférentes, ce qui est parfaitement du ressort d'un système d'exploitation, et non pas pour calculer le Condensé ou effectuer une vérification d'authenticité.
Par ailleurs, l'Environnement de Confiance EC peut également ne pas reposer sur le système d'exploitation OS2 et être indépendant de lui, la figure unique ne représentant qu'un mode de mise en œuvre possible.
Sur le système d'exploitation "Linux" (marque déposée), le Pilote 5 peut obtenir la liste des fichiers relatifs à la demande de connexion conformément à la séquence opératoire suivante, en partant de la constatation que chaque processus est vu, au sein du noyau de "Linux" (marque déposée), comme une tâche ("struct task_struct") :
• A partir de la tâche correspondant au processus, on obtient les pages que cette tâche a mappées en mémoire ("get_task_mm(task)"). On obtient ainsi une "struct mm_stract".
• On parcourt chacune de ces pages à la recherche d'une page marquée exécutable (mm->mmap & VMJBXECUTABLE). On fait ici l'hypothèse (raisonnable) que cette page appartient à l'exécutable qui correspond au processus.
• On récupère le fichier associé à cette page (mm->mmap->vm_file). Sous le système d'exploitation Linux (marque déposée), il s'agit d'une "struct file".
• On effectue un "hashage" du contenu du fichier ainsi trouvé.
Si on implémente l'utilisation d'un manifeste, il est en outre nécessaire : - D'obtenir le chemin où se trouve ce fichier : il suffit de parcourir récursivement les"dentry" associés au fichier (vm_file->f_dentry),
- de localiser le manifeste dans ce répertoire,
- de localiser chacun des fichiers référencés dans le manifeste, et - de hacher tous les fichiers, y compris le manifeste.

Claims

Revendications
1. Procédé d'authentification d'applications d'un système informatique comportant : un microprocesseur ; une pluralité d'applications ; un système d'exploitation généraliste ouvert (OS2) capable d'exécuter et de gérer lesdites applications, notamment d'associer à chaque identifiant d'application (3) les informations nécessaires à son exécution, dites « Informations d'Identification »; un Environnement de Confiance (EC) offrant des services auxdites applications, ; un composant logiciel, dit « Pilote » (5), permettant l'accès à l'Environnement de Confiance (EC) à partir du système d'exploitation (OS2), caractérisé en ce que, ce procédé exécutant préalablement à tout accès aux services de l'Environnement de Confiance par une application, il comprend les phases opératoires suivantes :
- la fourniture par le Pilote (5) au système d'exploitation de l'identifiant de l'application ;
- le retour par le système d'exploitation au Pilote de certaines informations nécessaires à l'exécution de l'application, dites « Informations d'Identification » ;
- la l'exécution d'une opération de condensation par le Pilote hashage"hashage" sur les des Informations d'Identification de ladite application à l'aide d'une fonction cryptographique de hachage et la transmission du résultat, dit « Condensé » à l'Environnement de Confiance ;
- la vérification par l'Environnement de Confiance de l'authenticité du résultat, dit Condensé, de l'opération de hashage"hashage". dit Condensé. caractérisé en ce qu'il met en œuvre un composant logiciel ou pilote (5) qui régit le passage du système d'exploitation OS2 à l'Environnement de Confiance et qui est conçu de manière à effectuer les opérations suivantes : - l'interception des demandes d'accès par une application non sécurisée à un service sécurisé qui s'exécute dans l'Environnement de confiance
- à la suite d'une interception, l'envoi au système d'exploitation de l'identifiant de l'application et la demande à ce système du fichier qui correspond à son code exécutable
- l'exécution d'un hashage sur le fichier fourni par le système d'exploitation et
- la transmission du condensé de cette opération de hashage à l'Environnement de Confiance en vue de ladite vérification
2. Procédé selon la revendication 1, caractérisé en ce que les Informations d'Identification comprennent au moins le code exécutable de l'application.
3. Procédé selon la revendication 2, caractérisé en ce que les Informations d'Identification comprennent également certains noms de fichiers et certains fichiers utilisés par l'application.
4. Procédé selon la revendication 1 selon la revendication 1, caractérisé en ce que la vérification de l'authenticité du Condensé par l'Environnement de Confiance (EC) est effectuée par recherche dans une liste de condenséCondensés acceptables.
5. Procédé selon la revendication 1 selon la revendication 1, caractérisé en ce que les vérifications d'authenticité les opérations d'authentification sont effectuées lors d'une phase préalable, dite de « login » (ou d'enregistrement) qui permet d'authentifier l'application préalablement à toute demande d'accès à un service aux ressources de l'Environnement de Confiance (EC).
6. Procédé selon l'une des revendications précédentes, caractérisé en ce que, selon le résultat de la vérification du Condensé, l'Environnement de Confiance (EC) accorde à l'application des droits d'accès différents à ses services.
7. Procédé selon l'une des revendications précédentes, caractérisé en ce que les services offerts par l'Environnement de Confiance (EC) comportent au moins l'accès à certaines ressources du système d' exploitation informatique(OS2).
8. Procédé selon la revendication 7, caractérisé en ce que les ressources du système d'exploitation informatique dont l'accès est contrôlées par l'Environnement de Confiance (EC) comportent des moyens de chiffrement cryptographique.
9. Procédé selon la revendication 8, caractérisé en ce que les ressources du système d'exploitation informatique dont l'accès est contrôlécontrôlées par l'Environnement de Confiance (EC) comportent des droits d'utilisation de contenus (DRM).
10. Procédé selon l'une des revendications précédentes, caractérisé en ce que l'Environnement de Confiance (EC) s'exécute dans un mode sécurisé du microprocesseur.
11. Système d'authentification d'applications d'un système informatique comportant : une pluralité d'applications ; un système d'exploitation généraliste (OS2) capable d'exécuter et de gérer lesdites applications, notamment d'associer à chaque identifiant d'application (3) les informations nécessaires à son exécution; un Environnement de Confiance (EC) offrant des services auxdites applications ; un composant logiciel, dit « Pilote » (5), régissant l'accès à l'Environnement de Confiance (EC) à partir du système d'exploitation (OS2), caractérisé en ce qu'il comprend :
- des moyens permettant l'interception par le Pilote (5) des demandes d'accès par une application non sécurisée à un service sécurisé qui s'exécute dans l'Environnement de Confiance ;
- des moyens pour la fourniture par le Pilote (5) au système d'exploitation (OS2) de l'identifiant de l'application interceptée;
- des moyens pour le retourla fourniture par le système d'exploitation au Pilote de certaines informations nécessaires à l'exécution de l'application, dites « Informations d'Identification » ;
- des moyens pour ll'exécution par a condensation par le Pilote (5) d'une opération de hashage"hashage" sur les des Informations d'Identification à l'aide d'une fonction cryptographique de hachage et pour la transmission du résultat,, dit « Condensé » à l'Environnement de Confiance ;
- des moyens pour la vérification de l'authenticité dudit Condensé par l'Environnement de Confiance.
12. Système d'authentification d'applications selon la revendication 11, caractérisé en ce qu'il s'exécute sur un appareil portable tel qu'un téléphone portable, ou un lecteur audio ou vidéo, ou un PDA.
EP06847139A 2005-12-23 2006-12-22 Procede d'authentification d'applications d'un systeme informatique Withdrawn EP1964018A2 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR0513247A FR2895545B1 (fr) 2005-12-23 2005-12-23 Procede d'authentification d'applications d'un systeme informatique
PCT/FR2006/002871 WO2007077362A2 (fr) 2005-12-23 2006-12-22 Procede d'authentification d'applications d'un systeme informatique

Publications (1)

Publication Number Publication Date
EP1964018A2 true EP1964018A2 (fr) 2008-09-03

Family

ID=36764469

Family Applications (1)

Application Number Title Priority Date Filing Date
EP06847139A Withdrawn EP1964018A2 (fr) 2005-12-23 2006-12-22 Procede d'authentification d'applications d'un systeme informatique

Country Status (7)

Country Link
US (1) US20090165148A1 (fr)
EP (1) EP1964018A2 (fr)
JP (1) JP2009521033A (fr)
KR (1) KR20080100171A (fr)
CN (1) CN101379503A (fr)
FR (1) FR2895545B1 (fr)
WO (1) WO2007077362A2 (fr)

Families Citing this family (24)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7519274B2 (en) 2003-12-08 2009-04-14 Divx, Inc. File format for multiple track digital data
US8472792B2 (en) 2003-12-08 2013-06-25 Divx, Llc Multimedia distribution system
EP1999883A4 (fr) 2006-03-14 2013-03-06 Divx Llc Système fédéré de gestion de droits numériques comprenant des systèmes de confiance
KR20100106327A (ko) 2007-11-16 2010-10-01 디브이엑스, 인크. 멀티미디어 파일을 위한 계층적 및 감소된 인덱스 구조
KR101635876B1 (ko) 2009-01-07 2016-07-04 쏘닉 아이피, 아이엔씨. 온라인 콘텐츠를 위한 미디어 가이드의 단일, 공동 및 자동 생성
US8869289B2 (en) 2009-01-28 2014-10-21 Microsoft Corporation Software application verification
EP2507995A4 (fr) 2009-12-04 2014-07-09 Sonic Ip Inc Systèmes et procédés de transport de matériel cryptographique de train de bits élémentaire
US8914534B2 (en) 2011-01-05 2014-12-16 Sonic Ip, Inc. Systems and methods for adaptive bitrate streaming of media stored in matroska container files using hypertext transfer protocol
US9467708B2 (en) 2011-08-30 2016-10-11 Sonic Ip, Inc. Selection of resolutions for seamless resolution switching of multimedia content
US8799647B2 (en) 2011-08-31 2014-08-05 Sonic Ip, Inc. Systems and methods for application identification
US8909922B2 (en) 2011-09-01 2014-12-09 Sonic Ip, Inc. Systems and methods for playing back alternative streams of protected content protected using common cryptographic information
US8964977B2 (en) 2011-09-01 2015-02-24 Sonic Ip, Inc. Systems and methods for saving encoded media streamed using adaptive bitrate streaming
JP5841467B2 (ja) * 2012-03-15 2016-01-13 株式会社日立ソリューションズ 携帯型情報端末及びプログラム
CN103378971B (zh) * 2012-04-27 2017-10-13 厦门雅迅网络股份有限公司 一种数据加密系统及方法
US9313510B2 (en) 2012-12-31 2016-04-12 Sonic Ip, Inc. Use of objective quality measures of streamed content to reduce streaming bandwidth
US9191457B2 (en) 2012-12-31 2015-11-17 Sonic Ip, Inc. Systems, methods, and media for controlling delivery of content
US9152798B1 (en) * 2013-02-04 2015-10-06 Google Inc. Securely enabling content protection across a sandboxed application boundary
US9906785B2 (en) 2013-03-15 2018-02-27 Sonic Ip, Inc. Systems, methods, and media for transcoding video data according to encoding parameters indicated by received metadata
US9094737B2 (en) 2013-05-30 2015-07-28 Sonic Ip, Inc. Network video streaming with trick play based on separate trick play files
US9342331B2 (en) 2013-10-21 2016-05-17 International Business Machines Corporation Secure virtualized mobile cellular device
US9866878B2 (en) 2014-04-05 2018-01-09 Sonic Ip, Inc. Systems and methods for encoding and playing back video at different frame rates using enhancement layers
US9942240B2 (en) 2015-07-21 2018-04-10 Citrix Systems, Inc. Anonymous application wrapping
US10846373B2 (en) 2015-12-03 2020-11-24 Orca Interactive Ltd Method and system for securing a client's access to a DRM agent's services for a video player
US11244077B2 (en) * 2020-01-31 2022-02-08 Fortanix, Inc. Securing data integrity for an application

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5919257A (en) * 1997-08-08 1999-07-06 Novell, Inc. Networked workstation intrusion detection system
US7225333B2 (en) * 1999-03-27 2007-05-29 Microsoft Corporation Secure processor architecture for use with a digital rights management (DRM) system on a computing device
AU6614600A (en) * 1999-07-29 2001-02-19 Intertrust Technologies Corp. Systems and methods for using cryptography to protect secure and insecure computing environments
US7243236B1 (en) * 1999-07-29 2007-07-10 Intertrust Technologies Corp. Systems and methods for using cryptography to protect secure and insecure computing environments
US7117371B1 (en) * 2000-06-28 2006-10-03 Microsoft Corporation Shared names
US6979266B2 (en) * 2001-03-30 2005-12-27 Igt Method and apparatus for downloading peripheral code
EP1331539B1 (fr) * 2002-01-16 2016-09-28 Texas Instruments France Mode protégé pour procésseurs permettre l'utilisation d'unités de gestion de mémoire et d'interruptions
US20040086120A1 (en) * 2002-11-06 2004-05-06 Akins Glendon L. Selecting and downloading content to a portable player

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO2007077362A3 *

Also Published As

Publication number Publication date
KR20080100171A (ko) 2008-11-14
CN101379503A (zh) 2009-03-04
WO2007077362A2 (fr) 2007-07-12
FR2895545B1 (fr) 2008-05-30
US20090165148A1 (en) 2009-06-25
WO2007077362A3 (fr) 2007-08-23
JP2009521033A (ja) 2009-05-28
FR2895545A1 (fr) 2007-06-29

Similar Documents

Publication Publication Date Title
WO2007077362A2 (fr) Procede d'authentification d'applications d'un systeme informatique
US8832047B2 (en) Distributed document version control
EP2513804B1 (fr) Langage de marquage extensible fiable pour services de calcul et de données fiables
US7707642B1 (en) Document access auditing
US20210288973A1 (en) Location-based user authentication
US20070180509A1 (en) Practical platform for high risk applications
FR2767208A1 (fr) Systeme et procede de memorisation protegee de donnees secretes
BRPI0615099A2 (pt) migração de licença digital de primeira plataforma para segunda plataforma
WO2013107362A1 (fr) Procédé et système de protection des données
JP2005141746A (ja) 文書制御システムにおけるオフラインアクセス
US20210303722A1 (en) Compound platform for maintaining secure data
Stach et al. Bringing privacy control back to citizens: DISPEL---a distributed privacy management platform for the internet of things
FR2926149A1 (fr) Dispositif, systemes et procede de demarrage securise d'une installation informatique
Barrera et al. Baton: certificate agility for android's decentralized signing infrastructure
US7568102B2 (en) System and method for authorizing the use of stored information in an operating system
Cho et al. Vulnerabilities of android data sharing and malicious application to leaking private information
Khan et al. A protocol for preventing insider attacks in untrusted infrastructure-as-a-service clouds
KR101265887B1 (ko) 보호 컴퓨팅 환경을 제공하는 방법 및 장치 내에 보호 환경을 설정하는 방법
Stach et al. Bringing Privacy Control back to Citizens
Desausoi et al. " Building a secure and auditable Personal Cloud
Cabianca Ensuring Data Protection
Moroney et al. Expert web services security in the. NET platform
Peasah Eliminating Android Security Threats Arising from Deletion Flaws Using Headless Block Swapping (HBS)
CN117834120A (zh) 基于Kubernetes的密钥处理方法和装置
Ali et al. Incorporating remote attestation for end-to-end protection in web communication paradigm

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20080618

AK Designated contracting states

Kind code of ref document: A2

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LI LT LU LV MC NL PL PT RO SE SI SK TR

17Q First examination report despatched

Effective date: 20101214

RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: TRUSTED LOGIC

DAX Request for extension of the european patent (deleted)
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20120703