Secure data sharing system and associated methods

Abstract

Disclosed herein is a secure data sharing system The system comprises a service interface module a trusted execution environment "TEE" in communication with the service interface module. The TEE has a first cryptographic key stored thereon, the first cryptographic key being known to the TEE and to a user device. The TEE further has a second cryptographic key different from the first cryptographic key stored thereon, the second cryptographic key being known to the TEE. The TEE is configured to: receive, from the service interface module, a first message, wherein the first message includes sensitive information encrypted with the first key; decrypt the first message using the first key to recover the information in plaintext; re-encrypt the information using the second key; and send a second message to the service interface module for use by a database management system "DBMS" associated with the service interface module, the second message including the information re-encrypted with the second key.

Description

[0001] SECURE DATA SHARING SYSTEM AND ASSOCIATED METHODS

[0002] Field

[0003] The present disclosure relates to a secure data sharing system and associated methods, in particular systems and methods capable of protecting user data in a database.

[0004] Background

[0005] In an ever more connected world, protection of sensitive user information is essential. It is increasingly common for individuals and businesses alike to upload personal, confidential, or otherwise sensitive information to online platforms for storage in databases. The databases themselves may be hosted by third parties. For example, a user may upload information which includes medical records, personal identification numbers, and / or other sensitive information to an online web service, for storage in a database. Similarly, business may upload sensitive information such as financial data to an online web service, for storage in a database.

[0006] In order to prevent misappropriation of such sensitive information, encryption can be used. For example, a user could encrypt information before they upload it to a web service for storage in a database, and store the encryption key locally. However, the user may not trust the web service and therefore may not share the encryption key with the web service. Functionality of the system, and legitimate access to the information, may as a result be limited. Accordingly, in situations in which certain specific authorized users, for example law enforcement officers, employers or government officials need to access the information, this is a sub-optimal situation.

[0007] Where a user accesses a platform via a web service, information could be encrypted by the web service before being sent to a database for storage. This may be useful where certain specific authorized users need access to the information. However, the web service could itself represent a weak point from a security perspective, and so this solution may not provide sufficient security for the user data. The user device may not be able to trust the web service. For example, information encrypted in this way may be vulnerable to bad actors associated with the web service, in which case the information stored on the associated database may be vulnerable.

[0008] Some bespoke solutions exist, in which a trusted execution environment (“TEE”) may be used for improved database security. Such an arrangement is described in CN 113609492, in which a security agent is established between the client and the cloud encrypted database to analyze user queries, and the calculation operation is separated from the comparison operation. The calculation operation is controlled by the security agent. The calculation program is executed, and the comparison operation is sent to the cloud encrypted database for execution. Significant processing is therefore performed within the security agent. In CN113609492, it is assumed that system admins and other higher-privilege users can be trusted. However, it is not always the case that system admins can be trusted.

[0009] However, a problem with such bespoke approaches is that they are not universally applicable, and require difficult-to-implement and in many cases computationally inefficient security protocols between components of the system. As such, they do not interact well with ‘off-the-shelf’ hosted database products or ‘off-the-shelf’ cloud products, such as Amazon Web Services (“AWS”), and so are not easily or widely implemented. They are inelegant, leading to inefficiencies.

[0010] An approach for protecting user data to be stored in third party databases, having improved security versatility, and / or practicality, is therefore required.

[0011] Summary

[0012] The present disclosure has been developed to address at least some of the problems described above.

[0013] In a first aspect there is provided a secure data sharing system, the system comprising: a service interface module; and a trusted execution environment “TEE” in communication with the service interface module; wherein the TEE has a first cryptographic key stored thereon, the first cryptographic key being known to the TEE and to a user device; wherein the TEE further has a second cryptographic key different from the first cryptographic key stored thereon, the second cryptographic key being known to the TEE; wherein the TEE is configured to: receive, from the service interface module, a first message, wherein the first message includes sensitive information encrypted with the first key; decrypt the first message using the first key to recover the information in plaintext; re-encrypt the information using the second key; and send a second message to the service interface module for use by a database management system “DBMS” associated with the service interface module, the second message including the information re-encrypted with the second key.

[0014] The first message may comprise a first database query directed to the DBMS, for example an INSERT database query for the storage of the information at the DBMS. The second message may also comprise the database query (albeit with an information field associated with the database query having been re-encrypted by the TEE). The first query may be a structured query language (SQL) query.

[0015] In a second aspect there is provided a secure data sharing system, the system comprising: a service interface module; and a trusted execution environment “TEE” in communication with the service interface module; wherein the TEE has a first cryptographic key stored thereon, the first cryptographic key being known to the TEE and to a user device; wherein the TEE further has a second cryptographic key different from the first cryptographic key stored thereon, the second cryptographic key being known to the TEE; wherein the TEE is configured to: receive, from the service interface module, a third message, wherein the third message includes sensitive information encrypted with the second key; decrypt the third message using the second key to recover the information in plaintext; re-encrypt the information using the first key; and send a fourth message to the service interface module for use by the user device, the fourth message including the information re-encrypted with the fist key.

[0016] The third message may comprise a second database query directed to the DBMS, for example a SELECT database query for retrieval of the information from the DBMS. The fourth message may also comprise the database query (albeit with an information field associated with the database query having been re-encrypted by the TEE). The second query may be a structured query language (SQL) query.

[0017] The service interface module may be configured for communication with a user device and a DBMS. The DBMS may be hosted by a third party. The DBMS may manage a database accessible by the service interface module. For example, the service interface module may utilize the database in order to provide a service to the user device.

[0018] The system of the first or second aspect may further comprise the user device, in communication with the service interface module. The system of the first or second aspect may further comprise the DBMS, in communication with the service interface module. The service interface module may be configured to forward the second message to the DBMS for storage of the re-encrypted information at the DBMS. The first message may originate from the user device. The service interface module may be configured to forward the fourth message to the user device. The third message may originate from the DBMS.

[0019] As the reader will understand, the first aspect may represent the upload of information from a user device to a DBMS; and the second aspect may represent the download of information (for example the same piece of information) from the DBMS to the user device. The first and second aspects are therefore complementary, and combinable.

[0020] Where a piece of information is said herein to be “known to” a unit, device or node, it is to be understood that the information has been saved by that unit, device or node, e.g. onto a storage unit accessible by that unit, device or node. Where the unit, device or node has its own associated storage unit, the information may be saved on the associated storage unit.

[0021] The first cryptographic key may not be known to the service interface module or to the DBMS. In some examples, the first cryptographic key may be known only to the user device and to the TEE. For example, the first cryptographic key may be unique to the user device and the TEE. Where the user device trusts the TEE, the user device can with confidence share the first cryptographic key with the TEE, even if the service interface module can’t necessarily be trusted. Additional security protocols for ensuring trust between the user device and the TEE are provided later. The TEE is the only device other than the user device which can access the sensitive information, which is acceptable when the user device can trust the TEE.

[0022] The system may comprise a plurality of user devices. Each user device may have a respective first cryptographic key stored thereon. Each respective first cryptographic key may be known only to the respective user device and to the TEE.

[0023] The second cryptographic key may not be known to the user device or to the service interface module or to the DBMS. In some examples, the second cryptographic key may only be known to the TEE. For example, the second cryptographic key may be unique to the TEE.

[0024] According to the first and second aspects, an elegant encryption solution, which uses a TEE for improved security, is provided. Furthermore, because of the use of the TEE associated with the service interface module, the user device knows that the service interface module can be trusted, even in cases in which a malicious system admin or other higher-privilege admin may be present at the service interface module. The service interface module can continue to communicate with the user device and with the DBMS as usual, while the TEE handles as little processing as possible (while still providing robust security), and hence the solution is elegant and readily compatible with existing off-the-shelf third party databases. No modifications to existing communication protocols with existing systems is required. The solution is thus elegant, versatile, and computationally efficient, while ensuring security of user information.

[0025] Another advantage of the invention according to the first and second aspects is that only the TEE and the user device from which the sensitive information originated are able to access the sensitive information. Because the user device trusts the TEE, they are confident in the security of their information. In some examples, as will be described later, the TEE may be provided with additional functionality for creating aggregated reports of user data. The aggregated reports may, through the process of aggregation, protect individual user data. However, the aggregated reports may provide information about the population of users, without revealing the specifics of the encrypted information of individual users. Certain authorized users may be able to access the aggregated user information in order to glean information about the population.

[0026] In a third aspect there is provided a method of operating a TEE for ensuring confidentiality of user information, for example a method of operating a system according to the first aspect. The method may comprise: receiving, from a service interface module, a first message, wherein the first message includes sensitive information encrypted with the first key; decrypting the first message using the first key to recover the information in plaintext; re-encrypting the information using the second key; and sending a second message to the service interface module for use by a database management system “DBMS” associated with the service interface module, the second message including the information re-encrypted with the second key; wherein the first cryptographic key is known to the TEE and to a user device from which the first message originated; and wherein the second cryptographic key is known to the TEE.

[0027] In a fourth aspect there is provided a method of operating a TEE for ensuring confidentiality of user information, for example a method of operating a system according to the second aspect. The method may comprise: receiving, from a service interface module, a third message, wherein the third message includes sensitive information encrypted with the second key; decrypting the third message using the second key to recover the information in plaintext; re-encrypting the information using the first key; and sending a fourth message to the service interface module for use by the user device, the fourth message including the information re-encrypted with the fist key; wherein the first cryptographic key is known to the TEE and to a user device from which the first message originated; and wherein the second cryptographic key is known to the TEE.

[0028] In a fifth aspect there is provided a computer-readable medium (for example a non- transitory computer-readable medium) having instructions stored thereon which, when executed by a processor, cause the processor to implement a method according to the third aspect or the fourth aspect.

[0029] Further optional features of the aspects will now be described.

[0030] The TEE may comprise an encryption module configured to implement the encryption and decryption described herein.

[0031] The first cryptographic key may be a symmetric cryptographic key. The second cryptographic key may be a symmetric cryptographic key.

[0032] One of the service interface module and the user device may have a permission object pertaining to the user device stored thereon. The permission object may be signed by at least one system administrator, for example by at least two system administrators. The permission object may be a data object carrying a permission pertaining to the user device. Where the permission object is periodically updated, it may be simpler to maintain freshness of the permission object on the service interface module than on the user device. The permission object may be used to establish trust between the TEE and the user device. The permission object may facilitate authorization of access to the sensitive data by the user device. As such, it may in some situations be preferable that at least two system administrators are required to sign any given permission object, as otherwise a malicious system administrator might simply grant themselves any access and circumvent the system security.

[0033] Where the permission object pertaining to the user device is maintained (e.g. stored) at the service interface module, the user device may have a certificate stored thereon. The certificate may be signed by at least one system administrator. The certificate may be used by the service interface module and / or by the TEE to authenticate the identity of the user device. The certificate may be a X.509 certificate. However, as the skilled person will understand, other types of certificate can be used as appropriate. The user device may initiate communication with the service interface module by sending the certificate to the service interface module. The service interface module may authenticate the certificate before further communicating with the user device. The service interface module may send one or both of the permission object and the certificate to the TEE after having authenticated the certificate.

[0034] The TEE may be configured, based on one or both of the permission object and the certificate received from the service interface module, to verify whether the user device is trusted. The user device may be configured, based on an attestation message received from the TEE (e.g. received via the service interface module), to verify whether trusted source code is running on the TEE. The TEE and the user device may be configured to establish the first cryptographic key when it is determined that the user device and the TEE are trusted. Establishing the first cryptographic key at the user device and at the TEE may comprise establishing a secure communication session between the user device and the TEE.

[0035] The TEE may be configured to: receive, from the service interface module, one or both of a permission object and a certificate, wherein the one or both of the permission object and the certificate are signed by at least one system administrator (in some examples at least two system administrators); determine whether the one or both of the permission object and the certificate is / are signed by the at least one system administrator; and verify that the user device is trusted when it is determined that the one or both of the permission object and the certificate is / are signed by the at least one system administrator.

[0036] The administrator signatures may be private key signatures. The determination may be performed using public keys associated with the private keys, the public keys being known to the TEE.

[0037] The user device may be configured to: receive a / the attestation message from the TEE, wherein the attestation message is generated using source code associated with the TEE; process the attestation message to determine whether the source code used to generate the attestation message is trusted; and verify that the TEE is trusted when it is determined that the source code used to generate the attestation message is trusted. The processing may comprise applying a verification algorithm to the attestation message, wherein the verification algorithm is specific to the source code associated with the TEE. The source code may include source code which runs within the TEE.

[0038] The first message may further include the permission object. The TEE may only decrypt the information using the first key when the permission object is determined to be valid.

[0039] The first message may further include the permission object, and a description of the information which is encrypted with the first key. The TEE may only decrypt the information using the first key when it is determined, based on the permission object, that the user device is permitted to handle the information described. The third message may be sent to the TEE responsive to the user device having sent a request for the information to the service interface module. The request may include the permission object. The TEE may only decrypt and re-encrypt the information if it is determined, based on the permission object received from the service interface module, that the user is permitted to access the information requested.

[0040] The service interface module may have a further permission object (e.g. a second permission object) stored thereon. The further permission object may further be signed by at least one system administrator, for example by at least two system administrators. The further permission object may pertain to the service interface module. That is to say, the further permission object may be a data object carrying a permission pertaining to the service interface module. The further permission object may be periodically updated. The further permission object may be used to establish trust between the TEE and the service interface module.

[0041] In some examples, the first message may further comprise the further permission object. In some examples, the third message may further comprise the further permission object. The TEE may be further configured, based on the further permission object, to verify that the service interface module is trusted. For example, when it is determined that the one or more signatures is valid, it may be determined that the further permission object is authentic. Where the first message or the third message includes a request, for example an INSERT query or a SELECT query, the request may only be processed or served when it is determined, based on the verification, that the service interface module is trusted.

[0042] The TEE may be configured to: receive, from the service interface module, the further permission object, wherein the further permission object is signed by at least one system administrator (in some examples at least two system administrators); determine whether the permission object is signed by the at least one system administrator; and verify that the service interface module is trusted when it is determined that the permission object is signed by the at least one system administrator. The administrator signatures may be private key signatures. The determination may be performed using public keys associated with the private keys, the public keys being known to the TEE.

[0043] The service interface module may be configured to request an aggregated report of user information from the TEE. The request for the aggregated report may include the further permission object pertaining to the service interface module. The service interface module may be configured to request an aggregated report on a periodic basis.

[0044] The TEE may be configured, in response to a request from the service interface module, to prepare an aggregated report for the service interface module. The TEE may only prepare the aggregated report for the service interface module responsive to verifying, based on the further permission object, that the service interface module is trusted.

[0045] The TEE may be configured to: receive, from the service interface module, a first request for an aggregated report pertaining to a plurality of users; responsive to the first request, issue a second request to the DBMS, the second request being a request for sensitive information pertaining to the plurality of user devices; receive the requested sensitive information from the DBMS; decrypt the requested sensitive information; aggregate the requested sensitive information into an aggregated report; and send the aggregated report to the service interface module.

[0046] The first request may further comprise the further permission object. The TEE may issue the second request responsive to verifying the further permission object.

[0047] The aggregation may be performed such that individual user data cannot be discerned from the aggregated report. The aggregated report may therefore enable the service interface module to manage a population of users, without ever having access to information pertaining to specific individual users. The aggregated report may nonetheless provide the service interface module with population-level information about the plurality of users.

[0048] The TEE may further perform, prior to sending the aggregated report to the service interface module, a condensation operation on the aggregated report. The condensation operation may comprise removing any remaining individualized user information from the aggregated report.

[0049] As a result, only the TEE can see the raw sensitive information of all users. The service interface module, upon receiving the aggregated report, only sees a population-level report with any individual personal information either being removed entirely, or diluted into the population such that individual personal information cannot be extracted. Separately, a given user device can request their own raw sensitive information, but cannot view anyone else’s raw sensitive information.

[0050] As the skilled reader will understand, the service interface module can be understood, and thus implemented, as a “user” as well, and any user (for example, a manager) could be given the permission to generate aggregated reports themselves.

[0051] Processing of data queries and / or parsing of data queries may be done at the DBMS and / or at the service interface module, for example only at the DBMS and / or at the service interface module. The DBMS and / or the service interface module may manage the database and database queries independently of the TEE.

[0052] No database management, processing of queries, or parsing of queries, may be performed at the TEE. The first and third messages may comprises an unparsed query (e.g. an unparsed database query directed to the DBMS), and the second and fourth messages may comprise the unparsed query.

[0053] The messages may further include database coordinates associated with the information, for example table name, primary key value and column name. The database coordinates may be used as additional authenticated data when the used encryption protocol comprises an Authenticated Encryption with Authenticated Data (AEAD) encryption protocol. The database coordinates may be provided as additional authentication data in cleartext form. The cleartext database coordinates may not be encrypted or decrypted at the TEE.

[0054] The sensitive information may be provided as a plaintext string for encryption. The plaintext string may not include any database coordinates.

[0055] Herein, cleartext may refer to unencrypted information which is not intended for encryption. Plaintext, on the other hand, may refer to unencrypted information which is intended for encryption. Furthermore, ciphertext may refer to the encrypted data as well as any related cryptographic material and book keeping material, such as an authentication tag, an IV, and / or any key identifiers.

[0056] The cleartext database coordinates may be used for an authenticity check. They may therefore be sent alongside the encrypted sensitive information, for example in the first message. In particular, the database coordinates may be used to ensure row-level integrity, column-level integrity, and / or table-level integrity of the reencrypted data. In particular, by calculating a computed tag produced by feeding the cleartext coordinates into the decryption step as additional authentication data (“AAD”), and comparing the computed tag to an authentication tag, the TEE can detect if a field was moved to another table, to another column, or to another row (i.e. if row-level integrity, column-level integrity, and / or table-level integrity has been violated).

[0057] That is, when decrypting the first message using the first key to recover the sensitive information in plaintext, the TEE may also feed the cleartext database coordinates into the decryption in order to calculate the computed tag. The TEE may then compare the computed tag to the authentication tag, in order to determine whether row-level integrity, column-level integrity, and / or table-level integrity has been maintained. For example, if the computed tag and the authentication tag do not correspond or do not match, integrity violation may be detected. An error message may be returned. Alternatively, or additionally, the TEE may terminate the process upon detecting the integrity violation. Accordingly, the re-encryption and sending steps may not be performed.

[0058] The authentication tag may be sent in the same message as the encrypted sensitive information and the cleartext database coordinates, e.g. in the first message. The authentication tag may have been generated by feeding the cleartext database coordinates into an initial encryption step which is performed at the user device to encrypt the sensitive information prior to sending.

[0059] Generally speaking, the authentication tag is cryptographically linked with the cleartext coordinates, such that the authentication tag can be sent with the first message and used at the TEE to verify data integrity. As the skilled reader will understand, an Authenticated Encryption with Associated Data (“AEAD”) scheme may be used for this.

[0060] The DBMS may be accessed via the service interface module. For example, the user device may access the DBMS via the service interface module. In this regard, the service interface module may be considered as a gatekeeper for the DBMS. In practice, the service interface module may utilize the DBMS in order to provide a service to the user device.

[0061] The user device may in some examples have no direct communication link with the TEE. The DBMS may in some examples have no direct communication link with the TEE. That is to say, the TEE may operate as a sidecar unit in communication with the service interface module.

[0062] The service interface module may comprises a web server. The service interface module may therefore be configured to provide a web service to the user device. As discussed above, the service interface module may utilize the DBMS in order to provide the web service.

[0063] The DBMS may comprises a database engine for running the DBMS. The DBMS may communicate with the service interface module over a local connection or over an intranet or internet connection.

[0064] The user device may communicate with the service provider module using TCP / IP, UDP / IP, or similar.

[0065] The second key may be randomly generated within the TEE. The second key may be periodically generated. All previously generated keys may be stored by the TEE.

[0066] The TEE may be a hardware module comprising a working memory which is shielded from the service interface module, such that confidentiality and integrity of code and data loaded inside the TEE is maintained. The TEE may therefore be a shielded secure environment.

[0067] The working memory may be a transitory (e.g. volatile) memory. The TEE may also comprise a non-transitory memory. The source code for the TEE may be stored on the non-transitory memory. More generally, the non-transitory memory may have stored thereon instructions for executing the functionality on the TEE. The non- transitory memory may also store thereon the first and second cryptographic key(s). The TEE may be configured such that the contents of the non-transitory memory is shielded from external devices, e.g. such that confidentiality and integrity of code and data stored on the non-transitory memory is maintained.

[0068] The TEE may comprise a separate area of a main processor on which the service interface module is run, wherein the separate area is configured such that it is shielded from operation of the service interface module. Alternatively, the TEE may comprise a separate module in communication with the service interface module, wherein the separate module is shielded from the service interface module.

[0069] Brief description of the drawings

[0070] The present disclosure will now be described in more detail, with reference to the accompanying drawings, in which: Figure 1 shows a secure data sharing system according to the present disclosure;

[0071] Figure 2 is a flow chart showing a first system setup stage executed by the system of Figure 1 ;

[0072] Figure 3 is a flow chart showing a second system setup stage executed by the system of Figure 1 ;

[0073] Figure 4 is a flow chart showing a third system setup stage executed by the system of Figure 1 ;

[0074] Figure 5 is a flow chart showing a data upload executed by the system of Figure 1 ;

[0075] Figure 6 is a flow chart showing a data download executed by the system of Figure 1 ;

[0076] Figure 7 is a flow chart showing a data aggregation operation executed by the system of Figure 1 ;

[0077] Figure 8 schematically illustrates a user device from the system of Figure 1 ;

[0078] Figure 9 schematically illustrates a web service server and associated TEE from the system of Figure 1 ;

[0079] Figure 10 schematically illustrates a DBMS from the system of Figure 1 ; and

[0080] Figure 11 shows a schematic and simplified representation of a computer apparatus which can be used to perform methods described herein.

[0081] Like references are used for like components throughout the description.

[0082] Detailed description

[0083] Figure 1 shows a secure data sharing system 100 according to the present disclosure. The system 100 includes: a user device 102; a service interface module 104; a Trusted Execution Environment (“TEE”) 106; a database management system (“DBMS”) 108; and one or more system administrators, exemplified in Figure 1 as a group of administrators 110, the group including for illustrative purposes a first administrator device 110a and a second administrator device 110b.

[0084] The user device 102 can for example be a mobile device, tablet computer, or personal computer. In other examples, the user device 102 may comprise a business terminal, or a server managed by a business. The user device 102 communicates with the service interface module 104 over a network, for example over the internet.

[0085] The service interface module 104 comprises a web server for providing a service to users (e.g. including user device 102). The service interface module 104 communicates with the user device 102 over a network, for example over the internet, in order, to provide the service to the user device 102. The service interface module 104 also communicates with the DBMS 108 over a network, such as the internet.

[0086] The DBMS 108 may be managed by a third party database provider, and may be a cloud-based product. The DBMS 108 communicates with the service interface module 104 over a network, for example over the internet. The DBMS 108 comprises a database which is accessible by the service interface module 104. The service interface module 104 uses the database in order to provide a service to the user device 102. The operator of the service provided by the service interface module 104 may pay a fee for the database to be hosted on the DBMS 108.

[0087] The TEE 106 is provided as a sidecar unit in communication with the service interface module 104. The TEE comprises an encryption engine. The TEE 106 may be provided in the same area, for example the same room or the same enclosure as the service interface module 104, and may have a direct wired connection with the service interface module 104. The TEE is provided to ensure that confidentiality is maintained for information provided by the user device 102 to the service interface module 104 for storage in the database. Owing to the presence of the TEE 106, the function and operation of which will be described below, the user device 102 knows that it can trust that confidentiality of the information being provided will be maintained. That is to say, even if the service interface module 104 and the DBMS 108 are not in and of themselves trusted by the user device 102, the TEE 106 in communication with the service interface module 104 provides the user device 102 with the required level of trust and security.

[0088] Each of the first administrator device 110a and the second administrator device 110b provides a separate respective administrating entity. They may be peers of the user device 102, or alternatively may be managed by one or more system administrators. Individually, each of the first administrator device 110a and the second administrator device 110b may not be trusted. However, when treated as a group 110, the first administrator device 110a and the second administrator device 110b may collectively be trusted. The purpose of the group 110 will be described in more detail below. As the reader will understand, the group 110 can, if required for improved security, include more than two administrator devices.

[0089] Each administrator device 110a, 110b has a key pair (comprising a public key 112a, 112b and an associated private key) associated therewith. Each administrator device 110a, 110b keeps its private key secret, but shares its public key 112a, 112b with the TEE 106. The key pairs associated with the administrator devices are used as verification keys. Stored on the user device 102 is a first certificate 114, for example a X.509 first certificate. The first certificate 114 is useable by the user device 102 to establish a secure communication link with the TEE 106. Namely, the TEE 106 can use the first certificate 114 from the user device 102 to verify the identify and intention of the user device 102, and will only establish a secure connection with the user device 102 when its identity is verified. The first certificate 114 is signed by each administrator device 110a, 110b in the group 110, using the private key associated with each administrator device 110a, 110b. The TEE 106 has stored thereon the public key 112a, 112b from each administrator device 110a, 110b. Accordingly, the TEE 106 can use the public keys 112a, 112b from each of the administrator devices 110a, 110b to verify that the first certificate 114 was signed by each of the administrator devices 110a, 110b, and thereby verify the identity of the user device 102. The service interface module 104 also manages a plurality of permission objects 120, one pertaining to each of the user devices 102 of the system. The plurality of permission objects may also comprise a permission object pertaining to the service interface module 104 itself. Each permission object is signed by a plurality of system administrators 110a, 110b from the group 110. The permission objects 120 may be periodically updated, to as to improve security. The permission objects 120 are used by the TEE 106 to verify the identity of the service interface module 104 and of the user devices 102. The TEE may only accept active (i.e. the most recently updated) permission objects 120.

[0090] No such certificate is needed at the DBMS 108. In particular, owing to the operation of the TEE 106, which is described in more detail below, the TEE 106 does not itself need to trust the DBMS 108.

[0091] Each of the user device 102 and the TEE 106 has stored thereon a first secret key 116. The secret key stored on the user device 102 is the same as the secret key 116 stored on the TEE 106. This first secret key 116 is sometimes referred to herein as a first cryptographic key. The first secret key 116 is a symmetric cryptographic key. It is known only to the user device 102 and the TEE 106. Accordingly, when information in plaintext is encrypted by either the user device 102 or the TEE 106 using the first secret key 116, the other of the user device 102 or the TEE 106 can decrypt the ciphertext using the first secret key 116. That is to say, secure communication between the user device 102 and the TEE 106 is possible using the first secret key 116. Therefore, having established the first secret key, the user device 102 can be confident that communication with the service interface module 104 is safe.

[0092] The TEE 106 also has stored thereon a second secret key 118. This second secret key 118 is sometimes referred to herein as a second cryptographic key. The second secret key 118 is a symmetric cryptographic key, and is known only to the TEE. Accordingly, by encrypting information in plaintext using the second secret key 118, the TEE 106 can ensure that no other device can read the information. Therefore, by using the second secret key 118 the TEE does not need to trust the DBMS 108 or the service interface module 104. Figure 2 is a flow chart showing a first system setup stage executed by the system of Figure 1 . The first system setup stage is performed between the group of administrators 110, the user device 102, the service interface module 104, and the TEE 106. The arrows are provided in Figure 2 to show the order in which the steps may be performed. The arrows do not necessarily indicate data transmissions between the elements of the system.

[0093] At step 202, each administrator in the group 110 generates a private key I public key pair.

[0094] At step 204, the TEE 106 receives a public key 112a, 112b from each administrator 110a, 110b. The public keys 112a, 112b may be received via the service interface module 104. The TEE 106 stores the public keys 112a, 112b thereon.

[0095] At step 206, the user device 102 establishes the first certificate 114 by having the first certificate 114 signed by each of the administrators 110a, 110b. The signing is done with the private key on each of the administrator devices 110a, 110b. The signing may be done using an Elliptic Curve Digital Signature Algorithm (“ECDSA”).

[0096] At step 208, the permission object 120 pertaining to the user device 102 is established. Administrators 110a, 110b sign a user permission object 120 with the private key on each of the administrator devices 110a, 110b. The resulting user permission object 120 (which comprises of the user permission object and the signatures) is then made accessible to the service interface module 104 for future usage. The signing may be done using an Elliptic Curve Digital Signature Algorithm (“ECDSA”). This process may be done periodically, such that the permission object 120 is periodically refreshed to further increase security.

[0097] Figure 3 is a flow chart showing a second system setup stage executed by the system of Figure 1 . The second system setup stage is performed between the service interface module 104 and the TEE 106. The arrows are provided in Figure 2 to show the order in which the steps may be performed. The arrows do not necessarily indicate data transmissions between the elements of the system. At step 301 , the service interface module 104 sends the second certificate 120 to the TEE 106.

[0098] At step 302, the TEE 106 receives the second certificate 120 from the service interface module 104.

[0099] At step 304, the TEE 106 uses the public keys 112a, 112b stored thereon to verify the authenticity of the certificate. Upon determining that the certificate is authentic, the TEE 106 determines that the service interface module 104 can be trusted.

[0100] Steps 302 and 304 may be omitted in some cases.

[0101] At step 306, the TEE 106 receives an instruction from the service interface module 104, in which the service interface module 104 instructs the TEE 106 to create the second secret key 118. The TEE accordingly generates the second secret key, and stores it thereon. Step 306 may be periodically repeated. The TEE 106 may therefore include a list of past and present second secret keys 118.

[0102] Figure 4 is a flow chart showing a third system setup stage executed by the system of Figure 1 . The third system setup stage is performed between the user device 102 and the TEE 106, in order to establish a secure communication link between the user device 102 and the TEE 106. For the purpose of Figure 4, where a message is sent from the user device 102 to the TEE 106 or vice versa, it is to be understood that the message travels via the service interface module 104.

[0103] At step 401 , the user device 102 sends the first certificate 114 to TEE 106.

[0104] At step 402, the TEE 106 receives from the user device 102 the first certificate 114.

[0105] At step 404, the TEE 106 uses the public keys 112a, 112b stored thereon to verify the authenticity of the first certificate 114. Upon determining that the first certificate 114 is authentic, the TEE 106 determines that the user device 102 can be trusted. At step 405, and responsive to determining that the user device 102 can be trusted, the TEE sends an attestation message to the user device 102. The attestation message includes a data package generated based on the source code running on the TEE 106.

[0106] At step 406, the user device 102 receives attestation message from the TEE 106. The attestation message comprises the data package generated based on source code associated with the TEE.

[0107] At step 408, the user device 102 processes the attestation message, and in particular applies a hash function to the data package, wherein the hash function is specific to the source code associated with the TEE.

[0108] At step 410, and based on determining that the message was generated using source code which is associated with the hash function, the user device 106 verifies that the TEE 106 is trusted.

[0109] Generally speaking, steps 408 and 410 outline an approach of processing the attestation message, and determining based on the processing whether the TEE is trusted. Steps 408-410 may be performed slightly differently depending on the specific type of TEE, but this general outline may be more generally applicable.

[0110] At step 412, based that the TEE 106 trusting the user device 102 and vice versa, the TEE 106 and the user device 102 mutually establish the first secret key 116, to thereby establish secure communication with the user device 102.

[0111] As the reader will understand, the methods of Figures 2 to 4 may all be performed in order to establish safe communications within the system 100. The method of Figure 3 may be performed before or after the method of Figure 4. In some examples, the method of Figure 3 may not be performed.

[0112] Having established secure communication between the components of the system 100, upload to the DBMS 108, and download from the DBMS 108, can be performed securely from the user device 102. As the reader will understand, in some examples the methods of Figures 2 to 4 may not need to be performed, for example in examples in which the system 100 is already configured.

[0113] As can be seen, the DBMS 108 is not involved in the setup stages of Figures 2 to 4. This is because trust is only strictly needed between the TEE 106 and the user device 106. Accordingly, no special or bespoke communication protocols are needed with the DBMS 108. The service interface module 104 can accordingly communicate with the DBMS 108 as usual.

[0114] Figure 5 is a flow chart showing a data upload executed by the system of Figure 1 .

[0115] At step 502, the user device 102 sends a message to the service interface module 104. The message comprises a request to store information in the DBMS 108. The message includes: a sensitive piece of information encrypted with the first secret key 116; semantic information pertaining to the information which is encrypted (sometimes referred to herein as “description of the information which is encrypted”); and a user identifier (optionally including the first certificate 114), and an authentication tag. The semantic information includes database coordinates for the information, namely: table name, column name, and primary key value. The semantic information may also include a description of the type or class of information which is encrypted. The authentication tag may have been calculated during encryption of the sensitive information at the user device 102 with the first secret key, by feeding the database coordinates into the encryption.

[0116] The database coordinates may have two functions. They may be used for correct storage in the DBMS. They may also be used as authentication data for the encrypted sensitive piece of information. Namely, the database coordinates may be cryptographically linked with the authentication tag, such that the coordinates can be cryptographically checked against the authentication tag to confirm data integrity, as will be described in more detail below.

[0117] At step 504, the service interface module 104 receives the message. At step 508, service interface module 104 sends a message (corresponding to the first message of the first aspect) to the TEE 106. The first message includes: the encrypted sensitive piece of information; the semantic information; and the user identifier (including the permission object 120 pertaining to the user device 102 and optionally including the first certificate 114). An identifier for the service interface module 104 (for example a further permission object 120 pertaining to the service interface module 104) may also be included with the first message. The first message may be sent in the form of an SQL query, for example an INSERT database query for the storage of the information at the DBMS.

[0118] At step 510, the TEE 106 receives the first message.

[0119] At step 512, the TEE 106 performs one or more of the following verifications as appropriate: verifying the first certificate 116; verifying the user permission object(s) 120. The TEE 106 also checks, based on the verified identity of the user device 102 and the description of the type or class of information which is encrypted in the second message, that the user device is permitted to deal in such information.

[0120] At step 514, responsive to verifying permissions at step 512, the TEE 106 decrypts the sensitive piece of information using the first secret key 116. A calculated tag may be calculated by feeding the database coordinates into the decryption and may be compared to the authentication tag in order to authenticate the obtained plaintext and / or check data integrity.

[0121] At step 516, the TEE 106 re-encrypts the sensitive piece of information using the second secret key 118. The database coordinates, and optionally permission data, may be used in the re-encryption as additional authenticated data.

[0122] At step 518, the TEE 106 sends a message (corresponding to the second message of the first aspect) to the service interface module 104. The second message includes at least the re-encrypted sensitive piece of information. The second message may also be sent in the form of an SQL query, for example a SELECT query for retrieval of the information form the DBMS. At step 520, the service interface module 104 receives the message.

[0123] At step 522, the service interface module 104 forwards the message to the DBMS 108, for storage of the re-encrypted sensitive piece of information in the database according to the semantic information.

[0124] At step 524, the DBMS 108 receives the message.

[0125] At step 526, the DBMS 108 saves the re-encrypted sensitive piece of information in the database according to the semantic information.

[0126] As the reader will understand, the first message and the second message may each include multiple pieces of information, each having its own respective database coordinates and permission information. One or more of the pieces of information may be sensitive and therefore treated as described above using decryption and reencryption. The first message and the second message may therefore include a plurality of pieces of information, a first portion thereof being in cleartext form or plaintext form, and a second portion thereof being in ciphertext form.

[0127] Figure 6 is a flow chart showing a data download executed by the system of Figure 1.

[0128] At step 602, the user device 102 sends a message to the service interface module 104. The message comprises a request to retrieve information from the DBMS 108. The message includes: semantic information pertaining to the information being requested (which may include database coordinates for the information being requested and a description of the type of information which is being requested); and an identifier for the user device 102 (e.g. the certificate 114).

[0129] At step 603, the service interface module 104 receives the message from the user device 102.

[0130] At step 604, the service interface module 104 assigns, based on the description of the type of information which is being requested, database coordinates for the information being requested, for example a table number, row number, and column number at which the piece of information is stored in the database.

[0131] At step 606, the service interface module 104 sends a message to the DBMS 108. The message includes at least: the semantic information pertaining to the information being requested; and the identifier for the user device 102 (e.g. the certificate 114). The semantic information may include the database coordinates and a description of the type or class of information being requested. The message may also include the permission object 120 pertaining to the user device 102 and the permission object 120 pertaining to the service interface module 104. The message may be sent in the form of an SQL query.

[0132] At step 607, the DBMS 108 receives the message.

[0133] At step 608, the DBMS 108 retrieves the requested piece of information from the database based on the semantic information in the message.

[0134] At step 610, the DBMS 108 sends a message (corresponding to the third message of the second aspect) to the service interface module 104. The message includes the requested piece of information in ciphertext; and may also include further information, for example the semantic information and / or other information, in cleartext. The requested piece of information in ciphertext is encrypted with the second secret key.

[0135] At step 612, the service interface module 104 receives the message from the DBMS 108.

[0136] At step 614, the service interface module 104 forwards the message to the TEE 106, along with the semantic information, an identifier for the user device 102 (for example the permission object 120 pertaining to the user device 102 and optionally the certificate 114), and an identifier for the service interface module 104 (for example the further permission object 10 pertaining to the service interface module 104).

[0137] At step 616, the TEE 106 receives the message from the service interface module 102. At step 618, the TEE 106 performs one or more of the following verifications as appropriate: verifying the first certificate 114; verifying the permission object(s) 120. The TEE 106 also checks, based on the verified identity of the user device 102, the user permission object(s) 120, and the description of the type of information which is being requested, that the user device is permitted to request such information.

[0138] At step 620, responsive to verifying permissions at step 618, the TEE 106 decrypts the requested piece of information using the second secret key 118. The database coordinates, and optionally permission data, may be used as additional authentication data. .

[0139] At step 622, the TEE 106 re-encrypts the requested piece of information using the first secret key 116. The database coordinates, and optionally permission data, may be used in the re-encryption as additional authenticated data.

[0140] At step 624, the TEE sends a message (corresponding to the fourth message of the second aspect) to the service interface module. The message includes at least the re-encrypted requested piece of information.

[0141] At step 626, the service interface module 104 receives the message from the TEE 106.

[0142] At step 628, the service interface module 104 forwards the message to the user device 102.

[0143] At step 630, the user device 102 receives the message from the service interface module 104 and decrypts the requested information back into plaintext form using the first secret key 116. The database coordinates, and optionally permission data, may be used as additional authentication data. For example, a calculated tag may be calculated by feeding the database coordinates into the decryption and may be compared to the authentication tag in order to authenticate the obtained plaintext and / or check data integrity. As the reader will understand, the third message and the fourth message may each include multiple pieces of information, each having its own respective database coordinates. One or more of the pieces of information may be sensitive and therefore treated as described above using decryption and re-encryption. The third message and the fourth message may therefore include a plurality of pieces of information, a first portion thereof being in cleartext form, and a second portion thereof being in ciphertext form.

[0144] Figure 7 is a flow chart showing a data aggregation operation executed by the system of Figure 1 .

[0145] At step 706, the service interface module 104 sends to the DBMS module 108 a request for information pertaining to a plurality of user devices 102. The requested information may include sensitive user information which has been encrypted by the TEE. The message may include semantic information pertaining to the information being requested. The semantic information may include the database coordinates and a description of the type or class of information being requested. The description of the type of information being requested may include date information or date range information, and department information, for example information identifying a department of users for whom aggregated data is requested. The message may be sent in the form of an SQL query.

[0146] At step 707, the DBMS 108 receives the message.

[0147] At step 708, the DBMS 108 retrieves the requested pieces of information from the database based on the semantic information in the message.

[0148] At step 710, the DBMS 108 sends a message to the service interface module 104. The message includes the requested pieces of information in ciphertext; and may also include further information, for example the semantic information and / or other information, in cleartext. The requested pieces of information in ciphertext are encrypted with the second secret key. At step 712, the service interface module 104 receives the message from the DBMS 108.

[0149] At step 714, the service interface module 104 forwards the message to the TEE 106, along with the semantic information, and an identifier for the service interface module 104 (for example the further permission object pertaining to the service interface module 104).

[0150] At step 716, the TEE 106 receives the message from the service interface module 102.

[0151] At step 718, the TEE 106 performs a verification using the further permission object 120. The TEE 106 also checks, based on the verified identity of the service interface module 104 and the aggregated information being requested, that the service interface module 104 is permitted to request such aggregated information.

[0152] At step 720, responsive to verifying permissions at step 718, the TEE 106 decrypts the requested pieces of information using the second secret key 118. The database coordinates, and optionally permission data, may be used as additional authentication data. .

[0153] At step 722, the TEE aggregates the obtained plaintext information to generate an aggregated report in which personal information is diluted between the user devices and therefore is not discernible. Optionally, further condensation or scrubbing is then applied to the aggregated report in order to further remove any remaining user information.

[0154] At step 724, the TEE sends the aggregated report to the service interface module 104.

[0155] At step 726, the service interface module 104 receives the aggregated report.

[0156] Figure 8 schematically illustrates an example user device 102 according to an example of the present disclosure. The user device 102 includes one or more processors 802, and a memory 804. Memory 804 has stored thereon instructions for executing by the processor, and also has data stored thereon. The data stored thereon includes user data, some of which is sensitive information. The data also includes cryptographic keys for ensuring secrecy of the sensitive information. For example, the first cryptographic key may be stored on the memory 804, in addition to the sensitive information which is to be sent in the first message. Figure 11 shows a possible architecture for the user device 102.

[0157] Figure 9 schematically illustrates a secure web service environment 900 which includes the service interface module 104, and the TEE 106. As shown, the TEE 106 is provided within a segregated area 901 of the web service environment 900.

[0158] Accordingly, only very limited communication between the service interface module 104 and the TEE 106 is possible. More specifically, the service interface module 104 is able to send messages to the TEE 106 and receive messages back from the TEE 106. However, the service interface module 104 is not able to access or amend the contents of the memory 908, and is not able to view or manipulate the processing which occurs in the processor 906.

[0159] Service interface module 104 includes one or more processors 902, and a memory 904. Memory 904 has stored thereon instructions for executing by the processor 902, and also has data stored thereon. The data may for example include the permission objects 120. Figure 11 shows a possible architecture for the service interface module 104.

[0160] TEE 106 includes one or more processors 906, and a memory 908. Memory 908 has stored thereon instructions for executing by the processor 906, and also has data stored thereon. The data includes cryptographic keys for ensuring secrecy of user information. For example, the TEE has stored thereon the public keys 112a, 112b, the first secret key(s) 116, and the second secret key 118.

[0161] Figure 10 schematically illustrates an example DBMS 108 according to an example of the present disclosure. The DBMS 108 includes one or more processors 1002, and a memory 1004. Memory 1004 has stored thereon instructions for executing by the processor 1002, and also has database contents information stored thereon. The data stored thereon includes user data, some of which is encrypted sensitive information. Figure 11 shows a possible architecture for the DBMS 108.

[0162] Figure 11 shows an example computer architecture for the user device 102, service interface module 104, or DBMS module 108 according to the present disclosure.

[0163] Figure 11 shows a schematic and simplified representation of a computer apparatus 1100 which can be used to perform methods described herein, either alone, in combination with other computer apparatuses or as part of a network or a “cloud” computing arrangement.

[0164] The computer apparatus 1100 comprises various data processing resources such as a processor 1102 (in particular, a hardware processor) coupled to a central bus structure. Also connected to the bus structure are further data processing resources such as memory 1104. A display adapter 1106 connects a display device 1108 to the bus structure. One or more user-input device adapters 1110 connect a user-input device 1112, such as a keyboard and / or a mouse to the bus structure. One or more communications adapters 1114 are also connected to the bus structure to provide connections to other computer systems 1100 and other networks.

[0165] In operation, the processor 1102 of computer system 1100 executes a computer program comprising computer-executable instructions that may be stored in memory 1104. When executed, the computer-executable instructions may cause the computer system 1100 to perform one or more of the methods described herein. The results of the processing performed may be displayed to a user via the display adapter 1106 and display device 1108. User inputs for controlling the operation of the computer system 1100 may be received via the user-input device adapters 1110 from the userinput devices 1112.

[0166] It will be apparent that some features of computer system 1100 shown in Figure 11 may be absent in certain cases. For example, one or more of the plurality of computer apparatuses 1100 may have no need for display adapter 1106 or display device 1108. This may be the case, for example, for particular server-side computer apparatuses 1100 which are used only for their processing capabilities and do not need to display information to users. Similarly, user input device adapter 1110 and user input device 1112 may not be required. In its simplest form, computer apparatus 1100 comprises processor 1102 and memory 1104.

[0167] The above detailed description describes a variety of example arrangements for and methods of performing distributed decryption. However, the described arrangements and methods are merely exemplary, and it will be appreciated by a person skilled in the art that various modifications can be made without departing from the scope of the appended claims.

[0168] More generally, it should be appreciated that the number of steps shown in the figures is not intended to be limiting. Steps may be repeated as often as necessary and certain steps may be omitted.

[0169] The computer apparatus discussed above may be a local computer or a server.

[0170] While various specific combinations of components and method steps have been described, these are merely examples. Components and method steps may be combined in any suitable arrangement or combination. Components and method steps may also be omitted to leave any suitable combination of components or method steps.

[0171] The described methods may be implemented using computer executable instructions. A computer program product or computer readable medium may comprise or store the computer executable instructions. The computer program product or computer readable medium may comprise a hard disk drive, a flash memory, a read-only memory (ROM), a CD, a DVD, a cache, a random-access memory (RAM) and / or any other storage media in which information is stored for any duration (e.g., for extended time periods, permanently, brief instances, for temporarily buffering, and / or for caching of the information). A computer program may comprise the computer executable instructions. The computer readable medium may be a tangible or non-transitory computer readable medium. The term “computer readable” encompasses “machine readable”. In an implementation, the modules, components and other features described herein can be implemented as discrete components or integrated in the functionality of hardware components such as ASICS, FPGAs, DSPs or similar devices.

[0172] The singular terms “a” and “an” should not be taken to mean “one and only one”. Rather, they should be taken to mean “at least one” or “one or more” unless stated otherwise. The word “comprising” and its derivatives including “comprises” and “comprise” include each of the stated features, but does not exclude the inclusion of one or more further features.

[0173] The above implementations have been described by way of example only, and the described implementations are to be considered in all respects only as illustrative and not restrictive. It will be appreciated that variations of the described implementations may be made without departing from the scope of the disclosure. It will also be apparent that there are many variations that have not been described, but that fall within the scope of the appended claims.

Claims

Claims1. A secure data sharing system, the system comprising: a service interface module; and a trusted execution environment “TEE” in communication with the service interface module; wherein the TEE has a first cryptographic key stored thereon, the first cryptographic key being known to the TEE and to a user device; wherein the TEE further has a second cryptographic key different from the first cryptographic key stored thereon, the second cryptographic key being known to the TEE; wherein the TEE is configured to: receive, from the service interface module, a first message, wherein the first message includes sensitive information encrypted with the first key; decrypt the first message using the first key to recover the information in plaintext; re-encrypt the information using the second key; and send a second message to the service interface module for use by a database management system “DBMS” associated with the service interface module, the second message including the information re-encrypted with the second key.

2. The system of claim 1 , further comprising: the user device, in communication with the service interface module; wherein the first message originates from the user device.

3. The system of claim 1 or claim 2, further comprising: the DBMS, in communication with the service interface module; wherein the service interface module is configured to forward the second message to the DBMS for storage of the re-encrypted information at the DBMS.

4. A secure data sharing system, the system comprising: a service interface module; anda trusted execution environment “TEE” in communication with the service interface module; wherein the TEE has a first cryptographic key stored thereon, the first cryptographic key being known to the TEE and to a user device; wherein the TEE further has a second cryptographic key different from the first cryptographic key stored thereon, the second cryptographic key being known to the TEE; wherein the TEE is configured to: receive, from the service interface module, a third message, wherein the third message includes sensitive information encrypted with the second key; decrypt the third message using the second key to recover the information in plaintext; re-encrypt the information using the first key; and send a fourth message to the service interface module for use by the user device, the fourth message including the information re-encrypted with the fist key.

5. The system of claim 4, further comprising: the user device, in communication with the service interface module; wherein the service interface module is configured to forward the fourth message to the user device.

6. The system of claim 4 or claim 5, further comprising: a DBMS in communication with the service interface module; wherein the third message originates from the DBMS.

7. The system according to any preceding claim, wherein one or each of the first cryptographic key and the second cryptographic key is a symmetric cryptographic key.

8. The system according to any preceding claim, wherein the first cryptographic key is known only to the TEE and to the user device.

9. The system of claim 2 or claim 5, wherein the TEE is configured, based on one or both of a permission object and a certificate received from the service interface module, to verify whether the user device is trusted; and wherein the user device is configured, based on an attestation message received from the TEE, to verify whether trusted source code is running on the TEE; and wherein the TEE and the user device are configured to establish the first cryptographic key when it is determined that the user device and the TEE are trusted; optionally wherein the permission object and the certificate pertain to the user device, wherein the certificate originates from the user device, and wherein the permission object originates from the service interface module.

10. The system of claim 9, wherein the TEE is configured to: receive, from the service interface module, one or both of the permission object and the certificate, wherein the one or both of the permission object and the certificate is / are signed by at least one system administrator; determine whether the one or both of the permission object and the certificate is / are signed by the at least one system administrator; and verify that the user device is trusted when it is determined that the one or both of the permission object and the certificate is signed by the at least one system administrator.11 . The system of claim 9 or claim 10, wherein the user device is configured to: receive a / the attestation message from the TEE, wherein the attestation message is generated using source code associated with the TEE; process the attestation message to determine whether the source code used to generate the attestation message is trusted; and verify that the TEE is trusted when it is determined that the source code used to generate the attestation message is trusted.

12. The system according to claim 9 or claim 10 when dependent upon claim 1 , wherein the first message further includes the permission object, and wherein the TEE only decrypts the information using the first key when the permission object is determined to be valid.

13. The system of claim 9 or claim 10 when dependent upon claim 1 , wherein the first message further includes the permission object, and a description of the information which is encrypted with the first key, and wherein the TEE only decrypts the information using the first key when it is determined, based on the permission object, that the user device is permitted to handle the information described.

14. The system of claim 9 or claim 10 when dependent upon claim 4, wherein the third message is sent to the TEE responsive to the user device having sent a request for the information to the service interface module, wherein the request includes the permission object, and wherein the TEE only decrypts and re-encrypts the information if it is determined, based on the permission object, that the user is permitted to access the information requested.

15. The system of any preceding claim, wherein processing of data queries and / or parsing of data queries is done at the DBMS.

16. The system of any preceding claim, wherein the DBMS manages the database and database queries independently of the TEE.

17. The system of any preceding claim, wherein no database management, processing of queries, or parsing of queries, is performed at the TEE.

18. The system of claim 17, wherein the first or third message comprises an unparsed query, and wherein the second or fourth message comprises the unparsed query.

19. The system of claim 9, wherein the administrator signatures are private key signatures, and wherein the determination is performed using public keys associated with the private keys, the public keys being known to the TEE.

20. The system of any preceding claim, wherein the DBMS is accessed via the service interface module.21 . The system of any preceding claim, wherein the user device has no direct communication link with the TEE.

22. The system of any preceding claim, wherein the DBMS has no direct communication link with the TEE.

23. The system of any preceding claim, wherein the service interface module comprises a web server.

24. The system of any preceding claim, wherein the DBMS comprises a database engine for running the DBMS.

25. The system of any preceding claim, wherein the DBMS communicates with the service interface module over a local connection or over a cloud connection.

26. The system of any preceding claim, wherein the user device communicates with the service provider module using TCP / IP, UDP / IP, or similar.

27. The system of any preceding claim, wherein the second key is randomly generated within the TEE.

28. The system of any preceding claim, wherein the second key is periodically generated, and wherein all previously generated keys are stored by the TEE.

29. The system of any preceding claim, wherein the TEE is a hardware module comprising a working memory which is shielded from the service interface module, such that confidentiality and integrity of code and data loaded inside the TEE is maintained.

30. A method of operating a TEE for ensuring confidentiality of user information, the method comprising: receiving, from a service interface module, a first message, wherein the first message includes sensitive information encrypted with the first key;decrypting the first message using the first key to recover the information in plaintext; re-encrypting the information using the second key; and sending a second message to the service interface module for use by a database management system “DBMS” associated with the service interface module, the second message including the information re-encrypted with the second key; wherein the first cryptographic key is known to the TEE and to a user device from which the first message originated; and wherein the second cryptographic key is known to the TEE.31 . A method of operating a TEE for ensuring confidentiality of user information, the method comprising: receiving, from a service interface module, a third message, wherein the third message includes sensitive information encrypted with the second key; decrypting the third message using the second key to recover the information in plaintext; re-encrypting the information using the first key; and sending a fourth message to the service interface module for use by the user device, the fourth message including the information re-encrypted with the fist key; wherein the first cryptographic key is known to the TEE and to a user device from which the first message originated; and wherein the second cryptographic key is known to the TEE.

32. A computer-readable medium having instructions stored thereon which, when executed by a processor, cause the processor to implement a method according to claim 30 or claim 32.

Images