This release is a pre-release and may not be stable for production use.
auditee
WORK IN PROGRESS -- DO NOT USE -- DO NOT TRUST
Tool to help with auditing an SGX enclave that has been remotely attested. The idea is as follows:
Given:
- a signed enclave binary file (e.g.
Enclave.signed.so), - the source code used to build the enclave, and
- an attestation report,
an auditor verifies:
- whether the signed enclave build can be reproduced, using the source code, and a nix & docker based toolchain to rebuild the enclave binary
- Whether the MRENCLAVE and ATTRIBUTES of the provided signed Enclave match that of the rebuilt one
- Whether the MRENCLAVE and ATTRIBUTES match the ones from the provided report
Roughly speaking the goal is to establish that the source code was indeed the code used to build the signed enclave that has been successfully (remotely) attested.
Such an audit can help external users gain trust into a system which depends on Intel SGX and remote attestation. Without such an audit, remote attestation is not sufficient because the fact that an MRENCLAVE (enclave hash) matches that of the attestation verification report does not prove to a user of the system that the MRENCLAVE corresponds to a version of source code that they are willing to trust.
MRENCLAVE (enclave hash)
The MRENCLAVE, also known as enclave hash, from three sources must all match. The enclave hash is obtained via a measurment of the enclave code and data when an enclave is initialized. This measurement can also be simulated, and thus a verifier can obtain the MRENCLAVE using a build toolchain, and the SGX signing tool to get the SIGSTRUCT which contains the MRENCLAVE.
- Hash extracted from the signed enclave (
Enclave.signed.so) that is remotely attestated - Hash in the attestation report, from IAS
- Hash extracted from the enclave, which was rebuilt from source code using a nix+docker based toolchain
If (1) and (3) match then the auditor can trust that they are auditing the correct code, and can trust that the report is for the enclave that is under audit, and consequently the successful attesation can be trusted in sofar that the attestation is for source code that has been audited.
1 maintainer
Metadata
1 maintainer
Release files for auditee 0.0.1.dev2
For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.
Source distribution (sdist)
| File | Size | Uploaded | Provenance | |
|---|---|---|---|---|
| auditee-0.0.1.dev2.tar.gz | 20.8 kB | Without provenance | Details |
Release files / auditee-0.0.1.dev2.tar.gz
| Download URL | auditee-0.0.1.dev2.tar.gz |
|---|---|
| Size | 20.8 kB |
| Tags | Source |
|
SHA-256 checksum How to use checksums |
4c35a65917216b13cd57b42ab8d2e61531ee5de3529ce49d2313b6ee1dbf7fa8
|
|
BLAKE2b-256 checksum How to use checksums |
6a61943187c0a0c32c38117d0224c440e6913b35d23dde9d6c3077235d97b739
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
No |
| Uploaded via |
twine/3.3.0 pkginfo/1.5.0.1 requests/2.22.0 setuptools/45.2.0 requests-toolbelt/0.9.1 tqdm/4.43.0 CPython/3.8.0
|
Security for auditee 0.0.1.dev2
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
No provenance found
None of the files in this release were uploaded with provenance metadata.
A note on package security
PyPI is a repository for distributing packages, not a service for auditing them. While third-party security researchers and our staff do their best to detect and remove malicious packages, PyPI cannot guarantee the quality, security or suitability of any given package.
