4 ms·

The main TEE wikipedia article wasn't very informative for me (about as high level as this blog post). Looking through links off of that brought me to Intel's "

The main TEE wikipedia article wasn't very informative for me (about as high level as this blog post). Looking through links off of that brought me to Intel's "Software Guard Extensions" wikipedia[1] article, which actually defines enclaves: "Intel SGX is a set of central processing unit (CPU) instruction codes from Intel that allows user-level code to allocate private regions of memory, called enclaves, that are protected from processes running at higher privilege levels." I still don't fully understand the security model of enclaves (for instance, the same wikipedia page also talks about modifying spectre to work against enclaves[2]). [1]https://en.wikipedia.org/wiki/Software_Guard_Extensions https://en.wikipedia.org/wiki/Software_Guard_Extensions [2]https://github.com/lsds/spectre-attack-sgx https://github.com/lsds/spectre-attack-sgx (disclaimer: I work at Google, but obviously not on this)

savagaon 8y ago
Disclaimer: I am from the Asylo team. You can find an overview of what enclaves are at https://asylo.dev/about/overview.html https://asylo.dev/about/overview.html. The security model of enclaves is as follows: Enclaves rely on the OS for their resource management/scheduling, however, the OS cannot compromise the enclave.
- option_greek 8y ago
  Is it possible to write applications in languages other than C/Cpp ? Even with Cpp, it appears from the examples that this seems more about handling specific secure data and seem to rely on special data structures. How do we convert existing applications to take advantage of Asylo ? Does it involve moving the sensitive parts to a enclave app and communicating with it from normal one ?
  - savagaon 8y ago
    The release today is just a start. We are looking at supporting additional languages and toolchains. Future releases/community contributions should also bring richer POSIX support. As to refactoring--it is really up to the developer. With sufficient POSIX support, an entire POSIX-compliant app can live inside an enclave. On the other hand, for security reasons, the developer may decide to refactor their application.
  - matthewgingell 8y ago
    Disclaimer: I work on the Asylo Team We started with C/C++ mostly because that's what we need for the bottom layer of a POSIX-like stack. For instance, to use OpenSSL we need to be able to build C and if we wanted to support, for instance, Python we would need to build its C language components. Some of the applications we want to target include Redis and SQLite and, again, there we need C and broad support for POSIX APIs. Ideally, those applications would build for Asylo out of the box, but we have some work to do to get that to work. Going forward, we are very interested in broader language support. For instance, we are currently working on support for Go. Rust would also be interesting because it (potentially) offers an orthogonal set of security guarantees at compile time.
    - option_greek 8y ago
      Makes sense. Eagerly waiting for NodeJS and Mono to be recompiled using Asylo. Do you foresee additional complexity in supporting managed languages ? I'm guessing a mono program with base recompiled to Asylo would be more secure than using SecureString in C#.
      - deeglaze 8y ago
        Disclaimer: I am from the Asylo team The Asylo framework has partial support for POSIX APIs and system calls. Each programming language implementation that implicitly depends on system calls in either its generated code or runtime environment will need to be inspected and tested. Languages that depend on unimplemented system calls or POSIX APIs to provide basic functionality will pose some challenge, depending on just which system it needs. If a runtime forwards calls to non-crucial system calls that Asylo does not currently support, then Asylo would need extending to satisfy the linker with at least a stub implementation that calls abort(). Asylo does provide support for basic I/O, sockets, and threads, so basic language functionality within Asylo should not be a significant challenge. We welcome any pull requests you might have to support your favorite language. Developers using Asylo still must be concerned about writing buggy code. If you write past the end of a buffer with user data passed into the enclave, that code is still vulnerable. We haven’t fixed that part of the software development process.
- rogerbinns 8y ago
  It would be helpful if the doc made it clear which enclaves are supported, and how you get your code onto them. While reading several of the pages I couldn't work out if this is x86 specific, supports ARM etc too, and how you would even get hello world into the enclave in the first place.
  - deleted 8y ago
    [deleted]
  - bluegate010 8y ago
    Thanks for the helpful feedback. To answer your question: Asylo is currently x86 specific and provides a simulated enclave backend. We plan on evaluating additional enclave technologies going forward, with the goal of supporting those which gain the most market traction and community support. Obvious disclaimer: currently working at Google on Asylo.
deleted 8y ago
[deleted]
artie_effim 8y ago
I curious if they are in Common Criteria evaluation? Is there a target of evaluation available?

savagaon 8y ago

Disclaimer: I am from the Asylo team. You can find an overview of what enclaves are at https://asylo.dev/about/overview.html https://asylo.dev/about/overview.html. The security model of enclaves is as follows: Enclaves rely on the OS for their resource management/scheduling, however, the OS cannot compromise the enclave.

option_greek 8y ago
Is it possible to write applications in languages other than C/Cpp ? Even with Cpp, it appears from the examples that this seems more about handling specific secure data and seem to rely on special data structures. How do we convert existing applications to take advantage of Asylo ? Does it involve moving the sensitive parts to a enclave app and communicating with it from normal one ?
- savagaon 8y ago
  The release today is just a start. We are looking at supporting additional languages and toolchains. Future releases/community contributions should also bring richer POSIX support. As to refactoring--it is really up to the developer. With sufficient POSIX support, an entire POSIX-compliant app can live inside an enclave. On the other hand, for security reasons, the developer may decide to refactor their application.
- matthewgingell 8y ago
  Disclaimer: I work on the Asylo Team We started with C/C++ mostly because that's what we need for the bottom layer of a POSIX-like stack. For instance, to use OpenSSL we need to be able to build C and if we wanted to support, for instance, Python we would need to build its C language components. Some of the applications we want to target include Redis and SQLite and, again, there we need C and broad support for POSIX APIs. Ideally, those applications would build for Asylo out of the box, but we have some work to do to get that to work. Going forward, we are very interested in broader language support. For instance, we are currently working on support for Go. Rust would also be interesting because it (potentially) offers an orthogonal set of security guarantees at compile time.
  - option_greek 8y ago
    Makes sense. Eagerly waiting for NodeJS and Mono to be recompiled using Asylo. Do you foresee additional complexity in supporting managed languages ? I'm guessing a mono program with base recompiled to Asylo would be more secure than using SecureString in C#.
    - deeglaze 8y ago
      Disclaimer: I am from the Asylo team The Asylo framework has partial support for POSIX APIs and system calls. Each programming language implementation that implicitly depends on system calls in either its generated code or runtime environment will need to be inspected and tested. Languages that depend on unimplemented system calls or POSIX APIs to provide basic functionality will pose some challenge, depending on just which system it needs. If a runtime forwards calls to non-crucial system calls that Asylo does not currently support, then Asylo would need extending to satisfy the linker with at least a stub implementation that calls abort(). Asylo does provide support for basic I/O, sockets, and threads, so basic language functionality within Asylo should not be a significant challenge. We welcome any pull requests you might have to support your favorite language. Developers using Asylo still must be concerned about writing buggy code. If you write past the end of a buffer with user data passed into the enclave, that code is still vulnerable. We haven’t fixed that part of the software development process.
rogerbinns 8y ago
It would be helpful if the doc made it clear which enclaves are supported, and how you get your code onto them. While reading several of the pages I couldn't work out if this is x86 specific, supports ARM etc too, and how you would even get hello world into the enclave in the first place.
- deleted 8y ago
  [deleted]
- bluegate010 8y ago
  Thanks for the helpful feedback. To answer your question: Asylo is currently x86 specific and provides a simulated enclave backend. We plan on evaluating additional enclave technologies going forward, with the goal of supporting those which gain the most market traction and community support. Obvious disclaimer: currently working at Google on Asylo.

deleted 8y ago

[deleted]

artie_effim 8y ago

I curious if they are in Common Criteria evaluation? Is there a target of evaluation available?