Secure decryption device and method by virtualizing and transforming physical encryption keys

Abstract

To provide a technical solution for secure decryption by virtualization and translation of physical encryption keys.SOLUTION: The disclosure includes a system of secure decryption by virtualization and translation of physical encryption keys, the system having a key translation memory corresponding to at least one virtual key address, a physical key memory operable to store at least one physical encryption key at a physical memory address thereof, and a key security engine to generate at least one key address translation index, the key security engine obtaining, from the key translation memory, a physical mapping address based on the key address translation index and the virtual key address, and acquiring, from the physical key memory, the physical encryption key stored at the physical memory address.SELECTED DRAWING: Figure 1

Description

[Technical Field]

[0001] The present invention relates generally to cryptographic devices, and more particularly to secure decryption through virtualization and transformation of physical cryptographic keys. [Background technology]

[0002] Electronic and digital networks are becoming increasingly commonplace in many devices. These device-centric networks execute complex instructions that control increasingly complex and sensitive content. This growing complexity results in increased vulnerability and risk to the network from malicious external systems. Communications within and with these networks are therefore subject to increasing security threats that can compromise these systems, obtain secure information on these networks, and potentially seize unauthorized control of the devices that own and control these networks. Even the security protocols themselves are at risk of corruption from malicious external interference. Summary of the Invention [Problem to be solved by the invention]

[0003] Therefore, the objective of the present disclosure is to provide a technical solution for secure decryption through virtualization and transformation of physical encryption keys. [Means for solving the problem]

[0004] The present disclosure aims to provide secure network communications that include, at a minimum, multiple levels of protection for encryption keys that provide access to confidential communications across a network. The protections provided by the present disclosure include, but are not limited to, providing a physical encryption key on a secure memory device with restrictions on direct addressing, creating a virtual address for the physical encryption key to access the secure memory device from any device outside the secure memory device, and restricting access to the virtual encryption key on a partition basis. The partitions, which determine the secure access address blocks that specific components and devices on the network can access, are based on the identity of specific virtual machines on or communicating with the network. The network may include, for example, but is not limited to, embedded systems operating on vehicles, automobiles, locomotives, aircraft, ships, or spacecraft. Thus, the present disclosure provides multiple layers of security, including restrictions on access to the physical key memory and the keys stored therein, as well as access to the addresses to those physical keys. Restricting access to both the physical keys and the physical key addresses obfuscates the location of the physical encryption keys and limits access to those encryption keys, thereby providing multiple layers of protection and reducing the number of potential points of intrusion into the network. Thus, a technical solution is provided for secure decryption through virtualization and translation of physical encryption keys. An embodiment of the present disclosure includes a method for secure decryption through virtualization and translation of a physical encryption key, generating, by a key security engine, at least one key address translation index, obtaining from a key address translation memory at least one physical mapping address based on the key address translation index and the at least one virtual key address, and obtaining from a physical key memory at least one physical encryption key stored at the physical memory address. An embodiment of the present disclosure includes a method for further decrypting a frame corresponding to a partition register using a physical encryption key. Embodiments of the present disclosure include a method in which a partition register contains a virtual key address. An embodiment of the present disclosure includes a method of further obtaining at least one key index address map from the secure register, where the key index address map corresponds to a partition register. Embodiments of the present disclosure include a method for obtaining a key index address map by obtaining a starting address associated with a key translation memory and obtaining a partition key count corresponding to a partition register. Embodiments of the present disclosure include a method for generating a key address translation index by generating an offset based on a starting address, and generating a virtual address block based on the starting address and a partition key count. Embodiments of the present disclosure include a method in which the key translation memory contains virtual key addresses and contains a plurality of consecutive virtual key addresses that are associated only with partition registers. Embodiments of the present disclosure include a method in which the physical mapping address includes a pointer to a physical memory address in the physical key memory. An embodiment of the present disclosure includes a system for secure decryption through virtualization and translation of physical encryption keys, the system having a physical key memory operable to store at least one physical mapping address corresponding to at least one virtual key address and at least one physical encryption key for the physical memory address; and a key security engine operable to generate at least one key address translation index, retrieve from the key translation memory the physical mapping address based on the key address translation index and the virtual key address, and retrieve from the physical key memory the physical encryption key stored at the physical memory address. An embodiment of the present disclosure includes a system having a secure register operable to store at least one key index address map. Embodiments of the present disclosure include a system that allows a key security engine to obtain a key index address map from a secure register. An embodiment of the present disclosure includes a system in which a key security engine can obtain a starting address associated with a key translation memory from a secure register and a partition key count corresponding to a partition register from the secure register. Embodiments of the present disclosure include a system in which a key security engine can generate an offset based on a starting address and generate a virtual address block based on the starting address and a partition key count. Embodiments of the present disclosure include a system in which a key index address map corresponds to a partition register. Embodiments of the present disclosure include a system in which a partition register contains a virtual key address. Embodiments of the present disclosure include a system in which a key security engine can decrypt frames corresponding to partition registers along with a physical encryption key. Embodiments of the present disclosure include a system in which a physical mapping address includes a pointer to a physical memory address in a physical key memory. Embodiments of the present disclosure include a system in which a key translation memory contains virtual key addresses and contains a plurality of consecutive virtual key addresses associated only with partition registers. An embodiment of the present disclosure includes a non-transitory computer-readable medium storing computer-readable instructions that cause a processing circuit to: (1) retrieve at least one key index address map associated with a partition register from a secure register; (2) generate at least one key address translation index from a key security engine; (3) retrieve at least one physical mapping address from a key translation memory based on the key address translation index and the at least one virtual key address; and (4) retrieve at least one physical virtualization key stored at a physical memory address from a physical key memory. Decrypt a frame associated with the partition register with the physical encryption key. Embodiments of the present disclosure include a non-transitory computer-readable medium storing computer-readable instructions, wherein a processing circuit retrieves from a secure register a starting address associated with a key translation memory, retrieves from the secure register a partition key count corresponding to a partition register, generates an offset based on the starting address, and generates a virtual address block based on the starting address and the partition key count. In the following, the present disclosure will be further explained with reference to the embodiments shown in the accompanying figures. [Brief explanation of the drawings]

[0005] [Figure 1] FIG. 1 is a block diagram of an embodiment of a decoding system according to the present disclosure. [Figure 2] FIG. 2 is a block diagram of a partition register memory in a decoding system according to the present disclosure. [Figure 3] FIG. 2 is a block diagram of a secure register memory in a decryption system according to the present disclosure. [Figure 4] FIG. 2 is a block diagram of a key security engine in a decryption system according to the present disclosure. [Figure 5] FIG. 2 is a block diagram of a physical key address mapping structure in the decryption system according to the present disclosure. [Figure 6] FIG. 1 is a flow diagram of a method for secure decryption by virtualization and transformation of a physical encryption key according to the present disclosure. DETAILED DESCRIPTION OF THE INVENTION

[0006] The present implementation will now be described in detail with reference to the drawings, which are provided as illustrative examples of implementations, to enable those skilled in the art to implement implementations and alternatives that will be apparent to those skilled in the art. In particular, the following figures and examples are not intended to limit the scope of the present embodiment to a single embodiment, but other embodiments are possible by replacing some or all of the elements described or illustrated. Furthermore, if certain elements of the present implementation can be implemented partially or completely using known components, only the portions of such known components necessary to understand the implementation will be described, and detailed descriptions of other portions of such known components will be omitted so as not to obscure the implementation. An implementation described as being implemented in software should not be limited thereto and, unless otherwise specified herein, can include implementations implemented in hardware, or combinations of software and hardware, as will be apparent to those skilled in the art, and vice versa. Herein, implementations depicting a singular component should not be considered limiting; rather, the present disclosure is intended to encompass other implementations including multiple identical components, and vice versa, unless otherwise specified herein. Furthermore, the applicant does not intend any term in the specification or claims to be ascribed an ungeneric or special meaning unless expressly stated so. Furthermore, the present implementations encompass present and future known equivalents to known components referred to herein by way of example.

[0007] Embodiments of the present disclosure may include multiple secure memory hardware regions to provide a multi-tiered encryption system deployable on at least embedded communication systems for various machines. As described above, embodiments of the present disclosure may provide secure communications for, but are not limited to, automotive system control and monitoring networks. The multiple secure memory hardware regions may be integrated with one or more communication protocols to provide security protocol encryption. The security protocols may include, but are not limited to, Control Area Network Security (CANsec) or any variants or derivatives thereof. Network communication security hardware according to embodiments of the present disclosure may include restricted address ranges of memory addresses for various application devices on the network, virtual addressing of memory addresses accessible by the restricted address ranges, and storage of physical encryption keys in secure memory, securely addressable by the virtual memory addresses. Thus, embodiments of the present disclosure provide a multi-tiered security hardware structure for providing tamper-resistant network communications by enforcing multiple access restrictions on retrieval of encryption keys for encrypting and decrypting network communications.

[0008] 1 illustrates an example of a decryption system 100 according to an embodiment of the present disclosure. As illustrated by the example of FIG. 1, the decryption system 100 includes a system processor 102, a routing engine 110, an encryption engine 120, a frame manager 130, a protocol engine 140, a partition register memory 200, a secure register memory 300, and a key security engine 400. The decryption system 100 and one or more of its components may include one or more logic devices or electronic devices, including, but not limited to, integrated circuits, logic gates, flip-flops, gate arrays, programmable gate arrays, etc.

[0009] The system processor 102 may execute one or more instructions related to the decoding system 100. The system processor 102 may include an electronic processor, integrated circuit, etc., including one or more of digital logic circuitry, analog logic, digital sensors, analog sensors, communication buses, volatile memory, non-volatile memory, etc. The system processor 102 may include, 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. The system processor 102 may include memory storing or operable to store one or more instructions for operating components of the system processor 102 and operating components operatively coupled to the system processor 102. The one or more instructions may include at least one of firmware, software, hardware, an operating system, an embedded operating system, etc. The system processor 102 or the decoding system 100 may generally include at least one communication bus controller for communicating between the system processor 102 and other elements of the decoding system 100 .

[0010] The routing engine 110 can route communications between one or more of the encryption engine 120, the frame manager 130, the protocol engine 140, the partition register memory 200, the secure register memory 300, and the key security engine 400. The routing engine 110 can be operatively coupled to a communication bus, channel, or the like, including a transmit bus, channel, or the like. As an example, a communication bus can operatively couple the routing engine 110 to the protocol engine 140. The key security engine 400 and the encryption engine 120 can also be operatively coupled to the routing engine 110 by at least a communication bus. The communication bus can terminate at the routing engine 110 and can include one or more queues, registers, or buffer devices, for example, to control scheduling, ordering, and prioritization. As an example, the routing engine 110 can include a first queue device operatively coupled to a transmit channel of the communication bus and a second queue device operatively coupled to a receive channel of the communication bus. The queue device can include, for example, but is not limited to, a first-in, first-out (FIFO) queue.

[0011] The encryption engine 120 can encrypt and decrypt one or more objects transmitted to or through the encryption engine 120 by at least a communication bus. The encryption engine 120 can include one or more encryption devices operable to convert unencrypted communications into encrypted communications by a transmission channel and to convert encrypted communications by a reception channel into unencrypted communications. By way of example, the encryption engine 120 can encrypt and decrypt according to the AES encryption and decryption scheme. The encryption engine 120 can include one or more logic or electronic devices, including, but not limited to, integrated circuits, logic gates, flip-flops, gate arrays, programmable gate arrays, and the like. It should be understood that any electrical, electronic, or similar device or component associated with the encryption engine 120 can be associated with, integrated with, integratable with, replace, add to, supplement, or be similar to the key security engine 400, or any component thereof.

[0012] The frame manager 130 can, for example, control or limit communications received from the protocol engines 140 by the protocol engines 140. The frame manager 130 can, for example, filter communications received from the protocol engines 140 based on one or more acceptance criteria for the decryption system. As an example, any communication that does not meet at least one acceptance criterion can be filtered or blocked from continuing along the receive bus and reaching one or more of the encryption engine 120 and the routing engine 110. The acceptance criteria can include, for example, an origin stamp, a timestamp, a hash, or a security token. The frame manager 130 can further include a filter memory device that stores filtered or blocked communications. The filter memory device can include one or more registers, arrays, flip-flops, etc.

[0013] Protocol engine 140 can receive and transmit communications according to one or more particular protocols. Protocol engine 140 can include a network interface that operably couples decoding system 100 to a network capable of operating according to at least one protocol compatible with protocol engine 140. As one example, protocol engine 140 can be compatible with at least the CAN-XL protocol, the CANsec protocol, or any variant or derivation thereof. As another example, protocol engine 140 can be compatible with, for example, any vehicle network or embedded network.

[0014] The partition register memory 200 can store one or more blocks associated with one or more partitions of a storage system operatively coupled to the decryption system 100. The partition register memory 200 can include one or more identifiers, encryption keys, and transmission control instructions associated with one or more partitions. The partition register memory 200 can include multiple partition registers, each partition including blocks associated with a corresponding partition of multiple partitions. As an example, partitions can be numerically identified by numbers from 0 to N in increments of 1. Each partition register in the partition register memory 200 can include one or more virtual addresses corresponding to one or more encryption keys. Thus, the partition register memory 200 can reference one or more encryption keys corresponding to a particular partition. Each partition can also be associated with one or more specific virtual machines executable in communication with the partition register memory 200 and the decryption system 100. The virtual machines associated with each partition can be restricted to execute within that partition and can be further restricted to access only the encryption keys indicated by the virtual addresses within that partition. Thus, the partition register memory 200 can provide restricted access to one or more encryption keys for one or more virtual machines executable on a particular partition.

[0015] The secure register memory 300 may store one or more virtual address ranges for virtual keys associated with each partition. As an example, the secure register memory 300 may store one or more address ranges associated with one corresponding partition. Each partition may be associated with a specific set of one or more virtual key addresses corresponding to various physical cryptographic keys stored in the key security engine 400. The secure register memory 300 may include one or more hardware memory devices that store binary data, digital data, etc. The secure register memory 300 may include one or more electrical components, electronic components, programmable electronic components, reprogrammable electronic components, integrated circuits, semiconductor devices, flip-flops, arithmetic units, etc.

[0016] The key security engine 400 may include one or more memory devices to translate virtual addresses into physical key addresses. The key security engine 400 may, for example, control, limit, or block access from devices external to the system and provide direct addressing only to specific virtual machines authorized by their corresponding partition registers to access specific virtual address ranges of the key security engine 400. The key security engine 400 may also include a mapping structure between virtual addresses and physical addresses. The mapping structure may include pointers stored in specific memory array locations. The pointers may include the physical memory addresses of specific physical cryptographic keys. Each specific physical cryptographic key accessible by a virtual address can be obtained by a specific virtual machine to decrypt any component of a communication associated with or associated with that virtual machine. The communication may include frames sent by a virtual machine and received by the protocol engine 140. The key security engine 400 may include one or more hardware memory devices for storing binary data, digital data, or the like. The key security engine 400 may include one or more electrical components, electronic components, programmable electronic components, reprogrammable electronic components, integrated circuits, semiconductor devices, flip-flops, arithmetic units, and the like.

[0017] The decoding system 100 may include a communication interface operatively coupling one or more of its components. The communication interface may communicate one or more instructions, signals, conditions, states, etc. between one or more components of the decoding system 100 and components, devices, or blocks operatively coupled or couplable thereto. The communication interface may include one or more digital, analog, or similar communication channels, lines, traces, etc. As an example, the communication interface may include at least one serial or parallel communication line among multiple communication lines of the communication interface. The communication interface may include one or more wireless communication devices, systems, protocols, interfaces, etc. The communication interface may include one or more logic or electronic devices, including, but not limited to, integrated circuits, logic gates, flip-flops, gate arrays, programmable gate arrays, etc. The communication interface may include one or more electrical communication devices, including, but not limited to, antennas, transceivers, packetizers, and wired interface ports.

[0018] Figure 2 illustrates an example of a partition register memory 200 in the example decoding system of Figure 1. As illustrated by the example of Figure 2, the partition register memory 200 includes one or more partition registers 202 associated with a first partition, including one or more transmit registers (TX0) 210 associated with the first partition and one or more receive registers (RX0) 240 associated with the first partition. The partition register memory 200 may further include any number of one or more partition registers 204, 206, 208, where each of the additional partition registers may correspond in one or more structure and operation to the partition register 202, as described below. Each register may include one or more memory arrays, flip-flops, gate arrays, accumulators, etc., and may be operable to store one or more digital bits, nibbles, bytes, words, etc.

[0019] The transmit register (TX0) 210 can control one or more parameters associated with outgoing communications, for example, by a virtual machine or application associated with a particular partition. The transmit register (TX0) 210 can include a data length block 220, a priority block 222, a frame source pointer block 224, a label block 226, and a virtual key index block 230. Each block can include a separate register or a portion of a register. The portion of a register can include a particular address range of a register.

[0020] The data length block 220 may include, for example, a physical memory location that stores an indication of the overall length or size of a particular frame communicated by the virtual machine to the decoding system 100. The priority block 222 may include, for example, a physical memory location that stores an indication of the priority, ranking, or order of a particular frame communicated by the virtual machine to the decoding system 100. The label block 226 may include, for example, a physical memory location that stores an identifier or unique identifier of a particular frame communicated by the virtual machine to the decoding system 100.

[0021] Virtual key index block 230 may include a physical memory location that stores an indication of at least one virtual address corresponding to a physical cryptographic key associated with a partition for a partition register. Virtual key index block 230 may include a number of virtual key address locations associated with a partition, a particular order of the virtual keys, and a virtual key identifier, e.g., one corresponding to the order. Thus, the numbered order for each virtual key in virtual key index block 230 may be looked up to generate an offset within the partition for each virtual key address in virtual key index block 230. By indicating the number of virtual key locations, virtual key index block 230 may advantageously indicate correspondence to any number of physical cryptographic keys without requiring the storage space required to store virtual addresses and without directly and securely storing memory locations of the physical cryptographic keys.

[0022] The receive register (RX0) 240 may, for example, control one or more parameters related to receive communications by a virtual machine or application associated with a particular partition. The receive register (RX0) 240 may correspond in one or more structure and operation to the transmit register (TX0) 210. The receive register (RX0) 240 may indicate at least one virtual key index corresponding to the virtual key index block 230, where, for example, for a particular frame or virtual machine, separate keys can perform encryption and decryption operations, respectively. The receive register (RX0) 240 may access the virtual key index block 230, avoiding the need to store additional keys, where the same key can perform both encryption and decryption according to a protocol corresponding to the partition register.

[0023] Figure 3 illustrates an example secure register memory in addition to the example system of Figure 1. As illustrated by the example of Figure 3, the example secure register memory 300 includes at least one key index starting address register 310 and one or more partition key count registers 320, 322, 324, 326 associated with one or more corresponding partitions. Each of the partition key count registers 320, 322, 324, 326 can correspond to one another in one or more of structure and operation, as described below.

[0024] The key index start address register 310 may include a physical memory location that stores a physical address that indicates the start of a contiguous block of one or more virtual addresses that correspond to a physical encryption key. The addresses may be stored contiguously to minimize the address space required to store them. This is particularly advantageous in embedded systems, where low power consumption and low volume devices are advantageous for compactness and field deployment. Thus, the key index start address register 310 may include a complete physical address, eliminating the need for the partition key count registers 320, 322, and 324 to store the corresponding complete physical address and reserve the bits necessary to do so.

[0025] The partition key count registers 320, 322, 324, 326 may include physical memory locations that store counts of one or more virtual keys associated with one or more partition registers. As an example, the partition key count registers 320, 322, 324 may store key counts of 2, 5, and 10, respectively, indicating that two keys are associated with the first partition (Partition 0), five keys are associated with the second partition (Partition 1), and ten keys are associated with the third partition (Partition 1). Thus, the key security engine 400 may generate an address for each virtual key according to its order within the partition range and the starting address of the key start address register. Specifically, the key security engine 400 may generate an offset for a particular virtual key based on the count across all of the partition key count registers 320, 322, 324, 326, and based on the starting address and the offset from the starting address to the address of the particular virtual key.

[0026] The secure register memory 300 may include one or more hardware memory devices that store binary data, digital data, etc. The secure register memory 300 may include one or more electrical components, electronic components, programmable electronic components, reprogrammable electronic components, integrated circuits, semiconductor devices, flip-flops, arithmetic units, etc. The secure register memory 300 may include at least one of a non-volatile memory device, a solid-state memory device, a flash memory device, and a NAND memory device. The secure register memory 300 may include one or more addressable memory regions disposed on one or more physical memory arrays. The physical memory array may include, for example, a NAND gate array disposed on at least one of a particular semiconductor device, a semiconductor integrated circuit device, and a printed circuit board device.

[0027] Figure 4 illustrates an exemplary key security engine in addition to the exemplary system of Figure 1. As illustrated by the example of Figure 4, the example key security engine 400 includes a key translation memory 410 and a physical key memory 420. It should be understood that the key security engine 400 may include a system processor that corresponds to one or more structures and operations with the system processor 102, thereby performing one or more operations related to one or more of the key translation memory 410 and the physical key memory 420. Thus, the key security engine 400 may advantageously perform secure cryptographic key operations under the control of at least one of the system processors 102 and the system processor 102 of the key security engine 400.

[0028] The key translation memory 410 can link at least one virtual key address to at least one corresponding physical key address. The key translation memory 410 can store data related to the key security engine 400. The key translation memory 410 can include one or more hardware memory devices that store binary data, digital data, etc. The key translation memory 410 can include one or more electrical components, electronic components, programmable electronic components, reprogrammable electronic components, integrated circuits, semiconductor devices, flip-flops, arithmetic units, etc. The key translation memory 410 can include at least one of a non-volatile memory device, a semiconductor memory device, a flash memory device, and a NAND memory device. The key translation memory 410 can include one or more addressable memory regions disposed on one or more physical memory arrays. The physical memory array can include, for example, a NAND gate array disposed on at least one of a particular semiconductor device, a semiconductor integrated circuit device, and a printed circuit board device. The key translation memory 410 may include one or more key translation indexes 430, 432, 434, 436 and one or more physical key addresses 440, 442, 444, 446.

[0029] The key translation indexes 430, 432, 434, 436 may include one or more physical memory locations that store corresponding indexes to virtual key addresses in the secure register memory 300. Thus, the secure register memory 300 may point to different ranges of key translation indexes 430, 432, 434, 436 that correspond to different partition registers. The key translation indexes may correspond to physical memory addresses in the key translation memory.

[0030] Physical key addresses 440, 442, 444, 446 may include one or more physical memory locations that store a physical key address corresponding to a respective one of key translation indexes 430, 432, 434, 436. A physical key address may store a pointer to a specific physical encryption key stored in the physical key memory memory location at that particular address. Thus, key translation indexes 430, 432, 434, 436 may advantageously address any physical encryption key, for example, within the physical key memory, regardless of the physical encryption key's location, address, or order. Key translation indexes 430, 432, 434, 436 may also advantageously handle any key, multiple keys, or any key needed for a particular application or security requirement. As an example, multiple physical key addresses 440, 442, 444, 446 may store pointers to the same physical encryption key. As another example, the addresses of one or more physical cryptographic keys may not exist in all physical key addresses 440, 442, 444, 446. Thus, the key translation indexes 430, 432, 434, 436 may have, but are not limited to, a one-to-one mapping correspondence with the physical key addresses 440, 442, 444, 446.

[0031] The physical key memory cells 450, 452, 454, 456 may include one or more physical memory locations that store an encryption key corresponding to each of the physical key addresses 440, 442, 444, 446. Each encryption key may be or include, for example, a symmetric or asymmetric key, and may be stored in a corresponding cell of the physical key memory 420. By way of example, but not limitation, the encryption key may correspond to an Advanced Encryption Standard (AES) encryption protocol or the like. The key security engine may retrieve the encryption key stored in the physical key memory cells 450, 452, 454, 456 and perform one or more encryption and decryption operations related to frames or communications associated with the decryption system 100 or any device or system operatively coupled thereto.

[0032] The physical key memory 420 can store data related to the key security engine 400 and can include one or more physical key memory cells 450, 452, 454, 456. The physical key memory 420 can include one or more hardware memory devices that store binary data, digital data, etc. The physical key memory 420 can include one or more electrical components, electronic components, programmable electronic components, reprogrammable electronic components, integrated circuits, semiconductor devices, flip-flops, arithmetic units, etc. The physical key memory 420 can include at least one of a non-volatile memory device, a semiconductor memory device, a flash memory device, and a NAND memory device. The physical key memory 420 can include one or more addressable memory regions disposed on one or more physical memory arrays. The physical memory arrays can include, for example, NAND gate arrays disposed on at least one of a particular semiconductor device, a semiconductor integrated circuit device, and a printed circuit board device.

[0033] 5 shows an example of a physical key address mapping structure 500 according to this embodiment. As shown in the example of FIG. 5, the example physical key address mapping structure 500 includes a key translation memory 410, a physical key memory 420, and a mapping structure 530 therebetween. The key translation memory 410 may include one or more key translation address blocks 510, 512, 514, 516, 518, each of which may or may not be associated with a corresponding one of the partition key count registers 320, 322, 324, 326, and may include one or more physical key address blocks 520, 522, 524, 526, 528, each of which may or may not be associated with a corresponding one of the partition key count registers 320, 322, 324, 326.

[0034] The key translation address blocks 510, 512, 514, 516, and 518 may correspond in structure and operation to the key translation indexes 430, 432, 434, and 436. In some implementations, the key translation address blocks 510, 512, 514, 516, and 518 include one or more of the key translation indexes 430, 432, 434, and 436. The key translation address block 510 may be before the start address indicated by the key index starting address register 310 and therefore may be excluded from the address range of virtual keys available to the partition key count registers 320, 322, 324, and 326. The key translation address blocks 512, 514, 516, and 518 may be associated with the partition key count registers 320, 322, 324, 326, and 328, respectively, according to the corresponding key count numbers, as described above. As an example, the key counts of the virtual key indexes in the partition key count registers 320, 322, 324, 326 may be 3, 2, 2, 3, respectively. Implementations according to the present invention can advantageously support any number of virtual key indexes.

[0035] The physical key address blocks 520, 522, 524, 526, 528 may correspond in structure and operation to the physical key addresses 440, 442, 444, 446. In some implementations, the physical key address blocks 520, 522, 524, 526, 528 include one or more of the physical key addresses 440, 442, 444, 446. The physical key address blocks 520, 522, 524, 526, 528 may identify a mapping structure between the mapping structure 530 to one or more physical mapping address blocks 550 of the physical key memory. Each of the key translation address blocks 510, 512, 514, 516, 518 and the physical key address blocks 520, 522, 524, 526, 528 may include a respective memory array having corresponding addresses to provide a direct mapping correlation between the corresponding memory locations. As an example, key translation address block 512 may have a memory address of "0x1000" in a first memory array of key translation memory 410, and physical key address block 522 may have a corresponding memory address of "0x1000" in a second memory array of key translation memory 410. The present embodiment is not limited to multiple memory arrays sharing addresses, as described above.

[0036] The mapping structure 530 may include one or more traversable links to a physical mapping address block 540 based on the physical key address blocks 520, 522, 524, 526, and 528. Each physical key address block 520, 522, 524, 526, and 528 may include operable addresses structured as pointers 532, 534, 536, and 538 based on the respective partition. Each pointer 532, 534, 536, and 538 may be associated with a first, second, third, and fourth partition by the partition key count registers 320, 322, 324, and 326. Any pointer may point to any of the physical key address blocks 520, 522, 524, 526, and 528, and any of the physical key address blocks 520, 522, 524, 526, and 528 may have any number of pointers associated with it, including, but not limited to, a zero pointer. This flexibility in indicating assignments advantageously provides for the use of any encryption key stored in the physical key storage block 550, and is available for access by the key security engine 400, for example, for any virtual machine or application associated with any partition.

[0037] The physical mapped address block 540 may correspond in one or more structure and operation to the physical key addresses 440, 442, 444, 446. In some implementations, the physical mapped address block 540 includes one or more of the physical key addresses 440, 442, 444, 446. The physical mapped address block 540 may correspond to physical addresses of a memory array of the physical key memory 420. The physical key storage block 550 may correspond in one or more structure and operation to the physical key memory cells 450, 452, 454, 456. In some implementations, the physical key storage block 550 includes one or more of the physical key memory cells 450, 452, 454, 456. The physical key storage block 550 may correspond to physical addresses of a memory array of the physical key memory 420. Each of the physical mapped address block 540 and the physical key storage block 550 may include a respective memory array having corresponding addresses to provide a direct mapping correlation between corresponding memory locations. This embodiment is not limited to multiple memory arrays sharing addresses as described above.

[0038] 6 illustrates an example of a method for secure decryption by virtualization and transformation of a physical encryption key according to an embodiment. In some implementations, the decryption system 100 performs the secure decryption method 600 according to an embodiment. In some implementations, the secure decryption method 600 begins at step 610.

[0039] In step 610, the decryption system obtains one or more virtual key addresses corresponding to one or more partition registers. The decryption system can obtain the virtual key addresses by identifying the partitions associated with the partition registers. The secure decryption method 600 then proceeds to step 620.

[0040] At step 620, the decryption system retrieves at least one key index address map from at least one secure register. The key index map may include one or more virtual addresses corresponding to one or more encryption keys in the encryption key engine 400. In some implementations, step 620 includes at least one of step 622 and step 624. At step 622, the decryption system retrieves at least one starting address corresponding to the key translation memory 410. At step 624, the decryption system retrieves at least one partition key count corresponding to at least one partition register. The decryption system may retrieve the partition key count in response to a decryption request originating, for example, from a virtual machine associated with a particular partition or partition register. Secure decryption method 600 then proceeds to step 630.

[0041] In step 630, the decryption system generates at least one key address translation index. The key address translation index may indicate a specific virtual address corresponding to a specific encryption key included in the decryption request. The decryption request may originate from the key security engine 400 or the encryption engine 120 in response to identifying a frame, communication, etc., related to a specific partition. The virtual machine originating the frame may be associated with a partition, and receipt of a frame identifying a specific partition or virtual machine may trigger the decryption request. In some implementations, step 630 includes at least one of steps 632 and 634. In step 632, the decryption system generates at least one offset from at least one key index register starting address. The offset may be generated by the key security engine 400 by adding the offsets of all partitions preceding the partition associated with the request to generate a partition offset, and adding the index number of the requested virtual key from the virtual key index of the partition register to the partition offset to generate a virtual key address. In step 634, the decryption system generates at least one virtual address block based on the starting address and the partition key count. The virtual address block may include the entire range of virtual addresses corresponding to the virtual key index of the partition. As an example, the virtual address block may start at a virtual key address and end at an offset into the virtual key address corresponding to the number of keys associated with the partition. Secure decryption method 600 then proceeds to step 640.

[0042] In step 640, the exemplary decryption system obtains at least one physical mapping address from the key address translation index and the virtual key address. The decryption system may obtain the physical mapping address by obtaining an address at a memory location in the key translation memory, as described above. In some implementations, step 640 includes step 642. In step 642, the exemplary system obtains a physical mapping address that points to a physical mapping address in the physical key memory. The physical mapping address may correspond to a pointer among pointers 532, 534, 536, and 538. Next, secure decryption method 600 proceeds to step 650.

[0043] In step 650, the exemplary system retrieves at least one physical encryption key stored at the physical mapping address. Key security engine 400 may retrieve one physical encryption key from one of physical key storage blocks 550 corresponding to the retrieved physical mapping address. In some implementations, step 650 includes step 652. In step 652, the exemplary system retrieves the physical encryption key corresponding to the physical mapping address. The physical encryption key may include an AES encryption key, a decryption key according to the AES encryption protocol, etc. Next, secure decryption method 600 proceeds to step 660.

[0044] At step 660, the illustrative system decrypts the frame corresponding to the partition or partition register associated with the original request with the obtained physical encryption key. The encryption engine 120 can decrypt any portion of any communication associated with a particular partition and is not limited to decrypting frames originating from a virtual machine associated with a particular partition. The encryption engine 120 can be integrated within the key security engine 400 to advantageously provide encryption and decryption operations within the secure boundaries of the key security engine 400. In some implementations, the secure decryption method 600 ends at step 660.

[0045] The subject matter described herein may depict different components contained within or connected to different other components. It should be understood that the depicted architectures are exemplary, and that in fact many other architectures that achieve the same functionality may be implemented. In a conceptual sense, any arrangement of parts to achieve the same functionality is effectively “associated” such that the desired functionality is achieved. Thus, any two components combined herein to achieve a particular function can be considered to be “associated” with each other such that the desired functionality is achieved, regardless of the architecture or intermediate components. Similarly, any two components so associated can also be considered to be “operably connected” or “operably coupled” to each other to achieve the desired functionality, and any two components that can be so associated can also be considered to be “operably coupleable” to each other to achieve the desired functionality. Specific examples of operably coupleable include, but are not limited to, physically coupleable and / or physically interacting components, wirelessly interactable and / or wirelessly interacting components, and / or logically interactable and / or logically interacting components.

[0046] With respect to the use of plural and / or singular terms herein, those skilled in the art may translate from plural to singular and / or from singular to plural as appropriate to the context and / or application. Various singular / plural permutations may be expressly set forth herein for clarity.

[0047] Those skilled in the art will understand that, in general, clauses used in this specification, and in particular the appended claims (e.g., the body of the appended claims), are generally intended as "open" clauses (e.g., a "comprising" clause should be interpreted as "including but not limited to," a "having" clause should be interpreted as "having at least," a "including" clause should be interpreted as "including but not limited to," etc.).

[0048] Although the figures and descriptions may indicate a particular order of steps in the methods, the order of such steps may differ from that shown and described unless otherwise specified above. Also, two or more steps may be performed concurrently or with partial concurrence unless otherwise specified above. Such variations may depend, for example, on the software and hardware systems selected and the designer's choice. All such variations are within the scope of this disclosure. Similarly, software implementations of the described methods may be accomplished through standard programming techniques with rule-based logic and other logic to accomplish the various connecting, processing, comparing, and determining steps.

[0049] It will be further understood by those skilled in the art that where a specific number of introduced claim recitations is intended, such intent will be explicitly recited in the claim, and that in the absence of such recitation, no such intent exists. For example, to aid in understanding, the following appended claims may include the use of the introductory phrases "at least one" and "one or more" to introduce the claim recitation. Furthermore, even if a specific number of introduced claim recitations is explicitly recited, those skilled in the art will recognize that such recitation should typically be interpreted to mean at least the recited number (e.g., a bare recitation of "two recitations" without other modifiers typically means at least two recitations, or two or more recitations).

[0050] Furthermore, when a convention similar to "at least one of A, B, and C, etc." is used, it is generally intended that one of ordinary skill in the art would understand the convention (e.g., "a system having at least one of A, B, and C" includes, but is not limited to, systems having A alone, B alone, C alone, A and B alone, A and B alone, A and C alone, A and C alone, B and C alone, and / or A, B, and C alone, etc.). When a convention similar to "at least one of A, B, or C, etc." is used, it is generally intended that one of ordinary skill in the art would understand the convention (e.g., "a system having at least one of A, B, or C" includes, but is not limited to, systems having A alone, B alone, C alone, A and B together, A and C together, B and C together, and / or A, B, and C together, etc.). Moreover, it will be further understood by those skilled in the art that virtually any disjunctive word and / or phrase presenting two or more alternative terms, either in the description, claims, or drawings, should be understood to contemplate the possibility of including one of the terms, either of the terms, or both terms. For example, the phrase "A or B" is understood to include the possibilities of "A" or "B" or "A and B."

[0051] Further, unless otherwise specified, use of terms such as "approximately," "about," "approximately," and "substantially" means plus or minus ten percent.

[0052] The foregoing description of exemplary embodiments has been presented for purposes of illustration and description. It is not intended to be exhaustive or limiting to the precise form disclosed, and modifications and variations are possible in light of the above teachings or may be acquired from practice of the disclosed implementations. It is intended that the scope of the present invention be defined by the appended claims and their equivalents. [Explanation of symbols]

[0053] 100 Decoding System 102 System Processor 110 Routing Engine 120 encryption engine 130 Frame Manager 140 Protocol Engine 200 Partitioned Register Memory 202, 204, 206, 208 Partition Registers 210 Transmit register (TX0) 220 Data Length 222 Priority 226 Label 230 Virtual Key Index 240 Receive register (RX0) 300 Secure Register Memory 310 Key Index Start Address 320, 322, 324, 326 Partition Key Count Registers 400 Key Security Engine 410 key conversion memory 420 Physical Key Memory 430, 432, 434, 436 Conversion Index 440, 442, 444, 446 Physical Key Address 450, 452, 454, 456 encryption keys 500 Physical Key Address Mapping Structure 510, 512, 514, 516, 518 Key Translation Address Blocks 520, 522, 524, 526, 528 Physical Key Address Blocks 530 Mapping Structure 532, 534, 536, 538 pointers

Claims

1. generating, by a key security engine, at least one key address translation index; obtaining at least one physical mapping address based on the key address translation index and at least one virtual key address from a key translation memory; and obtaining from the physical key memory at least one physical cryptographic key stored at a physical memory address; using the physical encryption key to decrypt a frame corresponding to a partition register; The method for secure decryption by virtualization and translation of physical cryptographic keys, wherein the key translation memory includes the virtual key addresses and includes a plurality of consecutive virtual key addresses associated only with the partition registers.

2. 2. The method of claim 1, wherein the partition register contains the virtual key address.

3. retrieving at least one key index address map from a secure register; the key index address map corresponds to the partition register; The step of obtaining the key index address map further comprises the steps of obtaining a starting address associated with a key translation memory and obtaining a partition key count corresponding to the partition register; generating a key address translation index further comprises generating an offset based on the starting address; and generating a virtual address block based on the starting address and the partition key count. The decoding method of claim 1 .

4. 2. The method of claim 1, wherein the physical mapping address comprises a pointer to the physical memory address in the physical key memory.

5. a key translation memory operable to store at least one physical mapping address corresponding to at least one virtual key address; a physical key memory operable to store at least one physical cryptographic key at a physical memory address; a key address translation index operable by the key security engine; Obtaining a physical mapping address from a key translation memory based on the key address translation index and a virtual key address, and obtaining a physical encryption key stored at the physical memory address from the physical key memory, generating at least one key address translation index; 10. A system for secure decryption through virtualization and translation of physical cryptographic keys, wherein the key translation memory includes the virtual key addresses and includes a plurality of consecutive virtual key addresses associated only with partition registers.

6. a secure register operable to store at least one key index address map; 6. The decryption system of claim 5, wherein the key security engine is further operable to obtain the key index address map from the secure register.

7. The key security engine further obtains from the secure register a starting address associated with the key transformation memory; 7. The decryption system of claim 6, operable to obtain a partition key count corresponding to a partition register from the secure register.

8. The key security engine further generates an offset based on the starting address; operative to generate a virtual address block based on the starting address and a partition key number. The decoding system of claim 7.

9. The decoding system of claim 6 , wherein the key index address map corresponds to a partition register.

10. 10. The decryption system of claim 9, wherein the partition register contains the virtual key address.

11. 6. The decryption system of claim 5, wherein the key security engine is further operable to decrypt frames corresponding to partition registers using the physical encryption key.

12. 6. The decryption system of claim 5, wherein the physical mapping address comprises a pointer to the physical memory address in the physical key memory.

13. A non-transitory computer-readable medium storing computer-readable instructions, the computer-readable instructions enabling a processing circuit to: generating, by a key security engine, at least one key address translation index; obtaining at least one physical mapping address based on the key address translation index and at least one virtual key address from a key translation memory; obtaining, from a physical key memory, at least one physical cryptographic key stored at a physical memory address; decrypting the frame corresponding to the partition register using the physical encryption key; The key translation memory includes the virtual key addresses and includes a plurality of consecutive virtual key addresses associated only with the partition registers.

14. the processing circuitry further obtaining a starting address associated with the key translation memory from a secure register; obtaining a partition key count corresponding to the partition register from the secure register; generating an offset based on the starting address; and generating a virtual address block based on the starting address and the partition key number.

Images