Home
Trellis++ provides the first primitive, i.e., integrity protection of the private data and software code utilizing cryptographic hash functions. Cryptographic hash functions represent an input string or message as a hash value, i.e., a message digest. This message digest is a compact and uniquely identifiable representation of the input string. More formally, cryptographic hash functions (hash functions in short) map an arbitrary length input message
The hash function h comprises the following properties:
- Compression: the function h with a domain D and range R maps a finite input of arbitrary bit-length, to an output h(x) of fixed-length; that is, h: D -> R and |D| > |R| and R is n bits long.
- Easy forward computation: given an input string x and a function h, h(x) is easy to compute.
-
Preimage resistance: The output of the hash function h must not reveal any information about the input message
$m$ . That is, given a message digest y but no corresponding input string x, it is computationally infeasible to find h(x') = y. - 2nd-preimage resistance: Given a fixed x and x != x', it is computationally infeasible to find h(x) = h(x').
- Collision Resistance: In simple words, it is extremely unlikely to find two different inputs that can produce the same digest (output.) It is computationally infeasible to compute h(x) = h(x'), given any two x and x’ where x and x' are distinct.
For the following discussion, we use concepts [1]. Trellis++ provides a primitive for confidentiality through Public Key Encryption (PKE) Schemes. A transformation E_k defines encryption of a message/plaintext m to obtain a ciphertext c using key k. That is, c = E_k(m). A transformation D_{k’} defines decryption of a ciphertext c to obtain the original message m using key k’. That is, m = D_{k’}(c). Keys k and k’ are said to have an asymmetric relationship in that a message encrypted with one key can only be decrypted with the other and vice-versa. A public-key encryption scheme PKE generates two asymmetric binary keys used to encrypt and sign data; the public key b and the private/secret key v. The private key v is assumed to be kept in a secure place and never exposed/revealed to an adversarial environment, ideally not even in an encrypted form. The security of PKE relies on it being computationally infeasible for an adversary to discover v given b.
When PKE is used for encryption, two participants can exchange public keys prior to commencing encrypted communication. When one participant needs to send an encrypted message m to the other, the sender can compute c_b = E_b(m) where b is the public key of the recipient, and then send c_b over a potentially untrusted channel to the recipient, whose exclusive knowledge of their private key v allows them to successfully decrypt the message by computing m = D_v(c_b).
When used for authentication and data integrity, a participant wishes to prove that they are the holder of a particular private key v without disclosing v and also wishes to guarantee that some message is not altered after creation by an adversary. To accomplish this, the participant starts with a known message
What remains is a mechanism to decide which public keys are trustworthy and which are not: i.e. we need a method to ensure that a valid key is authentic. The use of Public Key Infrastructure (PKI) enhances the security guarantees of the PKE schemes through the inclusion of a trusted third party called an issuer or certified authority (CA). An issuer generates digital certificates containing a client’s public key which the issuer signs with their private key. The issuer distributes their public key set through an accepted channel to all PKI participants, and therefore any participant which can prove they hold the private key corresponding to a public key from a digital certificate signed by the trusted issuer is assumed to be attested as trustworthy by the issuer.
Trusted Execution Environments (TEEs) are a recent industry innovation to enhance the privacy of data and computation [Brandenburger]. Through specialized execution environments (enclaves) TEEs defend against an adversarial environment, i.e., operating system, hypervisor, firmware, and drivers. TEEs include functionality to encrypt sensitive communications, seal (encrypt) data, and verify the integrity of code and data.
Intel SGX (Software Guard Extensions) is a hardware implementation of the TEE concept. It is an extension of the Intel architecture that intends to supply confidentiality and integrity guarantees to computation run in a potentially adversarial environment, i.e., where the Kernel, OS, and/or Hypervisor are potentially malicious, such as a remote shared cloud platform. SGX depends on software attestation and sealing mechanisms to prove that a user or application code is actually communicating with the correct piece of software hosted within a secure container in the trusted hardware and not a malicious simulator. Intel SGX tackles the secure remote computation problem by creating a trusted execution region in the remote computer’s processor. The protected execution region is called an \textit{enclave}. An enclave is a secure container that contains the secret code and data. The intended algorithm/computation and data is uploaded from the normal untrusted region into the enclave (secure container) by the remote computation service user. We utilize this enclave in the compute engine.
To prove that a specific piece of code/algorithm is actually running in trusted hardware, Intel SGX relies on local and remote attestation. The attestation mechanism provides proofs. A proof comprises a cryptographic signature of the enclave's content (code, data, parameters) using the platform’s own secret attestation key. In local attestation, the proof is verifiable by another enclave running in the same environment, allowing enclaves to securely collaborate to reach a result. In remote attestation, the signature on the proof can be verified by a third party as having originated from a piece of trusted hardware using the assumption that the secret key within the processor hardware is unknown outside of the hardware itself and the hardware never reports that key in any sort of processor instruction.
Remote attestation requires the Quoting Enclave (QE), shown as the bottom box inside the client’s trusted edge node in the Figure. The QE verifies the REPORT from the main enclave (left-hand green box). Also, the QE transforms the REPORT into a QUOTE by signing it with the platform’s Provisioning Key. The attestation process is as follows:
- The first step includes the secure container (green enclave in the Figure) informing the application that requires a secret outside of the enclave. Secure communication is established with a server (broker). The server (broker) sends a challenge as a response. This challenge serves as proof that the enclave is authentic and has not been tampered with.
- The certified code (application) gives the challenge message (from the server/broker) to the enclave.
- The enclave creates a manifest and generates a cryptographic hash of the content; In particular, it uses the EREPORT instruction and the user data. Also, to relate the manifest to a specific enclave a REPORT is generated for the Quoting Enclave. Hence, the enclave transmits the REPORT to the application.
- To verify and sign the REPORT the application sends the REPORT to the Quoting Enclave (QE).
- The QE verifies the REPORT. The QE creates and signs the QUOTE utilizing the Provisioning Key.
- The application transmits the QUOTE and manifest to the server/broker.
- Intel Attestation Services (IAS) validate the QUOTE signature. The server validates the integrity of the manifest using the QUOTE structure. The server confirms the expected answer to the original challenge (checks the challenge-response).
This process (remote attestation) allows the participants to attest that a particular combination of code, data, and parameters is running in a genuine Intel SGX-enabled CPU. The QUOTE can be verified using Intel’s Attestation Services. Please refer to [2] for a detailed description of the Remote Attestation process.
The creation of a group and member-private-keys follows the next steps:
- The issuer creates an issuing-private-key for the new group.
- The issuer creates the group certificate that contains the group-public-key.
- Through bulk-provisioning, the issuer generates unique Intel EPID member-private-keys.
- A member creates an Intel EPID signature digitally signing a message m with the Intel EPID member-private-key.
- The verifier checks the validity of a digital signature using the group-public-key that is embedded in the group digital certificate.
Some notes regarding the issuer and group signatures:
- The issuer keeps the issuing-private-key in a secure place.
- The issuer builds and maintains the revocation lists.
- The issuer forgets any member-private-keys.
- A single group-public-key corresponds to every member-private-key in the group.
- The generated Intel EPID signature does not reveal any member's private identifiable information.
Note: Full description of use cases and applications will be posted after paper publication.
There are an enormous number of potential applications for Trellis++ with its OSC+PAC model. Here we show a few illustrative examples, but this list should by no means be considered exhaustive or even fully representative.
A Consumer-Facing Food Company, known as CFFC, wishes to create periodic sustainability reports for consumers to strengthen their brand.
A farmer would like to report the dates they planted various fields to the Farm Services Agency (FSA).
A livestock farmer must maintain records of total nitrogen, phosphorus, and potassium amounts applied to farm fields through the spreading of manure for approval from state environmental agencies.
The global fishing industry would like to eliminate over-fishing by requiring fishing vessels to catch fish only in approved areas.
In fresh produce, often each export market has their own rules and regulations around which crop protection products (herbicides, insecticides, fungicides, etc.) can be applied to particular crops.
One of the more difficult certification problems is characterized by a mass balance. In its simplest form, there is some mass of product that has been certified to be produced (either based upon the total inputs to the process, or based upon a human auditor’s assessment), and the industry would like to know that the seller of a product indeed can certifiably produce that amount of that product. For example, if an organic farmer could receive a certification that they can or did produce 10 tons of organic apples, downstream buyers of those apples would like to know that the farmer has not re-used that 10-ton organic certification multiple times with multiple buyers, thereby selling potentially non-organic apples under an organic certificate.