Generation and management of secure encryption keys in an open and secure processor environment

By generating and authenticating secure application keys in the security subsystem of embedded and portable electronic systems, the problem of insufficient encryption in traditional systems is solved, the security of data storage and access is improved, and the security risks of the system are reduced.

CN114257371BActive Publication Date: 2026-04-03RENESAS ELECTRONICS CORP
View PDF 3 Cites 0 Cited by

Patent Information

Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
Filing Date
2021-09-23
Publication Date
2026-04-03

AI Technical Summary

Technical Problem

Traditional systems cannot effectively store, access, or manage sensitive data in embedded and portable electronic systems, especially in open and secure processor environments, where security risks and insufficient encryption exist.

Method used

By generating authentication codes and application keys in the security subsystem of the local processing device, using the authentication keys and application keys to generate a secure application key, and then authenticating it at the security subsystem, the security and reliability of the encryption process are ensured.

Benefits of technology

It enables the efficient generation and management of secure encryption keys in an open and secure processor environment, improving the security of data storage and access, and reducing system security risks.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN114257371B_ABST
    Figure CN114257371B_ABST
Patent Text Reader

Abstract

This application relates to the generation and management of secure encryption keys in an open and secure processor environment. An example implementation includes the following methods: generating a first authentication code at least partially based on an authentication key and an application key; transmitting the authentication key, the application key, and the first authentication code to a secure subsystem of a local processing device; generating a second authentication code at the secure subsystem at least partially based on the authentication key and the application key; and generating a secure application key at the secure subsystem based on a determination that the first and second authentication codes satisfy an authentication criterion.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This embodiment generally relates to encryption systems, and more specifically to the generation and management of secure encryption keys in open and secure processor environments. Background Technology

[0002] Embedded and portable electronic systems are becoming increasingly complex and face greater security risks. Furthermore, the number and flexibility of use cases for embedded and portable computer systems are expanding. Embedded and portable computer systems are increasingly required to store, access, and manage sensitive information in a wide variety of scenarios, while also supporting open and flexible application operations. However, in sufficiently broad use cases, traditional systems may not be able to effectively store, access, or manage sensitive data on embedded or portable electronic systems using sufficiently secure encryption. Therefore, a technical solution is needed for the generation and management of secure encryption keys in an open and secure processor environment. Summary of the Invention

[0003] An example implementation includes a method that: generates a first authentication code based at least in part on an authentication key and an application key; transmits the authentication key, the application key, and the first authentication code to a security subsystem of a local processing device; generates a second authentication code at the security subsystem based at least in part on the authentication key and the application key; and generates a secure application key at the security subsystem based on a determination that the first authentication code and the second authentication code satisfy an authentication criterion.

[0004] The example implementation also includes a method for: obtaining a secure application key at a security subsystem of the local processing system; obtaining an application key at the security subsystem based at least in part on the secure application key; obtaining a first authentication code at the security subsystem based at least in part on the secure application key; obtaining a device identifier key at the security subsystem; generating a second authentication code at the security subsystem based on the application key and the device identifier key; and accepting the application key based on the determination that the first authentication code and the second authentication code satisfy the authentication standard.

[0005] The example implementation also includes a device having a system processor and a security processor, the system processor being configured to: generate a first authentication code based at least in part on an authentication key and an application key, and transmit the authentication key, the application key, and the first authentication code; the security processor being operatively coupled to the system processor and configured to: receive the authentication key, the application key, and the first authentication code; generate a second authentication code based at least in part on the authentication key and the application key; and generate a secure application key based on a determination that the first authentication code and the second authentication code satisfy an authentication criterion. Attached Figure Description

[0006] These and other aspects and features of this embodiment will become clear to those skilled in the art after reading the following description of specific embodiments in conjunction with the accompanying drawings, wherein:

[0007] Figure 1 The figure illustrates an exemplary system according to this implementation.

[0008] Figure 2 The diagram is based on Figure 1 An exemplary security subsystem of an exemplary system.

[0009] Figure 3 The diagram illustrates an exemplary method for generating secure application keys on a local system according to this implementation.

[0010] Figure 4 Diagram of the continuation Figure 3 An exemplary method for generating a secure application key at the security subsystem of a local system.

[0011] Figure 5 Diagram of the continuation Figure 4 An exemplary method for generating a security application key associated with a local system.

[0012] Figure 6 The diagram illustrates an exemplary method for authenticating a secure application key according to this implementation.

[0013] Figure 7 The diagram illustrates an exemplary method for generating secure application keys at a remote system according to this implementation. Detailed Implementation

[0014] This embodiment will now be described in detail with reference to the accompanying drawings, which are provided as illustrative examples of the embodiments to enable those skilled in the art to practice the described embodiments and alternatives that will be apparent to them. It is important to note that the following drawings and examples are not intended to limit the scope of this embodiment to a single embodiment, but rather other embodiments are possible by interchangeing some or all of the elements described or illustrated. Furthermore, where certain elements of this embodiment may be implemented partially or entirely using known components, only those portions of such known components necessary for understanding this embodiment will be described, and detailed descriptions of other portions of such known components will be omitted to avoid obscuring the embodiment. Embodiments described as being implemented in software are not intended to be limited thereto, but may include embodiments implemented in hardware or a combination of software and hardware, and vice versa, as will be apparent to those skilled in the art, unless otherwise stated herein. Embodiments showing a single component in this specification should not be considered limiting; rather, this disclosure is intended to cover other embodiments including multiple identical components, and vice versa, unless expressly stated otherwise herein. Furthermore, the applicant does not intend to assign any terminology in the specification or claims an uncommon or special meaning unless expressly stated otherwise. Moreover, this embodiment covers current and future known equivalents of known components mentioned herein by way of illustration.

[0015] Figure 1 The diagram illustrates an exemplary system according to this implementation. Figure 1 As illustrated in the examples, exemplary system 100 includes at least one of a local system 110 and a remote system 120. In some implementations, local system 110 includes a system processor 102, boot firmware 104, a security subsystem 106, system memory 108, a communication interface 112, and a system bus 114. In some implementations, local system 110 includes an electronic circuit board, a printed circuit board, a conductive substrate, etc. In some implementations, remote system 120 includes a secure key memory 122 and an encryptor 124.

[0016] In some implementations, remote system 120 includes a server computer or the like that operatively coupled to or operatively coupled to local system 110 via one or more wired, wireless, digital, network, or similar connections.

[0017] System processor 102 is operable to execute one or more instructions associated with local processing system 110. In some implementations, system processor 102 is an electronic processor, integrated circuit, etc., including one or more digital logic, analog logic, digital sensors, analog sensors, communication buses, volatile memory, non-volatile memory, etc. In some implementations, system processor 102 includes, but is not limited to, at least one microcontroller unit (MCU), microprocessor unit (MPU), central processing unit (CPU), graphics processing unit (GPU), physical processing unit (PPU), embedded controller (EC), etc. In some implementations, system processor 102 includes memory operable to store or be storing one or more instructions for operating system processor 102 components and for operating components operatively coupled to system processor 102. In some implementations, the one or more instructions include at least one of firmware, software, operating system, embedded operating system, etc. It should be understood that system processor 102 or local system 110 typically includes at least one communication bus controller to enable communication between system processor 102 and other components of local system 110.

[0018] The boot firmware 104 is operable to execute one or more instructions to operate, initialize, start, restart, shut down, or hibernate one or more of the local system 110, system processor 102, security subsystem 106, system memory, and communication interface 112. In some implementations, the boot firmware includes one or more electrical, electronic, and logic devices. In some implementations, the boot firmware includes one or more integrated circuits, transistors, transistor arrays, etc. In some implementations, the boot firmware includes one or more boot instructions, a boot loader, etc.

[0019] Security subsystem 106 is operable to perform processing, storage, retrieval, etc., that are inaccessible to one or more of the system processor 102, boot firmware 104, system memory 108, communication interface 112, and remote system 120. In some implementations, the security subsystem includes restrictions on access to one or more storage devices, storage locations, storage addresses, etc. In some implementations, the security subsystem includes restrictions on access to one or more processing devices, processing functions, etc. In some implementations, the security subsystem stores or is operable to store information received by the communication interface at the local system. As an example, the security subsystem may store passwords, financial information, encryption keys, user identity information, security tokens, etc. In some implementations, the security subsystem stores or is operable to store immutable data. In some implementations, immutable data cannot be changed once written. As an example, immutable data includes, but is not limited to, device identifiers, unique keys associated with local system 110, unique key indexes associated with local system 110, key generation seeds, key generation instructions, etc. Therefore, in some implementations, security subsystem 106 can perform one or more functions that are inaccessible to any device or system outside the security subsystem.

[0020] System memory 108 is operable to store data associated with local system 110. In some implementations, system memory 108 includes one or more hardware storage devices for storing binary data, digital data, etc. In some implementations, system memory 108 includes one or more electrical components, electronic components, programmable electronic components, reprogrammable electronic components, integrated circuits, semiconductor devices, flip-flops, arithmetic units, etc. In some implementations, system memory 108 includes at least one of non-volatile storage devices, solid-state storage devices, flash memory devices, and NAND storage devices. In some implementations, system memory 108 includes one or more addressable memory regions disposed on one or more physical memory arrays. In some implementations, the physical memory array includes a NAND gate array disposed on a particular semiconductor device, integrated circuit device, printed circuit board device, etc.

[0021] Communication interface 112 is operable to communicatively couple local system 110 to remote system 120. In some implementations, communication interface 112 includes one or more network interface devices, channels, etc. In some implementations, the communication interface includes an Internet communication interface or is operatively combinable to an Internet communication interface via one or more external devices, systems, etc. System bus 114 is operable to transmit one or more instructions, signals, conditions, states, etc., between one or more of system processor 102, boot firmware 104, system memory 108, communication interface 112, and remote controller 120. In some implementations, system bus 114 includes one or more digital, analog, or other communication channels, lines, traces, etc.

[0022] The security key storage 122 is operable to store and retrieve one or more security keys associated with the local system 110. In some implementations, the security key storage includes one or more devices according to system memory 108. In some implementations, the security key storage 122 includes one or more magnetic, optical, magnetic tape, solid-state disks, or disk arrays. In some implementations, the security key storage 122 includes either write-once, non-rewritable, or similar storage devices.

[0023] Encryptor 124 is operable to execute one or more instructions for generating encrypted or decrypted data objects, operable to convert encrypted data objects into decrypted data objects, and operable to convert decrypted data objects into encrypted data objects. As an example, data objects include binary or text files, strings, etc. In some implementations, encryptor 124 includes one or more instructions for encrypting one or more data objects according to a predetermined encryption method, process, etc. As an example, encryption methods include methods for generating symmetric encryption keys, methods for generating asymmetric encryption keys, methods for verifying encryption keys, methods for encrypting data using encryption keys, and methods for decrypting data using encryption keys. In some implementations, the predetermined encryption method is immutably written into encryptor 124 during the manufacture of the local processing device 110.

[0024] In some implementations, the encryptor 124 includes one or more logic or electronic devices, including but not limited to integrated circuits, logic gates, flip-flops, gate arrays, programmable gate arrays, etc.

[0025] Figure 2 The diagram is based on Figure 1 An exemplary security subsystem of an exemplary system. For example... Figure 2 As illustrated in the examples, exemplary security subsystem 200 includes a secure memory 202, a secure processor 204, a secure key memory 206, an encryptor 208, and a true random number generator 210. In some implementations, security subsystem 106 includes exemplary security subsystem 200.

[0026] The secure memory 202 is operable to store data associated with the secure subsystem 200. In some implementations, the secure subsystem 200 restricts or prevents access to at least a portion of the secure memory 202 from the local processing system 110. In some implementations, the secure subsystem 200 restricts or prevents direct addressing of at least a portion of the secure memory 202 from the local processing system 110. In some implementations, the secure memory 202 includes one or more hardware storage devices for storing binary data, digital data, etc. In some implementations, the secure memory 202 includes one or more electrical components, electronic components, programmable electronic components, reprogrammable electronic components, integrated circuits, semiconductor devices, flip-flops, arithmetic units, etc. In some implementations, the secure memory 202 includes at least one of non-volatile memory devices, solid-state storage devices, flash memory devices, and NAND flash memory devices. In some implementations, the secure memory 202 includes one or more addressable memory regions disposed on one or more physical memory arrays. In some implementations, the physical memory array includes a NAND gate array disposed on a specific semiconductor device, integrated circuit device, printed circuit board device, etc.

[0027] Security processor 204 is operable to execute one or more instructions associated with security subsystem 200. In some implementations, security processor 204 restricts or prevents access to at least a portion of security memory 202 from local processing system 110. In some implementations, security processor 204 restricts or prevents direct addressing of at least a portion of security memory 202 from local processing system 110. In some implementations, security processor 204 is operable to perform one or more processing operations associated with restricted access to or prevention of access to security subsystem 200. In some implementations, security processor 204 is operatively coupled to system bus 114. In some implementations, security processor 204 includes one or more devices according to system processor 102.

[0028] The security key memory 206 is operable to store and retrieve one or more security keys associated with the local processing system 110. In some implementations, the security key memory 206 includes one or more devices according to system memory 108. In some implementations, the security key memory 206 is integrated with the security memory 202. In some implementations, the security key memory 206 is a physical or logical portion of the security memory 206. In some implementations, the security key memory 206 includes either a write-once, non-rewritable, or similar storage device.

[0029] Encryptor 208 is operable to execute one or more instructions for generating encrypted or decrypted data objects, operable to convert encrypted data objects into decrypted data objects, and operable to convert decrypted data objects into encrypted data objects. In some implementations, encryptor 208 includes one or more devices according to encryptor 124. True random number generator 210 is operable to generate one or more true random numbers, pseudo random numbers, etc. In some implementations, the true random number generator is integrated with security processor 204. In some implementations, true random number generator 210 includes one or more logic or electronic devices, including but not limited to integrated circuits, logic gates, flip-flops, gate arrays, programmable gate arrays, etc.

[0030] Figure 3 The illustration shows an exemplary method for generating a secure application key on a local system according to this implementation. In some implementations, exemplary system 100 performs method 300 according to this implementation.

[0031] In some implementations, method 300 begins with step 310.

[0032] In step 310, the exemplary system obtains the User Factory Programming Key (UFPK). In some implementations, the UFPK is stored in and obtained from system memory 108.

[0033] In some implementations, the UFPK is operable to encrypt user data, application data, user keys, application keys, etc. In some implementations, the UFPK is stored in system memory 108 as part of the manufacturing process, manufacturer installation process, etc., of the local processing system 110. Alternatively, in some implementations, the UFPK is transferred to a local processing system 110 outside of the manufactured local processing system. In some implementations, the UFPK is unique to the local processing device 110 or any of its components. In some implementations, the UFPK is not unique to the local processing device 110 and is associated with its aspects or components. As an example, a non-unique UFPK may be associated with a specific series, model, group, etc., of the local processing system 110. Method 300 then proceeds to step 312.

[0034] In step 312, the exemplary system obtains a message authentication code key (MACK). In some implementations, the MACK is stored in and obtained from system memory 108. In some implementations, the MACK is operable to securely generate at least one message authentication code, authentication code, etc. In some implementations, the MACK is stored in system memory 108 as part of the manufacturing process, manufacturer installation process, etc., of the local processing system 110. Alternatively, in some implementations, the MACK is transferred to a local processing system 110 outside of the manufactured local processing system. As an example, the MACK may be transferred to the local processing system during a refurbishment process, etc. In some implementations, the MACK is unique to the local processing device 110 or any of its components. In some implementations, the MACK is not unique to the local processing device 110 and is associated with its aspects or components. As an example, a non-unique MACK may be associated with a specific series, model, group, etc., of the local processing system 110. Method 300 then proceeds to step 320.

[0035] In step 320, the exemplary system generates a key bundle KB including the UFPK and MACK. In some implementations, the KB is or includes a wrapper, group, etc., containing the UFPK and MACK. In some implementations, the KB is a different data object, container, etc., including the UFPK and MACK. As an example, the KB can be a JSON object, etc. Alternatively, in some implementations, the KB is an index, address, reference, etc., associated with the UFPK and MACK. It should be understood that the KB can include additional data, objects, etc. It should also be understood that the UFPK and MACK can be bundled separately in different key bundles. It should also be understood that the exemplary system can optionally generate the KB. Method 300 then proceeds to step 322.

[0036] In step 322, the exemplary system transfers the KB from the local system to the remote system. In some implementations, the exemplary system transfers the KB from the local system 110 to the remote system 120 via communication interface 112. In some implementations, the exemplary system transfers the KB to the remote system 120 via an encrypted, secure, or similar communication channel, interface, etc. It should be understood that the exemplary system may transfer multiple key packets to the remote system 120, and may transfer the KB to the remote system 120 in a packetized format, etc. It should also be understood that the exemplary system may optionally transfer the KB, and may transfer both the UFPK and MACK to the remote system 120. Method 300 then proceeds to step 330. In step 330, the exemplary system receives the encrypted key packet KB from the remote system 120 at the local system 110. EIn some implementations, the exemplary system receives KB from the remote system 120 at the local system 110 via communication interface 112. In some implementations, the exemplary system receives KB from the remote system 120 via encrypted, secure, or similar communication channels, interfaces, etc. It should be understood that the exemplary system can receive multiple key packets from the remote system 120 at the local system 110, and can receive KB from the remote system 120 in packet format, etc. E It should also be understood that the exemplary system may optionally receive KB. E And it can receive UFPK from remote system 120 E and MACK E without KB E Or any one or more key packets. Method 300 then proceeds to step 332.

[0037] In step 332, the exemplary system receives a hardware root key index N from a remote system at the local system. In some implementations, the hardware root key index identifies one or more available hardware root keys at the local system 110. In some implementations, a security key memory 206 stores one or more immutable hardware root keys. In some implementations, the security key memory 206 stores multiple hardware root keys, including index identifiers, in the form of an array or the like. In some implementations, the hardware root key index N identifies an array or similar index associated with one of the multiple hardware root keys at the security key memory 206 or the local processing system 110. Method 300 then proceeds to step 340.

[0038] In step 340, the exemplary system obtains the application key AK. In some implementations, the AK is stored in and obtained from system memory 108. In some implementations, the AK is associated with at least one user application, user program, user data object, etc.

[0039] In some implementations, the AK is stored in system memory 108 as part of the manufacturing process, manufacturer installation process, etc., of the local processing system 110. Alternatively, in some implementations, the AK is transferred to the local processing system 110 outside the manufacturing local processing system. In some implementations, the AK is unique to the user application, user program, user data object, etc. In some implementations, the AK is not unique to the user application, user program, user data object, etc., and is associated with multiple AKs. As an example, a non-unique AK can be associated with multiple applications, application programming interfaces, etc., or any combination thereof. Method 300 then proceeds to step 342.

[0040] In step 342, the exemplary system generates a message authentication code (MAC) based at least partially on the AK and MACK. In some implementations, at least one of the security processor 204 and the encryptor 208 generates the MAC. Method 300 then proceeds to step 350. In step 350, the exemplary system generates an encrypted application key (AK) based at least partially on the UFPK. E In some implementations, at least one of the security processor 204 and the encryptor 208 generates an AK. E Method 300 then proceeds to step 360.

[0041] In step 360, the exemplary system will KB E AK E The MAC address is transferred from the local system to the security subsystem. In some implementations, the system processor 102 will transfer KB... E AK E One or more of the MAC components are transferred to boot firmware 104, and boot firmware 104 will transfer KB E AK E One or more of the data in the MAC are transmitted to the security subsystem 106. Alternatively, in some implementations, the system processor 102 will transfer KB... E AK E One or more MACs are directly transmitted to the security subsystem 106. In some implementations, at least one of the security memory 202 and the security processor 204 receives KB. E AK E And one or more of the MAC. Method 300 then proceeds to step 362. In step 362, the exemplary system transfers index N from the local system to the security subsystem. It should be understood that the exemplary system optionally transfers index N in response to optionally receiving index N from remote system 120. In some implementations, system processor 102 transfers index N to boot firmware 104, and boot firmware 104 transfers index N to security subsystem 106. Alternatively, in some implementations, system processor 102 directly transfers index N to security subsystem 106. In some implementations, at least one of security memory 202 and security processor 204 receives KB E AK E And one or more of the MACs. In some implementations, method 300 then proceeds to step 410.

[0042] Figure 4 Diagram of the continuation Figure 3 This is an exemplary method for generating a secure application key at the security subsystem of a local system. In some implementations, exemplary system 100 executes method 400 according to this implementation. In some implementations, method 400 begins at step 410. Method 400 then continues to step 412.

[0043] In step 412, the exemplary system obtains a KB at the security subsystem. E AK E And MAC. In some implementations, at least one of the secure memory 202 and the secure processor 204 receives KB. E AK E And at least one of MAC. Method 400 then proceeds to step 414.

[0044] In step 414, the exemplary system obtains index N at the security subsystem. In some implementations, at least one of security memory 202 and security processor 204 obtains index N. It should be understood that the exemplary system optionally obtains index N at the security subsystem 106 in response to optionally receiving index N from remote system 120. Method 400 then proceeds to step 416. In step 416, the exemplary system selects a hardware root key seed based at least partially on index N. In some implementations, security processor 204 selects a hardware root key seed from at least one of security memory 202 and security key memory 206. In some implementations, the hardware root key seed is one of a plurality of hardware root key seeds in an array, etc. In some implementations, the exemplary system selects a hardware root key seed by selecting the hardware root key seed at the index corresponding to index N from an array of hardware root key seeds. It should be understood that the exemplary system optionally selects a hardware root key seed based at least partially on index N at the security subsystem 106 in response to optionally receiving index N from remote system 120. Method 400 then proceeds to step 420.

[0045] In step 420, the exemplary system generates a hardware root key HRK, at least in part, based on a hardware root key seed. In some implementations, at least one of the security processor 204 and the encryptor 208 generates the hardware root key HRK. Method 400 then proceeds to step 430.

[0046] In step 430, the exemplary system performs a KB test. E Decrypt the UFPK to obtain the decrypted user factory programming key UFPK. D In some implementations, the exemplary system is at least partially based on HRK for KB. E Decrypt the UFPK to obtain the decrypted user factory programming key UFPK. D In some implementations, at least one of the security processor 204 and the encryptor 208 is paired with KB. E The UFPK is decrypted. In some implementations, exemplary systems decrypt the KB. E Decrypt the container to obtain UFPK DAlternatively, the exemplary system, in response to receiving a UFPK that is directly encrypted within an unencrypted key packet or directly receiving an encrypted UFPK without a key packet, directly decrypts the encrypted UFPK to obtain the UFPK. D Method 400 then proceeds to step 432.

[0047] In step 432, the exemplary system performs a KB test. E Decrypt the MACK to obtain the decrypted message authentication key MACK. D In some implementations, at least one of the security processor 204 and the encryptor 208 is paired with KB. E The system decrypts the MACK. In some implementations, exemplary systems decrypt the KB. E Decrypt the container to obtain the MACK D Alternatively, the exemplary system, in response to receiving a MACK that is directly encrypted within an unencrypted key packet, or directly receiving an encrypted MACK without a key packet, directly decrypts the encrypted MACK to obtain the MACK. D Method 400 then proceeds to step 434. In step 434, the exemplary system uses UFPK. D Decrypting the AK E To obtain the application key AK for decryption D In some implementations, at least one of the security processor 204 and the encryptor 208 decrypts the AK. D Method 400 then proceeds to step 440.

[0048] In step 440, the exemplary system is at least partially based on AK. D and MACK D Generate verification message authentication code (MAC) V In some implementations, at least one of the security processor 204 and the encryptor 208 generates a MAC. V Method 400 then proceeds to step 450.

[0049] In step 450, the exemplary system determines the MAC. V Does the MAC match? In some implementations, at least one of the security processor 204 and the encryptor 208 determines the MAC. V Whether it matches the MAC address. In some implementations, the MAC address... V The MAC address is a string, and this determination includes determining the MAC address. V The difference between MAC and MAC. Alternatively, this determination includes taking MAC... V The hash of the MAC address is matched against the hash of the MAC address. It should be understood that the exemplary system may perform matching based on other alternative matching methods according to this implementation. Based on the MAC address... VAfter determining the MAC address, proceed to step 400 and then to step 452. Alternatively, based on the MAC address... V Upon determining a MAC mismatch, method 400 then proceeds to step 454. In step 452, the exemplary system will... D The AK is rejected as untrusted. In some implementations, the security processor 204 rejects the untrusted AK. D This involves performing deletion, removal, tagging, and identification. In some implementations, method 400 ends at step 452. In step 454, the exemplary system accepts the AK. D It is trusted. In some implementations, the security processor 204 checks the accepted trusted AK. D This involves saving, recording, tagging, and identifying data. In some implementations, method 400 then proceeds to step 510.

[0050] Figure 5 Diagram of the continuation Figure 4 This is an exemplary method for generating a secure application key associated with a local system. In some implementations, exemplary system 100 executes method 500 according to this implementation. In some implementations, method 500 begins at step 510. Method 500 then continues to step 512.

[0051] In step 512, the exemplary system obtains a unique device identifier (uID). In some implementations, the system processor 102 obtains the uID from system memory 108. In some implementations, the uID is stored in system memory 108. Method 500 then proceeds to step 514.

[0052] In step 514, the exemplary system generates a unique message authentication code (uMAC) associated with the uID. In some implementations, at least one of the security processor 204 and the encryptor 208 generates the uMAC. In some implementations, the exemplary system bases the uMAC on the uID and the authenticated AK. D A uMAC is generated. Method 500 then proceeds to step 520. In step 520, the exemplary system generates a random seed RS. In some implementations, RS is or includes a string. In some implementations, the exemplary system optionally generates RS in response to selection, confirmation, setting, flags, etc. In some implementations, the exemplary system optionally generates RS based on user input received at one or more of the security processor 204 and system processor 102. Method 500 then proceeds to step 530.

[0053] In step 530, the exemplary system generates a security application key AK. S In some implementations, at least one of the security processor 204 and the encryptor 208 generates an AK. SIn some implementations, step 530 includes one or more of steps 532 and 534. In step 532, the exemplary system attaches the uMAC to the AK. D It should be understood that the exemplary system can connect the uMAC and AK through any string or data aggregation process. D Combination. In step 534, the exemplary system forwards the RS to the AK. D It should be understood that the exemplary system can optionally connect RS with AK through any string or data aggregation process. D Combine. Method 500 and then proceed to step 540.

[0054] In step 540, the exemplary system obtains a hardware-unique key HUK. In some implementations, at least one of the security processor 204 and the encryptor 208 obtains the HUK from at least one of the secure memory 202 and the secure key memory 206. In some implementations, the secure key memory 206 is associated with or uniquely associated with the local processing system 110. In some implementations, the secure key memory 206 is associated with or uniquely associated with the security subsystem 106. In some implementations, the secure key memory 206 stores the HUK unchanged, either thereafter or thereafter. Method 500 then proceeds to step 542. In step 542, the exemplary system encrypts the AK using the HUK. S In some implementations, the encrypted AK... S Includes RS, in order to increase the size of the decryption problem computationally, while increasing the AK for decryption without HUK. S The difficulty. Therefore, the exemplary system can be achieved by including a system with AK. S The RS, while technically limiting computing devices with quantifiable computing resources to decrypt AK without HUK. S Method 500 then proceeds to step 550. It should be understood that in some implementations, the exemplary system may execute steps 540, 542, and 550 independently of any uID. Furthermore, it should be understood that in such an implementation, AK... S It could be an AK D Therefore, in some implementations, the example system proceeds directly from step 510 to step 540.

[0055] In step 550, the exemplary system will AK S The data is transferred to the system memory of the local processing system. In some implementations, the security processor 204 transmits the AK via the system bus 114. S The data is transferred to system memory 108. Therefore, in the case of HUK encryption associated with or uniquely associated with security subsystem 106, AK... SIt can be stored outside of the security subsystem 106. As an example, if the security memory 202 has a limited size compared to the system memory 108, then AK... S It is advantageous to store it in system memory 108. As another example, consider AK... S Stored in system memory to allow one or more programs, applications, instructions, etc. to be based on AK S One or more actions are requested from security subsystem 106. In some implementations, method 500 ends at step 550.

[0056] Figure 6 The illustration shows an exemplary method for an authentication security application key according to this implementation. In some implementations, exemplary system 100 executes method 600 according to this implementation. In some implementations, method 600 begins at step 610.

[0057] In step 610, the exemplary system obtains AK from system memory. S In some implementations, the security processor 204 obtains the AK from the system memory 108 via the system bus 114. S Method 600 then proceeds to step 620.

[0058] In step 620, the exemplary system decrypts the AK using HUK. S In some implementations, at least one of the security processor 204 and the encryptor 208 decrypts the AK. S In some implementations, at least one of the security processor 204 and the encryptor 208 uses the HUK stored by at least one of the security key memory 206 and the security memory 202 to decrypt the AK. S In some implementations, this exemplary system decrypts the AK. S This involves generating or obtaining one or more data objects. In some implementations, the obtained data object includes one or more of an application key, a message authentication code, and a random seed. It should be understood that in some implementations, the example system may terminate operations on unsuccessful decryption attempts. In some implementations, unsuccessful decryption attempts include at least one decryption attempt using a corrupted HUK. In some implementations, unsuccessful decryption attempts include at least one decryption attempt using a HUK associated with a system outside the example system. In some implementations, unsuccessful decryption attempts include at least one decryption attempt using a HUK containing untrusted, malicious, or similar components, parts, etc. Therefore, in some implementations, the method terminates at step 620. Alternatively, in some implementations, method 600 then continues to step 622.

[0059] In step 622, the exemplary system retrieves the decrypted AK SObtain the decryption application key AK D In some implementations, at least one of the security processor 204 and the encryptor 208 obtains an AK. D Method 600 then proceeds to step 624. In step 624, the exemplary system retrieves the decrypted AK... S Obtain the unique message authentication code uMAC for decryption. D In some implementations, at least one of the security processor 204 and the encryptor 208 obtains a uMAC. D Method 600 then proceeds to step 630.

[0060] In step 630, the exemplary system is at least partially based on AK. D Generate a unique authentication message (uMAC) with uID. V In some implementations, at least one of the security processor 204 and the encryptor 208 generates a uMAC. V Method 600 then proceeds to step 640.

[0061] In step 640, the exemplary system determines the MAC. V Whether a MAC match is found. In some implementations, at least one of the security processor 204 and the encryptor 208 is determined. In some implementations, the exemplary system executes step 640 according to step 450. Based on the MAC... V After determining the MAC address, method 600 proceeds to step 642. Alternatively, based on the MAC address... V Upon determining a mismatched MAC address, method 600 then proceeds to step 644. In step 642, the exemplary system assigns the AK... D The system is rejected as untrusted. In some implementations, the exemplary system executes step 642 according to step 452. In some implementations, method 600 ends at step 642. In step 644, the exemplary system accepts AK. D This is considered reliable. In some implementations, the exemplary system executes step 644 according to step 454. In some implementations, method 600 ends at step 644.

[0062] Figure 7 The illustration shows an exemplary method for generating a secure application key at a remote system according to this implementation. In some implementations, exemplary system 100 executes method 700 according to this implementation. In some implementations, method 700 begins at step 710.

[0063] In step 710, the exemplary system obtains the key packet KB from the local system. In some implementations, the encryptor 124 obtains the KB from the communication interface 112 of the local system 110. It should be understood that the remote system 120 may include at least one communication interface conforming to or compatible with communication interface 112. It should also be understood that the encryptor 124 may indirectly receive the KB and any other communications from the local system 110 and other systems through its communication interface or a device between the remote system 120 and the local system 110. In some implementations, the communication interface is or includes a secure communication interface. As an example, the secure communication interface is or includes PGP encrypted data exchange over a secure HTTPS connection. Method 700 then proceeds to step 712.

[0064] In step 712, the exemplary system selects a hardware root key index N. In some implementations, the encryptor 124 selects a hardware root key index N. In some implementations, the security key memory 122 stores one or more hardware keys that match, correspond to, or are similar to one or more hardware keys stored on the local system 110. In some implementations, the security key memory 122 stores an array of multiple hardware keys that match, correspond to, or are similar to an array of multiple hardware keys stored on the local system 110. In some implementations, the security key memory immutably stores one or more hardware keys or arrays of hardware keys associated with the security key memory. Therefore, the remote system 120 and the local system 110 can perform encryption and decryption operations without transferring any hardware root key between them. Method 700 then proceeds to step 720. In step 720, the exemplary system selects a hardware root key HRK. In some implementations, the encryptor 124 selects a hardware root key associated with the local system 110. In some implementations, step 720 includes step 722. In step 722, the exemplary system selects the index hardware root key associated with index N. It should be understood that the exemplary system may selectively select the hardware root key of the local system's index, where multiple hardware root keys indexable by N may be stored optionally. Method 700 then proceeds to step 730.

[0065] In step 730, the exemplary system encrypts the KB with the selected HRK to generate an encrypted key packet KB. E In some implementations, step 730 includes one or more of steps 732 and 734. In step 732, the exemplary system uses HRK to encrypt the user factory programming key UFPK to generate an encrypted user factory programming key UFPK. EIn some implementations, the UFPK is embedded, encapsulated in a KB, associated with a KB, etc. In some implementations, the KB including the UFPK is encrypted. Alternatively, in some implementations, the UFPK is directly encrypted. It should be understood that the UFPK can be encrypted with or without a KB in any way compatible with local system 110 and step 330. In step 734, the exemplary system encrypts the message authentication key MACK with HRK to generate an encrypted message verification key MACK. E In some implementations, the MACK is embedded, encapsulated in, associated with, or similar to the KB. In some implementations, the KB including the MACK is encrypted. Alternatively, in some implementations, the MACK is directly encrypted. It should be understood that the MACK can be encrypted with or without a KB in any way compatible with local system 110 and step 330. Method 700 then proceeds to step 740.

[0066] In step 740, the exemplary system will KB E Transmitted to the local system. In some implementations, the encryptor 124 will be KB. E Communication interface 112 transmits data to local system 110. In some implementations, the exemplary system correspondingly transmits KB... E The KB is obtained in step 710. In some implementations, method 700 ends at step 740. Alternatively, in some implementations, the method then continues to step 742. In step 742, the exemplary system transfers index N to the local system. It should be understood that the exemplary system may optionally transfer index N according to one or more of steps 332 and 722. In some implementations, method 700 ends at step 742.

[0067] The topics described herein sometimes refer to different components contained within or connected to different other components. It should be understood that the architectures depicted are illustrative, and many other architectures can actually be implemented to achieve the same functionality. Conceptually, any arrangement of components that achieves the same functionality is effectively “associated” to achieve the desired function. Therefore, any two components combined herein to achieve a particular function can be considered “associated” with each other to achieve the desired function, regardless of the architecture or intermediate components. Similarly, any two such associating components can also be considered “operably connected” or “operably coupled” to each other to achieve the desired function, and any two components that can be so associating can also be considered “operably coupled” to each other to achieve the desired function. Specific examples of operably coupled components include, but are not limited to, physically matable and / or physically interactive components and / or wirelessly interactive and / or logically interactive and / or logically interactive components.

[0068] Regarding the use of plural and / or singular terms in this document, those skilled in the art can convert plural to singular and / or from singular to plural where the context and / or application are appropriate. For clarity, various singular / plural substitutions may be explicitly described herein.

[0069] Those skilled in the art will understand that, in general, the terms used herein, and especially those used in the appended claims (e.g., the body of the appended claims), are intended to be “open” terms (e.g., the term “comprising” should be interpreted as “including but not limited to”, the term “having” should be interpreted as “at least having”, the term “including” should be interpreted as “including but not limited to”, etc.).

[0070] Although the accompanying drawings and descriptions may illustrate a specific order of method steps, the order of these steps may differ from that depicted and described unless otherwise specified above. Furthermore, unless otherwise stated above, two or more steps may be performed simultaneously or partially simultaneously. For example, such variations may depend on the chosen software and hardware system and the designer's choices. All such variations are within the scope of this disclosure. Similarly, the software implementation of the described methods can be accomplished using standard programming techniques, incorporating rule-based logic and other logic to perform the various connection steps, processing steps, comparison steps, and decision steps.

[0071] Those skilled in the art will further understand that if an intention is to cite a specific number of the introduced claim, that intention will be explicitly stated in the claim, and without such a citation, no such intention exists. For example, to aid understanding, the appended claims below may contain the use of introductory phrases “at least one” and “one or more” to introduce the statement of the claim. However, the use of such phrases should not be construed as implying that introducing a claim citation by the wording “a” or “an” limits any particular claim containing such an introductory claim citation to an invention containing only one such citation, even when the same claim includes the introductory phrases “one or more” or “at least one” and the wording, such as “a” or “an” (e.g., “a” or “an” should generally be interpreted as “at least one” or “one or more”); the same applies to the use of definite articles to introduce citations of the claim. Furthermore, even if a specific number of the introduced claim citation is explicitly cited, those skilled in the art will recognize that such citation should generally be interpreted as indicating at least the cited number (e.g., an empty citation of “two citations” without other modifiers generally refers to at least two citations, or two or more citations).

[0072] Furthermore, in cases where agreements such as "at least one of A, B, and C" are used, generally, such a construction is intended to convey the meaning of the agreement as would be understood by a person skilled in the art (e.g., "a system having at least one of A, B, and C" includes, but is not limited to, systems having A alone, having B alone, having C alone, having A and B, having A and C, having B and C, and / or having A, B, and C, etc.). In cases similar to agreements such as "at least one of A, B, or C," generally, such a construction is intended to convey the agreement as would be understood by a person skilled in the art (e.g., "a system having at least one of A, B, or C" includes, but is not limited to, systems having A alone, having B alone, having C alone, having A and B, having A and C, having B and C, and / or having A, B, and C, etc.). A person skilled in the art will further understand that any separate words and / or phrases presenting two or more alternative terms, whether in the specification, claims, or drawings, should be understood to contemplate the possibility of including one, any, or both of these terms. For example, the phrase “A or B” would be understood to include the possibility of “A” or “B” or “A and B”.

[0073] In addition, unless otherwise stated, the words “approximately,” “about,” “roughly,” “basically,” etc. are used to indicate plus or minus ten percent.

[0074] The foregoing description of illustrative embodiments has been presented for purposes of explanation and description. It is not intended to be exhaustive or limiting of the precise forms disclosed, and modifications and variations can be made in accordance with the foregoing teachings, or may be derived from practice of the disclosed embodiments. The scope of the invention is intended to be defined by the appended claims and their equivalents.

Claims

1. A method executable on a local processing device including a security subsystem and system memory, the method comprising: Retrieve the factory key from the system memory; Obtain the authentication key from the system memory; Transmit the factory key and the authentication key to the remote system; Receive from the remote system an encrypted factory key based at least in part on the factory key and an encrypted authentication key based at least in part on the authentication key; Obtain the application key from the system memory; A first authentication code is generated, at least in part, based on the authentication key and the application key; The application key is encrypted using the factory key to generate an encrypted application key; The encrypted authentication key, the encrypted application key, and the first authentication code are transmitted to the security subsystem; The encrypted factory key is transmitted to the security subsystem; At the security subsystem, the encrypted factory key is decrypted to obtain the decrypted factory key; At the security subsystem, the encrypted authentication key is decrypted to obtain the decrypted authentication key; At the security subsystem, the encrypted application key is decrypted using the decrypted factory key to obtain the decrypted application key; At the security subsystem, a second authentication code is generated at least in part based on the decrypted authentication key and the decrypted application key; Based on the determination that the first authentication code and the second authentication code meet the authentication standard, the authentication key accepted for decryption is considered trustworthy; At the security subsystem, the device identifier is obtained from the system memory; A device authentication key is generated in part based on the device identifier and the accepted authentication key; At the security subsystem, a security application key is generated, which includes the device authentication key and the accepted authentication key.

2. The method according to claim 1, wherein decrypting the factory key further comprises: The encrypted factory key is decrypted at least in part based on the first hardware key at the local processing device.

3. The method of claim 2, wherein the first hardware key corresponds to a second hardware key at the remote system and associated with the local processing device.

4. The method according to claim 1, wherein decrypting the encrypted authentication key further comprises: The encrypted authentication key is decrypted at least in part based on a first hardware key at the local processing device.

5. The method of claim 4, wherein the first hardware key corresponds to a second hardware key at the remote system and associated with the local processing device.

6. The method according to claim 1, further comprising: At the security subsystem, the device identifier key is obtained; as well as At the security subsystem, the security application key is encrypted at least in part based on the device identifier key to obtain an encrypted security application key.

7. The method according to claim 6, further comprising: The encrypted security application key is transferred from the security subsystem to the system memory of the local processing device.

8. The method according to claim 1, further comprising: At the security subsystem, a random seed is generated. Generating the security application key further includes generating the security application key comprising the accepted application key, the device authentication key, and the random seed.

9. The method according to claim 1, further comprising: At the security subsystem, obtain the security application key; At the security subsystem, the application key is obtained at least in part based on the security application key; At the security subsystem, the first authentication code is obtained at least in part based on the security application key; At the security subsystem, the device identifier is obtained; At the security subsystem, a second authentication code is generated based on the application key and the device identifier; as well as Based on the determination that the first authentication code and the second authentication code meet the authentication criteria, the application key is accepted.

10. The method according to claim 9, wherein obtaining the security application key further comprises: At the security subsystem, the encrypted security application key is obtained from the system memory, and at the security subsystem, the encrypted security application key is decrypted to obtain the security application key.

11. A local processing device including a security system and a system memory, configured to perform the method according to claim 1.

Citation Information

Patent Citations

  • Method for protecting sensor data from manipulation and sensor to that end

    US20120303973A1

  • Data protection at factory reset

    US20170337390A1

  • Wearable device communication support apparatus and method

    WO2019124667A1