Secure Shell and Role Separation for Multitenant Computing

Abstract

Embodiments herein describe a SoC having one or more untrusted islands that can host one or more roles or tenants in a data center environment (e.g., a cloud computing environment). In one embodiment, a secure shell encapsulates the untrusted islands with a secure application programming interface (API) to access other hardware resources in the SoC. The hardware resources in the SoC (e.g., HardIP, SoftIP, or both) can be either secure / trusted or rely on the secure shell to ensure confidentiality.

Description

[Technical field]

[0001] Embodiments of the present disclosure generally relate to encapsulating portions of a system on a chip (SoC) using a secure shell as part of a trusted compute boundary (TCB). [Background technology]

[0002] Domain-specific accelerators, such as SmartNICs and other SoCs, offload work for multiple cloud tenants (e.g., cloud customers). These SoCs must provide high performance when offloading tenant workloads, but they must also ensure that tenants cannot eavesdrop on each other's sensitive information despite sharing the same hardware resources (e.g., accelerator SoCs). These domain-specific accelerator SoCs are built with different sets of components such as I / O gateways (e.g., Coherency and PCIe Modules (CPMs)), processing subsystems, networks, storage, and data accelerators (e.g., data transform engines (DTEs) for host and network connectivity of the SoC, and programmable logic (PL)). Multi-tenant data and metadata are transported across those components within the SoC using on-chip communication networks such as network on a chip (NoC) or programmable logic fabric interconnects. Even within each cloud tenant, sensitive information such as financial or legal affairs of one division of the enterprise may need to be protected from accidental or malicious eavesdroppers in other parts of the enterprise, along with insider information.

[0003] Furthermore, as modern public cloud infrastructure becomes more prevalent and trustworthy, a recent trend is for government agencies to award cloud contracts to public cloud infrastructure providers instead of building their own secure private cloud infrastructure. This adds new requirements for security in components to ensure that agency keys used to encrypt and exchange information should not be accessible by the cloud infrastructure provider itself, as well as to ensure that those keys are not accessible to other cloud tenants. Summary of the Invention [Problem to be solved by the invention]

[0004] Techniques are described for establishing an untrusted tenant portion in a system-on-chip (SoC). The SoC can include an untrusted tenant portion comprising a first circuit, the untrusted tenant portion configured to perform tasks for multiple tenants. The SoC further includes a secure shell comprising a second circuit, the secure shell configured to act as an interface to enable the tenant portion to communicate with other circuits in the SoC. The SoC further includes a secure shell launcher configured to establish a security protocol in the secure shell to protect sensitive information for the multiple tenants.

[0005] One embodiment described herein is a method that includes designating an untrusted island in a SoC comprising circuitry used to perform tasks for entities other than the owner of the SoC, creating a secure shell around the untrusted island comprising circuitry configured to act as an interface to allow the untrusted island to communicate with other circuitry in the SoC, and generating a NoC routing table to prevent untrusted entry points to a NoC in the untrusted island from directly accessing trusted entry points of the NoC in the secure shell.

[0006] One embodiment described herein is a SoC comprising: an untrusted island comprising a first circuit used to perform tasks for an entity other than an owner of the SoC; a secure shell comprising a second circuit surrounding the untrusted island that prevents the untrusted island from transmitting requests to other hardware elements in the SoC without first passing the request through the secure shell; and a secure shell launcher configured to establish a security protocol in the secure shell to protect sensitive information for the entity.

[0007] In a manner in which the above-recited features may be understood in detail, a more particular description briefly summarized above may be made by reference to exemplary implementations, some of which are illustrated in the accompanying drawings. It should be noted, however, that the accompanying drawings illustrate only typical example implementations and therefore should not be considered as limiting the scope thereof. [Brief description of the drawings]

[0008] [Figure 1] 1 illustrates a SoC having a secure shell and other TCB components, according to one embodiment. [Diagram 2]1 illustrates a system having an SoC, according to one embodiment. [Diagram 3] 1 illustrates a data path within a NoC, according to one embodiment. [Figure 4] 1 is a flow chart for establishing a secure shell for an untrusted island in a SoC, according to one embodiment. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0009] For ease of understanding, wherever possible, identical reference numbers have been used to designate identical elements common to the figures. It is contemplated that elements of one embodiment may be beneficially incorporated in other embodiments.

[0010] Various features are described below with reference to the drawings. It should be noted that the drawings may or may not be drawn to scale, and that elements of similar structure or function are represented by similar reference numerals throughout the drawings. It should be noted that the drawings are intended only to facilitate the description of features. They are not intended as an exhaustive description of features or as limitations on the scope of the claims. In addition, the illustrated examples do not necessarily have all aspects or advantages shown. An aspect or advantage described in connection with a particular embodiment is not necessarily limited to that embodiment and can be practiced in any other embodiment, even if not so illustrated or explicitly described.

[0011] Embodiments herein describe a SoC having one or more untrusted islands including softIP (e.g., programmable logic or programmable implementation) or HardIP (e.g., fixed implementation IP such as application specific integrated circuit (ASIC)) that can host one or more roles or tenants in a data center environment (e.g., cloud computing environment). In one embodiment, a secure shell (or trusted shell) encapsulates the untrusted islands with a secure application programming interface (API) to access resources in the SoC such as a data transformation engine (DTE) (also referred to as a data processing unit (DPU)), acceleration and crypto engines, and memory. Resources in the SoC (e.g., HardIP, SoftIP, or both) can be either secure / trusted or rely on the secure shell to ensure confidentiality, and the combination of these resources forms a trusted computation boundary (TCB). Advantages of embodiments herein include preventing a rogue tenant from stealing sensitive information of a data center (DC) owner (e.g., a Cloud Service Provider (CSP)) in a device (and vice versa), as well as preventing a rogue tenant from stealing sensitive information of another tenant that was provisioned by the DC owner for that tenant.

[0012] Furthermore, the secure shell and the untrusted island can be coupled to a shared SoC transport, such as a NoC. In one embodiment, the NoC transport allows three different types of data paths: (i) between two untrusted entry / exit points in the untrusted island, (ii) between two trusted entry / exit points in the secure shell, and (iii) an untrusted entry point in the island to a particular trusted entry point of the gatekeeper. After verifying that a request from the untrusted island is not fraudulent, the gatekeeper can then use the trusted entry point to allow the request to reach a different part of the secure shell through the NoC.

[0013] 1 illustrates an SoC 100 having a secure shell 105, according to one embodiment. The SoC 100 may be an integrated circuit (IC). The SoC 100 may include programmable logic (PL), hardened circuits, or a combination thereof. In one embodiment, the SoC 100 may be a field programmable gate array (FPGA), an ASIC, a SmartNIC, an acceleration device, a peripheral device, etc.

[0014] As shown, secure shell 105 surrounds tenant portion 110 (also referred to herein as an untrusted island or untrusted tenant portion) formed by circuitry within SoC 100. Tenant portion 110 includes hardware (e.g., circuits), such as PL, hardened circuits, or a combination thereof, that can be used to perform tasks for tenants within a data center or cloud computing environment. Tenant portion 110 is untrusted because it performs tasks for tenants (or roles) that are not controlled by the owner of SoC 100 (e.g., a DC owner or a cloud service provider). Thus, a malicious actor (e.g., a disgruntled employee of a tenant) may wish to use SoC 100 to steal information from other tenants or steal sensitive information from the SoC owner. As shown, multiple different tenants can use the circuitry within tenant portion 110 of the SoC. For example, tenant A may use some of the circuitry within tenant portion 110 to perform its tasks, and tenant B uses some of the circuitry within tenant portion 110 to perform its tasks.

[0015] The secure shell 105 (or trusted shell) encapsulates the untrusted islands (e.g., tenant portion 110) with secure application programming interfaces (APIs) to access other hardware resources in the SoC 100, such as the network on chip (NoC) 115, the I / O circuitry 120, the processor subsystem 125, the acceleration engines 130 (e.g., machine learning or crypto engines), the memory 135, and other types of circuits such as DTEs or DPUs (not shown). As discussed in more detail below, the secure shell 105 prevents a rogue tenant from stealing sensitive information of a DC owner (e.g., cloud service provider) in the SoC 100, and prevents a rogue tenant (e.g., Tenant A) from stealing sensitive information of another tenant (e.g., Tenant B) provisioned by the DC owner for that tenant. This sensitive information can include keys used for data encryption.

[0016] In one embodiment, secure shell 105 also prevents the DC owner from accessing tenant sensitive information, such as the tenant's keys used to encrypt and exchange information. To accomplish this, secure shell 105 may be established by the manufacturer of SoC 100, rather than by the DC owner. That is, because secure shell 105 is not configured or generated by the DC owner, but rather by the vendor of SoC 100, secure shell 105 can prevent the DC owner from accessing certain tenant sensitive information, such as their encryption keys. That is, the tenant may not trust the DC owner (or the cloud provider), but the tenant trusts the manufacturer of SoC 100.

[0017] In one embodiment, to establish trust between the tenant and the manufacturer of the SoC 100, the manufacturer may undergo a certification program or process to ensure that the SoC 100 establishes a secure shell 105 that prevents the DC owner from accessing the tenant's sensitive information. For example, the manufacturer may achieve FIPS 140-3 certification provided by the National Institute of Standards and Technology (NIST).

[0018] To establish secure shell 105 (and other security mechanisms within SoC 100), SoC 100 includes a secure shell launcher 140, which may include circuitry within SoC 100 including cryptographic authentication binaries within SoC 100 that are authenticated to establish security protocols within secure shell 105 that prevent the DC owner from accessing sensitive information of tenants. The cryptographic authentication binaries may be stored as secure ROM or secure RAM within SoC 100. When SoC 100 is powered on or booted, launcher 140 may establish secure shell 105 to isolate sensitive information for the DC owner and tenants from each other, and to isolate sensitive information for the tenants from each other.

[0019] In one embodiment, the secure shell launcher 140 is executed by a controller or processor (e.g., processor subsystem 125) in the SoC 100. This controller or processor may also be a secure boot engine that is authenticated and therefore trusted by the tenants. In one embodiment, the controller or processor configures the SoC 100 to have access to a configuration port to the secure shell 105, and is therefore the only circuitry in the SoC 100 that can configure or establish the secure shell 105. In addition to establishing the secure shell 105 and securing data for the tenants (and their roles), the secure shell launcher 140 may perform run-time functions such as receiving tenant keys and unwrapping these keys to form plaintext keys. The secure shell launcher 140 may also perform run-time functions such as generating public-private key pairs and exchanging wrapped public keys with peer tenants on other SoCs. The secure shell launcher may then deposit these keys (plaintext unwrapped or private keys) to the secure shell 105 via a firewalled path. Additionally, the secure shell launcher 140 can generate encrypted and authenticated updates to the secure shell 105 .

[0020] 2 illustrates a system including a SoC 200 coupled to a host or network 205. The SoC 200 may be an IC. The SoC 200 may include programmable logic (PL), hardened circuits, or a combination thereof. In an embodiment, the SoC 200 may be a field programmable gate array (FPGA), an ASIC, a SmartNIC, an acceleration device, a peripheral device, or the like.

[0021] However, in another embodiment, various circuits in SoC 200 may be split into different ICs. For example, secure shell 105 may be in an anchor die (or anchor IC), while memory 135, DTE 220, and processor subsystem 125 may be located in different chiplets (e.g., chiplet ICs) connected to the anchor die on different sides or surfaces.

[0022] The host 205 may be a computing system such as a server. The host 205 is communicatively coupled to the SoC 200 via a connection 210 (e.g., a PCIe connection). If the SoC 200 is connected to a network 205, the network 205 may be a networking switch such as a Top of Rack (TOR) switch. The network 205 is communicatively coupled to the SoC 200 via a connection 210 (e.g., an Ethernet connection). The SoC 200 may be part of an accelerator device or a SmartNIC located on the host 205. In other embodiments, the SoC 200 may be located outside the host 205.

[0023] As illustrated, memory 135 stores encryption keys. These keys are stored separately from tenant portion 110 (i.e., the untrusted island) of SoC 200. Thus, secure shell 105 can prevent tenants from accessing encryption keys stored in memory 135 for other tenants.

[0024] Label 1 in FIG. 2 discusses processor subsystem (PS) 125 unwrapping the encrypted tenant keys. In one embodiment, PS 125 (or a sub-portion of PS 125) may be an authenticated secure boot engine and therefore trusted by the tenants to unwrap (e.g., decrypt) their encrypted keys. In one embodiment, PS 125 may be a central processing unit with any number of processing cores capable of executing software or binaries. Although not shown, PS 125 may execute secure shell launcher 140 in FIG. 1. In one embodiment, the key unwrapping function and the sequence in which the key is unwrapped are services provided by PS 125 or a controller within PS 125. The key may be transmitted from host 205 to PS 125 in an encrypted state. PS 125 may then unwrap (decrypt) the key to a plaintext form.

[0025] The unwrapped key and any associated metadata can be transmitted to Secure Shell Key Storage and Management (labeled 2 in FIG. 2) via a NoC access control path such that only PS 125 has access to the ports at the Secure Shell key and cryptographic state management location. Thus, PS 125 is the only hardware element in SoC 200, external to Secure Shell 105, that can access and modify the unwrapped key stored within Secure Shell 105. Hardware within Secure Shell 105, such as the unwrapped key insertion and access control and the DDR encryption key (which are also considered part of Secure Shell 105), can also access the unwrapped key.

[0026] The Secure Shell key and cipher state management function can perform a number of functions, including receiving unwrapped keys from PS 125 and performing reads / writes to an encrypted and access controlled aperture window in memory 135 (labeled 3 in FIG. 2), which may be a DDR memory. Other defined functions can also be located here, with the same access characteristics. In one embodiment, the encrypted aperture window can only be accessed by Secure Shell 105 via NoC access control paths. These NoC access control paths are illustrated in FIG. 3. In one embodiment, the aperture for memory 135 is set to accept access only from a Secure Shell key and cipher state management source to access keys stored in memory 135.

[0027] Label 4 illustrates unwrapped key insertion and access control, which can insert the unwrapped tenant key into a request or command transmitted to the DTE 220. The access control can issue commands with context IDs for which DTE buffer read / write access is granted by the secure shell 105. FIG. 2 further illustrates that key insertion is performed in the secure shell 105 before data is transmitted to the DTE 220 and ultimately to the host 205. As discussed in FIG. 3, communication between the DTE 220 and the secure shell 105 can be provided by privileged entry points in the NoC. The circuitry in the NoC to provide these privileged entry points can be several orders of magnitude smaller than using access control policy logic. The size of this logic is determined by the size of the access control lists (ACLs), policies for key storage, policies for key rolling and reassignment of keys to context IDs, policies for filtering information sent back to roles, etc.

[0028] Label 12 illustrates the interfaces within DTE 220 for communicating with secure shell 105. In one embodiment, all interfaces for DTE 220 have trusted access to secure shell 105.

[0029] In one embodiment, the differences between the DTE API (Label 6) and the Secure Shell API (Label 5) can be minimized. For example, data communication between a tenant and the Secure Shell 105 can use a capsule definition (Label 5) with a key ID used by the tenant, and data communication between the Secure Shell 105 and the DTE 220 can use a trusted capsule (Label 6). The capsule definition can match the DTE physical interface to the host 205 so that the key is inserted by the Secure Shell 105. Furthermore, the access control overhead is expected to be an order of magnitude larger than the overhead associated with inserting a key into a capsule definition as shown in FIG. 2.

[0030] In one embodiment, secure shell 105 controls the destination tenant ports used by secure shell 105 to communicate data to DTE 220 such that only the issuing tenant ports get the return data (labels 6 and 8). As shown by label 9, secure shell 105 can ensure that Tenant A's data channels are routed only to hardware assigned to Tenant A in tenant portion 110, and Tenant B's data channels are routed only to hardware assigned to Tenant B in tenant portion 110. In one embodiment, labels 5 and 9 illustrate that each tenant (i.e., both Tenant A and Tenant B) has a physically separate port into secure shell 105 such that secure shell 105 can enforce access control on both the issuing and reply paths.

[0031] In one embodiment, the unwrapped keys that are part of the API of DTE 220 for communicating with Secure Shell 105 are issued only by the Unwrapped Key Insertion function (Label 4) of Secure Shell 105. Furthermore, because Secure Shell 105 performs access control at Label 4, no further access control needs to be performed within DTE 220 at the interface indicated by Label 12.

[0032] Label 10 illustrates tightly coupled memory (TCM) in DTE 220. As shown by label 11, PS 125 and secure shell 105 can write to the same index which is expected to be managed as mutually exclusive by TCM management policy. That is, the label sequence from label 1 to label 11 to label 12 to label 10 may be a "live" path for writing to an index in TCM, while at the same time, the label sequence from label 1 to label 2 to label 4 to label 6 to label 12 to label 10 may be another "live" path for writing to potentially the same index in TCM, so that a write in one may conflict with a write in the other. Thus, to prevent such conflicts, there is mutual exclusivity of indexes that can be written via the paths from label 11 to label 12 and from label 6 to label 12.

[0033] 3 illustrates a data path in a NoC 115 in a SoC 300, according to one embodiment. The SoC 300 can be an IC. The SoC 300 can include programmable logic (PL), hardened circuits, or a combination thereof. In one embodiment, the SoC 300 can be a field programmable gate array (FPGA), an ASIC, a SmartNIC, an acceleration device, a peripheral device, etc.

[0034] However, in another embodiment, various circuits in SoC 300 may be split into different ICs. For example, secure shell 105 may be in an anchor die (or anchor IC), while memory 135, DTE 220, and PS 125 may be located in chiplets (e.g., chiplet ICs) connected to the anchor die on different sides or faces. NoC 115 may also be split into different chiplets and anchor die, and NoC data paths may also be connected between the different ICs.

[0035] FIG. 3 illustrates three data paths through NoC 115. Path 1 illustrates a path through NoC 115 between two untrusted entry points in tenant portion 110 (e.g., an untrusted island). This path allows a tenant to still use NoC 115 to transmit data elsewhere in tenant portion 110. For example, a tenant can use NoC 115 to transmit data from a first circuit assigned to the tenant to a second circuit in portion 110 also assigned to the tenant. Both ends of path 1 are untrusted entry points in NoC 115. However, untrusted entry points cannot use the trusted entry points of the NoC, with one exception (path 3). That is, a tenant cannot use an untrusted entry point of NoC 115 within tenant portion 110 to transmit or receive data to a portion of NoC 115 outside tenant portion 110 (e.g., to a trusted entry point to secure shell 105, DTE 220, memory 135, PS 125, etc.).

[0036] Path 2 illustrates a path through NoC 115 between two trusted entry points in secure shell 105. As shown, none of path 2 passes through circuitry in SoC 300 assigned to tenant portion 110. These paths allow circuitry in secure shell 105 and other hardware components in SoC 100 (e.g., DTE 220, PS 125, memory 135, etc.) to communicate with each other, such as the privileged entry points discussed in FIG. 2. Path 2 also allows circuitry in secure shell 105 to use NoC 115 to transmit data to another location in secure shell 105. For example, a function in secure shell can use NoC 115 to transmit data from a first circuit in secure shell to a second circuit also in a different portion of secure shell 105. In this example, path 2 is used to transmit data between circuitry in NoC 115 and crypto engine 315 in DTE. Again, trusted entry points into NoC 115 cannot be used to transmit data to or receive data from untrusted entry points, with the exception shown in path 3.

[0037] Path 3 illustrates a path through NoC 115 between an untrusted entry point in tenant portion 110 (i.e., the untrusted island) and a designated entry point in gatekeeper 305. Gatekeeper 305 serves as an interface (e.g., an API) between the untrusted entry point and the rest of the trusted entry points in NoC 115 (e.g., trusted entry points to secure shell 105 and other trusted components in SoC 300). For example, data in tenant portion 110 must pass through gatekeeper to reach accelerator engine 310 (e.g., network accelerator engine, crypto engine, data compression engine, etc.). FIG. 3 illustrates one gatekeeper 305, but copies of this API circuitry may be located in different locations within secure shell 105.

[0038] Gatekeeper 305 can filter requests from untrusted entry points (e.g., tenants) to ensure that the requests are not fraudulent before forwarding data to another location in secure shell 105 using a trusted entry point. To detect fraudulent requests, in one embodiment, Gatekeeper stores the legitimate ContextIDs that a particular tenant has been allowed to use (e.g., the same ContextID that is later used as a reference to the key index or key used to encrypt / decrypt that tenant's data). Once the data is filtered by Gatekeeper 305, it can access any of the trusted entry points of NoC 115. Furthermore, to access tenant portion 110 from a trusted entry point, the data must also pass through Gatekeeper 305. In one embodiment, untrusted entry points of NoC 115 within tenant portion 110 cannot directly communicate with trusted entry points of NoC 115 outside tenant portion 110, but can indirectly communicate with trusted entry points via Gatekeeper 305.

[0039] To establish rules for the three types of paths shown in FIG. 3, the NoC routing table may be programmed via a secure shell launcher (not shown) in the PS 125 and then locked out from access by the owner (e.g., DC owner or cloud service provider) and tenants of the SoC 300. Thus, an attempt to directly access a trusted entry point from an untrusted entry point in the tenant portion 110 fails because the NoC routing table at the untrusted entry point cannot resolve traffic initiated by an untrusted agent because the physical identifier of the trusted entry point does not exist in the NoC routing table. Similarly, other hardware resources in the SoC 300, such as the processor subsystem 215, the acceleration engine 310, and the DTE 220, may have trusted and untrusted islands within them. Routing of the three types of paths may exist within or between these resources. To establish rules for the three types of routes for these other hardware resources, the configuration of the routing table, gatekeeper, or firewall may also be programmed via a secure shell launcher (not shown) in PS125, which may then be locked out from access by the owner of SoC300, as well as detection by the secure shell launcher of an attempt by a fraudster to modify the routing table or firewall.

[0040] In one embodiment, a hash of the NoC configuration including the routing table is maintained by the secure shell launcher such that attempts by a cheater to modify the routing table are detected through violations of periodic hash results, and a secure lockdown event prevents any sensitive information (e.g., secrets / keys) from being accessed by a cheater.

[0041] FIG. 4 is a flow chart of a method 400 for establishing a secure shell for an untrusted island in a SoC, according to one embodiment. At block 405, the secure shell launcher designates an untrusted island in the SoC. An untrusted island may include circuitry assigned to an entity other than the owner of the SoC. In a data center or cloud computing environment, an untrusted island may include circuitry used by a tenant or role (e.g., a subscriber to the data center or cloud computing environment). For example, a tenant may use the SoC to perform tasks such as data compression, encryption, machine learning / artificial intelligence, etc. Multiple entities (e.g., multiple tenants) may be assigned circuitry within an untrusted island.

[0042] At block 410, the secure shell launcher creates a secure shell around the untrusted island. In one embodiment, the secure shell isolates the sensitive information of the SoC owner and the tenants from each other, as well as the sensitive information of the tenants from each other. Furthermore, the secure shell launcher may be outside the control of the SoC owner. Alternatively, the secure shell launcher may include circuitry that executes cryptographically authenticated binaries or software programs developed by the SoC manufacturer. The secure shell launcher may run on circuitry within the SoC that has been certified by a government agency or other certification authority along with cryptographically authenticated binaries or software programs to establish trust between the SoC manufacturer and the tenant / owner of the SoC. Thus, the tenants may trust the secure shell launcher to establish a secure shell to protect the sensitive information of the tenants from other tenants and the SoC owner, which is discussed in more detail in FIG. 2.

[0043] At block 415, the secure shell launcher generates and locks a NoC routing table to prevent untrusted entry points to the NoC in an untrusted island from directly accessing a trusted entry point in the secure shell. For example, the NoC routing table may establish the NoC path restrictions described in FIG. 3, where an untrusted entry point in a portion of the NoC in a tenant portion (e.g., an untrusted island) can access another untrusted entry point in the NoC (path 1). In one embodiment, two untrusted entry points may have to be in a portion of an untrusted island assigned to the same tenant to prevent one tenant from accessing a portion of an untrusted island assigned to another tenant. Furthermore, two trusted entry points in the NoC that are in a trusted portion of the SoC (e.g., secure shell, PS, DTE, memory, acceleration engine, etc.) can communicate with each other (path 2). However, the NoC routing table prevents an untrusted entry point from directly communicating with a trusted entry point using the NoC.

[0044] However, there is one exception where an untrusted entry point can communicate (indirectly) to a trusted entry point through a gatekeeper. The gatekeeper acts as an interface between the untrusted entry points and the rest of the trusted entry points in the NoC. For example, to reach circuitry in the trusted parts of the SoC (e.g., secure shell, accelerator engines, PS, memory, etc.), data originating from an untrusted island first passes through a gatekeeper. A secure shell can have multiple gatekeepers spread across the SoC.

[0045] The gatekeeper can filter requests from untrusted entry points in an untrusted island to ensure that the request is not malicious before using the trusted entry point to forward the data to another location in the trusted portion of the SoC that uses the NoC. In other words, once the data has been filtered by the gatekeeper, it can be forwarded to any of the trusted entry points of the NoC. Furthermore, in one embodiment, to access an untrusted island from a trusted entry point, the data first passes through the gatekeeper.

[0046] In the foregoing, reference is made to the embodiments presented in this disclosure. However, the scope of the disclosure is not limited to the specific described embodiments. Instead, any combination of the described features and elements, whether related to different embodiments or not, is contemplated for implementing and practicing the contemplated embodiments. Furthermore, the embodiments disclosed herein may achieve other possible solutions or advantages over the prior art, but whether or not a particular advantage is achieved by a given embodiment does not limit the scope of the disclosure. Thus, the above-mentioned aspects, features, embodiments, and advantages are merely illustrative and are not considered elements or limitations of the appended claims unless expressly recited in the claims.

[0047] As will be appreciated by one of ordinary skill in the art, embodiments disclosed herein may be embodied as a system, method, or computer program product. Accordingly, aspects may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, microcode, etc.), or an embodiment combining software and hardware aspects, all of which may be generally referred to herein as a "circuit," "module," or "system." Furthermore, aspects may take the form of a computer program product embodied in one or more computer-readable medium(s) having computer-readable program code embodied therein.

[0048] Any combination of one or more computer readable media may be utilized. The computer readable medium may be a computer readable signal medium or a computer readable storage medium. The computer readable storage medium may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples (non-exhaustive list) of computer readable storage media include an electrical connection having one or more wires, a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the context of this specification, a computer readable storage medium is any tangible medium that can contain or store a program for use by or in connection with an instruction execution system, apparatus, or device.

[0049] A computer-readable signal medium may include a propagated data signal in which computer-readable program code is embodied, for example, in baseband or as part of a carrier wave. Such a propagated signal may take any of a variety of forms, including, but not limited to, electromagnetic, optical, or any suitable combination thereof. A computer-readable signal medium is not a computer-readable storage medium but may be any computer-readable medium that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device.

[0050] The program code embodied on the computer readable medium may be transmitted using any suitable medium, including but not limited to wireless, wireline, fiber optic cable, RF, etc., or any suitable combination of the foregoing.

[0051] Computer program code for carrying out operations of aspects of the present disclosure may be written in any combination of one or more programming languages, including, for example, object-oriented programming languages ​​such as Java, Smalltalk, C++, and conventional procedural programming languages ​​such as the "C" programming language or similar programming languages. The program code may execute completely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer, partially on a remote computer, or completely on a remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer via any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computer (e.g., via the Internet using an Internet Service Provider).

[0052] Aspects of the present disclosure are described below with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments presented in the present disclosure. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general purpose computer, a special purpose computer, or other programmable data processing apparatus such that the instructions, executed via a processor of the computer or other programmable data processing apparatus, result in a machine that creates means for performing the functions / acts specified in the blocks of the flowchart and / or block diagrams.

[0053] These computer program instructions may also be stored on a computer-readable medium, which instructions stored on the computer-readable medium can direct a computer, other programmable data processing apparatus, or other device to function in a particular manner to produce an article of manufacture including instructions that perform the functions / acts specified in the flowchart and / or block diagram blocks.

[0054] Computer program instructions may also be loaded into a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be executed on the computer, other programmable apparatus, or other device to generate a computer-implemented process, such that the instructions executing on the computer or other programmable apparatus provide a process for performing the functions / acts specified in the flowchart and / or block diagram blocks.

[0055] The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in the flowcharts or block diagrams may represent a module, segment, or portion of instructions, including one or more executable instructions for implementing a specified logical function. In some alternative implementations, the functions described in the blocks may occur out of the order described in the figures. For example, two blocks shown in succession may in fact be executed substantially simultaneously, or the blocks may be executed in reverse order, depending on the functionality involved. It should also be noted that each block of the block diagrams and / or flowchart illustrations, as well as combinations of blocks in the block diagrams and / or flowchart illustrations, may be executed by a dedicated hardware-based system that performs the specified functions or acts, or a combination of dedicated hardware and computer instructions.

[0056] The techniques disclosed above can be expressed at least in part through the following non-limiting examples.

[0057] Example 1: A system-on-chip (SoC) comprising: an untrusted tenant portion having a first circuit, the untrusted tenant portion configured to perform tasks for multiple tenants; a secure shell having a second circuit, the untrusted tenant portion configured to function as an interface to enable communication with other circuitry within the SoC; and a secure shell launcher configured to establish a security protocol in the secure shell to protect sensitive information for the multiple tenants.

[0058] Example 2: The SoC of Example 1, further comprising a processor configured to execute a secure shell launcher, wherein the binaries executed by the processor and the secure shell launcher are authenticated to establish a security protocol in the secure shell that prevents an owner of the SoC from accessing sensitive information for multiple tenants.

[0059] Example 3: The SoC of Example 2, wherein the processor is configured to unwrap the encrypted tenant key to form a plaintext key used to encrypt data being transmitted from an untrusted tenant portion to a host coupled to the SoC, the plaintext key being stored in a secure shell.

[0060] Example 4: The SoC of Example 3, wherein the processor is configured to generate, wrap, and transmit to a host coupled to the SoC an encrypted tenant public key used to encrypt data being transmitted to an untrusted tenant portion.

[0061] Example 5: The SoC of example 3, wherein the processor is the only hardware element within the SoC, outside the secure shell, that can access and modify the plaintext key stored in the secure shell.

[0062] Example 6: The SoC of example 1, further comprising a network-on-chip (NoC) that extends through the untrusted tenant portion and the secure shell.

[0063] Example 7: The SoC described in Example 6, wherein the secure shell launcher is configured to generate a NoC routing table to prevent untrusted entry points of a NoC in an untrusted tenant portion from directly communicating with trusted entry points of a NoC outside the untrusted tenant portion.

[0064] Example 8: The SoC of Example 7, further comprising a gatekeeper disposed within the secure shell, wherein the NoC routing table enables untrusted entry points of the NoC to communicate with the gatekeeper, and the gatekeeper is configured to ensure that data received from the untrusted entry point is not malicious, and to forward the received data to a trusted entry point of the NoC within the secure shell.

[0065] Example 9: The SoC of Example 8, wherein the untrusted entry point is configured to transmit data to multiple different untrusted entry points within a NoC within the untrusted tenant portion, but the untrusted entry point can only communicate with portions of the NoC outside the untrusted tenant portion after passing the data through a gatekeeper.

[0066] Example 10: A method comprising: designating an untrusted island within an SoC, the untrusted island comprising circuitry used to perform tasks for an entity other than an owner of the SoC; generating a secure shell around the untrusted island, the secure shell comprising circuitry configured to function as an interface to enable the untrusted island to communicate with other circuitry within the SoC; and generating a NoC routing table to prevent untrusted entry points to a NoC in the untrusted island from directly accessing trusted entry points of the NoC in the secure shell.

[0067] Example 11: The method described in Example 10, wherein generating the secure shell and generating the NoC routing table are performed by a processor within the SoC that is authenticated to establish a security protocol in the secure shell that prevents an owner of the SoC from accessing sensitive information for the entity.

[0068] Example 12: The method of example 11, further comprising using the processor to unwrap an encryption key for the entity to form a plaintext key used to encrypt data being transmitted from the untrusted island to a host coupled to the SoC, the plaintext key being stored in the secure shell.

[0069] Example 13: The method of example 10, further comprising receiving data transmitted by an untrusted entry point at a gatekeeper in the secure shell, ensuring at the gatekeeper that the data received from the untrusted entry point is not malicious, and forwarding the received data by the gatekeeper to a trusted entry point of the NoC in the secure shell.

[0070] Example 14: The method of example 10, wherein generating the NoC routing table includes enabling an untrusted entry point to transmit data to multiple different untrusted entry points for the NoC within the untrusted island.

[0071] Example 15: A SoC comprising: an untrusted island having a first circuit used to perform tasks for an entity other than an owner of the SoC; a secure shell having a second circuit surrounding the untrusted island that prevents the untrusted island from transmitting requests to other hardware elements in the SoC without first passing the request through the secure shell; and a secure shell launcher configured to establish a security protocol in the secure shell to protect sensitive information to the entity.

[0072] Example 16: The SoC of Example 15, further comprising a processor configured to execute a secure shell launcher, wherein the binaries executed by the processor and the secure shell launcher are authenticated to establish a security protocol in the secure shell that prevents an owner of the SoC from accessing sensitive information for the entity.

[0073] Example 17: The SoC of Example 16, wherein the processor is configured to unwrap the encrypted entity key to form a plaintext key used to encrypt data being transmitted from an untrusted island to a host coupled to the SoC, the plaintext key being stored in a secure shell.

[0074] Example 18: The SoC of example 17, wherein the processor is the only hardware element within the SoC, outside the secure shell, that can access and modify the plaintext key stored in the secure shell.

[0075] Example 19: The SoC of Example 15, further comprising a NoC extending through an untrusted island and a secure shell, wherein the secure shell launcher is configured to generate a NoC routing table to prevent untrusted entry points of NoCs in the untrusted island from directly communicating with trusted entry points of NoCs outside the untrusted island.

[0076] Example 20: The SoC of Example 19, further comprising a gatekeeper disposed within the secure shell, wherein the NoC routing table enables untrusted entry points of the NoC to communicate with the gatekeeper, and the gatekeeper is configured to ensure that data received from the untrusted entry point is not malicious, and to forward the received data to a trusted entry point of the NoC within the secure shell.

[0077] While the above is directed to specific examples, other and further examples may be devised without departing from the basic scope thereof, which is determined by the following claims.

Claims

1. A system on chip (SoC), comprising: an untrusted tenant portion comprising a first circuit, the untrusted tenant portion configured to perform tasks for a plurality of tenants; a secure shell comprising a second circuit, the secure shell configured to act as an interface to enable the untrusted tenant portion to communicate with other circuits within the SoC; a secure shell launcher configured to establish a security protocol in the secure shell to protect sensitive information for the plurality of tenants.

2. 2. The SoC of claim 1, further comprising a processor configured to execute the secure shell launcher, wherein the processor and binaries executed by the secure shell launcher are authenticated to establish a security protocol in the secure shell that prevents an owner of the SoC from accessing the sensitive information for the multiple tenants.

3. 3. The SoC of claim 2, wherein the processor is configured to unwrap an encrypted tenant key to form a plaintext key used to encrypt data being transmitted from the untrusted tenant portion to a host coupled to the SoC, the plaintext key being stored in the secure shell.

4. 4. The SoC of claim 3, wherein the processor is configured to generate, wrap, and transmit to a host coupled to the SoC an encrypted tenant public key used to encrypt data being transmitted to the untrusted tenant portion.

5. 4. The SoC of claim 3, wherein the processor is the only hardware element within the SoC, outside the secure shell, that can access and modify the plaintext key stored in the secure shell.

6. A SoC, an untrusted island comprising a first circuit used to perform tasks for an entity other than an owner of the SoC; a secure shell comprising a second circuit surrounding the untrusted island that prevents the untrusted island from transmitting requests to other hardware elements in the SoC without first passing the requests through the secure shell; a secure shell launcher configured to establish a security protocol in the secure shell to protect sensitive information for the entity.

7. 7. The SoC of claim 6, further comprising a processor configured to execute the secure shell launcher, wherein the processor and binaries executed by the secure shell launcher are authenticated to establish a security protocol in the secure shell that prevents the owner of the SoC from accessing the sensitive information for the entity.

8. 8. The SoC of claim 7, wherein the processor is configured to unwrap an encrypted entity key to form a plaintext key used to encrypt data being transmitted from the untrusted island to a host coupled to the SoC, the plaintext key being stored in the secure shell.

9. 9. The SoC of claim 8, wherein the processor is the only hardware element within the SoC, outside the secure shell, that can access and modify the plaintext key stored in the secure shell.

10. The SoC of claim 1 or 6, further comprising a network-on-chip (NoC) that extends through the untrusted tenant portion and the secure shell.

11. 11. The SoC of claim 10, wherein the secure shell launcher is configured to generate a NoC routing table to prevent untrusted entry points of the NoC within the untrusted tenant portion from directly communicating with trusted entry points of the NoC outside the untrusted tenant portion.

12. a gatekeeper disposed within the secure shell, the NoC routing table enabling the untrusted entry points of the NoC to communicate with the gatekeeper; The gatekeeper comprises: Ensuring that data received from the untrusted entry point is not malicious; The SoC of claim 11 , configured to forward the received data to the trusted entry point of the NoC within the secure shell.

13. 13. The SoC of claim 12, wherein the untrusted entry point is configured to transmit data to a plurality of different untrusted entry points within the NoC within the untrusted tenant portion, but the untrusted entry point can communicate with a portion of the NoC outside the untrusted tenant portion only after passing the data through the gatekeeper.

14. 1. A method comprising: Designating an untrusted island within a SoC, the untrusted island comprising circuitry used to perform tasks for an entity other than an owner of the SoC; creating a secure shell around the untrusted island, the secure shell comprising circuitry configured to act as an interface to allow the untrusted island to communicate with other circuitry within the SoC; generating a NoC routing table to prevent untrusted entry points to a NoC in the untrusted island from directly accessing trusted entry points of the NoC in the secure shell.

15. receiving data transmitted by the untrusted entry point at a gatekeeper within the secure shell; ensuring, at the gatekeeper, that the data received from the untrusted entry point is not malicious; forwarding, by the gatekeeper, the received data to the trusted entry point of the NoC within the secure shell; The method of claim 14 further comprising:

Images