[go: up one dir, main page]

WO2018119873A1 - Method for controlling functioning of microprocessor - Google Patents

Method for controlling functioning of microprocessor Download PDF

Info

Publication number
WO2018119873A1
WO2018119873A1 PCT/CN2016/113006 CN2016113006W WO2018119873A1 WO 2018119873 A1 WO2018119873 A1 WO 2018119873A1 CN 2016113006 W CN2016113006 W CN 2016113006W WO 2018119873 A1 WO2018119873 A1 WO 2018119873A1
Authority
WO
WIPO (PCT)
Prior art keywords
microprocessor
security element
operating system
request message
authentication request
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.)
Ceased
Application number
PCT/CN2016/113006
Other languages
French (fr)
Inventor
Shunhua ZHAO
Yongsheng QI
Ren Liu
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.)
Gemalto Smart Cards Technology Co Ltd
Original Assignee
Gemalto Smart Cards Technology Co Ltd
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 Gemalto Smart Cards Technology Co Ltd filed Critical Gemalto Smart Cards Technology Co Ltd
Priority to PCT/CN2016/113006 priority Critical patent/WO2018119873A1/en
Publication of WO2018119873A1 publication Critical patent/WO2018119873A1/en
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Images

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
    • G06F21/575—Secure boot
    • 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/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/44—Program or device authentication
    • 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

Definitions

  • the present invention relates to telecommunications and proposes a method for controlling the functioning of a microprocessor.
  • the present invention applies notably to IoT (Internet of Things) devices comprising microprocessors.
  • IoT Internet of Things
  • a microprocessor processes instructions comprised in a memory. When the microprocessor is powered on, boot instructions present in ROM are first executed. These boot instructions are also called Boot ROM: Boot ROM is a small piece of mask ROM or write-protected flash embedded inside the microprocessor chip. It contains the very first code which is executed by the microprocessor on power-on or reset. Depending on the configuration of some strap pins or internal fuses it may decide from where to load the next part of the code to be executed.
  • bootloader Other types of boot instructions are comprised in a program called bootloader.
  • Bootloader is responsible for finding and loading the final OS or firmware which is supposed to run on the microprocessor.
  • bootrom One main difference from bootrom is that it's usually in writable flash and can be replaced or upgraded.
  • bootrom can perform the job of the bootloader. However, in many cases a separate bootloader is used, either because the bootrom is not capable enough (or absent) , or because extra flexibility is needed.
  • the problem is that some IoT devices use microprocessors without secure boot sequences of the OS: These sequences can have been modified and this rises a security issue. Bootloader or final OS can be replaced by non-authorized ones. This may result in a security leakage: The microprocessor and bootrom which do not have the capability to authenticate the final OS or bootloader, will boot non-authorized bootloader or final OS as usual. The device provider or OS provider will lose the connection of their device after deployment when such a device is for example communicating over the air with a telecommunication network.
  • the present invention proposes a solution to this problem.
  • the invention proposes to add to such a device a security element, such as UICC (Universal Integrated Circuit Card) or an embedded UICC (eSE for embedded Secure Element or eUICC for embedded UICC) for authentication purposes of the OS of the device.
  • a security element such as UICC (Universal Integrated Circuit Card) or an embedded UICC (eSE for embedded Secure Element or eUICC for embedded UICC) for authentication purposes of the OS of the device.
  • the invention proposes a method for controlling the functioning of a microprocessor comprised in a device, the microprocessor cooperating with a memory storing an operating system, the microprocessor also cooperating with a security element, wherein it consists in, after power on of the microprocessor, the memory and the security element:
  • the operating system didn’t send an authentication request message to the security element, or
  • the operating system has sent an authentication request message to the security element but the security element didn’t authenticate the operating system.
  • the device is preferably an IoT device.
  • the security element is preferably an embedded security element.
  • the invention also concerns a device comprising a microprocessor cooperating with a memory storing an operating system, the microprocessor also cooperating with a security element, this device comprising means for:
  • the operating system didn’t send an authentication request message to the security element, or
  • the operating system has sent an authentication request message to the security element but the security element didn’t authenticate the operating system.
  • the security element cooperates preferably with a pattern checking module able to recognize a special pattern sent by the security element for resetting the microprocessor.
  • FIG. 1 an improved device according to the present invention
  • FiG. 1 represents an improved device according to the present invention.
  • a device 10 comprises a microprocessor 11 and a memory chip 12.
  • the microprocessor 11 communicates with the memory chip 12 through an address/data bus 13.
  • the microprocessor 11 here contains a facultative Boot Rom containing, like already said, the very first code which is executed by the microprocessor 11 on power-on or reset.
  • the OS which is supposed to run on the microprocessor 11 is stored in the memory chip 12 that can be an EEPROM or a Flashprom for example. It is this OS that the invention proposes to authenticate.
  • the invention proposes to add to the device 10 a security element 15 comprising an OS authentication module.
  • the security element 15 is here in the form of an eSE (embedded Security Element) and communicates with the microprocessor through an I/O bus 17.
  • eSE embedded Security Element
  • the security element has the following function: After power on of the microprocessor 11, the memory 12 and the security element 15:
  • the operating system didn’t send an authentication request message to the security element 15, or
  • the operating system has sent an authentication request message to the security element 15 but the security element 15 didn’t authenticate the operating system.
  • the security element has therefore two functions: The first one is to measure the time elapsed between the power on of the microprocessor 11 (that causes a reset of the microprocessor 11) and a given delay (for example 15 seconds) . If within these 15 seconds the OS didn’t send an authentication request message to the security element 15, the security element 15 considers that it cannot trust this OS. The second function is, when such an authentication request message is sent from the OS to the security element 15, the security element 15 checks this message. If the message is authenticated, the OS can be trusted. Otherwise, the OS cannot be trusted.
  • the security element 15 resets the microprocessor 11.
  • the reset is realized through a pattern checking module 18 which entries are connected to the I/O bus 17.
  • the eSE 15 sends on the bus 17 a predefined pattern (a sequence of commands/data) that is recognized by the pattern checking module 18. This module then delivers a reset signal to the microprocessor 11.
  • the microprocessor 11 then tries a new boot sequence.
  • the authentication of the OS by the eSE 15 can be done by several ways:
  • -A hash of the OS can be sent by the OS to the security element 15. This hash can be compared to a hash of reference;
  • -A signature of the OS can also be sent to the security element 15, this signature having to be authenticated by the security element 15; if the comparison of the received signature and a signature of reference fails, the microprocessor is reset.
  • An OS digest can also be checked, or signature of OS blocks...
  • the Bootrom 14 is not mandatory in the scope of the invention, the main point being that the OS placed on an external chip 21 be checked.
  • the eSE 15 boots rapidly, it is also possible to simultaneously power on the eSE 15, the microprocessor 11 and the memory chip 12.
  • the security element 15 can use another I/O interface to connect with the microprocessor disable function PIN, like security element 15 support additional PIN of: SPI or I2C or SWP. In such case, there could be chances that eSE sends a disable signal through these PINs to disable the microprocessor; the security element can keep using I/O ISO pin to communicate with microprocessor for OS authentication.
  • Figure 2 represents workflows of three scenarios of the method according to the present invention.
  • MCU is called a “Non-secure boot MCU” since some high-end MCUs or microprocessors have the secure boot feature embedded in their boot ROM: Before MCU bootrom boots bootloader or final OS, MCU can check if the bootloader or final OS is authorized one.
  • the step common to the three scenarios is referenced 101:
  • the MCU (microprocessor or microcontroller unit) 11 boots the device OS stored in memory chip 12. This happens immediately after the microprocessor is powered on.
  • the first scenario is referenced A. It corresponds to a scenario where the OS is successfully authenticated.
  • the OS sends an authentication request message to the eSE 15 at step 102.
  • This message is sent during the time frame within which the eSE 15 is waiting for such a message.
  • the eSE authenticated successfully the OS and can, at step 104 a confirmation message to the OS.
  • the result (step 105) is that the OS boots successfully (no reset of the microprocessor) .
  • step 113 is that the MCU stops working and the boot has failed.
  • the OS has sent an authentication request message to the eSE at step 120 but the eSE didn’t authenticate this OS (step 121) .
  • steps 11-113 in scenario B the same steps 121-124 occur.
  • the device 10 according to the invention is preferably an IoT device like a door, a washing machine, a TV or a fridge.
  • the invention also concerns a device 10 comprising a microprocessor 11 storing a boot sequence 14 and cooperating with a memory 12 storing an operating system, the microprocessor 11 also cooperating with a security element 15, this device comprising means for:
  • the operating system didn’t send an authentication request message to the security element 15, or
  • the operating system has sent an authentication request message to the security element 15 but the security element 15 didn’t authenticate the operating system.
  • the means for resetting the microprocessor 11 can be constituted by a pattern checking module 18 cooperating with the security element 15, this pattern checking module 18 being able to recognize a special pattern sent by the security element 15 for resetting the microprocessor 11.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Storage Device Security (AREA)

Abstract

A method is provided for controlling the functioning of a microprocessor (11) comprised in a device, the microprocessor (11) cooperating with a memory (12) storing an operating system, the microprocessor (11) also cooperating with a security element (15), wherein it consists in, after power on of the microprocessor (11), the memory (12) and the security element (15) : -reset the microprocessor (11) by the security element (15) if: -within a given time frame, the operating system didn't send an authentication request message to the security element (15), or -within the given time frame, the operating system has sent an authentication request message to the security element (15) but the security element (15) didn't authenticate the operating system.

Description

A method for controlling the functioning of a microprocessor
The present invention relates to telecommunications and proposes a method for controlling the functioning of a microprocessor.
The present invention applies notably to IoT (Internet of Things) devices comprising microprocessors.
A microprocessor processes instructions comprised in a memory. When the microprocessor is powered on, boot instructions present in ROM are first executed. These boot instructions are also called Boot ROM: Boot ROM is a small piece of mask ROM or write-protected flash embedded inside the microprocessor chip. It contains the very first code which is executed by the microprocessor on power-on or reset. Depending on the configuration of some strap pins or internal fuses it may decide from where to load the next part of the code to be executed.
Other types of boot instructions are comprised in a program called bootloader.
Bootloader is responsible for finding and loading the final OS or firmware which is supposed to run on the microprocessor. One main difference from bootrom is that it's usually in writable flash and can be replaced or upgraded.
Sometimes bootrom can perform the job of the bootloader. However, in many cases a separate bootloader is used, either because the bootrom is not capable enough (or absent) , or because extra flexibility is needed.
The problem is that some IoT devices use microprocessors without secure boot sequences of the OS: These sequences can have been modified and this rises a security issue. Bootloader or final OS can be replaced by non-authorized ones. This may result in a security leakage: The microprocessor and bootrom which do not have the capability to authenticate the final OS or bootloader, will boot non-authorized bootloader or final OS as usual. The device provider or OS provider will lose the connection of their device after deployment when such a device is for example communicating over the air with a telecommunication network.
The present invention proposes a solution to this problem.
More precisely, the invention proposes to add to such a device a security element, such as UICC (Universal Integrated Circuit Card) or an embedded UICC (eSE for embedded Secure Element or eUICC for embedded UICC) for authentication purposes of the OS of the device.
More precisely, the invention proposes a method for controlling the functioning of a microprocessor comprised in a device, the microprocessor cooperating with a memory storing an operating system, the microprocessor also cooperating with a security element, wherein it consists in, after power on of the microprocessor, the memory and the security element:
-reset the microprocessor by the security element if:
-within a given time frame, the operating system didn’t send an authentication request message to the security element, or
-within the given time frame, the operating system has sent an authentication request message to the security element but the security element didn’t authenticate the operating system.
The device is preferably an IoT device.
The security element is preferably an embedded security element.
The invention also concerns a device comprising a microprocessor cooperating with a memory storing an operating system, the microprocessor also cooperating with a security element, this device comprising means for:
-resetting the microprocessor by the security element if:
-within a given time frame, the operating system didn’t send an authentication request message to the security element, or
-within the given time frame, the operating system has sent an authentication request message to the security element but the security element didn’t authenticate the operating system.
The security element cooperates preferably with a pattern checking module able to recognize a special pattern sent by the security element for resetting the microprocessor.
Other features and advantages of the invention will appear below when reading the description of the figures that represent:
-Fig. 1 an improved device according to the present invention；
-Fig. 2 workflows of three scenarios of the method according to the present invention.
FiG. 1 represents an improved device according to the present invention.
In this figure, a device 10 comprises a microprocessor 11 and a memory chip 12. The microprocessor 11 communicates with the memory chip 12 through an address/data bus 13. The microprocessor 11 here contains a facultative Boot Rom containing, like  already said, the very first code which is executed by the microprocessor 11 on power-on or reset.
Here, the OS which is supposed to run on the microprocessor 11 is stored in the memory chip 12 that can be an EEPROM or a Flashprom for example. It is this OS that the invention proposes to authenticate.
For this purpose, the invention proposes to add to the device 10 a security element 15 comprising an OS authentication module. The security element 15 is here in the form of an eSE (embedded Security Element) and communicates with the microprocessor through an I/O bus 17.
The security element has the following function: After power on of the microprocessor 11, the memory 12 and the security element 15:
-reset the microprocessor 11 if:
-within a given time frame, the operating system didn’t send an authentication request message to the security element 15, or
-within this given time frame, the operating system has sent an authentication request message to the security element 15 but the security element 15 didn’t authenticate the operating system.
The security element has therefore two functions: The first one is to measure the time elapsed between the power on of the microprocessor 11 (that causes a reset of the microprocessor 11) and a given delay (for example 15 seconds) . If within these 15 seconds the OS didn’t send an authentication request message to the security element 15, the security element 15 considers that it cannot trust this OS. The second function is, when such an authentication request message is sent from the OS to the security element 15, the security element 15 checks this message. If the message is authenticated, the OS can be trusted. Otherwise, the OS cannot be trusted.
In both cases, when the OS cannot be trusted, the security element 15 resets the microprocessor 11.
In figure 1, the reset is realized through a pattern checking module 18 which entries are connected to the I/O bus 17. For obtaining the reset, the eSE 15 sends on the bus 17 a predefined pattern (a sequence of commands/data) that is recognized by the pattern checking module 18. This module then delivers a reset signal to the microprocessor 11.
The microprocessor 11 then tries a new boot sequence.
The authentication of the OS by the eSE 15 can be done by several ways:
-A hash of the OS can be sent by the OS to the security element 15. This hash can be compared to a hash of reference；
-Several instructions of the OS can be compared to instructions of reference； If all instructions are recognized and in the right order, the OS is authenticated and the microprocessor is allowed to finish his boot；
-A signature of the OS can also be sent to the security element 15, this signature having to be authenticated by the security element 15； if the comparison of the received signature and a signature of reference fails, the microprocessor is reset. An OS digest can also be checked, or signature of OS blocks…
The Bootrom 14 is not mandatory in the scope of the invention, the main point being that the OS placed on an external chip 21 be checked.
For having a precise measure of the time elapsed between the power on of the microprocessor 11 (and of course the memory chip 12) and the moment when the eSE decides that it didn’t receive the authentication request message in time, it is advisable to first power on the eSE 15 and, after this eSE having booted, power on the microprocessor 11 and the memory chip 12.
If the eSE 15 boots rapidly, it is also possible to simultaneously power on the eSE 15, the microprocessor 11 and the memory chip 12.
Instead of using a pattern checking module 18, the security element 15 can use another I/O interface to connect with the microprocessor disable function PIN, like security element 15 support additional PIN of: SPI or I2C or SWP. In such case, there could be chances that eSE sends a disable signal through these PINs to disable the microprocessor； the security element can keep using I/O ISO pin to communicate with microprocessor for OS authentication.
Figure 2 represents workflows of three scenarios of the method according to the present invention.
Here the MCU is called a “Non-secure boot MCU” since some high-end MCUs or microprocessors have the secure boot feature embedded in their boot ROM: Before MCU bootrom boots bootloader or final OS, MCU can check if the bootloader or final OS is authorized one.
The step common to the three scenarios is referenced 101: The MCU (microprocessor or microcontroller unit) 11 boots the device OS stored in memory chip 12. This happens immediately after the microprocessor is powered on.
The first scenario is referenced A. It corresponds to a scenario where the OS is successfully authenticated.
For this successful authentication, the OS sends an authentication request message to the eSE 15 at step 102. This message is sent during the time frame within which the eSE 15 is waiting for such a message.
At step 103, the eSE authenticated successfully the OS and can, at step 104 a confirmation message to the OS. The result (step 105) is that the OS boots successfully (no reset of the microprocessor) .
The second and third scenarios are noted B and C. In these scenarios, the OS is not properly authenticated:
For scenario B, no authentication request has been received by the eSE 15 within the aforementioned given time frame (step 110) . The eSE 15 then sends the pre-defined pattern to the pattern checking module 18 (step 111) and this module 18 recognises the pattern and disables the microprocessor by resetting it (step 112) .
The result (step 113) is that the MCU stops working and the boot has failed.
For scenario C, the OS has sent an authentication request message to the eSE at step 120 but the eSE didn’t authenticate this OS (step 121) . As for steps 11-113 in scenario B, the same steps 121-124 occur.
The device 10 according to the invention is preferably an IoT device like a door, a washing machine, a TV or a fridge.
The invention also concerns a device 10 comprising a microprocessor 11 storing a boot sequence 14 and cooperating with a memory 12 storing an operating system, the microprocessor 11 also cooperating with a security element 15, this device comprising means for:
-resetting the microprocessor 11 by the security element 15 if:
-within a given time frame, the operating system didn’t send an authentication request message to the security element 15, or
-within the given time frame, the operating system has sent an authentication request message to the security element 15 but the security element 15 didn’t authenticate the operating system.
The means for resetting the microprocessor 11 can be constituted by a pattern checking module 18 cooperating with the security element 15, this pattern checking module 18 being able to recognize a special pattern sent by the security element 15 for resetting the microprocessor 11.

Claims (7)

  1. A method for controlling the functioning of a microprocessor (11) comprised in a device, said microprocessor (11) cooperating with a memory (12) storing an operating system, said microprocessor (11) also cooperating with a security element (15) , wherein it consists in, after power on of said microprocessor (11) , said memory (12) and said security element (15) :
    -reset said microprocessor (11) by said security element (15) if:
    -within a given time frame, said operating system didn’t send an authentication request message to said security element (15) , or
    -within said given time frame, said operating system has sent an authentication request message to said security element (15) but said security element (15) didn’t authenticate said operating system.
  2. A method according to claim 1, wherein said device (10) is an IoT device.
  3. A method according to any of the claims 1 and 2, wherein said security element (15) is an embedded security element.
  4. A method according to any of the claims 1 to 3, wherein said microprocessor (11) stores a boot sequence.
  5. A device (10) comprising a microprocessor (11) cooperating with a memory (12) storing an operating system, said microprocessor (11) also cooperating with a security element (15) , wherein it comprises means for:
    -resetting said microprocessor (11) by said security element (15) if:
    -within a given time frame, said operating system didn’t send an authentication request message to said security element (15) , or
    -within said given time frame, said operating system has sent an authentication request message to said security element (15) but said security element (15) didn’t authenticate said operating system.
  6. A device according to claim 5, wherein said security element (51) cooperates with a pattern checking module (18) able to recognize a special pattern sent by said security element (15) for resetting said microprocessor (11) .
  7. A device according to any of the claims 5 or 6, wherein said microprocessor (11) stores a boot sequence.
PCT/CN2016/113006 2016-12-29 2016-12-29 Method for controlling functioning of microprocessor Ceased WO2018119873A1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/CN2016/113006 WO2018119873A1 (en) 2016-12-29 2016-12-29 Method for controlling functioning of microprocessor

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/CN2016/113006 WO2018119873A1 (en) 2016-12-29 2016-12-29 Method for controlling functioning of microprocessor

Publications (1)

Publication Number Publication Date
WO2018119873A1 true WO2018119873A1 (en) 2018-07-05

Family

ID=62710895

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2016/113006 Ceased WO2018119873A1 (en) 2016-12-29 2016-12-29 Method for controlling functioning of microprocessor

Country Status (1)

Country Link
WO (1) WO2018119873A1 (en)

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1416545A (en) * 2000-02-11 2003-05-07 英特尔公司 Protected boot flow
CN102693389A (en) * 2011-03-22 2012-09-26 联想(北京)有限公司 Method and apparatus for controlling CPU and CPU
CN104318142A (en) * 2014-10-31 2015-01-28 山东超越数控电子有限公司 Trusted booting method of computer
CN104866343A (en) * 2015-05-15 2015-08-26 长城信息产业股份有限公司 Security startup method for embedded equipment and securely-started embedded equipment

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1416545A (en) * 2000-02-11 2003-05-07 英特尔公司 Protected boot flow
CN102693389A (en) * 2011-03-22 2012-09-26 联想(北京)有限公司 Method and apparatus for controlling CPU and CPU
CN104318142A (en) * 2014-10-31 2015-01-28 山东超越数控电子有限公司 Trusted booting method of computer
CN104866343A (en) * 2015-05-15 2015-08-26 长城信息产业股份有限公司 Security startup method for embedded equipment and securely-started embedded equipment

Similar Documents

Publication Publication Date Title
EP3480720B1 (en) Method and system for downloading software based on mobile terminal
US8996851B2 (en) Host device and method for securely booting the host device with operating system code loaded from a storage device
US10084604B2 (en) Method of programming a smart card, computer program product and programmable smart card
US20150019856A1 (en) Secure download and security function execution method and apparatus
US20140250290A1 (en) Method for Software Anti-Rollback Recovery
US10360396B2 (en) Token-based control of software installation and operation
US20170255384A1 (en) Efficient secure boot carried out in information processing apparatus
US9875366B2 (en) Microprocessor system with secured runtime environment
US10936722B2 (en) Binding of TPM and root device
GB2514771A (en) Methods of securely changing the root key of a chip, and related electronic devices and chips
KR102114432B1 (en) Integrated subscriber identification module with core OS and application OS
KR102244465B1 (en) Electronic assembly comprising a disabling module
CN112685338A (en) Semiconductor device including secure repairable ROM and method of repairing the same
WO2017045627A1 (en) Control board secure start method, and software package upgrade method and device
CN105264934A (en) Mobile station comprising security resources with different security levels
KR20160142319A (en) System and method for boot sequence modification using chip-restricted instructions residing on an external memory device
CN113348110B (en) Electronic control device and security verification method for electronic control device
US10193694B1 (en) Method and apparatus for securely configuring parameters of a system-on-a-chip (SOC)
KR101379522B1 (en) Method and system for providing a data module lock to device hardware, system and method for confirming that a circuit card is compatible with a computer
EP2308003B1 (en) Verification key handling
WO2021012170A1 (en) Firmware booting method and device, and computer-readable storage medium
WO2018119873A1 (en) Method for controlling functioning of microprocessor
US11698994B2 (en) Method for a first start-up operation of a secure element which is not fully customized
CN112533196A (en) Trusted starting method and device for mobile terminal equipment
US10715527B2 (en) Method of managing profiles in a secure element

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 16925692

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 16925692

Country of ref document: EP

Kind code of ref document: A1