linux-sgx | Intel SGX for Linux* | Infrastructure Automation library
kandi X-RAY | linux-sgx Summary
kandi X-RAY | linux-sgx Summary
Intel Software Guard Extensions (Intel SGX) is an Intel technology for application developers seeking to protect select code and data from disclosure or modification. The Linux\* Intel SGX software stack is comprised of the Intel SGX driver, the Intel SGX SDK, and the Intel SGX Platform Software (PSW). The Intel SGX SDK and Intel SGX PSW are hosted in the [linux-sgx] project. The [SGXDataCenterAttestationPrimitives] project maintains an out-of-tree driver for the Linux\* Intel SGX software stack, which will be used until the driver upstreaming process is complete. It is used on the platforms with Flexible Launch Control and Intel AES New Instructions support and could support both Elliptic Curve Digital Signature algorithm (ECDSA) based attestation and Enhanced Privacy Identification (EPID) based attestation. Note: Ice Lake Xeon-SP (and the future Xeon-SP platforms) doesn’t support EPID attestation. The [linux-sgx-driver] project hosts the other out-of-tree driver for the Linux\* Intel SGX software stack, which will be used until the driver upstreaming process is complete. It is used to support Enhanced Privacy Identification (EPID) based attestation on the platforms without Flexible Launch Control. The [intel-device-plugins-for-kubernetes] project enables users to run container applications running Intel SGX enclaves in Kubernetes clusters. It also gives instructions how to set up ECDSA based attestation in a cluster. The [intel-sgx-ssl] project provides a full-strength general purpose cryptography library for Intel SGX enclave applications. It is based on the underlying OpenSSL* Open Source project. Intel SGX provides a build combination to build out a SGXSSL based SDK as [below] #build-the-intelr-sgx-sdk-and-intelr-sgx-sdk-installer). Users could also utilize this cryptography library in SGX enclave applications seperately. This repository provides a reference implementation of a Launch Enclave for Flexible Launch Control under [psw/ae/ref_le] psw/ae/ref_le). The reference LE implementation can be used as a basis for enforcing different launch control policy by the platform developer or owner. To build and try it by yourself, please refer to the [ref_le.md] psw/ae/ref_le/ref_le.md) for details.
Support
Quality
Security
License
Reuse
Top functions reviewed by kandi - BETA
Currently covering the most popular Java, JavaScript and Python libraries. See a Sample of linux-sgx
linux-sgx Key Features
linux-sgx Examples and Code Snippets
Community Discussions
Trending Discussions on linux-sgx
QUESTION
I cannot for the life of me get the LocalAttestation sample to run correctly on a fresh Linux install, following the instructions successfully. Given this is being built in simulation mode, I would have thought there were no additional dependencies?
I modified the demo to provide extra output, and this line returns 3002 SGX_ERROR_INVALID_ATTRIBUTE:
...ANSWER
Answered 2018-Sep-24 at 15:22Turns out this was an issue with the sample code. By initializing the launch_token zeroed out, everything works as expected:
QUESTION
char n[12];
sgx_read_rand(reinterpret_cast(&n),
sizeof(n));
mbedtls_printf("ENCLAVE: Salt for the password: %llu\n", *(char *)n);
string salt(n);
mbedtls_printf("ENCLAVE: Salt for the password: %s\n", salt.c_str());
...ANSWER
Answered 2018-May-17 at 07:11First of all, yes it's possible to convert it to a string. But you have to understand the types you're using.
QUESTION
After reading lots of documentation i did the first simple enclave function:
...ANSWER
Answered 2017-Nov-04 at 07:10Dimitris first check if you have compatible hardware from this list https://github.com/ayeks/SGX-hardware
Then try to clone an run this repo https://github.com/digawp/hello-enclave
That will help you understand how it works
QUESTION
I'm trying to perform a local attestation between two enclaves created from two different applications.
The provided sample code for Linux here creates 3 different enclaves and then establishes secure connections between them. But those enclaves have all been created by the same application which therefore is aware of all enclave IDs.
If two different applications are creating there own enclave which should communicate with one another, how would the source enclave get to know the ID of the destination enclave? Would that ID have to be transmitted from one application to the enclave on a "general" way (IPC)?
I've tried some simple test by starting a destination enclave and printing its ID: "26ce00000002"
Then I used this ID in the local attestation example to try to connect to this running destination enclave:
...ANSWER
Answered 2017-Jan-24 at 08:52We do not need a secure connection to exchange the enclave id's. The Application can store the enclave id in a registry or on the disc along with the enclave names which can be retrieved by corresponding application to obtain the id of the required enclave. Then the application initiates a session between the source enclave and the destination enclave by doing an ECALL into the source enclave, passing in the enclave id of the destination enclave. Upon receiving the enclave id of the destination enclave, the source enclave does an OCALL into the core untrusted code which then does an ECALL into the destination enclave to exchange the messages required to establish a session using ECDH Key Exchange protocol.
Community Discussions, Code Snippets contain sources that include Stack Exchange Network
Vulnerabilities
No vulnerabilities reported
Install linux-sgx
Support
Reuse Trending Solutions
Find, review, and download reusable Libraries, Code Snippets, Cloud APIs from over 650 million Knowledge Items
Find more librariesStay Updated
Subscribe to our newsletter for trending solutions and developer bootcamps
Share this Page