Manifest entries

Each entry in the keys field identifies a cryptographic key that the Anjuna SGX Runtime can use to secure data. There are four types of values that are valid for entries in this field:

The bindings field, used when the source field’s value is hardware, controls the hardware flags used to automatically derive a key for the configuration. For example, the VENDOR_IDENTITY value shown in the example enables the MRSIGNER feature, and the VENDOR_ENCLAVE enables the MRENCLAVE feature.

For RSA keys, when inserting a multi-line PEM key into a YAML file, insert a pipe character ("|") after the colon (":") and indent all of the individual lines of the key by the same amount.

For example:

This optional entry is used when the Anjuna SGX Runtime is used in combination with the Anjuna Policy Manager, which is a server that allows multiple enclaves to securely gain access to encryption keys that are not tied to the Intel® SGX sealing capabilities. Intel® SGX sealing keys are specific to a CPU and cannot be used to encrypt data on multiple hosts. This makes sharing encrypted files between multiple enclaves on different hosts more complex. The Anjuna Policy Manager addresses this problem by securely delivering the encryption keys to authorized enclaves. See Policy Manager reference for more information.

Example:

One or more entries, each specifying a pathname and a key. Each entry identifies a file that the Anjuna SGX Runtime is to store encrypted, rendering it unreadable to processes outside the secure enclave. The Anjuna SGX Runtime automatically encrypts the listed files, stores them encrypted, and decrypts them inside the secure enclave as-needed.

Files not listed in the encrypted_files section of the manifest are not encrypted by the Anjuna SGX Runtime.

Each path given must match the pathname that the protected application uses to find the file. A path may be either absolute or relative, but if the application uses an absolute path to find the file, then the path should be absolute in the manifest; if the application uses a relative path, then it should be relative in the manifest.

You can use simple wildcard characters to match several files in a common path. If, for example, your application frob requires access to three files named foo.frob, bard.frob, and baz.frob in the directory /opt/quux, then you can specify them as shown in the following example:

The character '?' matches any single character; the character '*' matches any number of characters of any kind.

This optional entry is used to generate an attested file for some of the files that the application in the enclave writes. For each file listed under the attested_files: option - a single file is generated, and it contains a file header and the actual content that the application wrote. The attested file can then be verified by the receiving end to prove that this file was created by a specific trusted enclave, before using the content of that file. Attested files are described in detail on the anjuna-check-attestation documentation page.

Example:

Applications may specify the same file as both attested and encrypted to attest encrypted files. In this case, the cleartext content is encrypted and then attested:

Example:

Specifies whether runtime debug information should be printed.

The default value is error. Anjuna expects to support intermediate logging levels in the future.

Specifies which logger to use:

Specifies the IP address of a remote syslog server. Required when logger_type is remote_syslog.

Specifies the port on which a remote syslog server is listening. Required when logger_type is remote_syslog.

An optional entry to fix the command-line parameters passed to the executable. When used, anjuna-runtime does not allow parameters to be passed to the executable on the command line and instead uses the manifest values. Each command line parameter must be specified on a different line. For example, to execute the command openssl genrsa -out private_key.pem, specify the following configuration:

Example:

Defines or overwrites one or more environment variables. Any security sensitive environment variable that the application uses should be fixed in this file where it will become part of the enclave signature. If you need spaces in an environment variable value, just surround the value with quotes according to normal YAML rules.

LD_LIBRARY_PATH is a special environment variable. Anjuna recommends, at least initially, that you do not set it in your manifest template file. When not set in the template file, anjuna-compile-manifest will create it for you and will place Anjuna’s Runtime folder first in the generated LD_LIBRARY_PATH so that your program uses Anjuna’s enclave-optimized version of glibc. anjuna-compile-manifest will also place any other path needed that ldd reports when run on the executable.

For example, on a typical Linux system, the LD_LIBRARY_PATH would look like this:

Set this boolean value to true for a release enclave that can not be debugged. The default value is false. This value affects the enclave signature and will always be in the compiled manifest file.

Intel® SGX ISVPRODID value. The value must be an integer between 0 and 65535. Default value is 0.

Intel® SGX ISVSVN value. The value must be an integer between 0 and 65535. Default value is 0.

Disable AVX (Advanced Vector Extensions) support. This option should be set to needed if the CPU does not support the AVX instruction set extensions. The default value is false. This value affects the enclave signature and is always present in the compiled manifest file.

Integer specifying the enclave size (which must be a power of 2). Default is 256 MB. Capital suffixes M, and G can be added. The minimal valid value for this setting is 128M.

The maximum number of threads that the enclave executable will use. Must be an integer between 1 and 254. Default is 4.

The Anjuna SGX Runtime needs to allocate memory for each thread, so increasing num_threads may require increasing enclave_size as well.

A list of files that are measured.

When the manifest is compiled, the Anjuna SGX Runtime will compute the SHA256 hash of each file in this list, and place it under a new entry named trusted_hashes. The example above gets compiled to the following:

If, at runtime, one of these files is opened and the SHA256 hash does not match, the open syscall will fail and return an error set to EACCESS.

trusted_libs is the same as trusted_files, but every entry must be a shared library or other ELF file. When an entry is added to trusted_libs, both the entry and all shared library dependencies of that entry will be locked to a specific SHA256 hash. This is useful for shared libraries that are not compiled into an executable. For example, to load a shared library needed to interact with an HSM via a PKCS#11 API: