m‎ > ‎t‎ > ‎

j

Lock it up —

Google releases open source framework for building “enclaved” apps for cloud

Toolkit aims to make building "confidential computing" containerized apps easier.

Sean Gallagher - May 3, 2018 7:48 pm UTC

EnlargeGoogle

Today, Google is releasing an open source framework for the development of “confidential computing” cloud applications—a software development kit that will allow developers to build secure applications that run across multiple cloud architectures even in shared (and not necessarily trusted) environments. The framework, called Asylo, is currently experimental but could eventually make it possible for developers to address some of the most basic concerns about running applications in any multi-tenant environment.

Container systems like Docker and Kubernetes are designed largely to allow untrusted applications to run without exposing the underlying operating system to badness. Asylo (Greek for “safe place”) aims to solve the opposite problem—allowing absolutely trusted applications to run “Trusted Execution Environments” (TEEs), which are specialized execution environments that act as enclaves and protect applications from attacks on the underlying platform they run on.

"The threats people are concerned about are things like rootkits or bootkits, things that hit the lower rings of the operating system stack," said Rob Sadowski, Google's Trust and Security marketing lead, in an interview with Ars. "And also, when you get into cloud or any shared infrastructure—virtualization on premises or in the cloud—you could have administrators or third parties who have access at these layers. So there's always this tension where you have people asking, 'How do I make sure I'm the only person who has access to any of this stuff?'"

Most major cloud services already offer measures such as logging and access controls to help monitor and lock down application environments. Some applications require even more assurance of their security—such as encryption key management, financial applications, and other tasks that enterprises might not feel at ease putting even into their own internal virtualization environments for security reasons. But as the need to ramp up some of these applications increases—for example, to manage encryption keys for thousands of Internet of Things devices—the imperative to find a way to scale them up in the cloud has grown as well.

Where did we get TEE?

The TEE concept was originally defined 10 years ago by the Open Mobile Terminal Platform, an organization of mobile network operators and mobile device vendors as part of a hardened mobile environment for mobile commerce and accessing protected pay-per-view mobile videos. But the TEE concept is now being applied to building hardened, "enclave-ized" applications atop technologies such as ARM's TrustZone security extension and Intel's Trusted Execution Technology (TXT) and Software Guard Extensions (SGX).

The problem has been that these capabilities have not been abstracted out in a way that makes it accessible for most developers to build enclaved applications of their own. While there have been some demonstrations of the use of TEE-type applications for tasks like cryptography—Wolf SSL ran a demonstration of a cloud-based cryptographic system based on SGX at the 2016 Intel Developer Forum—building such applications has required very highly specialized knowledge and tools, linked specifically to a particular hardware platform. And many of the proofs of concept for such enclaved applications have run only on workstation hardware.

That's a tools gap that the Asylo framework is aimed at closing. The SDK, available in version 0.2 for C++ developers, abstracts out multiple hardware and software back-ends for applications so they can be easily recompiled for any of them without a source code change. There's also a Docker image provided via Google Container Registry that includes all the dependencies needed to run the container on any environment that supports TEE.

"Asylo applications do not need to be aware of the intricacies of specific TEE implementations," wrote Google Cloud Senior Product Manager Nelly Porter and other members of the Google Cloud team in a blog post published today. "[Y]ou can port your apps across different enclave backends with no code changes. Your apps can run on your laptop, a workstation under your desk, a virtual machine in an on-premises server, or an instance in the cloud."

The current Asylo implementation provides enclaves through the use of a software back-end. "We are exploring future backends based on AMD Secure Encryption Virtualization (SEV) technology, Intel® Software Guard Extensions (Intel® SGX), and other industry-leading hardware technologies that could support the same rebuild-and-run portability," the Asylo team wrote in its blog post. And in a future release of Asylo, existing applications will be able to be run in an enclave by simply copying their source code into an Asylo container and recompiling them for the target platform. Support for other container environments, such as Kubernetes, is also expected, Porter told Ars.

Sean Gallagher Sean is Ars Technica's IT and National Security Editor. A former Navy officer, systems administrator, and network systems integrator with 20 years of IT journalism experience, he lives and works in Baltimore, Maryland. Email sean.gallagher@arstechnica.com // Twitter @thepacketrat

28 Reader Comments

  1. Ike Rumba Smack-Fu Master, in training et Subscriptor Even as an open source project, a nice integration into their container cloud offerings should serve as a nice competitive advantage for corporations weary of the underlying platform (and all the attack surface that comes with it).
  2. Nevarre Ars Legatus Legionis Ike Rumba wrote:Even as an open source project, a nice integration into their container cloud offerings should serve as a nice competitive advantage for corporations weary of the underlying platform (and all the attack surface that comes with it).

    I'm still extremely distrustful of cloud providers holding truly sensitive data, but this is a step in the right direction. It would be interesting to see how and if it gets integrated into FIPS-compliant cloud settings.
  3. MechR Ars Scholae Palatinae Quote:The TEE concept was originally defined 10 years ago by the Open Mobile Terminal Platform, an organization of mobile network operators and mobile device vendors as part of a hardened mobile environment for mobile commerce and accessing protected pay-per-view mobile videos.
    I knew there'd be a DRM angle.
  4. Fatesrider Ars Tribunus Militum et Subscriptor Hmmm...

    My angle about something like this would be a bit weird.

    Having a user-operated protected cloud server might be useful in a somewhat different way. I've always been a proponent of AI, but I loathe and despise that I have to inhabit some corporate ecosystem to do it.

    Having an AI on one's personal, user-operated, protected, cloud server might be a way around all of that. I'd rather pay to operate something like that than get a corporate AI mining my privacy for free.

    Now, all I'd need would be an AI to stick on it...
  5. ZenMasta Ars Praetorian I don't know if it's just me but I don't really care for the name. I know asylum has a couple of meanings but I generally always think of it negatively, as in a mental asylum. Rather than helping and providing shelter to refugees etc.
  6. fuzzyfuzzyfungus Ars Praefectus MechR wrote:Quote:The TEE concept was originally defined 10 years ago by the Open Mobile Terminal Platform, an organization of mobile network operators and mobile device vendors as part of a hardened mobile environment for mobile commerce and accessing protected pay-per-view mobile videos.
    I knew there'd be a DRM angle.

    That angle is basically the second-oldest reason for interest in "trusted systems". The feds were first, since they had classified information to worry about before piracy-with-a-computer was remotely cost effective(eg. TCSEC in 1983); but DRM (above the assorted clever but crude mucking with floppy disk geometry and such) came fairly early. Something like this Xerox patent in 1994. It didn't mutate into XML for another few years; but remains with us to this day.

    Also, until 'cloud computing' trying to sell to filthy pirate users were the "how can I protect this on someone else's computer?" use case.
  7. jonomacd Wise, Aged Ars Veteran Nevarre wrote:Ike Rumba wrote:Even as an open source project, a nice integration into their container cloud offerings should serve as a nice competitive advantage for corporations weary of the underlying platform (and all the attack surface that comes with it).

    I'm still extremely distrustful of cloud providers holding truly sensitive data, but this is a step in the right direction. It would be interesting to see how and if it gets integrated into FIPS-compliant cloud settings.


    As opposed to some random company running their own stack...? No thank you, I trust amazon and google to lock down and secure their environment and network way more than most banks even.
  8. Don Reba Ars Praetorian et Subscriptor "Google grants Asylo to C++ developers."
  9. Azethoth666 Ars Praefectus ZenMasta wrote:I don't know if it's just me but I don't really care for the name. I know asylum has a couple of meanings but I generally always think of it negatively, as in a mental asylum. Rather than helping and providing shelter to refugees etc.
    A Silo. Asylo.

    Anyway, try to take your meds before the people in white coats come for you, its easier all around.
  10. RRob Ars Scholae Palatinae I was wondering how malware might use better hardware support to hide from us on our own computers. But you nailed it.
    Quote:DRM
  11. Darkness1231 Ars Tribunus Militum et Subscriptor A nice thing, and somewhat important, is a way to secure AWS servers. So many releases of unprotected data available to anyone.

    I bet Google could even charge money for that service.


    /s
  12. WaveRunner Ars Praefectus MechR wrote:Quote:The TEE concept was originally defined 10 years ago by the Open Mobile Terminal Platform, an organization of mobile network operators and mobile device vendors as part of a hardened mobile environment for mobile commerce and accessing protected pay-per-view mobile videos.
    I knew there'd be a DRM angle.

    Of course there is a DRM angle.. there's also a financial angle, and a medical history angle, and a oh wait... let's say there is an everything angle that uses encrypted data period.

    These ideas also go as far back as 2002 when Microsoft started the TwC (Trust Worthy Computing) initiative.
  13. Takumar Smack-Fu Master, in training This article fails to explain why as a developer I should trust this solution to host my secrets. Also you failed to mention previous work at GlobalPlatform (mostly driven by ARM) to standardize TEE API. This is just Google PR.
  14. Jeremy W Ars Scholae Palatinae Darkness1231 wrote:A nice thing, and somewhat important, is a way to secure AWS servers. So many releases of unprotected data available to anyone.

    I bet Google could even charge money for that service.


    /s
    It’s not “AWS servers” (EC2) but the S3 storage service. And of course it can be secured, but wouldn’t you know it, there are a lot of people out there setting this stuff up who really have no idea what they’re doing.
  15. Darkness1231 Ars Tribunus Militum et Subscriptor Jeremy W wrote:Darkness1231 wrote:A nice thing, and somewhat important, is a way to secure AWS servers. So many releases of unprotected data available to anyone.

    I bet Google could even charge money for that service.


    /s
    It’s not “AWS servers” (EC2) but the S3 storage service. And of course it can be secured, but wouldn’t you know it, there are a lot of people out there setting this stuff up who really have no idea what they’re doing.
    Thanks for clearing that up.

    It is rather odd (to me) that so many data stores are left out like that. But then, it is somewhat amazing that others are routinely scouring the internet looking for them.
  16. xWidget Ars Scholae Palatinae Jeremy W wrote:Darkness1231 wrote:A nice thing, and somewhat important, is a way to secure AWS servers. So many releases of unprotected data available to anyone.

    I bet Google could even charge money for that service.


    /s
    It’s not “AWS servers” (EC2) but the S3 storage service. And of course it can be secured, but wouldn’t you know it, there are a lot of people out there setting this stuff up who really have no idea what they’re doing.
    I dunno. It can be pretty difficult to click the "not public" button when you're a contractor with such a small budget

    ...of millions of dollars per contract.
  17. jerk Seniorius Lurkius So this could potentially help a little right at the moment of attack, a running container may not be accessible to the attacker. But it can't know if it is e.g. launched in an emulator, which would make the attacker be able to access or change exactly anything in that so called "Trusted Execution Environment".
  18. xWidget Ars Scholae Palatinae jerk wrote:So this could potentially help a little right at the moment of attack, a running container may not be accessible to the attacker. But it can't know if it is e.g. launched in an emulator, which would make the attacker be able to access or change exactly anything in that so called "Trusted Execution Environment".
    The way I'm understanding it, and I could be wrong, is that anything inside the TEE is unusable to anything outside the TEE, and vice versa. I'm not 100% sure it would prevent a host-level rootkit from injecting itself into a container, but if that specific case weren't accounted for it should prevent an infected host from later looking through its running containers.
  19. Takumar Smack-Fu Master, in training xWidget wrote:The way I'm understanding it, and I could be wrong, is that anything inside the TEE is unusable to anything outside the TEE, and vice versa. I'm not 100% sure it would prevent a host-level rootkit from injecting itself into a container, but if that specific case weren't accounted for it should prevent an infected host from later looking through its running containers.

    This is roughly the idea indeed, TEE data can't be seen from the less trusted Linux environment. It has a lot less code, and usually access to some hardware blocks to speed up crypto. TEEs come in many forms and shapes, some of them being actual separate CPU cores, others being virtualized using ARM TrustZone or similar tech. TEE will run external code (called Trusted Applications) but only after checking signatures and possibly version revokation.

    Having a rootkit invade the TEE would mean having to defeat the TEE entrypoint barriers (some mobile TrustZone implementations have had logical issues in the past, that could be exploited to the point of code execution), or by a more fancy attack (RowHammer or the more recent Spectre variants could work here, in case of TrustZone), but then that's an extra effort.
  20. ken_lewis81 Seniorius Lurkius This is a bit thin. It looks like rewrite-the-press-release ftw.

    No discussion of a threat model where virtualisation meant sharing tin and containers offer more customers per rack, and so you need to assume your internet-facing service is also on the same hardware as potential adverseries -- who can use hardware flaws like Rowhammer to write into your process's RAM or Spectre and Meltdown to read from your side.

    No mention of what a 'Trusted Execution Environment' mean back in the initial days of Open Mobile Terminal Platform, Palladium or the TPM -- where an organisation might want to have control of their hardware by cryptographic attestation that the programs you're running are what they were intended to be. This is typically done by measuring a cryptographic hash of the program code and confirming it's in use. To retain that control over the system, there has to be a chain of attested and trusted program code built up from boot time, starting from some secure repository of startup info. In-house servers, desktops and laptops might need this to default-deny non-approved programs while JS in web browsers, Java or dotNET runtimes and even python/perl/php/shell executors might side-step this. The media companies who didn't want their customers to insert a 'digital tap' on the streaming digital video or music that we stream were also keen for this.

    No mention of HSM for cloud offerings, which is where the 'do you trust their hardware?' question is currently for cloud. If you have other people's programs you don't control possibly doing things to your programs on that shared hardware, you will want your cloud provider to attest that they're running the software you uploaded and not a compromised, hacked version, say, with a back door installed, or that your encrypted network connections and storage hav their keys visible in ordinary RAM. So there's a need to make security when time-sharing someone else's cloud servers a common, reliable and easy thing and it seems that Asylo is an enclave for just that: you measure what you upload, you whitelist what it's allowed to touch, there's a guard system which can report on your programs and the state of your containers and VM's.

    SGX is Intel's enclave. It has a non-X86/non-AMD64 code executor doing that monitoring and reporting. AMD has a bought-in product from ARM, called TrustZone, which also appears in your cellphone chips and forthcoming ARMv8 server chips.

    The interesting turn is "how do I know I can trust this?" So if you were to try to write your own enclave implementation for SGX, you'd need documentation and to do a deal with Intel. How that works is discussed in https://eprint.iacr.org/2016/086.pdf * which highlights side issues around 'who do you trust and why?' which also applies to TrustZone. This PDF is an easy read and suggests all the questions we should be asking in this space about how safe the shared cloud server space is, and how it might be better secured -- I think we have a long way to go in many fields for engineering reliable computer systems.

    *: found via https://pavelmachek.livejournal.com/142355.html when it was syndicated to http://planet.kernel.org/

    K3n.
  21. cecilroytoo Ars Praefectus et Subscriptor Latin, not Greek.
  22. AnonBS Smack-Fu Master, in training Quote:It’s not “AWS servers” (EC2) but the S3 storage service. And of course it can be secured, but wouldn’t you know it, there are a lot of people out there setting this stuff up who really have no idea what they’re doing.


    I agree with you on many have no clue about what they are doing in cloud. But on S3 you can store your data encrypted. You can use AWS provided encryption and if you don't trust them, encrypt yourself. The way cloud is taking off, in the next 5 to 10 years, it makes no sense for many companies to run their own datacenters.
  23. Sonnung Wise, Aged Ars Veteran Azethoth666 wrote:ZenMasta wrote:I don't know if it's just me but I don't really care for the name. I know asylum has a couple of meanings but I generally always think of it negatively, as in a mental asylum. Rather than helping and providing shelter to refugees etc.
    A Silo. Asylo.

    Anyway, try to take your meds before the people in white coats come for you, its easier all around.

    This is what I thought as well, A Silo. In packaging/warehousing, "Silo" is often used in automation to denote a bin or storage location that contains multiple items that are all of one type. In that relation, the Silo would be one online area used for one group of cloud resources or cloud people.
    Cloud People. cue ominous music
  24. ProfessorGuy Ars Scholae Palatinae So... they just write an empty API that returns values to the user who is calling these security libraries and they have all your data.

    Oh, you mean only use the provided API if it's genuine. And how, on someone else's computer, are you assuring that?
  25. Reaperman2 Ars Praetorian Takumar wrote:This article fails to explain why as a developer I should trust this solution to host my secrets.

    That doesn't strike me as the job of an article like this.
  26. passivesmoking Ars Tribunus Militum OK, I'm not 100% convinced of the utility of this. In a shared environment it would certainly offer a layer of protection against an abusive/malicious co-tenant, but surely there's no way to mitigate completely against bugs in the hosting environment itself? If there was then Spectre and Meltdown would not have been such huge deals.

    I'm not saying you shouldn't use this, but I also think it'd be foolish to assume it would insulate you completely from issues with hosting your application in the cloud.
  27. mchine Smack-Fu Master, in training Good news for small companies and websites slightly outside the wordpress scope, bad news for smaller hosting companies who charge 1000$ for a dedicated server.

    Personally though i'm starting to b tempted by the 1GB fiberconnections to start a hosting service myself and stack more containers in my bedroom than wall-E.

You must login or create an account to comment.

Channel Ars Technica

← Previous story Next story →

#auto

Subpages (1): g
Comments