An electronic control system for vehicle includes a center device that manages a program update of a vehicle, and a vehicular master device that is communicable with the center device. The center device, responsive to a user giving approval for program update by using a device not being a possession owned by the user, receives approval information of the user, and stores and manages the approval information in association with vehicle information of the user. The center device transmits the approval information to the user's vehicle side. When the vehicular master device receives the approval information, the vehicular master device performs rewriting of the program.

According to an example embodiment, a firmware rewriting apparatus includes: call position specifying means for specifying, among instructions described in a program of firmware stored in a memory, the instructions for changing a control flow; free area specifying means for specifying a free area in a storage area of the memory in which the program is not stored; and program rewriting means for rewriting the instruction specified by the call position specifying means into a call instruction of a frequency adjustment code and writing the frequency adjustment code for calling an inspection code at a frequency corresponding to a frequency of calling the frequency adjustment code and the inspection code for performing a security check of the program in response to a call from the frequency adjustment code into the free area specified by the free area specifying means.

Methods and devices are provided for installing and hiding applets onto smart cards devices. In a first step, a request for installing an instance of a first applet is received at the card device from an off-card entity. The request includes a first applet identifier. An applet instance is then installed with the first applet identifier in a registry of the card device's operating system. In a further step, a request for hiding the instance of the first applet identified by the first applet identifier is received at the card de-vice from the off-card entity. After receiving the hiding request, the smart card operating system finds the applet instance with the give applet identifier and hides it.

A process for management of Internet-of-Things (IoT) devices includes a management system for identifying, interrogating, and updating devices connected to one or more networks. The management system can include a data store for storing various data related to the devices and the various processes of the management system. The management system can include a controller for executing processes such as interrogation processes, firmware change processes, credential change processes, and other processes. The controller can determine versions of firmware and other configuration properties of a device and generate various profiles for updating the firmware and other configuration properties. The controller can determine upgrade paths for updating the firmware and other configuration properties from a first version to a second version, the upgrade paths including one or more intermediary versions for facilitating the upgrade path. The management system can update devices individually, on a device family basis, or on a system-wide basis.

Measurements of a device's firmware are made regularly and compared with prior, derived measurements. Prior measurements are derived from a set of identical firmware measurements obtained from multiple devices having the same make, model and firmware version number. The firmware integrity status is reported on a data and device security console for a group of managed endpoints. Alerts about firmware changes, which may be potential attacks on the firmware, are given automatically.

A method for receiving firmware including pieces of firmware data is provided. The method is performed by a first apparatus in a multicast group including at least the first apparatus and a second apparatus. The method includes (a) receiving first meta-information for the firmware data from the second apparatus, (b) generating, based on the first meta-information, second meta-information for at least one piece of firmware data to be used to apply the firmware to the first apparatus, among the firmware data, and (c) receiving, based on the second meta-information, the at least one piece of firmware data from a firmware providing apparatus or the second apparatus. The first meta-information includes at least history information including version and partitioning information for each of the pieces of firmware data, and the second meta-information includes at least the history information for each of the at least one piece of firmware data.

A computer platform includes a security processor; at least one hardware processor; and a memory. The security processor stores data representing a private platform key. The private platform key is part of an asymmetric pair of keys, and the asymmetric pair of keys includes a public platform key. The memory stores a firmware image. The firmware image includes data representing a root certificate of a public key infrastructure that signs a second certificate that is associated with the computer platform. The second certificate includes the public platform key and binding information binding the second certificate to the computer platform. The firmware image includes instructions that, when executed by the hardware processor(s), cause the hardware processor(s) to access data representing the second certificate and determine whether the second certificate is valid based on the root certificate and the binding information. The instructions, when executed by the hardware processor(s), further cause the hardware processor(s) to, responsive to determining that the second certificate is valid, use the public platform key to secure communication with the security processor.

A medical device includes at least one memory device storing data; a communication interface defining a first communication path to allow communications between the medical device and an external device or network; and a hardware key interface defining a second communication path that is separate from the first communication path. A hardware key is configured to be coupled to the meter via the second communication path defined by the hardware key interface. The data on the at least one memory device cannot be modified unless the hardware key interface is physically coupled to the hardware key. The hardware key may include a key code component and conducting lines, where the hardware key interface receives the key code via the conducting lines and the data on the at least one memory device cannot be modified unless the key code provided by the hardware key is validated.

A processing device sets a first flag that indicates whether a first critical security parameter (CSP) file exists. The first CSP file includes a first set of CSPs for a memory device. The processing device sets a second flag that indicates whether the first CSP file is valid. The processing device sets a third flag that indicates whether a second CSP file exists. The second CSP file includes a second set of CSPs for the memory device. The processing device sets a fourth flag that indicates whether the second critical security parameter file is valid. The processing device selects one of the first or second CSP file as an active CSP file based on an evaluation of the first, second, third, and fourth flags.

A method provides a firmware update to an electronic device, to code signing for firmware updates of electronic devices, and a system therefor. In particular, the system and method for updates firmware that is authenticated through a public key infrastructure. The method includes an electronic device receiving a firmware update provided with a signature of a signing key, a signing certificate with a signature of a master key, and a revision number. The device verifies the signature of the master key on the signing certificate of the signing key, checks the revision number on the signing certificate of the signing key against a roll back counter, and verifies the signature of the signing key on the firmware update. The device then rejecting or accepting the received firmware update based on the outcome of the above verifying and checking.