Enclave architecture

Abstract

A method of operating a computer system (2) to manage a set of registered service enclaves (6a, 6b, 6c, 6d, 6e, 6f) includes registering a new service enclave (10) into the set of registered service enclaves. A management institution service (6b) hosted on a first computing device (4b) receives an identifier (14) of a second computing device (12) hosting a new service enclave (10). The management institution service (6b) receives, from the second computing device (12), a proof (16) of software code stored in the new service enclave (10) using the identifier (14). In response, the management mechanism service (6b) generates a certificate associating the identifier (14) with the public key of the new service enclave (10) and provides the certificate to the registered service enclaves (6a, 6c, 6d, 6e, 6f).

Description

Background Art

[0001] The present invention relates to a secure computer system and an operating method thereof.

[0002] A microservices architecture may be used to enable manageable deployment of one or more services using a networked computer system architecture that includes multiple independent, self-contained components (e.g., having independent processors and / or software applications), each component having well-defined roles and interfaces.

[0003] Advantageously, due to the modular nature of the components, microservices architectures can be relatively straightforward to deploy, operate, update, and scale (e.g., by registering new service components) compared to monolithic architecture approaches. The components of a microservices architecture can also be spatially distributed, and such microservices architectures can also be particularly suitable for deployment in cloud-based applications, where they can provide good responsiveness and high resilience to failures.

[0004] Although each component of a microservices architecture can operate substantially independently, it is often necessary for components to communicate with each other, such as to direct the execution of one or more tasks or to share data to be processed.

[0005] However, the division of responsibilities for providing services and the need for multiple communication channels between components means that ensuring the security of a microservices system can be challenging. Users of a traditional microservices architecture may be required to trust the provider of the architecture, that the components are operating as expected (e.g., not maliciously), and it may be difficult or impossible to determine that this trust is well-placed.

[0006] Applicants have recognized that in order to improve the security of microservices architectures, it is desirable for such systems to be more transparently trustworthy.

[0007] Embodiments of the present invention attempt to address this challenge. Summary of the invention

[0008] From a first aspect, the present invention provides a method of operating a computing system to manage a set of registered service enclaves, wherein the system comprises:

[0009] a network of computing devices;

[0010] a plurality of service enclaves hosted on one or more of the computing devices of the network; and

[0011] An authority service hosted on a first computing device of a network; the method comprising registering a new service enclave from a plurality of service enclaves hosted on a second computing device of the network into the set of registered service enclaves by:

[0012] The authority service receives an identifier of a second computing device hosting a new service enclave;

[0013] The authority service receives, from the second computing device, an attestation of the software code stored in the new service enclave using the identifier of the second computing device;

[0014] In response to receiving the attestation, the authority service generates a certificate associating an identifier of the second computing device with a public key of the new service enclave; and

[0015] The authority service provides the certificate to the registered service enclaves of the plurality of service enclaves.

[0016] When viewed from another aspect, the invention provides a computer system comprising an authority service hosted on a first computing device, the authority service configured to register a new service enclave from a plurality of service enclaves hosted on one or more computing devices of a network of computing devices into a set of registered service enclaves by:

[0017] receiving an identifier of a second computing device of the network hosting the new service enclave;

[0018] receiving, from the second computing device, an attestation of the software code stored in the new service enclave using the identifier of the second computing device;

[0019] In response to receiving the attestation, generating a certificate associating an identifier of the second computing device with a public key of the new serving enclave; and

[0020] The certificate is provided to a registered service enclave of the plurality of service enclaves.

[0021] When viewed from another aspect, the present invention provides computer software which, when executed on a first computing device of a network of computing devices, causes the first computing device to host an authority service, the authority service being configured to register a new service enclave from a plurality of service enclaves hosted on one or more computing devices of the network of computing devices into a set of registered service enclaves by:

[0022] receiving an identifier of a second computing device of the network hosting the new service enclave;

[0023] receiving, from the second computing device, an attestation of the software code stored in the new service enclave using the identifier of the second computing device;

[0024] In response to receiving the attestation, generating a certificate associating an identifier of the second computing device with a public key of the new serving enclave; and

[0025] The certificate is provided to a registered service enclave of the plurality of service enclaves.

[0026] Thus, it will be seen that according to an embodiment of the present invention, the certification of the authority service binds the public key of the certified new service enclave to the identifier of the computing device hosting the new enclave. This allows the existing service enclave to trust the new service enclave and communicate securely with the new service enclave through the computing device hosting the new service enclave.

[0027] The authority service can thus act as a single point of trust to help convince users that the system as a whole (i.e., each of the multiple service enclaves) is configured to operate as expected. This means that users are not required to directly verify the configuration of each service enclave (although in some embodiments, they may still do so if they wish), but rather can verify the trustworthiness of the authority service. The authority service can be configured to confirm that it is running trusted software code (e.g., that has been independently certified as secure), which can help users assure themselves that the authority service is trustworthy and properly certifies the service enclaves of the system. For example, the software run by the authority service can be open source and / or auditable by an independent authority.

[0028] Allowing users to place their trust in only a single authority, rather than multiple service enclaves, allows the system to be scaled up without imposing any additional burden on users. Instead, the system can be scaled to include any number of enclaves as long as users can trust that the authority services are operating as expected. This microservices architecture also allows the software of the service enclave to be updated without requiring users to re-evaluate whether the updated enclave can be trusted.

[0029] Each computing device may be a respective server or workstation. It may have its own independent connection to the network. Each may include memory and a processor configured to provide a trusted execution environment (TEE). Each may be configured to securely decrypt and execute software instructions stored, encrypted, in an enclave of the device. Each may store one or more enclave-specific cryptographic key pairs.

[0030] In some embodiments, the computer system includes one or more computing devices hosting a plurality of service enclaves. Each of the plurality of service enclaves is preferably a trusted execution environment (TEE) enclave. The TEE enclave may be provided by an Intel processor supporting Software Guard Extensions (SGX), or an Arm processor supporting TrustZone, or any other processor configured to provide a TEE.

[0031] Each computing device of the network of computing devices is preferably configured to establish an encrypted and authenticated channel - e.g., a Transport Layer Security (TLS) network connection - with one or more other computing devices of the network of computing devices. The first computing device is preferably configured to establish an encrypted and authenticated channel (e.g., a TLS connection) with the second computing device. The first computing device may also be configured to establish an encrypted and authenticated channel (e.g., a TLS connection) with one or more other computing devices of the network of computing devices.

[0032] The authority service may be provided by an authority enclave hosted on the first computing device. The authority service may be configured to provide the certificate over any communication channel. The authority service may be configured to provide the certificate directly to the already registered service enclave. However, the authority service may be configured to provide the certificate to the already registered service enclave via one or more intermediary devices. The authority service may provide the certificate to multiple or all of the already registered service enclaves (i.e., those service enclaves that were in the set of registered service enclaves when the certificate was generated) of the plurality of service enclaves.

[0033] The authority service is preferably associated with a unique key pair, the unique key pair comprising a public key and a private key. Each registered service enclave is preferably associated with a unique key pair. Preferably, the public key of each enclave is known to one or more (e.g., all) registered service enclaves and the authority service. It will be appreciated that communications signed using the private key of a key pair can be verified as having been signed by the owner of the private key using the public key. Using key pairs in this manner can facilitate verification of the source of communications between enclaves, thereby helping to increase the security of the system.

[0034] Preferably, the authority service is configured to sign the certificate using a private key of a key pair associated with the authority service. Each of the registered service enclaves that receives the certificate may be configured to authenticate the certificate using the authority service's public key. As described above, this allows the registered service enclaves to verify the source of the certificate.

[0035] The authority service may be configured to implement one or more policies for the system. The one or more policies may include a maximum number of service enclaves that may be registered at one time. The one or more policies may be defined by policy data stored in the system. In some embodiments, the policy data is stored in the first computing device. In some embodiments, the policy data is stored in a database of the network. The policy data may be static. However, in some embodiments, the policy data is dynamically configurable, for example, by an administrator.

[0036] In some embodiments, (e.g., after having received the certificate), each of the registered service enclaves is configured to send encrypted data to the new service enclave using the public key of the new service enclave. Preferably, each registered service enclave is allowed to communicate with the new service enclave only after receiving (e.g., and authenticating) a certificate generated by the authority service. This helps ensure that the registered enclave can only communicate with the new enclave once the authority service has confirmed (by issuing a certificate) that the new enclave is operating as expected and is therefore likely to be secure.

[0037] In some embodiments, the new service enclave is configured to generate an attestation report. The attestation report may include a hash of the software code stored in the new service enclave. The attestation report preferably includes the public key of the new service enclave and / or the public key of the authority service.

[0038] Each computing device of the network of computing devices may have a respective identifier. The identifier of the second computing device (and / or each computing device) may include any suitable identifier unique within the system. The identifier may include a network address of the computing device. The identifier may include a processor ID.

[0039] Preferably, the registered service enclave (or each registered service enclave) is configured to store configuration data. The configuration data may include a respective identifier of each service enclave in a plurality of registered service enclaves.

[0040] In some embodiments, the configuration data includes one or more communication rules. Preferably, the configuration data (e.g., the communication rules of the configuration data) indicates whether a service enclave of a first type is authorized to communicate with a service enclave of a second type. A registered service enclave (or each of the registered service enclaves) is preferably configured to use the configuration data (e.g., the communication rules of the configuration data) to determine whether to receive and process communications from another service enclave. This may provide an additional layer of restriction on communications between enclaves, thereby helping to further increase the security of the system. For example, the communication rules may restrict communications between devices to those devices whose network addresses are all within a single country or organization.

[0041] In some embodiments, the configuration data includes a database access password for accessing a database of the network. The database may include information related to the digital identity of one or more users of the computing system. The digital identity may include an email address or the name of an Internet account associated with the user. A user may be associated with multiple digital identities. As described below, this may allow a user to interact with the computing system using an account associated with the established digital identity, rather than requiring the user to create a new digital identity for use with the computing system, the established digital identity itself being associated with the user. This may help reduce the anonymity of the user, thereby increasing the user's responsibility for their interaction with the system, which may improve the security of the system as a whole.

[0042] Preferably, the authority service is configured to store configuration data. In some embodiments, the configuration data includes policy data defining one or more policies that the authority service is configured to implement, for example, as discussed above. In some embodiments, the authority service is configured to provide the configuration data to the new service enclave. The authority service is preferably configured to provide the configuration data to the new service enclave only after the certificate is generated. This helps ensure that only service enclaves that have been certified and therefore registered with the authority service are allowed to access the system's configuration data.

[0043] In some embodiments, the configuration data includes expected measurement data for verifying the attestation of one or more already registered enclaves of the network. The attestation may include a hash of software code stored in the or each already registered service enclave. The expected measurement data may include a pre-configured hash of software code that the already registered service enclave is expected to store. Preferably, the new service enclave is configured to use the expected measurement data to attest to one or more already registered enclaves of the network. In some embodiments, the new service enclave is configured to compare the hash of software code stored in the already registered service enclave with the expected measurement data corresponding to the already registered service enclave.

[0044] The configuration data is preferably signed by a certification authority. In some embodiments, the certification authority may be considered part of the computing system disclosed herein, or it may be separate. Preferably, the certification authority is associated with a key pair comprising a private key and a public key. The configuration data may be signed using the private key of the certification authority. In some embodiments, the new service enclave is configured to authenticate the configuration data using the public key of the certification authority. The certification authority is preferably offline, i.e., not communicatively connected to the computing device's network. The offline certification authority is preferably isolated from the computing device's network. The configuration data may be transmitted to the authority service via a non-network channel (e.g., by movement of a physical storage medium).

[0045] Each of the registered service enclaves may be configured to receive new software code for execution in the registered service enclave. This allows the software running in each service enclave to be updated. Preferably, the new software code is signed using the private key of the certification authority. Preferably, the registered service enclave (or each registered service enclave) is configured to authenticate the new software code using the public key of the certification authority before executing the new software code in the registered service enclave. It will be appreciated that this allows the registered service enclave to verify the source of the software code before it is executed, thereby helping to improve the security of the system.

[0046] In some embodiments, the authority service is configured to provide certificates only to a subset of the plurality of service enclaves. The authority service may be configured to identify the subset of the plurality of service enclaves using one or more communication rules stored by the authority service. As described above, each already registered service enclave is preferably permitted to communicate with the new service enclave only after receiving (and preferably authenticating) a certificate generated by the authority service. In such embodiments, the communication rules may be implemented by withholding certificates associated with the new service enclave from the subset of service enclaves with which the new service enclave is not permitted to communicate. The communication rules may be stored in configuration data stored by the authority service.

[0047] The authority service is preferably configured to authenticate itself to the new service enclave (e.g., before registering the new service enclave). Thus, preferably, the new service enclave is configured to receive from the authority service an authentication of the software code stored in the authority service.

[0048] The computer system preferably also includes a gateway enclave. It may be hosted by a gateway computing device of the network. The gateway enclave is preferably arranged to provide an access point to users of the system, for example so that a user can interact with the gateway enclave to instruct a service enclave (via the gateway enclave) to perform one or more services for or on behalf of the user. Preferably, the gateway enclave is the only enclave of the computing system with which a user can interact (i.e. directly). In some embodiments, the gateway computing device may be the only computing device in the network with a public network address (e.g., with a public IP address on the Internet).

[0049] The gateway enclave is preferably configured to receive and / or send an attestation of the authority service to the client computing device. It may also be configured to receive and / or send an attestation of each registered service enclave in the set of registered service enclaves to the client computing device. This allows the user to receive an attestation of the system as a whole via the gateway enclave. The authority service itself may authenticate to the user that each registered service enclave is trustworthy; however, it should be understood that some embodiments may provide a further level of confidence by each registered service enclave being configured to send a respective attestation to the user (via the gateway enclave), e.g., in addition to the attestation provided by each service enclave to the authority service during its registration.

[0050] The gateway enclave is preferably configured to receive a service request from a client computing device. The service request may be a request for one or more of the service enclaves to perform a service. Preferably, in response to receiving the request, the gateway enclave is configured to instruct an already registered enclave to perform the requested service.

[0051] In some embodiments, the system includes a client computing device. The client computing device may include a smartphone, a tablet computer, or a personal computer.

[0052] In some embodiments, the gateway enclave is configured to receive a credential of a client computing device. The gateway enclave is preferably configured to receive the credential from the client computing device. The gateway enclave may be configured to verify the credential of the client computing device. Preferably, the gateway enclave is configured to verify the credential of the client computing device before instructing the registered enclave to perform the requested service. The gateway enclave may be configured to ignore the service request in response to a failure to verify the credential of the client computing device.

[0053] In some embodiments, the client computing device is configured to receive a certificate of the gateway enclave. The client computing device is preferably configured to receive the certificate from the gateway enclave. The client computing device is preferably configured to verify the certificate of the gateway enclave.

[0054] The gateway enclave and the authority service may be hosted on separate computing devices. However, in some embodiments, both the authority service and the gateway enclave are hosted on a first computing device. This may help increase the ease of implementing the authority service and the gateway enclave.

[0055] In some embodiments, the computing system includes an account manager service enclave. The account manager service enclave may be configured to generate a binding between an account credential of a user of the system and digital identity data corresponding to the user. The gateway enclave may be configured to verify the account credential of the user in response to receiving a service request from the user. The gateway enclave may be configured to compare the account credential provided by the user to a whitelist of account credentials stored in the configuration data to determine whether to process the service request.

[0056] In some embodiments, the computing system includes a signer enclave. The signer enclave may be configured to bind a user's account credentials to a virtual currency wallet. The signer enclave is preferably configured to bind a user's account credentials to a cryptographic transaction signing key pair. In some embodiments, the computing system includes a keystore enclave configured to store the user's cryptographic transaction signing key pair. The signer enclave is preferably configured to sign virtual currency transactions on behalf of the user. The signer enclave is preferably configured to sign transactions on behalf of the user according to one or more transaction signing policies associated with the user.

[0057] Preferably, at least two of the computing devices of the network have different respective processor architectures and / or computer architectures (e.g., different hardware and / or operating systems). Each processor or computing system may be manufactured by a different respective manufacturer (such as Intel Corporation). TM 、Arm Limited TM ) and / or may be manufactured by different corresponding operators (e.g. Amazon Web Services (AWS) TM This can help provide greater robustness and protection against attacks (such as side-channel attacks) because the likelihood of a single type of attack being successful against each computing device can be significantly reduced due to variations in processor architecture.

[0058] Any enclave that receives a certificate from another enclave will preferably verify the received certificate (e.g., using an appropriate public key) and will enter and / or signal an error state if verification fails.

[0059] Features of any aspect or embodiment described herein may, where appropriate, be applied to any other aspect or embodiment described herein.

[0060] When reference is made to different embodiments or sets of embodiments, it should be understood that these embodiments are not necessarily different and may overlap. BRIEF DESCRIPTION OF THE DRAWINGS

[0061] Certain embodiments of the invention will now be described, by way of example only, with reference to the accompanying drawings, in which:

[0062] Figure 1 is a schematic diagram of a computing system and its users according to an embodiment of the present invention;

[0063] Figure 2 is a schematic diagram of a computing device for use in embodiments of the present invention; and

[0064] Figure 3 is a flow chart for registration of a new service enclave according to an embodiment of the present invention. DETAILED DESCRIPTION

[0065] Figure 1 A computing system 2 according to an embodiment of the present invention is shown.

[0066] The system 2 includes a network 5 of computing devices 4a, 4b, 4c, 4d, each of which is configured to host at least one respective trusted execution environment (TEE) enclave 6a, 6b, 6c, 6d, 6e, 6f. Each TEE enclave 6a-6f is configured to run software code to provide a respective service in a set of microservices. The TEE enclaves 6a-6f together form a set of registered service enclaves 6. The TEE enclaves 6a-6f each store an enclave-specific cryptographic key pair and are each configured to generate an attestation report to attest to the respective software code they are running.

[0067] The network 5 may provide any number of wired and / or wireless communication channels 23 between the computing devices 4a, 4b, 4c, 4d and optionally with additional computer devices (e.g., computing device 12). The network 5 may be a dedicated physical network, or it may be provided at least in part over the Internet (e.g., as a virtual private network). Each device on the network 5 has a unique network address (e.g., a unique MAC address and / or IP address).

[0068] Figure 2An exemplary computing device 4 (e.g., as any of computing devices 4a, 4b, 4c, 4d) that can be used in system 2 is shown. It can be a server (e.g., a computer located in a server farm). It has a processor 41 connected to a memory 42 (e.g., DRAM) and a network interface 43 via a bus system 47. The processor 41 supports a trusted execution environment (TEE). It can implement Intel Software Guard Extensions (SGX) or Arm TrustZone. In addition to supporting conventional untrusted software code 43 and associated data 44 stored in memory 42, the processor 41 also has hardware mechanisms to support a secure boot process, remote attestation, and secure execution of code stored encrypted in one or more enclaves 45, 46 within memory 42. Each enclave 45, 46 is an area of ​​memory 42 that stores encrypted code and associated encrypted data, which is transmitted on the bus 47 in encrypted form and is only decrypted within the processor 41. The integrity of the data and software in the enclave can be verified at boot time, for example using a public key infrastructure (PKI) mechanism, and the TEE can protect the code and data of each enclave 45, 46 from malicious or unintentional damage or attack. The network interface 43 can be communicatively coupled to a local area network (LAN) and / or a wide area network (WAN) including the Internet. The device 4 can be configured for encrypted and authenticated communications with other devices of the system 2 through the network interface 43, for example using transport layer security (TLS).

[0069] Re-reference Figure 1 , the front-end gateway device 4a of the network 5 of computing devices 4a, 4b, 4c, 4d is configured to communicate with entities external to the system 2 (such as Figure 1 , which may be a smartphone, tablet, or personal computer). The communication may be conducted over the Internet. The front-end gateway device 4a is the only device 4a in the network 5 of computing devices 4a, 4b, 4c, 4d that is able to communicate directly with an external entity such as the client device 8. A user 9 may use an application running on the client device 8 to send a request to execute a service in the microservice set to one or more of the service enclaves 6 via the gateway device 4a. The front-end gateway device 4a is configured to host the front-end gateway enclave 6a.

[0070] The client device 8 can verify the attestation of the software code of the front-end gateway enclave 6a in order to assure the user 9 that the front-end gateway enclave 6a is executing the correct (i.e., expected) code. The front-end gateway enclave 6a verifies the attestation of the other registered service enclaves 6 (i.e., they are securely booted and are executing the expected software code) and can therefore confirm to the user 9 that the system 2 is in the expected state, i.e., the front-end gateway enclave 6a and all other registered service enclaves 6 are in the correct state and are running the expected software code. Thus, the entire system 2 is effectively and conveniently attested to the user 9 by the front-end gateway device 4a.

[0071] The authority service device 4b of the network 5 of computing devices 4a, 4b, 4c, 4d is configured to host an authority service enclave 6b. The authority service enclave 6b has an associated public and private key pair, the public key of which is known to all enclaves 6 and users 9 of the system 2.

[0072] The role of the authority service enclave 6b is to register new service enclaves into the set of registered service enclaves 6 in a trusted manner. The authority service enclave 6b registers the new service enclave and generates certificates to guarantee the identity and trustworthiness of the new service enclave to the other registered enclaves 6, including the front-end gateway enclave 6a. In this way, the authority service enclave 6b can ensure the continued trustworthiness of the microservice system 2 as a whole, even when new service enclaves are added to it.

[0073] Figure 1 An exemplary new service enclave 10 to be registered in the set of registered service enclaves 6 is shown. It may provide the same microservices as one of the already registered service enclaves 6 (e.g., to provide greater resilience to the network 5 in the event of hardware failures, or to provide better geographic coverage for the set of microservices provided by the system 2), or it may provide an updated version of an existing type of microservice, or it may provide an entirely new type of microservice within the set of microservices. Figure 2 The registration process is described in more detail. The new service enclave 10 is hosted on a computing device 12 (which may be a Figure 2 The new service enclave 10 stores a unique private key and public key pair and is configured to generate an attestation report 16 to attest to the software code stored in the new service enclave 10.

[0074] The authority service enclave 6b acts as a single point of trust for the user 9, which means that the user 9 is not required to directly verify the operation of each service enclave 6. Instead, since a service enclave 6 must be authenticated by the authority service enclave 6b before being allowed to communicate with other service enclaves 6 (and thus become part of the system 2), the user 9 can effectively delegate the burden of ensuring that each enclave 6 operates correctly to the authority service enclave 6b. By certifying that each service enclave 6 operates as expected, the operation and security of the system 2 as a whole can be established by the user 9 with the help of the trustworthiness of the authority service enclave 6b, which can be demonstrated to the user through the attestation of the front-end gateway enclave 6a.

[0075] The authority service enclave 6b runs software code that can be audited by the user 9 or by an independent audit authority, which can help the user 9 ensure that the authority service enclave 6b properly authenticates the service enclave 6 of the system 2.

[0076] The authority services enclave 6 b is also configured to communicate with an offline certification authority (CA) 20 that stores configuration data 22 of the system 2 .

[0077] The offline certification authority 20 has an associated CA private-public key pair, whose public key is provided out-of-band to the user 9. The CA public key is also stored in each enclave 6 that has registered. The CA private key is only known to the offline certification authority (CA) 20.

[0078] Configuration data 22 includes the network address of each of computing devices 4a, 4b, 4c, 4d registered in system 2. Configuration data 22 is signed using the CA private key, which means that each enclave 6 that has registered can authenticate configuration data 22 using the CA public key.

[0079] The authority service enclave 6b receives configuration data 22 from the offline certification authority 20 in an offline communication 21 (e.g., on a portable USB memory device physically transferred to the authority service device 4b by an engineer). Once the authority service enclave 6b has received the configuration data 22 and is connected to the network 5, the authority service enclave 6b sends the configuration data 22 to each registered service enclave 6. Each registered service enclave 6 authenticates the configuration data 22 using the CA public key.

[0080] The configuration data 22 also includes communication rules that indicate which registered service enclaves 6 are allowed to communicate with which other registered service enclaves 6. As described below, registered service enclaves 6 (except for the authority enclave 6b) are generally blocked from communicating with unregistered enclaves, such as the new service enclave 10. However, the communication rules of the configuration data 22 provide an additional layer of restrictions on communications between enclaves, thereby helping to further improve the security of the system 2.

[0081] When receiving a communication from a service enclave where the source is registered, the service enclave 6 where the recipient is registered determines whether to process the communication using the communication rules stored in the configuration data 22. If the communication rules of the configuration data 22 prohibit communication with the source service enclave for the recipient service enclave, the communication is ignored.

[0082] The system 2 also includes a database 24 (e.g., a dedicated database server of the network 5) that the registered service enclaves 6 can access using the network address and database access password of the database 24. The network address and database access password of the database 24 are stored in the configuration data 22.

[0083] The database 24 may store data for the system 2 as a whole and for each user 9 and / or client device 8 that interacts with the system 2. The database 24 also stores policy data that the authority service enclave 6b can access. The policy data can be configured by an administrator of the system 2 and defines one or more policies that the authority service 6b implements, including the maximum number of service enclaves 6 that can be registered in the system 2 at one time. The data stored on the database 24 may change and / or grow over time.

[0084] For each registered service enclave 6 , the configuration data 22 also includes a pre-configured hash of the respective software code that the respective registered service enclave 6 is expected to store.

[0085] The network 5 of computing devices 4a, 4b, 4c, 4d also comprises an account manager device 4c, which hosts an account manager enclave 6c. The purpose of the account manager enclave 6c is to enroll users 9 by issuing account certificates signed using the private key of the account manager enclave 6c.

[0086] The configuration data 22 includes a whitelist of account credentials identifying users 9 that have been registered by the account manager enclave 6 c and are therefore authorized to request services to be performed by the service enclave 6 .

[0087] In order to connect to the front-end gateway enclave 6a, the user 9 is required to present their account credentials (e.g., which may be stored on the user 9's personal device 8), which are checked by the front-end gateway enclave 6a using a whitelist stored in the configuration data 22.

[0088] The account manager enclave 6c also stores a binding between each user's 9 account credentials and corresponding digital identity data, which may include details of one or more of the user's 9 internet accounts (e.g. email or social media). The digital identity data is stored in the database 24 of the system 2 and can only be accessed by the account manager enclave 6c. The binding is stored by the account manager enclave 6c and can only be accessed and modified by the account manager enclave 6c.

[0089] The network 5 also includes a signer device 4d, which hosts a signer enclave 6d. The signer enclave 6d binds each user 9's account certificate to a corresponding virtual currency wallet and is responsible for storing and managing the user 9's virtual currency wallet, including signing transactions on behalf of the user 9 according to the stored transaction signing policy. The corresponding transaction signing policy is specific to and associated with each user's account certificate. The signer enclave 6d also stores a corresponding management policy for each wallet, which defines how to allow updates to the transaction signing policy.

[0090] Other service enclaves 6e, 6f, 10 may provide any desired microservices to users 9 of the system. These microservices may interact or collaborate with each other and / or with the signing services of the signed enclave 6d, for example, to provide a larger service offering. However, in some embodiments, the set of microservices provided by the system 2 includes a number of different services.

[0091] Figure 3 A flow chart is shown for registering a new service enclave 10 by an authority service enclave 6b according to an embodiment of the present invention.

[0092] In a first step S100, the new service enclave 10 generates an attestation report 16 attesting to the software stored in the new service enclave 10. The computing device 12 hosting the new service enclave 10 establishes a TLS connection with the authority service device 4b and then sends the attestation report 16 to the authority service enclave 6b via the network 5. The attestation report 16 is signed by the new service enclave 10 using the private key of the new service enclave 10. The attestation report 16 includes the public key of the new service enclave 10.

[0093] The authority services enclave 6b receives the attestation report 16 from the network address 14 of the device 12. The authority services enclave 6b may be required to provide attestation of the software code running on the authority services enclave 6b to the new services enclave 10, for example as a preliminary step to receiving the attestation report 16 from the new services enclave 10.

[0094] In response to receiving the attestation report 16, the authority service enclave 6b verifies the attestation report 16 and generates a certificate associating the public key of the new service enclave 10 with the network address 14 of the device 12 in step S102. The certificate 18 is signed using the private key of the authority service enclave 6b and provided by the authority service enclave 6b to each of the other registered service enclaves 6 (step S104).

[0095] After receiving the certificate, the registered service enclave 6 uses the public key of the authority service enclave 6b to authenticate the certificate 18. If the authentication is successful, the registered service enclave 6 can trust the new service enclave 10 and thereafter exchange encrypted data with the new service enclave 10 using the public key of the new service enclave 10 and the network address 14 of the device 12. Otherwise, if a successful authentication does not occur, the registered service enclave 6 is prevented from communicating with the new service enclave 10. This helps ensure that only properly authenticated enclaves are allowed to interact with the registered service enclave 6, thereby improving the security of the system 2.

[0096] In step S106, the authority enclave 6b sends the configuration data 22 of the system 2 to the new service enclave 10. In step S108, the new service enclave 10 authenticates the configuration data 22 using the public key of the offline authentication authority 20 pre-stored in the memory of the new service enclave 10.

[0097] In step S108, each of the other registered service enclaves 6 uses the network address 14 of the device 12 to send a corresponding attestation to the new service enclave 10, wherein the attestation includes a hash of the software code being executed by the corresponding registered service enclave 6.

[0098] In response to receiving each attestation, the new service enclave 10 compares the received hash with the corresponding hash of the expected software code stored in the configuration data 22 to verify each received attestation (step S112). This allows the new service enclave 10 to verify that each registered service enclave 6 is operating as expected, thereby further improving the security of the system 2.

[0099] In this way, the system 2 can be efficiently expanded while still allowing the user 9 to trust the system 2.

[0100] It will be appreciated by those skilled in the art that the invention has been illustrated by describing one or more specific embodiments thereof, but the invention is not limited to these embodiments; many variations and modifications are possible within the scope of the appended claims.

Claims

1. A method of operating a computing system to manage a set of registered service enclaves, wherein the system comprises: a network of computing devices; a plurality of service enclaves hosted on one or more of said computing devices of said network; as well as an authority service hosted on a first computing device of the network; the method comprising registering a new service enclave from among the plurality of service enclaves hosted on a second computing device of the network into the set of registered service enclaves by: receiving, by the authority service, an identifier of the second computing device hosting the new service enclave; receiving, by the authority service, from the second computing device, attestation of software code stored in the new service enclave using the identifier of the second computing device; In response to receiving the attestation, the authority service generates a certificate associating the identifier of the second computing device with a public key of the new service enclave; and the authority service providing the certificate to a registered service enclave among the plurality of service enclaves.

2. The method according to claim 1, further comprising: The registered service enclave authenticates the certificate using the public key of the authority service; as well as The already registered service enclave uses the public key of the new service enclave to send encrypted data to the new service enclave.

3. The method according to claim 1 or 2, comprising the new service enclave generating a certification report including the public key of the new service enclave and / or the public key of the authority service.

4. A method according to any preceding claim, wherein the identifier of the second computing device comprises a network address of the second computing device.

5. A method according to any preceding claim, wherein the already registered service enclave is only allowed to communicate with the new service enclave after receiving and authenticating the certificate generated by the authority service.

6. A method according to any preceding claim, comprising said authority service providing said credentials only to a subset of said plurality of service enclaves.

7. A method according to any preceding claim, wherein the authority service is provided by an authority enclave hosted on the first computing device, the method further comprising the new service enclave receiving, from the authority service, a certification of software code stored in the authority service.

8. A method according to any preceding claim, comprising: The registered service enclave stores configuration data; as well as The authority service provides the configuration data to the new service enclave.

9. The method of claim 8, wherein the configuration data comprises a respective identifier for each of the plurality of service enclaves.

10. A method according to claim 8 or 9, wherein the configuration data indicates whether a service enclave of a first type is authorized to communicate with a service enclave of a second type, and the method further comprises the registered service enclave using the configuration data to determine whether to receive and process communications from another service enclave.

11. A method according to any one of claims 8 to 10, wherein the configuration data comprises expected measurement data for verifying the certification of one or more already registered enclaves of the network.

12. The method of claim 11, wherein the expected measurement data comprises a preconfigured hash of software code that the registered service enclave is expected to store.

13. The method of claim 11 or 12, further comprising the new serving enclave using the expected measurement data to attest to one or more already registered enclaves of the network.

14. The method of any one of claims 8 to 13, wherein the configuration data is signed by an offline certification authority, the method further comprising the new service enclave authenticating the configuration data using a public key of the certification authority.

15. A method according to any preceding claim, comprising receiving new software code at a registered service enclave of the plurality of service enclaves, and certifying the new software code using a public key of an offline certification authority before executing the new software code in the registered service enclave.

16. A computer system comprising an authority service hosted on a first computing device, the authority service configured to register a new service enclave from a plurality of service enclaves hosted on one or more computing devices of a network of computing devices into a set of registered service enclaves by: receiving an identifier of a second computing device of the network hosting the new service enclave; receiving, from the second computing device, an attestation of software code stored in the new service enclave using the identifier of the second computing device; in response to receiving the attestation, generating a certificate associating the identifier of the second computing device with a public key of the new serving enclave; as well as The certificate is provided to a registered service enclave of the plurality of service enclaves.

17. The computer system of claim 16, further comprising the one or more computing devices hosting the plurality of service enclaves, wherein the registered service enclaves are configured to: authenticating the certificate using the public key of the authority service; and Sending encrypted data to the new services enclave using the public key of the new services enclave.

18. A computer system according to claim 16 or claim 17, wherein the authority service is provided by an authority enclave hosted on the first computing device.

19. The computer system of any one of claims 17 to 18, further comprising a gateway enclave configured to receive and / or send to a client computing device a certificate of the authority service and / or each registered service enclave in the set of registered service enclaves.

20. The computer system of any one of claims 17 to 19, further comprising a gateway enclave configured to receive a service request from a client computing device and, in response to receiving the request, instruct an already registered enclave to perform the requested service.

21. The computer system of claim 20, wherein the gateway enclave is configured to verify the credentials of the client computing device before instructing the registered enclave to perform the requested service.

22. The computer system of any one of claims 19 to 21, wherein the client computing device is configured to verify the gateway enclave's credentials.

23. The computer system of any one of claims 19 to 22, wherein the authority service and the gateway enclave are both hosted on the first computing device.

24. The computer system of any one of claims 17 to 23, wherein at least two of the computing devices of the network have different respective processor architectures and / or computer architectures.

25. Computer software that, when executed on a first computing device of a network of computing devices, causes the first computing device to host an authority service, the authority service being configured to register a new service enclave from a plurality of service enclaves hosted on one or more computing devices of the network of computing devices into a set of registered service enclaves by: receiving an identifier of a second computing device of the network hosting the new service enclave; receiving, from the second computing device, an attestation of software code stored in the new service enclave using the identifier of the second computing device; in response to receiving the attestation, generating a certificate associating the identifier of the second computing device with a public key of the new serving enclave; as well as The certificate is provided to a registered service enclave of the plurality of service enclaves.

Images