EP3674941B1 - Procédé de fabrication d'une application matérielle metier specifique securisée et modulaire et système d'exploitation associé - Google Patents

Procédé de fabrication d'une application matérielle metier specifique securisée et modulaire et système d'exploitation associé

Info

Publication number
EP3674941B1
EP3674941B1 EP19219571.7A EP19219571A EP3674941B1 EP 3674941 B1 EP3674941 B1 EP 3674941B1 EP 19219571 A EP19219571 A EP 19219571A EP 3674941 B1 EP3674941 B1 EP 3674941B1
Authority
EP
European Patent Office
Prior art keywords
container
business
operating system
containers
hardware
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
EP19219571.7A
Other languages
German (de)
English (en)
Other versions
EP3674941A1 (fr
Inventor
Luc Creti
Albert Ngo
Dominique TRONCHE
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 EP3674941A1 publication Critical patent/EP3674941A1/fr
Application granted granted Critical
Publication of EP3674941B1 publication Critical patent/EP3674941B1/fr
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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/57—Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/30—Creation or generation of source code
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/10—Protecting distributed programs or content, e.g. vending or licensing of copyrighted material ; Digital rights management [DRM]
    • G06F21/12—Protecting executable software
    • G06F21/121—Restricting unauthorised execution of programs
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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/52—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems during program execution, e.g. stack integrity ; Preventing unwanted data erasure; Buffer overflow
    • G06F21/53—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems during program execution, e.g. stack integrity ; Preventing unwanted data erasure; Buffer overflow by executing in a restricted environment, e.g. sandbox or secure virtual machine
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/4401—Bootstrapping
    • G06F9/4406—Loading of operating system
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/445—Program loading or initiating
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/48—Program initiating; Program switching, e.g. by interrupt
    • G06F9/4806—Task transfer initiation or dispatching
    • G06F9/4843—Task transfer initiation or dispatching by program, e.g. task dispatcher, supervisor, operating system
    • G06F9/485—Task life-cycle, e.g. stopping, restarting, resuming execution
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5061—Partitioning or combining of resources
    • G06F9/5077—Logical partitioning of resources; Management or configuration of virtualized resources
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/20—Network architectures or network communication protocols for network security for managing network security; network security policies in general

Definitions

  • the invention relates to the field of methods for manufacturing a secure and modular business-specific hardware application, as well as to the field of operating systems which are capable of managing containers in a generic and minimalist manner and which are intended to be used in a method for manufacturing a secure and modular business-specific hardware application.
  • a computer hardware application is a physical device intended to provide one or more dedicated computing services autonomously.
  • a hardware application usually includes the following elements within its scope: a computer (hardware), an operating system and a set of “business” software, i.e. specific to the IT services of the specific business application envisaged.
  • the hardware configuration of the computer that is part of the hardware application depends on the resources required to implement the business tasks. Typically, the following elements will be found: one or more microprocessors, RAM (random access memory), persistent storage memory (magnetic hard disk or SSD), one or more network interfaces.
  • RAM random access memory
  • persistent storage memory magnetic hard disk or SSD
  • network interfaces one or more network interfaces.
  • This computer may also contain hardware components specifically developed by its manufacturer to help perform business tasks. The addition of such components then offers a significant hardware differentiation of the product compared to a solution based on standard components available on the market.
  • a hardware application is designed to perform a dedicated task (or set of related tasks). It is therefore designed not to be modifiable by adding additional software or hardware that would allow additional tasks to be performed; it is therefore not extensible.
  • the provision of a service in the form of a hardware application makes it possible to eliminate, for its user, the following constraints that arise when the service is offered on an open system: the choice and sizing of the hardware intended to host the service, the choice, installation and configuration of the operating system on the chosen hardware, the installation of the software providing the business services, the resolution of compatibility problems occurring at each level, the securing of the whole (hardware and software protections).
  • the time and ease of deployment are therefore greatly improved by the provision of an IT service in the form of a hardware application.
  • Developing the hardware part of a hardware application is a complex and costly activity requiring skills in various areas of hardware design, covering areas as diverse as electronic board design and case design.
  • Any software publisher wishing to offer its solutions in the form of a hardware application does not necessarily have the skills and resources necessary to develop this hardware part. In this case, the publisher turns to an OEM-type supplier offering hardware that meets the needs of its solution.
  • the hardware supplied contains peripherals that are proprietary to the manufacturer, the software elements required to interact with these peripherals are not integrated into current operating systems or even available for download on the internet as is the case for standard peripherals.
  • the hardware manufacturer provides software (system drivers and libraries) with it to allow application developers to interact with these proprietary peripherals. All of these software elements are an application development kit, also called an SDK (Software Development Kit).
  • microservices architectures are a style of software architecture in which a complex set of applications is decomposed into multiple independent processes (microservices) and loosely coupled, often specialized in a single task. This architecture is opposed to the monolithic architecture in which the same IT services would be provided by a single complex process responsible for the entire service.
  • microservices architectures over monolithic architectures are: improved maintainability of the application, reusability of certain services, improved overall system resilience, improved adaptability of the application to changing needs.
  • a rule of microservices design is the separation of responsibilities of the services that make up the application. Each service is designed to perform one task and only one with the best possible quality of service.
  • this activity requires a high level of expertise in areas of competence that are often not directly related to those required to produce the "business" software to be installed in the hardware application.
  • This means that a specialist in a very specific field of activity and an expert in his field who wishes to produce a hardware application to deliver his know-how in this format does not necessarily have the experts and the hardware infrastructure required to produce the operating system for his hardware application.
  • the present invention will be more particularly applied to operating systems supporting container-type technologies including “Linux” and “FreeBSD” without this list being limiting.
  • this approach would facilitate the adoption of its solution by its customers who are unable to develop the operating system themselves due to lack of the required resources.
  • this approach would ensure that they have a state-of-the-art operating system in terms of functionality, robustness and security, whose suitability for the supplied hardware would be guaranteed by the OEM supplier, without resorting to complex developments.
  • a major technical obstacle making it difficult to implement the supply of a base by an OEM supplier is the fact that, in a traditional architecture, the technical choices made during all stages of the base's manufacturing have an impact on its ability to accommodate business applications and that these technical choices are difficult to modify after the base has been produced.
  • the operating system will often, in the case of a hardware application, be deployed in the form of an in-memory file system as is often the case in the world of embedded software.
  • Limiting the memory space used is therefore an important element, especially since a hardware application is a closed system in which it is not planned to be able to add persistent or non-additional storage spaces.
  • these two types of memory occupation are to the detriment of the space available for business applications and greatly reduce the interest of the solution if the available space becomes too limited.
  • Another solution could be to use a minimal hardened operating system containing a hypervisor allowing the deployment of "commoditized” virtual machines.
  • the business software components could then be deployed in virtual machines. This approach would allow for: genericity of the solution because the operating system would be agnostic with respect to the virtual machines it hosts, independence of the execution environment of the business services with respect to the underlying operating system, independence of the execution environment of the business services between themselves.
  • a state-of-the-art virtualization system provides a good level of isolation of virtual machines from each other and from the operating system.
  • the aim of the present invention is to provide a method for manufacturing a secure and modular specific business hardware application which at least partially overcomes the aforementioned drawbacks.
  • the invention proposes to improve this compromise, by using a rather versatile strategy, to ensure genericity, but also ensuring security by implementing this versatile strategy at a level that is intrinsically more secure than the level of virtual machines that could be spontaneously considered, namely the level of containers which intrinsically offers a level of partitioning between business software components that is slightly lower but still very satisfactory while requiring much fewer hardware and software resources, and much less time to implement these hardware and software resources.
  • the invention in addition to the hardware computer and the application development kit, also offers the manufacturer of a specific business hardware application based on business software components an operating system that is capable of managing containers in a generic and minimalist manner, as well as container models for instantiating the business software components in these containers.
  • this operating system is reduced to a minimum core of essential functions ensuring secure management of containers while maintaining their genericity.
  • the invention therefore proposes on the one hand the addition of an operating system but which remains generic (for genericity) and minimalist (for security), and on the other hand the distribution of the business software components at a container virtualization level rather than at a virtual machine virtualization level, this container level having the double advantage of an intrinsic partitioning still very satisfactory although slightly lower retaining a good level of security and a much lower need for hardware and software resources to operate, as well as a notably greater flexibility and speed, the integration in a closed box completely isolating it from the outside (the box cannot be physically opened without damaging the operation of the specific business hardware application) at least partly compensating for the slight sacrifice in security, moreover largely compensated by the drastic gain in resource reduction and in launch and implementation time of these resources.
  • the present invention proposes a method for manufacturing a secure and modular business-specific hardware application, comprising: a step of selecting: a hardware computer integrated in a closed case which isolates it from the outside so as to make the hardware resources of this hardware computer structurally non-extensible because they are made inaccessible without damage from outside the case, an operating system to manage containers in a generic and minimalist manner, associated with the computer, an application development kit, associated with the operating system and the computer, container models, specific business software components, a step of deploying the specific business software components in containers instantiated on the basis of the container models.
  • the present invention also proposes an operating system, capable of managing containers in a generic and minimalist manner, intended to be used in a method of manufacturing a specific secure and modular business hardware application, characterized in that it comprises: a generic mechanism for managing a non-predetermined number of containers, comprising: a function for installing container models, a function for updating container models, a function for creating a container by instantiating a container model, a function for starting a container, a function for stopping a container, a function for destroying a container, a mechanism for configuring said generic container management mechanism, capable of configuring: the list of containers to be managed, all of the additional components required for the operation of the containers to be managed.
  • the invention comprises one or more of the following features which can be used separately or in partial combination with each other or in total combination with each other, with one or other of the aforementioned objects of the invention.
  • the operating system capable of managing containers in a generic and minimalist manner, comprises: a generic mechanism for managing a non-predetermined number of containers, comprising: a function for installing container models, a function for updating container models, a function for creating a container by instantiating a container model, a function for starting a container, a function for stopping a container, a function for destroying a container, a mechanism for configuring said generic container management mechanism, capable of configuring: the list of containers to be managed, all of the additional components required for the operation of the containers to be managed.
  • said generic container management mechanism comprises only: said function for installing container models, said function for updating container models, said function for creating a container by instantiating a container model, said function for starting a container, said function for stopping a container, said function for destroying a container.
  • said configuration mechanism of said generic container management mechanism is capable of configuring only: said list of containers to be managed, said set of additional components required for the operation of the containers to be managed.
  • said set of additional components required for the operation of the containers to be managed comprises: virtual networks, and/or data volumes, and/or access to specific business hardware components with the access rights of the different containers to said components.
  • the number of software components forming said operating system is less than 100 software components, and preferably is between 50 and 100 software components.
  • the operating system achieves an optimal compromise between genericity on the one hand and security (by reducing the attack surface by reducing the number of software components) on the other.
  • a conventional prior art system comprises approximately 900 software components, while a system already considered to be reduced and optimized because it is rather focused on essential functions still comprises approximately 250 software components.
  • said hardware computer integrated into a closed casing which isolates it from the outside in such a way as to make the hardware resources of this hardware computer structurally non-extensible because they are made inaccessible without damage from outside the casing, already includes the possible specific business hardware component(s).
  • the or one of the specific business hardware components is a cryptographic card which is advantageously capable of producing/authenticating electronic signatures and/or of carrying out encryption/decryption of data.
  • said hardware computer comprises at least: one or more microprocessors, one or more random access memories, one or more persistent memories, one or more network interfaces.
  • the overall capacity of the RAM(s) is between 5 and 30 GB, preferably between 10 and 20 GB, and the overall capacity of the persistent memory(s) is between 50 and 500 GB, preferably between 100 and 300 GB.
  • said deployment of specific business software components is organized in a micro-services architecture.
  • additional security software components are implemented in said operating system, and/or specific configurations increasing the security level are implemented in said operating system.
  • dedicated business hardware is implemented in the specific business hardware application, additional software components for controlling the dedicated business hardware are implemented in said operating system.
  • the configuration of the entire software portion of the specific business hardware application is hardened to improve its security, and/or the configuration of the operating system is hardened to improve its security.
  • the operating system is a Linux operating system
  • the container management system is the Docker system.
  • FIG. 1 There figure 1 schematically represents an example of a computer system in block diagrams for implementing the method of manufacturing a specific secure and modular business hardware application according to an embodiment of the invention.
  • FIG. 1 schematically represents an example of a computer system in block diagrams for implementing the method of manufacturing a specific secure and modular business hardware application according to an embodiment of the invention.
  • the manufacturing process of a secure and modular business-specific hardware application first includes a selection step and then a deployment step.
  • the selection step several elements are selected from the following elements.
  • a hardware computer integrated in a closed case which isolates it from the outside in such a way as to make the hardware resources of this hardware computer structurally non-extensible because they are made inaccessible without damage from outside the case, these hardware resources comprising standard hardware 1 and hardware dedicated to the business 2.
  • an operating system 3 which is able to manage containers 7 in a generic and minimalist manner, associated with the hardware computer 1 and 2, this operating system 3 including a generic mechanism 4 for managing a non-predetermined number of containers, as well as a configuration mechanism for said generic container management mechanism.
  • management system 5 of the specific business hardware application there is a management system 5 of the specific business hardware application, a configuration system 6 of the specific business hardware application, as well as an application development kit associated with the operating system 3 and the computer 1 and 2 (not shown in the figure 1 ), container models 7, specific business software components capable of controlling dedicated hardware 2.
  • the specific business software components are deployed in containers 7 instantiated based on the container models 7.
  • a containerization system is comparable to a virtualization system which would be very light.
  • the pooling includes the kernel of the machine's operating system, with isolation between the different containers being achieved by the underlying kernel through a namespace-based rights system.
  • the management of the pooling of physical resources is therefore much more optimized in container management systems because it is ensured by a single core, whereas, in the case of virtual machines, there are as many cores as there are virtual machines.
  • Containers can thus be very light compared to virtual machines because the number of components necessary for their operation is very reduced.
  • a basic container will be around 5MB in size, while a virtual machine of equivalent capacity will be around 200MB.
  • Containerization systems can also offer persistent data separation features to improve the resilience of the overall system by requiring the application developer to separate the storage of application code from that of user data.
  • Container management systems also offer the possibility of managing "virtual" networks allowing containers to communicate with each other. These networks are, unless otherwise configured, confined to the machine hosting the operating system and therefore inaccessible from the physical network interfaces of the machine.
  • This isolation of virtual networks ensures secure communications between the different containers in the system.
  • each container can be compared to a set of processes grouped under the same namespace and running under the control of the underlying operating system. These are therefore "active" elements which carry out actual processing.
  • Containers are created (or instantiated) from “templates” or images that contain all the programs and data files needed to run the containers. Images are static, passive elements that do not perform any actual processing.
  • Images are installed in container management systems, either by downloading from an appropriate server that is part of the containerization system, or by an import/export mechanism of an archive file containing the images.
  • the underlying operating system is minimal, containing only the bare minimum to support its own operation, that of the dedicated hardware, and that of the container management system. The goal of a reduced attack surface is therefore achieved.
  • the proposed system is generic and can be used to deploy many types of hardware applications with the same hardware, because it makes no assumptions about the number or function of the containers to be deployed.
  • the system is capable of hosting any container compatible with the operating system and its associated container management system.
  • Each container can, independently of the others, host different interpreters or execute compiled binaries compatible with its execution capabilities.
  • the only limitation to the genericity of the solution is that the kernel of the underlying system must be able to execute all the system calls made by all the containers.
  • the boot time of a container is very short, partly because it does not contain a complete operating system and partly because it uses very efficient file system management systems. The objective of having a system with a low impact on the boot time of hardware applications is therefore also met.
  • Container technologies rely on the resource access isolation capabilities of modern kernels. Thus, a given container does not, by default, have access to the resources handled by other containers, nor to those handled by the operating system that hosts them. Thus, the exploitation of a security flaw present in one of the containers does not affect the other containers, therefore, since the application is correctly divided, the scope of the attack is then limited.
  • Container management systems because containers all use a single kernel on a given machine, provide great efficiency in the management of memory resources and microprocessor computing power (CPU for "Central Processing Unit” in English).
  • the container template system and the ability to organize them hierarchically allows for very efficient management of disk space consumed by reusing different templates.
  • container management systems share the use of a single kernel between the different containers instead of using a virtualization system. This situation results in the fact that, if the kernel can interact with hardware specifically developed for the hardware application, it is also possible to give access to this hardware to the different containers. This solves the problem of access to PCI-express devices, the use of which was not possible through the use of virtual machines, and to USB devices, the use of which through a hypervisor remains problematic to this day.
  • This invention could lead to future developments such as adding an additional level of security by signing container models, or by adding generic administration solutions for hardware applications.
  • the “Trustway” HSM offers an open hardware platform providing high-security cryptographic functions.
  • the OEM "Trustway Proteccio" offer allows the design of complete hardware security hardware applications based on a hardware platform made available by Atos in white label and customizable according to the graphic identity of the publisher.
  • code signing and verification mechanisms bring a new level of security to hardware applications.
  • the proposed distribution allows the deployment of containers with the main constraint that these are compatible with the version and configuration of the kernel of the operating system of the distribution envisaged.
  • This distribution is based on the "Linux” operating system and is built using a build tool called “buildroot”, a tool designed to produce “Linux” distributions for the embedded software world.
  • the container management system chosen for this project is the “Docker” system.
  • the system consists of 70 software components, 3 of which are specific to the operation of the "TrustWay Proteccio" solution.
  • the size occupied on the disk by the system is approximately 200 MB.
  • the disk footprint of the various software components of the base is represented graphically in a file.
  • a dependency graph of the different components will be created and described in a file.
  • Containers hosted on the same machine are also sealed against each other.
  • this device is inaccessible from inside Docker containers.
  • this device has a discretionary option to allow a specific container to have access to this device.
  • a container wishing to access the physical cryptographic module does not need to have the driver (because it is present and shared at the level of the underlying operating system) but only needs to know how to interact with the "Linux" device, which reduces the number of specific software components to be included in the container.
  • This system is based on a configuration file that describes which containers, virtual networks and data volumes must be created to run the hardware application.
  • This file also describes the different options for configuring each of these operations.
  • this "Docker" container management system When the hardware application starts, this "Docker" container management system is automatically triggered and instantiates, in accordance with the configuration file, all the virtual network containers and data volumes necessary for the operation of the hardware application.
  • This system is generic and makes no assumptions about Docker containers or virtual networks to run the hardware application.
  • the hardware application configuration file and the set of Docker container images it references fully define the behavior of the business part of the hardware application.
  • the user manual for this solution specifies the formats of these different elements and in which respective locations they must be installed to create a hardware application based on this solution.
  • Hypervisor A hypervisor is a virtualization platform that allows multiple operating systems to run on a single physical machine at the same time.
  • OEM Original Equipment Manufacturer GB
  • Micro-services architecture A style of software application architecture that contrasts with monolithic architecture.
  • Attack surface The sum of the various entry points through which an unauthorized user could potentially enter a computer system for malicious purposes. Minimizing the attack surface as much as possible is one of the interesting security measures.
  • Business service Function specific to a given application domain performed by computer software.
  • GB Software Development Kit
  • a driver system is a computer program designed to enable another program (often an operating system) • Pilot system to interact with a device. Generally, each device has its own driver. More simply, the driver for a given device is a software program that tells the operating system how to use that device. This software is dedicated to using the device that corresponds to it.
  • • Linux system In Linux, various special files are located in the /dev directory. These files are called device files (GB) and behave differently from ordinary files; they usually allow you to interact with the computer's hardware (e.g., the hard drive).
  • Peripheral A computer peripheral is a hardware device connected to a computer that adds functionality to the computer. The peripheral is not necessarily located outside the computer case and may not even be physically visible.
  • Base An operating system configured specifically for a given purpose intended to be used multiple times in the same configuration.
  • Container or container A container is a collection of processes that are isolated from the rest of the operating system. It runs from a separate image that provides all the files needed to support the processes it contains. By providing an image that contains all of an application's dependencies, the container ensures the application's portability and consistency across various environments.
  • Examples of container management systems include Docker, LXC, Solaris Containers, and FreeBSD jails.
  • Compiled language In a compiled language, before it can be executed, the source code of a program must be translated into "binary" code using instructions supported by the microprocessor of the computer that will execute it. The program responsible for this translation is called a "compiler.” Once compiled, the program can be executed an arbitrary number of times without needing to be translated again. The presence of the compiler is therefore not necessarily required for the execution of the program.
  • • Interpreted language In an interpreted language, the program's source code is executed by a software program called an interpreter. The interpretation operation must be performed as many times as the program needs to be executed. The presence of the interpreter is therefore required for the program to run.
  • In-memory file system In an in-memory file system, files are stored in the computer's RAM instead of being saved to a persistent storage area such as a magnetic hard drive or SSD flash memory. When the computer restarts, all files stored in an "in-memory file system" are lost.
  • Embedded software Embedded software is software that allows a machine, equipped with one or more microprocessors, to operate in order to perform a specific task with limited human intervention. These cover three main functions: • Processing related to the operation of the machine. • Communication with another computer or “Machine to Machine” (GB). • Communication with humans • Core The kernel of an operating system is one of the main parts of the operating system.
  • Hardening In computing, hardening is the process of securing a system. The approach primarily involves reducing the number of installed objects (software, software libraries, tools) to the minimum necessary, as well as removing unnecessary users and rights, while maintaining required functionality. • Hardening (GB) The underlying principle is to reduce the potential attack surface, considering that any installed object is potentially a source of vulnerability. Reducing the number of installed objects therefore reduces the number of possible vulnerabilities for a given system.
  • USB device A computer peripheral device that can be connected via USB (Universal Serial Bus), a standard for a computer bus that allows various types of devices to be connected, most often located outside the computer.
  • PCI-Express device A computer's peripheral hardware that can be connected via PCI-Express, a standard that specifies a serial local bus ("PCI express bus”) and a connector for connecting expansion cards to a computer's motherboard.
  • Container model A container template, sometimes also called an image, is a set of files that allows you to create multiple identical containers. It is the content of the template that defines the functionality of the containers that will be created from this template.
  • HSM "hardware security module” or “Hardware Security Module”
  • Hardware security module GB is a device considered to be practically inviolable and offering cryptographic functions. It is electronic equipment providing a security service which consists of generating, storing and protecting cryptographic keys.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • General Health & Medical Sciences (AREA)
  • Technology Law (AREA)
  • Multimedia (AREA)
  • Bioethics (AREA)
  • Health & Medical Sciences (AREA)
  • Stored Programmes (AREA)

Description

    DOMAINE DE L'INVENTION
  • L'invention concerne le domaine des procédés de fabrication d'une application matérielle métier spécifique sécurisée et modulaire, ainsi que le domaine des systèmes d'exploitation qui sont aptes à gérer des containers de manière générique et minimaliste et qui sont destinés à être utilisés dans un procédé de fabrication d'une application matérielle métier spécifique sécurisée et modulaire.
    • ARRIERE PLAN TECHNOLOGIQUE DE L'INVENTION
  • Une Application matérielle informatique est un dispositif physique destiné à rendre un ou plusieurs services informatiques dédiés de manière autonome.
  • Une Application matérielle comprend usuellement dans son périmètre les éléments suivants : un ordinateur (matériel), un système d'exploitation et un ensemble de logiciels « métiers » c'est-à-dire spécifiques aux services informatiques de l'application métier spécifique envisagée.
  • La configuration matérielle de l'ordinateur faisant partie de l'application matérielle dépend des ressources nécessaires pour mettre en œuvre les tâches métier. On trouvera généralement les éléments suivants : un ou plusieurs microprocesseurs, de la mémoire « vive » RAM, de la mémoire de stockage persistante (disque dur magnétique ou SSD), une ou plusieurs interfaces réseau.
  • Cet ordinateur peut également contenir des composants matériels développés spécifiquement par son fabricant pour participer à la réalisation des tâches métiers. L'adjonction de tels composants offre alors une différenciation matérielle importante du produit par rapport à une solution basée sur les composants standard disponibles sur le marché.
  • Contrairement aux systèmes informatiques ouverts une application matérielle est prévue pour exécuter une tâche (ou un ensemble de tâches connexes) dédiée. Elle est donc conçue pour ne pas être modifiable par adjonction de logiciels ou de matériels supplémentaires qui permettraient de réaliser des tâches additionnelles, elle est alors non extensible.
  • Un avantage intéressant des applications matérielles sur les systèmes informatiques « ouverts » est leur capacité à faciliter le déploiement de services informatiques. En effet, elles offrent leurs services métiers sous forme de solutions de types « clés en main (« Plug And Play » en langue anglaise) faciles à intégrer dans un système informatique complet.
  • Du fait de sa conception « monolithique », la fourniture d'un service sous forme d'application matérielle permet de faire disparaitre, pour son utilisateur, les contraintes suivantes qui se posent lorsque le service est proposé sur un système ouvert : le choix et dimensionnement du matériel destiné à héberger le service, le choix, l'installation et la configuration du système d'exploitation sur le matériel choisi, l'installation du logiciel fournissant les services métiers, la résolution de des problèmes de compatibilité intervenant à chacun des niveaux, la sécurisation de l'ensemble (protections matérielles et logicielles). Le temps et la facilité de déploiement sont donc grandement améliorés par la fourniture d'un service informatique sous forme d'application matérielle.
  • Le niveau d'expertise en informatique requis, de la part de l'utilisateur, de ces solutions est également réduit car l'application matérielle fait disparaitre cette complexité, la reportant entièrement sur le fabriquant du dispositif.
  • Le développement de la partie matérielle d'une application matérielle est une activité complexe et couteuse nécessitant des compétences dans divers domaines du design matériel (« hardware » en langue anglaise) concernant des domaines aussi divers que la conception de cartes électroniques ou la conception du boitier. Tout éditeur informatique désirant proposer ses solutions sous forme d'application matérielle ne dispose pas nécessairement des compétences et des ressources nécessaires pour développer cette partie matérielle. Dans ce cas de figure l'éditeur se tourne vers un fournisseur de type OEM proposant un matériel correspondant aux besoins de sa solution.
  • Lorsque le matériel fourni contient des périphériques propriétaires au fabricant, les éléments logiciels requis pour interagir avec ces périphériques ne sont pas intégrés dans les systèmes d'exploitation courants ni même disponibles en téléchargement sur internet comme c'est le cas pour les périphériques standards. Dans ce cas, le fabriquant du matériel livre avec celui-ci des logiciels (drivers système et librairies) afin de permettre aux développeurs d'applications d'interagir avec ces périphériques propriétaires. L'ensemble de ces éléments logiciels est un kit de développement d'applications encore dénommé SDK (« Software Development Kit » en langue anglais).
  • Dans le monde du développement d'applications informatiques, les architectures de type micro services sont un style d'architecture logicielle à partir duquel un ensemble complexe d'applications est décomposé en plusieurs processus (micro services) indépendants et faiblement couplés, souvent spécialisés dans une seule tâche. Cette architecture s'oppose à l'architecture monolithique dans laquelle les mêmes services informatiques seraient rendus par un seul processus complexe en charge de la totalité du service.
  • Les avantages des architectures en micro services par rapport aux architectures monolithiques sont : l'amélioration de la maintenabilité de l'application, la réutilisabilité de certains services, l'amélioration de la résilience globale du système, l'amélioration de l'adaptabilité de l'application à l'évolution des besoins. Une règle de la conception des micros services est la séparation des responsabilités des services composant l'application. Chaque service étant conçu pour effectuer une tâche et une seule avec la meilleure qualité de service possible.
  • De ce qui précède, il ressort clairement, et c'est là une part importante de leur valeur ajoutée, que les solutions de type application matérielle reportent une grande partie de la complexité de mise en œuvre depuis l'utilisateur de la solution vers le fabriquant de l'application matérielle. Plus particulièrement, concernant le système d'exploitation de l'application matérielle, les tâches suivantes doivent être réalisées : le choix du système d'exploitation, le choix des composants du système à installer, la construction éventuelle du système, la configuration par défaut du système, l'optimisation des performances, la sécurisation (durcissement), la conception et réalisation des procédures d'installation, la conception et réalisation des procédures de mise à jour, l'industrialisation de l'ensemble. La réalisation de ces tâches nécessite un investissement important en temps et en matériel.
  • De plus, cette activité nécessite un niveau d'expertise élevé dans des domaines de compétence souvent sans rapport directs avec ceux nécessaires pour produire les logiciels « métiers » devant être installés dans l'application matérielle. Cela signifie qu'un acteur spécialiste d'un domaine d'activité bien spécifique et expert en son domaine désireux de produire une application matérielle pour délivrer son savoir-faire sous ce format, ne dispose pas nécessairement des experts et de l'infrastructure matérielle requis pour réaliser la production du système d'exploitation de son application matérielle.
  • En outre, lorsque la fourniture du matériel est réalisée en mode OEM, cette tache risquée, critique, et couteuse doit être réalisée par chaque fabriquant d'application matérielle basée sur un matériel OEM donné. Il pourrait donc être intéressant pour le fournisseur du matériel OEM, de livrer en plus du SDK usuel, un système d'exploitation (ou socle) adapté au matériel qu'il fournit.
  • La présente invention sera plus particulièrement appliquée aux systèmes d'exploitation supportant des technologies de type containeurs dont « Linux » et « FreeBSD » sans que cette liste soit limitative.
  • Pour le fournisseur OEM, cette approche faciliterait l'adoption de sa solution par ses clients dans l'incapacité de développer par eux même le système d'exploitation faute des ressources requises. Pour les clients, cette approche serait l'assurance de disposer d'un système d'exploitation à l'état de l'art en termes de fonctionnalités, de robustesse et de sécurité dont le fournisseur OEM garantirait l'adéquation avec le matériel fourni, et ce sans recourir à des développements complexes.
  • Les coûts associés à la production de ce socle seraient ainsi mutualisés entre les différents clients du fournisseur OEM, au lieu d'être répliqués chez chaque client, permettant avec des coûts raisonnables d'obtenir un produit de qualité malgré le niveau d'expertise élevé requis pour le produire. Les profits engendrés par économies ainsi réalisées étant à répartir entre le client et le fournisseur OEM selon des modalités à définir en fonction des marchés.
  • La fourniture d'un socle associé à un matériel donné en mode OEM n'est cependant pas une pratique courante. Un verrou technique important rendant difficile la mise en œuvre de la fourniture d'un socle par un fournisseur OEM est le fait que, dans une architecture classique, les choix techniques réalisés lors de toutes les étapes de la fabrication du socle ont un impact sur sa capacité à accueillir les applications métier et que ces choix techniques sont difficiles à modifier après la production du socle.
  • En particulier, lors de la conception du socle, si on veut pouvoir atteindre un bon niveau de sécurité, il faut veiller à n'introduire dans le socle que le strict minimum des composants logiciels nécessaires. Dans une démarche plus aboutie encore, on peut envisager de modifier ces composants eux-mêmes afin de supprimer ou de désactiver certaines fonctions non nécessaires de ces composants. Le but de cette démarche « minimaliste » est de diminuer la surface d'attaque du socle, c'est-à-dire le nombre de points d'entrée qu'un agent menaçant pourra mettre à profit pour mener des actions malveillantes.
  • Bien que l'on puisse techniquement envisager de construire un socle à partir d'une distribution existante d'un système d'exploitation, en supprimant les éléments non nécessaires, cette démarche de haut en bas (« Top/Down » en langue anglaise) est plutôt à éviter pour obtenir un résultat de qualité, car il serait alors beaucoup plus difficile, à cause de l'intrication des dépendances des différents composants entre eux, de supprimer l'ensemble des composants inutiles. La meilleure démarche consiste en l'application d'une méthode de bas en haut (« Bottom/Up » en langue anglaise) dans laquelle on part d'un système composé du seul noyau auquel on ajoute unitairement les composants logiciels nécessaire au fonctionnement du système.
  • Pour résumer la problématique, il faut garder à l'esprit que, dans le cas de notre socle construit selon l'approche de bas en haut, l'ajout de composants logiciels supplémentaires nécessite de disposer de l'environnement technique et humain, à savoir ordinateurs, logiciels et experts permettant de produire le socle. Cette approche nuirait à l'objectif de réduire la complexité pour les éditeurs d'application matérielle. Il en résulte que tous les composants logiciels nécessaires au fonctionnement de l'application matérielle et à l'accueil des logiciels métiers doivent avoir été inclus dès la production du socle qui se trouve ainsi, figé dans son contenu fonctionnel dès sa fabrication.
  • Cependant l'accueil des composants métiers peut nécessiter l'adjonction de composants dans le socle afin d'assurer leur fonctionnement. Or, il s'agit de proposer un socle convenable pour l'utilisation du matériel fourni par le producteur de la solution OEM sans préjuger ni des applications métier qui vont être amenées à s'exécuter sur l'application matérielle ni des technologies sur lesquelles elles vont reposer.
  • Si ces applications sont basées sur un langage compilé, il faudra fournir, en plus du socle, l'ensemble des outils nécessaires pour compiler des programmes capables de s'exécuter sur le socle. Si ces applications sont basées sur des langages interprétés, elles auront besoin de l'environnement lié à la technologie qu'elles utilisent. Ces technologies sont nombreuses : Java, Python, Ruby, Perl, PHP, NodeJS par exemple.
  • La suppression a postériori de composants logiciels surnuméraires ajoutés à un socle bâti sur la démarche de bas en haut est vouée toutefois à certains problèmes communs avec le cas de l'approche de haut en bas. En effet, l'ensemble de ces facteurs conduit à une sorte de dilemme :
    • ➢ soit on souhaite rendre le socle très polyvalent, on doit ajouter un grand nombre de composants logiciels, on augmente ainsi sa surface d'attaque le rendant ainsi potentiellement plus vulnérable,
    • ➢ soit on construit un socle avec peu de composants donc à faible surface d'attaque mais on restreint les applications métier qu'il est capable d'accueillir diminuant ainsi sa polyvalence et donc son attractivité vis-à-vis de ses clients potentiels.
  • Un autre problème posé par un socle très polyvalent est l'espace de stockage qu'il va occuper qui grossira à mesure que des composants logiciels lui sont ajoutés. En effet, l'espace de stockage persistant disponible dans une application matérielle peut être assez limitée, la taille de la mémoire vive de celle-ci l'étant davantage encore.
  • Or, le système d'exploitation sera souvent, dans le cas d'une application matérielle, déployé sous la forme d'un système de fichier en mémoire comme c'est souvent le cas dans le monde du logiciel embarqué. La limitation de l'espace mémoire utilisé est donc un élément important d'autant plus qu'une application matérielle est un système fermé dans lequel il n'est pas prévu de pouvoir rajouter des espaces de stockages persistants ou non supplémentaires. En outre, ces deux types d'occupation mémoire se font au détriment de la place disponible pour les applications métier diminuent fortement l'intérêt de la solution si la place disponible devient trop restreinte.
  • Il s'agit donc de permettre la fourniture d'un socle au nombre de composants logiciels « minimal » (pour les raisons évoquées ci-dessus) et néanmoins capable d'accueillir une grande diversité d'applications métier réalisés avec de technologies variées et non connues à l'avance afin de convenir au plus grand nombre d'utilisateurs possibles. Afin d'améliorer encore l'attractivité de cette solution, le déploiement des applications métier sur ce socle devra être facile à mettre en œuvre afin d'offrir des temps de développements courts pour la production d'application matérielle basées sur cette solution.
  • Certains arts antérieurs ont essayé de proposer des solutions partielles aux différents problèmes évoqués ci-dessus.
  • La conception d'un système d'exploitation par l'approche de haut en bas pourrait résoudre le problème posé mais, outre les problèmes conceptuels de sécurité inhérents à cette approche déjà évoqués ci-dessus, cette technique n'offre pas d'isolation des services métiers entre eux ni par rapport au système d'exploitation ce qui d'un point de vue de la sécurité n'est pas optimal.
  • Une autre solution pourrait être d'utiliser un système d'exploitation minimal durci contenant d'un hyperviseur permettant de déployer des machines virtuelles « banalisées ». Les composants logiciels métiers pourraient alors être déployés dans des machines virtuelles. Cette approche permettrait d'obtenir : la généricité de la solution car le système d'exploitation serait agnostique par rapport aux machines virtuelles qu'il héberge, l'indépendance de l'environnement d'exécution des services métiers par rapport au système d'exploitation sous-jacent, l'indépendance de l'environnement d'exécution des services métiers entre eux.
  • Du point de vue de la sécurité du système, il s'agit probablement d'une bonne solution envisageable du point de vue de la maximalisation de la sécurité. Car un système de virtualisation à l'état de l'art fournit un niveau d'isolation des machines virtuelles entre elles et vis à vis du système d'exploitation de bonne qualité.
  • Du point de vue de la généricité de la solution, il s'agit probablement encore une fois d'une bonne solution envisageable du point de vue de la maximalisation de la généricité, car la technologie de virtualisation permet de faire travailler des systèmes d'exploitation de types différents (Linux, Windows, FreeBSD) sur le même matériel simultanément.
  • L'utilisation de la technologie de virtualisation permet donc la gestion simultanée d'environnements d'exécution très variés.
  • Cependant, cette solution souffre d'inconvénients importants notamment pour sa mise en œuvre dans le cadre d'une application matérielle. Ces inconvénients sont notamment :
    • ➢ un temps de démarrage des machines virtuelles important. En effet démarrer une machine virtuelle est l'équivalent de démarrer une machine physique avec l'ensemble des phases du processus de démarrage à exécuter. Ce temps de démarrage retarde de manière conséquente le temps nécessaire à obtenir la disponibilité des services métier en cas de redémarrage de l'application matérielle,
    • ➢ une consommation de ressources importantes. Les machines virtuelles nécessitant l'exécution d'un système d'exploitation complet, la consommation de ressources en termes d'utilisation mémoire et de puissance de calcul est augmentée par rapport au cas où les applications s'exécuteraient directement dans le système d'exploitation sous-jacent. Ce point est particulièrement sensible dans le cas d'applications matérielles car, s'agissant de systèmes fermés, l'adjonction de mémoire ou de processeur n'est pas envisageable,
    • ➢ pour les mêmes raisons que précédemment évoquées, la consommation d'espace disque de la solution à base de machines virtuelles est également augmentée dans des proportions considérables,
    • ➢ le mise en boîtier (« packaging » en langue anglaise) des applications métiers sous forme de machines virtuelle est une opération consommatrice de temps et nécessite de mettre en place des processus d'intégration complexes.
    • ➢ bien qu'il s'améliore progressivement, le support des périphériques USB au travers des solutions de virtualisation reste aujourd'hui problématique ce qui peut poser des problèmes si les applications métier doivent accéder à des périphériques USB de l'application matérielle.
    • ➢ enfin, les solutions de virtualisation supportent très mal les périphériques d'extensions non « standard » tels que les cartes PCI express ou autres matériels dédié. En général, de tels périphériques ne sont pas utilisables par les machines virtuelles. Or dans le cas d'une application matérielle, il n'est pas rare d'avoir à gérer ce genre de dispositif matériel.
  • Par conséquent, si la solution à base d'hyperviseur permet d'adresser de manière plutôt satisfaisante certains aspects du problème posé notamment les aspects sécurité et modularité, des inconvénients importants, pour une utilisation dans le domaine des applications matérielles subsistent et font que cette solution est relativement peu pratique à mettre en œuvre. De plus une telle solution risque d'être finalement assez peu attractive pour d'éventuels clients, en raison de la complexité résiduelle importante de la tâche d'adaptation des applications métier. Le document US2018/198824 est considéré comme étant pertinent dans le domaine de gestion de conteneurs dans des systèmes à applications dédiées.
    • OBJETS DE L'INVENTION
  • L'invention est définie dans les revendications indépendantes.
  • Le but de la présente invention est de fournir un procédé de fabrication d'une application matérielle métier spécifique sécurisée et modulaire palliant au moins partiellement les inconvénients précités.
  • Par définition, une application matérielle métier est spécifique et dédiée à un service informatique bien particulier. Un double problème de sécurité et de généricité assez contradictoire, proche d'un véritable dilemme, doit alors être résolu. En effet, si la solution proposée pour fabriquer cette application matérielle métier spécifique n'est pas assez sécurisée, sa vulnérabilité empêchera l'ensemble des clients potentiels de la trouver attractive, tandis qu'au contraire, si elle n'est pas assez générique, sa trop grande spécificité empêchera la plupart des clients potentiels de la trouver attractive. Ainsi, deux familles de stratégies à priori opposées existent pour fabriquer cette application matérielle métier spécifique :
    • ➢ la stratégie complètement dédiée, avec un nombre restreint de constituants logiciels exclusivement focalisés sur le besoin présent, qui offre une bonne sécurité mais une généricité insuffisante, car la surface d'attaque est réduite mais la plateforme de services est figée,
    • ➢ la stratégie polyvalente, avec un nombre restreint de constituants logiciels pour anticiper les nombreuses évolutions potentielles, qui offre une bonne généricité mais une sécurité insuffisante, car la surface d'attaque est élevée tandis que la plateforme de services reste évolutive.
  • L'invention propose d'améliorer ce compromis, en utilisant une stratégie plutôt polyvalente, pour assurer la généricité, mais en assurant également la sécurité par la mise en œuvre de cette stratégie polyvalente à un niveau intrinsèquement plus sécurisé que le niveau des machines virtuelles qui pourrait être spontanément envisagé, à savoir le niveau des containers lequel offre intrinsèquement un niveau de cloisonnement entre composants logiciels métiers légèrement inférieur mais encore très satisfaisant tout en requérant bien moins de ressources matérielles et logicielles, et bien moins de temps pour mettre en œuvre ces ressources matérielles et logicielles.
  • Ce léger sacrifice en termes de sécurité est :
    • ➢ d'une part largement contrebalancé par le gain en réduction de ressources matérielles et logicielles ainsi que par le gain en réduction de temps de lancement et de mise en œuvre de ces ressources matérielles et logicielles,
    • ➢ et d'autre part partiellement compensé par l'utilisation d'un système fermé non extensible isolé de l'extérieur, lequel système fermé, malgré sa taille souvent réduite par rapport à un serveur habituel, supporte très bien le déploiement des containers, notamment grâce à la rationalisation de son système d'exploitation.
  • Pour cela, l'invention, en plus de l'ordinateur matériel et du kit de développement d'applications, offre, au fabriquant d'une application matérielle métier spécifique sur la base de composants logiciels métiers, également un système d'exploitation qui est apte à gérer des containers de manière générique et minimaliste, ainsi que des modèles de containers permettant d'instancier les composants logiciels métiers dans ces containers.
  • Préférentiellement, ce système d'exploitation est réduit à un noyau minimum de fonctions essentielles assurant la gestion sécurisée des containers tout en maintenant leur généricité.
  • Cette démarche est le juste milieu et le bon compromis entre d'une part l'absence totale de système d'exploitation fourni au fabricant d'application matérielle métier spécifique, ce qui est la majorité des cas, requérant ainsi de sa part beaucoup de compétences et d'énergie pour le créer, et d'autre part la fourniture d'un système « clés en main » (« plug and play » en langue anglaise) permettant un emploi plus aisé mais au prix d'une spécificité élevée empêchant ou réduisant notablement l'évolutivité de l'application matérielle métier spécifique ainsi fabriquée.
  • L'invention propose donc d'une part l'adjonction d'un système d'exploitation mais lequel reste générique (pour la généricité) et minimaliste (pour la sécurité), et d'autre part la distribution des composants logiciels métiers à un niveau de virtualisation de containers plutôt qu'à un niveau de virtualisation de machines virtuelles, ce niveau de containers présentant le double avantage d'un cloisonnement intrinsèque encore très satisfaisant quoique légèrement inférieur conservant un bon niveau de sécurité et d'un besoin bien moindre en ressources matérielles et logicielles pour fonctionner, ainsi qu'une souplesse et une rapidité notablement supérieures, l'intégration dans un boîtier fermé l'isolant complètement de l'extérieur (on ne peut pas ouvrir physiquement le boîtier sans endommager le fonctionnement de l'application matérielle métier spécifique) compensant au moins en partie le léger sacrifice de sécurité, du reste largement compensé par le gain drastique en réduction de ressources et en temps de lancement et de mise en œuvre de ces ressources.
  • A cette fin, la présente invention propose un procédé de fabrication d'une application matérielle métier spécifique sécurisée et modulaire, comprenant : une étape de sélection : d'un ordinateur matériel intégré dans un boîtier fermé qui l'isole de l'extérieur de manière à rendre les ressources matérielles de cet ordinateur matériel structurellement non extensibles car rendues inaccessibles sans endommagement depuis l'extérieur du boîtier, d'un système d'exploitation à gérer des containers de manière générique et minimaliste, associé à l'ordinateur, d'un kit de développement d'applications, associé au système d'exploitation et à l'ordinateur, des modèles de containers, des composants logiciels métiers spécifiques, une étape de déploiement des composants logiciels métiers spécifiques dans des containers instanciés sur la base des modèles de containers.
  • A cette fin, la présente invention propose également un système d'exploitation, apte à gérer des containers de manière générique et minimaliste, destiné à être utilisé dans un procédé de fabrication d'une application matérielle métier spécifique sécurisée et modulaire, caractérisé en ce qu'il comprend : un mécanisme générique de gestion d'un nombre non prédéterminé de containers, comprenant : une fonction d'installation des modèles de containers, une fonction de mise à jour des modèles de containers, une fonction de création d'un container par instanciation d'un modèle de container, une fonction de démarrage d'un container, une fonction d'arrêt d'un container, une fonction de destruction d'un container, un mécanisme de configuration dudit mécanisme générique de gestion des containers, apte à configurer: la liste des containers à gérer, l'ensemble des composants additionnels requis pour le fonctionnement des containers à gérer.
  • Un élément important selon des modes de réalisation de l'invention décrite consiste, pour un fournisseur de matériel destiné à la fabrication d'application matérielle, à fournir en plus de son matériel, un système d'exploitation comprenant les éléments suivants :
    • le strict minimum en termes de composants logiciels permettant d'installer d'initialiser, de mettre à jour et de faire fonctionner un système d'exploitation et un système de gestion de containers,
    • un mécanisme générique permettant de gérer, pour un nombre de containers arbitraires et inconnus à l'avance :
      • ∘ l'installation et la mise à jour des modèles de containers,
      • ∘ la création d'un container,
      • ∘ le démarrage d'un container,
      • ∘ l'arrêt d'un container,
      • ∘ la destruction d'un container,
    • un mécanisme de configuration du mécanisme de gestion décrit ci-dessus, configuration permettant, pour une application matérielle donnée, de configurer :
      • ∘ la liste des containers devant être gérés,
      • ∘ l'ensemble des éléments additionnels liés à ces containers (réseaux, volumes de donnée etc.),
    • une configuration « durcie » de l'ensemble des logiciels faisant partie du système,
    • optionnellement, des composants logiciels destinés à renforcer la sécurité du système,
    • le cas échéant, l'ensemble des logiciels additionnels non standards nécessaire à utiliser le matériel spécifique inclus dans l'application matérielle,
    • optionnellement, un ou plusieurs modèles de containers d'exemple ou de gestion destiné à faciliter l'exploitation du matériel spécifique de l'application matérielle ou l'écriture de futurs modèles de containers utilisant ce matériel.
  • Suivant des modes de réalisation préférés, l'invention comprend une ou plusieurs des caractéristiques suivantes qui peuvent être utilisées séparément ou en combinaison partielle entre elles ou en combinaison totale entre elles, avec l'un ou l'autre des objets de l'invention précités.
  • De préférence, le système d'exploitation, apte à gérer des containers de manière générique et minimaliste, comprend : un mécanisme générique de gestion d'un nombre non prédéterminé de containers, comprenant : une fonction d'installation des modèles de containers, une fonction de mise à jour des modèles de containers, une fonction de création d'un container par instanciation d'un modèle de container, une fonction de démarrage d'un container, une fonction d'arrêt d'un container, une fonction de destruction d'un container, un mécanisme de configuration dudit mécanisme générique de gestion des containers, apte à configurer : la liste des containers à gérer, l'ensemble des composants additionnels requis pour le fonctionnement des containers à gérer.
  • De préférence, ledit mécanisme générique de gestion des containers comprend uniquement : ladite fonction d'installation des modèles de containers, ladite fonction de mise à jour des modèles de containers, ladite fonction de création d'un container par instanciation d'un modèle de container, ladite fonction de démarrage d'un container, ladite fonction d'arrêt d'un container, ladite fonction de destruction d'un container.
  • De préférence, ledit mécanisme de configuration dudit mécanisme générique de gestion des containers, est apte à configurer uniquement : ladite liste des containers à gérer, ledit ensemble des composants additionnels requis pour le fonctionnement des containers à gérer.
  • De préférence, ledit ensemble des composants additionnels requis pour le fonctionnement des containers à gérer, comprend : des réseaux virtuels, et/ou des volumes de données, et/ou l'accès à des composants matériels métiers spécifiques avec les droits d'accès des différents containers auxdits composants.
  • De préférence, le nombre des composants logiciels formant ledit système d'exploitation est inférieur à 100 composants logiciels, et de préférence est compris entre 50 et 100 composants logiciels.
  • Ainsi, le système d'exploitation réalise un compromis optimal entre généricité d'une part et sécurité (par diminution de la surface d'attaque en réduisant le nombre de composants logiciels) d'autre part.
  • A titre de comparaison, un système classique de l'art antérieur comprend environ 900 composants logiciels, tandis qu'un système déjà considéré comme réduit et optimisé car plutôt focalisé sur les fonctions essentielles comprend encore environ 250 composants logiciels.
  • De préférence, ledit ordinateur matériel, intégré dans un boîtier fermé qui l'isole de l'extérieur de manière à rendre les ressources matérielles de cet ordinateur matériel structurellement non extensibles car rendues inaccessibles sans endommagement depuis l'extérieur du boîtier, inclut déjà le ou les composants matériels métiers spécifiques éventuels.
  • Ainsi, la sécurité du procédé de fabrication proposé est encore améliorée.
  • De préférence, le ou l'un des composants matériels métiers spécifiques est une carte cryptographique qui est avantageusement apte à réaliser / authentifier les signatures électroniques et/ou à réaliser des chiffrements / déchiffrements de données.
  • Ainsi, la sécurité du procédé de fabrication proposé est encore améliorée.
  • De préférence, ledit ordinateur matériel comprend au moins : un ou plusieurs microprocesseurs, une ou plusieurs mémoires vives, une ou plusieurs mémoires persistantes, une ou plusieurs interfaces réseau.
  • De préférence, la capacité globale de la ou des mémoires vives est comprise entre 5 et 30Go, de préférence comprise entre 10 et 20Go, et la capacité globale de la ou des mémoires persistantes est comprise entre 50 et 500Go, de préférence comprise entre 100 et 300Go.
  • De préférence, ledit déploiement des composants logiciels métiers spécifiques est organisé en une architecture de micro-services.
  • Ainsi, la généricité du procédé de fabrication proposé est encore améliorée.
  • De préférence, des composants logiciels additionnels de sécurité sont implémentés dans ledit système d'exploitation, et/ou des configurations spécifiques augmentant le niveau de sécurité sont implémentées dans ledit système d'exploitation.
  • Ainsi, la sécurité du procédé de fabrication proposé est encore améliorée.
  • De préférence, des matériels métiers dédiés sont implémentés dans l'application matérielle métier spécifique, des composants logiciels additionnels de pilotage des matériels métiers dédiés sont implémentés dans ledit système d'exploitation.
  • Ainsi, des fonctionnalités spécifiques supplémentaires peuvent être ajoutées sans réduire la généricité de manière substantielle.
  • De préférence, la configuration de toute la partie logicielle de l'application matérielle métier spécifique est durcie pour améliorer sa sécurité, et/ou la configuration du système d'exploitation est durcie pour améliorer sa sécurité.
  • Ainsi, la sécurité du procédé de fabrication proposé est encore améliorée.
  • De préférence, le système d'exploitation est un système d'exploitation Linux, le système de gestion des containers est le système Docker.
  • Ainsi, ce système d'exploitation et ce type de containers offre un compromis optimisé entre sécurité et généricité.
  • D'autres caractéristiques et avantages de l'invention apparaîtront à la lecture de la description qui suit d'un mode de réalisation préféré de l'invention, donnée à titre d'exemple et en référence aux dessins annexés.
    • BREVE DESCRIPTION DES DESSINS
  • [ Fig. 1 ] La figure 1 représente schématiquement un exemple de système informatique en schémas bloc pour mettre en œuvre le procédé de fabrication d'une application matérielle métier spécifique sécurisée et modulaire selon un mode de réalisation de l'invention.
    • DESCRIPTION DETAILLEE DE L'INVENTION
  • La figure 1 représente schématiquement un exemple de système informatique en schémas bloc pour mettre en œuvre le procédé de fabrication d'une application matérielle métier spécifique sécurisée et modulaire selon un mode de réalisation de l'invention.
  • Le procédé de fabrication d'une application matérielle métier spécifique sécurisée et modulaire, comprend d'abord une étape de sélection puis une étape de déploiement.
  • Dans l'étape de sélection, sont sélectionnés plusieurs éléments parmi les éléments suivants. D'abord, il y a un ordinateur matériel intégré dans un boîtier fermé qui l'isole de l'extérieur de manière à rendre les ressources matérielles de cet ordinateur matériel structurellement non extensibles car rendues inaccessibles sans endommagement depuis l'extérieur du boîtier, ces ressources matérielles comprenant du matériel standard 1 et du matériel dédié au métier 2. Puis, il y a un système d'exploitation 3 qui est apte à gérer des containers 7 de manière générique et minimaliste, associé à l'ordinateur matériel 1 et 2, ce système d'exploitation 3 incluant un mécanisme 4 générique de gestion d'un nombre non prédéterminé de containers, ainsi qu'un mécanisme de configuration dudit mécanisme générique de gestion des containers. Ensuite, il y a un système de gestion 5 de l'application matérielle métier spécifique, un système de configuration 6 de l'application matérielle métier spécifique, ainsi qu'un kit de développement d'applications associé au système d'exploitation 3 et à l'ordinateur 1 et 2 (non représenté sur la figure 1), des modèles de containers 7, des composants logiciels métiers spécifiques aptes à piloter le matériel dédié 2.
  • Dans l'étape de déploiement, les composants logiciels métiers spécifiques sont déployés dans des containers 7 instanciés sur la base des modèles de containers 7.
  • En préalable à l'exposé des avantages de la solution, et de son adéquation à la résolution du problème posé, une brève introduction aux techniques de containerisation va d'abord être faite.
  • Un système de containerisation est comparable à un système de virtualisation qui serait très allégé.
  • Dans le cas d'un système de virtualisation, seules les ressources matérielles dont la mémoire vive, le processeur et le système de stockage permanent, sont mutualisées, l'ensemble des autres couches étant entièrement dupliquées entre chaque machine virtuelle.
  • Dans le cas d'un système de gestion de containers, la mutualisation inclut le noyau du système d'exploitation de la machine, l'isolation entre les différents containers étant réalisée par le noyau sous-jacent par le biais d'un système de droit basé sur des espaces de nommage.
  • La gestion de la mutualisation des ressources physiques est donc beaucoup plus optimisée dans les systèmes de gestion de containers car elle est assurée par un noyau unique, alors que, dans le cas de machines virtuelles, il y a autant de noyaux que de machines virtuelles.
  • Les containers peuvent ainsi être très allégés par rapport aux machines virtuelles car le nombre de composants nécessaire à leur fonctionnement se trouve très réduit.
  • Pour donner un ordre de grandeur de la quantité de logiciels mis en œuvre dans les deux technologies, un container basique aura une taille d'environ 5Mo là ou une machine virtuelle de capacité équivalente fera environ 200 Mo.
  • Les systèmes de containerisation peuvent également offrir des fonctionnalités de séparation des données persistantes permettant d'améliorer la résilience du système global en obligeant le développeur de l'application à séparer le stockage du code de l'application, de celui des données utilisateur.
  • Quand cette fonction est disponible, lorsqu'un container est détruit, puis recréé, l'ensemble des données du container sont effacées et un containeur « neuf » identique à son image de référence est créé. Dans ce modèle, pour assurer la persistance des données utilisateurs, il convient de créer des « volumes de données » et d'indiquer par configuration au système de gestion des containers que les données utilisateur vont être stockées dans ces volumes de données.
  • Les systèmes de gestion de containers proposent également la possibilité de gérer des réseaux « virtuels » permettant aux containers de communiquer entre eux, ces réseaux étant, sauf configuration contradictoire, confinés à la machine qui héberge le système d'exploitation et donc inaccessible depuis les interfaces réseaux physiques de la machine.
  • Cette isolation des réseaux virtuels, permet d'assurer des communications sûres entre les différents containers du système.
  • En première approximation, chaque container peut être comparé à un ensemble de processus regroupés sous un même espace de nommage et s'exécutant sous le contrôle du système d'exploitation sous-jacent. Il s'agit donc éléments « actifs » qui réalisent des traitements effectifs.
  • Les containers sont créés (ou instanciées) à partir de « modèles » (encore appelés « template » en langue anglaise) ou images qui contiennent l'ensemble des programmes et fichiers de données nécessaires à l'exécution des containers. Les images sont des éléments statiques et passifs qui ne réalisent aucun traitement effectif.
  • Il est possible d'exécuter plusieurs containers à partir de la même image.
  • Les images sont installées dans les systèmes de gestion des containers, soit par téléchargement depuis un serveur approprié faisant partie du système de containerisation, soit par un mécanisme d'importation/exportation de fichier d'archive contenant les images.
  • La solution proposée par des modes de réalisation de l'invention est structurellement semblable à la solution à base de machines virtuelles évoquées précédemment mais l'utilisation de containers en lieu et place des machines virtuelles offre des avantages qui rendent son application bien adaptée pour résoudre le problème posé par les systèmes de type application matérielle.
  • Le système d'exploitation sous-jacent est minimal puisqu'il ne contient que le strict minimum pour assurer son propre fonctionnement, celui du matériel dédié, ainsi que celui du système de gestion de conteneurs. L'objectif d'une surface d'attaque réduite est donc atteint.
  • Le système proposé est générique et pourra servir à décliner de nombreux types d'application matérielle avec le même matériel, car il ne fait aucune hypothèse sur le nombre ou la fonction des containers à déployer.
  • Dans le schéma bloc du système présenté à la figure 1, pour définir une nouvelle application matérielle, seuls les containers et le fichier de configuration du gestionnaire d'application matérielle dépendent des tâches métier et vont être produits par l'éditeur de l'application matérielle. L'ensemble des autres composants est réutilisable sans modification.
  • Le système est capable d'accueillir tout container compatible avec le système d'exploitation et son système de gestion de containers associé.
  • Toute la partie métier des différentes applications matérielles se trouve donc reportée dans les containers et se trouve par conséquent sans impact sur le système sous-jacent.
  • Chaque container peut, indépendamment des autres, héberger des interpréteurs différents ou exécuter des binaires compilés compatibles avec ses capacités d'exécution. La seule limitation à la généricité de la solution est que le noyau du système sous-jacent doit être capable d'exécuter l'ensemble des appels systèmes réalisé par l'ensemble des containers.
  • L'objectif de généricité et de réutilisabilité de la solution est donc également atteint.
  • Le temps de démarrage d'un container est très réduit notamment d'une part du fait qu'il ne contient pas un système d'exploitation complet et d'autre part du fait qu'il utilise des systèmes de gestion très efficaces du système de fichier. L'objectif d'avoir un système ayant un faible impact sur le temps de démarrage des applications matérielles est donc également rempli.
  • Les technologies de containers s'appuient sur les capacités d'isolation de l'accès aux ressources des noyaux modernes. Ainsi un container donné n'a, par défaut, pas accès aux ressources manipulées par les autres containers, pas plus qu'à celles manipulées par le système d'exploitation qui les héberge. Ainsi, l'exploitation d'une faille de sécurité présente dans un des containers, n'affecte pas les autres containers donc, puisque l'application est correctement découpée, la portée de l'attaque s'en trouve alors limitée.
  • Si des ressources doivent être partagées, la configuration va l'indiquer explicitement. Il est donc possible, par configuration, de maitriser le partage des ressources du système d'exploitation et des containers entre eux. On constate donc que l'objectif de cloisonnement est atteint par l'utilisation de cette technique.
  • Les systèmes de gestion de containers, du fait que les containers utilisent tous un noyau unique sur une machine donnée, apportent une grande efficacité dans la gestion des ressources mémoire et puissance de calcul microprocesseur (CPU pour « Central Processing Unit » en langue anglaise).
  • De plus, le système de modèles de containers et la possibilité de les organiser hiérarchiquement permet une gestion très efficace de l'espace disque consommé par réutilisation des différents modèles.
  • Pour mieux bénéficier de cet avantage, il est intéressant de porter une attention particulière au découpage hiérarchique des modèles. Il est à noter que l'invention en elle-même n'a aucun contrôle sur ce découpage et que ces précautions vont être prises par les éditeurs des containers devant être déployés sur la solution proposée par l'invention.
  • L'ensemble de ces caractéristiques concernant l'optimisation de l'utilisation des ressources matérielles font de la solution proposée par l'invention, une solution particulièrement adaptée pour exploiter des applications matérielles en raison de la limitation et de la non-extensibilité de ces ressources matérielles dans le cadre de systèmes fermés.
  • Comme déjà vu précédemment, les systèmes de gestion de containers mutualisent l'utilisation d'un noyau unique entre les différents containers au lieu de faire appel à un système de virtualisation. De cette situation résulte le fait que, si le noyau peut interagir avec du matériel spécifiquement développé pour l'application matérielle, il est également possible de donner l'accès à ce matériel aux différents containers. Ceci règle le problème d'accès aux périphériques PCI-express, dont l'utilisation n'était pas possible au travers de l'utilisation de machines virtuelles, et aux périphériques USB dont l'utilisation au travers d'un hyperviseur reste problématique à ce jour.
  • En résumé, avec la solution proposée par l'invention, il devient donc possible de bénéficier d'une capacité d'isolation et de cloisonnement tout en résolvant les problématiques de temps de démarrage, d'optimisation de l'utilisation des ressources et d'accès aux cartes d'extension PCI-express, et ceci, de manière suffisamment générique pour pouvoir mutualiser cet effort de développement entre de nombreux clients.
  • Cette invention pourra donner lieu à des développements futurs tels l'ajout d'un niveau de sécurité supplémentaire par signature des modèles de containers, ou encore par adjonction de solution d'administration génériques pour application matérielle.
  • Un exemple de mise en œuvre du procédé de fabrication d'une application matérielle métier spécifique sécurisée et modulaire selon des modes de réalisation de l'invention, va maintenant être décrite.
  • Cette mise en œuvre des principes de la solution proposée par l'invention a été effectuée sur la déclinaison OEM du matériel « Trustway Proteccio ».
  • Voici, ci-dessous, une présentation succincte de la plateforme matérielle sur laquelle cette réalisation a été faite.
  • Application matérielle cryptographique, le HSM « Trustway » propose une plateforme matérielle ouverte offrant des fonctions cryptographiques de haut niveau de sécurité.
  • Elle permet aux éditeurs d'embarquer un environnement logiciel complet (système et applications).
  • Au-delà de la sécurité des opérations cryptographiques qu'elle apporte, l'offre « Trustway Proteccio » OEM permet la conception d'applications matérielles de sécurité matérielle complète sur la base d'une plateforme matérielle mise à disposition par la société Atos en marque blanche et personnalisable selon l'identité graphique de l'éditeur.
  • Outre des dispositifs de sécurité physique à la pointe de la technologie, les mécanismes de signature et de vérification du code apportent aux applications matérielles un niveau de sécurité inédit.
  • C'est pour la plateforme matérielle décrite ci-dessus, qu'é été réalisée une distribution propriétaire basée sur le système d'exploitation « Linux » permettant de déployer des containers offrant des services applicatifs capables de tirer parti du matériel cryptographique présent dans l'application matérielle.
  • La distribution proposée permet de déployer des containers avec pour principale contrainte que ceux-ci soient compatibles avec la version et la configuration du noyau du système d'exploitation de la distribution envisagée.
  • Cette distribution est basée sur le système d'exploitation « Linux » et elle est construite en utilisant un outil de construction dénommé « buildroot », outil destiné à produire des distributions « Linux » pour le monde du logiciel embarqué.
  • Le système de gestion de containers retenu pour cette réalisation est le système « Docker ».
  • Pour évaluer la surface d'attaque de la solution obtenue, les éléments suivants peuvent être observés. Le système se compose de 70 composants logiciels dont 3 sont spécifiques au fonctionnement de la solution « TrustWay Proteccio ». La taille occupée sur le disque par le système est d'environ 200 Mo.
  • La liste détaillée de l'ensemble des composants logiciels faisant partie de ce système d'exploitation sera décrite dans un fichier.
  • On notera dans la liste de ces composants l'absence d'interpréteurs Java, Perl, Python ou autres outils similaires dans notre distribution minimale. Celle-ci est cependant capable d'héberger des containers utilisant ces technologies.
  • L'empreinte disque des différents composants logiciels du socle est représentée sous forme graphique dans un fichier.
  • On notera qu'une grande partie de l'empreinte disque de la solution est justifiée par le choix de l'utilisation de la technologie « Docker ».
  • Un graphe de dépendance des différents composants sera réalisé et décrit dans un fichier.
  • La configuration du système d'exploitation a été durcie par nos experts en conformité avec l'état de l'art sur le sujet.
  • L'utilisation de « Docker » permet de bénéficier structurellement d'un cloisonnement lié cette technologie.
  • En effet, le modèle de sécurité « Docker » réduit au minimum les capacités d'interaction de chaque container avec les éléments privilégiés du système d'exploitation sous-jacent.
  • Par exemple, afin qu'un container donné puisse modifier la date du système d'exploitation sous-jacent, il faudra, par configuration lui conférer explicitement ce privilège.
  • Les containers hébergés sur une même machine sont également étanches entre eux.
  • Typiquement, deux containers souhaitant communiquer entre eux doivent le faire par le biais d'une interface réseau virtuelle (à configurer explicitement) et d'une architecture de communication de type client-serveur. Les fichiers et processus d'un container sont invisibles de l'ensemble des autres containers.
  • L'utilisation de cette technologie nous permet donc effectivement de bénéficier d'un cloisonnement des différents services métiers entre eux, faisant que la compromission d'un service donné par un agent malveillant ne compromettra pas nécessairement la sécurité de l'ensemble du système.
  • Afin de pouvoir utiliser le matériel cryptographique inclus dans la plateforme « Proteccio » OEM, il a été ajouté dans une distribution propriétaire des composants logiciels, faisant partie de l'offre standard « Proteccio » OEM.
  • Ces composants permettent de donner accès au matériel cryptographiques depuis le système d'exploitation par le biais d'un module noyau additionnel (le driver ou pilote) interfacé par le biais d'un dispositif « Linux ».
  • Par défaut, en raison du modèle de sécurité « Docker », cet appareil est inaccessible depuis l'intérieur des containers « Docker ». Cependant, une option discrétionnaire permet d'autoriser un container donné à avoir accès à ce dispositif.
  • On notera qu'avec ce modèle, un container souhaitant accéder au module cryptographique physique n'a pas besoin de posséder le pilote (car celui-ci est présent et mutualisé au niveau du système d'exploitation sous-jacent) mais uniquement de savoir interagir avec le dispositif « Linux », ce qui diminue le nombre de composants logiciels spécifiques à inclure dans le container.
  • On notera également que, en vertu du cloisonnement, tous les containers de l'application matérielle n'ont pas nécessairement accès au module cryptographique physique (car c'est un composant très sensible du point de vue de la sécurité), mais que cet accès se décide au cas par cas pour chaque container en fonction de ses besoins réels.
  • Un système de gestion du cycle de vie des containers « Docker » a été développé et inclus dans ce socle.
  • Ce système se base sur un fichier de configuration qui permet de décrire quels containers, réseaux virtuels et volumes de données doivent être créés pour faire fonctionner l'application matérielle.
  • Ce fichier permet également de décrire les différentes options permettant de paramétrer chacune de ces opérations.
  • Lors du démarrage de l'application matérielle, ce système de gestion des containers « Docker » se déclenche automatiquement et instancie, conformément au fichier de configuration, l'ensemble des containers réseaux virtuels et volumes de données nécessaire au fonctionnement de l'application matérielle.
  • Lors de l'arrêt de la machine, les opérations inverses sont réalisées par le gestionnaire, et les éléments cités ci-dessus (sauf les volumes de données) sont détruits.
  • On obtient ainsi, à chaque redémarrage, une application matérielle dont le code exécutable est exactement conforme à celui contenu dans les images de containers livrées avec l'application matérielle, les données utilisateurs étant toutes confinées dans les volumes de données.
  • Cette « remise à neuf » de l'ensemble du code de l'application matérielle augmente la résilience du système de manière très importante, puisqu'à chaque redémarrage, seules les données utilisateur ont pu varier par rapport au démarrage précédent.
  • Ce système est générique et ne fait aucune hypothèse sur les containers « Docker » ou les réseaux virtuels permettant de faire fonctionner l'application matérielle.
  • Le fichier de configuration de l'application matérielle et l'ensemble des images des containers « Docker » auquel il fait référence définissent entièrement le comportement de la partie métier de l'application matérielle.
  • Avec la solution proposée par l'invention, un éditeur d'application matérielle qui désire utiliser le matériel « Proteccio » OEM (y compris le matériel cryptographique propriétaire « TrustWay ») n'a donc à produire que les images « Docker » nécessaires et à rédiger le fichier de l'application matérielle, puis à installer ce fichier et les archives contenant les images, aux endroits spécifiés dans la distribution pour voir l'application matérielle fonctionner conformément à ses spécifications.
  • Le manuel d'utilisation de cette solution spécifie les formats de ces différents éléments et à quels emplacements respectifs ils doivent être installés pour réaliser une application matérielle sur la base de cette solution.
  • Afin d'élargir le périmètre de la solution, on peut produire des systèmes conceptuellement équivalents pour tout type d'application matérielle sur laquelle il est possible d'exécuter un système de gestion de container.
  • Enfin, il est à noter que le couple « Linux/Docker » n'est pas la seule solution possible pour mettre en œuvre cette solution, mais que d'autres systèmes de gestion de containers existent pour « Linux ». En outre, d'autres systèmes d'exploitation que « Linux » offrent également des solutions de gestion de container.
  • Il pourrait même être envisagé, de développer un système d'exploitation et/ou un système de gestion de containers propriétaire qui permettrait d'atteindre les mêmes objectifs.
  • Bien entendu, la présente invention n'est pas limitée aux exemples et au mode de réalisation décrits et représentés, mais elle est susceptible de nombreuses variantes accessibles à l'homme de l'art.
  • Un glossaire des termes techniques est joint dans la table n°1 suivante (les termes français étant notés avec les termes anglais portant la mention GB) : [Table 1]
    • Application matérielle Appareil informatique spécifiquement conçu pour exécuter un logiciel destiné à fournir un service informatique dédié de manière autonome.
    • Appliance (GB)
    • Computer Appliance (GB)
    • Système d'exploitation Un système d'exploitation est un ensemble de programmes qui dirige l'utilisation des ressources d'un ordinateur par des logiciels applicatifs.
    • Operating System (GB)
    • O.S.
    • Logiciel applicatif Un logiciel applicatif est, un programme directement utilisé pour réaliser une tâche.
    • Machine virtuelle Une machine virtuelle est un système informatique qui donne l'illusion d'un ordinateur physique permettant ainsi d'exécuter un système d'exploitation et des logiciels différents de ceux de la machine physique qui héberge le système.
    Plusieurs machines virtuelles peuvent s'exécuter simultanément sur une même machine physique.
    • Hyperviseur Un hyperviseur est une plate-forme de virtualisation qui permet à plusieurs systèmes d'exploitation de travailler sur une même machine physique en même temps.
    • OEM « Original Equipment Manufacturer » (GB) ou équipementier : Entreprise fabriquant des composants informatiques matériels, principalement pour le compte d'une autre entreprise.
    • SSD Un SSD, abréviation de « Solid State Drive » (GB) ou « mémoire à état solide » est un matériel informatique permettant le stockage persistant de données sur de la mémoire flash. Contrairement aux disques durs magnétiques, il ne comporte pas de pièces en mouvement.
    • Architecture en micro-services Style d'architecture d'application logicielle s'opposant à l'architecture monolithique.
    • Surface d'attaque Somme des différents points d'entrés par lesquels un utilisateur non autorisé pourrait potentiellement s'introduire dans un système informatique à des fins malveillantes.
    Minimiser le plus possible la surface d'attaque fait partie des mesures de sécurité intéressantes.
    • Service métier Fonction spécifique à un domaine d'application donné réalisée par un logiciel informatique.
    • SDK « Software Development Kit » (GB) ou kit de développement d'applications : ensemble de logiciels destinés à faciliter le développement d'applications pour une plateforme donnée.
    • Driver system (GB) Un système pilote est un programme informatique destiné à permettre à un autre programme (souvent un système d'exploitation)
    • Système pilote d'interagir avec un périphérique. En général, chaque périphérique a son propre pilote. Plus simplement, le pilote d'un périphérique donné est un logiciel qui explique au système d'exploitation comment utiliser ce périphérique. Ce logiciel est dédié à l'utilisation du périphérique qui lui correspond.
    • Système Linux Dans le système Linux divers fichiers spéciaux sont situées dans le répertoire /dev. Ces fichiers s'appellent des fichiers de périphérique ou « device » (GB) et se comportent différemment des fichiers ordinaires, ils permettent le plus souvent d'interagir avec le matériel de l'ordinateur (disque dur par exemple).
    Ces fichiers spéciaux constituent l'interface avec le pilote dédié à un matériel donné faisant partie du noyau Linux, pilote qui à son tour accède au matériel.
    • Périphérique Un périphérique informatique est un dispositif matériel connecté à un ordinateur et qui ajoute à ce dernier des fonctionnalités. Le périphérique ne se situe pas nécessairement à l'extérieur du boitier de l'ordinateur et peut même ne pas être physiquement visible.
    • Socle Système d'exploitation configuré de manière spécifique pour un usage donné destiné à être utilisé à de multiples reprises dans la même configuration.
    • Conteneur ou container Un « conteneur » ou « container » est un ensemble de processus qui sont isolés du reste du système d'exploitation. Il s'exécute à partir d'une image distincte qui fournit tous les fichiers nécessaires à la prise en charge des processus qu'il contient. En fournissant une image qui contient toutes les dépendances d'une application, le conteneur assure la portabilité et la cohérence de l'application sur divers environnements. Parmi les différents systèmes de gestion de containers existant, on peut citer notamment Docker, LXC, Solaris Containers, FreeBSD jails.
    • Langage compilé Dans un langage compilé, avant de pouvoir être exécuté, le code source d'un programme doit être traduit en un code « binaire » utilisant des instructions supportées par le microprocesseur de l'ordinateur qui va l'exécuter. Le programme en charge de cette traduction est appelé « compilateur ». Une fois compilé, le programme peut être exécuté un nombre arbitraire de fois sans nécessiter d'être traduit à nouveau. La présence du compilateur n'est donc pas forcément requise pour l'exécution du programme.
    • Langage interprété Dans un langage interprété, le code source du programme est exécuté par un logiciel appelé interpréteur. L'opération d'interprétation doit être réalisée autant de fois que le programme doit être exécuté. La présence de l'interpréteur est donc requise pour l'exécution du programme.
    • Système de fichier en mémoire Dans un système de fichier en mémoire, les fichiers sont stockés dans la mémoire vive de l'ordinateur au lieu d'être enregistrés dans une zone de stockage persistante telle qu'un disque dur magnétique ou une mémoire flash de type SSD.
    Lors du redémarrage de l'ordinateur, l'ensemble des fichiers conservés dans un « système de fichier en mémoire » sont perdus.
    • Logiciel embarqué Un logiciel embarqué est un logiciel permettant de faire fonctionner une machine, équipée d'un ou plusieurs microprocesseurs, afin de réaliser une tâche spécifique avec une intervention humaine limitée. Ceux-ci couvrent trois principales fonctionnalités :
    • Traitement lié au fonctionnement de la machine.
    • Communication avec un autre calculateur ou « Machine to Machine » (GB).
    • Communication avec l'homme
    • Noyau Le noyau d'un système d'exploitation est une des parties principales du système d'exploitation. Il gère les ressources de l'ordinateur et permet aux différents composants, matériels et logiciels, de communiquer entre eux.
    • Kernel (GB)
    • Durcissement En informatique, le durcissement est le processus destiné à sécuriser un système. La démarche consiste principalement à réduire à l'indispensable les objets (logiciels, bibliothèques logicielles, outils) installés, ainsi qu'à éliminer les utilisateurs et les droits non indispensables, tout en conservant les fonctionnalités requises.
    • Hardening (GB)
    Le principe sous-jacent est la réduction de la surface d'attaque possible, en considérant que tout objet installé est potentiellement une source de vulnérabilité. La réduction du nombre d'objets installés réduit donc le nombre de failles possibles, pour un système donné.
    • Périphérique USB Matériel périphérique d'un ordinateur connectable par USB « bus série universel » ou « Universal Serial Bus »(GB), une norme relative à un bus informatique permettant de connecter divers types d'appareils le plus souvent situés à l'extérieur de l'ordinateur.
    • Périphérique PCI-Express Matériel périphérique d'un ordinateur connectable par PCI-Express, une norme qui spécifie un bus local série (« bus PCI express ») et un connecteur permettant de relier des cartes d'extension sur la carte mère d'un ordinateur.
    • Modèle de conteneur Un modèle de conteneur parfois aussi appelé image est un ensemble de fichiers permettant de créer de multiples conteneurs identiques. C'est le contenu du modèle qui définit les fonctionnalités des conteneurs qui seront créés à partir ce modèle.
    • HSM (GB) « module matériel de sécurité » ou « Hardware Security Module »
    • Module matériel de sécurité (GB) est un appareil considéré comme pratiquement inviolable et offrant des fonctions cryptographiques. Il s'agit d'un matériel électronique offrant un service de sécurité qui consiste à générer, stocker et protéger des clefs cryptographiques.

Claims (13)

  1. Procédé de fabrication d'une application matérielle métier spécifique sécurisée et modulaire, comprenant : une étape de sélection : d'un ordinateur matériel intégré dans un boîtier fermé qui l'isole de l'extérieur de manière à rendre les ressources matérielles de cet ordinateur matériel structurellement non extensibles car rendues inaccessibles sans endommagement depuis l'extérieur du boîtier, d'un système d'exploitation à gérer des containers de manière générique et minimaliste, associé à l'ordinateur, d'un kit de développement d'applications, associé au système d'exploitation et à l'ordinateur, des modèles de containers, des composants logiciels métiers spécifiques, une étape de déploiement des composants logiciels métiers spécifiques dans des containers instanciés sur la base des modèles de containers, le système d'exploitation, apte à gérer des containers de manière générique et minimaliste, comprend : un mécanisme générique de gestion d'un nombre non prédéterminé de containers, comprenant : une fonction d'installation des modèles de containers, une fonction de mise à jour des modèles de containers, une fonction de création d'un container par instanciation d'un modèle de container, une fonction de démarrage d'un container, une fonction d'arrêt d'un container, une fonction de destruction d'un container, un mécanisme de configuration dudit mécanisme générique de gestion des containers, apte à configurer pour une application matérielle donnée une liste des containers à gérer, et un ensemble des composants additionnels requis pour le fonctionnement des containers à gérer; ledit mécanisme générique de gestion des containers comprend uniquement : ladite fonction d'installation des modèles de containers, ladite fonction de mise à jour des modèles de containers, ladite fonction de création d'un container par instanciation d'un modèle de container, ladite fonction de démarrage d'un container, ladite fonction d'arrêt d'un container, ladite fonction de destruction d'un container.
  2. Procédé de fabrication d'une application matérielle métier spécifique sécurisée et modulaire selon la revendication 1, dans lequel ledit mécanisme de configuration dudit mécanisme générique de gestion des containers, est apte à configurer uniquement : ladite liste des containers à gérer, ledit ensemble des composants additionnels requis pour le fonctionnement des containers à gérer.
  3. Procédé de fabrication d'une application matérielle métier spécifique sécurisée et modulaire selon l'une quelconque des revendications 1 à 2, dans lequel ledit ensemble des composants additionnels requis pour le fonctionnement des containers à gérer, comprend : des réseaux virtuels, et/ou des volumes de données, et/ou l'accès à des composants matériels métiers spécifiques avec les droits d'accès des différents containers auxdits composants.
  4. Procédé de fabrication d'une application matérielle métier spécifique sécurisée et modulaire selon l'une quelconque des revendications précédentes, dans lequel le nombre des composants logiciels formant ledit système d'exploitation est inférieur à 100 composants logiciels, et de préférence est compris entre 50 et 100 composants logiciels.
  5. Procédé de fabrication d'une application matérielle métier spécifique sécurisée et modulaire selon l'une quelconque des revendications précédentes, dans lequel ledit ordinateur matériel, intégré dans un boîtier fermé qui l'isole de l'extérieur de manière à rendre les ressources matérielles de cet ordinateur matériel structurellement non extensibles car rendues inaccessibles sans endommagement depuis l'extérieur du boîtier, inclut déjà le ou les composants matériels métiers spécifiques éventuels.
  6. Procédé de fabrication d'une application matérielle métier spécifique sécurisée et modulaire selon la revendication 5, dans lequel le ou l'un des composants matériels métiers spécifiques est une carte cryptographique qui est avantageusement apte à réaliser / authentifier les signatures électroniques et/ou à réaliser des chiffrements / déchiffrements de données.
  7. Procédé de fabrication d'une application matérielle métier spécifique sécurisée et modulaire selon l'une quelconque des revendications précédentes, dans lequel ledit ordinateur matériel comprend au moins : un ou plusieurs microprocesseurs, une ou plusieurs mémoires vives, une ou plusieurs mémoires persistantes, une ou plusieurs interfaces réseau.
  8. Procédé de fabrication d'une application matérielle métier spécifique sécurisée et modulaire selon la revendication 7, dans lequel la capacité globale de la ou des mémoires vives est comprise entre 5 et 30Go, de préférence comprise entre 10 et 20Go, et la capacité globale de la ou des mémoires persistantes est comprise entre 50 et 500Go, de préférence comprise entre 100 et 300Go.
  9. Procédé de fabrication d'une application matérielle métier spécifique sécurisée et modulaire selon l'une quelconque des revendications précédentes, dans lequel ledit déploiement des composants logiciels métiers spécifiques est organisé en une architecture de micro-services.
  10. Procédé de fabrication d'une application matérielle métier spécifique sécurisée et modulaire selon l'une quelconque des revendications précédentes, dans lequel des composants logiciels additionnels de sécurité sont implémentés dans ledit système d'exploitation, et/ou des configurations spécifiques augmentant le niveau de sécurité sont implémentées dans ledit système d'exploitation.
  11. Procédé de fabrication d'une application matérielle métier spécifique sécurisée et modulaire selon l'une quelconque des revendications précédentes, dans lequel: des matériels métiers dédiés sont implémentés dans l'application matérielle métier spécifique, des composants logiciels additionnels de pilotage des matériels métiers dédiés sont implémentés dans ledit système d'exploitation.
  12. Procédé de fabrication d'une application matérielle métier spécifique sécurisée et modulaire selon l'une quelconque des revendications précédentes, dans lequel: la configuration de toute la partie logicielle de l'application matérielle métier spécifique est durcie pour améliorer sa sécurité, et/ou la configuration du système d'exploitation est durcie pour améliorer sa sécurité.
  13. Procédé de fabrication d'une application matérielle métier spécifique sécurisée et modulaire selon l'une quelconque des revendications précédentes, dans lequel: le système d'exploitation est un système d'exploitation Linux, le système de gestion des containers est le système Docker.
EP19219571.7A 2018-12-27 2019-12-23 Procédé de fabrication d'une application matérielle metier specifique securisée et modulaire et système d'exploitation associé Active EP3674941B1 (fr)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
FR1874267A FR3091368B1 (fr) 2018-12-27 2018-12-27 PROCEDE DE FABRICATION D’UNE APPLICATION MATERIELLE METIER SPECIFIQUE SECURISEE ET MODULAIRE ET système D’EXPLOITATION ASSOCIE

Publications (2)

Publication Number Publication Date
EP3674941A1 EP3674941A1 (fr) 2020-07-01
EP3674941B1 true EP3674941B1 (fr) 2025-10-22

Family

ID=67185169

Family Applications (1)

Application Number Title Priority Date Filing Date
EP19219571.7A Active EP3674941B1 (fr) 2018-12-27 2019-12-23 Procédé de fabrication d'une application matérielle metier specifique securisée et modulaire et système d'exploitation associé

Country Status (3)

Country Link
US (1) US11221829B2 (fr)
EP (1) EP3674941B1 (fr)
FR (1) FR3091368B1 (fr)

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10838759B2 (en) 2019-02-04 2020-11-17 Verizon Patent And Licensing Inc. Elastic container platform architecture
CN112214213B (zh) * 2020-10-27 2023-10-20 南方电网数字电网科技(广东)有限公司 Linux内核的开发和管理方法、装置、计算机设备和存储介质
US12367320B2 (en) * 2021-09-22 2025-07-22 Ridgeline, Inc. Mechanism for real-time identity resolution in a distributed system
US12422984B2 (en) 2022-12-29 2025-09-23 Pure Storage, Inc. Automated elastic resource management of a container system by a distributed storage system
CN120832199A (zh) * 2024-04-18 2025-10-24 北京全路通信信号研究设计院集团有限公司 一种ctcs-3级列控系统中多安全监督模块容器集管理方法及系统

Family Cites Families (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7739505B2 (en) * 2005-04-22 2010-06-15 Microsoft Corporation Linking Diffie Hellman with HFS authentication by using a seed
US9973566B2 (en) * 2013-11-17 2018-05-15 Nimbix, Inc. Dynamic creation and execution of containerized applications in cloud computing
US9800517B1 (en) * 2013-10-31 2017-10-24 Neil Anderson Secure distributed computing using containers
US9692666B2 (en) * 2014-12-22 2017-06-27 Rovio Entertainment Ltd. Container manager
US9635055B2 (en) * 2015-01-28 2017-04-25 defend7, Inc. Encryption levels for secure application containers
US9916233B1 (en) * 2015-03-27 2018-03-13 Amazon Technologies, Inc. Using containers for update deployment
US20170322824A1 (en) * 2016-05-05 2017-11-09 Microsoft Technology Licensing, Llc Cloning Computing Device Containers
CN109313544A (zh) * 2016-05-23 2019-02-05 W·特纳 具有虚拟机的基于容器的部署的超融合系统架构
US10417065B2 (en) * 2016-06-13 2019-09-17 Dynatrace Llc Method and system for automated agent injection in container environments
US9804952B1 (en) * 2016-11-07 2017-10-31 Red Hat, Inc. Application debugging in a restricted container environment
US10333985B2 (en) * 2017-01-09 2019-06-25 Microsoft Technology Licensing, Llc Distribution and management of services in virtual environments
US10691816B2 (en) * 2017-02-24 2020-06-23 International Business Machines Corporation Applying host access control rules for data used in application containers
US10523507B2 (en) * 2017-05-11 2019-12-31 Nirmata, Inc. Method and system for tuning performance of microservices-based applications
US10824726B1 (en) * 2018-03-29 2020-11-03 EMC IP Holding Company LLC Container anomaly detection using container profiles
US20190347127A1 (en) * 2018-05-09 2019-11-14 Red Hat, Inc. Service provisioning and orchestration for virtual machine to container migration

Also Published As

Publication number Publication date
FR3091368A1 (fr) 2020-07-03
US11221829B2 (en) 2022-01-11
FR3091368B1 (fr) 2021-12-24
US20200210150A1 (en) 2020-07-02
EP3674941A1 (fr) 2020-07-01

Similar Documents

Publication Publication Date Title
EP3674941B1 (fr) Procédé de fabrication d'une application matérielle metier specifique securisée et modulaire et système d'exploitation associé
US9626302B2 (en) Encrypting and decrypting a virtual disc
Benedicic et al. Sarus: Highly scalable docker containers for hpc systems
EP1687717B1 (fr) Demarrage securise d'un appareil electronique a architecture smp
US8726269B2 (en) Method to enable application sharing on embedded hypervisors by installing only application context
CN114201763B (zh) 优化容器镜像加密
CN103988181A (zh) 用于给虚拟映像打补丁的方法和系统
EP2649523A1 (fr) Méthode de compilation d'un code intermédiaire d'une application
FR2810423A1 (fr) Systeme informatique modulaire et procede associe
CN103975306A (zh) 用于创建虚拟设备的方法和系统
Gossen et al. A model-driven and generative approach to holistic security
Barnes Pro Windows Subsystem for Linux (WSL)
Marinilli Java deployment
US20060230397A1 (en) Method for third-party registration of software components
Raggi et al. Beginning ubuntu linux
Fuchs et al. Runtime firmware product lines using TPM2. 0
WO2016207533A1 (fr) Procédé d'aide a l'analyse de l'exécution d'une machine virtuelle
Reddy et al. Resolving Cloud Application Migration Issues
Ganipineni Analysis of Current Portable App Creating Utilities and Fork of the Current Best Open Source Utility
Ramos Apolinario Containerizing existing applications
FR2970577A1 (fr) Plateforme d'execution modulaire amelioree.
AU2004206591A1 (en) Distribution of services software in a network
Dufour et al. Introduction to Containers & Application to AI at LRZ
Gossen et al. Approach to Holistic Security
Johnson Installation and IDE Differences

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

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

Free format text: STATUS: THE APPLICATION HAS BEEN PUBLISHED

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL 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 RS SE SI SK SM TR

AX Request for extension of the european patent

Extension state: BA ME

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

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20201228

RBV Designated contracting states (corrected)

Designated state(s): AL 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 RS SE SI SK SM TR

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

Free format text: STATUS: EXAMINATION IS IN PROGRESS

17Q First examination report despatched

Effective date: 20220103

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

Effective date: 20230330

REG Reference to a national code

Ref country code: DE

Ref legal event code: R079

Ref country code: DE

Ref legal event code: R079

Ref document number: 602019077105

Country of ref document: DE

Free format text: PREVIOUS MAIN CLASS: G06F0021530000

Ipc: H04L0009400000

GRAP Despatch of communication of intention to grant a patent

Free format text: ORIGINAL CODE: EPIDOSNIGR1

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

Free format text: STATUS: GRANT OF PATENT IS INTENDED

RIC1 Information provided on ipc code assigned before grant

Ipc: G06F 9/50 20060101ALI20250429BHEP

Ipc: G06F 9/48 20060101ALI20250429BHEP

Ipc: G06F 21/12 20130101ALI20250429BHEP

Ipc: G06F 21/62 20130101ALI20250429BHEP

Ipc: G06F 21/57 20130101ALI20250429BHEP

Ipc: G06F 21/53 20130101ALI20250429BHEP

Ipc: G06F 9/445 20180101ALI20250429BHEP

Ipc: H04L 9/40 20220101AFI20250429BHEP

INTG Intention to grant announced

Effective date: 20250516

GRAS Grant fee paid

Free format text: ORIGINAL CODE: EPIDOSNIGR3

GRAA (expected) grant

Free format text: ORIGINAL CODE: 0009210

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

Free format text: STATUS: THE PATENT HAS BEEN GRANTED

AK Designated contracting states

Kind code of ref document: B1

Designated state(s): AL 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 RS SE SI SK SM TR

REG Reference to a national code

Ref country code: CH

Ref legal event code: F10

Free format text: ST27 STATUS EVENT CODE: U-0-0-F10-F00 (AS PROVIDED BY THE NATIONAL OFFICE)

Effective date: 20251022

Ref country code: GB

Ref legal event code: FG4D

Free format text: NOT ENGLISH

REG Reference to a national code

Ref country code: DE

Ref legal event code: R096

Ref document number: 602019077105

Country of ref document: DE

REG Reference to a national code

Ref country code: IE

Ref legal event code: FG4D

Free format text: LANGUAGE OF EP DOCUMENT: FRENCH

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

Ref country code: GB

Payment date: 20251218

Year of fee payment: 7

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

Ref country code: FR

Payment date: 20251218

Year of fee payment: 7

REG Reference to a national code

Ref country code: NL

Ref legal event code: MP

Effective date: 20251022

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

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: 20251022

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

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: 20251022

REG Reference to a national code

Ref country code: LT

Ref legal event code: MG9D

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

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: 20260122

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

Ref country code: DE

Payment date: 20251222

Year of fee payment: 7

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: 20251022

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: 20251022

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: 20251022

REG Reference to a national code

Ref country code: AT

Ref legal event code: MK05

Ref document number: 1850212

Country of ref document: AT

Kind code of ref document: T

Effective date: 20251022

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

Ref country code: RS

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: 20260122

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

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: 20260222

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

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: 20260223

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

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: 20251022

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

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: 20251022