Microcontroller for secure starting with firewall

TECHNICAL FIELD OF THE INVENTION

0001The present invention relates to the field of data protection and in particular data exchanged in financial transactions. The present invention specifically relates to a device for ensuring the security of the exchange of confidential data between a customer and a financial institution or between two financial institutions.

BACKGROUND OF THE INVENTION

0002The protection of sensitive data used in financial transactions is a major challenge for the field of the economy. Transactions can be made either through a dedicated website, the website using encryption and several verification measures or by means of a device such as vending machines. The latter authorize transactions using cards with at least one chip, the chip containing at least one authentication information of the card holder. Nevertheless, devices such as vending machines have disadvantages. Indeed, a vending machine includes a memory that stores the authentication codes retrieved from an interbank network, for example. A voluntary or unintentional failure of the machine, however, may allow an attacker to recover data from the memory contained in the machine. Although some progress has been made in the protection of vending machines in recent years, machines still have disadvantages associated with their architecture and / or the electronic components they contain.

0003In the document <patcit id="pcit0001" dnum="US7953989B1"><text>US7953989 B1</text></patcit>there is taught a device comprising a high security microcontroller which comprises tamper control circuits for detecting vulnerability conditions: a write in the program memory before the sensitive financial information has been erased, a tamper detection condition, activating a debugger, a power-on condition, a non-compliant temperature condition, a non-compliant power supply voltage condition, an oscillator failure condition, and a battery removal condition. If the tamper control circuit detects a vulnerability condition, then the memory where the sensitive financial information could be stored is deleted.

0004One of the disadvantages of the device described above is that the security of the system depends entirely on the proper functioning of the tamper device. Indeed, if the latter was defective, the security of the entire system would be compromised.

GENERAL DESCRIPTION OF THE INVENTION

0005The present invention aims to overcome one or more disadvantages of the prior art by proposing that can effectively protect the data exchange in financial transactions and prevent theft of data by degradation of the machine containing said device. This object is achieved by a microcontroller comprising a processor comprising a separate memory in different zones that are secured, unsecured or shared, to implement a secure start, a tamper control circuit comprising at least one sensor for detecting the conditions of vulnerability, said processor running a Linux operating system (Linus OS) and also including a monitor for switching operations either in a secure area of ​​the memory to operate at least authentication processes or in an unsecured area to other operations and determine whether the devices connected to or accessing the, or accessed by the microcontroller must be managed by the secure zone or the unsecured area,said microcontroller being characterized in that it comprises a hardware firewall, used by said processor, to determine whether the information or control of an application is authorized to access the secure area or not, said hardware firewall being connected to said self-protection control circuit to prevent intrusion and / or data recovery in the event of failure of said self-protection control circuit.

0006According to another particularity, the secure and non-secure zones are both included in the processor of the microcontroller, the data processing and exchange processes executed by the microcontroller being effected from one zone to another according to the nature of the information to be processed.

0007In another feature, the hardware firewall has registers that are each assigned to a device and that use the information stored in the Linux device tree, described in the Linux operating system, wherein said device tree is added with security attributes, defining the secure (S) or nonsecure (N) status of a device to be stored in each register associated with a device a secure or insecure status to induce the processing of the information or command to from a device in the secure zone of the processor if the device is defined as secure, and induce the processing of the information or the command froma device in the unsecured area of ​​the processor if the device is defined as unsecured.

0008In another feature, the Linux device tree is authenticated by a secure primary application during the secure boot operation.

0009According to another particularity, the secure zone comprises a core receiving at least one instruction from the unsecured zone or from a device included in the device tree, and performing various operations that depend on the received instruction, a register comprising a secure set of services comprising the rules for the protection of different types of processes corresponding to different types of services.

0010According to another particularity, the unsecured zone comprises the operating system kernel, an execution environment for programs and applications and / or data processing methods, at least one library, and at least one platform dedicated to the adding client applications or proprietary applications, the method of adding and accessing said applications to the functionalities of the device controlled by the microcontroller being defined by security rules implemented by the hardware firewall.

0011According to another particularity, the execution environment is configured to integrate at least one means for interpreting different types of client applications, said means being capable of translating the language of said applications into native programs in order to process them on said environment. execution.

0012In another feature, the runtime environment is Android.

0013In another feature, the devices included in the device tree and accessible are at least two of the following devices: Bluetooth / Wifi circuit, Ethernet, printers, display, GPS, camera, sound, proximity sensor, HDMI, USB, screen touch, keyboard, noncontact reader (NFC), magnetic card reader, smart card reader, cryptographic hardware, computer key manager.

0014A contactless reader is understood to mean any object reader that does not require direct contact between the object and the reader in order to communicate at least one piece of information, for example a card using radio-identification technology (RFID) or communications in the field. near (NFC).

0015The term "cryptographic material" means any device or device for encrypting or encrypting sensitive information or data, for example and without limitation a cryptoprocessor.

0016According to another particularity, the peripherals: display, touch screen, keyboard, contactless reader, magnetic card reader, smart card reader, cryptographic material and computer key manager are secure peripherals, while peripherals: Bluetooth circuit / Wifi, Ethernet, printers, GPS, camera, sound, proximity sensor, HDMI and USB receive either a secure status (S) or an unsecured status (N).

0017In another feature, the secure boot process of the Linux operating system for a microcontroller with self-protection device and secure area includes the steps of:<ul><li>start executing the code contained in the ROM;</li><li>load an encrypted initial partition from an external memory;</li><li>decrypt the information of the initial partition;</li><li>authenticate public keys (Pk) and authenticate a protected primary application (PPA) and initial software (ISW);</li><li>and load and start other Linux startup programs.</li></ul>the boot process being characterized in that the step "load and start other boot programs of Linux" includes at least one of the steps of:<ul><li>load the U-boot SPL (Secondary Program Loader);</li><li>authenticate the device tree (DT);</li><li>start the PA-loader (Primary Application loader);</li><li>decrypt the live PA (Primary Application live);</li><li>initialize ramdisk;</li><li>load the Linux kernel;</li><li>Start the Linux kernel</li><li>start dm-verity;</li><li>to run Android apps under SELinux</li></ul>

0018According to another particularity, at least several microcontroller device registers initially have a secure status (S) when the code contained in the ROM begins to execute and before the activation of the PA-loader.

0019According to another particularity, after activation of the PA-loader, the security attributes defined for each device in the device tree are managed by the PA-Loader and the secure status (S) of at least one register of the parser -fire associated with a device, initially defined in a secure status (S) and deemed non-critical due to the description in the device tree for the security and / or integrity of a system or device, is changed to an unsecured (N) or normal status in the firewall registry.

0020In another feature, the application platforms are separated from the library, the operating system kernel and the operating system runtime environment by a control module, contained in the operating system, which controls the accesses for the applications and limits the access to a given device or a service for the unauthorized client applications, the access control of said device or said service being carried out by means of a file provided by SELinux, said file whitelisting the type of operations allowed in combination with the identity (ID) of a particular application or process and establishing the operation permission for each application.

0021In another feature, the access of an authorized or unauthorized client application to certain features of a device such as for example the touch screen display, is controlled by the microcontroller and is done by means of a proxy a secure proxy actuated by the control module, said secure proxy verifying whether a message concerning a touch event is signed by a trusted third party before being displayed and if not, the touch event is not transferred to the unsecured area.

0022In another feature, a microcontroller with a tamper and secure zone and a secure boot of the Linux operating system is used in an all-in-one terminal including an LCD screen, a capacitive touch screen, a card reader magnetic field, a chip card reader, a contactless card reader, an upstream security circuit board, a connection circuit board and a camera for constituting a tamper-proof terminal in which each secured operation or secure device is managed by the secure area of ​​the microcontroller and in which the protection of access to this secure area is protected against access of a probe to the microcontroller by theinsertion of the main printed circuit including the microcontroller in a connection cage to detect any attempt to open the cage or drilling through the cage.

0023According to another particularity, the upstream security printed circuit comprises at least one proximity sensor for detecting any action presence and sending a signal to the microcontroller to perform an analysis and to trigger an action (display of a welcome or use message ).

0024According to another particularity, the connection printed circuit comprises at least one USB interface, a UART serial port, an Ethernet interface and a Bluetooth / Wifi interface for communication and data exchange.

DESCRIPTION OF ILLUSTRATIVE FIGURES

0025Other features and advantages of the present invention will appear more clearly on reading the description below, made with reference to the accompanying drawings, in which:<ul><li>The <figref idrefs="f0001">Figure 1</figref> represents a diagram of the structure of the microcontroller according to one embodiment,</li><li>The <figref idrefs="f0002">Figure 2</figref> represents a diagram of the components of the microcontroller secured by the firewall of said microcontroller, according to one embodiment,</li><li>The <figref idrefs="f0003">Figure 3</figref> represents a diagram of the processor structure of the microcontroller, according to one embodiment,</li><li>The <figref idrefs="f0004">Figure 4</figref> represents a diagram of the structure of a terminal comprising the microcontroller, according to one embodiment,</li><li>The <figref idrefs="f0005">Figures 5A</figref>, <figref idrefs="f0006">5B</figref> and <figref idrefs="f0007">5C</figref> represent the diagrams, respectively, of the system startup process and the steps S1, S2a, S2b, S3a and S3b of said startup process, according to one embodiment.</li></ul>

DESCRIPTION OF THE PREFERRED EMBODIMENTS OF THE INVENTION

0026The present invention relates to a microcontroller (1, <figref idrefs="f0001">Figure 1</figref>) for the protection of data exchange in a terminal for applications with a high level of security such as for example financial transactions.

0027In some embodiments, the microcontroller (1) comprises a processor (11, <figref idrefs="f0002">Figures, 2</figref> and <figref idrefs="f0003">3</figref>) comprising a memory separated into at least two areas that are secured (110, <figref idrefs="f0002">Figures 2</figref> and <figref idrefs="f0003">3</figref>), unsecure (111, <figref idrefs="f0002">Figures 2</figref> and <figref idrefs="f0003">3</figref>), for implementing a secure boot, comprising a tamper control circuit (13) or tamper circuit for detecting the vulnerability conditions and the processor (11) running a Linux operating system, said processor comprising a monitor to switch operations either in a secure area (110) of the memory for operating at least one authentication process or in an unsecured area (111) for other operations and determining whether the devices connected to or accessing the, or accessed by the microcontroller (1) must be managed by the secure area (110) or the non-secure area (111) using a hardware firewall (12, <figref idrefs="f0001">Figures 1</figref> and <figref idrefs="f0002">2</figref>) to determine whether the information or control of an application is authorized to access the secure area (110) or not. The self-protection device (13) comprises, for example, sensors (130a, 130b, 130c,<figref idrefs="f0001">Figure 1</figref>) allowing it to detect if someone tries to access the microcontroller (1) or the device controlled by the microcontroller (1) in the case where access is not allowed. For example and in a nonlimiting manner, the sensors (130a, 130b, 130c) are capable of detecting shocks (130a) and / or variations in voltage (130b) and temperature (130c), etc. The tamper device (13) further comprises at least one alarm (132) that triggers in the event of an intrusion and at least one clock (131) to date the events, for example an unauthorized access attempt. In case of intrusion the tamper device (13) sends an order allowing erasing the confidential data contained in secure memories (14) or encrypted (volatile or non-volatile) disposed in the microcontroller (1) and connected to the tamper device (13). The data are, for example and without limitation, authentication codes or coding keys. The microcontroller also comprises a ROM (10a) ("Read-Only Memory"), a BOOT-RAM boot memory (10b), a static memory SRAM (10c) ("Static Random Access Memory" or RAM static) and a debugger. The processor (11, The microcontroller also comprises a ROM (10a) ("Read-Only Memory"), a BOOT-RAM boot memory (10b), a static memory SRAM (10c) ("Static Random Access Memory" or RAM static) and a debugger. The processor (11, The microcontroller also comprises a ROM (10a) ("Read-Only Memory"), a BOOT-RAM boot memory (10b), a static memory SRAM (10c) ("Static Random Access Memory" or RAM static) and a debugger. The processor (11,<figref idrefs="f0001">Figures 1</figref>, <figref idrefs="f0002">2</figref> and <figref idrefs="f0003">3</figref>) virtualizes the secure area (110) and the non-secure area (111) by means of the processor switching layer (112). For example and without limitation, the processor (11) is an ARM Cortex-A9. The devices (16a, 16b, 16c, 16d, 16e, 16f) managed respectively by the secure area (110) and the unsecured area (111) of the microcontroller (1) are assigned by the hardware firewall (12). ), respectively, the letter "S" (for secure) and the letter "N" (for non-secure or normal), said security information is saved in the registers of the hardware firewall (12) as shown on the<figref idrefs="f0002">figure 2</figref>. The self-protection device (13), also connected to the hardware firewall (12), is assigned a permanent secure status, in order to avoid any intrusion, in particular an attempt to recover data in case the device of self-protection (13) would fail.

0028In some embodiments, the memory is divided into three areas, one secure, one unsecured and one shared. The shared zone is intended to receive devices requiring the use of resources, for example information or applications, secured and unsecured resources. Such an architecture makes it possible to avoid the introduction of a weak point for the peripherals requiring only secure resources.

0029In some embodiments, the secure (110) and non-secure (or normal) zones are both included in the processor (11) of the microcontroller (1), for example as shown in FIGS. <figref idrefs="f0002">figures 2</figref> and <figref idrefs="f0003">3</figref>. The data processing and exchange processes executed by the microcontroller (1) are carried out from one zone to another depending on the nature of the information to be processed. For example, if the information relates to sensitive data such as authentication codes, it is first transmitted to the secure area (110) for verification (authentication). When the authentication is complete, the result of the processing is transmitted to the non-secure zone (111) to allow or not the continuation of the treatment. The configuration of the processor (11) and the memory in a secure area (110) and a non-secure area (111) and the presence of the hardware firewall (12) controlling the accessibility of the devices (16a, 16b, 16c, 16d, 16th, 16f) managed by the microcontroller (1) provides an additional layer of protection. This protective layer could be combined, in addition, with the self-protection circuit (13) which mainly prevents unauthorized access from outside. The secure microcontroller (1) prevents unauthorized access from within and is therefore complementary to the prevention of unauthorized access from outside for a secure and tamper-proof terminal.

0030a device in the unsecured area of ​​the processor if the device is defined as unsecured. The layout of the various interfaces associated with the different devices in the two zones is configured by the hardware firewall (12). For example, if the processor tries to access a given interface, it must do so in the correct mode. operation that is to say according to the secure or non-secure status established by the hardware firewall (12) to have access to said interface.

0031In some embodiments, the Linux device tree is authenticated by a secure primary application during the secure boot operation.

0032In some embodiments, the secure area (110) includes a core (110b) receiving at least one instruction from the unsecured area (111) or a device (16a, 16b, 16c, 16d, 16e, 16f) included in the device tree, and performing various operations that depend on the received instruction, a register (110a) comprising a set of secure services including rules for protecting different types of processes corresponding to different types of services

0033In some embodiments, the non-secure area (111) includes the operating system kernel (111a), an execution environment (111b) of the programs and applications and / or data processing methods, at least one library, and at least one platform (111c, 111d) dedicated to the addition of client applications (111d) or proprietary applications (111c), the method of adding and accessing said applications to the functionalities of the device controlled by the microcontroller (1) being defined by security rules implemented by the hardware firewall (12).

0034In some embodiments, the execution environment (111b) is configured to integrate at least one means for interpreting different types of client applications, said means being capable of translating the language of said applications into native programs for processing on them. said execution environment (111b). This configuration thus makes it possible to avoid having to change the execution environment as soon as the programming language of the client applications is changed.

0035In some embodiments, the runtime environment is Android.

0036In some embodiments, the accessible devices are at least two of the following devices: Bluetooth (16c) / Wifi (16b) circuit, Ethernet (16d), printers, display, GPS, camera (161), sound, proximity sensor ( 16k), HDMI, USB (16a), touch screen (16f), keypad, non-contact reader (16th), magnetic card reader (16h), smart card reader (16g), cryptographic material, computer key manager .

0037In some embodiments, display devices, touch screen (16f), keyboard, non-contact reader (16th), magnetic card reader (16h), smart card reader (16g), cryptographic hardware and computer key manager are secure devices, while Bluetooth (16c) / Wifi (16b), Ethernet (16d), printers, GPS, camera (161), sound, proximity sensor (16k), HDMI and USB (16a) devices receive either a secure status (S) or a non-secure status (N).

0038In some embodiments, the secure boot process of the Linux operating system (see <figref idrefs="f0005">Figures 5A</figref>, <figref idrefs="f0006">5B</figref> and <figref idrefs="f0007">5C</figref>) for a microcontroller (1) with self-protection device (13) and secure area or trusted processing area (110) comprises the steps of:<ul><li>start executing the code contained in the ROM (10a);</li><li>load an encrypted initial partition from an external memory;</li><li>decrypt the information of the initial partition;</li><li>authenticate the public keys (Pk) and authenticate the protected primary application (PPA) and initial software (ISW);</li><li>and load and start other Linux startup programs.</li></ul>

0039The ROM includes the public keys for authenticating the information of the initial partition loaded from the external memory and / or optionally the decryption. The ROM then downloads the decrypted information from the original partition, the Protected Primary Application (PPA) and the Initial Software (ISW), which includes Secure Initial Software (ISSW) and normal or non-secure initial software (ISNW). ), in the boot memory or BOOT-RAM (10b), only accessible in secure mode (S).

0040In another embodiment, the secure boot process of the Linux operating system, in particular and preferably the "load and start other Linux boot programs" step includes at least one of the steps of:<ul><li>load the U-boot SPL (Secondary Program Loader);</li><li>authenticate the device tree (DT);</li><li>start the PA-loader (Primary Application loader);</li><li>decrypt the live PA (Primary Live Application) which is the specific secure client application that contains the specific functions for a client or payment scheme;</li><li>initialize ramdisk;</li><li>load the Linux kernel;</li><li>Start the Linux kernel</li><li>start dm-verity;</li><li>to run Android apps under SELinux</li></ul>

0041The U-boot SPL image is loaded into the unsecured area or normal zone (see <figref idrefs="f0005">Figures 5A</figref>, <figref idrefs="f0006">5B</figref>) of the processor (11). After the programs start, the list of devices included in the operating system's device tree is sent for authentication in the secure area (110). After authentication of the list, the next step is activated. If, during the different steps, an authentication process is required, the instruction is transferred again to the secure area for verification. The process thus proceeds until the operating system (110a) is started and the applications run.

0042SELinux (Security-Enhanced Linux) is used to further define the limits of the secure environment or "sandbox" of the Android application. SELinux improves the security of Android by confining privileged processes and automating the creation of the security policy. Anything that is not explicitly allowed is denied. SELinux can operate in one of two global modes: the permissive mode, in which authorization denials are logged but not enforced, and the enhanced mode, in which deny permissions are both logged and enforced. SELinux is configured in the enhanced mode. SELinux also supports a permissive mode by domain in which specific domains (processes) can be permissive while placing the rest of the system in a global enhanced mode. A domain is simply a label identifying a process or set of processes in the security policy, where all processes marked with the same domain are treated identically by the security policy. A list of permissive domains is stored in the memory of the microcontroller (1) and checked before executing a command provided by an Android application.

0043As a result, the application platforms are separated from the library, the kernel, and the operating system runtime environment by a control module, contained in the operating system, that controls application access and limit access to a given device or service to an unauthorized client application, control and access to said device or service being performed using a file provided by SELinux, said file describing in a "whitelist" the type of operations that are authorized by a particular application or process and establishing the operation permission for each application.

0044In some embodiments, at least several device registers of the microcontroller (1) initially have a secure status (S) when the code contained in the ROM (10a) begins to execute and before the activation of the PA-loader. The system is always started in the secure zone (111a), almost all the devices are then assigned, initially by default, the secure status (S) and are forbidden to access until the step of authentication of devices included in the device tree be executed.

0045In some embodiments, after activation of the PA-loader, the security attributes defined for each device in the device tree are managed by the PA-Loader and the secure status (S) of at least one register of the device. a firewall (12) associated with a device, initially defined in secure status (S) and deemed uncritical due to the description in the device tree for the security and / or integrity of a system or device a device, is changed to an unsecure (N) or normal status in the firewall registry. After authenticating the device tree, the PA-loader reads it and changes the status of the devices contained in the tree following the rules established by the hardware firewall (12). For example,

0046In some embodiments, the application platforms (111c, 111d) are separated from the library, the operating system kernel (111a) and the runtime environment (111b) of the system. operation by a control module, contained in the operating system, which controls access for applications and limits access to a given device or service for unauthorized client applications, access control device or service being performed using a file provided by SELinux, said file whitelisting the type of operations allowed in combination with the identity (ID) of a particular application or a process and establishing operation permission for each application.

0047In some embodiments, the access of an authorized or unauthorized client application to certain functionalities of a device such as for example the touch screen display, is controlled by the microcontroller (1) and is done by means of a secure proxy activated by the control module, said secure proxy verifying if a message concerning a touch event is signed by a trusted third party before being displayed and if not, the touch event is not transferred to the zone unsecured. For example and without limitation, if a client application using a standard Android application programming interface (API), tries to access the display screen (16f) of a device controlled by the microcontroller (1), the control module operates the secure proxy that checks whether there is a match between the application API and the native API of the system. If there is no match, the application is not allowed. In the case where the application is authorized, the screen initially displays only input data provided by the application, said data can not trigger the execution of a task. The data is subsequently transmitted to the secure area by the secure proxy for verification. If the data is authenticated, it is signed and transmitted, via the secure proxy, to the screen so as to trigger in the processor of the display screen, the execution of a task. there is a mapping between the application API and the native system API. If there is no match, the application is not allowed. In the case where the application is authorized, the screen initially displays only input data provided by the application, said data can not trigger the execution of a task. The data is subsequently transmitted to the secure area by the secure proxy for verification. If the data is authenticated, it is signed and transmitted, via the secure proxy, to the screen so as to trigger in the processor of the display screen, the execution of a task. there is a mapping between the application API and the native system API. If there is no match, the application is not allowed. In the case where the application is authorized, the screen initially displays only input data provided by the application, said data can not trigger the execution of a task. The data is subsequently transmitted to the secure area by the secure proxy for verification. If the data is authenticated, it is signed and transmitted, via the secure proxy, to the screen so as to trigger in the processor of the display screen, the execution of a task. there is no match, the application is not allowed. In the case where the application is authorized, the screen initially displays only input data provided by the application, said data can not trigger the execution of a task. The data is subsequently transmitted to the secure area by the secure proxy for verification. If the data is authenticated, it is signed and transmitted, via the secure proxy, to the screen so as to trigger in the processor of the display screen, the execution of a task. there is no match, the application is not allowed. In the case where the application is authorized, the screen initially displays only input data provided by the application, said data can not trigger the execution of a task. The data is subsequently transmitted to the secure area by the secure proxy for verification. If the data is authenticated, it is signed and transmitted, via the secure proxy, to the screen so as to trigger in the processor of the display screen, the execution of a task. said data can not trigger the execution of a task. The data is subsequently transmitted to the secure area by the secure proxy for verification. If the data is authenticated, it is signed and transmitted, via the secure proxy, to the screen so as to trigger in the processor of the display screen, the execution of a task. said data can not trigger the execution of a task. The data is subsequently transmitted to the secure area by the secure proxy for verification. If the data is authenticated, it is signed and transmitted, via the secure proxy, to the screen so as to trigger in the processor of the display screen, the execution of a task.

0048In some embodiments, a microcontroller (1) with a tamper (13) and secure area or trusted processing area (110) and a secure boot of the Linux operating system is used in a terminal (2) all-in-one including an LCD screen (16f), a capacitive touch screen (16f), a magnetic card reader (16h), a smart card reader (16g), a contactless card reader (16e), an upstream security circuit board (21), a connection circuit board (22) and a camera (16l) for constituting a tamper-proof terminal (2) in which each secured operation or secure peripheral device is managed by the secure area or trusted processing area (110) of the microcontroller (1) and wherein the protection of theaccess to this secure zone or trusted processing area (110) is protected against access of a probe to the microcontroller (1) by insertion of the main printed circuit (20) including the microcontroller (1) into a cage connection to detect any attempt to open the cage or drilling through the cage.

0049In some embodiments, the upstream security circuit (21) includes at least one proximity sensor (16k) for detecting any presence or action and sending a signal to the microcontroller (1) to perform an analysis and initiate an action ( displaying a welcome or usage message).

0050In some embodiments, the connection circuit board (22) comprises at least one USB interface (16a), a UART serial port (16i), an Ethernet interface (16j) and a Bluetooth (16c) / Wifi interface (16b) for communication and data exchange.

0051The present application describes various technical features and advantages with reference to the figures and / or various embodiments. Those skilled in the art will understand that the technical features of a given embodiment may in fact be combined with features of another embodiment unless the reverse is explicitly mentioned or it is evident that these characteristics are incompatible or that the combination does not provide a solution to at least one of the technical problems mentioned in this application. In addition, the technical features described in a given embodiment can be isolated from the other features of this mode unless the opposite is explicitly mentioned.

0052It should be obvious to those skilled in the art that the present invention allows embodiments in many other specific forms without departing from the scope of the invention as claimed. Therefore, the present embodiments should be considered by way of illustration, but may be modified in the field defined by the scope of the appended claims, and the invention should not be limited to the details given above.