WO2025170749A1 - Secure data processor architecture - Google Patents

Abstract

A computer is disclosed. The computer includes a central processing unit (CPU) configured to execute an operating system; and a security processing engine (SPE) coupled to the CPU, the SPE being on a same integrated semiconductor chip as the CPU and having dedicated hardware and dedicated software isolated from the CPU, wherein the SPE is programmed to boot and perform an integrity check for the CPU before the CPU executes an operating system.

Description

SECURE DATA PROCESSOR ARCHITECTURE

CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application is a PCT application of and claims the benefit and priority under 35 U.S.C. 119(e) of U.S. Provisional Application No. 63/549,942, filed on February 5, 2024, which is incorporated herein by reference in its entirety for all purposes.

BACKGROUND

[0002] In today’s digital economy, the security of payment transactions is important to protect against fraud and unauthorized transactions. In payment transactions, communication (e.g., nearfield communication (NFC)) and data (e.g., primary account number (PAN)) are encrypted. However, software-based encryption processes may expose plaintext assets before the encryption is completed because the boot process may be compromised if the boot loader responsible for initializing the hardware and loading the operating system is compromised (e.g., affected by malicious codes). Similarly, cryptographic operations performed by software may also be vulnerable.

[0003] Embodiments of the disclosure address these and other problems individually and collectively.

SUMMARY

[0004] One embodiment is related to a device comprising: a central processing unit (CPU) configured to execute an operating system; and a security processing engine (SPE) coupled to the CPU, the SPE being on a same integrated semiconductor chip as the CPU and having dedicated hardware and dedicated software isolated from the CPU; where the SPE is programmed to boot and perform an integrity check for the CPU before the CPU executes an operating system.

[0005] Another embodiment is related to a method comprising: Powering on a device comprising a security processing engine (SPE) and central processing unit (CPU) on a same integrated semiconductor chip, wherein the SPE has dedicated hardware and dedicated software isolated from the CPU; performing, by the SPE, an integrity check that boot information of the CPU has not been altered or tampered with; and after the integrity check is performed, executing, by the CPU, an operating system.

[0006] Another embodiment is related to a system comprising: a user device comprising: a central processing unit (CPU) configured to execute an operating system; a security processing engine (SPE) coupled to the CPU, the SPE being on an integrated semiconductor chip as the CPU and having dedicated hardware and dedicated software isolated from the CPU; and a portable device communicating with the user device via a near-field communication (NFC); where the SPE is programmed to boot and perform an integrity check for the CPU before the CPU executes the operating system.

[0007] Further details regarding embodiments of the disclosure can be found in the Detailed Description and the Figures.

BRIEF DESCRIPTION OF THE DRAWINGS

[0008] FIG. 1 is a block diagram illustrating an example communication system, according to certain embodiments.

[0009] FIG. 2 is a block diagram illustrating an example user device, according to certain embodiments.

[0010] FIG. 3 is a block diagram illustrating an example portable device, according to certain embodiments

[0011] FIG. 4 is a block diagram illustrating an architecture embedding a security processing engine (SPE) inside a platform controller hub (PCH), according to certain embodiments.

[0012] FIG. 5 is a block diagram illustrating an architecture embedding a SPE inside a processor, according to certain embodiments.

[0013] FIG. 6 is a block diagram illustrating an architecture embedding a SPE inside a system-on-chip (SoC), according to certain embodiments. [0014] FIG. 7 illustrates a hardware portion of a SPE, according to certain embodiments.

[0015] FIG. 8 illustrates a software portion of a SPE, according to certain embodiments.

[0016] FIG. 9 illustrates a booting process for SPE and host central processing unit (CPU), according to certain embodiments.

[0017] FIG. 10 illustrates an example flowchart depicting a generalized process performed by SPE and host CPU, according to certain embodiments.

[0018] FIG. 11 illustrates an example flowchart depicting a security operation performed by SPE, according to certain embodiments.

DETAILED DESCRIPTION

[0019] Prior to discussing embodiments of the disclosure, some terms can be described in further detail.

[0020] A “user device” may be a device that is operated by a user. Examples of user devices may include a mobile phone, a smart phone, a card, a personal digital assistant (PDA), a laptop computer, a desktop computer, a server computer, a vehicle such as an automobile, a thin-client device, a tablet PC, etc. Additionally, user devices may be any type of wearable technology device, such as a watch, earpiece, glasses, etc. The user device may include one or more processors capable of processing user input. The user device may also include one or more input sensors for receiving user input. As is known in the art, there are a variety of input sensors capable of detecting user input, such as accelerometers, cameras, microphones, etc. The user input obtained by the input sensors may be from a variety of data input types, including, but not limited to, audio data, visual data, or biometric data. The user device may comprise any electronic device that may be operated by a user, which may also provide remote communication capabilities to a network. Examples of remote communication capabilities include using a mobile phone (wireless) network, wireless data network (e.g., 4G, 5G or similar networks), Wi-Fi, Wi-Max, or any other communication medium that may provide access to a network such as the Internet or a private network. [0021] An “interaction” may include a reciprocal action or influence. An interaction can include a communication, contact, or exchange between parties, devices, and/or entities. Example interactions include a transaction between two parties and a data exchange between two devices. In some embodiments, an interaction can include a user requesting access to secure data, a secure webpage, a secure location, and the like. In other embodiments, an interaction can include a payment transaction in which two devices can interact to facilitate a payment.

[0022] “Interaction data” can include data related to and/or recorded during an interaction. In some embodiments, interaction data can be transaction data of the network data. Transaction data can comprise a plurality of data elements with data values.

[0023] A “resource provider” may be an entity that can provide a resource such as goods, services, information, and/or access. Examples of resource providers includes merchants, data providers, transit agencies, governmental entities, venue, and dwelling operators, etc.

[0024] A "portable device" can be a device that is easily transportable. In some cases, it can be hand-held and compact. For example, a portable device may fit into a user's wallet and/or pocket (e.g., pocket-sized). Some exemplary portable devices may include smart cards, ordinary credit, or debit cards (with a magnetic strip), keychain devices, etc. Other examples of portable devices include cellular phones, personal digital assistants (PDAs), pagers, payment cards, security cards, access cards, smart media, transponders, vehicles (e.g., cars, boats, motorcycles, etc.), wearable devices (e.g., smart watch, smart jewelry, smart clothing, etc.) and the like. The portable devices can also be debit devices (e.g., a debit card), credit devices (e.g., a credit card), or stored value devices (e.g., a stored value card).

[0025] An “antenna” can include a device used to transmit and/or receive signals. An antenna can be a rod, a wire, a chip, a chipset, etc. that is capable of receiving and/or transmitting radio signals. An antenna can be a near-field communication antenna, an ultra-wideband antenna, or any other suitable type of antenna.

[0026] A “near-field communication antenna” can include a device used to transmit and/or receive near-field communication based signals. A near-field communication antenna can be a chip or a chipset that enables short-range wireless communication between two devices. A near-field communication antenna can be a near-field communication reader chip (e.g., active component) or a near-field communication tag (e.g., passive component). A near-field communication antenna that is a near-field communication reader chip can provide power and can send near-field communication commands to a near-field communication tag. Near-field communication is based on inductive coupling between two antennas present on two devices (e.g., on a user device and on an access device). The two dvices can communicate in one or both directions, using a frequency of 13.56 MHz in the globally available unlicensed radio frequency ISM band using the ISO/IEC 14443 air interface standard at data rates ranging from 106 to 848 kbit/s.

[0027] A “processor” may include a device that processes something. In some embodiments, a processor can include any suitable data computation device or devices. A processor may comprise one or more microprocessors working together to accomplish a desired function. The processor may include a CPU comprising at least one high-speed data processor adequate to execute program components for executing user and/or system-generated requests. The CPU may be a microprocessor such as AMD's Athlon, Duron, and/or Opteron; IBM and/or Motorola's PowerPC; IBM's and Sony's Cell processor; Intel's Celeron, Itanium, Pentium, Xeon, and/or XScale; and/or the like processor(s).

[0028] A “memory” may be any suitable device or devices that can store electronic data. A suitable memory may comprise a non-transitory computer readable medium that stores instructions that can be executed by a processor to implement a desired method. Examples of memories may comprise one or more memory chips, disk drives, etc. Such memories may operate using any suitable electrical, optical, and/or magnetic mode of operation.

[0029] A “server computer” may include a powerful computer or cluster of computers. For example, the server computer can be a large mainframe, a minicomputer cluster, or a group of servers functioning as a unit. In one example, the server computer may be a database server coupled to a Web server. The server computer may comprise one or more computational apparatuses and may use any of a variety of computing structures, arrangements, and compilations for servicing the requests from one or more client computers. [0030] Near-field communication (NFC) is a short-range two way wireless communication technology that uses magnetic-field induction to enable communications between electronic devices in close proximity. An NFC-capable device is configured with a coil-loop antenna, through which an electric current is passed to generate a magnetic field that surrounds the conductor forming the coilloop. A change in the magnetic field in the vicinity of the antenna induces a change in voltage across the terminals of the coil-loop, and a change in voltage across the terminals of the coil-loop changes the magnetic field generated by the antenna. By modulating the magnetic field generated between the inductively-coupled coil-loop antennae, data is transferred between devices.

[0031] Novel techniques disclosed in the present disclosure provide a solution that embeds a payment entity’s cryptographic root of trust (ROT, e.g., crypto keys) into a specialized processor called a security processing engine (SPE, also referred to as a “secure data processor”). The SPE may be further integrated inside a general processor, a system-on-chip (SoC) or platform controller hub (PCH). The SPE, containing dedicated hardware and software components, can act as a payment engine to perform encryption using the ROT for communication protection of payment transactions. Such an architecture can make payments native to all smart devices.

[0032] The SPE may be an isolated portion of an integrated semiconductor chip (or a system package), for example, in a user device or edge processor, with its own processing components dedicated to payment transaction protection. The cryptographic keys used for the payment transaction can be stored within the SPE’s memory, securely isolated from the CPU of the user device, and the crypto key operations (e.g., key injection, key generation, key attestation, encryption/decryption, signature generation, etc.) may be performed by the SPE.

[0033] The booting process for the user device may be performed in two stages: the SPE boot process and the host boot process. A SPE verify-boot process may bridge these two stages. For example, the SPE may be booted first when the user device is powered on, and may verify the integrity of the CPU before the CPU is booted to execute instructions for an operation such as a payment transaction. In some embodiments, the SPE can perform security operations (e.g., encryption of data in the NFC payment communication) using the ROT on behalf of the CPU to prevent an unauthorized entity from gaining control of the device to perform unauthorized transactions.

[0034] For the purpose of this application, isolation between the SPE and CPU physically and electrically may mean no electrical interference, or unauthorized/unintended communication between the SPE and CPU. Secured communication between the SPE and CPU through certain communication protocols is possible.

[0035] Embodiments of the present disclosure provide a number of advantages/benefits. For example, booting SPE first and performing an integrity check for the CPU of the user device before the CPU is booted can detect any security issues or malicious activities in the CPU to ensure the device has a clean start. Furthermore, the ROT of the device stored in the SPE is securely isolated from the CPU both physically and electrically (e.g., in different segments of an integrated semiconductor chip and/or accessing different memory storage). Such secure isolation provides further protection against potential malicious activities. Finally, the SPE performing encryption and decryption functions on behalf of the CPU using the securely isolated ROT, when combined with the above features, can eliminate the vulnerability of software-based encryption because, in software-based encryption, the software responsible for encrypting data cannot know whether the CPU executing the software has been compromised.

[0036] FIG. 1 is a block diagram illustrating an example communication system, according to certain embodiments. The communication system 100 depicted in FIG. 1 is an example and is not intended to unduly limit the scope of claimed embodiments. Many variations, alternatives, and modifications are possible. For example, in some implementations, communication system 100 may have more or fewer components than those shown in FIG. 1 , may combine two or more components, or may have a different configuration or arrangement of components. The system, subsystems, and other components depicted in FIG. 1 may be implemented in software (e.g., code, instructions, program) executed by one or more processing units (e.g., processors, cores) of the system, using hardware, or combinations thereof. The software may be stored on a non-transitory storage medium (e.g., on a memory device). [0037] The communication system 100 comprises a user device 102, and a portable device 106. In some embodiments, the user device 102 can be a smartphone. The user device 102 can be operated by a resource provider that provides resources, or it could be operated by the user of the portable device 106. the user device 102 can include a user device NFC antenna 112 for communication with the portable device 106.

[0038] The portable device 106 can be in the form of a card that includes an NFC antenna 116. The portable device 106 can be a card such as a driver’s license, a debit card, a credit card, an employee badge, etc. The portable device 106 can receive NFC signals 122 from the user device 102 via the portable device NFC antenna 116. The portable device 106 can transmit NFC signals 126 to the user device 102 via the portable device NFC antenna 116.

[0039] Both the user device 102 and the portable device 106 (e.g., a contactless payment card) may interact with each other using NFC signals 122 and 126 to facilitate a transaction (e.g., a contactless payment transaction, a data transfer, etc.). Such communication (via NFC signals 122 and 126) between the user device 102 and the portable device 106 may be referred to as NFC communication.

[0040] FIG. 2 is a block diagram illustrating an example user device, according to certain embodiments. The example user device 102 may comprise a processor 204. The processor 204 may include a security processing engine (SPE) 205 that is isolated from the CPU (not shown) of the processor 204. The processor 204 may be coupled to a memory 202, a network interface 206, a computer-readable medium 208, input elements 210, output elements 212, a power source connection 214, and an NFC subsystem 216. The computer-readable medium 208 can comprise one or more modules, including the communication module 208A.

[0041] The memory 202 can be used to store data and code. For example, the memory 202 can store interaction data, application protocol data unit (APDU) commands, etc. The memory 202 may be coupled to the processor 204 internally or externally (e.g., cloud-based data storage), and may comprise any combination of volatile and/or non-volatile memory, such as RAM, DRAM, ROM, flash, or any other suitable memory device. [0042] The input elements 210 may include any suitable device(s) capable of inputting data into the user device 102. Examples of input elements 210 include buttons, touchscreens, touch pads, microphones, etc.

[0043] The output elements 212 may comprise any suitable device(s) that may output data. Examples of output elements 212 may include display screens, speakers, and data transmission devices. For example, the output elements 212 can include a display screen capable of displaying a response value to a user of the user device 102.

[0044] The computer-readable medium 208 may comprise code, executable by the processor 204, for performing methods.

[0045] The communication module 208A allows the processor 204 to control the NFC subsystem 216, which includes the NFC chip 216A and the NFC antenna 216B, which is tuned typically for 13.56 MHz. The NFC chip 216A could be, for example, a PN531 microcontroller-based transmission module from the Phillips Semiconductor Branch of Koninklijke Phillips Electronics N.V.

[0046] The network interface 206 may include an interface that can allow the user device 102 to communicate with external computers. Some examples of the network interface 206 may include a modem, a physical network interface (such as an Ethernet card or other Network Interface Card (NIC)), a virtual network interface, a communications port, a Personal Computer Memory Card International Association (PCMCIA) slot and card, or the like. The wireless protocols enabled by the network interface 206 may include Wi-Fi™. Data transferred via the network interface 206 may be in the form of signals, which may be electrical, electromagnetic, optical, or any other signal capable of being received by the external communications interface (collectively referred to as “electronic signals” or “electronic messages”). These electronic messages that may comprise data or instructions may be provided between the network interface 206 and other devices via a communications path or channel. As noted above, any suitable communication path or channel may be used, such as, for instance, a wire or cable, fiber optics, a telephone line, a cellular link, a radio frequency (RF) link, a WAN or LAN network, the Internet, or any other suitable medium. [0047] The NFC subsystem 216 can include an NFC chip 216A and an NFC antenna 216B. The communication module 208A, in conjunction with the processor 204, can cooperate with the NFC subsystem 216 to communicate using NFC.

[0048] The NFC antenna 216B can include an antenna configured to utilize nearfield communication frequencies. Near-field communication can include a set of communication protocols that enable communication between two electronic devices over a distance of 4 cm or less. Near-field communication is based on inductive coupling between two antennas present on near-field communication-enabled devices communicating in one or both directions, using a frequency of 13.56 MHz in the globally available unlicensed radio frequency ISM band using the ISO/IEC 14443 air interface standard at data rates ranging from 106 to 848 kbit/s.

[0049] The NFC antenna 216B can be connected to an interface and connected to driver circuits. The interface and the driver circuits can connect the near-field communication antenna to the processor 204.

[0050] The power source connection 214 can both provide power and receive power from connected devices. In some embodiments, the power source connection 214 can be electrically coupled to the power supply cable 110, which can be electrically coupled to the bridge apparatus 120. As such, the power source connection 214 can provide electricity to the bridge apparatus 120.

[0051] An interaction application (e.g., a tap-to-phone application) may comprise a kernel software including codes running on the processor 204 to cause the user device 102 to receive data from and transmit data (e.g., via the NFC subsystem 216 and an NFC API) to an external device such as an external card.

[0052] In some embodiments, the interaction application can generate interaction command messages (e.g., APDU commands) and receive interaction response messages (e.g., APDU responses). The APDU commands may include both contactless APDU commands and contact APDU commands. The interaction application may be configured to generate either contactless APDU commands or contact APDU commands based on an indicator (discussed below) received by the interaction application. [0053] FIG. 3 illustrates a block diagram of an exemplary portable device 106. In some embodiments, the portable device 106 can be an integrated circuit chip card. The portable device 106 may include a processor 302, an NFC antenna 304, and a memory 306 storing a plurality of applications (e.g., application 308) executable by the processor 302.

[0054] The memory 306 can be implemented using any combination of any number of non-volatile memories (e.g., flash memory, EEPROM) and volatile memories (e.g., DRAM, SRAM), or other suitable non-transitory storage medium, or a combination thereof media. The memory 306 may store various applications, including the application 408, that can be selected by a client device (e.g., the user device 102) for data exchange. Examples of such applications may include mobile wallet applications, interaction applications, resource provider applications, identification applications, etc. An interaction application can include transit applications, secure location access applications, payment applications, and/or any other suitable application facilitating in an interaction between two entities (e.g., a user and a resource provider). In some embodiments, an interaction application can be provisioned by an authorizing entity. As an example, the application 408 can be a payment application that can allow a user of the portable device 106 to gain access to a resource (e.g., goods and/or services purchased using the payment application). The memory 406 may also store credentials such as primary account numbers, .tokens, cryptograms, expiration dates, etc.

[0055] The NFC antenna 304 can be similar to the NFC antenna 216B in the user device 102 in FIG. 2, and can similarly be included in an NFC subsystem.

[0056] As discussed above, SPE may be integrated inside a general processor, a system-on-chip (SoC), or a platform controller hub (PCH). FIGs. 4, 5, and 6 illustrate different architectures of embedded SPE. In some embodiments, these architectures may be utilized by the user device. FIG. 4 is a block diagram illustrating an architecture 400 embedding an SPE inside a platform controller hub (PCH), according to certain embodiments.

[0057] As shown in FIG. 4, the architecture 400 may include a CPU 410, containing multiple cores 412 (or core cluster), a PCH 430, memory 420, and other peripherals (not shown). A PCH may be a chipset that serves as an interface between a CPU and various peripherals in computing systems. The PCH can enable data transfer between the CPU 410, memory 420, and peripherals (e.g. , USB ports, PCI express (PCIe) slots, network interfaces, etc.). The PCH may include a switch 432 for communicating to CPU 410 through a root complex 414, which manages connection and data transfer between the CPU and PCIe devices). The SPE 205 may be embedded inside the PCH 430, connected to an interconnect 434 in the PCH 430, and communicate with the CPU 41- via switch 432 and the root complex 414. In some embodiments, the architecture may include a physical layer interface (PHY) 440 connected to PCH 430 for receiving NFC communication 450 (e.g., communication 122 & 126 between user device 102 and portable device 106). PHY 440 may be an electronic circuit on the chip responsible for transmitting and receiving raw data bits over a physical medium and performing encoding/decoding if necessary.

[0058] In FIG. 4, in some embodiments, the SPE 205 of architecture 400 may be isolated from the CPU 410 for security purposes. For example, SPE 205 and CPU 410 may be on an integrated semiconductor chip (or substrate) but are located in different segments of the chip to create physical and electrical separation, for example, by adding insulating layers (e.g., silicon dioxide). Additionally, SPE 205 and CPU 410 may not share or access the same storage used for performing security operations (i.e., using separate storage devices for storing cryptographic keys). For example, SPE 205 may have its own dedicated software and hardware (further details discussed below in FIGs. 7 and 8), including memory (e.g., read-only-memory (ROM) and random access memory (RAM)) that stores the cryptographic root of trust (ROT), such as hardware root of trust (e.g., hardware security modules (HSM)), and is isolated from CPU 410. Thus, any unauthorized access (e.g., malicious attack) to the CPU 410 may not affect the SPE 205. In some embodiments, SPE 205 may be able to access system memory 420 (e.g., via interconnect 434, switch 432, and root complex 414) if there is a need beyond the encryption/decryption function.

[0059] Furthermore, SPE 205 of architecture 400 may be configured to perform security operations, such as encryption and decryption functions, on behalf of CPU 410 using the root of trust stored in SPE’s dedicated memory. The security operations may be selectively performed on certain data, but not on other data. For example, an NFC communication 450 destined for CPU 410 may first be routed to SPE 205 via PHY 440. SPE 205 may be configured to check whether the received data should be selected for encryption based on certain rules or criteria (i.e., belonging to certain data categories). For example, the data categories (or data to be selected for encryption) may include, but are not limited to, data related to payment transactions, important credentials, identity information (e.g., mobile driver’s license or E-passports), etc. If it does, SPE 205 may perform encryption on the selected data. The encrypted data by SPE 205 may be transferred to CPU 410 via interconnect 434, for example, by storing it in system memory 420 for CPU 410 to access. In other words, SPE 205 can perform encryption/decryption functions without the CPU’s 140 involvement (e g., using the direct memory access (DMA) feature). Thus, the selected data may have been encrypted when it reaches CPU 410, and a bad actor may not have a chance to temper with the selected data. After processing the selected data, CPU 410 may transfer the selected data back to SPE 205, which can be decrypted and sent to a receiver (e.g., portable device 106) of the NFC communication.

[0060] On the other hand, data not selected for encryption by SPE 205 of architecture 400 may be passed directly to CPU 410 via interconnect 434 without encryption. CPU 410 can determine how to handle this data (e.g., whether to encrypt or decrypt). Compared to the above approach, the data being encrypted by CPU 410 rather than SPE 205 may expose plain text data when accessing memory 420 or using CPU codes before the data is finally encrypted. As a result, those unselected data not encrypted by SPE 205 when it initially arrives at PCH 430 may have a higher security vulnerability if either memory 420 or CPU codes are compromised.

[0061] FIG. 5 is a block diagram illustrating an architecture 500 embedding an SPE 205 inside a processor 510, according to certain embodiments. As shown in FIG. 5, the architecture 500 may include an integrated semiconductor chip that contains a processor, including multiple cores (or core cluster) 520, a root-complex 540, and a SPE 205 sitting between the core cluster 520 and the root complex 540. All components in the processor 510 may share the same system memories (e.g., memory 550a and memory 550b). Similarly to the discussion above in relation to FIG. 4, the SPE 205 may be isolated from the core cluster 520 of the processor, for example, in different segments of the integrated semiconductor chip. The SPE 205 may have its own dedicated software and hardware (further details discussed below in FIGs. 7 and 8), such as dedicated local memory (e.g., ROM and RAM) that stores the cryptographic root of trust (ROT, or hardware root of trust). However, SPE 205 may be able to access the system memories, such as storing or retrieving encrypted data, or if there is a need beyond the encryption/decryption function for this architecture.

[0062] Similar to the discussion above in relation to FIG. 4, in FIG. 5, SPE 205 of architecture 500 may be configured to perform security operations, such as encryption and decryption functions on behalf of core cluster 520 using the root of trust stored in the SPE’s dedicated memory. The NFC communication 560 (e.g., communication 122 and 126 between user device 102 and portable device 106 in FIG. 1 ) destined for core cluster 520 may go through certain communication interfaces (not shown), and reach SPE 205 first, which may be configured to inspect and selectively perform encryption on certain data in the NFC communication 560 before transferring the selected data to core cluster 520. SPE 205 of architecture 500 may then store the encrypted data into system memories 550a and 550b for core cluster 520 to access.

[0063] After processing the selected data, core cluster 520 may transfer the selected data back to SPE 205 (or store the selected data into system memories 550a and 550b for SPE 205 to access), which can decrypt to send to a receiver (e.g., portable device 106) of the NFC communication.

[0064] FIG. 6 is a block diagram illustrating an architecture 600 embedding a SPE 205 inside a system-on-chip (SoC) 610, according to certain embodiments. An SoC may be an integrated circuit that consolidates components of a computer or electronic systems, such as a CPU (e.g., multiple cores), controllers, Input/output units, and secondary storage devices, on a single semiconductor chip (or substrate). As shown in FIG. 6, the architecture 600 may include multiple CPU cores 620, an internal interconnect 640, and a SPE 205 sitting between the CPU core 620 and the internal interconnect 640. All components in the SoC 610 may share the same system memory 650, which may be external to the SoC 610.

[0065] Similar to the discussion above in relation to FIG. 4, the SPE 205 of architecture 600 may be isolated from the core cluster 520 of the processor, for example, in different segments of the integrated semiconductor chip. The SPE 205 may have its own dedicated software and hardware (further details discussed below in FIGs. 7 and 8), such as dedicated local memory (e.g., ROM and RAM) that stores the cryptographic root of trust (ROT, or hardware root of trust). However, SPE 205 may be able to access the system memory 650 if there is a need beyond the encryption/decryption function for this architecture.

[0066] Similar to the discussion above in relation to FIG. 4, in FIG. 6, SPE 205 of architecture 600 may be configured to perform security operations, such as encryption and decryption functions on behalf of CPU cores 620 using the root of trust stored in the SPE’s dedicated memory. The NFC communication 660 (e.g., communication 122 and 126 between user device 102 and portable device 106) destined for CPU cores 620 may go through certain communication interfaces (not shown) and internal interconnect 640, and reach SPE 205 first, which may be configured to inspect and selectively perform encryption on certain data in the NFC communication 660 before transferring the selected data to CPU cores 620 . SPE 205 of architecture 600 may then store the encrypted data in system memory 650 for CPU cores 620 to access.

[0067] After processing the selected data, CPU cores 620 may transfer the selected data back to SPE 205 (or store the selected data into system memory 650 for SPE 205 to access), which can decrypt to send to a receiver (e.g., portable device 106) of the NFC communication.

[0068] FIG. 7 illustrates the hardware portion of a SPE, according to certain embodiments. As discussed above, the SPE may have dedicated hardware 700. The hardware portion may include, but is not limited to, random number generator (RNG) 702 for cryptographic purposes, fuse 704, real-time clock (RTC) 706, and input/output (I/O) interface 708. SPE may also have an engine processor 742, which may be a low- complexity processor with low power consumption. The engine processor may work with a cryptographic accelerator (or crypto accelerator) 740, which may have specialized cryptographic capability for performing cryptographic operations for certain data, such as data related to payment transactions. The crypto accelerator 740 may have its own read-only memory (ROM) 722 and static random access memory (SRAM) 724. ROM 722 may contain a kernel boot loader and hardware root of trust. Serial peripheral interface (SPI) flash 720 may store software of SPE (described below in FIG. 8), such as a micro-kernel of SPE, crypto libraries, drivers, and applications. In some embodiments, ROM 722, and SPI flash 720 may work together to ensure the safeguard (e.g., keep keys in encrypted form), generation, and management of cryptographic keys. These storage devices (e.g., ROM 722, SRAM 724, SPI flash 720) may be separated and isolated from the CPU cores of the processor, SoC, or PCH that the SPE is embedded inside. Once the processor (e.g., in FIG. 5), SoC (e.g., in FIG. 6), or PCH (e.g., in FIG. 4) is taped out (i.e., completion of IC design and transition to manufacturing), the ROM content and manufacturing fuses are set (or cannot be modified). After that, the processor, SoC, or PCH may be integrated into a user device (e.g., 102), and the content in SPI flash may be set (i.e., it cannot be programmed externally).

[0069] FIG. 8 illustrates the software portion of a SPE, according to certain embodiments. As discussed above, the SPE may have dedicated software 800. The bottom layer of the software stack includes a ROM 810 containing the hardware root of trust. The second layer is the boot loader (BL) 820. The third layer is the microkernel (SPE m-kernel) 830. The fourth layer may include crypto libraries 842, a flash file system (FS) 844 for flash memory, an I/O driver 846, and a process manager 848. The top layer may include applications and services (e.g., KeyStore (for managing cryptographic keys and certificates), NFC communication 850 for SPE. The process manager 848 may manage the applications and services 850. For example, upon receiving an NFC communication (e.g., 450 of FIG. 4), the process manager 848 may invoke the NFC communication manager (e.g., part of applications and services 850) to check communication to determine whether data encryption should be performed under certain data categories, such as data related to payment transactions, as discussed above in relation to FIG. 4. If the communication containing data in the data categories, the process manager may further invoke security application/service (e.g., KeyStore) to perform data encryption. Crypto libraries 842 may include libraries for various cryptographic technologies or algorithms, such as advanced encryption standards (AES) and elliptic curve cryptography (ECC).

[0070] FIG. 9 illustrates a booting process for both the security processing engine (SPE) and host CPU, according to certain embodiments. In FIG. 9, the host CPU 950 and the SPE (security processing engine) 205 can be in a user device 102 (e.g., a mobile phone). When the user device is powered on, the SPE 205 may be first booted before the host CPU 950 is booted. Thus, the SPE 205 can detect any security issues or malicious activities in the CPU 950, such as malicious software in CPU microcodes and/or host boot loader, before the CPU 950 is booted up. The SPE 205 may verify the integrity of CPU codes and host boot loader (also referred to as verify-boot process) to ensure they are not tempered. Once the hardware integrity check is completed, the process can be handed off to the software process for communication between the host OS, and SPE applications and services.

[0071] As shown in FIG. 9, the booting process for the user device 102 may be performed in two stages. 910 and 912. The first stage is the SPE boot process 910, and the second stage 912 is the host boot process 912. An SPE verify-boot process 930 may bridge the two stages. The booting process for SPE may commence at step S1 when the user device is powered up.

[0072] At step S2, SPE 205 may obtain the hardware root of trust (ROT) (e.g., crypto keys) from the ROM 920.

[0073] At step S3, SPE 205 may load the boot loader 922 into its internal RAM (e.g., SRAM 724 of FIG. 7). Then, boot loader 922 may locate and load the micro-kernel (mKernel) 924, which may include basic functions or services for SPE 205.

[0074] At step S4, the SPE may send a reset signal to the host CPU 950 to start the host boot process 912.

[0075] At step S5, the SPE 205 may then perform verify-boot process 930, which is a process for performing integrity checks on CPU codes and host boot loader in host CPU 950. The verify-boot process 930 may be performed in parallel with the host boot process 912.

[0076] At step S6, the host CPU 950 of the user device (e.g., a mobile device) 102 may execute CPU codes (e.g., from a Boot ROM), then load the host boot loader 962.

[0077] At step S7, the SPE 205 may interact with the host CPU 950 to verify that the boot information from the host is correct, for example, by checking the pointers, hash values, or signatures of CPU codes 960 and addresses of the host boot loader 962 (e.g., such as comparing the temporarily stored boot information in memory to expected information) to ensure CPU codes 960 and host boot loader 962 are executed correctly without any sign of tempering or altering/modifications. The verified result may be recorded and reported to the services and applications of SPE.

[0078] At step S8, the host boot loader 962 may load OS loader 970 (e.g., Linux loader or Mac OS loader, including kernel initialization). This step may mark the transfer of control (also referred to as handoff) from a hardware-initialized system (e.g., including host boot loader) to software-controlled operations (e.g., loading the operating system and preparing the user device for user interactions and application execution).

[0079] At step S9, the host OS 972 may then be loaded and executed by the host CPU 950.

[0080] At step S10, once the host OS 972 is operating, the host OS can communicate with drivers, services, and applications 940 in the SPE. For example, as discussed earlier in relation to FIG. 4, the SPE may perform security operations on certain data from the NFC communication, and inform the host CPU 410 (or 950 of FIG. 9 executing host OS 972) that the selected data have been encrypted, transferred, and stored into system memory 420 for access. In some embodiments, some services and applications 940 in the SPE (e.g., not involving in security operations) may be exposed through SPE’s driver (or certain inter-processor communication protocols) and executed by the host CPU 950.

[0081] While the host CPU 950 is performing its boot process (S8 to S10), at step S11 , SPE 205 may report the verified boot result to the service application 940 of SPE. If the verified report indicates that a potential problem exists, the user device 102 may stop the payment transactions that is part of the NFC communication (e.g., 122 and 126 of FIG. 1), and notify the bank or the owner of the user device 102, or other stakeholders.

[0082] FIG. 10 illustrates an example flowchart depicting a generalized process performed by SPE and host CPU, according to certain embodiments. The method presented in FIG. 3 and described below are intended to be illustrative and nonlimiting. Although FIG. 10 depicts the various processing steps occurring in a particular sequence or order, this is not intended to be limiting. In certain alternative embodiments, the processing may be performed in some different order or some steps may also be performed in parallel. It should be appreciated that in alternative embodiments the processing depicted in FIG. 10 may include a greater number or a lesser number of steps than those depicted in FIG. 10.

[0083] At step 1010, a device, which includes a security processing engine (SPE) and a host central processing unit (CPU) on a same integrated semiconductor chip, may be powered on. The SPE may have dedicated hardware and dedicated software isolated from the CPU. For example, in FIG. 9, a user device 102, which includes a security processing engine (SPE) 205 and a host CPU 950, may be powered on as shown in step S1 , for example, when a user of the user device 102 supplies power source to the device through power source connector 214 of FIG. 2. As discussed above in relation to FIG. 4, SPE 205 and CPU 950 (or 410) may be on an integrated semiconductor chip (or substrate) but are located in different segments of the chip for isolation purposes. Additionally, SPE 205 may have its own dedicated hardware (e.g., including separate storage devices for storing hardware root of trust) and dedicated software, as shown in FIGs. 7 and 8.

[0084] At step 1020, an integrity check may be performed by the SPE to verify that boot information of the CPU has not been altered or tampered with. For example, in FIG. 9, after the SPE 205 sends a reset signal, at step S4, to the host CPU 950 to start the host boot process 912, SPE 205 may then, at step S5, perform verify-boot process 930 in parallel with the host boot process 912. The integrity check, part of step S7, may verify boot information, including CPU codes 960 and host boot loader 962, in the CPU to ensure no sign of tempering or altering/modifications.

[0085] At step 1030, after the integrity check is performed, the host CPU may execute an operating system. For example, in FIG. 9, after the integrity check is performed, at steps S8 and S9, the host CPU may transfer control from hardware- initialized system to software-controlled operations to load the operating system 972 that can be executed by cores of the host CPU 950 (e.g., executed by cores 412 of FIG. 4, core cluster 520 of FIG. 5, and CPU cores 620 of FIG. 6).

[0086] FIG. 11 illustrates an example flowchart depicting a security operation performed by SPE, according to certain embodiments.

[0087] At step 1110, a security processing engine (SPE) may be configured to perform security operations (e.g., encryption/decryption) based on certain criteria. For example, as discussed in relation to FIG. 4, SPE 205 may be configured to check whether the received data (from NFC communication 450) should be selected for encryption if the data belongs to certain data categories, such as payment transactions, important credentials, identity information (e.g., mobile driver’s license, or E-passports), etc. [0088] At step 1120, NFC communication may be received from a portable device. For example, in FIGs. 1 and 4, the NFC communication, such as a contactless payment transaction, may be performed between the user device 102 and the portable device 106 via NFC signals 122 and 126.

[0089] At step 1130, the SPE may determine whether the data in the received NFC communication is selected for encryption based on the configurations in 11 10. For example, in FIGs. 4 and 8, the process manager 848 of SPE 205 may invoke the NFC communication manager (part of 850) to determine whether the data in the received NFC communication meet the criteria (e.g., belong to certain data categories), and should be selected for encryption.

[0090] At step 1140, if the received data is selected for encryption (i. e. , determined to meet the criteria), the process proceeds to step 1170 (described below). If the received data is not selected for encryption (i.e., does not meet the criteria), the process proceeds to step 1150, where SPE 205 may pass the data directly to CPU 410 via interconnect 434 without encryption, and CPU 410 can determine how to handle this data.

[0091] At step 1160, the SPE may encrypt the selected data in the received NFC communication. For example, in FIGs. 4 and 8, the process manager 848 of SPE 205 may further invoke security application/service (part of 850) to perform data encryption using one of the cryptographic technologies (e.g., AES, ECC, etc.) available in the crypto libraries 842.

[0092] At step 1170, the encrypted data may be transferred to the host CPU for processing. For example, in FIG. 4, the encrypted data by SPE 205 may be transferred to CPU 410 via interconnect 434, for example, by storing it in system memory 420 for CPU 410 to access and process the payment transaction.

[0093] Any of the software components or functions described in this application may be implemented as software code to be executed by a processor using any suitable computer language such as, for example, Java, C, C++, C#, Objective-C, Swift, or scripting language such as Perl or Python using, for example, conventional or object- oriented techniques. The software code may be stored as a series of instructions or commands on a computer readable medium for storage and/or transmission, suitable media include random access memory (RAM) a read only memory (ROM), a magnetic medium such as a hard-drive or a floppy disk, or an optical medium such as a compact disk (CD) or DVD (digital versatile disk), flash memory, and the like. The computer readable medium may be any combination of such storage or transmission devices.

[0094] Such programs may also be encoded and transmitted using carrier signals adapted for transmission via wired, optical, and/or wireless networks conforming to a variety of protocols, including the Internet. As such, a computer readable medium according to an embodiment of the present invention may be created using a data signal encoded with such programs. Computer readable media encoded with the program code may be packaged with a compatible device or provided separately from other devices (e.g., via Internet download). Any such computer readable medium may reside on or within a single computer product (e.g., a hard drive, a CD, or an entire computer system), and may be present on or within different computer products within a system or network. A computer system may include a monitor, printer, or other suitable display for providing any of the results mentioned herein to a user.

[0095] The above description is illustrative and is not restrictive. Many variations of the invention will become apparent to those skilled in the art upon review of the disclosure. The scope of the invention should, therefore, be determined not with reference to the above description, but instead should be determined with reference to the pending claims along with their full scope or equivalents.

[0096] One or more features from any embodiment may be combined with one or more features of any other embodiment without departing from the scope of the invention.

[0097] As used herein, the use of "a," "an," or "the" is intended to mean "at least one," unless specifically indicated to the contrary.

Claims

WHAT IS CLAIMED IS:

1. A device comprising: a central processing unit (CPU) configured to execute an operating system; and a security processing engine (SPE) coupled to the CPU, the SPE being on a same integrated semiconductor chip as the CPU and having dedicated hardware and dedicated software isolated from the CPU, wherein the SPE is programmed to boot and perform an integrity check for the CPU before the CPU executes an operating system.

2. The device of claim 1 , wherein the SPE is isolated from the CPU physically and electrically on the integrated semiconductor chip.

3. The device of claim 1 , wherein the dedicated hardware of the SPE comprises one of more of: memory, cryptographic accelerator, random number generator, real-time clock, and Input/output.

4. The device of claim 3, wherein the memory in the dedicated hardware of the SPE stores hardware root of trust.

5. The device of claim 1 , wherein the dedicated software of the SPE comprises one or more of: boot loader, kernel, libraries, driver, and applications.

6. The device of claim 1 , wherein the SPE is programmed to perform security operations for the CPU.

7. The device of claim 6, wherein the security operations comprise selectively performing encryption, by the SPE, on data from a near-field communication (NFC) destined for the CPU and sending, by the SPE, the encrypted data to the CPU.

8. The device of claim 1 , wherein the integrity check comprises verifying boot information of the CPU.

9. The device of claim 8, the boot information comprises CPU codes and host boot loader in the CPU.

10. A method comprising: powering on a device comprising a security processing engine (SPE) and central processing unit (CPU) on a same integrated semiconductor chip, wherein the SPE has dedicated hardware and dedicated software isolated from the CPU; performing, by the SPE, an integrity check that boot information of the CPU has not been altered or tampered with; and after the integrity check is performed, executing, by the CPU, an operating system.

11. The method of claim 10, wherein the boot information comprises CPU codes and host boot loader in the CPU.

12. The method of claim 10, further comprising performing security operations, by the SPE, for the CPU.

13. The method of claim 12, wherein the security operations comprise selectively performing encryption, by the SPE, on data from a near-field communication (NFC) destined for the CPU and sending, by the SPE, the encrypted data to the CPU.

14. The method of claim 10, wherein the SPE is isolated from the CPU physically and electrically on the integrated semiconductor chip.

15. The method of claim 10, wherein the dedicated hardware of the SPE comprises one of more of: memory, cryptographic accelerator, random number generator, real-time clock, and Input/output.

16. The method of claim 10, wherein the dedicated software of the

SPE comprises one or more of: boot loader, kernel, libraries, driver, and applications.

17. A system, comprising: a user device comprising: a central processing unit (CPU) configured to execute an operating system; a security processing engine (SPE) coupled to the CPU, the SPE being on an integrated semiconductor chip as the CPU and having dedicated hardware and dedicated software isolated from the CPU; and a portable device communicating with the user device via a near-field communication (NFC), wherein the SPE is programmed to boot and perform an integrity check for the CPU before the CPU executes the operating system.

18. The system of claim 17, wherein the dedicated hardware of the SPE comprises one of more of: memory, cryptographic accelerator, random number generator, real-time clock, and Input/output.

19. The system of claim 17, wherein the dedicated software of the SPE comprises one or more of: boot loader, kernel, libraries, driver, and applications.

20. The system of claim 17, wherein the SPE is programmed to perform security operations for the CPU, and the security operations comprise selectively performing encryption, by the SPE, on data from the NFC communication destined for the CPU and sending, by the SPE, the encrypted data to the CPU.