EP2124153B1 - Procédés et dispositif de mise en oeuvre de périphériques multifonction avec un gestionnaire de périphérique standard unique - Google Patents

Procédés et dispositif de mise en oeuvre de périphériques multifonction avec un gestionnaire de périphérique standard unique Download PDF

Info

Publication number
EP2124153B1
EP2124153B1 EP09290365A EP09290365A EP2124153B1 EP 2124153 B1 EP2124153 B1 EP 2124153B1 EP 09290365 A EP09290365 A EP 09290365A EP 09290365 A EP09290365 A EP 09290365A EP 2124153 B1 EP2124153 B1 EP 2124153B1
Authority
EP
European Patent Office
Prior art keywords
function
command
file
manager
peripheral
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.)
Active
Application number
EP09290365A
Other languages
German (de)
English (en)
Other versions
EP2124153A1 (fr
Inventor
Thierry Gouraud
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.)
Bull SAS
Original Assignee
Bull 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 Bull SAS filed Critical Bull SAS
Publication of EP2124153A1 publication Critical patent/EP2124153A1/fr
Application granted granted Critical
Publication of EP2124153B1 publication Critical patent/EP2124153B1/fr
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • G06F13/10—Program control for peripheral devices
    • G06F13/102—Program control for peripheral devices where the programme performs an interfacing function, e.g. device driver
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2213/00—Indexing scheme relating to interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • G06F2213/0042—Universal serial bus [USB]

Definitions

  • the present invention relates to the interfaces between a host system and a device and more particularly methods and apparatus for implementing multifunction devices, in particular USB multifunction devices, with a single standard device manager, without a specific device manager.
  • USB devices such as storage, pointing, or data securing devices, that can be connected to a host system that includes an operating system and applications running on that system.
  • the operating system of the latter comprises one or more device drivers , also known as drivers in English terminology, allowing access and use a device.
  • the devices can be implemented with standard device drivers, integrated with the operating system.
  • the devices are, for example, delivered with a CDROM containing the corresponding manager.
  • device managers can or must be signed, that is to say, be cryptographically authenticated by the operating system.
  • API Application Programming Interface in English terminology
  • USB device provides a number of services to the operating system and applications.
  • the USB standard defines the class of a USB device, which can be considered as the definition of the interfaces between the device and the host system. Knowing the class of a USB device must allow the host system to implement a driver for that device and must allow another device provider to implement a compatible device performing similar functions.
  • USB standard defines standard classes such as mass memories and network interfaces.
  • the USB standard also gives the possibility to describe a device as being composite.
  • a device is usually called a composite device or a multifunction device. It makes it possible to implement several functions, for example, a mass memory function and a network interface function. Each function makes it possible to execute different requests, a request being for example the writing, reading, encryption or decryption of a data item.
  • a multifunction device can be thought of as the agglomeration of several sub-devices, each defining its own class. A host system typically sees this device through several handlers: a multifunctional handler that manages agglomeration and a handler by sub-device, that is, by function.
  • USB standard allows a USB device to implement a class that is not defined by the standard.
  • the device provider must provide a device-specific driver for each operating system that it wants to support.
  • a cryptographic device can provide secure storage as well as PKCS # 11 services (standard describing certain cryptographic services and APIs). The device must then implement the mass storage class and a PKCS # 11 class that is specific to it.
  • PKCS # 11 services standard describing certain cryptographic services and APIs.
  • the figure 1 illustrates an example of implementation of such a multifunction device including secure storage and offering PKCS # 11 services.
  • the host system 100 is here connected to a device 105 comprising secure storage and offering the PKCS # 11 services via a USB bus 110.
  • the applications 115 implementing the storage functions of the device use the file system manager 120 itself using the USB storage manager 125, that is to say a standard USB storage driver .
  • the USB storage manager 125 uses the USB multi-function manager 130 using the USB bus manager 135.
  • the applications 140 implementing the PKCS # 11 services use the PKCS # 11 library 145 which is based on the PKCS # 11 150 manager, that is to say a specific PKCS # driver . 11.
  • the PKCS # 11 150 manager uses the USB multi-function manager 130 using the USB bus manager 135.
  • the secure storage services 155 use the USB storage manager 160 which itself makes use of the USB bus manager 165.
  • the PKCS # 11 170 services of the device 105 use the PKCS # 11 manager 175 which itself makes use of the USB bus manager 165.
  • USB device drivers for certain device classes. These device classes generally correspond to popular devices such as keyboards, mice, and USB keys or disks.
  • a USB device should preferably be able to be used with several types of operating systems. It can also be used before or when starting an operating system. In this case, the device must be identified according to one of the classes supported by the BIOS (acronym for Basic Input Output System in English terminology) so that it can access it. Many different BIOSs exist and most do not implement all the protocols and classes defined by the USB consortium. In particular, some BIOSes may refuse to work with a composite device even if they correctly support one of its classes.
  • BIOSes that can boot to a USB disk but are unable to boot to a device identified as a composite device that has one of the classes as the disk class. However, it may be essential to boot to a cryptographic device that provides secure storage. It is therefore important that any BIOS that supports booting to a USB device can boot to such a secure device.
  • USB devices encourage their use in mobile mode, ie their use on a computer that does not belong to the owner of the device.
  • a cryptographic device can be used in a cybercafe to allow encryption and signature of mail. In this kind of use, the device user rarely has the ability or the rights to install a device-specific driver.
  • a function command may be encapsulated in a particular command conforming to this unique interface to be transmitted according to the transmission protocol associated therewith.
  • function commands are scanned for, if necessary, retrieving encapsulated commands. Orders received or extracted are then transmitted, via a routing module, to the corresponding function to be executed.
  • the invention solves at least one of the problems discussed above.
  • the method according to the invention thus makes it possible to connect a multifunction device to a host system which implements only a single device manager.
  • the method further comprises a step of processing at least one datum associated with said datum. least one command to obtain said at least one specific parameter.
  • the method according to the invention is thus able to take into account any specificities related to said first function.
  • the method according to the invention thus allows a host system, when connecting a multifunction device, to implement only a single device manager.
  • said multifunction device is identified by said host system as a standard device adapted to implement said first function.
  • the method of the invention thus allows the host system to use a standard device driver, without requiring the development and installation of one or more particular device managers.
  • said at least one specific parameter is an address of an external device or a data storage address.
  • the multifunction device can be recognized as a mass memory or a network interface.
  • the invention also relates to a computer program comprising instructions adapted to the implementation of each of the steps of the method described above.
  • the invention also relates to a multifunction device device comprising a communication interface adapted to connect said device to a host system, this device being characterized in that it comprises means for processing at least one command received through said communication interface, said at least one command being in accordance with at least one of the functions of said multifunction device, called first function, to allow execution of a request associated with said at least one command by at least one other function distinct from said first function, called second function.
  • the device according to the invention thus makes it possible to connect a multifunction device to a host system that implements only a single device manager.
  • the device further comprises means for identifying said peripheral as a standard peripheral adapted to implement said first function.
  • the device according to the invention thus allows the host system to use a standard device manager, without requiring the development and installation of one or more particular device managers.
  • the device further comprises means for processing at least one specific parameter associated with said at least one command for identifying said second function.
  • the device further comprises conversion means for obtaining said at least one specific parameter from at least one datum associated with said at least one command.
  • conversion means for obtaining said at least one specific parameter from at least one datum associated with said at least one command.
  • said device is adapted to implement storage functions, cryptography and / or network interface.
  • the first function is for example a storage function or a network interface function.
  • the device is of the USB or PCI type.
  • the field of application of the present invention relates to information systems in which a device, for example a USB device, and an application running on an operating system of a host system need to communicate with each other.
  • the invention makes it possible to define an interface between the device and the application using one or more operating system managers, without requiring the use of specific device drivers. Only standard device drivers are implemented.
  • USB devices providing cryptographic services including secure storage and PKCS # 11 services
  • the devices according to the invention can be of different types.
  • peripherals are identified as peripherals of a standard class supported by the majority of operating systems and BIOS. Thus, despite their composite nature, they are not recognized as such.
  • the specificities of the device are here managed by an application and / or a library executing on the host system at the request of the user.
  • the application and / or library uses only the services of the standard class to implement a specific data exchange with the device, so it is no longer necessary to install a specific device manager.
  • the specific functions and the corresponding data are not transmitted as instructions but as simple data, which are transmitted using the functions of the standard device manager.
  • the invention is implemented in the system described with reference to FIG. figure 1 where a device providing a first secure storage function and a second PKCS # 11 service function is connected to a host system.
  • the cryptographic device is here identified according to its first function, that is to say as a device belonging to the standard class of mass storage. Access to the secure storage of this cryptographic device is therefore implemented according to the services of the standard class of mass storage.
  • the second function that is, PKCS # 11 services
  • PKCS # 11 libraries that implements a mechanism based on writing and reading data in a storage area of the device.
  • the requests are transmitted in the form of data associated with particular files, that is to say in the form of commands for writing files, while the responses to these requests are obtained by reading specific files.
  • the files comprising the queries are interpreted by the device to execute the queries and generate the files containing the responses to these queries.
  • Such files are unique in that they do not participate in the secure storage function but serve as a swap area between the library and the device.
  • the specific file with the name REQ_EXEC can be used to send requests to the device and the file called REQ_REP is used to access the responses to the requests.
  • the REQ_EXEC and REQ_REP files are stored in a device memory, preferably the mass memory, which is used, in part, as a swap area between the device and the host system.
  • the device analyzes the contents of this file to retrieve the request related to PKCS # 11 services, executes this request according to the associated data stored in the file REQ_EXEC, or whose references are indicated in this file, and writes the answer to this request in the file REQ_REP.
  • the PKCS # 11 1 library After writing the data from the REQ_EXEC file, the PKCS # 11 1 library reads the contents of the REQ_REP file using the corresponding command to obtain the response to the request.
  • the device must be able to establish the reverse conversion, that is, convert sectors to files, to access the file representing the queries and write the responses to those queries in a file.
  • the implementation of the invention as described above therefore requires a precise knowledge of the file system used by the device.
  • the device since the host system and its user are free to choose the file system used on a given disk, the device must be able to take into consideration all possible types of file managers.
  • the device usually does not have the resources to implement all possible file systems.
  • One solution here is to implement one or more special files in a particular disk of the device (the standard class of mass storage allows a USB device to present multiple disks).
  • the choice of the file manager used for this particular disk is then determined by the device.
  • the file manager is preferably selected from among those supported by the largest number of operating systems.
  • the particular disk is preferably identified by a label and / or a documentation file present on the disk as not before and, advantageously, can not be used to store information of a user but as being reserved for the PKCS # 11 library.
  • the particular disk uses a predetermined file manager while the disk or disks allowing a user to store data use the file manager chosen by the user and / or imposed by the operating system.
  • the figure 2 illustrates an example of implementation of a multifunction device comprising a secure storage and offering PKCS # 11 services, according to the invention.
  • the device shown schematically here offers the same services to the user as the one shown on the figure 1 .
  • the host system 200 is here connected to a device 205 comprising secure storage and offering PKCS # 11 services via a USB bus 210.
  • Applications 215 implementing the storage functions of the device use a file system manager 220 for converting the files into sectors.
  • the file system manager 220 determined by the user or the operating system during device configuration, itself uses the USB storage manager 225, i.e. a standard USB storage driver .
  • the USB storage manager 225 uses the USB bus manager 230.
  • references 215 to 230 uses the general principles implemented for storing data and accessing them in a standard mass storage class device.
  • the applications 235 implementing the PKCS # 11 services use the PKCS # 11 library 240 which transforms the requests to the PKCS # 11 services into write command of these requests in files of the device.
  • the PKCS # 11 240 library uses a system manager of files 220, determined by the device, for converting the write commands of files into sector write commands.
  • the PKCS # 11 library 240 transmits file reading commands to the device to obtain responses to submitted requests. Again, the PKCS # 11 library 240 uses the file system manager 220 determined by the device to convert the file read commands into sector read command.
  • the secure storage services 245 are based on a USB storage manager 250 which is itself based on a reverse file system manager 255 connected to a USB bus manager 260.
  • the PKCS # 11 services 265 are based on a PKCS # 11 manager 270 which is itself based on the inverse file system manager 255 connected to the USB bus manager 260.
  • the inverse file system handler 255 When the inverse file system handler 255 receives a sector read or write command, it determines which disk belongs to the sector.
  • the command is transmitted to the USB storage manager 250 which processes the command in a standard manner.
  • the command is transmitted to the USB storage manager 250 which processes the command in a standard way to read or write the corresponding data in a standard manner.
  • the inverse file system handler 255 is used to determine the file (s) used to transmit the requests related to the PKCS # 11 services and the PKCS # 11 270 handler is enabled to access the files thus determined in order to execute the query or requests contained therein and to write the result of these requests in the response file or files used.
  • FIG. 3 schematically illustrates examples of algorithms implemented in the host system and in the device, for example in the device shown in FIG. figure 2 , respectively, to access a second function of the device using a command for a first function of the device.
  • the first function is here a storage function while the second function is a specific function, not supported by the device manager used, that is to say, not supported by the device manager corresponding to the identifier of the device.
  • the application running on the host system that wants to access a device-specific function forms the corresponding request (step 300). This request is then placed in a specific file to be stored in the device (step 305) using a write command.
  • the specific file is converted into sectors (step 310), preferably into sectors of a particular disk using a predetermined file manager, and a sector write command is executed (step 315).
  • the specific file is thus transmitted to the device as sectors.
  • the host system After writing the specific file to the device, the host system generates a command to read a specific file in the device to obtain the result of the request (step 320).
  • the specific file to be read is converted into sectors to be read (step 325), preferably into sectors of a particular disk using a predetermined file manager, and a read command of these sectors is executed (step 330).
  • the host system then receives the contents of the specific file representing the result of the request (step 340).
  • the device Upon receipt of a sector write command (step 350), the device writes the received data to the sectors targeted by the command (step 355). Simultaneously or sequentially, the sectors received are converted to a file (step 360) using a reverse file manager preferably corresponding to a predetermined device manager.
  • a test is then performed to determine if it is a specific file (step 365). If the written sectors do not match a specific file, the algorithm stops. If, on the contrary, the written sectors correspond to a specific file, the previously written sectors are read (step 370) and the query stored in the file corresponding to these sectors is executed (step 375). Alternatively, the content of the sectors is stored in a temporary memory before the test 365 is performed to avoid, if necessary, a sector reading (access to a temporary memory is generally faster than access to a disk).
  • the result of the query is set as a specific file (step 380) and converted to sectors (step 385) that are written to the disk, preferably a specific disk using a predetermined file manager, of the device (step 390).
  • the result of the query is thus accessible to the host system via a read command sectors corresponding to the specific file.
  • peripherals can be implemented with other types of peripherals, classes of peripherals and / or buses, in particular buses of the PCI type (acronym of Peripheral Component Interconnect ) or PCI Express.
  • the standard class is here, preferably, the class HID (abbreviation of Human Interface Device in English terminology) and the cryptographic services are identified as additional buttons or sensors and accessed without requiring a specific manager.
  • HID abbreviation of Human Interface Device in English terminology
  • PCI or PCI Express network interface providing cryptographic services.
  • the PCI and PCI Express standards allow you to define multifunction peripherals similar to USB composite devices. It is thus possible to implement PCI cards behaving like network cards, representing a first function, and as cards adapted to provide cryptographic services, representing a second function.
  • an implementation of such a map consists, as a standard, of implementing the cryptographic services as a first function (in the sense of the PCI standard) and the network card part as a second function.
  • the card 400 here comprises a PCI or PCI Express 405 interface and a network interface 410.
  • the user or more precisely the operating system of the host system, can access the access services.
  • Such a card nevertheless has the disadvantage of requiring a specific device manager for the cryptography part.
  • IP internet Protocol acronym in English terminology
  • IP wxyz
  • Such an embodiment can be envisaged with other types of bus, in particular a USB bus for a USB network interface providing cryptographic services.
  • the device manager can then be of CDC class (acronym for Device Class Communication in English terminology).

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Stored Programmes (AREA)
  • Information Transfer Systems (AREA)

Description

  • La présente invention concerne les interfaces entre un système hôte et un périphérique et plus particulièrement des procédés et un dispositif de mise en oeuvre de périphériques multifonction, en particulier de périphériques multifonction USB, avec un gestionnaire de périphérique standard unique, sans gestionnaire de périphérique spécifique.
  • Il existe de nombreux périphériques USB, par exemple des dispositifs de stockage, de pointage ou de sécurisation de données, pouvant être connectés à un système hôte comprenant un système d'exploitation et des applications exécutées sur ce système.
  • Pour permettre l'échange de données entre un périphérique USB et le système hôte, le système d'exploitation de celui-ci comprend un ou plusieurs gestionnaires de périphérique, aussi appelés drivers en terminologie anglo-saxonne, permettant l'accès et l'utilisation d'un périphérique. Dans de nombreux cas, les périphériques peuvent être mis en oeuvre avec des gestionnaires de périphérique standard, intégrés au système d'exploitation.
  • Néanmoins, dans les systèmes d'exploitation modernes, il est généralement possible à un fabricant de périphériques de fournir un gestionnaire de périphérique indépendamment du fournisseur du système d'exploitation. Dans ce cas, les périphériques sont, par exemple, livrés avec un CDROM contenant le gestionnaire correspondant.
  • Par ailleurs, il est généralement nécessaire de disposer de droits d'administration élevés pour pouvoir installer un nouveau gestionnaire de périphérique. De plus, dans certains systèmes d'exploitation, les gestionnaires de périphérique peuvent ou doivent être signés, c'est à dire être authentifiés de façon cryptographique par le système d'exploitation.
  • L'accès au périphérique par une application exécutée sur le système hôte est réalisé à travers une interface appelée API (sigle d'Application Programming Interface en terminologie anglo-saxonne) qui définit la manière dont un composant logiciel peut communiquer avec un autre, en particulier avec un gestionnaire de périphérique.
  • Il est rappelé ici qu'un périphérique USB fournit un certain nombre de services au système d'exploitation ainsi qu'aux applications. La norme USB définit la classe d'un périphérique USB, celle-ci peut être considérée comme la définition des interfaces entre le périphérique et le système hôte. Connaître la classe d'un périphérique USB doit permettre au système hôte d'implémenter un gestionnaire pour ce périphérique et doit permettre à un autre fournisseur de périphériques d'implémenter un périphérique compatible réalisant des fonctions analogues.
  • La norme USB définit des classes standard telles que les mémoires de masse et les interfaces réseau.
  • La norme USB donne également la possibilité de décrire un périphérique comme étant composite. Un tel périphérique est généralement appelé périphérique composite ou périphérique multifonction. Il permet de mettre en oeuvre plusieurs fonctions, par exemple, une fonction de mémoire de masse et une fonction d'interface réseau. Chaque fonction permet d'exécuter différentes requêtes, une requête étant par exemple l'écriture, la lecture, le chiffrement ou le déchiffrement d'une donnée. Un périphérique multifonction peut être considéré comme l'agglomération de plusieurs sous-périphériques, chacun définissant sa propre classe. Un système hôte voit généralement ce périphérique au travers de plusieurs gestionnaires : un gestionnaire multifonction qui gère l'agglomération et un gestionnaire par sous-périphérique, c'est-à-dire par fonction.
  • La norme USB permet à un périphérique USB d'implémenter une classe non définie par la norme. Dans ce cas, le fournisseur du périphérique doit fournir un gestionnaire spécifique au périphérique par système d'exploitation qu'il veut supporter.
  • Par exemple, un périphérique cryptographique peut fournir un stockage sécurisé ainsi que les services PKCS#11 (standard décrivant certains services et APIs de cryptographie). Le périphérique doit alors implémenter la classe stockage de masse et une classe PKCS#11 qui lui est spécifique.
  • La figure 1 illustre un exemple de mise en oeuvre d'un tel périphérique multifonction comprenant un stockage sécurisé et offrant les services PKCS#11.
  • Le système hôte 100 est ici relié à un périphérique 105 comprenant un stockage sécurisé et offrant les services PKCS#11 via un bus USB 110.
  • Les applications 115 mettant en oeuvre les fonctions de stockage du périphérique utilisent le gestionnaire de système de fichiers 120 utilisant lui-même le gestionnaire de stockage USB 125, c'est-à-dire un driver standard de stockage USB. Le gestionnaire de stockage USB 125 fait appel au gestionnaire multifonction USB 130 utilisant le gestionnaire de bus USB 135.
  • De la même façon, les applications 140 mettant en oeuvre les services PKCS#11 font appel à la bibliothèque PKCS#11 145 qui est basée sur le gestionnaire PKCS#11 150, c'est-à-dire un driver spécifique aux services PKCS#11. Comme le gestionnaire de stockage USB 125, le gestionnaire PKCS#11 150 fait appel au gestionnaire multifonction USB 130 utilisant le gestionnaire de bus USB 135.
  • Dans le périphérique 105, les services de stockage sécurisé 155 utilisent le gestionnaire de stockage USB 160 qui fait lui-même appel au gestionnaire de bus USB 165.
  • De façon similaire, les services PKCS#11 170 du périphérique 105 utilisent le gestionnaire PKCS#11 175 qui fait lui-même appel au gestionnaire de bus USB 165.
  • Cependant, l'interfaçage d'un périphérique USB avec une application s'exécutant sur le système hôte pose plusieurs problèmes techniques.
  • Tout d'abord, un système d'exploitation donné ne fournit des gestionnaires de périphériques USB que pour certaines classes de périphériques. Ces classes de périphériques correspondent en général aux périphériques les plus répandus tels que les claviers, les souris et les clés ou les disques USB.
  • Par ailleurs, même si les services fournis par un périphérique sont définis par un standard, les mécanismes utilisés pour implémenter l'interface ne sont pas toujours définis. Par exemple dans le cas d'un périphérique fournissant les services définis par PKCS#11, les APIs sont définies entre les applications utilisant PKCS#11 et les fournisseurs de bibliothèques PKCS#11 mais l'interface entre la bibliothèque et le périphérique n'est pas couverte par le standard, ce qui explique qu'il n'y a pas de gestionnaire standard pour interfacer la librairie et le périphérique.
  • II sera également observé qu'un périphérique USB doit, de préférence, pouvoir être utilisé avec plusieurs types de systèmes d'exploitation. Il peut aussi être utilisé avant ou lors du démarrage d'un système d'exploitation. Dans ce cas, le périphérique doit être identifié selon l'une des classes supportées par le BIOS (acronyme de Basic Input Output System en terminologie anglo-saxonne) pour que celui-ci puisse y accéder. De nombreux BIOS différents existent et la plupart n'implémentent pas l'ensemble des protocoles et des classes définis par le consortium USB. En particulier, certains BIOS peuvent refuser de fonctionner avec un périphérique composite même s'ils supportent correctement l'une de ses classes.
  • Par exemple, il existe certains BIOS capables de démarrer sur un disque USB mais incapables de démarrer sur un périphérique identifié comme un périphérique composite dont l'une des classes est la classe disque. Cependant, il peut être essentiel de démarrer sur un périphérique cryptographique fournissant un stockage sécurisé. Il est donc important que n'importe quel BIOS supportant le démarrage sur un périphérique USB puisse démarrer sur un tel périphérique sécurisé.
  • Il sera également observé que l'installation d'un gestionnaire de périphérique nécessite généralement des droits d'administration élevés dans le système hôte. De plus, le système d'exploitation peut limiter voire interdire l'installation de gestionnaires non signés, ce qui implique de devoir signer le gestionnaire spécifique, cette opération se fait généralement à la discrétion du fournisseur du système hôte.
  • Par ailleurs, il est généralement nécessaire de fournir un gestionnaire de périphérique par version du système d'exploitation. La charge d'efforts à fournir en termes de tests et de validation du gestionnaire par le fournisseur du périphérique peut devenir rédhibitoire et entraîner ce fournisseur à limiter le support de son périphérique à un petit nombre de systèmes d'exploitation et de versions.
  • Enfin, le faible encombrement et les fonctionnalités de certains périphériques USB encouragent leur utilisation en mode nomade, c'est à dire leur utilisation sur un ordinateur n'appartenant pas au propriétaire du périphérique. Par exemple, un périphérique cryptographique peut être utilisé dans un cybercafé pour permettre le chiffrement et la signature de courriers. Dans ce genre d'utilisation, l'utilisateur du périphérique a rarement la possibilité ou les droits suffisants pour installer un gestionnaire spécifique au périphérique.
  • A titre d'illustration, la demande de brevet WO 2008/003599 décrit une méthode permettant d'accéder à différentes fonctions d'un périphérique multifonction en utilisant une interface unique. A ces fins, une commande de fonction peut être encapsulée dans une commande particulière conforme à cette interface unique pour être transmise selon le protocole de transmission associé à cette dernière. Après avoir été reçues, les commandes de fonction sont analysées pour, le cas échéant, extraire des commandes encapsulées. Les commandes reçues ou extraites sont alors transmises, via un module de routage, vers la fonction correspondante pour y être exécutées.
  • L'invention permet de résoudre au moins un des problèmes exposés précédemment.
  • L'invention a ainsi pour objet un procédé de traitement d'au moins une commande dans un périphérique multifonction comprenant une interface de communication adaptée à connecter ledit périphérique à un système hôte, ladite au moins une commande étant conforme à au moins l'une des fonctions dudit périphérique multifonction, appelée première fonction, le procédé étant caractérisé en qu'il comprend les étapes suivantes,
    • réception de ladite au moins une commande ;
    • traitement de ladite au moins une commande selon ladite première fonction ;
    • analyse de ladite au moins une commande pour déterminer si au moins un paramètre spécifique lié à au moins une autre fonction, distincte de ladite première fonction, appelée seconde fonction, est associé à ladite au moins une commande ; et,
    • en réponse à ladite analyse, si au moins un paramètre spécifique lié à ladite seconde fonction est associé à ladite au moins une commande, exécution d'une requête liée à ladite seconde fonction.
  • Le procédé selon l'invention permet ainsi de connecter un périphérique multifonction à un système hôte qui ne met en oeuvre qu'un gestionnaire unique de périphérique.
  • Selon un mode de réalisation particulier, le procédé comprend en outre une étape de traitement d'au moins une donnée associée à ladite au moins une commande pour obtenir ledit au moins un paramètre spécifique. Le procédé selon l'invention est ainsi capable de tenir compte d'éventuelles spécificités liées à ladite première fonction.
  • L'invention a également pour objet un procédé de mise en oeuvre d'au moins un service d'un périphérique multifonction comprenant une interface de communication adaptée à connecter ledit périphérique à un système hôte, ledit au moins un service étant appelé par au moins une commande conforme à au moins l'une des fonctions dudit périphérique multifonction, appelée première fonction, le procédé étant caractérisé en qu'il comprend les étapes suivantes,
    • détermination de la fonction dudit périphérique multifonction à laquelle appartient ledit au moins un service ; et,
    • si ledit au moins un service n'appartient pas à ladite première fonction, association à ladite au moins une commande d'une référence audit au moins un service et d'au moins un paramètre spécifique à ladite fonction dudit périphérique multifonction à laquelle appartient ledit au moins un service.
  • Le procédé selon l'invention permet ainsi à un système hôte, lors de la connexion un périphérique multifonction, de ne mettre en oeuvre qu'un gestionnaire unique de périphérique.
  • De façon avantageuse, ledit périphérique multifonction est identifié par ledit système hôte comme un périphérique standard adapté à mettre en oeuvre ladite première fonction. Le procédé selon l'invention permet ainsi au système hôte d'utiliser un gestionnaire de périphérique standard, sans nécessiter le développement et l'installation d'un ou de plusieurs gestionnaires de périphérique particuliers.
  • Selon des modes de réalisation particuliers, ledit au moins un paramètre spécifique est une adresse d'un dispositif externe ou une adresse de stockage de données. Le périphérique multifonction peut ainsi être reconnu comme une mémoire de masse ou une interface réseau.
  • L'invention a également pour objet un programme d'ordinateur comprenant des instructions adaptées à la mise en oeuvre de chacune des étapes du procédé décrit précédemment.
  • L'invention a aussi pour objet un dispositif pour périphérique multifonction comprenant une interface de communication adaptée à connecter ledit périphérique à un système hôte, ce dispositif étant caractérisé en ce qu'il comprend des moyens de traitement d'au moins une commande reçue à travers ladite interface de communication, ladite au moins une commande étant conforme à au moins l'une des fonctions dudit périphérique multifonction, appelée première fonction, pour permettre l'exécution d'une requête associée à ladite au moins une commande par au moins une autre fonction, distincte de ladite première fonction, appelée seconde fonction.
  • Le dispositif selon l'invention permet ainsi de connecter un périphérique multifonction à un système hôte qui ne met en oeuvre qu'un gestionnaire unique de périphérique.
  • De façon avantageuse, le dispositif comprend en outre des moyens d'identification dudit périphérique comme un périphérique standard adapté à mettre en oeuvre ladite première fonction.
  • Le dispositif selon l'invention permet ainsi au système hôte d'utiliser un gestionnaire de périphérique standard, sans nécessiter le développement et l'installation d'un ou de plusieurs gestionnaires de périphérique particuliers.
  • Selon un mode de réalisation particulier, le dispositif comprend en outre des moyens de traitement d'au moins un paramètre spécifique associé à ladite au moins une commande pour identifier ladite seconde fonction.
  • Toujours selon un mode de réalisation particulier, le dispositif comprend en outre des moyens de conversion pour obtenir ledit au moins un paramètre spécifique à partir d'au moins une donnée associée à ladite au moins une commande. Le dispositif selon l'invention est ainsi capable de tenir compte d'éventuelles spécificités liées à ladite première fonction.
  • Toujours selon un mode de réalisation particulier, ledit périphérique est adapté à mettre en oeuvre des fonctions de stockage, de cryptographie et/ou d'interface réseau. La première fonction est par exemple une fonction de stockage ou une fonction d'interface réseau.
  • Toujours selon un mode de réalisation particulier, le périphérique est du type USB ou PCI.
  • D'autres avantages, buts et caractéristiques de la présente invention ressortent de la description détaillée qui suit, faite à titre d'exemple non limitatif, au regard des dessins annexés dans lesquels :
    • la figure 1 illustre un exemple de mise en oeuvre standard d'un périphérique multifonction comprenant un stockage sécurisé et offrant des services PKCS#11 ;
    • la figure 2 illustre un exemple de mise en oeuvre d'un périphérique multifonction comprenant un stockage sécurisé et offrant des services PKCS#11, conformément à l'invention ;
    • la figure 3, comprenant les figures 3a et 3b, illustre schématiquement des exemples d'algorithmes mis en oeuvre dans le système hôte et dans le périphérique, respectivement, pour accéder à une seconde fonction du périphérique à l'aide d'une commande visant une première fonction du périphérique ; et,
    • la figure 4, comprenant les figures 4a et 4b, représente un exemple de mise en oeuvre d'un périphérique multifonction comprenant une interface réseau et offrant des services PKCS#11, de façon standard et conformément à l'invention, respectivement.
  • Le domaine d'application de la présente invention concerne les systèmes d'information dans lesquels un périphérique, par exemple un périphérique USB, et une application tournant sur un système d'exploitation d'un système hôte ont besoin de communiquer entre eux.
  • L'invention permet de définir une interface entre le périphérique et l'application utilisant un ou plusieurs gestionnaires du système d'exploitation, sans nécessiter l'utilisation de gestionnaires de périphérique spécifiques. Seuls des gestionnaires de périphérique standard sont mis en oeuvre.
  • Bien qu'à des fins illustratives la description vise essentiellement des périphériques USB fournissant des services de cryptographie comprenant un stockage sécurisé ainsi que des services PKCS#11, les périphériques conformes à l'invention peuvent être de différentes natures.
  • Conformément à l'invention, les périphériques sont identifiés comme des périphériques d'une classe standard supportée par la majorité des systèmes d'exploitation et des BIOS. Ainsi, malgré leur nature composite, ils ne sont pas reconnus comme tels.
  • Les spécificités du périphérique sont ici gérées par une application et/ou une bibliothèque s'exécutant sur le système hôte à la demande de l'utilisateur. L'application et/ou la bibliothèque n'utilisent que les services de la classe standard pour implémenter un échange de données spécifiques avec le périphérique, il n'est donc plus nécessaire d'installer un gestionnaire de périphérique spécifique. En d'autres termes, les fonctions spécifiques et les données correspondantes ne sont pas transmises comme des instructions mais comme de simples données, celles-ci étant transmises à l'aide des fonctions du gestionnaire de périphérique standard.
  • La mise en oeuvre de ce mécanisme permet d'éviter l'installation de gestionnaires de périphérique spécifiques. Le périphérique est ainsi supporté par la plupart des BIOS ainsi que par la plupart des systèmes d'exploitation supportant la classe standard du périphérique.
  • Par ailleurs, l'utilisation d'un tel périphérique selon un mode nomade est simplifiée en ce que la fourniture logicielle accompagnant le périphérique est limitée à des applications et/ou des bibliothèques. Il n'est pas nécessaire de procéder à l'installation de modules logiciels systèmes ce qui permet d'envisager le support d'un plus grand nombre de systèmes d'exploitation et de versions.
  • Selon un mode de réalisation particulier, l'invention est mise en oeuvre dans le système décrit en référence à la figure 1 où un périphérique offrant une première fonction de stockage sécurisé et une seconde fonction de services PKCS#11 est connecté à un système hôte.
  • Le périphérique cryptographique est ici identifié selon sa première fonction, c'est-à-dire comme un périphérique appartenant à la classe standard de stockage de masse. L'accès au stockage sécurisé de ce périphérique cryptographique est par conséquent implémenté selon les services de la classe standard de stockage de masse.
  • La seconde fonction, c'est-à-dire ici les services PKCS#11, est accédée par l'intermédiaire d'une bibliothèque PKCS#11 qui met en oeuvre un mécanisme basé sur l'écriture et la lecture de données dans une zone de stockage du périphérique. Ainsi, les requêtes sont transmises sous la forme de données associées à des fichiers particuliers, c'est-à-dire sous la forme de commandes d'écriture de fichiers, tandis que les réponses à ces requêtes sont obtenues par la lecture de fichiers spécifiques. Les fichiers comprenant les requêtes sont interprétés par le périphérique pour exécuter les requêtes visées et générer les fichiers comprenant les réponses à ces requêtes.
  • De tels fichiers sont particuliers dans le sens où ils ne participent pas à la fonction de stockage sécurisé mais servent de zone d'échange entre la bibliothèque et le périphérique.
  • Ainsi, par exemple, le fichier spécifique ayant le nom REQ_EXEC peut être utilisé pour transmettre des requêtes au périphérique et le fichier appelé REQ_REP est utilisé pour accéder aux réponses aux requêtes. Les fichiers REQ_EXEC et REQ_REP sont stockés dans une mémoire du périphérique, de préférence la mémoire de masse, qui est utilisée, en partie, comme zone d'échange entre le périphérique et le système hôte.
  • Il convient de remarquer que plusieurs fichiers correspondant à des requêtes peuvent être utilisés. De même, plusieurs fichiers correspondant à des réponses à des requêtes peuvent être utilisés. Il est également possible d'utiliser un même fichier pour mémoriser alternativement les requêtes et les réponses aux requêtes.
  • De façon simplifiée, lorsqu'une application exécutée par le système hôte a besoin d'accéder à un service PKCS#11, elle s'adresse à la bibliothèque correspondante qui transmet la requête et les données associées sous forme de données à écrire dans le fichier REQ_EXEC dans le périphérique. Suite à la réception d'une commande d'écriture d'un fichier, le périphérique détermine si la commande d'écriture concerne le ou les fichiers utilisés pour recevoir les requêtes liées aux services PKCS#11, c'est-à-dire ici si la commande d'écriture vise le fichier REQ_EXEC. Dans l'affirmative, le périphérique analyse le contenu de ce fichier pour extraire la requête liée aux services PKCS#11, exécute cette requête selon les données associées mémorisées dans le fichier REQ_EXEC, ou dont les références sont indiquées dans ce fichier, et écrit la réponse à cette requête dans le fichier REQ_REP.
  • Après avoir écrit les données du fichier REQ_EXEC, la bibliothèque PKCS#11 1 lit le contenu du fichier REQ_REP à l'aide de la commande correspondante pour obtenir la réponse à la requête.
  • On notera cependant que les commandes d'écriture et de lecture de données, notamment dans des périphériques de stockage de type USB, ne visent pas des fichiers en tant que tels mais des secteurs. Un système de gestion de fichiers est mis en oeuvre dans le système hôte pour convertir des fichiers en secteurs. Une connaissance précise de la structure du système de fichiers est ainsi utilisée par les systèmes d'exploitation pour réaliser la traduction des demandes de lectures/écritures de fichiers en demandes de lectures/écritures de secteurs.
  • Le périphérique doit être en mesure d'établir la conversion inverse, c'est-à-dire de convertir des secteurs en fichiers, pour accéder au fichier représentant les requêtes et écrire les réponses à ces requêtes dans un fichier. La mise en oeuvre de l'invention telle que décrite précédemment nécessite donc une connaissance précise du système de fichiers utilisé par le périphérique.
  • Il existe cependant de nombreux types de gestionnaires de fichiers tels que FAT (acronyme de File Allocation Table en terminologie anglo-saxonne), FAT32 (similaire à FAT mais utilisant des adresses codées sur 28 bits) et NTFS (sigle de NT File System en terminologie anglo-saxonne).
  • Par ailleurs, le système hôte et son utilisateur ayant toute latitude pour choisir le système de fichiers utilisé sur un disque donné, le périphérique doit être en mesure de prendre en considération tous les types de gestionnaire de fichiers possibles.
  • Cependant, le périphérique n'a généralement pas les ressources nécessaires pour implémenter tous les systèmes de fichiers possibles.
  • Une solution consiste ici à implémenter un ou plusieurs fichiers spéciaux dans un disque particulier du périphérique (la classe standard de stockage de masse permet à un périphérique USB de présenter plusieurs disques). Le choix du gestionnaire de fichiers utilisé pour ce disque particulier est alors déterminé par le périphérique. Le gestionnaire de fichier est, de préférence, choisi parmi ceux supportés par le plus grand nombre de systèmes d'exploitation.
  • Le disque particulier est, de préférence, identifié par un label et/ou par un fichier documentation présent sur le disque comme ne devant pas et, avantageusement, ne pouvant pas être utilisé pour stocker des informations d'un utilisateur mais comme étant réservé à la bibliothèque PKCS#11.
  • Ainsi, le disque particulier fait appel à un gestionnaire de fichiers prédéterminé tandis que le ou les disques permettant à un utilisateur de stocker des données font appel au gestionnaire de fichiers choisi par l'utilisateur et/ou imposé par le système d'exploitation.
  • La figure 2 illustre un exemple de mise en oeuvre d'un périphérique multifonction comprenant un stockage sécurisé et offrant des services PKCS#11, conformément à l'invention.
  • Le périphérique représenté schématiquement ici offre les mêmes services à l'utilisateur que celui représenté sur la figure 1.
  • Le système hôte 200 est ici relié à un périphérique 205 comprenant un stockage sécurisé et offrant des services PKCS#11 via un bus USB 210.
  • Les applications 215 mettant en oeuvre les fonctions de stockage du périphérique utilisent un gestionnaire de système de fichiers 220 permettant de convertir les fichiers en secteurs. Le gestionnaire de système de fichiers 220, déterminé par l'utilisateur ou le système d'exploitation lors de la configuration du périphérique, utilise lui-même le gestionnaire de stockage USB 225, c'est-à-dire un driver standard de stockage USB. Le gestionnaire de stockage USB 225 fait appel au gestionnaire de bus USB 230.
  • L'ensemble formé par les références 215 à 230 utilise les principes généraux mis en oeuvre pour mémoriser des données et accéder à celles-ci dans un périphérique de classe standard de stockage de masse.
  • Les applications 235 mettant en oeuvre les services PKCS#11 font appel à la bibliothèque PKCS#11 240 qui transforme les requêtes aux services PKCS#11 en commande d'écriture de ces requêtes dans des fichiers du périphérique. La bibliothèque PKCS#11 240 utilise un gestionnaire de système de fichiers 220, déterminé par le périphérique, pour convertir les commandes d'écriture de fichiers en commande d'écriture de secteurs.
  • De même, la bibliothèque PKCS#11 240 transmet au périphérique des commandes de lecture de fichiers pour obtenir les réponses aux requêtes soumises. A nouveau, la bibliothèque PKCS#11 240 utilise le gestionnaire de système de fichiers 220 déterminé par le périphérique pour convertir les commandes de lecture de fichiers en commande de lecture de secteurs.
  • Dans le périphérique 205, les services de stockage sécurisé 245 sont basés sur un gestionnaire de stockage USB 250 qui est lui-même basé sur un gestionnaire inverse de système de fichiers 255 relié à un gestionnaire de bus USB 260.
  • De façon similaire, les services PKCS#11 265 sont basés sur un gestionnaire PKCS#11 270 qui est lui-même basé sur le gestionnaire inverse de système de fichiers 255 relié au gestionnaire de bus USB 260.
  • Lorsque le gestionnaire inverse de système de fichiers 255 reçoit une commande de lecture ou d'écriture de secteurs, il détermine à quel disque appartient le secteur.
  • Si le secteur appartient à un disque permettant à l'utilisateur de mémoriser des données ou d'accéder à celles-ci, la commande est transmise au gestionnaire de stockage USB 250 qui traite la commande de façon standard.
  • Si le secteur appartient au disque particulier utilisé pour mémoriser les fichiers spéciaux, la commande est transmise au gestionnaire de stockage USB 250 qui traite la commande de façon standard pour lire ou écrire les données correspondantes de façon standard. Parallèlement, si la commande est une commande d'écriture, le gestionnaire inverse de système de fichiers 255 est utilisé pour déterminer le ou les fichiers utilisés pour transmettre les requêtes liées aux services PKCS#11 et le gestionnaire PKCS#11 270 est activé pour accéder aux fichiers ainsi déterminés afin d'exécuter la ou les requêtes contenues dans ceux-ci et d'écrire le résultat de ces requêtes dans le ou les fichiers de réponse utilisés.
  • La figure 3, comprenant les figures 3a et 3b, illustre schématiquement des exemples d'algorithmes mis en oeuvre dans le système hôte et dans le périphérique, par exemple dans le périphérique représenté sur la figure 2, respectivement, pour accéder à une seconde fonction du périphérique à l'aide d'une commande visant une première fonction du périphérique.
  • La première fonction est ici une fonction de stockage tandis que la seconde fonction est une fonction spécifique, non supportée par le gestionnaire de périphérique utilisé, c'est-à-dire non supportée par le gestionnaire de périphérique correspondant à l'identifiant du périphérique.
  • L'application exécutée sur le système hôte voulant accéder à une fonction spécifique du périphérique forme la requête correspondante (étape 300). Cette requête est ensuite placée dans un fichier spécifique devant être mémorisé dans le périphérique (étape 305) à l'aide d'une commande d'écriture.
  • Pour écrire le fichier spécifique dans une mémoire du périphérique, le fichier spécifique est converti en secteurs (étape 310), de préférence en secteurs d'un disque particulier utilisant un gestionnaire de fichiers prédéterminé, et une commande d'écriture des secteurs est exécutée (étape 315). Le fichier spécifique est ainsi transmis au périphérique sous forme de secteurs.
  • Après avoir écrit le fichier spécifique dans le périphérique, le système hôte génère une commande de lecture d'un fichier spécifique dans le périphérique pour obtenir le résultat de la requête (étape 320). Le fichier spécifique à lire est converti en secteurs à lire (étape 325), de préférence en secteurs d'un disque particulier utilisant un gestionnaire de fichiers prédéterminé, et une commande de lecture de ces secteurs est exécutée (étape 330). Le système hôte reçoit alors le contenu du fichier spécifique représentant le résultat de la requête (étape 340).
  • A la réception d'une commande d'écriture de secteurs (étape 350), le périphérique écrit les données reçues dans les secteurs visés par la commande (étape 355). Simultanément ou de façon séquentielle, les secteurs reçus sont convertis en fichier (étape 360) en utilisant un gestionnaire inverse de fichiers correspondant, de préférence, à un gestionnaire de périphérique prédéterminé.
  • Un test est ensuite effectué pour déterminer s'il s'agit d'un fichier spécifique (étape 365). Si les secteurs écrits ne correspondent pas à un fichier spécifique, l'algorithme s'arrête. Si, au contraire, les secteurs écrits correspondent à un fichier spécifique, les secteurs préalablement écrits sont lus (étape 370) et la requête mémorisée dans le fichier correspondant à ces secteurs est exécutée (étape 375). Alternativement, le contenu des secteurs est mémorisé dans une mémoire temporaire avant que le test 365 ne soit effectué pour éviter, si nécessaire, une lecture des secteurs (un accès à une mémoire temporaire est généralement plus rapide qu'un accès à un disque).
  • Le résultat de la requête est mis sous forme de fichier spécifique (étape 380) et converti en secteurs (étape 385) qui sont écrits sur le disque, de préférence un disque spécifique utilisant un gestionnaire de fichiers prédéterminé, du périphérique (étape 390). Le résultat de la requête est ainsi accessible au système hôte via une commande de lecture des secteurs correspondant au fichier spécifique.
  • Comme indiqué précédemment, l'invention peut être mise en oeuvre avec d'autres types de périphériques, classes de périphériques et/ou bus, notamment des bus de type PCI (sigle de Peripheral Component Interconnect en terminologie anglo-saxonne) ou PCI Express.
  • Il est ainsi possible, par exemple, de mettre en oeuvre une souris USB fournissant des services de cryptographie. La classe standard est ici, de préférence, la classe HID (sigle de Human Interface Device en terminologie anglo-saxonne) et les services de cryptographie sont identifiés comme des boutons ou des capteurs supplémentaires et accédés sans nécessiter de gestionnaire spécifique.
  • De même, il est possible de mettre en oeuvre une interface réseau PCI ou PCI Express fournissant des services de cryptographie. Les normes PCI et PCI Express permettent de définir des périphériques multifonction analogues aux périphériques composites USB. Il est ainsi possible d'implémenter des cartes PCI se comportant comme des cartes réseau, représentant une première fonction, et comme des cartes adaptées à fournir des services de cryptographie, représentant une seconde fonction.
  • Comme illustré sur la figure 4a, une implémentation d'une telle carte consiste, de façon standard, à implémenter les services de cryptographie comme une première fonction (au sens de la norme PCI) et la partie carte réseau comme une seconde fonction.
  • La carte 400 comprend ici une interface PCI ou PCI Express 405 ainsi qu'une interface réseau 410. Selon la fonction mise en oeuvre, l'utilisateur, ou plus précisément le système d'exploitation du système hôte, peut accéder aux services d'accès au réseau 415 ou aux services cryptographiques 420.
  • Une telle carte présente néanmoins l'inconvénient d'exiger un gestionnaire de périphérique spécifique pour la partie cryptographie.
  • En mettant en oeuvre l'invention, la carte peut ne fournir qu'une seule fonction carte réseau (au sens de la norme PCI) et donner la visibilité des services cryptographiques au système hôte comme un serveur de cryptographie distant ayant, par exemple, une adresse IP (sigle d'internet Protocol en terminologie anglo-saxonne) particulière (IP=w.x.y.z) alors qu'en fait les trames envoyées à l'adresse IP particulière w.x.y.z sont traitées localement sur la carte sans être émises sur le réseau et les réponses sont générées comme des trames émanant de cette adresse.
  • Comme illustré sur la figure 4b, une telle carte 450 ayant une interface PCI ou PCI Express 455 et une interface réseau 460 n'a besoin que d'un seul gestionnaire de périphérique, ici de type interface réseau, pour accéder aux services d'accès au réseau 465 de la carte où, si l'adresse utilisée est une adresse particulière (IP=w.x.y.z), la commande est transmise aux services cryptographiques 470 et, dans les autres cas (IP ≠ w.x.y.z), la commande est considérée comme une commande réseau classique.
  • Un tel mode de réalisation peut être envisagé avec d'autres types de bus, notamment un bus USB pour une interface réseau USB fournissant des services de cryptographie. Le gestionnaire de périphérique peut alors être de classe CDC (sigle de Communication Device Class en terminologie anglo-saxonne).

Claims (7)

  1. Procédé de traitement d'au moins une commande dans un périphérique multifunction (205, 450) comprenant une interface de communication (260, 455) adaptée à connecter ledit périphérique à un système hôte (200), ladite au moins une commande étant conforme à au moins l'une des fonctions dudit périphérique multifonction, appelée première fonction, le procédé étant caractérisé en qu'il comprend les étapes suivantes,
    - réception (350) de ladite au moins une commande ;
    - traitement (355) de ladite au moins une commande selon ladite première fonction ;
    - analyse (365) de ladite au moins une commande pour déterminer si au moins un paramètre spécifique lié à au moins une autre fonction, distincte de ladite première fonction, appelée seconde fonction est associé à ladite au moins une commande et traitement (360) d'au moins une donnée associée à ladite au moins une commande pour obtenir ledit au moins un paramètre spécifique, ledit au moins un paramètre spécifique étant une adresse de stockage de données et ledit traitement d'au moins une donnée associée à ladite au moins une commande comprenant une étape de conversion de secteurs en fichier ; et,
    - en réponse à ladite analyse, si au moins un paramètre spécifique lié à ladite seconde fonction est associé à ladite au moins une commande, exécution (375) d'une requête liée à ladite seconde fonction.
  2. Procédé selon revendication 1 selon lequel ledit périphérique multifonction est identifié par ledit système hôte comme un périphérique standard
  3. Programme d'ordinateur comprenant des instructions adaptées à la mise en oeuvre de chacune des étapes du procédé selon la revendication 1 ou la revendication 2.
  4. Dispositif pour périphérique multifonction (205, 450) comprenant une interface de communication (260, 455) adaptée à connecter ledit périphérique à un système hôte (200), ce dispositif étant caractérisé en ce qu'il comprend des moyens de traitement (255) d'au moins une commande reçue à travers ladite interface de communication, ladite au moins une commande étant conforme à au moins l'une des fonctions dudit périphérique multifonction, appelée première fonction, lesdits moyens de traitement étant adaptés à traiter ladite au moins une commande reçue selon ladite première fonction, pour permettre l'exécution d'une requête associée à ladite au moins une commande par au moins une autre fonction, distincte de ladite première fonction, appelée seconde fonction, le dispositif comprenant en outre des moyens de traitement d'au moins un paramètre spécifique associé à ladite au moins une commande pour identifier ladite seconde fonction ainsi que des moyens de conversion pour obtenir ledit au moins un paramètre spécifique à partir d'au moins une donnée associée à ladite au moins une commande, lesdits moyens de conversion étant adaptés à convertir des secteurs en fichier.
  5. Dispositif selon la revendication précédente comprenant des moyens d'identification dudit périphérique comme un périphérique standard adapté à mettre en oeuvre ladite première fonction.
  6. Dispositif selon la revendication 4 ou la revendication 6, ledit périphérique étant adapté à mettre en oeuvre des fonctions de stockage, de cryptographie et/ou d'interface réseau, ladite première fonction étant une fonction de stockage ou une fonction d'interface réseau.
  7. Dispositif selon l'une quelconque des revendications 4 à 6, ledit périphérique étant du type USB ou PCI.
EP09290365A 2008-05-21 2009-05-18 Procédés et dispositif de mise en oeuvre de périphériques multifonction avec un gestionnaire de périphérique standard unique Active EP2124153B1 (fr)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
FR0853305A FR2931568B1 (fr) 2008-05-21 2008-05-21 Procedes et dispositif de mise en oeuvre de peripheriques multifonction avec un gestionnaire de peripherique standart unique

Publications (2)

Publication Number Publication Date
EP2124153A1 EP2124153A1 (fr) 2009-11-25
EP2124153B1 true EP2124153B1 (fr) 2013-01-09

Family

ID=40148634

Family Applications (1)

Application Number Title Priority Date Filing Date
EP09290365A Active EP2124153B1 (fr) 2008-05-21 2009-05-18 Procédés et dispositif de mise en oeuvre de périphériques multifonction avec un gestionnaire de périphérique standard unique

Country Status (3)

Country Link
US (1) US8006009B2 (fr)
EP (1) EP2124153B1 (fr)
FR (1) FR2931568B1 (fr)

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP5531521B2 (ja) * 2009-09-11 2014-06-25 富士ゼロックス株式会社 文書管理システム、文書操作装置及びプログラム
US8909916B2 (en) * 2009-11-30 2014-12-09 Red Hat, Inc. Using a PKCS module for opening multiple databases
US9182996B2 (en) 2013-03-12 2015-11-10 Midnight Mosaic Llc Methods and apparatus for USB tunneling through USB printer device class
US9411966B1 (en) * 2013-05-21 2016-08-09 Amazon Technologies, Inc. Confidential data access and storage
US9098303B2 (en) * 2013-09-04 2015-08-04 Red Hat, Inc. Portable computing device providing operating system for host devices
JP6349783B2 (ja) * 2014-02-28 2018-07-04 富士通株式会社 端末装置、サーバ装置、デバイスドライバプログラム及び外部周辺機器制御方法

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR853305A (fr) 1939-03-08 1940-03-15 Tube Ind Participation Ltd Dispositif de commande pour bancs à étirer les tubes
US6758398B1 (en) * 1998-09-11 2004-07-06 L.V. Partners, L.P. Optical reader with ultraviolet wavelength capability
US20070168668A1 (en) * 2005-12-08 2007-07-19 Chang Robert C Media card with command pass through mechanism
CN101529405A (zh) * 2006-07-05 2009-09-09 格马尔托股份有限公司 多功能***装置、相应的方法以及具有通过单个接口通信的***和主机的电子***

Also Published As

Publication number Publication date
EP2124153A1 (fr) 2009-11-25
US8006009B2 (en) 2011-08-23
US20100235545A1 (en) 2010-09-16
FR2931568B1 (fr) 2012-07-13
FR2931568A1 (fr) 2009-11-27

Similar Documents

Publication Publication Date Title
EP2110742B1 (fr) Dispositif portable et procédé de démarrage externe d'une installation informatique
CN104598257B (zh) 远程应用程序运行的方法和装置
EP2124153B1 (fr) Procédés et dispositif de mise en oeuvre de périphériques multifonction avec un gestionnaire de périphérique standard unique
US20130276068A1 (en) Methods and systems for generation of authorized virtual appliances
US10146942B2 (en) Method to protect BIOS NVRAM from malicious code injection by encrypting NVRAM variables and system therefor
CN109542862B (zh) 用于控制文件***的挂载的方法、装置和***
US20190238560A1 (en) Systems and methods to provide secure storage
US6691160B1 (en) Input/output communication networks and booting protocols
CN111259364B (zh) 一种使用国密加密卡的方法、装置、设备及存储介质
US9870263B2 (en) System virtualization instance management for terminal sessions
CN108846129B (zh) 存储数据访问方法、装置及存储介质
EP4187393A1 (fr) Gestion dynamique d'un pare-feu de mémoire
CN112270000B (zh) 密码服务提供方法、装置和计算机可读存储介质
EP2058746B1 (fr) Entité électronique portable, station hôte et procédé associé
US11734429B1 (en) Secure bios-enabled passthrough system
EP2131287A1 (fr) Dispositif électronique de mise à disposition de services autoadaptatifs en fonction de la plateforme de l'équipement hôte avec lequel il est en liaison
US20200287981A1 (en) System and Method for Providing UEFI Protocol Access Control
EP2144169B1 (fr) Gestion d'une mémoire physique partitionnée dans une entité électronique: procédé et dispositif
KR20010088530A (ko) 휴대형 기억매체 및 이 기억매체를 이용하여 리모트컴퓨터의 서비스를 로컬 컴퓨터에서 실행하는 방법
FR3085814A1 (fr) Systeme de communication entre un module cam et un terminal mobile disposant d'une connexion au reseau internet.
EP4115579A1 (fr) Procédé de gestion d'une requête d'accès à un site internet depuis un dispositif d'accès
FR3124288A1 (fr) Technique d’accès à un support de stockage.
FR3124287A1 (fr) Procédé et dispositif de contrôle d’accès à un support de stockage.
CN117234666A (zh) 容器环境下的对象存储操作方法、装置及计算设备
CN112748831A (zh) 一种通过桌面快捷方式打开虚拟应用的方法、装置及介质

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

AK Designated contracting states

Kind code of ref document: A1

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

17P Request for examination filed

Effective date: 20091221

17Q First examination report despatched

Effective date: 20100511

GRAP Despatch of communication of intention to grant a patent

Free format text: ORIGINAL CODE: EPIDOSNIGR1

GRAS Grant fee paid

Free format text: ORIGINAL CODE: EPIDOSNIGR3

GRAA (expected) grant

Free format text: ORIGINAL CODE: 0009210

AK Designated contracting states

Kind code of ref document: B1

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

REG Reference to a national code

Ref country code: GB

Ref legal event code: FG4D

Free format text: NOT ENGLISH

REG Reference to a national code

Ref country code: CH

Ref legal event code: EP

Ref country code: AT

Ref legal event code: REF

Ref document number: 593121

Country of ref document: AT

Kind code of ref document: T

Effective date: 20130115

REG Reference to a national code

Ref country code: IE

Ref legal event code: FG4D

Free format text: LANGUAGE OF EP DOCUMENT: FRENCH

REG Reference to a national code

Ref country code: DE

Ref legal event code: R096

Ref document number: 602009012641

Country of ref document: DE

Effective date: 20130314

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: SI

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20130109

REG Reference to a national code

Ref country code: NL

Ref legal event code: VDEP

Effective date: 20130109

REG Reference to a national code

Ref country code: AT

Ref legal event code: MK05

Ref document number: 593121

Country of ref document: AT

Kind code of ref document: T

Effective date: 20130109

REG Reference to a national code

Ref country code: LT

Ref legal event code: MG4D

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: LT

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20130109

Ref country code: ES

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20130420

Ref country code: NO

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20130409

Ref country code: SE

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20130109

Ref country code: AT

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20130109

Ref country code: IS

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20130509

Ref country code: BG

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20130409

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: FI

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20130109

Ref country code: LV

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20130109

Ref country code: GR

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20130410

Ref country code: NL

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20130109

Ref country code: PL

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20130109

Ref country code: PT

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20130509

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: HR

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20130109

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: RO

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20130109

Ref country code: CZ

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20130109

Ref country code: EE

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20130109

Ref country code: DK

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20130109

Ref country code: SK

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20130109

PLBE No opposition filed within time limit

Free format text: ORIGINAL CODE: 0009261

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: NO OPPOSITION FILED WITHIN TIME LIMIT

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: CY

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20130109

BERE Be: lapsed

Owner name: BULL S.A.S.

Effective date: 20130531

26N No opposition filed

Effective date: 20131010

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: MC

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20130109

REG Reference to a national code

Ref country code: CH

Ref legal event code: PL

REG Reference to a national code

Ref country code: DE

Ref legal event code: R097

Ref document number: 602009012641

Country of ref document: DE

Effective date: 20131010

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: LI

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20130531

Ref country code: CH

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20130531

REG Reference to a national code

Ref country code: IE

Ref legal event code: MM4A

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: BE

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20130531

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: IE

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20130518

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: MT

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20130109

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: TR

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20130109

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: LU

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20130518

Ref country code: HU

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT; INVALID AB INITIO

Effective date: 20090518

Ref country code: MK

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20130109

REG Reference to a national code

Ref country code: FR

Ref legal event code: PLFP

Year of fee payment: 8

REG Reference to a national code

Ref country code: FR

Ref legal event code: PLFP

Year of fee payment: 9

REG Reference to a national code

Ref country code: FR

Ref legal event code: PLFP

Year of fee payment: 10

PGFP Annual fee paid to national office [announced via postgrant information from national office to epo]

Ref country code: IT

Payment date: 20200522

Year of fee payment: 12

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: IT

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20200518

P01 Opt-out of the competence of the unified patent court (upc) registered

Effective date: 20230330

PGFP Annual fee paid to national office [announced via postgrant information from national office to epo]

Ref country code: FR

Payment date: 20230517

Year of fee payment: 15

PGFP Annual fee paid to national office [announced via postgrant information from national office to epo]

Ref country code: GB

Payment date: 20240522

Year of fee payment: 16

PGFP Annual fee paid to national office [announced via postgrant information from national office to epo]

Ref country code: DE

Payment date: 20240517

Year of fee payment: 16