Flashing mechanism for updating one or more electronic devices

Abstract

The invention relates to a computer-implemented flashing mechanism (200) for enabling automated updating of preloaded software stored in at least one electronic device (10) connected to a flashing application run by a workstation (103); the preloaded software comprising a boot loader, a kernel, and an operating system. The flashing mechanism (200), implemented by the flashing application (FA), includes an information-sharing mechanism (300) for placing information to be shared between the boot loader and the operating system and / or by the flashing application in a data relay. Figure 2

Description

Title of the invention: Flashing mechanism for updating one or more electronic devices TECHNICAL FIELD AND SUBJECT OF THE INVENTION

[0001] The present invention relates to connected electronic devices, in particular connected watches (“smart watch” in English).

[0002] The invention relates more particularly to a flashing mechanism for automatically updating one or more connected electronic devices. STATE OF THE ART

[0003] Nowadays, there are more and more electronic products in many fields. For example, in the watchmaking sector, smartwatches are becoming increasingly common on the market.

[0004] A smartwatch operates using a mobile operating system and can therefore offer functions that a "conventional" watch, particularly a mechanical one, cannot perform, such as playing digital files (audio or video), measuring the user's physical activity (e.g., heart and respiratory rate), receiving FM radio (for "Frequency Modulation"), Bluetooth, Wi-Fi and / or cellular connectivity, and even mobile phone functions. The smartwatch can therefore be independent and is not limited to a remote display on a multifunctional mobile device ("smartphone").

[0005] To enable the above functions to be performed during use, software is pre-loaded before the smartwatch is sold. When the latest software version, providing improvements and / or corrections, is released, whether before or after the smartwatch is sold to the user, the pre-loaded software used by the smartwatch should be updated by an operator (e.g., the seller, the smartwatch manufacturer's logistics team, etc.) responsible for updating the smartwatch. Furthermore, it is desirable to avoid requiring the user (the end customer) to update the pre-loaded software on the day of purchase, even though it remains possible for the user to do so via a Wi-Fi network, but this is more cumbersome and time-consuming.

[0006] Updating pre-loaded software is performed via a process known as “flashing.” However, existing flashing processes generally include steps requiring manual intervention and / or tools that are difficult to master. For example, to activate a quick start-up function on the smartwatch, manual intervention is essential. For example, certain buttons must be pressed simultaneously for a short, predetermined duration. If necessary, Tools such as the "fastboot" command line must be used. Furthermore, the operator must know how to select items from a quick-start menu displayed on the smartwatch screen. In addition, the operator must monitor the flashing process, which lasts several minutes, almost continuously.

[0007] The above drawbacks are difficult to manage, particularly for operators using flashing tools who are not sufficiently skilled in IT. Furthermore, existing flashing tools or processes do not allow for the simultaneous updating of multiple smartwatches. In other words, there is currently no tool or process for mass flashing that can update thousands of smartwatches quickly with a small number of operators. Consequently, the drawbacks listed above are multiplied depending on the number of smartwatches to be updated, or in other words, "flashed."

[0008] There are therefore needs for a flashing mechanism configured to automatically and simultaneously update a large number of electronic devices, especially those of the connected type. GENERAL PRESENTATION OF THE INVENTION

[0009] The present invention relates to a computer-implemented flashing mechanism for enabling automated updating of preloaded software stored in at least one electronic device connected to a flashing application running on a workstation; the preloaded software comprising a boot loader, a kernel, and an operating system. The flashing mechanism, implemented by the flashing application, includes an information-sharing mechanism consisting of placing information to be shared between the boot loader and the operating system and / or the flashing application in a data relay directly accessible by the kernel.

[0010] The invention thus makes it possible to update, automatically and in parallel, a large number of electronic devices, in particular those of the connected type.

[0011] Preferably, the data relay is a kernel command line, and the information sharing mechanism comprises: • the addition of information to be shared with the boot loader, said information to be shared including operating system identification information and being added to the kernel command line during the generation of the kernel command line intended to be included in a boot loader image; and / or • the addition of information to be shared with the operating system, said information to be shared including a lock state and bootloader identification information, this information to be shared being added to the end of the kernel command line when (re)starting the electronic device.

[0012] Advantageously, the flashing mechanism comprises at least one of the following steps to be performed: • a restart step consisting of restarting the electronic device by automatically executing the bootloader without manual intervention and maintaining the electronic device in a bootloader mode for a predetermined period; • an unlocking step performed to unlock the electronic device's bootloader in order to allow a memory component of the electronic device to be reflashed.

[0013] Preferably, the flashing mechanism includes an authentication mechanism performed to secure the execution of the restart step and the unlocking step; the restart step and the unlocking step being respectively performed only following a positive confirmation obtained at the end of the authentication mechanism; the positive confirmation indicating that the execution of the flashing mechanism is desired by an operator in charge of updating the electronic device, and that said operator is recognized as an authorized operator to update the electronic device.

[0014] Advantageously, the unlocking step is carried out when the electronic device is in bootloader mode and positive confirmation is obtained at the end of the authentication mechanism.

[0015] Preferably, if the electronic device is in an operating system mode where the electronic device is running the operating system, the restart step is performed following the positive confirmation obtained at the end of the authentication mechanism.

[0016] Preferably, the flashing mechanism consists of: • perform the authentication mechanism only once in a case where the electronic device is in bootloader mode when connected to the workstation; • perform the authentication mechanism twice in a case where the electronic device is in operating system mode when connected to the workstation.

[0017] Advantageously, the flashing application includes a key pair corresponding to the operator and comprising a public key and a private key; the authentication mechanism comprising: • a step involving the generation of a cryptographic challenge by the electronic device • a challenge signing step consisting of generating, via the flashing application, a signature by signing the challenge using the private key; • a verification step of the received public key and signature, performed by the electronic device to determine whether the received public key is recognized or accepted by the electronic device, and to determine whether the received signature is signed by said operator associated with the received and accepted public key; in which the positive confirmation confirms that the received signature is signed by the operator associated with the received and accepted public key.

[0018] Advantageously, authentication information including one or more authorized public keys, each representing one of the authorized operators, or their associated representative values, is pre-recorded in the electronic device before the flashing mechanism is carried out.

[0019] Preferably, during the verification step, if a representative value of said received public key is equal to that of one of the authorized public keys, or if said received public key is identical to one of the authorized public keys, the electronic device recognizes or accepts the received public key.

[0020] Preferably, the representative value of said received public key and those of the authorized public keys are respectively a checksum generated from said public key and those respectively generated from one of said authorized public keys, using a secure hashing algorithm “SHA256” (abbreviation for “Secure Hash Algorithm 256” in English).

[0021] Advantageously, the flashing mechanism includes displaying on a workstation screen information including the flashing progress status of the electronic device.

[0022] Advantageously, the flashing mechanism is carried out when at least one electronic device is connected to the workstation via a USB access port (“Universal Serial Bus” in English).

[0023] Preferably, the flashing mechanism is configured to automatically and simultaneously update pre-loaded software stored in a plurality of connected electronic devices.

[0024] The invention also relates to a flashing system configured to perform a flashing mechanism as described above to allow an automated update of pre-loaded software stored in one or more electronic devices, the flashing system comprising a flashing application executed by a workstation which performs at least part of the flashing mechanism.

[0025] Preferably, the flashing system comprises the workstation including: • one or more USB access ports, each of which allows one of the electronic devices to communicate digital data with the workstation when the electronic device is connected to the workstation via the access port; • a screen configured to display information including the flashing progress of the electronic device. PRESENTATION OF THE FIGURES

[0026] The invention will be better understood upon reading the following description, given by way of example, and referring to the following figures, given by way of non-limiting examples, in which identical references are given to similar objects.

[0027] [Fig.1] illustrates a schematic representation of a flashing system according to an embodiment of the invention.

[0028] [Fig.2] illustrates the flashing mechanism according to one embodiment of the invention.

[0029] It should be noted that the figures set out the invention in detail to implement the invention, said figures being of course able to serve to better define the invention where appropriate. DETAILED DESCRIPTION OF THE INVENTION

[0030] In general, the invention thus relates to a flashing mechanism for updating one or more electronic devices 10, in particular for automatically and simultaneously updating a large number of connected electronic devices 10.

[0031] The electronic device 10 is, for example, a connected electronic device, in particular a smartwatch. The electronic device 10 includes one or more memory components 11 for storing digital data, a screen for displaying information to the user, and a processor 12 configured to perform, in cooperation with the memory component 11, the screen and other components of the electronic device 10, functions to be provided to the user of the electronic device 10.

[0032] During the manufacture or prior to the sale of the electronic device 10, software is preloaded and stored in partitions of the memory component 11, which is preferably flash memory. The preloaded software, executed by the processor 12, includes a bootloader and an operating system. The operating system includes a kernel, which is a fundamental part of the operating system, enabling the hardware and software components of the electronic device 10 to communicate with each other. The operating system ensures... In addition to basic functionalities, and layered on top of the operating system, a number of applications provide additional functionalities of interest to the user of the electronic device 10. According to one embodiment, the kernel and the operating system are respectively a "Linux Kernel®" kernel and a "Wear OS®" mobile operating system from Android® based on the Linux® kernel and developed by Google®. The invention is nevertheless not limited to the types of bootloader and / or operating system used by the electronic device 10.

[0033] The boot loader, the kernel, and the operating system are each an image, which is a block of binary code stored in the partitions of the memory component 11 of the electronic device 10. During boot of the electronic device 10, the processor 12 of the electronic device 10 first executes the boot loader image. At this stage, the electronic device 10 is in MCD boot loader mode. Then, the processor 12 performs operations, first in kernel space and then in user space. Kernel space and user space coexist when the electronic device 10 is in MSE operating system mode.

[0034] In kernel space, the processor 12 executes the kernel image to communicate with firmware of the electronic device 10. In user space (MSE mode), the processor 12 operates on the operating system to run mobile applications and / or perform functions desired by the user.

[0035] When the latest software updates bringing improvements and / or corrections to the pre-loaded software of one or more electronic devices 10 are published, the pre-loaded software used by the electronic devices 10 should respectively be updated by an authorized operator, e.g. the seller, the research and development team or the logistics team of the manufacturer of the electronic device 10. Such an operator is an "authorized operator" of a flashing mechanism 200 of the invention.

[0036] Furthermore, preferably, authentication information comprising one or more authorized public keys, each representing one of the authorized operators or groups of operators, or their associated representative values, is pre-recorded in the electronic device 10 before the sale of the electronic device 10 or before the flashing mechanism 200 is performed. Advantageously, the representative values ​​of the authorized public keys are each a checksum generated from one of said authorized public keys, using, for example, a secure hashing algorithm such as SHA256 (short for Secure Hash Algorithm 256). Compared to For authorized public keys, their representative values ​​occupy less memory space. It is therefore preferable to store the representative values ​​beforehand, instead of storing the corresponding authorized public keys beforehand, particularly in an embodiment where the memory space of memory component 11 is limited.

[0037] The invention relates to a flashing system 1 used by an operator to perform the flashing mechanism 200 so as to automatically update one or more electronic devices 10, or more precisely, to automatically update the software preloaded and stored in one or more electronic devices 10. Figure 1 illustrates a schematic representation of the flashing system 1 according to one embodiment of the invention. The flashing system 1 comprises a flashing application (indicated by "AF" in Figure 1) executed by a workstation 103 which serves as the host. The flashing application AF performs at least part of the flashing mechanism 200. According to a preferred embodiment, the invention allows automatic batch flashing, that is, the automatic flashing of a plurality of electronic devices 10 in parallel.

[0038] Figure 2 illustrates the flashing mechanism 200 according to one embodiment of the invention. The flashing mechanism 200, comprising an information sharing mechanism 300 and an authentication mechanism 400, can be performed whether one or both of the electronic devices 10 are in MCD bootloader mode or MSE operating system mode, respectively. The flashing mechanism 200 will be described in more detail after the description of the flashing system 1. For ease of understanding, the following description simply describes the automatic update of a single electronic device 10.

[0039] The flashing system 1 preferably includes the workstation 103. The workstation 103 can be any suitable device, for example, a desktop or laptop computer with a USB (Universal Serial Bus) interface, which includes a processor configured to run software applications including the flashing application. Alternatively, the workstation 103 can be a single-board nano-computer (e.g., a Raspberry Pi) equipped with a USB interface and remotely controlled (via a Wi-Fi network, for example) using a tablet or mobile device, in which the software applications including the flashing application are run by the tablet or mobile device. The workstation 103 further includes a data storage unit configured to store software updates, which are generally stored as "images."The data memory unit is also used to store at least some of the data generated and / or received during the execution of the flashing mechanism 200. The data memory unit can be any combination of memory means. premises integrated into the workstation 103 or, alternatively, a remote data storage means which is accessible by the workstation 103. In addition, the workstation 103 includes a screen configured to display to the operator information relating to the execution of the flashing mechanism 200, e.g. a flashing progress status of each of the electronic devices 10, and a warning message if a failure has occurred during the execution of the flashing mechanism 200, etc.

[0040] In one embodiment, the workstation 103 comprises one or more access ports, each of which allows one of the electronic devices 10 to communicate digital data with the workstation 103 when the electronic device 10 is connected via the access port to the workstation 103, either wired or wirelessly. Preferably, the electronic device 10 is connected to the access port of the workstation 103. Preferably, each access port corresponds to a port number. In one embodiment, the assignment of a port number to each access port is done via a calibration mechanism, which will be described in detail below. The access ports are, for example, USB ports to which the electronic devices 10 are connected. The number of access ports is preferably equal to or greater than the number of electronic devices 10 being updated in parallel.The invention is not limited to the types or number of access ports.

[0041] According to one embodiment, the workstation 103 includes a network interface for interfacing with a communication network and for performing communication and data transmission according to the network protocol(s) used to implement the communication network. The communication network is preferably implemented as a single network or, alternatively, a combination of several networks. The invention is not limited to the type(s) of network(s) used to implement the communication network. According to the invention, one or more types selected from the following wired and wireless networks may, in particular, be used to implement the communication network: Internet, Ethernet, wireless networks (e.g., Wi-Fi, Bluetooth, wide area network (WAN), personal area network (PAN), etc.), a cellular network according to 2G, 3G, 4G, or 5G telecommunications standards, and / or other suitable types of communication networks.

[0042] First, in order for the flashing mechanism 200 to be able to fully control the flashing of the electronic device(s) 10, an information-sharing mechanism 300 can be implemented to share information between the boot loader (in MCD mode), the kernel (in kernel space in MSE mode), the operating system (in user space in MSE mode), and the flashing application. The flashing mechanism 200 includes the implementation of an operating system service component configured to restart the electronic device 10, with automatic execution of the boot loader, without manual intervention (e.g., the buttons being pressed simultaneously for a short predetermined duration).

[0043] In addition, as mentioned previously, some of this information to be shared, which can be exposed without special protection, is preferably displayed on the screen of the workstation 103 during the execution of the flashing mechanism 200.

[0044] The information to be shared includes, for example, at least some of the following: the identification information (e.g., model name, number) of the electronic device 10, the identification information (e.g., name, version number) and lock status of the bootloader, the identification information (e.g., name, version number) of the operating system of the electronic device 10, a response to the challenge that the flashing application generates and sends to the electronic device 10 (the challenge-response authentication principle being described in more detail in the paragraphs concerning the 400 authentication mechanism), the port number of the access port through which the electronic device 10 is connected to the workstation 103, etc. The lock status indicates whether the bootloader of the electronic device 10 is "locked" or "unlocked".Writing and erasing data in the partitions of memory component 11 can be performed (i.e., the partitions of memory component 11 can be reflashed) only when the boot loader is unlocked.

[0045] At least some of this information to be shared is conventionally accessible only by the boot loader (e.g., the electronic device 10 being in MCD mode), or only by the operating system (in user space of MSE mode). For example, conventionally, the operating system identification information (e.g., "WearOS build ID") of the electronic device 10 is not stored in the boot loader image and is accessible only by the operating system. The boot loader lock state, on the other hand, is conventionally accessible only by the boot loader.

[0046] The information sharing mechanism 300 consists of placing, in a data relay directly accessible by the kernel (in kernel space of MSE mode), the information to be shared by the boot loader (in MCD mode), the operating system (in user space of MSE mode), and / or the flashing application. Data relays are, for example, a kernel command line or files such as attributes (e.g., sysfs attributes) used by the kernel to communicate with operating system service components. These attributes can be dynamically created and deleted when the electronic device 10 is connected to and disconnected from the workstation 103.

[0047] Two embodiments in which a kernel command line serves as a data relay are described above. In one embodiment, during the generation of the kernel command line intended to be included in the bootloader image, the identification information (e.g., "WearOS build ID") of the operating system of the electronic device 10 is added to the kernel command line. Thus, during a (re)boot of the electronic device 10, by reading said kernel command line, the bootloader retrieves the operating system identification information.

[0048] In another embodiment, during the (re)start of the electronic device 10, the boot loader reads the kernel command line included in the boot loader image and appends to the kernel command line the information to be shared with the operating system, e.g., the identification information (e.g., the name, the version number) and the boot loader lock state. Thus, the fact that the identification information and the boot loader lock state are not stored in the operating system image is no longer an obstacle for the operating system.

[0049] Another embodiment in which attributes created for use by the kernel and serving as data relays is described above. The kernel writes information about the flashing application, such as a challenge response generated by the flashing application, into one of the attributes. The operating system service component can then read the attribute to verify the challenge response, as described below in the description of the 400 authentication mechanism.

[0050] In addition to the information sharing mechanism 300 and the operating system service component, the flashing mechanism 200 further includes subsequent steps 210 to 240, including an authentication mechanism 400 carried out before step 220 of restarting the electronic device 10 and before step 230 of unlocking to secure the execution of these two steps 220 and 230.

[0051] The initiation step 210 includes a connection step 211 and, preferably, a confirmation step 212. The initiation step 210 is performed when the electronic device 10 is connected to the workstation 103 via one of the access ports (e.g., USB ports) of the workstation 103, in order to establish data communication between the flashing application and the electronic device 10. The connection step 211, performed by the flashing application, consists of initializing an automated negotiation process to establish parameters for data communication between the workstation 103 and the electronic device 10 before the start of data communication. The data communication includes data transmissions used and / or generated during the execution of the flashing mechanism 200. The confirmation step 212 is then performed by the flashing application so that the operator confirms the intention to update electronic device 10 (or electronic devices 10).

[0052] Next, the authentication mechanism 400, comprising the following steps 410 to 450, is implemented. The execution of step 220, restarting the electronic device 10, and that of step 230, unlocking, are, as mentioned previously, determined respectively based on the result of the authentication mechanism 400. To implement the authentication mechanism 400, the flashing application includes a key pair corresponding to the operator responsible for updating the electronic device 10; the key pair comprises a public key and a private key.

[0053] Step 410, the sending of a challenge request, performed by the flashing application, consists of sending a challenge request to the electronic device 10. The electronic device 10 then performs step 420, which generates a cryptographic challenge (commonly referred to as a "challenge"). During this step 420, the bootloader (if the electronic device 10 is in MCD bootloader mode) or the daemon (if the electronic device 10 is in MSE operating system mode) generates a challenge corresponding to the received challenge request. The daemon is an operating system service that runs continuously. The challenge is preferably a 28-byte random challenge with high entropy. The generated challenge is sent in response to the challenge request received from the flashing application.

[0054] In an embodiment in which the electronic device 10 is connected (e.g. plugged in) to one of the USB ports of the workstation 103, the challenge request from step 410 is included in a USB request sent to the electronic device 10 during the automated negotiation process between the workstation 103 and the electronic device 10. Furthermore, the challenge generated in step 420 is then included in a USB response sent to the workstation 103 to respond to said USB request.

[0055] Upon receiving the challenge, the flashing application performs step 430, the challenge signing step, which consists of generating a signature by signing the challenge using the operator's private key. More specifically, the flashing application encrypts the challenge with the private key to generate the signature. The flashing application then performs step 440, which consists of sending a challenge response to the electronic device 10, including the generated signature and the public key associated with the private key.

[0056] The electronic device 10 then performs step 450, which verifies the received public key and signature. The public key verification is performed to determine whether the received public key is recognized or accepted by the electronic device 10. In other words, the electronic device 10 verifies whether the operator associated with the received public key is one of the operators authorized to update the electronic device 10.

[0057] With regard to step 450, the response to the challenge generated and sent by the flashing application is preferably stored, as mentioned previously, in an attribute that the kernel uses to communicate with operating system service components. Furthermore, as described above, the authentication information previously stored in the electronic device 10 includes the authorized public keys or representative values ​​associated with these authorized public keys.

[0058] In a reference embodiment where the authentication information previously stored in the electronic device 10 includes the representative values ​​associated with the authorized public keys, the electronic device 10 calculates a representative value (e.g., a checksum) of said public key received from the workstation 103, using, for example, the "SHA256" algorithm. If the representative value of said received public key is equal to that of one of the authorized public keys, or if said received public key is identical to one of the authorized public keys, the electronic device 10 recognizes or accepts the received public key. The operator associated with the received public key is authorized to update the electronic device 10.

[0059] Next, the received signature is verified, based on the challenge corresponding to the received signature and the received and accepted public key, to determine if the received signature is signed by the operator associated with the received and accepted public key. More specifically, the electronic device 10 decrypts the received signature using the received public key to generate a decrypted result, and compares the decrypted result with the challenge generated in step 420 by the electronic device 10. If the decrypted result is identical to the generated challenge, the received signature is considered to be signed by the operator using their private key associated with the received and accepted public key. Preferably, the "SHA256" algorithm is used to calculate a representative value associated with the challenge (generated and sent in step 420) and that of the decrypted result, during the verification of the received signature.

[0060] If the electronic device 10 confirms that the received signature is signed by the operator using their private key associated with the received and accepted public key, the result of the authentication mechanism 400 is a positive confirmation. This positive confirmation indicates that the execution of the flashing mechanism 200 is desired by the operator responsible for updating the electronic device 10, and that said operator is recognized as an authorized operator to update the electronic device 10. Thus, the execution of step 220, which restarts the electronic device 10, and / or step 230, which unlocks it, can be carried out.

[0061] On the contrary, neither step 220 nor 230 is performed if the result of the The 400 authentication mechanism indicates that the signature is not signed by the operator using their private key associated with the received public key, or that the operator associated with the received public key is not recognized as an operator authorized to update the electronic device 10.

[0062] Following the positive confirmation obtained at the end of step 450 of the authentication mechanism 400, either step 230 of unlocking is carried out if the electronic device 10 at this stage is in MCD bootloader mode, or the flashing application requests the electronic device 10 to carry out step 220 of rebooting if the electronic device 10 at this stage is in MSE operating system mode.

[0063] The restart step 220 is performed to restart the electronic device 10 and to maintain the electronic device 10 in MCD bootloader mode for a predetermined period. The restart step 220 is performed by automatically executing the bootloader without manual intervention. Then, the authentication mechanism 400 is performed again to generate a new challenge and a new signature and to verify them. If a new positive confirmation is obtained after this second execution of the authentication mechanism 400, the unlocking step 230 is then performed. Thus, in a case where the electronic device 10 is in MSE mode when connected (e.g., plugged in) to the workstation 103, the flashing mechanism 200 consists of performing the authentication mechanism 400 twice.Alternatively, if the electronic device 10 is in MCD mode when connected to the workstation 103, the flashing mechanism 200 consists of performing the authentication mechanism 400 only once.

[0064] When the electronic device 10 is in MCD bootloader mode and positive confirmation is obtained at the end of the authentication mechanism 400, the unlocking step 230 is performed to unlock the bootloader in order to allow the partitions of the memory component 11 to be reflashed.

[0065] The flashing step 240, which consists of writing the latest software updates received from the workstation 103 to the partitions of the memory component 11 of the electronic device 10, is performed only after the unlocking step 230. Preferably, the flashing progress of the electronic device 10, for example, a step of the flashing mechanism 200 currently in progress for the electronic device 10, can be displayed on the screen of the workstation 103.

[0066] In an embodiment where the access port is a USB port, the challenge, public key, signature, and responses are transmitted between the electronic device 10 and the workstation 103, using a USB bulk endpoint or a USB control endpoint. More specifically, if the electronic device 10 is in MCD bootloader, a USB block endpoint is used whereas if the electronic device 10 is in MSE operating system mode, a USB control endpoint is used.

[0067] In a case where several electronic devices 10 are connected to the workstation 103 to be updated, the latest software updates corresponding to each of the electronic devices 10 are properly identified and previously retrieved by the workstation 103. Thus, when one of the electronic devices 10 is at the flashing step 240, the latest software updates corresponding to said electronic device 10 are not confused with those of another electronic device, and are written in the memory component 11 of said electronic device 10.

[0068] The electronic devices 10 can each start to perform the flashing mechanism 200 at different times, and / or spend different amounts of time performing the steps of the flashing mechanism 200. For example, the electronic devices 10 include a first and a second electronic device, and the second electronic device is at the challenge signing step 430 when the first electronic device is already at the flashing step 240.

[0069] Preferably, the flashing mechanism 200 further comprises a calibration mechanism 500 configured to display, during the automatic flashing of a plurality of electronic devices 10, to the operator a warning message indicating that one or more electronic devices of said plurality of electronic devices 10 encounters a failure or successive failures during the execution of the flashing mechanism 200. For ease of understanding, in the following description, only one electronic device 10 (“electronic device 10 in question” in the text below), among all the electronic devices 10 updated in parallel, encounters failures.

[0070] The calibration mechanism 500 includes port number assignment, failure detection with respect to the electronic device 10 in question, generation of a warning message, and preferably, automatic cancellation of the flashing mechanism 200 with respect to the electronic device 10 in question. The flashing application assigns a port number to each access port, as mentioned previously. When the flashing application detects failures (e.g., an error or a blockage) occurring during the execution of the flashing mechanism 200 with respect to the electronic device 10, the flashing application generates a warning message and informs the operator so that the operator is aware of these failures.Furthermore, as a preferential measure, the flashing application automatically ignores the electronic device 10 in question if the failures are not overcome after a predetermined period following the detection of these failures. The implementation of the flashing mechanism 200 compared to . The electronic device 10 in question is therefore suspended.

[0071] The warning message includes the port number of the access port through which the electronic device 10 in question is connected to the workstation 103. Preferably, the warning message also includes the following information: the identification information (e.g., model name, number) of the electronic device 10 in question, a brief description of the failures encountered, a step of the flashing mechanism 200 currently in progress, the identification information (e.g., name, version number) and the lock status of the bootloader, the identification information (e.g., name, version number) of the operating system of the electronic device 10 in question, etc.

[0072] The warning message is preferably displayed on the screen of the workstation 103, and advantageously, is displayed in red to attract the operator's attention. With the warning message, the operator can take the necessary action for the electronic device 10 in question, while allowing the remaining electronic devices 10 to continue to be updated in parallel. The calibration mechanism 500 thus avoids reflashing all the electronic devices 10 that were updated simultaneously, and saves considerable time.

[0073] The flashing system and the flashing mechanism according to the invention thus make it possible to update, automatically and in parallel, a large number of electronic devices, in particular those of the connected type.

[0074] The invention is not limited to the embodiments described above but extends to any embodiment consistent with its spirit.

Claims

Claims

1. Flashing mechanism (200) for enabling an automated update of preloaded software stored in at least one electronic device (10) connected to a flashing application (AF) executed by a workstation (103); the flashing mechanism (200) being implemented by the flashing application (AF); the preloaded software comprising a boot loader, a kernel and an operating system; the flashing mechanism (200) being characterized in that it comprises an information sharing mechanism (300) consisting of placing, in a data relay directly accessible by the kernel, information to be shared between the boot loader and the operating system and / or made available by the flashing application.

2. Flashing mechanism (200) according to the preceding claim, wherein the data relay is a kernel command line; the information sharing mechanism (300) comprising: • adding the information to be shared with the boot loader, said information to be shared comprising operating system identification information and being added in the kernel command line when generating the kernel command line intended to be included in a boot loader image; and / or • adding the information to be shared with the operating system, said information to be shared comprising a lock state and boot loader identification information, said information to be shared being added following the kernel command line when (re)starting the electronic device (10).

3. Flashing mechanism (200) according to any one of the preceding claims, comprising at least one of the following steps to be performed: • a restart step (220) consisting of restarting the electronic device (10) by automatically executing the boot loader without manual intervention and maintaining the electronic device (10) in a boot loader mode (MCD) for a predetermined period; • an unlocking step (230) performed to unlock the bootloader of the electronic device (10) to allow a memory component (11) of the electronic device (10) to be reflashed.

4. Flashing mechanism (200) according to the preceding claim, comprising an authentication mechanism (400) performed to secure the performance of the restart step (220) and that of the unlocking step (230); the restart step (220) and the unlocking step (230) being respectively performed only following a positive confirmation obtained at the end of the authentication mechanism (400); the positive confirmation indicating that the performance of the flashing mechanism (200) is desired by an operator in charge of updating the electronic device (10), and that said operator is recognized as an operator authorized to update the electronic device (10).

5. Flashing mechanism (200) according to the preceding claim, wherein: • when the electronic device (10) is in boot loader mode (MCD) and the positive confirmation is obtained at the end of the authentication mechanism (400), the unlocking step (230) is performed; • if the electronic device (10) is in an operating system mode (MSE) where the electronic device (10) executes the operating system, the restart step (220) is performed following the positive confirmation obtained at the end of the authentication mechanism (400).

6. A flashing mechanism (200) according to claim 4 or claim 5, comprising: • performing the authentication mechanism (400) once in a case where the electronic device (10) is in boot loader mode (BLM) when connected to the workstation (103); • performing the authentication mechanism (400) twice in a case where the electronic device (10) is in system mode operating system (MSE) when connected to the workstation (103).

7. Flashing mechanism (200) according to one of claims 4 to 6, wherein the flashing application comprises a key pair corresponding to the operator and comprising a public key and a private key; the authentication mechanism (400) comprising: • a step (420) of generating a cryptographic challenge by the electronic device (10); • a challenge signing step (430) consisting of generating, by the flashing application, a signature by signing the challenge using the private key; • a step (450) of verifying the public key and the signature received, carried out by the electronic device (10) to determine whether the public key received is recognized or accepted by the electronic device (10), as well as to determine whether the signature received is signed by said operator associated with the public key received and accepted; in which the positive confirmation confirms that the received signature is signed by the operator associated with the received and accepted public key.

8. Flashing mechanism (200) according to the preceding claim, wherein: • authentication information comprising one or more authorized public keys which each represent one of the authorized operators, or their associated representative values, are previously recorded in the electronic device (10) before the flashing mechanism (200) is carried out; • during the verification step (450), if a value representative of said received public key is equal to that of one of the authorized public keys, or if said received public key is identical to one of the authorized public keys, the electronic device (10) recognizes or accepts the received public key.

9. Flashing mechanism (200) according to the preceding claim, in wherein the representative value of said received public key and those of the authorized public keys are respectively a checksum generated from said public key and those respectively generated from one of said authorized public keys, using a secure hash algorithm “SHA256” (abbreviation of “Secure Hash Algorithm 256” in English).

10. Flashing mechanism (200) according to one of the preceding claims, comprising displaying on a screen of the workstation (103) information comprising the progress status of flashing of the electronic device (10).

11. Flashing mechanism (200) according to one of the preceding claims, being carried out when the at least one electronic device (10) is connected to the workstation (103) via a USB access port ("Universal Serial Bus" in English).

12. Flashing mechanism (200) according to one of the preceding claims, configured to update, automatically and in parallel, software preloaded and stored in a plurality of electronic devices (10) of the connected type.

13. A flashing system (1) configured to perform a flashing mechanism (200) according to any preceding claim for automatically updating software preloaded and stored in one or more electronic devices (10), the flashing system (1) comprising a flashing application executed by a workstation (103) that performs at least part of the flashing mechanism (200).

14. Flashing system (1) according to the preceding claim, comprising the workstation (103) comprising: • one or more USB access ports each of which allows one of the electronic devices (10) to communicate digital data with the workstation (103) when the electronic device (10) is connected to the workstation (103) via the access port; • a screen configured to display information including the progress of flashing the electronic device (10).

Images